[
https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthick Sankarachary updated ODE-364:
--------------------------------------
Attachment: (was: patch.txt)
> Publishing 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
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
