OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue 96 - Proposal For Vote


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