From t-nakata at cw.jp.nec.com Mon Feb 7 22:30:54 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Tue, 08 Feb 2005 13:30:54 +0900 Subject: [graap-wg] Comment List In-Reply-To: References: Message-ID: <4208407E.1010409@cw.jp.nec.com> Hi: In today's telecon, someone mentioned that we need to have an id of the comments to keep track. I've made a simple excel sheet with the entries. I'll post in html in case of viruses. If any one needs them, I can send the original .xls file. Best Regards Toshi -- We have moved to a new Office!! Toshiyuki Nakata ????? Internet System Laboratories NEC t-nakata at cw.jp.nec.com 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60210) Fax +81-44-431-7681 (NEC Internal 22-60219) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050208/e6c3386d/attachment.htm From t-nakata at cw.jp.nec.com Wed Feb 9 20:32:05 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Thu, 10 Feb 2005 11:32:05 +0900 Subject: [graap-wg] Comment List In-Reply-To: <4208407E.1010409@cw.jp.nec.com> References: <4208407E.1010409@cw.jp.nec.com> Message-ID: <420AC7A5.3010004@cw.jp.nec.com> Jon has made a number of new entries. So have updated the list. (We now have 19 entries.) Best regards Toshi Toshiyuki Nakata wrote: > Hi: In today's telecon, someone mentioned that > we need to have an id of the comments to keep track. > > I've made a simple excel sheet with the entries. > > I'll post in html in case of viruses. If any one needs them, > I can send the original .xls file. > > Best Regards > Toshi -- We have moved to a new Office!! Toshiyuki Nakata ????? Internet System Laboratories NEC t-nakata at cw.jp.nec.com 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60210) Fax +81-44-431-7681 (NEC Internal 22-60219) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050210/d9165b25/attachment.htm From t-nakata at cw.jp.nec.com Wed Feb 9 20:35:34 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Thu, 10 Feb 2005 11:35:34 +0900 Subject: [graap-wg] Comment List In-Reply-To: <420AC7A5.3010004@cw.jp.nec.com> References: <4208407E.1010409@cw.jp.nec.com> <420AC7A5.3010004@cw.jp.nec.com> Message-ID: <420AC876.9090509@cw.jp.nec.com> Had aduplicate entry. Apologies Toshiyuki Nakata wrote: > Jon has made a number of new entries. > So have updated the list. > (We now have 19 entries.) 18. > > > Best regards > Toshi > > Toshiyuki Nakata wrote: > >> Hi: In today's telecon, someone mentioned that >> we need to have an id of the comments to keep track. >> >> I've made a simple excel sheet with the entries. >> >> I'll post in html in case of viruses. If any one needs them, >> I can send the original .xls file. >> >> Best Regards >> Toshi > > > -- We have moved to a new Office!! Toshiyuki Nakata ????? Internet System Laboratories NEC t-nakata at cw.jp.nec.com 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60210) Fax +81-44-431-7681 (NEC Internal 22-60219) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050210/a39f336d/attachment.htm From takuya_araki at mua.biglobe.ne.jp Wed Feb 9 23:05:04 2005 From: takuya_araki at mua.biglobe.ne.jp (Takuya Araki (Biglobe)) Date: Thu, 10 Feb 2005 14:05:04 +0900 Subject: [graap-wg] asynchronous binding Message-ID: <20050210140501.OAXOAC1454A6.587C0C8A@mua.biglobe.ne.jp> 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 From alain at ISI.EDU Thu Feb 10 10:45:44 2005 From: alain at ISI.EDU (alain at ISI.EDU) Date: Thu, 10 Feb 2005 08:45:44 -0800 Subject: [graap-wg] asynchronous binding Message-ID: <1108053944.420b8fb8e8e3f@webmail.isi.edu> A few excerpts: >From WS-Addressing 08/2004 --------------------------- (http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/) Some processors may use message identifiers () 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/html/wsaddressdelta.asp) 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/wsgram/user/#submissionid) 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 > From pruyne at hpl.hp.com Thu Feb 10 12:14:27 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Thu, 10 Feb 2005 10:14:27 -0800 Subject: [graap-wg] [Fwd: [ogsa-wg] Basic EMS BOF] Message-ID: <420BA483.6050100@hpl.hp.com> 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 -------- Original Message -------- Subject: [ogsa-wg] Basic EMS BOF Date: Thu, 10 Feb 2005 11:36:38 +0900 From: Hiro Kishimoto To: 'OGSA-WG' Andrew's email bounced. ---- Hiro Kishimoto From: "Andrew Grimshaw" To: Subject: Basic EMS BOF Date: Wed, 9 Feb 2005 11:52:37 -0500 All, As discussed I am proposing a BOF to be held in Korea. Below is the one paragraph description I will send to Stacey and Bill Nitzberg. I am also working on a DRAFT charter, and will, of course, send that around as well. Please comment on the below in the next 24 hours. The one paragraph proposal needs to be in by Friday - the draft charter does not. The charter will spell it out in more detail, and include proposed work product and timelines. A DRAFT of the charter will be ready by the F2F. BOF proposal: Proposed Working Group Name: OGSA Basic Execution Services - OGSA-BES The OGSA Execution Management Services (EMS) design team has developed as part of the OGSA V1 document a draft set of EMS services to support a wide range of use-cases. The objective of the proposed OGSA-BES working group is to focus on a minimal sub-set of the EMS services and develop a recommendations document (i.e., specification) for them. The working group will work closely with the OGSA WG, the JSDL working group, and others as necessary. Proposed working group chairs: Mark Morgan University of Virginia Steve Newhouse Southampton University -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050210/b5cc83a4/attachment.htm From karlcz at univa.com Thu Feb 10 12:40:31 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Thu, 10 Feb 2005 10:40:31 -0800 Subject: [graap-wg] [Fwd: [ogsa-wg] Basic EMS BOF] In-Reply-To: <420BA483.6050100@hpl.hp.com> References: <420BA483.6050100@hpl.hp.com> Message-ID: <20050210184031.GA9554@isi.edu> 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 at univa.com From Wolfgang.Ziegler at scai.fraunhofer.de Thu Feb 10 15:12:39 2005 From: Wolfgang.Ziegler at scai.fraunhofer.de (Wolfgang Ziegler) Date: Thu, 10 Feb 2005 22:12:39 +0100 Subject: [graap-wg] notes/minutes from 2/7/05 teleconference Message-ID: <420BCE47.4070700@scai.fraunhofer.de> 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" -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: minutes Feb 7 2005.txt Url: http://www.ogf.org/pipermail/graap-wg/attachments/20050210/16f44480/attachment.txt From hiro.kishimoto at jp.fujitsu.com Fri Feb 11 00:41:12 2005 From: hiro.kishimoto at jp.fujitsu.com (Hiro Kishimoto) Date: Fri, 11 Feb 2005 15:41:12 +0900 Subject: [graap-wg] [Fwd: [ogsa-wg] Basic EMS BOF] In-Reply-To: <20050210184031.GA9554@isi.edu> Message-ID: <014e01c51004$ae48b000$57d5190a@ORD> Many thanks Karl, I am pretty sure your attendance helps this charter BoF come out well. GT 4.0 GRAM, WS-Agreement, and JSDL are key technologies for this. See you in Seoul. ---- Hiro Kishimoto > -----Original Message----- > From: owner-graap-wg at ggf.org [mailto:owner-graap-wg at ggf.org] On Behalf Of Karl > Czajkowski > Sent: Friday, February 11, 2005 3:41 AM > To: Jim Pruyne > Cc: GRAAP-WG > Subject: Re: [graap-wg] [Fwd: [ogsa-wg] Basic EMS BOF] > > 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 at univa.com > From takuya_araki at mua.biglobe.ne.jp Mon Feb 14 04:53:40 2005 From: takuya_araki at mua.biglobe.ne.jp (Takuya Araki (Biglobe)) Date: Mon, 14 Feb 2005 19:53:40 +0900 Subject: [graap-wg] asynchronous binding In-Reply-To: <1108053944.420b8fb8e8e3f@webmail.isi.edu> Message-ID: <20050214195332.TACLAC1454A6.587C0C8A@mua.biglobe.ne.jp> Alain, Karl: Thank you for the excerpts! So Karl, let me confirm your opinion: Are you thinking of using the method which is implemented in WS-GRAM? If so, I agree with that it increases the reliability of the system, but it doesn't seem to be able to replace asynchronous operations completely. What it does is: * Give a unique message ID to a (synchronous) message * In case of trouble, the client can re-send the same message using the same message ID It surely increases the reliability of the system, but it is for synchronous operations; it wouldn't be suitable for operations which take a long time. In such a case, a client can't tell if there are some network/server problems, or it is normal and just taking a long time; they should be treated differently. For example, if there might be some network/server problems, it might be desirable to inform that to the user; on the other hand, if it is normal and just taking a long time, it shouldn't be informed to the user. In addition, it only supports "polling", which causes more overhead than "callback" method. (By the way, it seems that GRAM has "batch mode" as an application level asynchronous operation. That's why the current method is enough for GRAM, I think.) Comments? -- Takuya Araki Grid System Technology Group Internet Systems Research Laboratories NEC Corporation -----Original Message----- From: owner-graap-wg at ggf.org [mailto:owner-graap-wg at ggf.org] On Behalf Of alain at ISI.EDU Sent: Friday, February 11, 2005 1:46 AM To: takuya_araki at mua.biglobe.ne.jp Cc: graap-wg at gridforum.org Subject: Re:[graap-wg] asynchronous binding A few excerpts: >From WS-Addressing 08/2004 --------------------------- (http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/) Some processors may use message identifiers () 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/html/wsaddressdelta.asp) 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/wsgram/user/#submissionid) 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 > From nakata at mtg.biglobe.ne.jp Mon Feb 14 06:35:59 2005 From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata) Date: Mon, 14 Feb 2005 21:35:59 +0900 Subject: [graap-wg] next teleconference In-Reply-To: <41FDEB42.1060801@hpl.hp.com> References: <41FDEB42.1060801@hpl.hp.com> Message-ID: <42109B2F.8030602@mtg.biglobe.ne.jp> Hi: I am expecting another telecon in 10 hours or so. If not, please do reply to say no. I've setup my alarm clock @ 6:30 and hope that I'd be able to wake up... Best Regards Toshi Jim Pruyne wrote: > 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 > > > > > -- Toshiyuki Nakata t-nakata at cw.jp.nec.com +81-44-431-7653 (NEC Internal 8-22-60210) From karlcz at univa.com Mon Feb 14 13:39:01 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Mon, 14 Feb 2005 11:39:01 -0800 Subject: [graap-wg] asynchronous binding In-Reply-To: <20050214195332.TACLAC1454A6.587C0C8A@mua.biglobe.ne.jp> References: <1108053944.420b8fb8e8e3f@webmail.isi.edu> <20050214195332.TACLAC1454A6.587C0C8A@mua.biglobe.ne.jp> Message-ID: <20050214193901.GD28310@isi.edu> On Feb 14, Takuya Araki (Biglobe) loaded a tape reading: > Alain, Karl: > > Thank you for the excerpts! > > So Karl, let me confirm your opinion: > Are you thinking of using the method which is implemented in WS-GRAM? > If so, I agree with that it increases the reliability of the system, > but it doesn't seem to be able to replace asynchronous operations completely. > Yes, that is my suggestion and no I do not completely agree with your assessment... I am attaching a longer description of my position which was drafted as part of a different activity. I think it addresses this topic well enough so I will only paste it and then add a few more comments specifically about WS-Agreement. I apologize for the length. RELIABILITY: One issue that arises in job management is the potentially high stakes of errors in the management protocol. Specifically, while a client may well be expected to tolerate rejection and even execution failure, it is undesireable to have job management state "disappear" or get duplicated due to message-layer, client, or provider failures. We assert that the simple creation pattern is sufficient because there are multiple binding options available to get reliability. One approach is to have transactional bindings which use commit and rollback to make sure a creation occurs exactly once or not at all. However, not all Internet deployments will have transactional messaging, so another approach is to use WS-Addressing MessageID header to get idempotent invocation. This mechanism allows the client to resend an application message in case it missed the response message, and the provider must resend the response without duplicating actions such as actual execution. This "at most once" semantics is sufficient for real world EMS scenarios, as the client will eventually learn whether the execution was accepted or not. GT 4.0 GRAM optionally uses a proprietary message-level concept that is equivalent to the WS-Addressing MessageID in order to work across any binding and because it was designed before the WS-Addressing mechanism was fully clarified by its authors. In this variant, the idempotent ID is sent as an extra field in the input message and interpreted early in the request processing to avoid duplication. The idempotent operation style optimizes the success case by not requiring additional message exchanges unless there is an error condition or timeout. In contrast, a transactional approach requires more exchanges to setup and commit (or cancel) the invocation. ASYNCHRONY: Another concern is how much delay may be encountered in the creation pattern. The WS architecture makes no statements about the relative duration of an "in-out" message exchange, as that is essentially a binding issue. Two camps seem to dislike long message delays for different reasons which are both somewhat inconsistent with the WS architecture model. First, one camp confuses the WSDL message protocol with an API specification, so they believe that a WSDL "in-out" message must mean a blocking procedure call in their client bindings. They are uncomfortable with the implication that a long delay cannot be processed asynchronously by their application. We believe this is a mistaken viewpoint to take when designing protocols, because the asynchrony of the client can be addressed simply by using an appropriate tooling strategy. They should move to better tooling if their existing client stubs are indeed this limiting. For example, the C language WS tooling in GT 4.0 generates synchronous and asynchronous stubs for each WSDL operation, so our GT 4.0 GRAM client tool is able to perform the creation message exchange using asynchronous "post message" and "response callback" programmatic interfaces. The newest JAX RPC revision also is said to have better support for asynchronous invocation. The second dissenting camp is concerned that long response delays will be fragile because some bindings cannot tolerate the delay. For example, a SOAP over HTTP binding may not be able to wait long enough for a response before the TCP connection is lost. Because an "in-out" message pattern addresses the response implicitly via binding-level context, it is not as durable as an explicit peer-to-peer message exchange using "in only" messages sent to explicit endpoints at both peer sites. Unfortunately, this style is also difficult in constrained binding environments because SOAP over HTTP is often valued specifically for being asymmetric and allowing simple NAT/firewall traversal from "anonymous" clients to well-known providers. If we render a peer-to-peer interface model in order to support fragile bindings, we create obstacles for these other common deployment environments. [Please note, WS-Agreement is meant to support this peer-to-peer pattern optionally, but I admit that we may need to make some technical cleanup on the spec before completion... it seems to have lost some details in the time I have been absent from the workgroup discussions. See the optional initiator's EPR field in the create call. What is missing, I think, is clear normative text on how this will be used by the responding party and how/if it should appear in the Agreement context for correlative purposes.] A third solution which happens to address both camps simultaneously is to render explicit "post" and "poll" interfaces to initiate the logical operation and then hold the response at the provider until the client can reconnect and retrieve the result. This supports fragile bindings in NAT/firewall environments and also yields an asynchronous interface with naive tooling that generates synchronous stubs for "in out" message exchanges. However, it complicates the application-level modelling and lifts transport-level message buffering into the application-level service implementation. We argue that a simple "in-out" message exchange in combination with idempotent ID mechanisms can equally well satisfy the fragile bindings and NAT/firewall asymmetry without significant impact on the application protocol. It still retains state at the provider, but rather than adding post/poll operations to the WSDL it simply uses message send for "post" and message resend for "poll". This also means that the application logic can be written using the more natural "in-out" pattern and a simple buffering layer at (or slightly above) the binding code can handle the resends at the provider. This model supports asynchrony because the polling exchange can "block" at the messaging level until the binding times out. In other words, a client who logically iterates with: ID = new_identifier while is_non_response ( result = EPR->create(ID, input content) ) repeat will not "spin" but rather post a new copy of the idempotent create message at the frequency at which the binding signals an error, e.g. a closed connection. While the binding is still functioning, the underlying protocol such as SOAP over HTTP will provide for asynchronous delivery of the response message. (Note of course that the above snippet could be written in a longer psuedo-code format by using an asynchronous post/callback model such as we use in GT4 C bindings. The sychronous create call is nothing more than a post followed by a conditional wait on the callback monitor.) This approach does not permit visibility as to WHY the response is taking so long, but merely visibility as to WHETHER the response has been issued yet. There is no lifecycle model in WS-Agreement for the decision making that the Agreement provider performs while considering an Agreement creation request, nor should we take lightly the burden of trying to develop such a model. > (By the way, it seems that GRAM has "batch mode" as an application level asynchronous operation. > That's why the current method is enough for GRAM, I think.) > No, actually our "globusrun" tool's batch mode is not about asynchronous submission. It simply turns off the subscription and state monitoring that the tool normally does after submission. The submission step itself is roughly equivalent to the WS-Agreement createAgreement operation. karl -- Karl Czajkowski karlcz at univa.com From t-nakata at cw.jp.nec.com Wed Feb 16 00:53:14 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Wed, 16 Feb 2005 15:53:14 +0900 Subject: [graap-wg] Updated Comment list: In-Reply-To: <20050214193901.GD28310@isi.edu> References: <1108053944.420b8fb8e8e3f@webmail.isi.edu> <20050214195332.TACLAC1454A6.587C0C8A@mua.biglobe.ne.jp> <20050214193901.GD28310@isi.edu> Message-ID: <4212EDDA.2000809@cw.jp.nec.com> Hello, I've updated the comments list to reflect Monday?Tuesday's discussion and additional comments. Please understand that the Resolution/Discussion is a temporary one and I will update it when I read the minutes. (It was rather difficult to follow wome of the discussions.) Please also understand that this table is just for making discussion on the telecon easier. It is not meant to be the response to the original posts, which I think was agreed to be done by posting to the GridForum forge Web page.. (I don't remember people being assigned to this job on the telecon though..) Best Regards Toshi -- We have moved to a new Office!! Toshiyuki Nakata ????? Internet System Laboratories NEC t-nakata at cw.jp.nec.com 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60210) Fax +81-44-431-7681 (NEC Internal 22-60219) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050216/276892a5/attachment.htm From takuya_araki at mua.biglobe.ne.jp Wed Feb 16 09:44:30 2005 From: takuya_araki at mua.biglobe.ne.jp (Takuya Araki (Biglobe)) Date: Thu, 17 Feb 2005 00:44:30 +0900 Subject: [graap-wg] asynchronous binding In-Reply-To: <20050214193901.GD28310@isi.edu> Message-ID: <20050217004432.AAFMC0A82785.6401CA41@mua.biglobe.ne.jp> Karl: Thank you for your comment. Here is summary of my understandings: * I agree with that the asynchronous operations should be implemented at the binding level if there are proper tools. - Here, you think there are such tools - My opinion is currently available tools are not enough for this purpose * Your suggestion is to implement asynchrony by "polling"; "message ID" of WS-Addressing can be used to know the uniqueness of the message (, which corresponds to "correlation ID" of my proposal) The difference from the polling method of my proposal is: - It is not visible on WSDL level (so there is no impact on the spec) - On the transport level, it uses a normal synchronous operation; when it timeouts, the same message is sent using the same massage ID again. - Here, your opinion is this suggestion solves the problem. - My opinion is this is useful, but might not be enough to handle time consuming agreement creation. I understand your opinion that this kind of "implementation issue" should not affect the specification. However, I feel it is in the future that proper tools solves the problem completely. Therefore, I believe that the WSDL level solution is useful to implement practical systems using currently available tools. My proposal is perfectly optional, and can be safely ignored if you don't like it. Some other comments are in line: >... > First, one camp confuses the WSDL message protocol with an > API specification, so they believe that a WSDL "in-out" > message must mean a blocking procedure call in their client > bindings. They are uncomfortable with the implication that a > long delay cannot be processed asynchronously by their > application. We believe this is a mistaken viewpoint to take > when designing protocols, because the asynchrony of the > client can be addressed simply by using an appropriate > tooling strategy. > > They should move to better tooling if their existing client > stubs are indeed this limiting. For example, the C language > WS tooling in GT 4.0 generates synchronous and asynchronous > stubs for each WSDL operation, so our GT 4.0 GRAM client tool > is able to perform the creation message exchange using > asynchronous "post message" and "response callback" > programmatic interfaces. The newest JAX RPC revision also is > said to have better support for asynchronous invocation. Are you talking here about API level asynchrony? If so, API level asynchrony is also important, but what we are discussing is transport level asynchrony, I think. (I checked the recent version of JAX RPC spec. It says it supports "a client level asynchrony", but I couldn't figure out if it also supports transport level asynchrony...) > ... > This approach does not permit visibility as to WHY the > response is taking so long, but merely visibility as to > WHETHER the response has been issued yet. There is no > lifecycle model in WS-Agreement for the decision making that > the Agreement provider performs while considering an > Agreement creation request, nor should we take lightly the > burden of trying to develop such a model. Sorry, I couldn't catch the point of these sentences. Are you saying that the WSDL level asynchronous operations should manage some kind of lifecycle model in the provider? If so, well, I admit that there is something which should be done in the application level... > > (By the way, it seems that GRAM has "batch mode" as an > application level asynchronous operation. > > That's why the current method is enough for GRAM, I think.) > > No, actually our "globusrun" tool's batch mode is not about > asynchronous submission. It simply turns off the > subscription and state monitoring that the tool normally does > after submission. The submission step itself is roughly > equivalent to the WS-Agreement createAgreement operation. Sorry about the misunderstanding. But my point is that GRAM does not use time consuming operations, which seems to be why the current method is enough for GRAM... My concern about using your suggestion for operations which take a long time is as follows: * As I mentioned in the previous mail, a client program can't distinguish timeout caused by message layer problems; it just thinks that the operation is taking a long time, and might retry forever. * The server should keep the HTTP connection for the long period, (though the connection is disconnected and reconnected periodically). That might be intolerably high overhead for the server, if there are a lot of agreement creation requests. (Usually, there is a limit of number of HTTP connection.) -- Takuya Araki Grid System Technology Group Internet Systems Research Laboratories NEC Corporation From t-nakata at cw.jp.nec.com Fri Feb 18 03:36:50 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Fri, 18 Feb 2005 18:36:50 +0900 Subject: [graap-wg] Updated**2 Comment list: In-Reply-To: <4212EDDA.2000809@cw.jp.nec.com> References: <1108053944.420b8fb8e8e3f@webmail.isi.edu> <20050214195332.TACLAC1454A6.587C0C8A@mua.biglobe.ne.jp> <20050214193901.GD28310@isi.edu> <4212EDDA.2000809@cw.jp.nec.com> Message-ID: <4215B732.9020703@cw.jp.nec.com> Hi: I've updated the list to reflect lots of new comments.. Best Regards Toshi -- We have moved to a new Office!! Toshiyuki Nakata ????? Internet System Laboratories NEC t-nakata at cw.jp.nec.com 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60210) Fax +81-44-431-7681 (NEC Internal 22-60219) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050218/a98f00eb/attachment.htm From karlcz at univa.com Sat Feb 19 20:44:14 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Sat, 19 Feb 2005 18:44:14 -0800 Subject: [graap-wg] asynchronous binding In-Reply-To: <20050217004432.AAFMC0A82785.6401CA41@mua.biglobe.ne.jp> References: <20050214193901.GD28310@isi.edu> <20050217004432.AAFMC0A82785.6401CA41@mua.biglobe.ne.jp> Message-ID: <20050220024414.GA10531@isi.edu> On Feb 17, Takuya Araki (Biglobe) loaded a tape reading: > Karl: > > Thank you for your comment. > > Here is summary of my understandings: > > * I agree with that the asynchronous operations should be > implemented at the binding level if there are proper tools. > - Here, you think there are such tools > - My opinion is currently available tools are not enough for this purpose > > * Your suggestion is to implement asynchrony by "polling"; > "message ID" of WS-Addressing can be used to know the uniqueness > of the message (, which corresponds to "correlation ID" of my proposal) > The difference from the polling method of my proposal is: > - It is not visible on WSDL level (so there is no impact on the spec) > - On the transport level, it uses a normal synchronous operation; > when it timeouts, the same message is sent using the same massage ID again. > > - Here, your opinion is this suggestion solves the problem. > - My opinion is this is useful, but might not be enough to handle time consuming > agreement creation. > > I understand your opinion that this kind of "implementation issue" should not > affect the specification. However, I feel it is in the future that proper tools > solves the problem completely. Therefore, I believe that the WSDL level solution > is useful to implement practical systems using currently available tools. > > My proposal is perfectly optional, and can be safely ignored if you don't like it. > I agree with your summary. I have a question: would the binding-level method I propose be satisfactory for the asymmetric (no initiator-side endpoints) case? What I propose is that we leave the current model more or less untouched and focus on reintroducing/repairing the symmetric peer-to-peer creation mechanism to address asynchrony at the WSDL level. I went through the public draft very carefully on a long flight the other day and realize there are a number of problems relating to the underspecification and inconsistency of the symmetric case. The creation input's optional "initiator EPR" is useless as the spec stands! I think some related state information was removed in the effort to get rid of negotiation, and this part was overlooked. I am not 100% sure how much overlap there is between this and your proposal, so let me phrase it in terms of adjustments to the public draft that I have been reading: 1) Remove the optional "initiator EPR" from the createAgreement() input. The simple createAgreement() is always asymmetric. 2) Introduce a new FOO() operation which has a mandatory "acceptance EPR" field along with the offer and which outputs an empty message (ACK) or fault. A fault indicates that the offer cannot be considered, e.g. the initiator should not expect any further messages regarding this offer. 3) The acceptance EPR must address an endpoint providing two new operations: -- acceptAgreement() which takes as input the EPR to the newly formed Agreement provided by responder, e.g. the same EPR that would have appeared in the simple createAgreement output -- rejectAgreement() operation which takes a fault as input, e.g. the same fault that would have appeared in the simple createAgreement output 4) the responder MUST drive the acceptAgreement() operation on the acceptance EPR to accept, or the rejectAgreement() operation to reject, once he has made his decision. I think this is in the spirit of the original spec drafts and the whole idea of symmetric parties. To make it completely symmetric: 5) the acceptAgreement() operation outputs the EPR of an Agreement provided by the initiator, allowing both parties to know an Agreement EPR hosted by the other party to which further Agreement-related operations can be directed. This becomes an underpinning for future extensions where the parties can signal more interesting Agreement conditions/changes to one another. I called it "Foo()" above because the naming depends on what is decided for this last feature. I would call it createSymmetricAgreement if we included (5). I would call it something like requestAgreement if we do (1)-(4) only. I continue to be uncomfortable using the words "synchronous" or "asynchronous" to name message patters because they are always asynchronous in the WS architecture. I think synchrony only makes sense when talking about APIs where control is passed from one piece of code to another. > Are you talking here about API level asynchrony? I am stating that some recurring discussions come from people trying to address API-level concerns in the WSDL instead of in the tooling where they belong. I was not sure if you were stating any of these arguments or not. > If so, API level asynchrony is also important, but what we are > discussing is transport level asynchrony, I think. > Good, I think we are on the same page then. > (I checked the recent version of JAX RPC spec. > It says it supports "a client level asynchrony", but I couldn't > figure out if it also supports transport level asynchrony...) > It's an API concern, which is why I brought it up as a response to those trying to address API asynchrony. Of course, transport asynchrony depends on binding protocol rather than a WSDL->API translation scheme. > > ... > > This approach does not permit visibility as to WHY the > > response is taking so long, but merely visibility as to > > WHETHER the response has been issued yet. There is no > > lifecycle model in WS-Agreement for the decision making that > > the Agreement provider performs while considering an > > Agreement creation request, nor should we take lightly the > > burden of trying to develop such a model. > > Sorry, I couldn't catch the point of these sentences. > Are you saying that the WSDL level asynchronous operations > should manage some kind of lifecycle model in the provider? > If so, well, I admit that there is something which should be done > in the application level... > No, I was merely trying to state that we would have to consider what we are doing if we introduced some two-level factory scheme, e.g. an initial "lightweight" factory create call that returns the EPR of a new "pending request" resource which the client can poll to find the eventual "accepted agreement" EPR. I don't think this would be that much more powerful than the binding-level solution I have promoted, and it opens the can of worms as to what is the lifecycle of a "pending request". Another way of rendering this two-level scheme would be to just return the Agreement EPR in a new enhanced lifecycle where it has not been accepted yet. An asynchronous state-change can indicate whether it is accepted or rejected once the provider knows. This is pretty much what our original state machine model looked like before we factored out negotiation. :-) It also happens to be what GRAM does today. :-( > Sorry about the misunderstanding. > But my point is that GRAM does not use time consuming > operations, which seems to be why the current method is enough for GRAM... > I suppose you may be right. We have not done much testing with long creation delays, because our current GRAM submission semantics are not exactly analogous to Agreement. > My concern about using your suggestion for operations which take a long time > is as follows: > * As I mentioned in the previous mail, a client program can't distinguish timeout > caused by message layer problems; it just thinks that the operation is > taking a long time, and might retry forever. > > * The server should keep the HTTP connection for the long period, > (though the connection is disconnected and reconnected periodically). > That might be intolerably high overhead for the server, if there are a lot of > agreement creation requests. (Usually, there is a limit of number of HTTP > connection.) I had not really considered that holding HTTP connections open would be a scalability problem... I know most browsers do it by default these days and I assume binding-level technology will be improved as needed as the WS methodology matures. But I will accept that it could be a practical limit today. Would a corrected version of the symmetric agreement mechanism satisfy your needs here, or do you also still feel that a two-phase creation mechanism must be available for asymmetric initiators who will not host any WS-Agreement related endpoints? karl -- Karl Czajkowski karlcz at univa.com From karlcz at univa.com Sun Feb 20 21:29:52 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Sun, 20 Feb 2005 19:29:52 -0800 Subject: [graap-wg] asynchronous binding In-Reply-To: <20050220024414.GA10531@isi.edu> References: <20050214193901.GD28310@isi.edu> <20050217004432.AAFMC0A82785.6401CA41@mua.biglobe.ne.jp> <20050220024414.GA10531@isi.edu> Message-ID: <20050221032952.GA2624@isi.edu> On Feb 19, Karl Czajkowski loaded a tape reading: ... > > Would a corrected version of the symmetric agreement mechanism satisfy > your needs here, or do you also still feel that a two-phase creation > mechanism must be available for asymmetric initiators who will not > host any WS-Agreement related endpoints? > > > karl > While waiting for a response, I dug back in my email archive and found this comment from Takuya on 1 Dec 2004: I added asynchronous request operations (e.g. createAgreementAsync), polling operations for getting the result (e.g. createAgreementGetResult), and response operations (e.g. createAgreementResult). Please see the attached document for detail. It also includes some minor comments to the original specification. but unfortunately my archive does not retain the Word document attachment, so I cannot review the specific changes. (Does anyone know of a public archive where I can easily retrieve such GRAAP messages with attachments?) Just based on the above summary, I would say that I am proposing we drop the createAgreementGetResult operation in favor of an equivalent binding-level behavior to reliably get (or "re-get" by polling) the result of the existing createAgreement call in case it takes too long for the baseline bindings. I am also proposing that we attempt to incorporate his notion of a "reverse direction" createAgreementResult operation (which I separated as acceptAgreement and rejectAgreement) into a repair for the now underspecified and broken symmetric agreement pattern. Does anybody else have opinions on these issues? Will there be a GRAAP call today (Monday 20 Feb)? karl -- Karl Czajkowski karlcz at univa.com From hiro.kishimoto at jp.fujitsu.com Sun Feb 20 21:45:23 2005 From: hiro.kishimoto at jp.fujitsu.com (Hiro Kishimoto) Date: Mon, 21 Feb 2005 12:45:23 +0900 Subject: [graap-wg] asynchronous binding In-Reply-To: <20050221032952.GA2624@isi.edu> Message-ID: <004e01c517c7$c5f5fad0$57d5190a@ORD> Karl, hope it helps, > attachment, so I cannot review the specific changes. (Does anyone know > of a public archive where I can easily retrieve such GRAAP messages > with attachments?) http://www-unix.gridforum.org/mail_archive/graap-wg/threads.html And his message is; http://www-unix.gridforum.org/mail_archive/graap-wg/2004/11/msg00004.html ---- Hiro Kishimoto > -----Original Message----- > From: owner-graap-wg at ggf.org [mailto:owner-graap-wg at ggf.org] On Behalf Of Karl > Czajkowski > Sent: Monday, February 21, 2005 12:30 PM > To: Takuya Araki (Biglobe) > Cc: graap-wg at gridforum.org > Subject: Re: [graap-wg] asynchronous binding > > On Feb 19, Karl Czajkowski loaded a tape reading: > ... > > > > Would a corrected version of the symmetric agreement mechanism satisfy > > your needs here, or do you also still feel that a two-phase creation > > mechanism must be available for asymmetric initiators who will not > > host any WS-Agreement related endpoints? > > > > > > karl > > > > While waiting for a response, I dug back in my email archive and found > this comment from Takuya on 1 Dec 2004: > > I added asynchronous request operations > (e.g. createAgreementAsync), polling operations for getting the > result (e.g. createAgreementGetResult), and response operations > (e.g. createAgreementResult). Please see the attached document for > detail. It also includes some minor comments to the original > specification. > > but unfortunately my archive does not retain the Word document > attachment, so I cannot review the specific changes. (Does anyone know > of a public archive where I can easily retrieve such GRAAP messages > with attachments?) > > Just based on the above summary, I would say that I am proposing we > drop the createAgreementGetResult operation in favor of an equivalent > binding-level behavior to reliably get (or "re-get" by polling) the > result of the existing createAgreement call in case it takes too long > for the baseline bindings. I am also proposing that we attempt to > incorporate his notion of a "reverse direction" createAgreementResult > operation (which I separated as acceptAgreement and rejectAgreement) > into a repair for the now underspecified and broken symmetric > agreement pattern. > > Does anybody else have opinions on these issues? Will there be a > GRAAP call today (Monday 20 Feb)? > > > karl > > -- > Karl Czajkowski > karlcz at univa.com > From pruyne at hpl.hp.com Mon Feb 21 01:11:17 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Sun, 20 Feb 2005 23:11:17 -0800 Subject: [graap-wg] No teleconference on 2/21 Message-ID: <42198995.6080709@hpl.hp.com> 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 From nakata at mtg.biglobe.ne.jp Mon Feb 21 08:19:13 2005 From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata) Date: Mon, 21 Feb 2005 23:19:13 +0900 Subject: [graap-wg] asynchronous binding In-Reply-To: <20050221032952.GA2624@isi.edu> References: <20050214193901.GD28310@isi.edu> <20050217004432.AAFMC0A82785.6401CA41@mua.biglobe.ne.jp> <20050220024414.GA10531@isi.edu> <20050221032952.GA2624@isi.edu> Message-ID: <4219EDE1.8010502@mtg.biglobe.ne.jp> Hi Karl: > but unfortunately my archive does not retain the Word document > attachment, so I cannot review the specific changes. (Does anyone know > of a public archive where I can easily retrieve such GRAAP messages > with attachments?) > Please refer to Section 8.4 in http://www-unix.gridforum.org/mail_archive/graap-wg/2004/11/doc00000.doc which had been refererred from http://www-unix.gridforum.org/mail_archive/graap-wg/2004/11/msg00004.html > Just based on the above summary, I would say that I am proposing we > drop the createAgreementGetResult operation in favor of an equivalent > binding-level behavior to reliably get (or "re-get" by polling) the > result of the existing createAgreement call in case it takes too long > for the baseline bindings. I am also proposing that we attempt to > incorporate his notion of a "reverse direction" createAgreementResult > operation (which I separated as acceptAgreement and rejectAgreement) > into a repair for the now underspecified and broken symmetric > agreement pattern. > > Does anybody else have opinions on these issues? > Will there be a > GRAAP call today (Monday 20 Feb)? From Jim's subsequen mail, probably no.. Best Regards Toshi > > > karl > -- Toshiyuki Nakata t-nakata at cw.jp.nec.com +81-44-431-7653 (NEC Internal 8-22-60210) From karlcz at univa.com Mon Feb 21 23:22:24 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Mon, 21 Feb 2005 21:22:24 -0800 Subject: [graap-wg] asynchronous binding In-Reply-To: <20050221032952.GA2624@isi.edu> References: <20050214193901.GD28310@isi.edu> <20050217004432.AAFMC0A82785.6401CA41@mua.biglobe.ne.jp> <20050220024414.GA10531@isi.edu> <20050221032952.GA2624@isi.edu> Message-ID: <20050222052224.GE10302@isi.edu> On Feb 20, Karl Czajkowski loaded a tape reading: ... > Just based on the above summary, I would say that I am proposing we > drop the createAgreementGetResult operation in favor of an equivalent > binding-level behavior to reliably get (or "re-get" by polling) the > result of the existing createAgreement call in case it takes too long > for the baseline bindings. I am also proposing that we attempt to > incorporate his notion of a "reverse direction" createAgreementResult > operation (which I separated as acceptAgreement and rejectAgreement) > into a repair for the now underspecified and broken symmetric > agreement pattern. > Thanks to all who pointed out that the GGF site does indeed have an archive for the GRAAP-WG mailing list. :-) After reviewing the proposed changes, I think the above comments still stand. The only additional "async" interface proposal was for termination, and I would also suggest dropping that because it is my belief that there is no implication of long delays in this operation. Termination is an inherently asynchronous mechanism by which the client requests termination and finds out if his request is acceptable or not; he does not get some response synchronized to happen "after" termination but he should assume the resource is not to be accessed if the response is successful. This is a point that I think was argued extensively (and convincingly, to me) in the OGSI and WSRF work groups. I actually would question why we have a wsag:Terminate instead of just using the WS-ResourceLifetime mechanism. I cannot see what value it adds or what would be different about the semantics. The text in the Agreement Context section is hardly convincing on this point. :-( Is it supposed to I am afraid I must have been absent during the time when this was decided... karl -- Karl Czajkowski karlcz at univa.com From nakata at mtg.biglobe.ne.jp Tue Feb 22 09:41:31 2005 From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata) Date: Wed, 23 Feb 2005 00:41:31 +0900 Subject: [graap-wg] asynchronous binding In-Reply-To: <20050222052224.GE10302@isi.edu> References: <20050214193901.GD28310@isi.edu> <20050217004432.AAFMC0A82785.6401CA41@mua.biglobe.ne.jp> <20050220024414.GA10531@isi.edu> <20050221032952.GA2624@isi.edu> <20050222052224.GE10302@isi.edu> Message-ID: <421B52AB.2070403@mtg.biglobe.ne.jp> Hi Karl: Just to make sure.. Could you clarify as to whether you agree to we make CreateAgreementAsynch as an optional operation for CreateAgreement? best Regards Toshi Karl Czajkowski wrote: > On Feb 20, Karl Czajkowski loaded a tape reading: > ... > >>Just based on the above summary, I would say that I am proposing we >>drop the createAgreementGetResult operation in favor of an equivalent >>binding-level behavior to reliably get (or "re-get" by polling) the >>result of the existing createAgreement call in case it takes too long >>for the baseline bindings. I am also proposing that we attempt to >>incorporate his notion of a "reverse direction" createAgreementResult >>operation (which I separated as acceptAgreement and rejectAgreement) >>into a repair for the now underspecified and broken symmetric >>agreement pattern. >> > > > Thanks to all who pointed out that the GGF site does indeed have an > archive for the GRAAP-WG mailing list. :-) > > After reviewing the proposed changes, I think the above comments still > stand. The only additional "async" interface proposal was for > termination, and I would also suggest dropping that because it is my > belief that there is no implication of long delays in this operation. > > Termination is an inherently asynchronous mechanism by which the > client requests termination and finds out if his request is acceptable > or not; he does not get some response synchronized to happen "after" > termination but he should assume the resource is not to be accessed if > the response is successful. This is a point that I think was argued > extensively (and convincingly, to me) in the OGSI and WSRF work > groups. > > I actually would question why we have a wsag:Terminate instead of just > using the WS-ResourceLifetime mechanism. I cannot see what value it > adds or what would be different about the semantics. The text in the > Agreement Context section is hardly convincing on this point. :-( > Is it supposed to I am afraid I must have been absent during the time > when this was decided... > > > karl > -- Toshiyuki Nakata t-nakata at cw.jp.nec.com +81-44-431-7653 (NEC Internal 8-22-60210) From hludwig at us.ibm.com Tue Feb 22 09:44:03 2005 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Tue, 22 Feb 2005 10:44:03 -0500 Subject: [graap-wg] asynchronous binding In-Reply-To: <20050222052224.GE10302@isi.edu> Message-ID: Karl, on your issue with termination: > I actually would question why we have a wsag:Terminate instead of just > using the WS-ResourceLifetime mechanism. I cannot see what value it > adds or what would be different about the semantics. The text in the > Agreement Context section is hardly convincing on this point. :-( > Is it supposed to I am afraid I must have been absent during the time > when this was decided... I think we might be mixing semantics. There is a difference between the lifetime of the agreement instance and the state of the agreement instance to be observed. The terminate message is supposed to move the agreement state to afterObserved while the WSRF lifetime addresses how long the Agreement service is supposed to be around. We might argue that thi sshould be the same but, in fact, I tend to think to keep it separate. Heiko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050222/33258725/attachment.html From maclaren at cct.lsu.edu Tue Feb 22 10:13:54 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Tue, 22 Feb 2005 10:13:54 -0600 Subject: [graap-wg] asynchronous binding In-Reply-To: References: Message-ID: <39009f7e45b67d3db67600d9d6b58cb1@cct.lsu.edu> As I've said in one of my comments on the spec, I think that the use of the word "terminate" to refer to the agreement is confusing. In Section 4.1, under /wsag:Context/wsag:ExpirationTime, the term TerminationTime is used to refer to the service lifetime, and ExpirationTime to the end of the agreement. It's inconsistent. (My original opinions on the "terminate agreement" operation still stand, however - I don't think it makes sense at all... But that comment has already been discussed and rejected.) Jon. On Feb 22, 2005, at 9:44 AM, Heiko Ludwig wrote: > > Karl, > > on your issue with termination: > > > I actually would question why we have a wsag:Terminate instead of > just > > using the WS-ResourceLifetime mechanism. ?I cannot see what value it > > adds or what would be different about the semantics. The text in the > > Agreement Context section is hardly convincing on this point. :-( > > Is it supposed to I am afraid I must have been absent during the > time > > when this was decided... > > I think we might be mixing semantics. There is a difference between > the lifetime of the agreement instance and the state of the agreement > instance to be observed. The terminate message is supposed to move the > agreement state to afterObserved while the WSRF lifetime addresses how > long the Agreement service is supposed to be around. We might argue > that thi sshould be the same but, in fact, I tend to think to keep it > separate. > > Heiko From takuya_araki at mua.biglobe.ne.jp Tue Feb 22 11:27:58 2005 From: takuya_araki at mua.biglobe.ne.jp (Takuya Araki (Biglobe)) Date: Wed, 23 Feb 2005 02:27:58 +0900 Subject: [graap-wg] asynchronous binding In-Reply-To: <20050220024414.GA10531@isi.edu> Message-ID: <20050223022759.CAFHC0A82745.6480CA41@mua.biglobe.ne.jp> Karl: Thank you for your comments and new proposal. (And sorry about the late response.) Basically, I agree with your new proposal. * Your requestAgreement, accepctAgreement, rejectAgreement operations are mostly same as my proposal. Its OK for me to change operation names. - Letting acceptAgreement create a new service ( "5)" in your proposal) seems to be a new topic. If you want to include this, it might be better to discuss it as a different topic in the WG. - It is OK to drop async version of the Terminate operation as you mentioned in another mail. I thought that it might be used as "destructor" of the agreement; there might be something like clean-up which takes some time. If there are dependent agreements and they should be also terminated at the time, the whole time might be long. However, your discussion in another mail (terminate operation is inherently asynchronous operation, etc.) seems to be also convincing. (Terminate operation can return immediately if the provider accepts the termination; clean-ups and calling terminate operations of dependent agreement can be executed asynchronously...) Therefore, I agree with dropping async version of Terminate operation. * It's a bit pity to drop WSDL level polling operation :-) (considering scalability, etc.), but if we have request/accept/rejectAgreement operations, they can be used if scalability is important. Some other comments are in line: > ... > No, I was merely trying to state that we would have to > consider what we are doing if we introduced some two-level > factory scheme, e.g. an initial "lightweight" factory create > call that returns the EPR of a new "pending request" resource > which the client can poll to find the eventual "accepted > agreement" EPR. I don't think this would be that much more > powerful than the binding-level solution I have promoted, and > it opens the can of worms as to what is the lifecycle of a > "pending request". > > Another way of rendering this two-level scheme would be to > just return the Agreement EPR in a new enhanced lifecycle > where it has not been accepted yet. An asynchronous > state-change can indicate whether it is accepted or rejected > once the provider knows. This is pretty much what our > original state machine model looked like before we factored > out negotiation. :-) It also happens to be what GRAM does today. :-( Actually, "the EPR of a new pending request resource" is not created in my proposal. The polling method is defined at the factory; to identify the request, I used correlation ID. In this case, it seems to have less lifecycle problem than two-level factory scheme. > Would a corrected version of the symmetric agreement > mechanism satisfy your needs here, or do you also still feel > that a two-phase creation mechanism must be available for > asymmetric initiators who will not host any WS-Agreement > related endpoints? If there are request/accept/rejectAgreement operations, most of my needs can be satisfied, I think. If you still feel uncomfortable about the polling operation I proposed(, though it is not two-level factory scheme), I agree with dropping the polling operation and using the binding level solution instead for the asymmetric case. -- Takuya Araki Grid System Technology Group Internet Systems Research Laboratories NEC Corporation From pruyne at hpl.hp.com Wed Feb 23 17:03:59 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Wed, 23 Feb 2005 15:03:59 -0800 Subject: [graap-wg] minutes from telecons (Feb. 14 and Feb. 23) Message-ID: <421D0BDF.7030602@hpl.hp.com> 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 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Feb2305-minutes.txt Url: http://www.ogf.org/pipermail/graap-wg/attachments/20050223/55e38bae/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Feb1405-minutes.txt Url: http://www.ogf.org/pipermail/graap-wg/attachments/20050223/55e38bae/attachment-0001.txt From karlcz at univa.com Wed Feb 23 21:33:30 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Wed, 23 Feb 2005 19:33:30 -0800 Subject: [graap-wg] More async/asymmetry comments Message-ID: <20050224033330.GC25746@isi.edu> I am sorry I missed the telecon. I have been giving this asymmetry/asynchrony topic more thought and discussing it with some WSRF/Web Service experts in the Globus Alliance. I still think that binding-level reliability can extend the utility of the basic "synchronous" Agreement creation patters and that we should repair the "initiator EPR" mess to render the peer-to-peer asynchronous pattern proposal (with the accept/reject operations). Additionally, I am persuaded that as a practical matter, it may be worth rendering the asymmetric (client-server) interface to support asynchronous (post+poll) messaging because of limitations in the binding and tooling world today. However, I am uncomfortable with the standing proposal and how it uses correlation IDs. As was pointed out to me, there is a related distributed systems management problem of deciding how this ID "namespace" is managed and how information is buffered, e.g. for how long. The low-level binding solution that uses Message-ID has some unaddressed quality of service issues pertaining to how long the IDs are remembered in order to enforce idempotence. It also has security issues pertaining to whether one client can deny service to another by anticipating and "polluting" IDs. I think it would be unfortunate if we replicated all of these flaws in the WS-Agreement WSDL interface. The view I share w/ my Globus colleagues is that we should use WSRF resources to model the buffering state and use those resource EPRs as the correlation IDs, since we are already using WSRF. This alternative is what I was hinting at in an earlier message as "another layer of resources". There are really two reasonable variants to doing this, depending on how we wish to think about the lifecycle of Agreement resources. 1) Change the Agreement resource lifecycle to again capture "pre-agreement" and possibly "post-agreement" states. The pre-agreement state can be used to allow a simple low-latency Agreement creation step and then have the "responder agrees to offer" decision made asynchronously. The initiator can poll or subscribe for notifications to learn what decision is made. The post-agreement state would capture the notion Heiko is arguing for that it is possible to "expire" or "cancel" an agreement without destroying the service interface. I mention this only to carry through the modelling approach; the pre and post states are really independent concepts. 2) Introduce separate PreAgreement and PostAgreement resources that have lifetimes linked with the existing Agreement resource. The PreAgreement resource represents the messaging state for determining whether the responder will agree to the offer or not. When he agrees, the initiator can invoke an operation on the PreAgreement to obtain the Agreement resource EPR. Similarly, the PostAgreement resource would represent the Agreement after it is "expired" or "canceled", obviating the need for an Agreement resource that exists after Heiko's agreement termination? I suppose you could mix the two, using a PreAgreement resource and having a post-agreement state on the Agreement resource, but I think that is a bit strange. I will try to start a separate thread about the termination stuff again... Personally, I prefer (1) as I think it sets us up with a better base on which to integrate future negotiation mechanisms. The Agreement provides a generic introspection interface to present different negotiation lifecycles. Optional RPs could provide info on the specific negotiation process, either as extended pre-agreement states or as references to some other service domain where that info can be found. It was also argued by my WSRF colleagues that this would be easier to implement in practice than a flurry of "smaller" resources, although that might depend on implementation technology? karl -- Karl Czajkowski karlcz at univa.com From karlcz at univa.com Wed Feb 23 21:42:52 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Wed, 23 Feb 2005 19:42:52 -0800 Subject: [graap-wg] Re: More async/asymmetry comments In-Reply-To: <20050224033330.GC25746@isi.edu> References: <20050224033330.GC25746@isi.edu> Message-ID: <20050224034252.GD25746@isi.edu> On Feb 23, Karl Czajkowski loaded a tape reading: ... > Additionally, I am persuaded that as a practical matter, it may be > worth rendering the asymmetric (client-server) interface to support > asynchronous (post+poll) messaging because of limitations in the > binding and tooling world today. I should add that two specific SOAP/HTTP limitations have changed my mind (I am sorry I had forgotten about these in earlier discussions): 1) In/out message exchanges are correlated by HTTP post/response ordering and so would block up an HTTP socket until done. I was wrongly thinking that an out message could be delayed while other exchanges continued on the same socket. 2) HTTP post pipelining is discouraged in the HTTP spec, so even the "in" half gets blocked as opposed to just blocking responses until the slow one occurs. So in practice, every concurrent blocking in/out exchange will result in another socket from the client to whomever he is invoking. A much better HTTP-based binding solution would allow two sockets to handle any number of outstanding requests by: 1) Allowing pipelining of posts and having simple empty responses for acknowledgement of receipt on one socket, with additional correlating message headers. 2) Having pipelined gets to retrieve the responses on another socket, in what ever order they are produced and using the correlation headers to sort them out. But obviously that is not a solution today. karl -- Karl Czajkowski karlcz at univa.com From t-nakata at cw.jp.nec.com Thu Feb 24 01:31:07 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Thu, 24 Feb 2005 16:31:07 +0900 Subject: [graap-wg] minutes from telecons (Feb. 14 and Feb. 23) In-Reply-To: <421D0BDF.7030602@hpl.hp.com> References: <421D0BDF.7030602@hpl.hp.com> Message-ID: <421D82BB.9030205@cw.jp.nec.com> Comment List Updated. Please note that the second issue we discussed today was Entry 10 and NOT entry 9. Jim Pruyne wrote: > 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. Will it be from 4:00 Central or from 5:00 Central? > > --- Jim > Best Regards Toshi -- We have moved to a new Office!! Toshiyuki Nakata ????? Internet System Laboratories NEC t-nakata at cw.jp.nec.com 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60210) Fax +81-44-431-7681 (NEC Internal 22-60219) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050224/e9e66e86/attachment.htm From hludwig at us.ibm.com Thu Feb 24 09:16:34 2005 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Thu, 24 Feb 2005 10:16:34 -0500 Subject: [graap-wg] minutes from telecons (Feb. 14 and Feb. 23) In-Reply-To: <421D82BB.9030205@cw.jp.nec.com> Message-ID: Toshi, by discussing and resolving comment 8, we simultaneously addressed comments 31 and 32. Maybe we can just add a referral from those comments to the answer to comment 8. Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 236 9453 http://www.research.ibm.com/people/h/hludwig/ Toshiyuki Nakata Sent by: owner-graap-wg at ggf.org 02/24/2005 02:31 AM Please respond to t-nakata To Jim Pruyne cc GRAAP-WG Subject Re: [graap-wg] minutes from telecons (Feb. 14 and Feb. 23) Comment List Updated. Please note that the second issue we discussed today was Entry 10 and NOT entry 9. Jim Pruyne wrote: > 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. Will it be from 4:00 Central or from 5:00 Central? > > --- Jim > Best Regards Toshi -- We have moved to a new Office!! Toshiyuki Nakata ????? Internet System Laboratories NEC t-nakata at cw.jp.nec.com 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60210) Fax +81-44-431-7681 (NEC Internal 22-60219) Comment-ID Title Posted By Status Resolution/Discussion 1 Changing Offers Toshiyuki Nakata Resolved Treat the normative part as correct. 2 Minor comments & asynchronous operations[ Reply ] Takuya Araki On discussion Discuss on the mailing-list. (especially wrt . Having it in the protocol or having it in the bindings) 3 Semantics of related agreements ill-defined[ Reply ] Heiko Ludwig (GGF12) Resolved (14thFeb) 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. 4 How do we know that terms are fulfilled?[ Reply ] Heiko Ludwig (GGF12) Resolved (15thFeb) 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. 5 Why is the termination time part of context?[ Reply ] Heiko Ludwig (GGF12) Resolved Because the expiration time refers to the whole of Agreement. **Action: leave it in place, capture this discussion, add justifying statements to the document. 6 ZeroOrMore needed[ Reply ] Heiko Ludwig (GGF12) Resolved Unless someone gives a clear Usecase of how this term is used, stick to the current proposal. 7 Specification too complex[ Reply ] Heiko Ludwig (GGF12) Resolved 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. 8 AgreementIsProvider attribute[ Reply ] Heiko Ludwig (GGF12) Resolved(23rd Feb) Wewill augment the guarantee terms with which party is obligated and the obligee for each guarantee by role (initiator or provider). Alsoimplies a response to issue #32. Now that obligation is specific,there's no need for the AgreementInitiatorIsServiceConsumer flag in the context. 9 Related Agreements and Brokers[ Reply ] Heiko Ludwig (GGF12) To Be Discussed ? 10 Referred Specs[ Reply ] Komori Hitoshi Being Discussed 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 (section1.1.1). Remove the MAY be composed entries. Add column where we areexplict about version that will be used. (Revisit this at beginning of next week). 11 Three "nits" Jon MacLaren To Be Discussed ? 12 WS-Agreement spec - proposed refactoring Jon MacLaren To Be Discussed ? 13 Consistency of WSRF ResProp. based monitoring Jon MacLaren To Be Discussed ? 14 WS-Agreement dependent on less mature specs Jon MacLaren To Be Discussed cf Entry 9 15 Use of WS-ResourceProperties Jon MacLaren To Be Discussed ? 16 Organisation of runtime monitoring material Jon MacLaren To Be Discussed ? 17 No XML snippets for Resource Properties in S8 Jon MacLaren To Be Discussed ? 18 Inconsistent use of expiration / termination Jon MacLaren To Be Discussed ? 19 Figure 2 Tiziana Ferrari To Be Discussed ? 20 glossary and Figure 1 Tiziana Ferrari To Be Discussed ? 21 comments about Section 7 (run time states) Tiziana Ferrari To Be Discussed ? 22 definition of compliance in Section 6 Tiziana Ferrari To Be Discussed ? 23 Language problem in Section 5.1.1 Tiziana Ferrari To Be Discussed ? 24 creation contraints and serv. lev. Objectives Tiziana Ferrari To Be Discussed ? 25 Occurance of AssessmentInterval in Comp.Type Heiko Ludwig To Be Discussed ? 26 TerminalFault Tiziana Ferrari ? ? 27 Agreement name optional Mike Fisher ? ? 28 Consistent approach to Term Compositors Mike Fisher ? ? 29 Guarantee Terms Mike Fisher ? ? 30 Include base objective set for web services Asit Dan ? ? 31 ServiceProvider/ServiceCustomer explicit Heiko Ludwig ? ? 32 Obliged party attribute for terms Heiko Ludwig ? ? 33 Explain service reference use better Heiko Ludwig ? ? 34 Refining scope of Guarantee Terms Heiko Ludwig ? ? 35 Guarantee terms for best effort systems Heiko Ludwig ? ? 36 Business Value Table Heiko Ludwig ? ? 37 ? ? ? ? 38 ? ? ? ? 39 ? ? ? ? 40 ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050224/237f79c0/attachment.html From t-nakata at cw.jp.nec.com Thu Feb 24 19:15:19 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Fri, 25 Feb 2005 10:15:19 +0900 Subject: [graap-wg] minutes from telecons (Feb. 14 and Feb. 23) In-Reply-To: References: Message-ID: <421E7C27.8080907@cw.jp.nec.com> Heiko:Thank you very much for your comments. Revised version attached. Best Regards Toshi Heiko Ludwig wrote: >Toshi, > >by discussing and resolving comment 8, we simultaneously addressed >comments 31 and 32. Maybe we can just add a referral from those comments >to the answer to comment 8. > >Heiko > >----- >Heiko Ludwig, Dr. rer. pol. >IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 >hludwig at us.ibm.com, tel. +1 914 784 7160, mob. +1 646 236 9453 >http://www.research.ibm.com/people/h/hludwig/ > > > > > >Toshiyuki Nakata >Sent by: owner-graap-wg at ggf.org >02/24/2005 02:31 AM >Please respond to >t-nakata > > >To >Jim Pruyne >cc >GRAAP-WG >Subject >Re: [graap-wg] minutes from telecons (Feb. 14 and Feb. 23) > > > > > > >Comment List Updated. >Please note that the second issue we discussed today was Entry 10 and >NOT entry 9. > > > >Jim Pruyne wrote: > > > >>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. >> >> > > >Will it be from 4:00 Central or from 5:00 Central? > > > >>--- Jim >> >> >> >Best Regards >Toshi > > > -- We have moved to a new Office!! Toshiyuki Nakata ?????? Internet System Laboratories NEC t-nakata at cw.jp.nec.com 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60210) Fax +81-44-431-7681 (NEC Internal 22-60219) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050225/072a5a77/attachment.htm From karlcz at univa.com Fri Feb 25 00:18:36 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Thu, 24 Feb 2005 22:18:36 -0800 Subject: [graap-wg] lifecycle concerns Message-ID: <20050225061836.GA2771@isi.edu> 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 at univa.com From karlcz at univa.com Fri Feb 25 00:43:10 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Thu, 24 Feb 2005 22:43:10 -0800 Subject: [graap-wg] termination versus determination Message-ID: <20050225064310.GB2771@isi.edu> 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 at univa.com From takuya_araki at mua.biglobe.ne.jp Fri Feb 25 04:37:58 2005 From: takuya_araki at mua.biglobe.ne.jp (Takuya Araki (Biglobe)) Date: Fri, 25 Feb 2005 19:37:58 +0900 Subject: [graap-wg] More async/asymmetry comments In-Reply-To: <20050224033330.GC25746@isi.edu> Message-ID: <20050225193756.TBENAC1454A6.587C0C8A@mua.biglobe.ne.jp> Karl: Basically, I agree with your (another) new proposal. Here is detailed opinion about it. There are pros and cons: * pros - Programs don't have to create/manage correlation ID (This is good!). * cons - Your proposal 1) * This affects other part of the spec (introduces a new agreement state). * Programs might need to be aware of the agreement state; this might make the program complex. + For example, in the original spec, if an agreement service (resource) and a domain-specific service are implemented as one service, the operations of the domain-specific service can be implemented assuming that the agreement exists when they are called. However, in this proposal, the operations of the domain-specific service should check the agreement state everytime, and return fault or something if the state is "pre-agreement". This should be implemented in all operations, which might be burden of programmers. (We might need AspectJ :-) (However, I admit that if we include the Terminate operation, this kind of state management should be done anyway...) - Your proposal 2) * There are no state problems, but it looks a bit awkward compared to 1)... For example, care should be taken about the lifecyle of the two services (as you mentioned in the previous mail). - Using notification makes the spec depend on WS-BaseNotification, etc. I am not against using it, but it increases the complexity of the spec anyway. My proposal took into account of keeping simplicity and avoiding change to the current spec. But if this level of complexity and change to the spec are allowed, I agree with your proposal. I also think your proposal 1) seems to be better than 2), if the complexity can be justified by other reasons, like future negotiation mechanism can be implemented on top of that. -- Takuya Araki Grid System Technology Group Internet Systems Research Laboratories NEC Corporation > -----Original Message----- > From: owner-graap-wg at ggf.org [mailto:owner-graap-wg at ggf.org] > On Behalf Of Karl Czajkowski > Sent: Thursday, February 24, 2005 12:34 PM > To: GRAAP-WG > Subject: [graap-wg] More async/asymmetry comments > > I am sorry I missed the telecon. > > I have been giving this asymmetry/asynchrony topic more > thought and discussing it with some WSRF/Web Service experts > in the Globus Alliance. I still think that binding-level > reliability can extend the utility of the basic "synchronous" > Agreement creation patters and that we should repair the > "initiator EPR" mess to render the peer-to-peer asynchronous > pattern proposal (with the accept/reject operations). > > Additionally, I am persuaded that as a practical matter, it > may be worth rendering the asymmetric (client-server) > interface to support asynchronous (post+poll) messaging > because of limitations in the binding and tooling world > today. However, I am uncomfortable with the standing > proposal and how it uses correlation IDs. As was pointed out > to me, there is a related distributed systems management > problem of deciding how this ID "namespace" is managed and > how information is buffered, e.g. for how long. > > The low-level binding solution that uses Message-ID has some > unaddressed quality of service issues pertaining to how long > the IDs are remembered in order to enforce idempotence. It > also has security issues pertaining to whether one client can > deny service to another by anticipating and "polluting" IDs. > I think it would be unfortunate if we replicated all of these > flaws in the WS-Agreement WSDL interface. > > The view I share w/ my Globus colleagues is that we should > use WSRF resources to model the buffering state and use those > resource EPRs as the correlation IDs, since we are already > using WSRF. This alternative is what I was hinting at in an > earlier message as "another layer of resources". > > There are really two reasonable variants to doing this, > depending on how we wish to think about the lifecycle of > Agreement resources. > > 1) Change the Agreement resource lifecycle to again capture > "pre-agreement" and possibly "post-agreement" states. > > The pre-agreement state can be used to allow a simple low-latency > Agreement creation step and then have the "responder agrees to > offer" decision made asynchronously. The initiator can poll or > subscribe for notifications to learn what decision is made. > > The post-agreement state would capture the notion Heiko is > arguing for that it is possible to "expire" or "cancel" an > agreement without destroying the service interface. I mention > this only to carry through the modelling approach; the pre and > post states are really independent concepts. > > 2) Introduce separate PreAgreement and PostAgreement resources that > have lifetimes linked with the existing Agreement resource. > > The PreAgreement resource represents the messaging state for > determining whether the responder will agree to the offer or > not. When he agrees, the initiator can invoke an operation on > the PreAgreement to obtain the Agreement resource EPR. > > Similarly, the PostAgreement resource would represent the > Agreement after it is "expired" or "canceled", obviating the need > for an Agreement resource that exists after Heiko's agreement > termination? > > I suppose you could mix the two, using a PreAgreement > resource and having a post-agreement state on the Agreement > resource, but I think that is a bit strange. I will try to > start a separate thread about the termination stuff again... > > Personally, I prefer (1) as I think it sets us up with a > better base on which to integrate future negotiation > mechanisms. The Agreement provides a generic introspection > interface to present different negotiation lifecycles. > Optional RPs could provide info on the specific negotiation > process, either as extended pre-agreement states or as > references to some other service domain where that info can > be found. It was also argued by my WSRF colleagues that this > would be easier to implement in practice than a flurry of > "smaller" resources, although that might depend on > implementation technology? > > > karl > > -- > Karl Czajkowski > karlcz at univa.com From maclaren at cct.lsu.edu Fri Feb 25 11:53:16 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Fri, 25 Feb 2005 11:53:16 -0600 Subject: [graap-wg] termination versus determination In-Reply-To: <20050225064310.GB2771@isi.edu> References: <20050225064310.GB2771@isi.edu> Message-ID: <88a23771328f511b7ec8b1e06062d4f9@cct.lsu.edu> From your list, I think that only c) and d) can work. a) and b) assume a lot about when payment occurs, etc. I'm not sure that it's always possible to roll things back. The way that you "get out" of a contract, is by both parties signing some sort of "amendment" to the contract - case c). It is possible that there would be some sort of clause pre-written into some agreements - your case d). These could be used to handle specific things like, "if the resource falls over during the execution of your job, you get any money back, and there's nothing else to happen between us". Note that these are not something special - they are simply the "compensation" clauses that we used to talk about in GESA. I think you need to able to do c) - to just have d), you need to be able to predict all the conditions that might arise, which is (of course) impossible. (Incidentally, I argued for c) strongly in the past, when I first saw the "terminate" operation.) I think that one of the reasons that thinking about this is complicated is that you have a resource, fronted by a service, to represent the agreement. It's a very odd responsibility model - essentially a single (potentially third) party is trusted for maintaining the definitive version of the agreement. I disagree with Karl's statement that the resource IS the agreement - if this were true, some accident befalling the resource can eliminate it! In Grid computing, resources are fallible. They can disappear. What happens when a WS-Agreement resource fails? Is it equivalent to contracts disappearing into thin air? Or do we say that WS-Agreement resources have to be reliable, and always available? If so, how is this achieved? If the agreement was represented by a signed document, which both parties had a copy of, then these strange issues about the meaning of terminating the service would not present themselves. Both parties have a responsibility to look after their copy of the agreement...just like that paper based system which has worked for hundreds of years. Jon. On Feb 25, 2005, at 12:43 AM, Karl Czajkowski wrote: > 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 at univa.com > From karlcz at univa.com Fri Feb 25 21:54:03 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Fri, 25 Feb 2005 19:54:03 -0800 Subject: [graap-wg] termination versus determination In-Reply-To: <88a23771328f511b7ec8b1e06062d4f9@cct.lsu.edu> References: <20050225064310.GB2771@isi.edu> <88a23771328f511b7ec8b1e06062d4f9@cct.lsu.edu> Message-ID: <20050226035403.GA11340@isi.edu> On Feb 25, Jon MacLaren loaded a tape reading: > From your list, I think that only c) and d) can work. a) and b) assume > a lot about when payment occurs, etc. I'm not sure that it's always > possible to roll things back. > I wonder if (a) can work in certain domains, e.g. job management. First, I think domain-specific terms could imply the compensation mechanism and have specialized terms to parameterize any variants allowed in this domain. Secondly, I think we have to admit that existing domains may have the ability to cancel requests while the entire accounting system is understood out of band. (I can cancel a job on any Grid system I know of today, and some _unspecified_ accounting takes place. We need to support these systems in a transitional sense; we cannot say "no entry" until each domain has a rich cost modeling language.) > The way that you "get out" of a contract, is by both parties signing > some sort of "amendment" to the contract - case c). > Yes, I understand that point... the question is, are these amendments always WS-Agreements? Or should we admit the fact that some (lowercase) agreements are formed by simpler interactions that can terminate a WS-Agreement? > I think that one of the reasons that thinking about this is complicated > is that you have a resource, fronted by a service, to represent the > agreement. It's a very odd responsibility model - essentially a single > (potentially third) party is trusted for maintaining the definitive > version of the agreement. I disagree with Karl's statement that the > resource IS the agreement - if this were true, some accident befalling > the resource can eliminate it! > When I said "resource" I meant the WS-Resource which is nothing but abstract document state in my mind. I did not mean computing resource etc. I still think it is appropriate and even desirable to say that this WS-Agreement resource represents the (lowercase) agreement in a one-to-one manner. We can mandate that destruction of the resource implies "retirement" of the agreement and vice-versa. What I mean is that we cannot destroy the management interface used to talk about the obligations until the obligations are "complete", e.g. historical and no longer constraining the behavior of the parties in the (domain-specific) service domain. Retired doesn't mean forgotten, but transitioned from this on-line systems management regime to some other audit, accounting, and reconciliation regime. The way I really see it is: the WS-Agreement resource for a particular domain-specific service captures a limited slice of the operating policies of the domain-specific service provider and consumer. This is its primary purpose: to allow automated management of domain-specific operating policies. As long as there are still dynamically-created operating policies, the WS-Agreement resource should remain to allow management of these policies. As soon as the dynamic policies are removed, whether by the passing of time or some explicit termination request, the WS-Agreement resource may be safely eliminated. I think of the domain-specific operating policies as the first-order obligations of the agreement parties. The WS-Agreement resource also may capture how those operating policies relate to other domains such as accounting, audit, and payment. As we have both said, these second-order obligations cannot be erased or "managed" in the sense that we would like to manage the first-order operating policies. When we drop the first-order rock into the job pool or take it out again, there are ripples through the second-order accounting system. We cannot just will the ripples away. :-) Fundamentally I see WS-Agreement as the projection of systems-management platforms into the multi-agent realm: negotiated system behavior through automated federation of policies. The cost/accounting stuff comes up because it is obviously important to allow reasoning about alternatives in a multi-agent system. But WS-Agreement is not _about_ the accounting stuff; it just has to make nods to it in order to make systems management tasks feasible in a decentralized environment. (Ignoring, of course, that a domain-specific WS-Agreement could be about an accounting system!) > In Grid computing, resources are fallible. They can disappear. What > happens when a WS-Agreement resource fails? Is it equivalent to > contracts disappearing into thin air? Or do we say that WS-Agreement > resources have to be reliable, and always available? If so, how is > this achieved? > I don't think we should mix up availability and existence. An implementation of WS-Agreement may have better or worse QoS. We can still talk about Agreements and hope they (or a good copy) will become available in the future by the same name. Destruction/termination means throwing away the name for the obligations and making them unmanageable forever. We should never allow, say, a job to keep existing in the job system if the WS-Agreement job-submission resource is terminated. > If the agreement was represented by a signed document, which both > parties had a copy of, then these strange issues about the meaning of > terminating the service would not present themselves. Both parties > have a responsibility to look after their copy of the agreement...just > like that paper based system which has worked for hundreds of years. > > Jon. > There is nothing stopping both parties from requiring WS-Security or equivalent signed-message mechanisms in the binding layer, and archiving these messages as their "signed copies". Perhaps this is a good argument for leaving the full Agreement document in the acceptance message? Otherwise, some sort of out-of-spec "offer hash" would have to be added to the headers, or a signed RP query of the agreement would be needed to give the initiator his signature proof. Separable from this who-signed-what question is the presentation of the obligations and service delivery---the on-line management interface. The current client-server interface is obviously asymmetric and "unfair" in that it doesn't give the initiator a way to report on his view of the obligation and performance. I would like to see the symmetric (peer-to-peer) protocol variant corrected both for this "fair presentation" reason and for the more basic asynchronous signaling benefits. I think both parties in the symmetric case would present WS-Agreement resources which represent the (lowercase) agreement obligations and performance, but each presenting their own view on it. This gives you the "he said, she said" view of the system, but of course 3rd-party monitoring and audit might always be necessary to get the "actually happened" view. karl -- Karl Czajkowski karlcz at univa.com From t-nakata at cw.jp.nec.com Mon Feb 28 07:17:01 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Mon, 28 Feb 2005 22:17:01 +0900 Subject: [graap-wg] minutes from telecons (Feb. 14 and Feb. 23) In-Reply-To: <421D0BDF.7030602@hpl.hp.com> References: <421D0BDF.7030602@hpl.hp.com> Message-ID: <422319CD.3060009@cw.jp.nec.com> Hi for item 10 Jim mentioned. | 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). I've tried to make a candidate of the table ((I've put the old table and the wording with the new one after it. Apologies for the weird format. I am not an Word expert..)) Problem is I am not sure whether the current WS-Agreement spec is comosable with the newest spec. Comments would be appreciated. Best regards Toshi Jim Pruyne wrote: > 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 > > -- We have moved to a new Office!! Toshiyuki Nakata ?????? Internet System Laboratories NEC t-nakata at cw.jp.nec.com 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60210) Fax +81-44-431-7681 (NEC Internal 22-60219) -------------- next part -------------- A non-text attachment was scrubbed... Name: Relationship to other WS.doc Type: application/msword Size: 29696 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20050228/a2f94c08/attachment.doc From maclaren at cct.lsu.edu Mon Feb 28 09:25:57 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Mon, 28 Feb 2005 09:25:57 -0600 Subject: [graap-wg] minutes from telecons (Feb. 14 and Feb. 23) In-Reply-To: <422319CD.3060009@cw.jp.nec.com> References: <421D0BDF.7030602@hpl.hp.com> <422319CD.3060009@cw.jp.nec.com> Message-ID: Given the different wording that is used in the various standardisation bodies, I think that it would be good to explicitly state something like "These are draft documents, and are not yet completed standards. As such, they may be subject to change." This would save people not familiar with OASIS or W3C terminology from getting the wrong idea. Jon. On Feb 28, 2005, at 7:17 AM, Toshiyuki Nakata wrote: > Hi for item 10 Jim mentioned. > > | 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). > > I've tried to make a candidate of the table ((I've put the old table > and > the wording with the > new one after it. Apologies for the weird format. I am not an Word > expert..)) > > > Problem is I am not sure whether the current WS-Agreement spec is > comosable with the newest spec. > Comments would be appreciated. > > Best regards > Toshi > > > Jim Pruyne wrote: > >> 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 >> >> > > -- > We have moved to a new Office!! > Toshiyuki Nakata ?????? > Internet System Laboratories NEC > t-nakata at cw.jp.nec.com > 1753, Shimonumabe, Nakahara-Ku, > Kawasaki,Kanagawa 211-8666,Japan > Tel +81-44-431-7653 (NEC Internal 22-60210) > Fax +81-44-431-7681 (NEC Internal 22-60219) > > > From nakata at mtg.biglobe.ne.jp Mon Feb 28 10:40:49 2005 From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata) Date: Tue, 01 Mar 2005 01:40:49 +0900 Subject: [graap-wg] minutes from telecons (Feb. 14 and Feb. 23) In-Reply-To: References: <421D0BDF.7030602@hpl.hp.com> <422319CD.3060009@cw.jp.nec.com> Message-ID: <42234991.8090604@mtg.biglobe.ne.jp> Hi: Thank you very much for the feedback. Should we put them in the table or in the main spec? Best Regards Toshi (5.2 hours till the telecon .. Apologies if I don7t make it..) Jon MacLaren wrote: > Given the different wording that is used in the various standardisation > bodies, I think that it would be good to explicitly state something like > "These are draft documents, and are not yet completed standards. As > such, they may be subject to change." This would save people not > familiar with OASIS or W3C terminology from getting the wrong idea. > > Jon. > > > On Feb 28, 2005, at 7:17 AM, Toshiyuki Nakata wrote: > >> Hi for item 10 Jim mentioned. >> >> | 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). >> >> I've tried to make a candidate of the table ((I've put the old table and >> the wording with the >> new one after it. Apologies for the weird format. I am not an Word >> expert..)) >> >> >> Problem is I am not sure whether the current WS-Agreement spec is >> comosable with the newest spec. >> Comments would be appreciated. >> >> Best regards >> Toshi >> >> >> Jim Pruyne wrote: >> >>> 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 >>> >>> >> >> -- >> We have moved to a new Office!! >> Toshiyuki Nakata ?????? >> Internet System Laboratories NEC >> t-nakata at cw.jp.nec.com >> 1753, Shimonumabe, Nakahara-Ku, >> Kawasaki,Kanagawa 211-8666,Japan >> Tel +81-44-431-7653 (NEC Internal 22-60210) >> Fax +81-44-431-7681 (NEC Internal 22-60219) >> >> >> > > > > -- Toshiyuki Nakata t-nakata at cw.jp.nec.com +81-44-431-7653 (NEC Internal 8-22-60210) From maclaren at cct.lsu.edu Mon Feb 28 10:58:14 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Mon, 28 Feb 2005 10:58:14 -0600 Subject: [graap-wg] minutes from telecons (Feb. 14 and Feb. 23) In-Reply-To: <42234991.8090604@mtg.biglobe.ne.jp> References: <421D0BDF.7030602@hpl.hp.com> <422319CD.3060009@cw.jp.nec.com> <42234991.8090604@mtg.biglobe.ne.jp> Message-ID: <97a1b190c01716470ca9cddd994822d8@cct.lsu.edu> Some people will just glance at the table rather than reading the whole text - so I think you should put it in the table. Jon. On Feb 28, 2005, at 10:40 AM, Toshiyuki Nakata wrote: > Hi: Thank you very much for the feedback. > Should we put them in the table or in the main spec? > > Best Regards > Toshi (5.2 hours till the telecon .. Apologies if I don7t make it..) > > > Jon MacLaren wrote: > >> Given the different wording that is used in the various >> standardisation >> bodies, I think that it would be good to explicitly state something >> like >> "These are draft documents, and are not yet completed standards. As >> such, they may be subject to change." This would save people not >> familiar with OASIS or W3C terminology from getting the wrong idea. >> >> Jon. >> >> >> On Feb 28, 2005, at 7:17 AM, Toshiyuki Nakata wrote: >> >>> Hi for item 10 Jim mentioned. >>> >>> | 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). >>> >>> I've tried to make a candidate of the table ((I've put the old table >>> and >>> the wording with the >>> new one after it. Apologies for the weird format. I am not an Word >>> expert..)) >>> >>> >>> Problem is I am not sure whether the current WS-Agreement spec is >>> comosable with the newest spec. >>> Comments would be appreciated. >>> >>> Best regards >>> Toshi >>> >>> >>> Jim Pruyne wrote: >>> >>>> 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 >>>> >>>> >>> >>> -- >>> We have moved to a new Office!! >>> Toshiyuki Nakata ?????? >>> Internet System Laboratories NEC >>> t-nakata at cw.jp.nec.com >>> 1753, Shimonumabe, Nakahara-Ku, >>> Kawasaki,Kanagawa 211-8666,Japan >>> Tel +81-44-431-7653 (NEC Internal 22-60210) >>> Fax +81-44-431-7681 (NEC Internal 22-60219) >>> >>> >>> >> >> >> >> > > -- > Toshiyuki Nakata > t-nakata at cw.jp.nec.com > +81-44-431-7653 > (NEC Internal 8-22-60210) > From hludwig at us.ibm.com Mon Feb 28 11:05:06 2005 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Mon, 28 Feb 2005 12:05:06 -0500 Subject: [graap-wg] termination versus determination In-Reply-To: <20050226035403.GA11340@isi.edu> Message-ID: Conceptually, I agree with the notion that agreements shouldn't be terminated at all and their useful lifetime as a resource int he WSRF sense ends at some point. The validity of agreements should only be terminated by another agreement. However, this raises 2 pragmatic issues: 1. Agreements not having a reasonable end date don't quite fit the resource lifecycle model since they, in theory, should be available indefinitely. We have to find a pragmatic way of removing them when they are not useful anymeore, e.g., when one cannot claim service against them etc. 2. Agreeing to "terminate" (not provide service against it) an agreement using another agreement is quite a bit of overhead. It would be good to have a simple standard means that would shortcut this, such as a "terminte" method. Ths could be optional and rejectable. Trying to keep things simple, Heiko owner-graap-wg at ggf.org wrote on 02/25/2005 10:54:03 PM: > On Feb 25, Jon MacLaren loaded a tape reading: > > From your list, I think that only c) and d) can work. a) and b) assume > > a lot about when payment occurs, etc. I'm not sure that it's always > > possible to roll things back. > > > > I wonder if (a) can work in certain domains, e.g. job > management. First, I think domain-specific terms could imply the > compensation mechanism and have specialized terms to parameterize any > variants allowed in this domain. Secondly, I think we have to admit > that existing domains may have the ability to cancel requests while > the entire accounting system is understood out of band. (I can cancel > a job on any Grid system I know of today, and some _unspecified_ > accounting takes place. We need to support these systems in a > transitional sense; we cannot say "no entry" until each domain has a > rich cost modeling language.) > > > > The way that you "get out" of a contract, is by both parties signing > > some sort of "amendment" to the contract - case c). > > > > Yes, I understand that point... the question is, are these amendments > always WS-Agreements? Or should we admit the fact that some > (lowercase) agreements are formed by simpler interactions that can > terminate a WS-Agreement? > > > > I think that one of the reasons that thinking about this is complicated > > is that you have a resource, fronted by a service, to represent the > > agreement. It's a very odd responsibility model - essentially a single > > (potentially third) party is trusted for maintaining the definitive > > version of the agreement. I disagree with Karl's statement that the > > resource IS the agreement - if this were true, some accident befalling > > the resource can eliminate it! > > > > When I said "resource" I meant the WS-Resource which is nothing but > abstract document state in my mind. I did not mean computing resource > etc. I still think it is appropriate and even desirable to say that > this WS-Agreement resource represents the (lowercase) agreement in a > one-to-one manner. We can mandate that destruction of the resource > implies "retirement" of the agreement and vice-versa. What I mean is > that we cannot destroy the management interface used to talk about the > obligations until the obligations are "complete", e.g. historical and > no longer constraining the behavior of the parties in the > (domain-specific) service domain. Retired doesn't mean forgotten, but > transitioned from this on-line systems management regime to some other > audit, accounting, and reconciliation regime. > > The way I really see it is: the WS-Agreement resource for a particular > domain-specific service captures a limited slice of the operating > policies of the domain-specific service provider and consumer. This is > its primary purpose: to allow automated management of domain-specific > operating policies. As long as there are still dynamically-created > operating policies, the WS-Agreement resource should remain to allow > management of these policies. As soon as the dynamic policies are > removed, whether by the passing of time or some explicit termination > request, the WS-Agreement resource may be safely eliminated. I think > of the domain-specific operating policies as the first-order > obligations of the agreement parties. > > The WS-Agreement resource also may capture how those operating > policies relate to other domains such as accounting, audit, and > payment. As we have both said, these second-order obligations cannot > be erased or "managed" in the sense that we would like to manage the > first-order operating policies. When we drop the first-order rock > into the job pool or take it out again, there are ripples through the > second-order accounting system. We cannot just will the ripples > away. :-) > > Fundamentally I see WS-Agreement as the projection of > systems-management platforms into the multi-agent realm: negotiated > system behavior through automated federation of policies. The > cost/accounting stuff comes up because it is obviously important to > allow reasoning about alternatives in a multi-agent system. But > WS-Agreement is not _about_ the accounting stuff; it just has to make > nods to it in order to make systems management tasks feasible in a > decentralized environment. (Ignoring, of course, that a domain-specific > WS-Agreement could be about an accounting system!) > > > > In Grid computing, resources are fallible. They can disappear. What > > happens when a WS-Agreement resource fails? Is it equivalent to > > contracts disappearing into thin air? Or do we say that WS-Agreement > > resources have to be reliable, and always available? If so, how is > > this achieved? > > > > I don't think we should mix up availability and existence. An > implementation of WS-Agreement may have better or worse QoS. We can > still talk about Agreements and hope they (or a good copy) will become > available in the future by the same name. Destruction/termination > means throwing away the name for the obligations and making them > unmanageable forever. We should never allow, say, a job to keep > existing in the job system if the WS-Agreement job-submission resource > is terminated. > > > > If the agreement was represented by a signed document, which both > > parties had a copy of, then these strange issues about the meaning of > > terminating the service would not present themselves. Both parties > > have a responsibility to look after their copy of the agreement...just > > like that paper based system which has worked for hundreds of years. > > > > Jon. > > > > There is nothing stopping both parties from requiring WS-Security or > equivalent signed-message mechanisms in the binding layer, and > archiving these messages as their "signed copies". Perhaps this is a > good argument for leaving the full Agreement document in the > acceptance message? Otherwise, some sort of out-of-spec "offer hash" > would have to be added to the headers, or a signed RP query of the > agreement would be needed to give the initiator his signature proof. > > Separable from this who-signed-what question is the presentation of > the obligations and service delivery---the on-line management > interface. The current client-server interface is obviously asymmetric > and "unfair" in that it doesn't give the initiator a way to report on > his view of the obligation and performance. > > I would like to see the symmetric (peer-to-peer) protocol variant > corrected both for this "fair presentation" reason and for the more > basic asynchronous signaling benefits. I think both parties in the > symmetric case would present WS-Agreement resources which represent > the (lowercase) agreement obligations and performance, but each > presenting their own view on it. This gives you the "he said, she > said" view of the system, but of course 3rd-party monitoring and audit > might always be necessary to get the "actually happened" view. > > > karl > > -- > Karl Czajkowski > karlcz at univa.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050228/5d25746f/attachment.html From maclaren at cct.lsu.edu Mon Feb 28 13:11:43 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Mon, 28 Feb 2005 13:11:43 -0600 Subject: [graap-wg] termination versus determination In-Reply-To: References: Message-ID: <7141404d20214538865630519f8e045a@cct.lsu.edu> I didn't catch any previous suggestion that agreements would have no end date. Contracts typically have some sort of end date attached to them. The problem for me is having this "terminate" operation, whose semantics are hard to define, for ending things ahead of time. As you already have a system for creating agreements, making an amendment is using a system you've already defined. Whereas adding a "terminate" operation is creating a new mechanism. It would actually be simpler to remove "terminate" from the specification. I believe that you'll find the "terminate" operation to be quite complicated to actually use. At least if you have a second agreement, you have a signed record that this has happened. (With a "terminate" operation, the only records you have are in log files.) And you'll need some sort of amendment system if you want to do re-negotiation anyway... Getting back to Karl's message, I agree that you could find scenarios where option a) would work. (I don't think that it would always work in job management, though. There are probably charging models where rolling back is not sufficient, and some other form of compensation is required for backing out of the contract. Also, I agree that there can be meaningful early ways out of a contract, but that these should be pre-defined. Like if I was renting an apartment for a year, but there is a clause stating that with 2 months notice, I can leave during the term of the contract. You can agree this sort of stuff, but it's execution should be out of band in terms of the agreement protocol. It's between the two parties to arrange this sort of stuff. (Of course, this complicates the expiry of the agreement resource - maybe you want to keep it around until the original end-date in any case.) Jon. On Feb 28, 2005, at 11:05 AM, Heiko Ludwig wrote: > > Conceptually, I agree with the notion that agreements shouldn't be > terminated at all and their useful lifetime as a resource int he WSRF > sense ends at some point. The validity of agreements should only be > terminated by another agreement. However, this raises 2 pragmatic > issues: > > 1. Agreements not having a reasonable end date don't quite fit the > resource lifecycle model since they, in theory, should be available > indefinitely. We have to find a pragmatic way of removing them when > they are not useful anymeore, e.g., when one cannot claim service > against them etc. > > 2. Agreeing to "terminate" (not provide service against it) an > agreement using another agreement is quite a bit of overhead. It would > be good to have a simple standard means that would shortcut this, such > as a "terminte" method. Ths could be optional and rejectable. > > Trying to keep things simple, > Heiko > > owner-graap-wg at ggf.org wrote on 02/25/2005 10:54:03 PM: > > > On Feb 25, Jon MacLaren loaded a tape reading: > > > From your list, I think that only c) and d) can work. ?a) and b) > assume > > > a lot about when payment occurs, etc. ?I'm not sure that it's > always > > > possible to roll things back. > > > > > > > I wonder if (a) can work in certain domains, e.g. job > > management. First, I think domain-specific terms could imply the > > compensation mechanism and have specialized terms to parameterize > any > > variants allowed in this domain. ?Secondly, I think we have to admit > > that existing domains may have the ability to cancel requests while > > the entire accounting system is understood out of band. ?(I can > cancel > > a job on any Grid system I know of today, and some _unspecified_ > > accounting takes place. ?We need to support these systems in a > > transitional sense; we cannot say "no entry" until each domain has a > > rich cost modeling language.) > > > > > > > The way that you "get out" of a contract, is by both parties > signing > > > some sort of "amendment" to the contract - case c). > > > > > > > Yes, I understand that point... the question is, are these > amendments > > always WS-Agreements? ?Or should we admit the fact that some > > (lowercase) agreements are formed by simpler interactions that can > > terminate a WS-Agreement? > > > > > > > I think that one of the reasons that thinking about this is > complicated > > > is that you have a resource, fronted by a service, to represent > the > > > agreement. ?It's a very odd responsibility model - essentially a > single > > > (potentially third) party is trusted for maintaining the > definitive > > > version of the agreement. ?I disagree with Karl's statement that > the > > > resource IS the agreement - if this were true, some accident > befalling > > > the resource can eliminate it! > > > > > > > When I said "resource" I meant the WS-Resource which is nothing but > > abstract document state in my mind. ?I did not mean computing > resource > > etc. ?I still think it is appropriate and even desirable to say that > > this WS-Agreement resource represents the (lowercase) agreement in a > > one-to-one manner. ?We can mandate that destruction of the resource > > implies "retirement" of the agreement and vice-versa. ?What I mean > is > > that we cannot destroy the management interface used to talk about > the > > obligations until the obligations are "complete", e.g. historical > and > > no longer constraining the behavior of the parties in the > > (domain-specific) service domain. ?Retired doesn't mean forgotten, > but > > transitioned from this on-line systems management regime to some > other > > audit, accounting, and reconciliation regime. > > > > The way I really see it is: the WS-Agreement resource for a > particular > > domain-specific service captures a limited slice of the operating > > policies of the domain-specific service provider and consumer. This > is > > its primary purpose: to allow automated management of > domain-specific > > operating policies. As long as there are still dynamically-created > > operating policies, the WS-Agreement resource should remain to allow > > management of these policies. ?As soon as the dynamic policies are > > removed, whether by the passing of time or some explicit termination > > request, the WS-Agreement resource may be safely eliminated. I think > > of the domain-specific operating policies as the first-order > > obligations of the agreement parties. > > > > The WS-Agreement resource also may capture how those operating > > policies relate to other domains such as accounting, audit, and > > payment. ?As we have both said, these second-order obligations > cannot > > be erased or "managed" in the sense that we would like to manage the > > first-order operating policies. ?When we drop the first-order rock > > into the job pool or take it out again, there are ripples through > the > > second-order accounting system. We cannot just will the ripples > > away. :-) > > > > Fundamentally I see WS-Agreement as the projection of > > systems-management platforms into the multi-agent realm: negotiated > > system behavior through automated federation of policies. ?The > > cost/accounting stuff comes up because it is obviously important to > > allow reasoning about alternatives in a multi-agent system. ?But > > WS-Agreement is not _about_ the accounting stuff; it just has to > make > > nods to it in order to make systems management tasks feasible in a > > decentralized environment. (Ignoring, of course, that a > domain-specific > > WS-Agreement could be about an accounting system!) > > > > > > > In Grid computing, resources are fallible. ?They can disappear. > ?What > > > happens when a WS-Agreement resource fails? ?Is it equivalent to > > > contracts disappearing into thin air? ?Or do we say that > WS-Agreement > > > resources have to be reliable, and always available? ?If so, how > is > > > this achieved? > > > > > > > I don't think we should mix up availability and existence. ?An > > implementation of WS-Agreement may have better or worse QoS. ?We can > > still talk about Agreements and hope they (or a good copy) will > become > > available in the future by the same name. ?Destruction/termination > > means throwing away the name for the obligations and making them > > unmanageable forever. ?We should never allow, say, a job to keep > > existing in the job system if the WS-Agreement job-submission > resource > > is terminated. > > > > > > > If the agreement was represented by a signed document, which both > > > parties had a copy of, then these strange issues about the > meaning of > > > terminating the service would not present themselves. ?Both > parties > > > have a responsibility to look after their copy of the > agreement...just > > > like that paper based system which has worked for hundreds of > years. > > > > > > Jon. > > > > > > > There is nothing stopping both parties from requiring WS-Security or > > equivalent signed-message mechanisms in the binding layer, and > > archiving these messages as their "signed copies". ?Perhaps this is > a > > good argument for leaving the full Agreement document in the > > acceptance message? ?Otherwise, some sort of out-of-spec "offer > hash" > > would have to be added to the headers, or a signed RP query of the > > agreement would be needed to give the initiator his signature proof. > > > > Separable from this who-signed-what question is the presentation of > > the obligations and service delivery---the on-line management > > interface. The current client-server interface is obviously > asymmetric > > and "unfair" in that it doesn't give the initiator a way to report > on > > his view of the obligation and performance. > > > > I would like to see the symmetric (peer-to-peer) protocol variant > > corrected both for this "fair presentation" reason and for the more > > basic asynchronous signaling benefits. ?I think both parties in the > > symmetric case would present WS-Agreement resources which represent > > the (lowercase) agreement obligations and performance, but each > > presenting their own view on it. ?This gives you the "he said, she > > said" view of the system, but of course 3rd-party monitoring and > audit > > might always be necessary to get the "actually happened" view. > > > > > > karl > > > > -- > > Karl Czajkowski > > karlcz at univa.com > > From pruyne at hpl.hp.com Mon Feb 28 14:02:43 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Mon, 28 Feb 2005 14:02:43 -0600 Subject: [graap-wg] telecon reminder Message-ID: <422378E3.2070206@hpl.hp.com> 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 From sediga at av8.net Mon Feb 28 16:17:23 2005 From: sediga at av8.net (Art Sedighi) Date: Mon, 28 Feb 2005 17:17:23 -0500 Subject: [graap-wg] telecon reminder In-Reply-To: <422378E3.2070206@hpl.hp.com> Message-ID: <200502282217.RAA01662@citation.av8.net> Sorry guys I have been out of touch... Will get back to the swing of things next week... I had some personal matters that I needed to take care of... Art -----Original Message----- From: owner-graap-wg at ggf.org [mailto:owner-graap-wg at ggf.org] On Behalf Of Jim Pruyne Sent: Monday, February 28, 2005 3:03 PM To: GRAAP-WG Subject: [graap-wg] telecon reminder 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 From pruyne at hpl.hp.com Mon Feb 28 17:58:47 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Mon, 28 Feb 2005 17:58:47 -0600 Subject: [graap-wg] minutes from 2/28 telecon Message-ID: <4223B037.2060407@hpl.hp.com> All, Here are minutes from today's telecon. We'll meet again next week at the usual time. Reminder to follow. --- Jim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Feb2805-minutes.txt Url: http://www.ogf.org/pipermail/graap-wg/attachments/20050228/6df48cdb/attachment.txt From maclaren at cct.lsu.edu Mon Feb 28 18:57:08 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Mon, 28 Feb 2005 18:57:08 -0600 Subject: [graap-wg] minutes from 2/28 telecon In-Reply-To: <4223B037.2060407@hpl.hp.com> References: <4223B037.2060407@hpl.hp.com> Message-ID: <1ea0e3eaf557e8762517ae8cc7a967f6@cct.lsu.edu> > 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. Just to clarify... I realise that no external parties able to update the monitoring information. However, the service/resource is changing state - is this state change any different from an external writer? I wasn't sure that WS-RF would guarantee the user sees a consistent state at these times - I thought you only needed one writer and one reader for consistency problems here. Maybe someone who knows WS-RF better than me can clarify this. Jon. From t-nakata at cw.jp.nec.com Mon Feb 28 18:55:16 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Tue, 01 Mar 2005 09:55:16 +0900 Subject: [graap-wg] minutes from 2/28 telecon In-Reply-To: <4223B037.2060407@hpl.hp.com> References: <4223B037.2060407@hpl.hp.com> Message-ID: <4223BD74.8000709@cw.jp.nec.com> Hello: Updated the Comments list. I also added the status column in the table to reflect Jon's comments on the mailing list. One problem. for WS-RF RP, http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/11590/wsrf-WS-ResourceProperties-1.2-draft-06.b.doc) Was uploaded on Feb 25th 05) I've avoided quoting this on the table as I suppose it is still a work in progress.... Comments will be appreciated Best regards Toshi Jim Pruyne wrote: > All, > > Here are minutes from today's telecon. We'll meet again next week at > the usual time. Reminder to follow. > > --- Jim > > -- We have moved to a new Office!! Toshiyuki Nakata ????? Internet System Laboratories NEC t-nakata at cw.jp.nec.com 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60210) Fax +81-44-431-7681 (NEC Internal 22-60219) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050301/64527a93/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Relationship to other WS2.doc Type: application/msword Size: 31232 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20050301/64527a93/attachment.doc From karlcz at univa.com Mon Feb 28 20:20:15 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 1 Mar 2005 09:20:15 +0700 Subject: [graap-wg] termination versus determination In-Reply-To: <7141404d20214538865630519f8e045a@cct.lsu.edu> References: <7141404d20214538865630519f8e045a@cct.lsu.edu> Message-ID: <20050301022015.GB7113@moraine.localdomain> On Feb 28, Jon MacLaren loaded a tape reading: > I didn't catch any previous suggestion that agreements would have no > end date. Contracts typically have some sort of end date attached to > them. The problem for me is having this "terminate" operation, whose > semantics are hard to define, for ending things ahead of time. > I am wondering if the full space should have three different ending mechanisms: 1) Retirement via the WSRF terminate or lifetime expiration, which shuts down the first-class WS-Agreement management interface but does not amend any obligations represented in the Agreement resource. It simply makes them unavailable for direct monitoring or amendment by reference. Q: Should retirement ever be allowed while service-domain obligations are still in scope? Can we even distinguish what I referred to before as "first class" obligations (like running a job) from "second class" obligations (like making payment)? Perhaps some extra markup could annotate such terms? 2) Activation of a pre-specified escape clause of the Agreement resource which amends the obligations and also could amend or hasten the retirement schedule. Q: How can we do this to support existing domains and encourage better modeling of escape terms over time? 3) Full first-class amendment via WS-Agreement creation. Once an existing agreement is subsumed by another and its obligations are out of scope, the old one can be retired. If these reasonably cover the termination variants we have discussed, I would tend to think it is better to include them in the specification and leave it up to domain specializations or operating policies to determine when the different mechanisms are allowed. I am not certain, however, that we can capture (3) because it requires the "related agreement" concept to reference existing Agreement resources in a new offer; can we see a generic enough pattern for mechanism (3) such that we can introduce a relationship for that without trying to over-reach? > As you already have a system for creating agreements, making an > amendment is using a system you've already defined. Whereas adding a > "terminate" operation is creating a new mechanism. It would actually > be simpler to remove "terminate" from the specification. > We also have practical concerns about "resource leakage" which is why I emphasize the retirement idea above. I think we have to provide a way to purge WS resources during operation, or many people will ignore the specification as malformed or impractical. > I believe that you'll find the "terminate" operation to be quite > complicated to actually use. At least if you have a second agreement, > you have a signed record that this has happened. (With a "terminate" > operation, the only records you have are in log files.) And you'll > need some sort of amendment system if you want to do re-negotiation > anyway... > Would you accept the retirement of agreement interfaces without any change to the agreed obligations? Would you accept the use of a terminate pattern to trigger a non-reversable escape clause, e.g. "cancel my job according to the original agreement"? > Getting back to Karl's message, I agree that you could find scenarios > where option a) would work. (I don't think that it would always work > in job management, though. There are probably charging models where > rolling back is not sufficient, and some other form of compensation is > required for backing out of the contract. > > Also, I agree that there can be meaningful early ways out of a > contract, but that these should be pre-defined. Like if I was renting > an apartment for a year, but there is a clause stating that with 2 > months notice, I can leave during the term of the contract. You can > agree this sort of stuff, but it's execution should be out of band in > terms of the agreement protocol. It's between the two parties to > arrange this sort of stuff. (Of course, this complicates the expiry of > the agreement resource - maybe you want to keep it around until the > original end-date in any case.) > I am only concerned about whether this escape mechanism, when applicable, has to be explicitly modeled in the agreement terms or whether it can be implicit in the type/domain-specialization. Keeping on my Globus GRAM architect hat, I have to be able to support existing job cancel mechanisms! I need to do this even if the initial semantics are weakly defined and future standards efforts are needed to rationalize different cancelation/compensation approaches. > Jon. > > karl -- Karl Czajkowski karlcz at univa.com From karlcz at univa.com Mon Feb 28 21:57:58 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 1 Mar 2005 10:57:58 +0700 Subject: [graap-wg] minutes from 2/28 telecon In-Reply-To: <4223B037.2060407@hpl.hp.com> References: <4223B037.2060407@hpl.hp.com> Message-ID: <20050301035758.GE7235@moraine.localdomain> On Feb 28, Jim Pruyne loaded a tape reading: > All, > > Here are minutes from today's telecon. We'll meet again next week at > the usual time. Reminder to follow. > > --- Jim > > Sorry, I missed the call due to a nasty cold w/ fever... Was there any discussion of the overall plan or scope of activity for the spec work? My gut feeling is that there were a number of minor points raised during the comment period but the three issues with the biggest practical impact are: 1) resolving the asynchronous/peer-to-peer messaging requirements 2) and making sense of the termination issue 3) understanding the Agreement lifecycle as it relates to these two problems All of these have seen some discussion on the list, I know, but none have had a clear conclusion. My meta-question is whether we are in agreement that these should be addressed as possibly substantial edits to the specification (if necessary)... I think these problems overlap with some general specification "damage" which occurred when the negotiation mechanisms were stripped out and the state model reduced. I think we should try to get these things right and be open to the possibility of a second comment period after the edits are complete. Thoughts? karl p.s. of course there is also still a great need for a primer or other layman's guide, but I am focusing on the eventual standard itself. -- Karl Czajkowski karlcz at univa.com