[
https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthick Sankarachary updated ODE-364:
--------------------------------------
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.
was:
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.
Summary: Publishing a SOAP message to a set of interested BPEL
processes (was: Publising a SOAP message to a set of interested BPEL processes)
> 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
>
> Attachments: patch.txt
>
> 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.
