Sorry about the typos... Here is the corrected version below. =============================================== Hi,
I have used this pattern before in which a JMS Consumer/provider mediates between the CXF-BC and the backend services whose QOS is not good enough to outlast the HTTP timeouts (aka longer running transactions) in the CXF-BC. I have usually put an SMX Bean for loanger running transactions in between the CXF-BC and JMS Consumer to send back a stock message to the caller saying something like "your message is being processed, check back later" when the JMS Consumer sets a Done on the original exchange and the request has been persisted. I have also seen the problem of the Operation Name being lost, but I had seen it with the Routing Slip and not the SOAP based JMS Consumer acting as a pass through. In any case in order to circumvent this situation, I added an SMX Bean following the Routing Slip (in your case JMS-Provider) that pulled the top level element in the JBI-part of the provider created message exchange and used it to create dynamic request to the backing service using the fresh exchange(optional) with the operation name correctly set. (My scenario was in-out.). Obviously, I also had to deal with sync/async since XA transactions were involved. In your case, you can in the SMX-Bean get the exchange and set the operation name by hand and simply send it on its way. You will also need to set the synchronous=true in the JMS-Consumer. Hope this helps. Cheers, Ashwin... Ashwin Karpe wrote: > > Hi, > > I have used this pattern before which a JMS Consumer/provider in between > the CXF-BC and the backend services whose QOS is not good enough to > outlast the HTTP timeouts (aka longer running transactions) in the CXF-BC. > I have usually put a SMX Bean in beteen the CXF-BC and JMS COnsumer to > send back a stock message to the caller saying your message is being > processed when the JMS Consumer sets a Done on the original exchange. > > I have also seen the problem of the Operation Name being lost, but I had > seen it with the Routing Slip and not the JMS Consumer. In any case in > order to circumvent this situation, I added an SMX Bean following the > JMS-Provider that pulled the top level element in the JBI-part of the > provider created message exchange and use it to create dynamic request to > the backing service using the fresh exchange with the operation name > correctly set. (My scenario was in-out.). Obviously, I also had to deal > with sync/async since XA transactions were involved. > > In your case, then you can in the SMX-Bean get the exchange and set the > operation name by hand and simple send it on its way. You will also need > to set the synchronous=true in the JMS-Consumer. > > Hope this helps. > > Cheers, > > Ashwin... > > > Lukasz L. wrote: >> >> yeah, I didn't noticed that it's transacted, which is a good option for >> persistence, I'm not sure but probably you also need to add >> synchronous="true" on the consumer (because when it's asynchronous >> transaction ends after sending message not after received status DONE >> from CXF provider), >> >> but to better answer you question, can you say what do you want to >> achieve here? >> is that in-only invocation? if yes but you care if the invocation >> successful, maybe it's better to design target service to send >> confirmation, that is make it in-out? >> if you don't care if target service invocation was successful, then you >> probably don't need persistence on the bus (just CXF consumer - provider >> pair), probability that SM crashes during such invocation would be very >> low, >> >> >> jav1erp wrote: >>> >>> thank for your reply >>> >>> I've just tried to see how I can keep messages in case of smx crash. Any >>> idea? >>> >>> >>> >> >> > > ----- --- Ashwin Karpe, Principal Consultant, PS - Opensource Center of Competence Progress Software Corporation 14 Oak Park Drive Bedford, MA 01730 --- +1-972-304-9084 (Office) +1-972-971-1700 (Mobile) ---- Blog: http://opensourceknowledge.blogspot.com/ -- View this message in context: http://www.nabble.com/operation-name-is-null-after-jms-endpoints-tp21713138p21746231.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
