On Thursday 30 September 2010 10:15:22 am Benson Margulies wrote: > I'm trying to perform a mental mapping from what I know about SOAP to > what I know about JMS. Which, in the later case, is not as much as it > might be. > > In a JMS-y sort of model, 'thing a' pushes a unit of work onto a > queue, and there are a school of (b) sharks looking for something to > do. > > One of them gets the unit of work and works on it. > > If the WebMethod is *not* OneWay, then presumably the (a) thing is > blocked waiting for one of the (b) things to respond?
Yep. It's a bit different on 2.3 than on <=2.2.x. In 2.3, we actually use the the spring call to jmsTemplate.receiveSelected to retrieve the response immediately in the conduit. With 2.2.x, it would unwind the stack and wait up in the client for a response to eventually arrive elsewhere. In either case, it's waiting. (providing you don't use the async API's) > And the response > travels back through some other JMS queue that (ahem) springs into > existence as part of the client proxy setup? Or does JMS have a > response channel as a basic mechanism? Or is @OneWay required for > pub/sub? We support a bunch of ways of handling this. I think the default is to create a temporary queue for the responses to travel on. However, we also support using a predefined and shared queue, but using a message selector to select off the message that is appropriate. It really depends on how your infrastructure is setup and what's easier for you to manage. > Does the JAX-WS asyncronous business with the Futures work with JMS > when there is some sort of reply? Yes. When it's not a sync call, the JMSListener will be setup and everything will unwind. As responses come in, they will get coorelated and the appropriate callback/future handled. You can have 1000 requests outstanding and just the thread or two for the JMSLIstener will be created. -- Daniel Kulp [email protected] http://dankulp.com/blog
