RE: [wsbpel] policy annotations and BPEL (was RE: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set)

["Edwin Khodabakchian" <edwink@collaxa.com>]

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