[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 96 - Proposal For Vote
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]