ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karthick Sankarachary (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (ODE-412) Publish/Subscribe Across Instances
Date Thu, 06 Nov 2008 19:42:46 GMT

     [ https://issues.apache.org/jira/browse/ODE-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Karthick Sankarachary reassigned ODE-412:

    Assignee: Karthick Sankarachary

>  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
>            Assignee: Karthick Sankarachary
>             Fix For: 2.0
>   Original Estimate: 168h
>  Remaining Estimate: 168h
> 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.

View raw message