Hi Benson,
if you have several consumers and want only one to react then pub/sub (topics)
is not the right solution. In your case you simply use one queue that all
consumers listen on. In jms normally the jms server will send to the present
consumers using some round robin scheme (or other depending on jms server). In
any case the server makes sure only one consumer will get the message.
Then the consumer will do his work and send a reply back to the destination
named in the JMSReplyTo header. So where the reply goes depends on the sender.
The sender has to set up a reply queue and set it in the message.
Stacks like cxf and camel provide support for request response scenarios like
above. There are two common ways for the reply queue. You can use a fixed queue
or you can use a temporary queue. If you configure no reply queue in CXF then a
temporary queue will be used.
Another thing is the correlation of sent and received messages. This can hit
you if you talk with a non cxf stack but in CXF to CXF scenarios you do not
have to care about it.
A config like below should get you going for the client side. The server will
be configured similarly.
Best Regards
Christian
-----------------
<client id="service" xmlns="http://cxf.apache.org/jaxws";
serviceClass="the java interface for the service"
address="jms://">
<features>
<bean class="org.apache.cxf.transport.jms.JMSConfigFeature"
xmlns="http://www.springframework.org/schema/beans"; >
<property name="jmsConfig" ref="jmsConfig"/>
</bean>
<logging xmlns="http://cxf.apache.org/core"; />
</features>
</client>
<bean id="jmsConfig"
class="org.apache.cxf.transport.jms.JMSConfiguration"
p:autoResolveDestination="true"
p:connectionFactory-ref="jmsConnectionFactory"
p:targetDestination="testqueue" />
<bean id="jmsConnectionFactory"
class="com.tibco.tibjms.TibjmsConnectionFactory">
<property name="serverUrl" value="${jms.serverUrl}" />
<property name="userName" value="${jms.userName}" />
<property name="userPassword" value="${jms.userPassword}" />
<property name="reconnAttemptCount"
value="${jms.reconnAttemptCount}" />
<property name="reconnAttemptDelay"
value="${jms.reconnAttemptDelay}" />
</bean>
-------------------
Christian Schneider
Informationsverarbeitung
Business Solutions
Handel und Dispatching
Tel : +49-(0)721-63-15482
EnBW Systeme Infrastruktur Support GmbH
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim HRB 108550
Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
Geschäftsführer: Jochen Adenau, Hans-Günther Meier
-----Ursprüngliche Nachricht-----
Von: Benson Margulies [mailto:bimargul...@gmail.com]
Gesendet: Donnerstag, 30. September 2010 16:15
An: CXF Users
Betreff: JMS pub/sub, JAX-WS, async, and where are those replies going anyway?
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? 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?
Does the JAX-WS asyncronous business with the Futures work with JMS
when there is some sort of reply?
