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
|