[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 96 - Proposal For Vote
Hi Yaron,
What is a "relationship" IRI?
Paco
"Yaron Y. Goland"
<ygoland@bea.com> To: Danny van der Rijn <dannyv@tibco.com>
cc: wsbpeltc <wsbpel@lists.oasis-open.org>
03/21/2005 01:22 Subject: Re: [wsbpel] Issue 96 - Proposal For Vote
PM
Please respond to
ygoland
Imagine I'm using WS-Addressing (which we now all love since it is a W3C
WG). I have a partnerLink and it is being used to manage two different
conversations. Each conversation has its own relationship IRI. Since
only one partnerLink is involved there is no way for the engine to know
the programmer's intention when sending or receiving a message on that
partnerLink. Which conversation (e.g. relationship) does the programmer
intend to make the message a part of?
This is where opaque correlations come in. They act as a 'handle' to
point at the appropriate relationship value and so let the engine knows
which conversation the message is expected to be a part of.
Yaron
Danny van der Rijn wrote:
> 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
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
---------------------------------------------------------------------
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]