Publish/Subscribe Across Instances
-----------------------------------
Key: ODE-412
URL: https://issues.apache.org/jira/browse/ODE-412
Project: ODE
Issue Type: New Feature
Components: BPEL Compilation/Parsing, BPEL Runtime
Affects Versions: 1.2
Environment: platform-independent
Reporter: Karthick Sankarachary
Fix For: 2.0
By default, WS-BPEL processes exchange messages with each other and external
services in a point-to-point manner. To be precise, when a message is sent to a
certain process endpoint, it is routed to at most one (matching) instance of
that process. In reality, when a process contains an intermediate receive
activity that does not use correlation sets, chances are that more than one
instance might be waiting on that particular receive at any given point in
time. Even if correlation sets are used, there's an off chance that there might
exist more than one process instance with the same correlation value.
The above constraint makes it hard, if not impossible, to support use cases
where you want a message to be broadcast, if you will, to an arbitrary number
of (matching) instances. It would be nice to be able to use messages as signals
that are sent to all process instances (a la BPMN). To that end, we introduce a
"route" attribute in all inbound message activities defined by WS-BPEL as shown
below:
<receive route="any|all".../>
<onEvent route="any|all".../>
<onMessage route="any|all".../>
Formally, the route attribute is defined as shown below, such that it has a
default value of "any", which enforces the default behavior (i.e.,
point-to-point exchanges). To enable publish-subscribe exchanges, you will
simply need to set its value to "all".
<xsd:attribute name="route" use="optional" default="any">
<xsd:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="all"/>
<xs:enumeration value="any"/>
</xs:restriction>
</xsd:simpleType>
</xsd:attribute>
When the route attribute is set to "all" on an intermediate receive activity,
inbound messages are broadcast to all instances, regardless of whether they
originated from a process or an external service. While we don't disallow the
use of the route attribute in start receive activities, it has no effect on the
default behavior (which is to create a new instance).
In addition to the route attribute, it would be nice to have a mechanism to
filter messages that match a receive activity, especially if broadcast is
turned on. However, the syntax of that mechanism is yet to be determined and
out of scope for now.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
