March 2005 - graap-wg - lists.ogf.org

updated draft
by Karl Czajkowski 06 Apr '05

06 Apr '05

Jim has kindly posted version 12 of the draft, including comments and revisions by me. The comments emphasize my concerns about the existing presentation and content of some sections. The revisions attempt to add the extensibility needed for Jon's signature problem (without actually defining any signature-related syntax) and the "async" interfaces. I also removed the Terminate operation. I am sure there are presentation problems and inconsistencies, but hopefully this is a more concrete basis for further discussion of these proposed changes. Please ignore the appendix entirely. The main sections are intended to be normative and the appendix is unknown older content that I did not touch. karl https://forge.gridforum.org/projects/graap-wg/document/WS-AgreementSpecific… -- Karl Czajkowski karlcz(a)univa.com

5 19

Negotiation Protocol Specification
by Chee-Kian Koh 29 Mar '05

29 Mar '05

Hi all, I understand that this working group is currently working on a negotiation protocol named WS-AgreementNegotiation. I also know of another effort call WS-Negotiation, and so I'm wondering if these two are the refering to the same thing. Thanks. ----------------------------------------- Melvin Koh Chee Kian Grid Research Engineer Asia Pacific Science & Technology Center Sun Microsystems Inc. Website: http://apstc.sun.com.sg/ -----------------------------------------

1 0

minutes from 3/28 telecon
by Jim Pruyne 29 Mar '05

29 Mar '05

Minutes attached. We should be meeting next week at the same time. --- Jim Minutes from Mar 21 '05 Telecon Attendees --------- Toshiyuki Nakata Jim Pruyne Karl Czajkowski Takuya Araki John Rofrano Jon MacLaren Asit Dan Agenda ------ Issue 18: Superceded by following discussion on lifecycle which is to be addressed. Issue 21: Is our state model extensible is an important question. For example, "Not Ready" is not always a needed state. What we'd like to do is update the overall state diagram. We need to introduce an initial state. Processing is removed as a top-level state, and can be considered a sub-state of Ready. Transition from either "Not Ready" or "Ready" to "Completed" is possible. **Action: update the state diagram and description text. Try to find a better word than "Completed." **Asit to own the updates. There's been discussion related to signature of agreement on the mailing list. Karl and Jon have reached some consensus. This requires some extensibility on the input and output to the create agreement operations. Perhaps already covered in the current versions. **Action: Karl to review the current spec. in this area. Karl also raised issues about how to specify the criticality of an extension. That is, would an extension have to be processed, or may it be safely ignored if a provider doesn't understand them. Is there a community best-practice alredy in place or needed for this? Jim starting to schedule with JSDL to get bi-directional updates, and how it relates to OGSA BES.

2 2

JSDL cheat sheet
by Karl Czajkowski 29 Mar '05

29 Mar '05

In the absence of a revised JSDL document w/ all the work items completed that were generated at GGF-13, here are some notes I took for myself on the basic structure and scope... Please note that there are two ways to look at the resource constraints (this is one of the most metaphysical aspects of job scheduling): 1) implied performance requirements via physical resource selection 2) qualitative features of the job configuration I think the JSDL view is more towards (2), meaning that the resource constraints describe basic "shape" of a job. They need to be complemented by more performance-oriented constraints including wall-clock lifecycle and/or performance of hardware (CPUs, interconnects, disks, hierarchical RAM, etc.). I think JSDL is extensible enough to insert performance constraints into its structure, so I do not know if it is better to do this or use an external annotation format for composing JSDL, performance metrics, and WS-Agreement. karl JSDL cheat sheet ---------------- There is an explicit understanding that the base JSDL doc element allows expression of homogeneous parallel jobs, and sequential jobs. To express heterogeneous parallel jobs, or heterogeneous "alternates" (a Unicore idea?), will require an enclosing context that presents a set of JSDL job documents w/ some way to interpret them for this purpose. In other words, a multi-job like syntax could represent either "do all these simultaneously" or "choose one of these that fits the resource pool". It will take some time for a new draft to settle out w/ all the revision decisions enacted. We pushed a lot of stuff out of scope and tried to fix a lot of warts. Here is a rough sense of the structure, without trying to write a schema right now: JobDefinition JobDescription JobIdentification ? JobName ? Description ? JobAnnotation * JobProject * xsd:any##other User ? ExecutionUserID ? ExecutionGroupID ? UserGroup * xsd:any##other * Application ? ApplicationName ? ApplicationVersion ? ExecutableApplication ? Executable Argument (xsd:string) * Environment (xsd:string) * attr: name=xsd:string Input ? Output ? Error ? WorkingDirectory ? PosixStackLimit ? PosixProcessLimit ? ... PosixMaxFilesizeLimit ? xsd:any##other * xsd:any##other? Resource ? HostName * ResourceCount ? CPUArchitecture ? TotalCPUCount ? TotalRAM ? ... PerResourceCPUCount ? PerResourceRAM ? ... DataStaging * FileName FileSystemID ? CreationMode DeleteOnTermination ? Source ? URL Target ? URL xsd:any##other ? xsd:any##other * xsd:any##other * The Input and Output elements are actually complex structures to do the expected things such as associating source/destination URLs with local filenames or filespaces. The types of many obvious things are xsd:string. The types of the "resource constraint" numerical limits will be a ValueRangeType that basically is something like this: sequence <Exact>xsd:integer</Exact> * <LessThan>xsd:integer</Exact> * <GreaterThan>xsd:integer</GreaterThan> * <Between> <Lower>xsd:integer</Lower> <Upper>xsd:integer</Upper> </Between> * to allow the structured expressionf of their previous "string range value language" which allowed things like: a, b, c, d-e, f-, -g to give a mixed list of values, intervals, and semi-spaces. -- Karl Czajkowski karlcz(a)univa.com

1 0

proposal: agreement lifecycle end-games
by Karl Czajkowski 28 Mar '05

28 Mar '05

I think the best solution to this termination/expiration mess is to separate completely the notions of "lifetime of obligations" and "lifetime of Agreement interface". A. The lifetime of obligations should be captured solely in term-level meta-data and/or domain-specific lifecycle models. Individual service or guaranatee terms MAY have expiration times on them that are set statically or renegotiated by a mechanism outside the scope of our first specification. Additionally, some obligations MAY last indefinitely or until some domain-specific events occur. B. The lifetime of the service interface SHOULD be greater than the effective lifetime of any obligations, but I guess I can accept that this may not be possible with limited Agreement implementation QoS. It is hard to be normative about such failure modes. C. I suggest that we drop (for now) any notion of terminating the obligations using WS-Agreement mechanisms. If we can find a clear proposal for handling such ammendment of obligations before the spec is done, I am not personally against reincorporating it in some form. D. I suggest that we defer to WS-ResourceLifetime for handling the termination of the Agreement resource itself, with the specification advocating the above "SHOULD" about Agreements outlasting their embedded obligations (B). E. We should introduce an agreement-wide state, complementing the proposed Pending/Rejected/Observed states, to represent the Complete or PostObserved condition where all terms have passed "out of scope" and into history. What is the best state name for this? F. Should we introduce any kind of "linger" time to indicate an interaction with WS-ResourceLifetime to commence an automatic countdown to Agreement destruction once it has reached the Complete or PostObserved state? karl -- Karl Czajkowski karlcz(a)univa.com

2 9

telecon on March 28
by Jim Pruyne 28 Mar '05

28 Mar '05

All, We'll have a telecon at our usual time on our usual day: Mon. afternoon US / Tues. Morning Asia. Dial-in and times will be the same: 4:00 Central Time US 866673-8466 or 702-477-6031 passcode: 8578310. --- Jim

1 0

scoping thoughts
by Karl Czajkowski 25 Mar '05

25 Mar '05

The recent thread between Jon and me has given me some added clarity as to the framing and scoping of the agreement problem space. Please consider the following as my view of how the agreement concept space is populated and which of these concepts are in or out of scope of WS-Agreement. Note, I have CAPITALIZED certain keywords that I think are the important concepts we need to tease apart. I thought this would be easier than reading HTML or LaTeX tags in the ASCII. :-) Do we have a concensus on these concept definitions and/or scoping? If so, I would be happy to try to rejigger the specification introductory text to better communicate this information. If not, I think it is crucial that we iterate on this until we do have consensus! karl In designing and presenting WS-Agreement, it is useful to define the concept space of agreement. 1. Agreement is a RELATIONSHIP between two parties. The core concept of WS-Agreement is that agreement is a relationship between two parties in which they are obligated to act in certain ways according to a notion of reciprocity. These obligations are necessarily domain-specific, and the reciprocity does not imply symmetry: one party may be obligated to complementary behaviors such as paying for service rather than returning service in kind. The semantics of this relationship are out of scope of WS-Agreement because they are domain-dependent. 2. WS-Agreement defines a PROTOCOL for establishing agreement. The fundamental resource management challenge being addressed by WS-Agreement is the standardization of a signaling protocol to allow temporary two-party agreement relationships to be established, maintained, and retired in a decentralized, multi-party, distributed system. These agreements modify, or parameterize, the behavior of the parties towards one another while respecting global system constraints on available resources etc. The mechanics and syntax of this protocol, except for the embedded domain-specific content, are within scope of WS-Agreement. 3. The WS-Agreement protocol encodes an agreement DOCUMENT which represents the nature of the relationship in order to facilitate agreement establishment. At minimum, WS-Agreement requires that one party OFFERs to establish agreement with an embedded agreement document. The other party must ACCEPT or REJECT this offer to establish (or not) the agreement relationship and bind the two parties. The syntax of this document, except for the embedded domain-specific content, are within scope of WS-Agreement. 4. The agreement document also is useful to represent the STATUS of the relationship for purposes of general system introspection and management. The presentation of the document and associated advisory metadata is within scope of WS-Agreement. 5. Another goal in some trust and accounting environments is to be able to DEMONSTRATE that an agreement relationship exists. The ability to demonstrate the existence of an agreement relationship may be valuable when resolving conflicts or in order to increase confidence in an agreement relationship between parties enjoying limited trust in one another. This demonstration of agreement can be facilitated by bilateral exchange of agreement documents with signature or some other means of visibility to a third party arbiter, whereas mere establishment of agreement between trusting parties may be accomplished with less data exchange. The ability to exchange agreement documents bilaterally is within scope of WS-Agreement, while the specifics of how one might sign such documents is out of scope and only supported through extension mechanisms. 6. Another goal is to be able to MEASURE the satisfaction of an agreement relationship. The measurement or validation of behavior of a party may be performed for different reasons by each party in the agreement and/or a third party. a) A party may measure its own behavior in order to adaptively stay within the terms of the agreement, to know whether it has done so, or to ADVISE the other party when the relationship cannot be satisfied. b) A party may measure the other party's behavior in order to RATE the reliability or trustworthiness of that party. c) A third party may AUDIT either party's behavior in order to facilitate resolution of conflicts (possibly in combination with demonstration of the agreement relationship). The self-monitoring behavior of an agreement party is out of scope of WS-Agreement, but the ability to advise other parties of past or imminent status changes is within scope. The monitoring of behaviors by the second or third party is out of scope of WS-Agreement. [Should an ability to advise a party of external observations of its behavior be in scope? It is not currently.] -- Karl Czajkowski karlcz(a)univa.com

1 0

proposal: stateful async agreement
by Karl Czajkowski 22 Mar '05

22 Mar '05

I reviewed all of the comments on the GGF tracker, and I do not see any real surprises relative to the "big issues" that have been in discussion. Here, I want to group together a set of possible resolutions that go together if we accept my earlier proposal to handle "asynchronous agreement" via a new stateful Agreement life-cycle. A. Agreements get a new life-cycle state "Pending" which means that an offer has been made but no obligations are in effect yet. The term-level status is undefined at this point. B. Agreements get a new life-cycle state "Rejected" which means that the offer was rejected and no obligations will ever be in effect. C. Agreements get a new life-cycle state "Observed" which means that an offer has been accepted and all obligations are in effect. The term-level status is meaningful at this point. This state captures the semantics of the entire lifespan of the Dec 2004 draft (module the confusion around termination). 1. The life-cycle model includes transitions Pending->Observed and Pending->Rejected but NOT Observed->Rejected. 2. Additional states may be warranted to try to resolve the many questions surrounding "termination" and "expiration." D. The existing createAgreement operation remains as an interaction where an input offer initiates a synchronous acceptance decision; the response is either a fault for rejection or an EPR to an Agreement that MUST already be in the Observed state. 1. The optional initiatorAgreement EPR is retained but the responder is under no obligation to invoke anything on this service. It is an optional avenue for the responder to monitor the "initiator's view" of their agreement. (And to attempt to initiate other control processes?) E. An optional AgreementAcceptance portType is introduced with two operations: acceptAgreement and rejectAgreement. 1. Both operations accept an empty input, as the association with an agreement is implicit via the WSRF addressing model. 2. An optional fault might be useful on rejectAgreement input to communicate why the offer was rejected? 3. These operations are only meaningful when the AgreementAcceptance service is in a Pending state. The operations synchronously change the service state to Observed or Rejected, respectively. 4. The AgreementAcceptance and Agreement portTypes may be merged to form a single service interface, and the state is shared between them. (What is the right way to do this in WSDL? Provide portType combinations in specification?) F. A new createPendingAgreement operation is introduced where an input offer initiates an asynchronous acceptance decision; the response is either a fault (fatal errors/rejection) or an EPR to an Agreement that MAY be in Pending, Observed, or Rejected state. 1. The responder MUST update its state RP to either Observed or Rejected following its decision. 2. The initiator MAY use alternate mechanisms to determine if and when the Agreement transfers to Observed, including but not limited to the querying of a state RP. Until the initiator determines the state as changed to Observed or Rejected, it SHOULD NOT assume the outcome. 3. An optional initiatorAcceptance EPR MAY appear in the input message, in which case the responder MUST invoke acceptAgreement or rejectAgreement to communicate its decision, in addition to updating its state RP. 4. An optional initiatorAgreement EPR MAY appear as in createAgreement. This EPR MAY be the same as the initiatorAcceptance EPR, if the service implements both interfaces. 5. Should the output allow an optional state indicator? I think it is simpler to say "no" and uniformly assume an interaction after creation. G. Topic "Changing Offers" is resolved as the input offer is accepted or rejected WITHOUT MODIFICATION by the agreement acceptance decision. Because of this, no response Agreement document is required in any of the above mechanisms. 1. Should there be an optional mechanism to retrieve the agreement document from the responder in such a way that it MAY be signed or otherwise held as proof of acceptance for auditing purposes? If so, does a queryable "agreement RP" satisfy this need? karl -- Karl Czajkowski karlcz(a)univa.com

2 9

composition/extension model for states?
by Karl Czajkowski 22 Mar '05

22 Mar '05

In both the term-level and my newly proposed agreement-level states, there is a modeling concern as to whether domain-specific or community-specific extensions of the state model are allowed. 1. [I do not like:] allowing arbitrary new states to replace existing states in the basic machine, e.g. the state machine can be in "no state" according to a basic client/observer who doesn't recognize extended states. 2. Allow "sub-states" which turn the basic state machine into a hyphergraph where specialized state transfers can happen "within" a generic state but transition rules between super states should be respected still. A. Encode sub-states as extensibility content within the basic state elements, meaning document structure follows the generic rules and extra content "flickers" within that structure. This approach can be applied recursively to extend extensions! B. Encode sub-states as sibling RPs to the basic state elements. This allows stacking/mixing of multiple state models but any consistency model between the various RPs is left unaddressed. C. Hybrid of (A) and (B) where basic non-extended content remains and a new extended variant is places alongside. This avoids the consistency issue of having to inspect both generic and specialized RPs, and also avoids requiring basic clients to filter or "project" extended states down to the base version they recognize. Do we have a clear consensus on which approach is advocated for WS-Agreement? I think extended states will be important both to address domain-specific things like "job states" as well as to compose with negotiation systems in the future. Thoughts? karl -- Karl Czajkowski karlcz(a)univa.com

1 0

terminal fault type
by Karl Czajkowski 22 Mar '05

22 Mar '05

I think we can safely remove the terminal fault type from the appendix. It is a leftover from the negotiation interface when we were perhaps trying to be too sophisticated. The idea was to be able to distinguish to kinds of fault when invoking against a stateful resource: 1) the usual kind, which means the operation failed 2) terminal kind, which means not only did it fail, but you broke the resource permanently :-) This can be handled by returning the regular kind of fault and then finding that there is a "resource unknown" fault on a future invocation, just like if the resource terminates asynchronously. We did suggest this topic to the WSRF folks and they didn't seem to make it a priority. I don't see why we should either. karl -- Karl Czajkowski karlcz(a)univa.com

1 0