Re: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

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