Re: [wsbpel] Issue 96 - Proposal For Vote

[Francisco Curbera <curbera@us.ibm.com>]

I would not characterize the current situation as saying that BPEL assumes
that the process author must manage the correlation between requests and
replies. It is more accurate to say that in addition to already existing
binding level correlation mechanisms BPEL introduces the possibility of
correlating sets of messages (not only request/reply patterns) using
business data. This is in line with BPEL's focus on the business layer and
is not exclusive of the use of protocol level correlation at the request
reply level - both methods can (and in fact do) coexist because they live
at different levels of abstraction.

So I think the perspective taken in this proposal confuses this
distinction. I understand that a deployed process can take advantage of
binding layer correlation mechanisms, so I would be ok, for example,
introducing a "hint to deployment" marker (in partner links?) to indicate
the fact that a process has a dependency on protocol binding providing this
kind of support. I am not very comfortable with raising those protocol
artifacts up to the level of business relevant correlation because they are
just different mechanisms with different goals. Even if at times we
shortcut layers of abstraction, that does not mean that the abstractions
are not relevant or need to be smashed together.

Paco




                                                                                                                                        
                      "Yaron Y. Goland"                                                                                                 
                      <ygoland@bea.com>        To:       wsbpeltc <wsbpel@lists.oasis-open.org>                                         
                                               cc:                                                                                      
                      03/10/2005 04:30         Subject:  [wsbpel] Issue 96 - Proposal For Vote                                          
                      PM                                                                                                                
                      Please respond to                                                                                                 
                      ygoland                                                                                                           
                                                                                                                                        




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