July 2006 - graap-wg - lists.ogf.org

[Fwd: WSAG Draft]
by Wolfgang Ziegler 02 Aug '06

02 Aug '06

Dear all, Here are some comments from my colleague Oliver: AgreementSchemaTypes: wsa-Namespace is not used (should be removed) wsrf-bf: fault section could be moved to wsdl, therefore eliminating the dependency to wsrf-bf in the xml-schema (only in wsdl). AgreementAcceptanceSchemaTypes: Namespaces wsa and wsrf-bf should be removed since they were not used in the schema. Best regards Wolfgang -- Wolfgang Ziegler www.scai.fraunhofer.de/ziegler.html Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) Schloss Birlinghoven, D-53754 Sankt Augustin, Germany Tel: +49 2241 14 2258; Fax: +49 2241 14 42258 CoreGRID Network of Excellence www.coregrid.net Collaboration Gateway www.coregrid.net/cg Institute on Resource Management and Scheduling www.coregrid.net/irms

4 4

WS-Agreement workshop in conjunction with GGF18
by Wolfgang Ziegler 31 Jul '06

31 Jul '06

Dear all, as discussed at last GGF in Tokyo we will have a workshop addressing implementation and interoperability issues. Please see the call for participation below. Best regards Wolfgang ============================================================= First WS-Agreement Workshop September 10, 2006 Washington DC, USA in conjunction with Global Grid Forum 18 Deadline for 2-page contribution: *** August 20 **** Call for Participation ---------------------- The first workshop on WS-Agreement aims to identify: - Current WS-Agreement implementations - WS-Agreement interoperability concerns - Common terms used in WS-Agreement templates - Application specific terms used in WS-Agreement - Use cases for WS-Agreement *** All authors are requested to relate their work to the current version of WS-Agreement, which can be found at: https://forge.gridforum.org/sf/docman/do/listDocuments/projects.graap-wg/do… *** Submission Process ------------------ Developers/authors are requested to provide a 2-page document (in PDF format) single column, 10pt font size. The document should describe details of the WS-Agreement implementation and how it relates to the specification available at the above Web site. The 2-page document should be sent to Wolfgang Ziegler (wolfgang.ziegler(a)scai.fraunhofer.de) Omer F. Rana (o.f.rana(a)cs.cardiff.ac.uk) or Philipp Wieder (ph.wieder(a)fz-juelich.de) by August 20, 2006. The contributions will be evaluated and authors will be informed on August 28, 2006, whether their contribution has been accepted. Workshop details ---------------- Authors of accepted contributions are requested to present their work at the workshop. Demonstrations of work are particularly welcome. The workshop will be held in conjunction with the Global Grid Forum 18, on September 10, 2006, at the Washington Convention Center 801 Mount Vernon Place NW Washington, DC 20001 For more information regarding the venue, registration, and lodging, please visit http://www.ggf.org/GGF18/ggf_events_ggf18.htm. ============================================================= -- Wolfgang Ziegler www.scai.fraunhofer.de/ziegler.html Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) Schloss Birlinghoven, D-53754 Sankt Augustin, Germany Tel: +49 2241 14 2258; Fax: +49 2241 14 42258 CoreGRID Network of Excellence www.coregrid.net Collaboration Gateway www.coregrid.net/cg Institute on Resource Management and Scheduling www.coregrid.net/irms

1 0

no telecon on 7/19
by Jim Pruyne 19 Jul '06

19 Jul '06

Folks, See my previous message with the draft of the specification. To give time to review, I'm canceling this week's call, and we'll meet again next week to finalize this draft. Thanks. --- Jim

2 1

proposed final draft of WS-Agreement
by Jim Pruyne 19 Jul '06

19 Jul '06

All, Attached is the proposed, final draft for WS-Agreement. I believe this has all outstanding items from public comment, and group discussion completed (thanks Heiko!). Rather than have a telecon tomorrow (7/19), I propose that we review this draft over the next week, and determine if we are satisfied with the state, and discuss on a telecon next week. The last bit of changes was determining how we wish to deal with IDs, and it was decided, ultimately, to simply stick with strings as feedback we heard said that other types are less certain in tooling, and the semantics of comparison were not clear. Given that the sole purpose of ids is comparison in a sense, we've decided (Heiko and myself on the call last week), that we would just stick with strings since both the tooling, and the meaning of comparison are well defined here. --- Jim

1 0

Re: [ogsa-wg] FINAL CALL: OGSA 1.5 Architecture and Glossary
by Karl Czajkowski 18 Jul '06

18 Jul '06

On Jul 17, Subramaniam, Ravi modulated: ... > Would it be accurate to observe that where the disconnect here is that > the view taken in the thread is that the establishment is the key and > hence having that bi-party is desired but I have taken the > "binding/honoring view" where the referenced parties define the > agreement? > Unfortunately, I don't think that is the disconnect. Apologies for this long e-mail, but I want to recap some of the issues which have haunted WS-Agreement. There are three different relationships, as you mention. This same debate was had regarding WS-Agreement, and it wasn't merely an issue of feature minimization, but also a philosophical issue: 1. The communicating parties in the "establishment" of the agreement, obviously important in WS-Agreement. These are the "initiator" and "responder" roles in our protocol. One can actually design multi-party protocols here, but the debate is whether this is desirable---whether it models the underlying relationships and decision-making that is to be exposed. 2. The obligated parties of the agreement. We basically map these to the protocol roles in WS-Agreement, but we recognize that they can be delegated relationships... this is part of the internal logic of the service to either make decisions or "broker" decisions. As you said, the communicating parties "represent" the obligating parties during the establishment of the agreement. This obligating relationship is actually what people are referring to when they say that, in practice, real world agreements that "appear" multi-party are really sets of bilateral agreements. This boils down to how the obligated parties can reconcile things with an auditer or within a legal system. This is complicated by the fact that new entities are sometimes introduced, e.g. a set of members agreeing bilaterally with an "association" over which the entities will also gain fractional control. 3. The services which are the subject of obligations. It sounds like everyone here is seeing this the same way, so I won't belabor the point. The two philosophical debates to be had are regarding the cardinality of these obligating relationships (2) and also whether the obligating relationships are important to informing the communication patterns and semantics of the protocol. I think the best reason to investigate real-world agreements/contracts is to see what we can learn from them about practical solutions that have been found. For example, this can inform us on the important differences between negotiation+agreement, performance, and reconciliation which may occur in different overlapping but not equal time periods. (For example, one might legally resolve a contract dispute after the "service period" is over, but before the contract has become legally irrelevant.) This has helped GRAAP-WG to delineate the function of WS-Agreement service representations: our service represents a basic negotiation and agreed-service monitoring infrastructure, but retires agreements to some presumed external entity for audit and reconciliation. Our agreement language is (hopefully) complete enough to guide the reconciliation phase, as well as to guide the actual negotiation and performance phases. However, I personally belong to the school which sees this as just a useful model for automated agreement patterns. It makes the distributed architecture more understandable to follow the social idioms used for human-based agreements and contracts. There are those who even question the legality of things like digital signature and non-repudiation. I do not want adaptive computing systems to really be forming legally binding obligations. With their problems, digital signatures are still much easier to justify than the idea that we can delegate legal responsibilities to a machine-driven decision process! I think there are examples of machine-driven, binding decisions out there, e.g. in the financial trading sector. But, I think many computer systems operators/owners will be scared away from Grid technologies if they are told that their computer will now begin signing contracts which bind the owner... I think we need a lower barrier to entry into this field. karl -- Karl Czajkowski karlcz(a)univa.com

1 0

telecon on 7/12
by Jim Pruyne 12 Jul '06

12 Jul '06

We will have a telecon. on Wed. morning/evening. Dial-in numbers will be the same: 9:00AM Central Daylight Time US (UTC-5) which should be: 10:00AM Eastern Daylight Time US 1500 UK 1600 Germany 2300 Japan 2100 Thailand Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the US. Conference code #8578310. Primary discussion topic is to finalize decisions on use of QNames, anyURIs, and Strings in appropriate places in the schema. --- Jim

2 1

Strings, QNames and videotape - or: many ways to skin a cat
by Heiko Ludwig 12 Jul '06

12 Jul '06

All, as the last outstanding item before closing on the final V1 of WS-Agreement, we need to settle on the use of strings, QNames and NCNames for descriptive names and IDs that we use in the schema and spec. Right now, it is a merry mixture, following various trends in the past. We have a number of options to address the restrictions that should apply to unique identfiers and desriptive names: - Unique identifiers could be strings (no restriction), QNames (one can/must use namespaces to structure ids), or NCNames (no QName). There are pros and cons to all of them but the most likely candidates seem to be strings or QNames. I don't see implementation reasons for NCNames right now. - Descriptive names could be strings or we may force NCNames. I don't see the point of telling people how they would like to call their agreement etc. descriptively. If a users thinks a:b:c tells him or her what is meant who wants to object. So I strongly propose the first. Applying the above thoughts to the schema, we yield: - a schema where all ids are QNames and all descriptive names are strings: - a schema where all ids and names are strings: To decide what is an id and what is a descriptive name I strictly went by the name of the attribute, finishing with Id or not. This might not be correct. For example, ServiceName coul dreally be an ID. Then we should call it that way and make it whatever we decide. If we go with string ids, it doesn't matter. This point is to be concluded in tomorrow's phone call and then applied to the text of the spec in the following day or two. Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig(a)us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 http://www.research.ibm.com/people/h/hludwig/

2 1

RE: [graap-wg] url for the Web Services Policy WG in W3C
by Toshiyuki Nakata 05 Jul '06

05 Jul '06

> Hello: > Asit: Thank you very much for the pointer. > > I intend to attend today's teleconference, but I might fail > to do so, .. > All in all I would suggest that for this version of the spec, > we should stick to the current spec to be released and > consider the modifications for the next version of the specification. Sorry I couldn't attend last week's teleconference. Afterwards I heard that the modification to the current spec would be small.... So.. Since the change seems to be small, could we keep the spec as it is and reflect the change when the new WS-Policy specification is finalised ? Best Regards Toshi ----- Toshiyuki Nakata 中田　登志之 Executive Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509) > -----Original Message----- > From: Toshiyuki Nakata [mailto:t-nakata@cw.jp.nec.com] > Sent: Wednesday, June 14, 2006 9:18 AM > To: 'Asit Dan' > Cc: 'GRAAP-WG' > Subject: RE: [graap-wg] url for the Web Services Policy WG in W3C > > Hello: > Asit: Thank you very much for the pointer. > > I intend to attend today's teleconference, but I might fail > to do so, so here are my views on PROS and CONS: > > PROS: > Quote: from > http://www.w3.org/2006/04/ws-policy-charter.html > "Web Services Policy defines a flexible policy data model and > an extensible grammar for expressing the capabilities, > requirements and general characteristics of a Web service, > and defines mechanisms for associating policies with Web > service constructs. > Web Services Policy is used to convey the conditions for an > interaction between a Web service requester and a Web service > provider." > It would be good to have this related part in WS-Agreement > described in a compatible way as that would make acceptance > of WS-Agreement easier. > > CONS: > 1)Adopting WS-Policy would mean that WS-Agreement would > depend on a specification which still needs to be agreeed to. > While the charter does say that "Therefore, this Working > Group shall be schedule-driven and Web Services Policy shall > remain compatible with and to the extent possible accommodate > the use of these existing policy assertions. " > Until the final draft is out, one may not know what will stay stable. > The end date is 31 December 2007 which is a year and a half > away. I think many people have been waiting for WS-Agreement > spec to be completed and to have to really wait more might > have negative effects. > > 2)Adopting WS-Policy would mean that there would be need to > change the current implementations. > I do not know how many implementations of WS-policy there are > in the world but to have to modify the current > imlplementation would have some negative issues (at least for > the implementation people) for getting interoperability etc. > > 3)(This is a minor issue) Since this has a large impact, we > might need another call of public comments. > > All in all I would suggest that for this version of the spec, > we should stick to the current spec to be released and > consider the modifications for the next version of the specification. > > Best regards > Toshi > > ----- > Toshiyuki Nakata 中田　登志之 > Executive Chief Engineer, Central Research Lab. NEC 1753, > Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan > Tel +81-44-431-7653 (NEC Internal 22-60035) Fax > +81-44-431-7609 (NEC Internal 22-60509) > > > -----Original Message----- > > From: owner-graap-wg(a)ggf.org > [mailto:owner-graap-wg@ggf.org] On Behalf > > Of Asit Dan > > Sent: Thursday, June 08, 2006 12:04 AM > > To: Toshiyuki Nakata > > Cc: GRAAP-WG > > Subject: [graap-wg] url for the Web Services Policy WG in W3C > > > > > > Toshi, > > As per the discussion in today's call, here is the url > for the Web > > Services Policy Working Group Charter. > > http://www.w3.org/2006/04/ws-policy-charter.html > > > > You can find the WS-Policy document by following the > WS-Policy” Member > > Submission <http://www.w3.org/Submission/2006/06/> link. > > Regards. > > Asit Dan, Ph.D. > > SWG SOA Design Requirements > > Phone: (914) 766-1767 > > Internet: asit(a)us.ibm.com > > ICSOC 06 PC Chair (http://www.icsoc.org) > > >

6 10

telecon on 7/5
by Jim Pruyne 05 Jul '06

05 Jul '06

We will have a telecon. on Wed. morning/evening. Dial-in numbers will be the same: 9:00AM Central Daylight Time US (UTC-5) which should be: 10:00AM Eastern Daylight Time US 1500 UK 1600 Germany 2300 Japan 2100 Thailand Phone Number: 866-673-8466 in the US. 702-477-6031 for those outside the US. Conference code #8578310.

1 0