[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 96 - Opaque Correlation Sets
>Furniss: Aren't there also cases where the BPEL process requires that the >communication be via a correlating protocol, but doesn't mind which one >? The requirement from the process is just that the communication be >"connection-oriented" at application level - the application is not >going to use its own data values to discriminate, and isn't interested >in what the underlying protocol uses, so long as the conversations can >be distinguished. Which underlying protocol is actually used is deferred >to the binding. > >Or is this out in abstractional hyper-space ? > When we move outside of WSDL- and Schema-described XML messages, don't we lose some control? Doesn't this opacity bring risk with it? What other issues have we not identified (plus allowing use of proprietary specifications)? >>Leyman: Yaron, >> >>there are scenarios in which the author of a process doesn't >>know whether partners of the process want to use opaque or >>transparent correlation sets. I.e. we should consider to >>support the specification of both kinds of correlation >>mechanism for a given activity, and then would have to define >>"overwriting rules" in case both kinds of correlation tokens >>do appear in a given interaction. >> >> >>Issue - 96 - Opaque Correlation Sets >>Status: open >>Date added: 3 Feb 2004 >>Submitter: Yaron Goland >>Date submitted: 03 February 2004 >>Document: Spec - Main >>Description: When a BPEL programmer wants to use correlation >>they define a correlation set which consists of a series of >>properties. The BPEL programmer then makes sure that when >>initializing a correlation set the message being used for >>initialization has the proper values, IDs, etc., inside of >>it. This is a powerful generic feature that allows BPEL to >>work with a wide variety of correlation mechanisms. However, >>protocols are now being introduced to explicitly manage >>message correlation, for example, ws-addressing. One of the >>benefits of such protocols is that they free the programmer >>from having to worry about the details of correlation set >>definition and value creation. Therefore it would be >>extremely useful if BPEL, in addition to its existing >>correlation set mechanism, introduced the ability to define >>an 'opaque' correlation set. That is, a correlation set whose >>definition and associated message values are managed by the >>BPEL engine. An opaque correlation set would only define what >>protocol it is based on and leave the other details to the BPEL >> >> >engine. E.g. <correlationSet > name="myCor" algorithm=" >http://somestandards.org/astandard/mechanism"/> >Changes: 3 Feb 2004 - new issue > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]