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