WebService passthrough

[njorgens]

Hi,

I come from the BEA ALSB world and need a short introduction to how I would do a simple passthrough using WebServices.

I work in a contract first environment, so I have all the WSDLs and Schemas, and now I need to build a PoC of doing passthrough on the ESB.

MyCase is that I have a service A that needs to call service A' through the ESB, service A' is hosted on SoapUI at the moment.

How would I deploy this, it seems that I should be able to do with a fairly small deployment.

Later on I need to do Orchestration and Transformation, but right now we are just interested in the passthrough.

I've looked through the webservice_* QS's but they seem to focus a great deal on JMS, and this is a WebService only world I live in.

[tfennelly]

So you'd like to be able to do the following now:

 webservice_Client -> ESB[route] -> webservice_Endpoint

With a view to evolving this into something like:

 webservice_Client -> ESB[transform,route] -> webservice_Endpoint

Yeah?

JBossESB can currently do the first part (i.e. get the message into the ESB over HTTP and onto an action processing pipeline, from where it can be manipulated before routing), but I'm fairly sure it can't route the message off the bus via HTTP. As obvious a requirement as this may seem, it hasn't been implemented yet (AFAIK). I know it's been talked about a few times for sure. It actually wouldn't be too difficult to grow your own HTTP router action to do this. This could be extracted from the SOAPClient action (uses commons http-client).

As far as the transformation is concerned, that shouldn't be a problem for you as long as you don't use attachments. If you do, you'll need a stream reader for Smooks that can handle the attachments for you.

[njorgens]

OK, thanks for the clarification, I'll stop looking. I've currently implemented this in BEA ALSB (ESB), and have a Spring/Xfire generic solution for the same thing.

Furthermore I would need validation etc. in the JBoss ESB. I guess I will have to look at another Open Source alternative then, any pointers? (Mule, ServiceMix?).

The real strength would be to just import the WSDL files to the BUS. and the do the routing/transformations, with optional calls to other services.

Thanks,
NEKO

[marklittle]

Tom, is this what you're refering to?

[njorgens]

Probably, but really the routing inside the bus should not be done using Http, but rather a queue (maybe Jms) or something more reliable.
Actually my requirement is to route SOAP/HTTP consumers to SOAP/HTTP providers.
Hopefully this can be done at some point in JBossESB. I'm up for helping doing this work.
Currently we are using BEA ALSB, but the development experience really sucks!!! You can only use a Web point/click interface for both development and debugging.
Furthermore the support for scripting is not there, so there are no real reuse possibilities.
It has XQuery support for transformations though, which is extremely powerful, and would be nice to have built into JBossESB.
Furthermore Unit test support of Orchestrations/Compositions and Transformations.
As far as I've read so far JBossESB uses files you deploy to you server. Those files you can work with in i.e. eclipse and have SCM support.
Another feature lacking in BEA.
Should I create any JIRA's on any of this stuff?

[marklittle]

So you're after reliable routing as well? If so then JMS is the best option at the moment. From a purely WS-* perspective, obviouisly something around WS-RX would be better in the long term.

I'd create a few JIRAs if I were you. Seems like there are at least two issues here (including XQuery support, which maybe Smooks can already handle, but it's worth checking).

[tfennelly]

Tom, is <a href="http://jira.jboss.com/jira/browse/JBESB-287">this</a> what you're refering to?

I think that JIRA was just for the HTTP Gateway, which we now have via the JBossRemotingGatway.

What we're missing for Neko's requirements (from a routing perspective) is a HTTP based router for getting messages off the bus. I'm not talking about a Courier here, which is (at the moment) an internal routing component.

The SOAPClient has this basic functionality built into it using the HttpClientFactory, which basically provides a thin layer on top of Commons HttpClient. I don't think it would be a big deal to build a standalone HttpClient action which would also use the HttpClientFactory (and which SOAPClient could extend perhaps).

Re XQuery and Smooks, Smooks doesn't support this yet. If Neko has experience of using XQuery (I've only ever really played around with it) and is interested, I'd be happy to help add this functionality either to the ESB natively (as an XQueryAction), or via Smooks (if that makes more sense), or both.

[marklittle]

"tfennelly" wrote:

Tom, is <a href="http://jira.jboss.com/jira/browse/JBESB-287">this</a> what you're refering to?

I think that JIRA was just for the HTTP Gateway, which we now have via the JBossRemotingGatway.

I don't know either. It confuses me ;-)

What we're missing for Neko's requirements (from a routing perspective) is a HTTP based router for getting messages off the bus. I'm not talking about a Courier here, which is (at the moment) an internal routing component.

The <a href="http://wiki.jboss.org/wiki/Wiki.jsp?page=SOAPClient">SOAPClient</a> has this basic functionality built into it using the <a href="http://wiki.jboss.org/wiki/Wiki.jsp?page=HttpClientFactory">HttpClientFactory</a>, which basically provides a thin layer on top of Commons HttpClient. I don't think it would be a big deal to build a standalone HttpClient action which would also use the <a href="http://wiki.jboss.org/wiki/Wiki.jsp?page=HttpClientFactory">HttpClientFactory</a> (and which SOAPClient could extend perhaps).

JIRA is your friend ;-)

Re XQuery and Smooks, Smooks doesn't support this yet. If Neko has experience of using XQuery (I've only ever really played around with it) and is interested, I'd be happy to help add this functionality either to the ESB natively (as an XQueryAction), or via Smooks (if that makes more sense), or both.

JIRA is still your friend ;-)

[tfennelly]

JIRA is still your friend ;-)

With friends like JIRA, who needs enemies ;-)