Please see section 3 of
http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-core.html#msgaddrprops
and IETF RFC 3987.
Thanks,
Yaron
Francisco Curbera wrote:
> Hi Yaron,
>
> What is a "relationship" IRI?
>
> Paco
>
>
>
>
>
>
> "Yaron Y.
> Goland"
>
>
> <> To: Danny van der Rijn
> <>
>
> cc: wsbpeltc
> <>
>
> 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:
> > > For additional commands, e-mail:
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
>
>
