Details
-
New Feature
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.2
-
None
-
platform-independent
Description
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.
