I have a few questions about SOAP over JMS implementation in CXF and applicability to high volume applications.
my requirements are * wdsl-first approach. (See no problems with CXF) * it should be simple JMS transport wrapper over existing web service. As I understand CXF's SOAP over JMS implementation addresses this perfectly. I can afford extra port and binding. * It should allow for transactional request processing. - e.g. runtime exception in service itself shoulf cause message redelivery, but legitimate faults will be sent to reply destination. I did not get to this part yet, but I assume this should be possible with JMS transport. and for client: * send requests in transactional fashion - e.g. runtime exception later in the same transaction should roll back sent message. * process response in transactional fashion - e.g. runtime exception in response handler will cause response message redelivery * provide simple async API for client - allow working with same POJOs application would work in synchronous request/response case. * scale - application will be sending ~200K messages a day and thus will receive same number of responses. Both service and client will be clustered. * allow for significant response time - due to heavy and spiky load it may sometimes take hours for service to respond. It is a batch process, so client is ok to wait. - But it has to process response eventually. Application cant afford dropping reponses. Specifics of my task is that response is self-contained and can be processed with no knowledge of request. I.e. no need to correlate messages. I also know that data binding will be JAXB. ********** Before I realized there is a way to generate async interface, my plan (and 3/4 of implementation) went like this: I extended JMSConduit with implementation that overrides sendExchange(), so that all exchanges processed as one-way ones. One difference is that pre-configured reply destination still added to the outbound message. I also extended JaxWsClientProxy and overrode invoke() implementation so that it always calls invokeAsync(). Both pieces contain enough of code copied from original classes, so it does not look terribly clean. For response processing I created listener that takes original CXF client and extracts JAXB context (endpoint -> service -> dataBinding -> context). When message arrives it applies xpath to extract "/soap:Envelope/soap:Body/*", deserializes results with JAXB context, and then calls actual biz logic with resulting element. ****** While it all works and provides simple API so far, I was wondering if there is a better way. And I found out async bindings possible (sorry, I'm new to JAX-WS binding). Now, I'm seriously considering dropping all my efforts in favour of standard async binding, but a few things still bother me. Could someone please clarify on these questions for me. * How do async bindings with JMS scale? I.e. in my mind lots of messages with response time in minutes or perhaps even hours leads to numerous listeners with numerous selectors. Also to large correlation map. * How reliable async binding is for high load/slow response case? E.g. if client goes down, correlation map is lost, so are all responses. Or did I miss the way to recover after that? * Does it work for static response queues? E.g. http://cwiki.apache.org/CXF20DOC/jms-transport.html states that "static reply queue can not be shared by several instances of the service client", but it is unclear if the issue is still relevant. * What is a degree of transaction support? I.e. is it possible to roll back message sent in a shared transaction, or expect redelivery on processing? Also if anyone already has experience with CXF/SOAP/JMS deployment and could share, that would be really great. Thanks! Pavel
