Publising a SOAP message to a set of interested BPEL processes
--------------------------------------------------------------
Key: ODE-364
URL: https://issues.apache.org/jira/browse/ODE-364
Project: ODE
Issue Type: New Feature
Components: BPEL Runtime
Affects Versions: 1.2
Environment: Platform-Independent
Reporter: Karthick Sankarachary
Fix For: 1.2
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 speaks as to how to implement 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 were two paths that need to be considered:
a) Out-Of-Process invocation of the shared service: This follows the path
defined 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 defined
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
deregisters 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
