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] policy annotations and BPEL

All this seems rather abstract to me so I will tend to agree with Satish that we should not over engineer areas of the language where the requirements are not cristal clear. Could you please provide a detailed us case with associated WSDL, BPEL and Deployment Descriptor?
Thank you,

From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Monday, October 20, 2003 10:39 AM
To: Satish Thatte
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] policy annotations and BPEL


Satish Thatte enscribed upon magnetic domains:

WS-Policy and general assertion mechanisms like it don’t force you to express requirements at any specific level of detail (such as XML canonicalization) — so the issue of detail vs high level intent seems like a red herring to me relative to that sort of general mechanism.

The WS-Policy framework certainly doesn't force this level of specificity, but WS-SecurityPolicy certainly works at this level. It was to WS-SecurityPolicy that I was referring. Is there an alternative Policy vocabulary for "Security Intents" that you are offering for discussion?[1]

I see two specific issues which I still don’t see addressed

  1. BPEL processes are not self-sufficient.  They have dependencies on WSDL and other related artifacts.  Whatever the level of intent at which one wants to express QoS requirements, they need to be expressed uniformly for the package of related artifacts
This assertion (the need for uniform expression) seems to contradict your prior assertion, that business intent can be modelled using the WS-Policy framework. I am confused: what are you advocating?

Regardless, it is true that we are creating a constellation of inter-related artifacts that are needed to describe a working system. The real issue we are debating is: where is the most appropriate location in this constellation for QoS intentions, as well as QoS details. Lumping them together in a single, uniform declaration seems an unnatural act. The lower-level details expressable in WS-SecurityPolicy are an implementation of the higher-level intents. There is a strong coupling between the business process and the QoS intentions that are a logical part of that process. There is a strong coupling between the QoS details and the service descriptions. Thus my assertion that lumping them together is an unnatural act: it is poor architecture.

Perhaps some of our disagreement stems from some unstated assumptions. Your arguments certainly make more sense if we look only at run-time considerations, and ignore the design-time. Is this case?

  1.  Your approach requires us to invent a private BPEL notation for high level QoS requirements which I think is a rathole in itself, and one where others will undoubtedly assert prior initiative if not ownership
I have already proposed such a notation; it is not complex, nor, in itself controversial. The real rathole is debating the applicability of this approach to a set of proprietrary specifications that have different architectural ideas. This is not in the scope of the TC, nor is it in the best interests of the standards-setting process.

I'm not sure to whom you refer, when you state that "other will undoubtedly assert prior initiative..." Is there a need to set up a liason with some other standards TC / WG?

I won’t get into the fuzziness argument but I don’t equate abstraction with fuzziness ;-)

Then we "agree to disagree" on this point; I wasn't looking forward to "dictionaries at twenty paces." :-)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]