[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]