OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue 96 - Proposal For Vote


Can you back up the following assertion?

> When such algorithms are used the BPEL process needs a 'handle' to 
> point to the machine managed correlation sets.


Danny

Yaron Y. Goland wrote:

> 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>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]