[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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: 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: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?
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? 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.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? 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]