-
1. Re: Gateways
tfennelly Jan 17, 2007 5:46 AM (in response to jpount)Can you post the stack trace here please John?
-
2. Re: Gateways
bernard.tison Jan 17, 2007 8:38 AM (in response to jpount)John,
The two-way courier can be used for a request/reply scenario. In the route(message) method of the CBRProxyAction class you'll find some code that illustrates the way it works. It uses a unique identifier as a message selector in the replyToEPR to make sure that the reply message is correlated to the original request message so that you don't have to do this correlation yourself.
HTH
Bernard -
3. Re: Gateways
jpount Jan 17, 2007 5:54 PM (in response to jpount)Guys,
Thanks for the replies.
The classcast exception was my receiving application expecting a jms TextMessage but I actually received a jboss/esb message. I have since changed the JMSRouter action to a Notifier (NotifyQueues) and it works ok although I'm not sure this is the correct/preferred way to do it.
I will certainly look at the TW courier today and see if I can get it working.
A bit off the subject, but in terms of general design do you know the best way to set up service like the one described below - ie imagine a service which needed to get customer information from a number of systems and combine it all in a response or outgoing message. The service would be called by a consumer, passing in a message containing say a customer id and/or name. The service would then need to make a call to a Web Service and an external app via JMS, get the responses back, combine them and create a message to pass back to the consumer.
I assume that there would be a gateway/action to start the service and then other actions or utility classes would be called to get the data (as in the Content Enricher and Composed Message Processor patterns). Would you call the WS directly from within code or use an ESB router for example?
Also, I assume that any validation / transformation would be done in the action class sitting behind the gateway ie a message comes in and you apply an XSD to the message to catch errors, then maybe do semantic error checks and perhaps transform the message into another format (Canonical Data Model pattern) before passing it on to the actions which perform the business logic. Where does security come in ?
I know it's a lot, and the ESB is new but any thoughts or suggestions would be greatly appreciated
Cheers,
John -
4. Re: Gateways
tfennelly Jan 18, 2007 4:59 AM (in response to jpount)Hi John.
"jpount" wrote:
The classcast exception was my receiving application expecting a jms TextMessage but I actually received a jboss/esb message. I have since changed the JMSRouter action to a Notifier (NotifyQueues) and it works ok although I'm not sure this is the correct/preferred way to do it.
All message payloads on the bus are carried within an instance of org.jboss.soa.esb.message.Message. The JMSRouter will not unwrap this message and route only the payload unless told to explicitly (by setting the "unwrap" property on the action to true).
The default behaviour is to leave the message wrapped under the assumption that the message is being routed to a "Message Aware Listener" (verses a "Gateway Listener") - more on this below. Basically, it supports routing within the bus, or routing "off the bus". See the javadoc for the JMSRouter class and it's superclass AbstractRouter."jpount" wrote:
A bit off the subject, but in terms of general design do you know the best way to set up service like the one described below - ie imagine a service which needed to get customer information from a number of systems and combine it all in a response or outgoing message. The service would be called by a consumer, passing in a message containing say a customer id and/or name. The service would then need to make a call to a Web Service and an external app via JMS, get the responses back, combine them and create a message to pass back to the consumer.
Check out the Trailblazer sample. It does something similar to this. jBPM is slatted for addition very soon (not for the GA though I think). This will add support for proper orchestration."jpount" wrote:
I assume that there would be a gateway/action to start the service and then other actions or utility classes would be called to get the data (as in the Content Enricher and Composed Message Processor patterns). Would you call the WS directly from within code or use an ESB router for example?
The basic idea is as follows...
1. You use a Gateway to route an "ESB unaware" message onto the bus i.e. a Gateway gets you onto the bus.
2. The Gateways only job is to make the message "ESB aware" (+ of course manage the protocol - HTTP, JMS etc).
3. The Gateway then routes the "ESB aware" message to a "Message Aware Listener".
4. The "Message Aware Listener" applies a list of actions to the message, one of which could be a routing action of some sort (internal, or "off the bus").
Something to note here - Gateways DO NOT apply actions under the current architecture. They just wrap-and-route!"jpount" wrote:
Also, I assume that any validation / transformation would be done in the action class sitting behind the gateway ie a message comes in and you apply an XSD to the message to catch errors, then maybe do semantic error checks and perhaps transform the message into another format (Canonical Data Model pattern) before passing it on to the actions which perform the business logic. Where does security come in ?
As I mentioned above, Gateways do not apply actions to a message. This would be done by a Message Aware Listener.
Validation is not currently a core service provided by the ESB, but there's nothing to stop anyone writing an action that performs validation. As far as Transformation is concerned, there's an action supplied for performing transformations (SmooksTransformer) and it can be used to apply XSLT, Java, Groovy and other types of transformation to an XML or non-XML message. See the MessageTransformation PDF on the docs/services folder, as well as the following flash demos:
1. console-demo-01
2. console-demo-02