[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, 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? 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. 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. Satish -----Original Message----- From: Assaf Arkin [mailto:arkin@intalio.com] Sent: Wednesday, September 24, 2003 6:46 PM To: Ron Ten-Hove Cc: Francisco Curbera; wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] Issue - 66 - Zero or multiple matches of correlation set 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 > 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/leave_workgr oup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]