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