WebService-Proxy for Content-Based Routing (CBR)

[eric.hubert]

Hi all,

please assist me in putting up the configuration for the following scenario.

 (SOAP over HTTP) ----- WebService 1 (host C)
Client (host A) ------> JBoss ESB (host B) -|
 ----- WebService 2 (host D)

The client sends a SOAP request to the ESB. The ESB shall forward the request to the proper WebService (1 or 2) based on a certain SOAP header information (e.g. a version Number).

I asume that I can setup anything via configuration and don't have to write a single line of Java source code (eg. for a Proxy WebService). I hope this assumption is correct.

Thanks for any pointer.

Regards,
Eric

PS: I already studied the quickstarts provided with JBoss ESB but couldn't map them to my use case, as most of them are dedicated to JMS.

[tfennelly]

Hi Eric.

Your usecase isn't yet catered for out-of-the-box. The piece that's missing is the ability to route HTTP requests off the bus i.e. to ESB unaware endpoints. The SOAPClient is already doing this via Apache Commons HttpClient. When building the SOAPClient, we abstracted out the HttpClient stuff, but we didn't create a standalone "HttpInvoker/HttpClient" type ESB Action that could be reused independently. See the "HttpClient Configuration" section in SOAPClient.

Using the SOAPClient code as a basis, it wouldn't actually be too difficult to write this component for the ESB. Might actually be possible to extract a super class from SOAPClient (HttpClient?) that pulls up the Http invocation aspects.

[eric.hubert]

Hi Tom!

"tfennelly" wrote:
Hi Eric.
Your usecase isn't yet catered for out-of-the-box.
Using the SOAPClient code as a basis, it wouldn't actually be too difficult to write this component for the ESB. Might actually be possible to extract a super class from SOAPClient (HttpClient?) that pulls up the Http invocation aspects.

Thank you very much for your quick reply! I hope someone could give me more details on how I could get this use case working. Defining this exact scenario in WSO2 ESB and Bea Auqalogic ServiceBus took me only a few minutes. So I expected it to be the same with JBoss ESB. At least manageable within a day.
I'm not sure wheter I understood the JBoss ESB architecture correctly. So please correct me, if I'm wrong about the steps involved.
1. The SOAP message has to be received by some kind of HTTP-Listener
2. The message has to be converted to some kind of JBoss ESB native message format, as CBR and other services are only be able to work on that. Right? So am I forced to use a JMS message destination here, as all JBoss ESB internal communication is based on JMS?
3. The CBR has to parse the message (hopefully stream-based so that only the header will get parsed if the X-Path expression only asks for a field of the header) and route the message to the defined destination. Of course this might include a (cached) service lookup in the registry beforehand. So here would come the HttpClient into play.

Maybe this is completely nonesense, but I didn't get it from reading the documentation. Especially the http-Listener and enqueing part is quite nebulous to me. Please shed some light on this!

Thanks a lot!

Regards,
Eric

[tfennelly]

Eric...

"eric.hubert" wrote:
1. The SOAP message has to be received by some kind of HTTP-Listener

The SOAP message can be received over any protocol supported by the ESB i.e. JMS, FTP, HTTP etc

"eric.hubert" wrote:
2. The message has to be converted to some kind of JBoss ESB native message format, as CBR and other services are only be able to work on that. Right? So am I forced to use a JMS message destination here, as all JBoss ESB internal communication is based on JMS?

This is handled for you by the gateways i.e. they normalise the message, allowing it to be consumed by action pipelines. What I'm saying here (and above) is that all the ESB related components for getting your SOAP message onto the ESB for processing by an action processing pipeline *should* be available right now.

"eric.hubert" wrote:
3. The CBR has to parse the message (hopefully stream-based so that only the header will get parsed if the X-Path expression only asks for a field of the header) and route the message to the defined destination. Of course this might include a (cached) service lookup in the registry beforehand. So here would come the HttpClient into play.

Not totally sure about the CBR. Actually, I think the current routing components might not work for message unaware endpoints. I think it uses the ServiceInvoker/MessageMulticaster. Up to this point, only message aware endpoints are being registered in the registry. I added a JIRA (ages ago) to enhance the reg to support annotated endpoint registration (e.g. "message-aware"/"message-unaware") + actual registration of the message unaware endpoints managed by the ESB (i.e. gateways).

Sorry about not being able to offer you and out of the box solution to this. Hopefully we'll get to improve WS support (and more) in future releases.

[kdunki]

I have excat the same problem and I don't know how to solve it. It would be really helpful if someone could provide us with an example (jboss-esb.xml) or explain in detail how it could work.