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?
Thank you,
Edwin
From: Ron Ten-Hove
[mailto:]
Sent: Monday, October 20, 2003
10:39 AM
To: Satish Thatte
Cc:
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
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?
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." :-)
-Ron
