The JMS Adapter is unaware of who receives the messages. Each adapter instance just takes the message from the queue and delivers it to its own configured interface, one interface per adapter instance. The SOA infrastructure is then responsible for routing that message, usually via a database table and an in memory notification message, to a component within a composite. Each message will create a new composite but the BPEL engine and Mediator engine will attempt to match callback messages to the appropriate Mediator or BPEL instance.
Note that message type, including XML document type, has nothing to do with the preceding statements.
The net result is that if you have a sequence of two receives from the same queue using different adapters then the messages will be split equally between the two adapters, meaning that half the time the wrong adapter will receive the message. This blog entry looks at how to resolve this issue.
Note that the same problem occurs whenever you have more than 1 adapter listening to the same queue, whether they are in the same composite or different composites. The solution in this blog entry is also relevant to this use case.
When using a synchronous Request-Reply JMS adapter we can omit to specify the message selector because the Request-Reply JMS adapter will immediately do a listen with a message selector for the correlation ID rather than processing the incoming message asynchronously.
The synchronous request-reply will block the BPEL process thread and hold open the BPEL transaction until a response is received, so this should only be used when you expect the request to be completed in a few seconds.
The JCA Connection Factory used must point to a non-XA JMS Connection Factory and must have the isTransacted property set to “false”. See the documentation for more details.
I developed a JDeveloper SOA project that demonstrates using a single queue for multiple incoming adapters. The overall process flow is shown in the picture below. The BPEL process on the left receives messages from the jms/TestQueue2 and sends messages to the jms/Test Queue1. A Mediator is used to simulate multiple services and also provide a web interface to initiate the process. The correct adapter is identified by using JMS message properties and a selector.
The flow above shows that the process is initiated from EM using a web service binding on mediator. The mediator, acting as a client, posts the request to the inbound queue with a JMSType property set to "Initiate".
Model | Client | BPEL | Service | |
---|---|---|---|---|
Inbound Request | Client receives web service request and posts the request to the inbound queue with JMSType='Initiate' | The JMS adapter with a message selector "JMSType='Initiate'" receives the message and causes a composite to be created. The composite in turn causes the BPEL process to start executing. The BPEL process then sends a request to Service 1 on the outbound queue. Key Points
| Service 1 receives the request and sends a response on the inbound queue with JMSType='Service1' and JMSCorrelationID= incoming JMS Message ID. | |
Separate Request and Reply Adapters | The JMS adapter with a message selector "JMSType='Service1'" receives the message and causes a composite to be created. The composite uses a correlation set to in turn deliver the message to BPEL which correlates it with the existing BPEL process. The BPEL process then sends a request to Service 2 on the outbound queue. Key Points
| Service 2 receives the request and sends a response on the inbound queue with JMSType='Service2' and JMSCorrelationID= incoming JMS Message ID. | ||
Asynchronous Request-Reply Adapter | The JMS adapter with a message selector "JMSType='Service2'" receives the message and causes a composite to be created. The composite in turn delivers the message to the existing BPEL process using native JMS correlation. Key Point
| The BPEL process then sends a request to Service 3 on the outbound queue using a synchronous request-reply. Service 3 receives the request and sends a response on the inbound queue with JMSType='Service2' and JMSCorrelationID= incoming JMS Message ID. | ||
Synchronous Request-Reply Adapter | The synchronous JMS adapter receives the response without a message selector and correlates it to the BPEL process using native JMS correlation and sends the overall response to the outbound queue. Key Points
| |||
Outbound Response | Client receives the response on an outbound queue. |
When using a single JMS queue for multiple purposes bear in mind the following:
The sample is available to download here and makes use of the following JMS resources:
JNDI | Resource; | Notes |
---|---|---|
jms/TestQueue | Queue | Outbound queue from the BPEL process |
jms/TestQueue2 | Queue | Inbound queue to the BPEL process |
eis/wls/TestQueue | JMS Adapter Connector Factory | This can point to an XA or non-XA JMS Connection Factory such as weblogic.jms.XAConnectionFactory |
eis/wls/TestQueue | None-XA JMS Adapter Connector Factory | This must point to a non-XA JMS Connection Factory such as weblogic.jms.ConnectionFactory and must have isTransacted set to “false” |
To run the sample then just use the test facility in the EM console or the soa-infra application.
Hi, Antony, recently I was reading your SOA 11g cookbook and I can't find the MDS file you mentioned in the chapter 2. You suggest in the book that checking out the 'apps' directory from SVN repository, but what's the location of the SVN repository? Since I can't find your email address through internet, so have to submit an inquiry here. If you may send me a letter, I will be very appreciated of your helpfulness.