[
https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622714#action_12622714
]
Karthick Sankarachary commented on ODE-364:
-------------------------------------------
To answer Alex's comments:
1) There was a proposal to add a boolean annotation in the provisioned service
listed in the deployment descriptor (specifically,
deploy/provide/service/shareable) that would indicate whether or not the
endpoint was actually designed for pub-sub semantic. However, I did not get an
overwhelming thumbs up for that idea, so it was dropped. I was hoping to enable
endpoint sharing if and only if the "shareable" element on the corresponding
service is true. Currently, that (hypothetical) attribute is treated as always
being set to true.
2) I was assuming that the design-time tooling would ensure that
request-response operations are not enabled for pub-sub. However, come to think
of it, the engine could very well perform that validation at run-time by
introspecting the service (that is about to be shared), and automatically
disabling endpoint sharing if even one operation in that service is
request-response. Having said that, there might be a use-case where using
pub-sub in the context of request-response operations makes sense, particularly
if the consumer (requestor) doesn't necessarily care which process provides the
response, as long as it gets one (think of it as a distributed OR-Join workflow
pattern.) In fact, I suspect that's why I probably wanted to handle
request-response gracefully to begin with. In light of that, I suggest
extending the "shareable" annotation with a boolean attribute (specifically,
deploy/provide/service/shareable/@oneway), which by default would be true, to
indicate whether or not to ensure if all operations are one-way. If its false,
then the reply sent back to the consumer will be that of one of the subscribing
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.
