August 2007 - graap-wg - lists.ogf.org

telecon on 8/1
by Jim Pruyne 19 Sep '07

19 Sep '07

All, Our telecon schedule has slipped over the last few weeks. Last time, attendance was 0. I'll try once again to hold the conference, but if there are again no or few participants, I'll see about re-addressing our conference schedule, perhaps waiting until after the summer, and maybe OGF21 to re-start them. We'll hold it at our usual times: 9:00AM Central Standard Time US (GMT-0500) which should be: 10:00AM Eastern Standard Time US 1600 Germany 2300 Japan The current dialin numbers are: Toll number: 8324452343 Toll free number: 8664809967 Conference code: 8578310 I would personally appreciate an update from people doing implementations and to get our session plans for OGF21 finalized. If anyone else has topics they would like to discuss, please let me and the mailing list know! The agenda is very open, and it would be great to get broader participation so we can make more progress on topics following the completion of WS-Agreement. --- Jim

9 30

Feedback on "Challenges in EU Grid Contracts"
by Karl Czajkowski 31 Aug '07

31 Aug '07

Michael, I just read "Challenges in EU Grid Contracts" for the first time after seeing it linked from Toshi's wiki page updates. I thought it might be useful to address several topics in the paper regarding WS-Agreement, though I have a suspicion that some of these issues may have been addressed long ago by others... 1. There is an assertion that WS-Agreement does not support acknowledgement of receipt of an offer independent of the acceptance decision. This is incorrect, as the PendingAgreement construct is specifically defined for this purpose: the CreatePendingAgreement factory pattern returns an EPR to a PendingAgreement which is yet to be accepted or rejected. This feature was motivated by a different observation that a decision process might be too slow to perform during a SOAP-over-HTTP in/out message, but it equally addresses your concern of knowing that the offer was received before the decision process is complete. (A WS-* purist position could be that message acknowledgement is a transport-level problem rather than a SOAP problem, but we had to bow to the practical use of SOAP-over-HTTP...) 2. There is an allowance for external acceptance notification channels, though I admit this is not emphasized in the text. Present in the base protocol are the Acceptance port type and the agreement state resource property, both of which may be used simultaneously on the same agreement. It is the state model which allows for transitions to accepted state independent of the other protocol operations. There is nothing to disallow other notification paths such as email, facsimile, registered mail, etc. (but, see next issue). 3. A significant difference between WS-Agreement and the contract law model described in the paper is the moment of acceptance: in WS-Agreement, acceptance is defined as the moment the responder chooses to accept, and is not dependent on sending an acceptance message to the initiator. This difference becomes clear in unusual asynchronous/lossy message environments and/or contested agreements. This is a crucial technical point in WS-Agreement. In order to define the acceptance moment as when the acceptance is delivered to the initiator (as in your contract law discussion) would require a reliable delivery model where some trustworthy (third-party) observer can witness the delivery. At risk of confusing the terminology, a way to characterize such a variant of our protocol might be: 1. initiator sends offer to responder. 2. responder chooses to accept. 3. responder attempts to send acceptance notice. 4. reliable message channel observes delivery of (3) and acceptance is now true. Given our presumption of an Internet-like environment without any secure, third-party channel to "serve" notices, this does nothing more than "rotate" the participant roles by one unidirectional message. In effect, it is really the "initiator" in step (4) who decides acceptance by choosing to receive the acceptance notice or not, because it is not possible to prove that he received a message unless he acknowledges it! Thus, his offer is not really obligating, as he can shirk his responsibilities by choosing not to acknowledge the acceptance. Thus, I would say the above "contract law"-style sequence of: offer/accept/receipt-as-decision is indistinguishable in practice from: invite/offer/accept-as-decision As there must be some party in the system that first knows the decision before this information is distributed asynchronously to all parties, we make the responder be the observer! Finally, as I described it in a previous email. WS-Agreement supports this through the slightly more general: advertise/offer/accept-as-decision where you could restrict or otherwise optimize access to advertisements in order to effect a directed invitation. (It is considered somewhat out of scope for WS-Agreement to define how advertisements are retrieved, e.g. what sort of publishing or information dispersal architecture is used for discovery.) I hope this helps clarify the technical solution embodied in WS-Agreement. karl -- Karl Czajkowski Software Architect Univa Corporation 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz(a)univa.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software

3 7

XPath issues in Creation Constraints
by Dominic Battre 23 Aug '07

23 Aug '07

Hi. As we are looking for interoperability tests and implementations start showing up, I have a question about common practice in the evaluation of creation constraints. I have raised the issue before, but I think I have never received an answer. The issue is: A creation constraint might have an xpath "//wsag:foobar" but it is very difficult to get the namespace that is bound to the "wsag:" prefix. At least in case Axis 1 that is used. Does Axis 2 solve this problem or any other toolkit? Otherwise the question is whether it is technically feasible to evaluate XPath expressions like that at all. If it is not feasible, it might be considered a problem in the WS-Agreement spec. The reason for my writing this is that I found this bug report: http://bugzilla.globus.org/globus/show_bug.cgi?id=4227 The Globus Toolkit community faced the same issue and surrendered - or lets say, they came up with a very nice solution: Introducing a sane query language TargetedXPath. This is the Schema: http://src.gridindex.org/globus_4.1.1/xref/src/wsrf/schema/core/query/ This is the Implementation: http://src.gridindex.org/globus_4.1.1/xref/src/wsrf/java/core/source/src/or… I like this approach a lot. Would this be a viable approach for WS-Agreement? Best regards, Dominic

2 2