Hi: Apologies again for not making it on this call.. Any other moves on the pending issues? Best Regards Toshi
Andreas, We didn't have a discussion on this in our weekly call. As Karl and Toshi noted that this is a trivial change (and Heiko provided a validated schema with this change), so from a pure technical implementation viewpoint this doesn't impact the spec even at this late stage.
I believe this is a very important issue, and we should have a well reasoned and well articulated position on this for the wider audience -- whatever may be the final decision of the group. The issue will keep coming up as the wider audience (Web Services community) will fail to grasp the strong objections of this group to aligning this spec to WS* stack, and WS-Policy in particular. I believe the goal of this group is to make WS-Agreement specification to be adopted by the wider Web Services community, and not to be perceived as something niche for job scheduling or just "Grid-thingy". Off course, in the same spirit, I (we) have equally strongly advocated to the JSDL community for leveraging this spec in specifying flexible scheduling objectives.
There are several benefits from this change: better alignment and acceptance by the broader WS* community and also avoiding confusion on SLA vs Policy. A wide spectrum of folks I hear from in my everyday activities (architects, developers, customers, analysts...) don't quite distinguish SLA and Policy. [ Off course, that's not my position.] Typical comments I hear -- are you using WS-Policy in specifying service level assertions? By embracing the use of WS-Policy as an envelope for agreement terms we not only avoid this confusion but also easily demonstrate what additional aspects are being covered by WS-Ag spec. Finally, in the runtime enforcement environments (service registry, monitoring system, workload manager, ... ) SLA derived enforcement policies can be represented uniformly.
Given that WS-Policy draft (that has been submitted to W3C) is very stable - has been co-authored by representatives from several organizations, already implemented by many vendors and many other OASIS standards on security, transaction, reliability, etc. dependent on this spec - and changes to the current draft of WS-Ag spec is minimal (not surprising, since we started with WS-Policy for term composition), there are many good reasons to embrace WS-Policy now. In any case, it's a public document (W3C), and we can make WS-Ag spec dependent only on the submitted draft.
Regards. Asit Dan, Ph.D. SWG SOA Design Requirements Phone: (914) 766-1767 Internet: asit@us.ibm.com ICSOC 06 PC Chair (http://www.icsoc.org)
Karl Czajkowski <karlcz@univa.com> Sent by: owner-graap-wg@ggf.org 06/28/2006 03:20 AM
To Andreas Savva <andreas.savva@jp.fujitsu.com> cc "'GRAAP-WG'" <graap-wg@gridforum.org>, Toshiyuki Nakata <t-nakata@cw.jp.nec.com>, Asit Dan/Watson/IBM@IBMUS Subject Re: [graap-wg] url for the Web Services Policy WG in W3C
I agree. It doesn't seem to add much to WS-Agreement at this point, and I think people who want to engage in an "SLA and policy" discussion should be able to observe the trivial mapping necessary to understand our compositions as policy composition.
karl
On Jun 28, Andreas Savva modulated: ...
I've read Toshi's previous email on pros/cons and I agree with him. I think at this point (one step before publication of the WS-Agreement spec) making a change that brings back a dependency on a specification that is about to enter the standardization process is not a good idea.
-- Andreas Savva
-- Karl Czajkowski karlcz@univa.com
------- NEC 中央研究所 主席技術主幹 中田 登志之 Toshiyuki Nakata Executive Chief Engineer Central Research Laboratories NEC Corporation +81-44-431-7653