OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]