[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] policy annotations and BPEL
Ron, 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. I see two specific issues which I still
don’t see addressed
I won’t get into the fuzziness
argument but I don’t equate abstraction with fuzziness ;-) In any case I think we have exhausted the
arguments at this point. Satish From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@ Satish, Ron, I was asking very simple questions. Regardless of the level, would the analyst not need to express these requirements both for BPEL processes and for WSDL services under various circumstances? Would s/he want to use the same notation for expressing them in all cases or not? If yes, do we feel we can dictate that notation?
The analyst works at a different
level of abstraction than WS-SecurityPolicy etc..
The process model he works with must work at that level of abstraction -- which
is distinct from that of a software developer. (The difference can be
summarized by the phrase "business intent versus technical
execution.") How is the analyst to express high-level intents for security
or QoS? You advocate a single mechanism to be shared by the analyst, technical process
modeller, and the administrator/deployer: WS-Policy, or something very much
like it. While this is appealing to a technologist's peculiar sensibilities,
this is inappropriate for two reasons:
The latter point is important. If BPEL processes are
truly portable, then there will be a market for "canned" predefined
processes (e.g., Siebel UAN) that can be obtained and used by many different
organizations. Yet if security and QoS intents
cannot be expressed within the process, or, worse still, are cast in concrete
in WS-Policy annotations scattered through various artifacts, the purchaser of
such a process definition will be left guessing at the intended security and
QoS intents of the original process designer. He will have to reverse-engineer
those intents, erase the various policy annotations that embody them in the
particular implementation he purchased, and finally produce his own policy
annotations. Doesn't sound terribly portable to me. I do worry about fuzzy statements of requirements especially when they may have legal implications. How does one prove that these high level requirements are actually satisfied?
This
is a general problem in any EDI-type of situation, and nothing we have
discussed can address this. It is up to the parties involved to resolve the
legal issues, not us. Work on the legal aspects of XML-based EDI has been done
elsewhere in OASIS; Jamie Clark has made some substantial contributions in this
regard. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]