Re: [wsbpel] policy annotations and BPEL

["Monica J. Martin" <monica.martin@sun.com>]

Edwin Khodabakchian wrote:

> Ron,
> 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?

mm1: Perhaps, Satish could also provide an example so we could 
understand both approaches, then determine if use cases are required. 
Thanks.

> Thank you,
> Edwin
>
>     ------------------------------------------------------------------------
>     *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,
>
>     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.
>>        2. 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?
>
>>       1.
>>
>>     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." :-)
>
>     -Ron
>