[
https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622694#action_12622694
]
Assaf Arkin commented on ODE-364:
---------------------------------
"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. "
Deployment artifacts are there for a reason. If I accidentally use the same
service in two places, that should be flagged as an error and stop deployment,
not result in a hard to diagnose bug. Pub/sub is not the common case, it
should be specified explicitly in deployment not applied implicitly as a result
of something that might be an error.
"Ideally, the design-time tooling should take care to prevent pub-sub across
any services whose operations are not one-way."
If it's a bad idea (and it is), the engine must prevent it from happening by
issuing an error. If used, a design-time tool should issue a warning earlier
in the lifecycle of the process definition.
> 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.
