Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.2
-
None
-
Platform-Independent
Description
By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
In general, there are two paths that need to be considered:
a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
