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:
> For additional commands, e-mail:
>
>
