- graap-wg - lists.ogf.org

termination versus determination
by Karl Czajkowski 03 Mar '05

03 Mar '05

The whole idea of an abstract "agreement" that is separable from the Agreement resource is troublesome. In order to make sense of it, I have taken to understanding the "agreement" word to mean "the obligations to which the parties are bound as a result of this WS-Agreement interaction." I cannot readily accept the idea that the Agreement resource can be destroyed and yet the "agreement" still exists in some state other than "all obligations are now historical and let's balance the accounting." If the agreement terms have obligations that are still within scope, I think it should be impossible to destroy the Agreement resource which represents the management interface to those active/pending behavioral obligations. The spec currently says, I think, that the resource SHOULD outlast the agreement and I think the spec should read that the resource MUST outlast any obligations denoted in the agreement. I think, but am not sure, that Heiko's idea of terminating an agreement (not the Agreement resource) is to release the parties from these obligations. If I understand Jon's objection, I think it is that such a notion is not really well defined. Releasing parties from the obligation can mean a number of different things: a) Truncate the scope of obligations and resolve accounting as if the obligations had been scoped from their original start time until the time of this truncation. b) Act as if the obligations never existed, and each party absorbs their own costs incurred so far. c) Form a new Agreement which amends the obligations of the old; resolve accounting based on the new terms, which could encode a detailed transitional cost model, etc. d) Trigger some existing "escape" clause in the agreement terms which specified how to amend the obligations as in (c). Of course, in all of these there is an assumed change in behavior of the parties to coincide with these changes in obligation. I think it is a fair point that one cannot simply talk about terminating the Agreement resource or its represented obligations without identifying which of these avenues (or some other) are to be followed. In the real world of contracts and agreement, things are not destroyed so much as ammended and obsoleted. The old stuff is never forgotten, and in fact can be dragged in to court as evidence to help resolve later conflicts. At the same time, we have practical use for cancelling the obligations in some domains, e.g. cancel a job halfway through the run. What we need to do is capture the right form of ammendment. I think for jobs, the flavor (a) is about right; the job execution gets truncated and the user gets billed for time spent so far. If we get into fancier resources or advance reservation, we might need some additional penalty clause to be triggered as in (d). The general case is (c) where another offer/accept cycle can explicitly "ammend" or "obsolete" an existing agreement. I don't know if this should always create a new Agreement resource or simply operate on the existing one. In practice when two people decide to "tear up" a contract they are really making a token gesture that destroys some physical records and creates a new verbal agreement that they will ammend the old agreement as described above in (b)! What I think all of this gets at is that the Agreement resource universe of WS-Agreement is a subset of the "agreement" universe where our WS-Agreement parties live. An Agreement resource MAY be retired because its agreement obligations have become historical curiosity. The various actions that can cause obligations to become "past tense" range from timer expiration, to explicit destroy-resource requests or replacement Agreement creation. When this happens, history is not erased but rather system management state is ammended and pertinent information is recorded into audit and accounting systems. Do we need more explicit Agreement content to denote what forms of ammendment can (or have) been applied to the obligations of an Agreement? Or can that be implicit in the domain-specific terms? karl -- Karl Czajkowski karlcz(a)univa.com

3 8

minutes from 2/28 telecon
by Jim Pruyne 01 Mar '05

01 Mar '05

All, Here are minutes from today's telecon. We'll meet again next week at the usual time. Reminder to follow. --- Jim Minutes from Feb. 28 '05 Teleconference Attendees --------- Jim Pruyne Takuya Araki Asit Dan Jon Rofrano Toshiyuki Nakata Kate Keahey Heiko Ludwig Agenda ------ Issue 10 & 14: Not used the spec., but followed the model is another category as in the case of WS-Policy. **Action: use table provided by Toshi in e-mail of 2/28/05 to replace the current table on page 6. Issue 13: The only thing that can change is the term states because there is no updates. So, there is no concern for consistency, and no need for consistent updates. **Action: Respond that we don't think this is a concern in the follow up. **Jim will add the comment to the tracker. Issue 9: Related agreements to be removed, and we only address two party agreements. **Action: Respond in tracker that we don't address this question. **Jim will add the comment to the tracker. Issue 11: - Reference to JSDL: **Action: Do not add to avoid confusion with referring to other in progress specs. - Colors on figures: **Action: Change to gray shades. Heiko to do this. - Update Jon's Affiliation: **Action: Will be done by Heiko. Issue 12: Proposed that the agreement document structure be separated from any of the supporting services/port-types. **Action: For at least one first time reader, it seems at the proper granularity. Concern that it will result in "chasing document" if we split it any further though from a purely technical perspective this would be possible and perhaps sound. Issue 15: Our approach will be to support port-types consistent with the convention used in WS-ResourceProperty. **Action: Will be re-addressed on the next call. Also find out what the state of WS-RP is. Reminder: Jim to contact JSDL to get an update on their status during a joint telecon.

5 6

telecon reminder
by Jim Pruyne 28 Feb '05

28 Feb '05

All, There will be a telecon today at the usual times and numbers. That's 4:00PM Central US and 866-673-8466 id #8578310. --- Jim

2 1

minutes from telecons (Feb. 14 and Feb. 23)
by Jim Pruyne 28 Feb '05

28 Feb '05

All, Attached are minutes from the last two telecons, on the 14th and 23rd of Feb. These deal almost entirely with handling comments we've received. Please not all Actions captures (with ** in front of them), and where ownership is explicit or implicit, update the entries in the tracker related to the comment. That tracker is at: https://forge.gridforum.org/forum/forum.php?forum_id=461 We will resume our usual Mon. call times starting next week which would be 4:00 central time in the US. A reminder on that is hopefully forthcoming. --- Jim Minutes from Feb. 23 '05 Teleconference Attendees --------- Takuya Araki Heiko Ludwig Jon Rofrano Wolfgang Zeigler Toshiyuki Nakata Asit Dan Agenda ------ Public comment period is over. Issue 8 (continued from last time): Much discussion about roles and which roles need to be specified explicitly in the context. Result is that this is a two-party agreement only, so the agreement initiator and provider define those two roles. This validates the definition of those two roles in the context as currently defined. **Action: We will augment the guarantee terms with which party is obligated and the obligee for each guarantee by role (initiator or provider). Also implies a response to issue #32. Now that obligation is specific, there's no need for the AgreementInitiatorIsServiceConsumer flag in the context. Issue 9 (and issue 14): Asit: Things we use are a matter of "public record" in the sense that it is visible to everyone. Toshi: But can we not use the information in them without naming them explictly. **Action: We need to be explict about the state of the specs. that we refer to, including their version. Be clear where these are public but not ratified by any standards body. Update table on page 6 (section 1.1.1). Remove the MAY be composed entries. Add column where we are explict about version that will be used. (Revisit this at beginning of next week). Minutes from Feb. 14 '05 Teleconference Attendees --------- Toshiyuki Nakata Heiko Ludwig Jim Pruyne Takuya Araki Asit Dan Agenda ------ Issue 2: Decided not enough participants to fully address the asynchronous binding issues on this call. Issue 3: Related agreements agreed last weeks to be taken out, but some discussion was still going on. Not enough further argument to change this decision. **Could be a primer issue as used in a service description term. Issue 4: on how do we know that terms are fulfilled? This seems to be outside the scope as it requires lots of further infrastructure. **Action: Add such information in the spec that says that enforcement is outside the scope. Issue 5: On why is expiration time part of the context? Agreed that it is not safe to always assume that it is provided as part of a higher-level structure such as a WSRF service? So, if needed the expiration time should be part of the agreement document. So, why in the context instead of a service description term? Asit: at least it does need to be defined how one fills in this field. Heiko: Also, it doesn't apply to the service, it applies to the agreement, so it isn't really a "service description term." **Action: leave it in place, capture this discussion, add justifying statements to the document. Issue 6: ZeroOrMore needed? Should this be provided as an additional cardinality in the compositors? This is adopted from WS-Policy, should we stay in synch. with it? What scenarios exist that support the use of ZeroOrMore? We also don't support arbitrary cardinality choices (e.g. "2 out of 5"), so we already don't strive to handle all of these. **Action: Leave it as is unless someone can come up with a strong use-case supporting it. Issue 7: Too complex. No easy way to address this. We can take this as a guiding principle as we address other comments. Also, it can be a statement on the type of presentation, and a more readable doc. (primer) is needed. Spec. doesn't require that entire thing be used in every example, so complexity can be removed in specific cases. This can be more clearly stated. **Action: Can also reply that actual number of structures is not all that large. Issue 8: AgreementInitiatorIsServiceConsumer why is this here? Heiko to give a specific proposal/use case where this is needed.

5 7

lifecycle concerns
by Karl Czajkowski 25 Feb '05

25 Feb '05

I wish to raise the discussion again regarding what I find as confusing facets of lifecycle in the WS-Agreement draft spec. In my earlier note about asynchronous/asymmetric operation patterns, I suggested that one way to address the message correlation problem is to return to something like our earlier Agreement state-machine: We could return an Agreement resource EPR immediately and have the Agreement start in a "not committed" state, which I will call "DecisionPending" to avoid confusion with the removed negotiation facilities. The initiator (client) can then monitor/poll the Agreement resource to determine whether the responder (service) accepts the offer or not. I think this would be a good change to allow an application-level asynchronous creation or other future negotiation patterns to compose with the basic Agreement presentation. I see the lifecycle then being basically: 1. DecisionPending 2. Observed (passively or actively) [violated or satisfied] 3. Complete (no longer observed) [violated or satisfied] These three phases are demarked by the state of the obligations between the two parties: there are no obligations yet in (1); in (2) the obligations are present but whether they affect service delivery has to do with the precise scoping of the terms; and in (3) the obligations are still present in a historical sense, but they are permanently out of scope and no longer affect service delivery. During observation (2), we can also consider whether the obligations are presently being satisfied or violated. This relates to the monitoring/enforcement discussion as to whether we wish to capture this in any way. During both (2) and (3), we can consider historically whether the obligations were satisfed or violated and by "how much". This relates more to audit and accounting. This notion of satisfied/violated is represented in the Guarantee States diagram as not-determined, fullfilled, and violated. As I read it, this section refers to the present conditions of phase (2) only, without any memory of past delivery. The basic state phases described above sound similar to the Service Runtime States diagram, but this part of the spec is scoped to individual services rather than the agreement as a whole. I think the states here are are embedded in the Observed (2) phase, except when all service terms are in the "Completed" state then the agreement as a whole is Completed as well. I have minor quibbles with the states "Ready," "Not Ready," and "Processing" which I think are straying towards domain-specific extensions. I think a generic state would be more like "Out of Scope" and "In Scope", e.g. is the service present according to the scoping conditions of the agreement terms. Orthogonally, we can consider readiness as whether the service terms are fullfilled or violated according to this scoping. Thoughts? Rotten fruit? karl -- Karl Czajkowski karlcz(a)univa.com

1 0

Re:[graap-wg] asynchronous binding
by alain＠ISI.EDU 22 Feb '05

22 Feb '05

A few excerpts: >From WS-Addressing 08/2004 --------------------------- (http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/) Some processors may use message identifiers (<wsa:MessageID>) as part of a uniqueness metric in order to detect replays of messages. Care should be taken to ensure that a unique identifier is actually used. For example, it may be appropriate in some scenarios to combine the message identifier with a timestamp. >From WS-Addressing Additions and Updates 04/2004 ------------------------------------------------- (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/h…) 2.3 MessageID and Retransmission The purpose of the MessageID header is to assign each message a unique identity. This identity can be used for duplicate detection, message correlation, and many other purposes. The prior revision of WS-Addressing required that no message share the exact same MessageID content. This statement posed a problem for reliable messaging [WSRM], which retransmits the exact same application message to compensate for transient communication failures (dropped messages). This revision relaxes the requirement slightly so that messages that have the same application intent may use the same MessageID. This definition allows MessageID to be used for correlation in the presence of retransmissions. Allowing the retransmission caused a minor security issue since a retransmission might be interpreted as a replay attack. The security considerations section describes how a timestamp may be used to resolve this issue. >From WS-GRAM user guide: ------------------------ (http://www-unix.globus.org/toolkit/docs/development/4.0-drafts/execution/ws…) A submission ID may be used in the GRAM protocol for robust reliability in the face of message faults or other transient errors in order to ensure that at most one instance of a job is executed, i.e. to prevent accidental duplication of jobs under rare circumstances with client retry on failure. The managed-job-globusrun tool always uses this feature, requiring either a submission ID to be passed in as input or a new unique ID to be created by the tool itself. If a new ID is created, it should be captured by the user who wishes to exploit this reliability interface. The ID in use, whether created or passed as input, will be written to the first line of standard output unless the quiet mode is in effect. If a user is unsure whether a job was submitted successfully, he should resubmit using the same ID as was used for the previous attempt. Quoting Takuya: >Karl: >Could you tell me the pointer to the standard spec. of the >asynchronous operation binding you mentioned in the telecon? >I've found that WS-Addressing has "message information headers", >which can carry the information that is necessary to implement >asynchronous operations, but what you mentioned seems to be more than that... >-- >Takuya Araki >Grid System Technology Group >Internet Systems Research Laboratories >NEC Corporation ><t-araki(a)dc.jp.nec.com>

8 14

No teleconference on 2/21
by Jim Pruyne 21 Feb '05

21 Feb '05

Folks, Feb. 21 is a holiday in the US, so I will not be available to set up a telecon. I suggest that we have the call this week on Wed. (Thurs. morning in Asia) instead at the same time of day. Unless many people say they will not be able to make it at this time, I will go ahead and set-up the call then. Thanks. --- Jim

1 0

next teleconference
by Jim Pruyne 14 Feb '05

14 Feb '05

All, The next teleconference will be on Mon. Jan 31. We are changing time with some hope this will better support people around the world. We'll hold the conference at 4PM central time (GMT-0600) in the US. That's four hours later than previously. As always, I have little faith in my ability to translate between time zones around the world, but here goes: Germany/Central Europe 11:00PM (2300) UK/GMT 10:00PM (2200) Eastern US 5:00PM Pacific US 2:00PM Japan 7:00AM (0700) The number will be the same as we typically use: 866-673-8466 or 702-477-6031 passcode: 8578310 Thanks. --- Jim

2 2

Re: [graap-wg] [Fwd: [ogsa-wg] Basic EMS BOF]
by Karl Czajkowski 11 Feb '05

11 Feb '05

On Feb 10, Jim Pruyne loaded a tape reading: > It appears that the OGSA-EMS team is looking to spin off a working group > in the area of job execution. If any of the graap team who will be in > Korea are able to attend this BoF I would suggest it, and hope that we > could make use of graap's work relevant there as well. > > --- Jim > FYI, I am intending to be there and will try to represent applicable ideas from GT 4.0 GRAM, WS-Agreement, and JSDL. karl -- Karl Czajkowski karlcz(a)univa.com

2 1

notes/minutes from 2/7/05 teleconference
by Wolfgang Ziegler 10 Feb '05

10 Feb '05

Minutes including Alain's notes are attached. Best regards Wolfgang -- 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 http://www.scai.fraunhofer.de "Heut ist nicht so kalt wie gestern, trotzdem dass heut kaelter ist" Minutes from Feb. 7, 2005 Teleconference Attendees --------- Takuya Araki Toshiyuki Nakata Wolfgang Zeigler Heiko Ludwig Asit Dan Alain Andrieux Karl Czajkowski Agenda ------ GGF session confirmed for March 16, 1:30 p.m. - 3 p.m. Working through the comments: #1, Changing Offers: After short discussion based on the material Toshi added to this track on the gridforge web-page, and previous discussions on this subject the participants agreed. Decission taken: The example mentioned in the spec is wrong, offers are not expected to change. The wsdl has to be corrected #2, Asynchronous Operations: Toshi: we need asynchronous messaging if the creation of an agreement takes long time to come back from the factory Heiko: according to WSDL specs we would do specify the asynchronicity at the binding level of the factory service specification, not at the port type level. Karl: then we need negotiation again! Asynch is like a very thin layer of negotiation. We would have a different port type: an asynchronous factory to compose with what exists already in the spec if we think binding level is not enough. A messageId like in GRAM would provide a mechanism to recover from the absence of response after the creation message is sent to the factory. In GRAM, if the user does not obtain a response within a timeout delay he chose, s/he/it can choose to decide to retry the submission by using the same message ID. If the job has been created already with that message ID, the factory does not create another job resource but simply returns the EPR (again). In WS-Agreement we could apply this concept instead of asynchronous notifications by having the client/initiator re-issue the same message to the factory, with the same message ID, after a delay chosen by the client. Note: messageID is a concept designed in WS-Addressing in order to detect duplicate messages. Karl will provide the mailing list with information on different ways to handle this problem examined in the context of GT4 implementation. Decission taken: Further discussion to prepare a decission should happen on the mailing list. #3, Related Agreement: Decission taken: Introduces too much complexity into the spec, related agreements are dropped from the spec for the moment. A short discussion after this decission (about probably shifting this kind of features into the (domain specific) context raised other questions like what is a domain, isn't the compatibility reduced when adding too much domain specific issues.., These questions could not be discussed as time for the telecon was over but need a final clarification. Discussions on certain aspects of the spec seem to be difficult as at this stage implementation experience is missing and also interoperability tests between different implementations.

1 0