[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set
Ron, I was evidently trying to focus on function, not individual specs (as Diane and Monica asked us to do), so I said WS-Policy "is an example". Referring to concrete examples usually improves the clarity of the argument. I certainly am not as fond of this kind of "spec wars" discussions as you seem to be. The point I am making is that by separating concerns we're better off. I don't think you are arguing with that point, just with my example. Good to see you also have your favorite examples. Paco Ron Ten-Hove <Ronald.Ten-Hove@ To: Francisco Curbera/Watson/IBM@IBMUS Sun.COM> cc: wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set 09/24/2003 06:31 PM 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]