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

[Assaf Arkin <arkin@intalio.com>]

I would also like to see a separation of concern between the process 
definition and the QoS requirements of the service and wouldn't rule out 
using existing mechanisms, e.g, the WSDL 1.2 features & properties 
framework.

arkin

Ron Ten-Hove wrote:

> Francisco Curbera wrote (in part):
>
>>I agree with the scenario in which certain "policies" are required by a
>>process model. It is no clear to me, though, that we should define a BPEL
>>native mechanism to deal with it. I'd rather prefer to see a good
>>separation of concerns in which BPEL focuses on the business logic and
>>another "composable" spec provides a general purpose mechanism to attach
>>QoS requirements to processes, interfaces etc. WS-Policy is an example of
>>that spec. 
>>
>    The choice of  WS-Policy is an unfortunate one, however. It is a 
> proprietary spec, and the licensing terms ban implementations (you are 
> only permitted to read and copy the spec.) Thus we must omit WS-Policy 
> from consideration.
>
>    Rather than latching onto a likely looking spec (encumbered or not) 
> to completely separate the concerns, can't we try to find a neutral 
> way to express such QoS requirements in a business process model? Our 
> needs are modest, and certainly don't need the full weight of the 
> WS-Policy framework or CPP/A. Why become coupled to a particular 
> specification if we can avoid it?
>
>    A good example of this "neutural" approach is BPSS. It expresses 
> the messaging QoS needs of a collaborative business process in 
> high-level business terms. It has a few simple attributes for its 
> Document and Envelope types that align well with ebMS and CPP/A QoS 
> concepts, but doesn't require that the other ebXML specs be used. By 
> using high-level, business-oriented requirements to declare /what /QoS 
> properties are needed, BPSS avoids that trap of needing to specify 
> /how /such needs are to be met.
>
> -Ron
>