By default Java CAPS uses the Java Message Service infrastructure as its underlying messaging layer. Occasionally there is a requirement or a temptation to develop synchronous service, for example invoked as web services or as HTTP Request/Response services, that invoke some back-end component over JMS. In request/response scenarios the response must be delivered by the component which received the request, a JCD or a BP. If the request is passed to the nback-end infrastructure through a JMS Queue or Topic there arises an issue of getting the response back to the same instance of the JCD or a BP that sent the original request. The attached extract, JMS RequestReply, from an early draft of the “Java CAPS Basics – Implementing Common EAI Patterns“, discusses and illustrates how the JMS RequestReply() method of the JMS OTD can be used to implement this kind of functionality.
blogs.czapski.id.au
Articles on gtkdialog and demo image building. Formerly on JavaCAPS and SOA Suite for healthcare integration.
This blog used to have technical material on different topics relating to Sun Java CAPS, OpenESB and SOA Suite for healthcare integration.
New posts are not going to be related to either of these. Of late the technical topics relate to building Linux-based infrastructure demo images.
What the future holds - who knows ...
Hello Michael,
Good example of how to implement the JMS Request Reply mechanism. We have also used this in our current project, but we are now running into some issues. By using the requestReply method, a temporarly queue is being setup. according to the description this queue will only exists if as long as its creator exists, the java-collaboration instance. But in our situation now we are facing a problem that the number of temp.queues in the JMS IQ Manger is increasing. We discovered this behaviour when performing some load-tests.
Does this sounds familiar to you, and is there a solution?
thusfur we tried to change some configuration (number of connections to JMS etc.) and setting the queues non-persistent
JMSClient.setDeliveryMode( jmsRequest.NONPERSISTENT );
But did doesn’t seems to help, resolving the problem with increasing number of queues on the IQ Manager.
Hope you can help?
Simon