Issue 96 - Proposal For Vote

["Yaron Y. Goland" <ygoland@bea.com>]

Issue 96 - Engine-managed correlation sets

Proposal: Introduce an opaque form of correlation set which has a 
'conversationAlgorithm' attribute (used in place of properties) 
specified by a URI that identifies what correlation mechanism the 
correlation set is required to use. Also introduce a default URI value 
that says "figure it out at deployment".

Rationale: BPEL's current correlation design assumes that all 
correlation management beyond that needed for request/reply is manually 
managed by the programmer. For example, when a message is received that 
contains a useful bit of correlation data the programmer is expected to 
create a correlation set and use it on the receive/pick to pull out that 
data so it can be used for future correlation purposes. But there are 
conversation management algorithms which operate at the binding layer 
and so below the notice of the BPEL program. Opaque correlation sets are 
introduced in order to enable for the creation of BPEL's that make use 
of machine managed conversations.

Required Changes:

Section 10 -

From: The declarative specification of correlation relies on declarative 
properties of messages.

To: The declarative specification of correlation relies on declarative 
properties of messages or optionally the use of machine managed 
conversation mechanisms.

Add to the end of the previous paragraph: Machine managed conversations 
depend on correlation sets whose value are set by algorithms that are 
managed below the BPEL process itself. The values and nature of the 
conversation algorithms are therefore invisible to the BPEL process. 
When such algorithms are used the BPEL process needs a 'handle' to point 
to the machine managed correlation sets. This is why two types of 
correlation sets have been introduced. One that is based on properties 
and depends on explicit management by the BPEL process and another based 
on opaque algorithms where managing the correlation values is handled by 
the BPEL engine.

Section 10.1

Add the following to the end of the section:

In cases where the conversation is being managed below the BPEL process 
the BPEL process won't know what values are used to identify a 
conversation and so cannot define and manage the appropriate properties. 
This is why machine managed correlation sets have been introduced. The 
BPEL process only needs to define the existence of a machine managed 
correlation set and identify what conversation algorithm is expected to 
be used. No properties or other information is needed. Machine managed 
correlation sets behave identically to property based correlation sets 
in terms of initialization and referencing.

Section 10.2

From:
<correlationSets>?
	<correlationSet name="ncname" properties="qname-list"/>+
</correlationSets>

To:
<correlationSets>?
	<correlationSet name="ncname" properties="qname-list"? 
conversationAlgorithm="uri"?/>+
</correlationSets>

(Note: The previous BNF also needs to be changed in section 6.2)

When defining a correlation set either the properties or 
conversationAlgorithm MUST be used but not both. The 
conversationAlgorithm attribute, if used, specifies the name of the 
conversation management mechanism the BPEL process expects to be used to 
manage the conversation. A BPEL processor MUST statically check the 
value of the conversationAlgorithm attributes used in a submitted BPEL 
and MUST reject any BPEL's that contain a value that is not supported by 
the BPEL processor.

All BPEL processors MUST support conversationAlgorithm identified by the 
URI 
http://schemas.xmlsoap.org/ws/2005/03/business-process/lateBoundConversation. 
This URI specifies that the actual conversation algorithm to be used 
should be specified when the BPEL is deployed. The documentation element 
inside of the correlation set definition can be used to provide 
additional information about the expectations for what kind of 
conversation mechanism is expected to be used when the generic 
lateBoundConversation URI is used.

Other than the lack of properties, the behavior of a 
conversationAlgorithm correlation set is identical to a property based 
correlation set in terms of its life cycle.

New Schema:

     <complexType name="tCorrelationSet">
         <complexContent>
             <extension base="bpws:tExtensibleElements">
                 <attribute name="properties" use="optional">
                     <simpleType>
                         <list itemType="QName"/>
                     </simpleType>
                 </attribute>
                 <attribute name="name" type="NCName" use="required"/>
                 <attribute name="conversationAlgorithm" type="ANYURI" 
use="optional"/>
             </extension>
         </complexContent>
     </complexType>