Hi Bernd. We've had a few people (not many) ask about this in the past. Yes it could be supported, but the whole philosophy behind ESB is SOA which is about loose coupling. The synchronous request-response pattern that we are used to in other areas is not the default one that we would encourage. There are quite a few papers and articles on the Web about how and why one-way interactions are more appropriate. In that situation, a single global transaction does not work and something like JMS transacted sessions, or compensation transactions (e.g., WS-BA) is better. However, there are still some cases where a single transaction that encapsulates the sending of the request and all work done by that request (including possible any other onward calls the initial receiver may make) is needed. It's just not something that we support at the moment. But I'm sure it will come eventually (e.g., through the eventually support of WS-AT or JTS).
If you want to use deliverySync, and are not in a position to rearchitect the request using async messaging (see http://www.jboss.org/community/docs/DOC-9105 for an example), then the best solution is to execute the deliverSync within a method using @NotSupported.
I agree 100% with you, synchronous delivery shouldn't be the default paradigm in a SOA world. And I think everybody starting with the ESB should read at least some of the literature you mentioned (I like especially Gregor Hohpes articles and interviews on that).
But at some layer close to the client you often try to hide the asynchronism if possible (e.g. the UI should display some result if possible synchronously). In our app we face this requirement but since we do not expose the ServiceInvoker to the client, the client accesses a SLSB instead as entry point. And it will behave synchronously if we get an answer within the timeout period, otherwise the client will get a "try to fetch result later on"...
I agree, that people should not be motivated to use synchronism in a SOA, but it would be nice to have it supported better out-of-the-box...
Anyway, for the moment it seems I have to implement the code around the ServiceInvoker myself :-/. But at least I can post the code for other people facing this requirement later...
Hi Bernd. Couldn't you just use two correlated one-way requests instead of deliverSync?
You mean I have one SLSB with two methods:
And the client has to call both in order?
Ideed, thats maybe not such a bad idea... I will think about it when I come back to it (currently I am stuck on other problems ;-))...
OK, let me know how it goes :-)
I had a look into it again today. I have a problem of correlation now: After delivering asynchronously I have nothing, not even some ESB UUID. So how to wait for exactly this result message in a generic easy way?
The second problem: If I solve the correlation by some business identifier I still have to wait for the response of the service, but there is no way on the ServiceInvoker to do something like:
serviceInvoker.waitForResponse(categoryName, serviceName, timeout) // or with correlation UUID serviceInvoker.waitForResponse(categoryName, serviceName, uuid, timeout) // or at least serviceInvoker.getResponseCourier(categoryName, serviceName) // or the like
Otherwise I cannot do that in a generic way because I need to subscribe to JMS for example (but then I have to know the special queue name and I am bound to JMS).
What do you think? Or am I on the wrong path?
Cheers & Thanks
Hi Bernd. In this case you need an endpoint in the client that allows the service to call back to it when the work is done (the service then becomes a client and the client then becomes a service).
When the client does a send of the original work, I'd expect it to set the MessageID in the outgoing message. When the service sends back a response eventually, it sets the RelatesTo field in the response message and the client can use that to correlate the response with the original request.