OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsbpel] policy annotations and BPEL

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.
-----Original Message-----
From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Wednesday, October 15, 2003 12:26 PM
To: Satish Thatte
Cc: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] policy annotations and BPEL


    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:
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,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]