One more comment on the behavior of these JMS channel classes. We have found it useful to adopt a standard service name-->queue or service name --> topic convention and these channel classes use service name to destination class to implement that by default. This practice, in combination with ActiveMQ's delightful capability to auto create a queue or topic on demand, gives us a very simple way to manage this mapping without a lot of configuration overhead.
However, since the actual classes in contact with JMS are the JmsTemplate class, and since those classes are injected via Spring you can always override this behavior by specifying your own destinations independent of that in the Spring config file. The drawback of that approach is that when you have dozens of services you have to configure senders and receivers for them individually. Hence the value of a naming mapping convention. On the consumer/server side I broke the link the XFire JMS transport had with associating the endpoint with the way the service was registered and instead associate the service registration name with the named listener on the listener that is configured on the JCA inbound connector. That way you do not need the destination URL on the client outbound transport to have the literal name of the service embedded, which is I more in the spirit of how endpoints in the WSDL should be used. --Keith -----Original Message----- From: Sam Wilson [mailto:[EMAIL PROTECTED] Sent: Friday, April 13, 2007 9:51 AM To: [EMAIL PROTECTED] Subject: Re: [xfire-user] FW: problems with using JMSTransport and JAXB Keith, That sounds very similar to what I had put together, though perhaps a little more robust on the sending side. Perhaps your code would make a better contribution than mine at this point. Sam Willard, Keith wrote: > > Sam, > > While I have not figured why the provided JMSTransport classes in > XFire do not work in my hands with more complex examples besides the > provided Echo example (namely they blow up in parsing the returned xml > after the channel has passed the InMessage back into the framework) I > have written an alternative set of JMS transport/channel classes > (separate for producer and consumer) that appears to work around the > problem. > > In addition to working, these classes have the advantage of using > Jencks for connection/session pooling and the Spring JmsTemplate > classes on the producer (generally client) side and the > Jencks/ActiveMQ JCA container framework (as well as the Spring > JmsTemplate classes) on the consumer (generally server) side to do the > actual JMS sending and receiving work. So they don't do much > themselves except interact with the XFire world but the channel gets > the benefit of an efficient pooled leak free JMS resource world. We > have used this combination of Jencks/Spring JmsTemplate before and > like it a lot better than working with the jms api's directly. > > These channel classes presently support three message exchange > patterns, a synchronous request/reply pattern using JMS queues, one > way queue messaging and one way topic messaging. > > For the request reply pattern (that was most problematic with the > existing JMSTransport classes) the biggest change I made was to follow > the existing http client channel as an example (which worked with the > JAXB services) and block in the channel's > > send(MessageContext context, OutMessage message)method to receive the > response rather than having the client have a second thread and use an > onMessage() method to capture the return result. It does continue to > use the idea of a named response queue rather than temp queues. > > In doing this I was following the approach taken by the XFire client > http channel (which workedJ). > > Just changing things so the client response work was using the same > thread as the send was enough to cause the client side parsing > problems I was seeing to disappear. > > --Keith > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
