|
Ron,
I remember from
previous discussions that a common assumption is that most likely the
analyst will work neither at the WSDL level nor at the BPEL language level, but
at an abstract notation level (BPMN and similar tools). So whether the high
level tool translates policies down to the WSDL level or to the BPEL
level might not be that important for the analyst.
Ugo
Satish,
My apologies
for being slow to respond to your message; I was on holiday last week.
My comments are in-line below:
Satish Thatte wrote:
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 analyst does not work at that level of detail (e.g., what does he
know about canonicalization algorithms for XML?)
- It inhibits reuse of process definitions.
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.
If WS-Policy is indeed the universal mechanism used to express such intents,
then we have an even greater impediment to portability. WS-Policy (and its
offshoots) are proprietary specifications which cannot be licensed by third
parties. The implications for portability (and even interoperability) are
dismaying to say the least. If a licensable alternative to WS-Policy appears
(which seems likely), we still have the portability problems discussed above,
plus the balkanization of the policy landscape which will create more
portability headaches. Is it the intent of this TC to encourage such
outcomes?
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.
Regardless, I believe chasing down
legal issues is a rat-hole. EDI participants have been solving this problem
for decades. The real issue facing us is technical: assuring interoperation
and portability.
As to the "fuzzy statements", this
is a necessary consequence of abstraction, is it not?
Best
regards,
-Ron
|