[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] policy annotations and BPEL (was RE: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set)
Fair enough. - Edwin > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: Tuesday, September 30, 2003 6:54 AM > To: edwink@collaxa.com; wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] policy annotations and BPEL (was RE: > [wsbpel] Issue - 66 - Zero or multiple matches of correlation set) > > Edwin, > > What you are suggesting is equivalent to the WSDL approach of > using encoding URIs which are opaque. But in our case invoke > will work against an annotated WSDL definition which will use > different policy annotation mechanisms. So we now have to > not only understand the opaque URIs but also map them to > other annotation styles. Too much complexity IMHO. > > Satish > > > -----Original Message----- > From: Edwin Khodabakchian [mailto:edwink@collaxa.com] > Sent: Monday, September 29, 2003 11:54 AM > To: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] policy annotations and BPEL (was RE: > [wsbpel] Issue - 66 - Zero or multiple matches of correlation set) > > Frank, Satish, Ron, > > I am not sure I understand the details of this discussion but > I would like to suggest an option for addressing this requirement. > > We could copy what HTML and introduce the notion of process > STYLESHEETS as an extensible mechanism for annotating and > customizing the behavior of BPEL > activity: > > <invoke ... class="MyClassName" /> > Or > <invoke ... style="someName1:someValue1;...;someNameN:someValueN" /> > > We could provide the styling mechanism but not define in the > initial version any of the names and values. As some of the > specs around BPEL mature, we can then bridge the gap by > defining specific name and values. > > In general, I very much agree with Satish and Frank: it is > much better to under spec than over spec. This is just a > "1.0". If we are successful they will be many more versions. > > Edwin > > > -----Original Message----- > > From: Frank Leymann [mailto:LEY1@de.ibm.com] > > Sent: Sunday, September 28, 2003 2:02 AM > > To: wsbpel@lists.oasis-open.org > > Subject: Re: [wsbpel] policy annotations and BPEL (was RE: > > [wsbpel] Issue - 66 - Zero or multiple matches of correlation set) > > > > > > My position is close to Satish's. > > > > I have no doubts, there is the need for generic mechanisms for > > creating policies (e.g. QoS, business properties), > annotating "service > > artifacts" > > with policies as well as specifying domain specific policies > > (transaction, security, payment,...). But the former is > clearly out of > > the sope of our TC's work; once such generic creation and > annotation > > mechansims are chosen by the TC we might consider to > identify business > > process specific policies, but from my perspective this is > something > > we should not depend on for creating a first release of BPEL. > > > > A general purpose policy model is very much preferable for > the reasons > > Satish mentioned. Inventing creation and annotation mechanisms for > > policies within the BPEL TC doesn't seem to be the right way to me. > > > > Regards, > > Frank > > > > > > > > > > > > > > > > To: "Ron Ten-Hove" <Ronald.Ten-Hove@Sun.COM> > > cc: <wsbpel@lists.oasis-open.org> > > Subject: [wsbpel] policy annotations and BPEL (was RE: > > [wsbpel] Issue - > > 66 - Zero or multiple matches of correlation set) > > > > > > Ron, > > > > > > > > Clearly, the disagreement is not about the need for QoS and other > > policy annotation. There are two separate issues we are > talking about. > > > > > > > > A. Does such annotation belong within BPEL? > > B. Whether it does or not, how should it be expressed? > > > > > > > > The following are my personal opinions. I won't qualify them > > as such at every step. > > > > > > > > I believe such annotation is not within the scope of the TC's > > work. BPEL is not attempting to provide a complete business > > process modeling solution. > > What it is attempting to standardize is the description of > > long-running patterns of service-level messaging interactions > > both for multi-party business protocol definition and > > multi-service composition. If we attempt to go beyond this, > > we will either do an incomplete and half-baked job of policy > > annotation or we will not finish for a very long time. > > > > > > > > Regardless of this, we have two options for expressing > > annotations. Use BPEL's extensibility mechanisms and express > > them as BPEL extensions. Or follow a separate policy > > annotation model that is used not only in the context of BPEL > > but in most other contexts. Let us take the example of > > security annotations for messaging interactions. We may > > sometimes need to annotate a specific receive action in a > > BPEL process, sometimes an input action within a WSDL > > operation, or sometimes an entire WSDL portType. The > > annotation may be essentially the same: e.g., message(s) must > > be signed. > > If we have BPEL specific extensions for this and WSDL has > > WSDL specific extensions for the same sort of annotation, we > > now have two ways of saying the same thing, which will > > inevitably start diverging at least in subtle ways simply > > because there are many ways to express this sort of > > constraint and reasonable groups of people will come up with > > different styles of annotation which are not isomorphic. > > > > > > > > This is why I favor the idea of a separate policy annotation > > model that is used not only in the context of BPEL but in > > most other contexts. We then have a chance to provide > > uniform annotation at all the levels we need to, without > > having to anticipate every combination of possibilities. > > Yes, WS-Policy is such a model but the point I am making is > > that we need something of that sort. I am not asking us to > > take a dependency on WS-Policy specifically. > > > > > > > > Satish > > > > > > ________________________________ > > > > From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] > > Sent: Fri 9/26/2003 1:03 PM > > To: Satish Thatte > > Cc: wsbpel@lists.oasis-open.org > > Subject: Re: [wsbpel] Issue - 66 - Zero or multiple matches > > of correlation set > > > > > > > > Satish Thatte wrote: > > > > >Ron, > > > > > >Would it not be unfortunate for the real people building > > real systems > > >with web services standards if they had to learn 5 > different ways to > > >express QoS and other policy assertions regarding service > > interfaces, > > >just because 5 standards committees found it convenient to avoid a > > >dependency on anything outside their control? > > > > > Do you have a proposal for such a dependency? > > > > It would be even more unfortunate if those real people > > had to build real systems using a standard that was > > completely silent on important issues like QoS from a process > > perspective. This just makes the situation worse -- > > vendor-specific extensions, pseudo-standards, etc. It is an > > invitation to Balkanize the BPEL implementation landscape. > > This is not what OASIS wants from us, wouldn't you agree? > > > > A few simple, business-level assertions about QoS that > > are supported by the standard will serve to reduce (but, as > > you observe, not > > eliminate) this source of incompatibility. (The effort to > > fully address such an issue would rapidly run into > > diminishing returns; I am not advocating that we walk such a > > path! I think the TC has a (rightly) well developed allergy > > to scope enlargement.) > > > > Further, the approach for loosely coupling specifications > > has been used successfully by OASIS in the past. Is is more a > > question of alignment than dependency avoidance. > > > > >The other alternative of > > >using "metamodels" that need mappings and bindings to actual > > >realizations is a level of complexity that I also think it > would be > > >best to avoid. > > > > > In general, I agree. However, I would add that (meta-) > > models based on business processing modelling domain concepts > > should not be so excluded, precisely because this is the > > domain the TC is working in. > > > > >I believe we should focus only on our core concerns which > have to do > > >with process models. We all recognize that these models > > don't live in > > >a vacuum and will have to work well with WSDL, WS-Security, and > > >whatever other specifications in the areas of reliability, > > transactions > > >and coordination, policy, etc., that people end up using. I > > would much > > >rather defer the solution than create a burden of legacy > that people > > >would have to deal with for a long time to come. > > > > > We have conflicting requirements here. One is to make > > BPEL an expressive process modelling language; the other to > > make it a simple execution language. Business level QoS > > concerns are doubtless important for the former BPEL > > requirement, but undesirable from the latter. We have had, in > > the past, rather vigorous support for promoting BPEL as a > > modelling language; do you disagree with the notion of BPEL > > as an expressive BP modelling language? > > > > Our legacy will also include the things we refuse to > > address, which may result in diminished utility, > > interoperability or portability: all things that will reduce > > the value of this specification. Sins of omission have as > > many consequences as those of commission :-) > > > > -Ron > > > > > > > > > > > > To unsubscribe from this mailing list (and be removed from > > the roster of the OASIS TC), go to > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le > ave_workgroup.php > > . > > > > > > > > > > > > > > > > To unsubscribe from this mailing list (and be removed from > > the roster of the OASIS TC), go to > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le > ave_workgroup.php. > > > > > > > To unsubscribe from this mailing list (and be removed from > the roster of > the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le > ave_workgr > oup.php. > > > > > To unsubscribe from this mailing list (and be removed from > the roster of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le ave_workgroup.php. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]