From Wolfgang.Ziegler at scai.fraunhofer.de Tue Mar 1 04:23:46 2005 From: Wolfgang.Ziegler at scai.fraunhofer.de (Wolfgang Ziegler) Date: Tue, 01 Mar 2005 11:23:46 +0100 Subject: [graap-wg] minutes from 2/28 telecon In-Reply-To: <20050301035758.GE7235@moraine.localdomain> References: <4223B037.2060407@hpl.hp.com> <20050301035758.GE7235@moraine.localdomain> Message-ID: <422442B2.6090702@scai.fraunhofer.de> Hi Karl, we should address the three issues in separate telecons for each after GGF13. I would have no problem to have a second comment period afterwards (where we should finally collect the positive comments after all ;-)) Best regards Wolfgang Karl Czajkowski wrote: > 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. > -- 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3761 bytes Desc: S/MIME Cryptographic Signature Url : http://www.ogf.org/pipermail/graap-wg/attachments/20050301/bc610e2f/attachment.bin From karlcz at univa.com Tue Mar 1 08:51:39 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 1 Mar 2005 21:51:39 +0700 Subject: [graap-wg] minutes from 2/28 telecon In-Reply-To: <1ea0e3eaf557e8762517ae8cc7a967f6@cct.lsu.edu> References: <4223B037.2060407@hpl.hp.com> <1ea0e3eaf557e8762517ae8cc7a967f6@cct.lsu.edu> Message-ID: <20050301145139.GB10449@moraine.localdomain> I am not sure that I am following this concern, but to my knowledge WS-ResourceProperties does not define any coherency or consistency among resource properties. It only states that query results will be valid according to the schema. This is not about "writers" but about dynamic RP documents and the possible lack of synchronization in constructing the RP elements in query results. (WS-RF tries to be lenient about what infrastructure is required to implement the basic facilities.) I think the best approach would be to define RPs that are meaningful in isolation from one another and only loosely associated with each other via their association to the resource identity; dynamic values that have temporal associations should probably be part of one RP element rather than spread across several. I do not think there is anything risky about stating that a particular RP will be updated coherently (coherence amongs its attributes and subelements). A particular specification could add requirements, but of course this might restrict the WSRF tooling environments that are capable of hosting the standard. Also, I would be concerned if we required strong consistency and didn't make it so that a WS-Agreement environment would degrade gracefully if the consistency were violated; for example, references across terms could use temporally unique IDs for dynamic elements so that a consumer could detect a dangling reference rather than making an incorrect dereference. I suppose you could call this an implementation detail, but I would like to think we could encourage or even mandate some hygiene... Can someone explain concisely what the consistency hazard is that has been raised? karl On Feb 28, Jon MacLaren loaded a tape reading: > >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. -- Karl Czajkowski karlcz at univa.com From maclaren at cct.lsu.edu Tue Mar 1 09:26:54 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Tue, 1 Mar 2005 09:26:54 -0600 Subject: [graap-wg] minutes from 2/28 telecon In-Reply-To: <20050301145139.GB10449@moraine.localdomain> References: <4223B037.2060407@hpl.hp.com> <1ea0e3eaf557e8762517ae8cc7a967f6@cct.lsu.edu> <20050301145139.GB10449@moraine.localdomain> Message-ID: I'll try and explain my original concern, although I'm pretty certain after reading your mail that it is actually of no concern. I was worried that someone could read the RP document while it was half-way through being written. I was thinking in terms of a chunk of memory being written by one thread, as another tries a read. But from what you say, i.e. that the results will be valid according to the schema, this is clearly not an issue. Given that updates to the component parts of an RP are atomic in some sense, I'm not aware of any coherence issues in the current WS-Agreement spec. Which is I guess what the comment from the telecon was saying also. Thanks for the clarification... Jon. On Mar 1, 2005, at 8:51 AM, Karl Czajkowski wrote: > I am not sure that I am following this concern, but to my knowledge > WS-ResourceProperties does not define any coherency or consistency > among resource properties. It only states that query results will be > valid according to the schema. This is not about "writers" but about > dynamic RP documents and the possible lack of synchronization in > constructing the RP elements in query results. (WS-RF tries to be > lenient about what infrastructure is required to implement the basic > facilities.) > > I think the best approach would be to define RPs that are meaningful > in isolation from one another and only loosely associated with each > other via their association to the resource identity; dynamic values > that have temporal associations should probably be part of one RP > element rather than spread across several. I do not think there is > anything risky about stating that a particular RP will be updated > coherently (coherence amongs its attributes and subelements). > > A particular specification could add requirements, but of course this > might restrict the WSRF tooling environments that are capable of > hosting the standard. Also, I would be concerned if we required > strong consistency and didn't make it so that a WS-Agreement > environment would degrade gracefully if the consistency were violated; > for example, references across terms could use temporally unique IDs > for dynamic elements so that a consumer could detect a dangling > reference rather than making an incorrect dereference. I suppose you > could call this an implementation detail, but I would like to think we > could encourage or even mandate some hygiene... > > Can someone explain concisely what the consistency hazard is that has > been raised? > > > karl > > > On Feb 28, Jon MacLaren loaded a tape reading: >>> 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. > > -- > Karl Czajkowski > karlcz at univa.com > From hludwig at us.ibm.com Wed Mar 2 14:53:04 2005 From: hludwig at us.ibm.com (Heiko Ludwig) Date: Wed, 2 Mar 2005 15:53:04 -0500 Subject: [graap-wg] termination versus determination In-Reply-To: <20050301022015.GB7113@moraine.localdomain> Message-ID: Coming back to the termination issue ... owner-graap-wg at ggf.org wrote on 02/28/2005 09:20:15 PM: > 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 figure the notion of an "contract end date" refers mostly to a colloqialism implying the time when all obligations relating to service of the contract are over and is particularly applicable to services that are provided for a particular time. Q: Do we want to make the resource lifetime the equivalent of the time of the main service; and what if the model doesn't fit, e.g., in case of a set of services, disputes or services where an end time doesn't really apply. > 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? This means that the AgreementProvider will se tthe resource lifetime according to the (domain-specific) times the terms indicate and will only really end the resource when the last "main" obligation is fulfilled. What happens if it never is, if something goes wrong? I am not sure whether we want to bring too much contract-specific semantics to the notion of recource lifetime. If we cannot map reasonably, we should keep it separate. > 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? > Following approach 2 entails extending the obligation and rights semantics that we have. At the moment we don't have the explicit notion of an option on an agreement level, just service terms and guarantee terms. However our service description terms might contain this on the domain-specific level. We could extend our term model to distinguish options, guarantees and services (what will be done without exercising the option). That's what WSLA provides and it worked well. On which level, though, will the AgreementProvider offer an operation to exercise an option, if we assume that also the initiator might want to exercise it: Agreement or service? 2 and 3 point to a model where agreements basically modify the set of rights and obligations that are in force between 2 parties. That's a model that is not uncommon in service management but would require some adjustments to the expressivness of the agreement spec and it raises the issue of how to expose the state monitoring. A per-agreement state monitoring might not be appropriate in this case. Amending the spec in the proposed sense might be worth the effort but it will take some time. Furthermore, the proposal puts quite some more requirements on the implementors of the spec. Finally, we still don't have a very simple mechanism by which initiator or provider can terminate the agreement consensually and easily. The terminate opreation was meant do provide this, probably still requiring all those mechanism you listed above. Heiko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050302/73da01ae/attachment.html From karlcz at univa.com Wed Mar 2 19:40:18 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Thu, 3 Mar 2005 08:40:18 +0700 Subject: [graap-wg] termination versus determination In-Reply-To: References: <20050301022015.GB7113@moraine.localdomain> Message-ID: <20050303014018.GA19139@moraine.localdomain> On Mar 02, Heiko Ludwig loaded a tape reading: ... > I figure the notion of an "contract end date" refers mostly to a > colloqialism implying the time when all obligations relating to service > of the contract are over and is particularly applicable to services > that are provided for a particular time. > I agree. If I am understanding the objections raised, it is that even this "simple" case is underspecified. Even if termination is meant for things like "end my job", I think Jon has raised the issue that you really need to know in what way (with what amended obligations) the job will be ended... who gets paid what, etc. I think it would be more clear if we just had a way to annotate service descriptions w/ temporal scoping (start+end times) and leave the whole Agreement expiration as the latest of all service description end times. To adjust the end time(s) would require amendment of the scope of these services. > Q: Do we want to make the resource lifetime the equivalent of the time > of the main service; and what if the model doesn't fit, e.g., in case > of a set of services, disputes or services where an end time doesn't > really apply. > I had assumed from the start (until I read that bit in the draft about the separate agreement expiration time) that the times were the same. I realize now that this becomes murky when one pays attention to cases with more than one service or when the "second-class" obligations, like accounting and payment, become an issue... > > 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? > > This means that the AgreementProvider will se tthe resource lifetime > according to the (domain-specific) times the terms indicate and will > only really end the resource when the last "main" obligation is > fulfilled. What happens if it never is, if something goes wrong? > Then the resource would stick around and hopefully indicate a "something has gone wrong, please help me" status? :-) Note, however, that I think obligations could equally go out of scope after having been satisfied or violated and abandoned. Once there is no more service action that will result, we are just talking about knowledge of past obligations for accounting. I don't think there is ever a time when it is impossible that an amendment could be made, so I am willing to admit that some amendments will happen after the Agreement resource has been retired. For example, contested payment obligations could be reversed or even just refunded on a basis of generosity (or any arbitrary domain-specific policy). I am not advocating that Agreement resources must persist forever to allow for these cases. > I am not sure whether we want to bring too much contract-specific > semantics to the notion of recource lifetime. If we cannot map > reasonably, we should keep it separate. > I think we could (must?) avoid mandating a behavior because it is so dependent on domain-specific semantics. But I think we could appeal to intuition and abstraction in trying to clarify the difference between "retiring" the resource and actually amending obligations; I think it would be best for most domain-specific deployments of WS-Agreement to resist tearing down the management interface before the interesting obligations are met or terminally rejected. > Following approach 2 entails extending the obligation and rights > semantics that we have. At the moment we don't have the explicit notion > of an option on an agreement level, just service terms and guarantee > terms. However our service description terms might contain this on the > domain-specific level. We could extend our term model to distinguish > options, guarantees and services (what will be done without exercising > the option). That's what WSLA provides and it worked well. On which > level, though, will the AgreementProvider offer an operation to > exercise an option, if we assume that also the initiator might want to > exercise it: Agreement or service? > I could accept the "options" being encoded explicitly or implicitly in domain-specific terms/extensions. The only question then is whether obligation termination or amendment can be addressed through a generic "terminate" operation or whether domain-specific "exercise option Foo" operations must always be introduced for this? > 2 and 3 point to a model where agreements basically modify the set of > rights and obligations that are in force between 2 parties. That's a > model that is not uncommon in service management but would require some > adjustments to the expressivness of the agreement spec and it raises > the issue of how to expose the state monitoring. A per-agreement state > monitoring might not be appropriate in this case. > I am not sure this introduces as much complication as you imply. I think all agreements always "modify the rights and obligations that are in force between 2 parties", because these parties live in a stateful and finite universe. So I've _always_ viewed WS-Agreement as modifying the universe of policies based on a particular set of "transient" goals. The specification is more or less aligned to support this now, and I think we just need to clean up some rough edges. As for monitoring, I think any realistic scenario will always admit that there are external services and parties who may play parts in monitoring, detection, adaptation, audit, and accounting. When I say "external", I mean external to the WS-Agreement specification and quite possibly external to any domain-specific Agreement that is established. WS-Agreement only needs to establish the parts that are being dynamically established and adjusted by automated entities; it does not have to presume an initial context of nothingness between the parties. > Amending the spec in the proposed sense might be worth the effort but > it will take some time. Furthermore, the proposal puts quite some more > requirements on the implementors of the spec. Finally, we still don't > have a very simple mechanism by which initiator or provider can > terminate the agreement consensually and easily. The terminate > opreation was meant do provide this, probably still requiring all those > mechanism you listed above. > I'm not sure how much more requirements are placed on implementors. Again, I see this mostly as trying to clarify the semantics of what we are proposing (and adjusting the mechanisms if they aren't consistent with a reasonable semantics). The only implementor burden I see is in understanding the domain terms well enough to decide if termination/amendment should be allowed or not, and I think this burden already existed; I think this discussion is just about how to render the mechanisms to clarify their meaning as it relates to the domain-specific environment. > > > Heiko karl -- Karl Czajkowski karlcz at univa.com From t-nakata at cw.jp.nec.com Thu Mar 3 02:58:00 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Thu, 03 Mar 2005 17:58:00 +0900 Subject: [graap-wg] More async/asymmetry comments In-Reply-To: <20050224033330.GC25746@isi.edu> References: <20050224033330.GC25746@isi.edu> Message-ID: <4226D198.1050101@cw.jp.nec.com> Karl: I am also very much interested in your proposal. Discussing this case with another colleague of mine, I got a bit worried in the implementation issue, which I think is due to my ignorance of WSRF resource modelling and I 'd like to clarify this part. (It also relates a little bit to the consistency issues.) To make sure that my worry is just a mistake on my part, could you bear with my question below? Karl Czajkowski wrote: >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. > > > If the initiator decided to subscribe, can you tell me the sequence of subscribe/notify? 1)my original assumption. 1.1) Initiator requests CreateAgreement 1.2)Provider creates an empty Agreement (With agreement state Not-Yet-Complete)and returns an EPR to the created Agreement. 1.3)Initiator subscribes for the notification using the returned EPR. My worry is what if the provider had been very quick and had agreed to the agreement and had changed the agreement status to Agreed between timing 1.2 and 1.3? Would the Initiator be notified of this at the timing of 1.3? or would the initiator have to do some kind of atomic chack and subscribe? 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) From karlcz at univa.com Thu Mar 3 03:30:45 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Thu, 3 Mar 2005 16:30:45 +0700 Subject: [graap-wg] More async/asymmetry comments In-Reply-To: <4226D198.1050101@cw.jp.nec.com> References: <20050224033330.GC25746@isi.edu> <4226D198.1050101@cw.jp.nec.com> Message-ID: <20050303093045.GP19139@moraine.localdomain> This is actually a very messy question. :-) There are two related problems: the lack of transactional control to group the separate operations, and the lack of QoS guarantees for notification. For the transaction problem, you are worried about a race-condition between the creation and subscription where a state change would be missed. This can be addressed in a number of ways that are all unfortunately not standards: 1) require that a subscription always trigger a notification of the "current" state at the time of subscription in addition to future state changes, etc. 2) do one state query after subscription to get approximately the same value as in (1), with the added excitement of interpreting this result that is delivered outside the notification stream. 3) provide a merged createAgreement and subscribe operation; this is what we do in WS-GRAM in GT 4.0, both to avoid the race-condition and reduce the number of message exchanges. However, even with one of these solutions there is another set of risks: notification does not really guarantee reliability or ordered delivery of notifications that the provider "tried" to send. Of course, Web services in general do not provide message delivery guarantees, but the lack of a response to the deliverNotification operation means that the sender cannot even know if the message was received successfully. One solution for WS-Agreement would be use the peer-to-peer interface variant and use the proposed domain-specific accept() operation in favor of generic subscription/notification for this important state transition. In Globus, our long-term architectural solution to the generic notification QoS problem has been to assume a soft-state methodology w/ temporal metadata. We would advocate sending a stream of redundant messages within certain max/min frequencies and letting the consumer sort it duplication or loss. This leads to a system that will converge on steady state values and may diverge under loss/congestion. These concepts were built into OGSI from the start. However, the WSRF specifications do not provide such primitives and we have not introduced extensions for this yet. So, in GT 4.0 it is incumbent on the subscriber to actually poll values as a fall-back to avoid hanging forever in the presence of notification failures! Furthermore, the network could reverse the order of multiple notifications which might be confusing for an overly-trusting consumer, depending on the state model for the topic in question. With the right temporal metadata, a consumer of a notification stream can reorder or filter out-of-order messages to avoid violating state invariants. Even without such metadata, one can often filter out meaningless or "backwards" transitions, e.g. even our "DUROC" co-allocator that consumed GRAM state change messages would guard against non-sensical job state notifications by comparing them to the currently held view of the remote job's state before doing any further processing. karl On Mar 03, Toshiyuki Nakata loaded a tape reading: > If the initiator decided to subscribe, can you tell me the sequence of > subscribe/notify? > > 1)my original assumption. > 1.1) Initiator requests CreateAgreement > 1.2)Provider creates an empty Agreement (With agreement state > Not-Yet-Complete)and > returns an EPR to the created Agreement. > 1.3)Initiator subscribes for the notification using the returned EPR. > > My worry is what if the provider had been very quick and had agreed to > the agreement and had > changed the agreement status to Agreed between timing 1.2 and 1.3? > > Would the Initiator be notified of this at the timing of 1.3? or would > the initiator have to do some kind of > atomic chack and subscribe? > > > 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) > > -- Karl Czajkowski karlcz at univa.com From t-nakata at cw.jp.nec.com Thu Mar 3 04:05:15 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Thu, 03 Mar 2005 19:05:15 +0900 Subject: [graap-wg] More async/asymmetry comments In-Reply-To: <20050303093045.GP19139@moraine.localdomain> References: <20050224033330.GC25746@isi.edu> <4226D198.1050101@cw.jp.nec.com> <20050303093045.GP19139@moraine.localdomain> Message-ID: <4226E15B.9090002@cw.jp.nec.com> Thank you very much for your clarification. best regards Toshi Karl Czajkowski wrote: >This is actually a very messy question. :-) > >There are two related problems: the lack of transactional control to >group the separate operations, and the lack of QoS guarantees for >notification. > >For the transaction problem, you are worried about a race-condition >between the creation and subscription where a state change would be >missed. This can be addressed in a number of ways that are all >unfortunately not standards: > > 1) require that a subscription always trigger a notification of the > "current" state at the time of subscription in addition to future > state changes, etc. > > 2) do one state query after subscription to get approximately the > same value as in (1), with the added excitement of interpreting > this result that is delivered outside the notification stream. > > 3) provide a merged createAgreement and subscribe operation; this is > what we do in WS-GRAM in GT 4.0, both to avoid the race-condition > and reduce the number of message exchanges. > >However, even with one of these solutions there is another set of >risks: notification does not really guarantee reliability or ordered >delivery of notifications that the provider "tried" to send. Of >course, Web services in general do not provide message delivery >guarantees, but the lack of a response to the deliverNotification >operation means that the sender cannot even know if the message was >received successfully. One solution for WS-Agreement would be use the >peer-to-peer interface variant and use the proposed domain-specific >accept() operation in favor of generic subscription/notification for >this important state transition. > >In Globus, our long-term architectural solution to the generic >notification QoS problem has been to assume a soft-state methodology >w/ temporal metadata. We would advocate sending a stream of redundant >messages within certain max/min frequencies and letting the consumer >sort it duplication or loss. This leads to a system that will converge >on steady state values and may diverge under loss/congestion. These >concepts were built into OGSI from the start. However, the WSRF >specifications do not provide such primitives and we have not >introduced extensions for this yet. So, in GT 4.0 it is incumbent on >the subscriber to actually poll values as a fall-back to avoid hanging >forever in the presence of notification failures! > >Furthermore, the network could reverse the order of multiple >notifications which might be confusing for an overly-trusting >consumer, depending on the state model for the topic in question. >With the right temporal metadata, a consumer of a notification stream >can reorder or filter out-of-order messages to avoid violating state >invariants. Even without such metadata, one can often filter out >meaningless or "backwards" transitions, e.g. even our "DUROC" >co-allocator that consumed GRAM state change messages would guard >against non-sensical job state notifications by comparing them to the >currently held view of the remote job's state before doing any further >processing. > > >karl > > >On Mar 03, Toshiyuki Nakata loaded a tape reading: > > > >>If the initiator decided to subscribe, can you tell me the sequence of >>subscribe/notify? >> >>1)my original assumption. >>1.1) Initiator requests CreateAgreement >>1.2)Provider creates an empty Agreement (With agreement state >>Not-Yet-Complete)and >>returns an EPR to the created Agreement. >>1.3)Initiator subscribes for the notification using the returned EPR. >> >>My worry is what if the provider had been very quick and had agreed to >>the agreement and had >>changed the agreement status to Agreed between timing 1.2 and 1.3? >> >>Would the Initiator be notified of this at the timing of 1.3? or would >>the initiator have to do some kind of >>atomic chack and subscribe? >> >> >>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) >> >> >> >> > > > -- 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 maclaren at cct.lsu.edu Thu Mar 3 16:27:59 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Thu, 3 Mar 2005 17:27:59 -0500 Subject: [graap-wg] termination versus determination In-Reply-To: <20050303014018.GA19139@moraine.localdomain> References: <20050301022015.GB7113@moraine.localdomain> <20050303014018.GA19139@moraine.localdomain> Message-ID: <158b1e998a0d962883e72bd97849c9e9@cct.lsu.edu> I think that escaping from an agreement should always be considered domain specific, and remain outside of the scope of the protocol. The proposed standard already encompasses agreement discovery, creation and monitoring. I think including specific support for acceptable scenario-specific escape conditions introduces another facet. Introducing the terminate operation tries to do this too. In my view, it provides a false panacea - it encourages people to believe (and perhaps even expect) that they can simply and generically escape from an agreement... Jon. On Mar 2, 2005, at 8:40 PM, Karl Czajkowski wrote: > On Mar 02, Heiko Ludwig loaded a tape reading: > ... >> I figure the notion of an "contract end date" refers mostly to a >> colloqialism implying the time when all obligations relating to >> service >> of the contract are over and is particularly applicable to services >> that are provided for a particular time. >> > > I agree. If I am understanding the objections raised, it is that even > this "simple" case is underspecified. Even if termination is meant > for things like "end my job", I think Jon has raised the issue that > you really need to know in what way (with what amended obligations) > the job will be ended... who gets paid what, etc. > > I think it would be more clear if we just had a way to annotate > service descriptions w/ temporal scoping (start+end times) and leave > the whole Agreement expiration as the latest of all service > description end times. To adjust the end time(s) would require > amendment of the scope of these services. > > >> Q: Do we want to make the resource lifetime the equivalent of the time >> of the main service; and what if the model doesn't fit, e.g., in case >> of a set of services, disputes or services where an end time doesn't >> really apply. >> > > I had assumed from the start (until I read that bit in the draft about > the separate agreement expiration time) that the times were the same. > I realize now that this becomes murky when one pays attention to cases > with more than one service or when the "second-class" obligations, > like accounting and payment, become an issue... > > >>> 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? >> >> This means that the AgreementProvider will se tthe resource lifetime >> according to the (domain-specific) times the terms indicate and will >> only really end the resource when the last "main" obligation is >> fulfilled. What happens if it never is, if something goes wrong? >> > > Then the resource would stick around and hopefully indicate a > "something has gone wrong, please help me" status? :-) Note, however, > that I think obligations could equally go out of scope after having > been satisfied or violated and abandoned. Once there is no more > service action that will result, we are just talking about knowledge > of past obligations for accounting. > > I don't think there is ever a time when it is impossible that an > amendment could be made, so I am willing to admit that some amendments > will happen after the Agreement resource has been retired. For > example, contested payment obligations could be reversed or even just > refunded on a basis of generosity (or any arbitrary domain-specific > policy). I am not advocating that Agreement resources must persist > forever to allow for these cases. > > >> I am not sure whether we want to bring too much contract-specific >> semantics to the notion of recource lifetime. If we cannot map >> reasonably, we should keep it separate. >> > > I think we could (must?) avoid mandating a behavior because it is so > dependent on domain-specific semantics. But I think we could appeal > to intuition and abstraction in trying to clarify the difference > between "retiring" the resource and actually amending obligations; I > think it would be best for most domain-specific deployments of > WS-Agreement to resist tearing down the management interface before > the interesting obligations are met or terminally rejected. > > >> Following approach 2 entails extending the obligation and rights >> semantics that we have. At the moment we don't have the explicit >> notion >> of an option on an agreement level, just service terms and guarantee >> terms. However our service description terms might contain this on the >> domain-specific level. We could extend our term model to distinguish >> options, guarantees and services (what will be done without exercising >> the option). That's what WSLA provides and it worked well. On which >> level, though, will the AgreementProvider offer an operation to >> exercise an option, if we assume that also the initiator might want to >> exercise it: Agreement or service? >> > > I could accept the "options" being encoded explicitly or implicitly in > domain-specific terms/extensions. The only question then is whether > obligation termination or amendment can be addressed through a generic > "terminate" operation or whether domain-specific "exercise option Foo" > operations must always be introduced for this? > > >> 2 and 3 point to a model where agreements basically modify the set of >> rights and obligations that are in force between 2 parties. That's a >> model that is not uncommon in service management but would require >> some >> adjustments to the expressivness of the agreement spec and it raises >> the issue of how to expose the state monitoring. A per-agreement state >> monitoring might not be appropriate in this case. >> > > I am not sure this introduces as much complication as you imply. I > think all agreements always "modify the rights and obligations that > are in force between 2 parties", because these parties live in a > stateful and finite universe. So I've _always_ viewed WS-Agreement as > modifying the universe of policies based on a particular set of > "transient" goals. The specification is more or less aligned to > support this now, and I think we just need to clean up some rough > edges. > > As for monitoring, I think any realistic scenario will always admit > that there are external services and parties who may play parts in > monitoring, detection, adaptation, audit, and accounting. When I say > "external", I mean external to the WS-Agreement specification and > quite possibly external to any domain-specific Agreement that is > established. WS-Agreement only needs to establish the parts that are > being dynamically established and adjusted by automated entities; it > does not have to presume an initial context of nothingness between the > parties. > > >> Amending the spec in the proposed sense might be worth the effort but >> it will take some time. Furthermore, the proposal puts quite some more >> requirements on the implementors of the spec. Finally, we still don't >> have a very simple mechanism by which initiator or provider can >> terminate the agreement consensually and easily. The terminate >> opreation was meant do provide this, probably still requiring all >> those >> mechanism you listed above. >> > > I'm not sure how much more requirements are placed on implementors. > > Again, I see this mostly as trying to clarify the semantics of what we > are proposing (and adjusting the mechanisms if they aren't consistent > with a reasonable semantics). The only implementor burden I see is in > understanding the domain terms well enough to decide if > termination/amendment should be allowed or not, and I think this > burden already existed; I think this discussion is just about how to > render the mechanisms to clarify their meaning as it relates to the > domain-specific environment. > > >> >> >> Heiko > > karl > > -- > Karl Czajkowski > karlcz at univa.com > From hiro.kishimoto at jp.fujitsu.com Sun Mar 6 05:04:24 2005 From: hiro.kishimoto at jp.fujitsu.com (Hiro Kishimoto) Date: Sun, 6 Mar 2005 20:04:24 +0900 Subject: [graap-wg] OGSA-BES BoF discussion (FW: Proposed agenda for March 7th call) Message-ID: <023001c5223c$41d38310$57d5190a@ORD> Hi all, As you may already know, OGSA Basic Execution Service WG Charter BoF will be held at GGF13 (Mar. 16 Wed, 9-10:30am). OGSA-WG will have a preparation discussion on upcoming Monday call (March 7th, 5-6:30pm CDT) and would invite you to join discussion. Craig, John: May I ask you to forward this invitation to your groups, SAGA-RG and DRMAA-WG, respectively? Thanks, ---- Hiro Kishimoto >From Draft Charter: > 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 WG/RGs within GGF, e.g. OGSA WG, JSDL WG, SAGA RG, > GRAAP WG and also widely used pioneering projects; e.g. Globus, > UNICORE, Condor, Legion, Platform, SGE, PBS, OMII, and others as > appropriate. 3) OGSA-BES BoF discussion (30 min, Andrew) BoF session description, Draft Charter, 7 questions discussion - current draft http://www.gridforum.org/Meetings/GGF13/Charters/GGF13_OGSA_Basic_Execution_Serv ice_WG_BOF.pdf Revised draft charter etc. will be posted before the call. The dial-in number for Monday; Free: +1-866-639-4741 Toll: +1-574-935-6703 PIN: 8980700 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0307 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html -------------- next part -------------- An embedded message was scrubbed... From: "Hiro Kishimoto" Subject: [ogsa-wg] Proposed agenda for March 7th call Date: Sun, 6 Mar 2005 19:50:30 +0900 Size: 7018 Url: http://www.ogf.org/pipermail/graap-wg/attachments/20050306/cf88322f/attachment.mht From pruyne at hpl.hp.com Mon Mar 7 16:06:41 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Mon, 07 Mar 2005 16:06:41 -0600 Subject: [graap-wg] Direct URL for doc. comments Message-ID: <422CD071.5030201@hpl.hp.com> All, There's been confusion on finding the URL for the comments list. I believe this will do it: https://forge.gridforum.org/forum/forum.php?forum_id=461 --- Jim From pruyne at hpl.hp.com Mon Mar 7 17:07:40 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Mon, 07 Mar 2005 17:07:40 -0600 Subject: [graap-wg] minutes from Mar. 7 telecon Message-ID: <422CDEBC.3020601@hpl.hp.com> Are attached. --- Jim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Mar0705-minutes.txt Url: http://www.ogf.org/pipermail/graap-wg/attachments/20050307/cce046c8/attachment.txt From pruyne at hpl.hp.com Mon Mar 7 17:23:12 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Mon, 07 Mar 2005 17:23:12 -0600 Subject: [graap-wg] [Fwd: Re: [ogsa-wg] Proposed (DRAFT) Agenda for Basic EM BOF] Message-ID: <422CE260.6020602@hpl.hp.com> It would seem like a good idea if some graap members would attend this bof at GGF13. Andrew's original announcement is below. --- Jim -------- Original Message -------- Subject: Re: [ogsa-wg] Proposed (DRAFT) Agenda for Basic EM BOF Date: Mon, 07 Mar 2005 16:39:16 -0600 From: Ian Foster To: Andrew Grimshaw , , 'Karl Czajkowski' , Kazushige Saga Three comments: a) It's important to give time for other people to present. E.g., I suspect Karl Czajkowski will want to present on our behalf. There will likely be others. People should be able to sign up ahead of the meeting and get a time allocation. b) I don't see how we can require a priori that "the output of the OGSA-BEM will fit into the overall OGSA EMS architecture." I don't know what that means, and in any case, we need to see what people come up with. c) It is important to say something in the BOF description as to what we expect the scope of "basic execution management service" to be. E.g., "focused on defining Web services interfaces for job submission, monitoring, and management." Ian. At 05:31 PM 3/7/2005 -0500, Andrew Grimshaw wrote: > The objective of the BOF is to form the OGSA Basic Execution > Management Service Working Group (OGSA-BEM). The output of the > OGSA-BEM will fit into the overall OGSA EMS architecture, as initially > described in the OGSA V1 Document. It is expected that the OGSA EMS > architecture will evolve over time and that evolution will eventually > need to be incorporated. Such incorporation may not take place in this > working group depending on whether OGSA-BEM completes before changes > are made in the overall OGSA-EMS. > > > > Proposed Agenda > > > > > > Presentation of GGF IP Rules > > Pass around sign-up sheet > > > > > > Background on OGSA EMS > > > > Basic Execution Management A Focus on Minimal Services > > Draft Service Containers description > > > > Charter discussion > > Should charter be extended to include Actors? > > Should the charter be extended to include any form of > agreements? > > Milestones > > > > Scheduling of calls > > > > _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org From pruyne at hpl.hp.com Wed Mar 9 09:27:40 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Wed, 09 Mar 2005 09:27:40 -0600 Subject: [graap-wg] [Fwd: RE: [ogsa-wg] Proposed (DRAFT) Agenda for Basic EM BOF] Message-ID: <422F15EC.4070204@hpl.hp.com> More info. on the OGSA execution BoF. Note the reference to GRAAP here. Perhaps someone (Wolfgang?) can contact Andrew and see if they'd like a couple minutes on WS-Agreement in the 30mins. they're planning for other speakers. --- Jim -------- Original Message -------- Subject: RE: [ogsa-wg] Proposed (DRAFT) Agenda for Basic EM BOF Date: Tue, 8 Mar 2005 19:43:38 -0500 From: Andrew Grimshaw To: 'Ian Foster' , Ian, a) As discussed on last nights telecom, we are going to allocate up to 30 minutes for other presenters. I have already sent email to the two people who have requested time. b) The whole point of this working group IS to fit into the overall architecture. That is how the charter SHOULD read. The charter is the contract the working group makes with the steering committee, and limits the scope of the working group. c) I don?t understand item c, the draft charter document clearly states *?*Focus/Purpose 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 WG/RGs within GGF, e.g. OGSA WG, JSDL WG, SAGA RG, GRAAP WG and also widely used pioneering projects; e.g. Globus, UNICORE, Condor, Legion, Platform, SGE, PBS, OMII, and others as appropriate. The milestones are particularly ambitious in order to support the overall OGSA roadmap and timeline. Fortunately there has already been significant discussion with the OGSA-WG on the overall EMS architecture, as well as discussions with other interested parties such as OMII and EGEE. *Scope* The scope of the proposed working group is on the definition of services for service instantiation and management, with a particular focus initially on legacy ?job? services. For example, using the OGSA V1 nomenclature, service containers and jobs. *?* * * *Andrew* ------------------------------------------------------------------------ *From:* owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] *On Behalf Of *Ian Foster *Sent:* Monday, March 07, 2005 5:39 PM *To:* Andrew Grimshaw; ogsa-wg at ggf.org; 'Karl Czajkowski'; Kazushige Saga *Subject:* Re: [ogsa-wg] Proposed (DRAFT) Agenda for Basic EM BOF Three comments: a) It's important to give time for other people to present. E.g., I suspect Karl Czajkowski will want to present on our behalf. There will likely be others. People should be able to sign up ahead of the meeting and get a time allocation. b) I don't see how we can require a priori that "the output of the OGSA-BEM will fit into the overall OGSA EMS architecture." I don't know what that means, and in any case, we need to see what people come up with. c) It is important to say something in the BOF description as to what we expect the scope of "basic execution management service" to be. E.g., "focused on defining Web services interfaces for job submission, monitoring, and management." Ian. At 05:31 PM 3/7/2005 -0500, Andrew Grimshaw wrote: The objective of the BOF is to form the OGSA Basic Execution Management Service Working Group (OGSA-BEM). The output of the OGSA-BEM will fit into the overall OGSA EMS architecture, as initially described in the OGSA V1 Document. It is expected that the OGSA EMS architecture will evolve over time and that evolution will eventually need to be incorporated. Such incorporation may not take place in this working group depending on whether OGSA-BEM completes before changes are made in the overall OGSA-EMS. Proposed Agenda Presentation of GGF IP Rules Pass around sign-up sheet Background on OGSA EMS Basic Execution Management A Focus on Minimal Services Draft Service Containers description Charter discussion Should charter be extended to include Actors? Should the charter be extended to include any form of agreements? Milestones Scheduling of calls _______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org From pruyne at hpl.hp.com Mon Mar 14 17:05:20 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Mon, 14 Mar 2005 17:05:20 -0600 Subject: [graap-wg] minutes from 3/14/05 telecon Message-ID: <423618B0.7050500@hpl.hp.com> They are attached. I hope everyone's enjoying GGF. --- jim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Mar1405-minutes.txt Url: http://www.ogf.org/pipermail/graap-wg/attachments/20050314/9b7d024c/attachment.txt From t-nakata at cw.jp.nec.com Fri Mar 18 00:26:48 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Fri, 18 Mar 2005 15:26:48 +0900 Subject: [graap-wg] More async/asymmetry comments In-Reply-To: <20050225193756.TBENAC1454A6.587C0C8A@mua.biglobe.ne.jp> References: <20050225193756.TBENAC1454A6.587C0C8A@mua.biglobe.ne.jp> Message-ID: <423A74A8.5050106@cw.jp.nec.com> Hello: I had a brief chat with Karl on the issue below. Basically, Takuya and I agreed that the proposal 1) seems attractive. The only worry that I mentioned to Karl was, the re-introduction of the agreement state. I vaguely remember that the state had been dropped because of the following discussion After the agreement phase, it would be difficult to define the agreement state as some of the SDT's might be observed and some others might not be and that it was rather meaningless to have a state of its own. If this was the real reason it might be good to resurrect the agreement state with the understanding that it would show the status of what the agreement process was. Comments? BestRegards Toshi Takuya Araki (Biglobe) wrote: >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 >> >> > > > > -- 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 t-nakata at cw.jp.nec.com Fri Mar 18 02:17:13 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Fri, 18 Mar 2005 17:17:13 +0900 Subject: [graap-wg] minutes from 3/14/05 telecon In-Reply-To: <423618B0.7050500@hpl.hp.com> References: <423618B0.7050500@hpl.hp.com> Message-ID: <423A8E89.4000704@cw.jp.nec.com> Hello- Resending the Comments list as somehow or other, I still haven't received the email I sent on the 15th March Apologies if you receive this twice.. Best Regards Toshi Jim Pruyne wrote: > They are attached. I hope everyone's enjoying GGF. > > --- 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/20050318/3e064214/attachment.htm From Wolfgang.Ziegler at scai.fraunhofer.de Fri Mar 18 11:40:32 2005 From: Wolfgang.Ziegler at scai.fraunhofer.de (Wolfgang Ziegler) Date: Fri, 18 Mar 2005 18:40:32 +0100 Subject: [graap-wg] Minutes of the GRAAP session at GGF13 Message-ID: <423B1290.6020407@scai.fraunhofer.de> Dear all, the minutes of the sessions are attached, the slides and the minutes are also uploaded to the gridforge site. 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: GRAAP minutes GGF13.txt Url: http://www.ogf.org/pipermail/graap-wg/attachments/20050318/3f2c12ba/attachment.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3761 bytes Desc: S/MIME Cryptographic Signature Url : http://www.ogf.org/pipermail/graap-wg/attachments/20050318/3f2c12ba/attachment.bin From pruyne at hpl.hp.com Sun Mar 20 23:28:26 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Sun, 20 Mar 2005 23:28:26 -0600 Subject: [graap-wg] Telecon on 3/21 Message-ID: <423E5B7A.1010004@hpl.hp.com> Folks, We will have our telecon on Mon. 3/21 at the usual time and number. Those being: 4PM US Central 5PM US Eastern 2PM US Pacific 22:00 UK 23:00 Germany 07:00 Japan Of course, if any of these times vary from the usual, that just means I messed up on the conversions, not that I've changed the times. The number, as always, is 866-673-8466 or 702-477-6031 passcode 8578310 I hope that at least some folks who attended GGF will be able to attend, and let us know what happened there. We'll also continue to work through the comments received during public comment, and perhaps get an update on any doc. changes that have been made as a result of previous discusisons. --- Jim From nakata at mtg.biglobe.ne.jp Mon Mar 21 03:25:55 2005 From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata) Date: Mon, 21 Mar 2005 18:25:55 +0900 Subject: [graap-wg] Telecon on 3/21 In-Reply-To: <423E5B7A.1010004@hpl.hp.com> References: <423E5B7A.1010004@hpl.hp.com> Message-ID: <423E9323.4020409@mtg.biglobe.ne.jp> Thank you very much for the announcement. I'll be atttending but would have to leave early (7:40..) I can supplement what Wolfgang wrote in the minutes of GGF13, but most of it's already there so not much to add. The other big issue would be the OGSA-BES and EMS Best Regards Toshi Jim Pruyne wrote: > Folks, > > We will have our telecon on Mon. 3/21 at the usual time and number. > Those being: > 4PM US Central > 5PM US Eastern > 2PM US Pacific > 22:00 UK > 23:00 Germany > 07:00 Japan > > Of course, if any of these times vary from the usual, that just means I > messed up on the conversions, not that I've changed the times. > > The number, as always, is 866-673-8466 or 702-477-6031 passcode 8578310 > > I hope that at least some folks who attended GGF will be able to attend, > and let us know what happened there. We'll also continue to work > through the comments received during public comment, and perhaps get an > update on any doc. changes that have been made as a result of previous > discusisons. > > --- 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 Mar 21 03:36:23 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Mon, 21 Mar 2005 16:36:23 +0700 Subject: [graap-wg] Telecon on 3/21 In-Reply-To: <423E9323.4020409@mtg.biglobe.ne.jp> References: <423E5B7A.1010004@hpl.hp.com> <423E9323.4020409@mtg.biglobe.ne.jp> Message-ID: <20050321093623.GA30298@moraine.localdomain> On Mar 21, Toshiyuki Nakata loaded a tape reading: > Thank you very much for the announcement. > I'll be atttending but would have to leave early (7:40..) > I can supplement what Wolfgang wrote in the minutes of GGF13, but > most of it's already there so not much to add. > > The other big issue would be the OGSA-BES and EMS > Best Regards > Toshi > My impression is that it is an uphill battle to convince the OGSA-BES group to consider seriously using WS-Agreement, while they all seem clear on the idea of using JSDL. I think this is due to several facts: 1) They are on an aggressive schedule and so have some conservatism. 2) There are some preconcieved notions of what BES should be that look more like GRAM or other job-specific interfaces. 3) There was a bit of the lingering anti-wsrf sentiment floating around Seoul. 4) BES is supposed to fit EMS, and it is not clear EMS really has an understanding where WS-Agreement could fit. 5) Most groups are unclear on how we intend WS-Agreement to be used, not really seeing the "generalized GRAM/GARA" history and perhaps being confused by all the generic agreement, SLA, etc. terminology into thinking it has to be a heavyweight process involving human administrators. I think these last issues are the biggest concern for GRAAP-WG besides, obviously, getting the technical issues ironed out. We need to figure out how to market all these nifty ideas or we run the risk of producing a specification that will gather dust on the shelf. karl -- Karl Czajkowski karlcz at univa.com From nakata at mtg.biglobe.ne.jp Mon Mar 21 03:59:54 2005 From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata) Date: Mon, 21 Mar 2005 18:59:54 +0900 Subject: [graap-wg] Telecon on 3/21 In-Reply-To: <423E9323.4020409@mtg.biglobe.ne.jp> References: <423E5B7A.1010004@hpl.hp.com> <423E9323.4020409@mtg.biglobe.ne.jp> Message-ID: <423E9B1A.2050706@mtg.biglobe.ne.jp> Just as a suppplement? Toshiyuki Nakata wrote: >>> >> We will have our telecon on Mon. 3/21 at the usual time and number. >> Those being: >> 4PM US Central >> 5PM US Eastern >> 2PM US Pacific >> 22:00 UK >> 23:00 Germany >> 07:00 Japan >> Fortunately it is not yet daylight Saving time in US.. http://www.timeanddate.com/worldclock/city.html?n=64 says.. DST starts on Sunday, 3 April 2005, 02:00 local standard time DST ends on Sunday, 30 October 2005, 02:00 local daylight time We don't have DST in Japan or Thailand so we need to watch out.. Best Regards Toshi > -- Toshiyuki Nakata t-nakata at cw.jp.nec.com +81-44-431-7653 (NEC Internal 8-22-60210) From nakata at mtg.biglobe.ne.jp Mon Mar 21 04:31:26 2005 From: nakata at mtg.biglobe.ne.jp (Toshiyuki Nakata) Date: Mon, 21 Mar 2005 19:31:26 +0900 Subject: [graap-wg] Telecon on 3/21 In-Reply-To: <20050321093623.GA30298@moraine.localdomain> References: <423E5B7A.1010004@hpl.hp.com> <423E9323.4020409@mtg.biglobe.ne.jp> <20050321093623.GA30298@moraine.localdomain> Message-ID: <423EA27E.1090505@mtg.biglobe.ne.jp> Karl Czajkowski wrote: > On Mar 21, Toshiyuki Nakata loaded a tape reading: > >>Thank you very much for the announcement. >>I'll be atttending but would have to leave early (7:40..) >>I can supplement what Wolfgang wrote in the minutes of GGF13, but >>most of it's already there so not much to add. >> >>The other big issue would be the OGSA-BES and EMS >>Best Regards >>Toshi >> > > > My impression is that it is an uphill battle to convince the OGSA-BES > group to consider seriously using WS-Agreement, while they all seem > clear on the idea of using JSDL. I think this is due to several > facts: > I talked with several people @GGF13. 1)If you loook at the two layered picture of Agreeement Services and the lower level, Real services (Such as Job submission etc), My understanding is BES has to deal with the Serive layer beneath the Agreement Factory layer. 2)On the other hand EMS has to look into what is the relationship between the Service Layer and the Agreement Layer. Eg. Is the Job defined first in the Service Layer and an Agreement Layer has to encompass this or, Is the Job defined between the Service Layer and the Agreement layer as a result of the CreateAgreement Operation. There *ARE* open questions as these which someone has to address... > 4) BES is supposed to fit EMS, and it is not clear EMS really has > an understanding where WS-Agreement could fit. From my undersatnding, EMS had been waiting for WS-Ag to get fixed. I've also heard several semntimets from other projects... > > 5) Most groups are unclear on how we intend WS-Agreement to be used, > not really seeing the "generalized GRAM/GARA" history and perhaps > being confused by all the generic agreement, SLA, > etc. terminology into thinking it has to be a heavyweight process > involving human administrators. > > I think these last issues are the biggest concern for GRAAP-WG > besides, obviously, getting the technical issues ironed out. We need > to figure out how to market all these nifty ideas or we run the risk > of producing a specification that will gather dust on the shelf. > Actually as I said before, several WGs / projects are really waiting for output from GRAAP-WG. Best Reagards 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 Mar 21 05:49:24 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Mon, 21 Mar 2005 18:49:24 +0700 Subject: [graap-wg] Telecon on 3/21 In-Reply-To: <423EA27E.1090505@mtg.biglobe.ne.jp> References: <423E5B7A.1010004@hpl.hp.com> <423E9323.4020409@mtg.biglobe.ne.jp> <20050321093623.GA30298@moraine.localdomain> <423EA27E.1090505@mtg.biglobe.ne.jp> Message-ID: <20050321114924.GA450@moraine.localdomain> On Mar 21, Toshiyuki Nakata loaded a tape reading: ... > 1)If you loook at the two layered picture of Agreeement Services and the > lower level, Real services (Such as Job submission etc), My > understanding is BES has to deal with the Serive layer beneath the > Agreement Factory layer. > I am not 100% certain that I understood your comment after this one, because I want to read it as stating something close to what I think I have been saying, but as I said at the BES BoF, this "Agreement + job submission" view is a misunderstanding of WS-Agreement's service abstraction. "Job submission" is not the service layer we would envision beneath the Agreement management layer, because the submission pattern is exactly what WS-Agreement is meant to address. Specifically, agreements about "generic execution jobs" or "specific kinds of job" are what we intended the basic agreement creation pattern to handle. Creation==submission. It is hard to express this without using the word agreement in a circular manner, but we took GRAM/GARA and said, "these are agreements about jobs or reservations" and tried to generalize it just a bit. These generalizations, while important, are not very intuitive for people to grasp; if they were, the GRAM and GARA systems would probably have started off more general. ;-) WS-Agreement, through the GRAAP-WG charter, was scoped from the very beginning to address the "submission" part in its management model; our two explicit example use cases were job submission and advance reservation for jobs! That's the domain area brought in by the founding participants. This is why I frame this as a misunderstanding/public relations problem. There are not open questions for how WS-Agreement SHOULD handle jobs except that we haven't publicized the the answers well enough. :-) I am completely in agreement regarding the time sensitivity of this work. We need to get a technically sound, well documented standard out in a short amount of time. Any two of these three features will probably not be sufficient... karl -- Karl Czajkowski karlcz at univa.com From maclaren at cct.lsu.edu Mon Mar 21 09:12:53 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Mon, 21 Mar 2005 09:12:53 -0600 Subject: [graap-wg] Telecon on 3/21 In-Reply-To: <20050321093623.GA30298@moraine.localdomain> References: <423E5B7A.1010004@hpl.hp.com> <423E9323.4020409@mtg.biglobe.ne.jp> <20050321093623.GA30298@moraine.localdomain> Message-ID: <89cfbad89e72758c31ac3408c739eac9@cct.lsu.edu> Just to comment on a couple of these points... On Mar 21, 2005, at 3:36 AM, Karl Czajkowski wrote: > My impression is that it is an uphill battle to convince the OGSA-BES > group to consider seriously using WS-Agreement, while they all seem > clear on the idea of using JSDL. I think this is due to several > facts: > > 1) They are on an aggressive schedule and so have some conservatism. I believe that they were talking about getting interoperable implementations by the end of 2005, which is very aggressive... > 2) There are some preconcieved notions of what BES should be that > look more like GRAM or other job-specific interfaces. A strawman interface was presented, but this was (I felt) little more than "these are the things that BES should support". Pre-conceived is a little harsh - everything presented can be changed. > 3) There was a bit of the lingering anti-wsrf sentiment floating > around Seoul. There has been some excellent discussion on the OGSA-WG list just prior to this meeting on whether or not WS-RF is necessary, and if it is, what is it necessary for? But to be fair, it's not "sentiment" - there are some very astute people saying that the Grid community doesn't need WS-RF. Unfortunately, in Seoul, there was practically no debate on this subject (at least, not inside of the WG sessions!). I would expect to see this being played out in the OGSA-BES list. It's a debate that needs to happen. Jon. From maclaren at cct.lsu.edu Mon Mar 21 09:30:31 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Mon, 21 Mar 2005 09:30:31 -0600 Subject: [graap-wg] Telecon on 3/21 In-Reply-To: <20050321114924.GA450@moraine.localdomain> References: <423E5B7A.1010004@hpl.hp.com> <423E9323.4020409@mtg.biglobe.ne.jp> <20050321093623.GA30298@moraine.localdomain> <423EA27E.1090505@mtg.biglobe.ne.jp> <20050321114924.GA450@moraine.localdomain> Message-ID: On Mar 21, 2005, at 5:49 AM, Karl Czajkowski wrote: > On Mar 21, Toshiyuki Nakata loaded a tape reading: > ... >> 1)If you loook at the two layered picture of Agreeement Services and >> the >> lower level, Real services (Such as Job submission etc), My >> understanding is BES has to deal with the Serive layer beneath the >> Agreement Factory layer. >> > > I am not 100% certain that I understood your comment after this one, > because I want to read it as stating something close to what I think I > have been saying, but as I said at the BES BoF, this "Agreement + job > submission" view is a misunderstanding of WS-Agreement's service > abstraction. "Job submission" is not the service layer we would > envision beneath the Agreement management layer, because the > submission pattern is exactly what WS-Agreement is meant to address. > > Specifically, agreements about "generic execution jobs" or "specific > kinds of job" are what we intended the basic agreement creation > pattern to handle. Creation==submission. It is hard to express this > without using the word agreement in a circular manner, but we took > GRAM/GARA and said, "these are agreements about jobs or reservations" > and tried to generalize it just a bit. These generalizations, while > important, are not very intuitive for people to grasp; if they were, > the GRAM and GARA systems would probably have started off more > general. ;-) Are you saying that agreement creation is equivalent to job submission? (More comments below) > WS-Agreement, through the GRAAP-WG charter, was scoped from the very > beginning to address the "submission" part in its management model; > our two explicit example use cases were job submission and advance > reservation for jobs! That's the domain area brought in by the > founding participants. The GRAAP-WG charter does not address job submission. It addresses resource allocation. We used advance reservation for computational jobs as a use case. However, we make clear that the claiming of the resources, i.e. the job submission part of that use case, is not something that the GRAAP-WG would address. > This is why I frame this as a misunderstanding/public relations > problem. There are not open questions for how WS-Agreement SHOULD > handle jobs except that we haven't publicized the the answers well > enough. :-) I can understand that the decoupling of the resource allocation from the job submission is only one architectural viewpoint. In private discussions that I've had with non-GGF participants, they have wanted to view the resource allocation, job submission, and job execution as a single "business transaction". That's a completely valid viewpoint. However, it is different from the one described in the charter, where we view these as separate concerns. Perhaps this is where people's misconceptions come from. Perhaps you could clarify exactly where you view a GRAM-type protocol fitting in with WS-Agreement? Perhaps some sort of sequence diagram. Do you envisage the user have a separate interaction with GRAM to create/submit/launch the underlying computational job? Jon. From karlcz at univa.com Mon Mar 21 09:28:22 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Mon, 21 Mar 2005 22:28:22 +0700 Subject: [graap-wg] Telecon on 3/21 In-Reply-To: <89cfbad89e72758c31ac3408c739eac9@cct.lsu.edu> References: <423E5B7A.1010004@hpl.hp.com> <423E9323.4020409@mtg.biglobe.ne.jp> <20050321093623.GA30298@moraine.localdomain> <89cfbad89e72758c31ac3408c739eac9@cct.lsu.edu> Message-ID: <20050321152822.GB8121@moraine.localdomain> On Mar 21, Jon MacLaren loaded a tape reading: ... > A strawman interface was presented, but this was (I felt) little more > than "these are the things that BES should support". Pre-conceived is > a little harsh - everything presented can be changed. > Well, I didn't mean it with the negative connotation you are reading... I guess I should have chosen a better adjective. I meant that the only real consensus I have heard so far seems to center on some very traditional rendering. I am slowly learning to be conservative in assuming there is agreement where it hasn't been explicitly recognized. :-) I think this traditionalist approach relates directly to the aggressive schedule, and is not necessarily a bad thing for a starting point. However, to get everyone interested in BES to work through and understand the WS-Agreement rendering well enough to accept or reject it would put the remaining BES activity on a pace that I have yet to see happen in GGF! I'm just trying to share my view on it to set expectations in GRAAP... we need to make sure we get WS-Agreement right and on the next editing cycle; focusing too much on BES when things are this uncertain may not be productive in bringing WS-Agreement to closure. (I would love to see it adopted for BES, but I would not be willing to put that on the critical path unless BES is willing to delay its milestones if necessary. If their schedules are really so tight, having a "BES 2.0" that uses WS-Agreement might be wiser.) > > 3) There was a bit of the lingering anti-wsrf sentiment floating > > around Seoul. > > There has been some excellent discussion on the OGSA-WG list just prior > to this meeting on whether or not WS-RF is necessary, and if it is, > what is it necessary for? But to be fair, it's not "sentiment" - there > are some very astute people saying that the Grid community doesn't need > WS-RF. Unfortunately, in Seoul, there was practically no debate on > this subject (at least, not inside of the WG sessions!). I would > expect to see this being played out in the OGSA-BES list. It's a > debate that needs to happen. Well, I would hope BES only considers its applicability to job submission/management! If there needs to be a larger architectural debate like whether "the Grid community [needs] WS-RF", it needs to happen in a broader context. I only brought it up because WS-Agreement is obviously WSRF-based, so in order to adopt WS-Agreement soon, the BES group would have to agree on the underlying technologies almost immediately. > > Jon. karl -- Karl Czajkowski karlcz at univa.com From karlcz at univa.com Mon Mar 21 16:13:07 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 22 Mar 2005 05:13:07 +0700 Subject: [graap-wg] Telecon on 3/21 In-Reply-To: References: <423E5B7A.1010004@hpl.hp.com> <423E9323.4020409@mtg.biglobe.ne.jp> <20050321093623.GA30298@moraine.localdomain> <423EA27E.1090505@mtg.biglobe.ne.jp> <20050321114924.GA450@moraine.localdomain> Message-ID: <20050321221307.GA3567@moraine.localdomain> Wow! I thought we'd discussed this ad nauseum in GRAAP face-to-faces, so I neglected to mention it. I see GRAM as being obsolete once WS-Agreement is available to form agreements bearing JSDL terms. The only bits of GRAM that might need to remain are some extended operations or RPs on the Agreement itself. karl On Mar 21, Jon MacLaren loaded a tape reading: ... > The GRAAP-WG charter does not address job submission. It addresses > resource allocation. We used advance reservation for computational > jobs as a use case. However, we make clear that the claiming of the > resources, i.e. the job submission part of that use case, is not > something that the GRAAP-WG would address. > > >This is why I frame this as a misunderstanding/public relations > >problem. There are not open questions for how WS-Agreement SHOULD > >handle jobs except that we haven't publicized the the answers well > >enough. :-) > > I can understand that the decoupling of the resource allocation from > the job submission is only one architectural viewpoint. In private > discussions that I've had with non-GGF participants, they have wanted > to view the resource allocation, job submission, and job execution as a > single "business transaction". That's a completely valid viewpoint. > However, it is different from the one described in the charter, where > we view these as separate concerns. > > Perhaps this is where people's misconceptions come from. > > Perhaps you could clarify exactly where you view a GRAM-type protocol > fitting in with WS-Agreement? Perhaps some sort of sequence diagram. > Do you envisage the user have a separate interaction with GRAM to > create/submit/launch the underlying computational job? > > Jon. -- Karl Czajkowski karlcz at univa.com From maclaren at cct.lsu.edu Mon Mar 21 17:18:36 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Mon, 21 Mar 2005 17:18:36 -0600 Subject: [graap-wg] Telecon on 3/21 In-Reply-To: <20050321221307.GA3567@moraine.localdomain> References: <423E5B7A.1010004@hpl.hp.com> <423E9323.4020409@mtg.biglobe.ne.jp> <20050321093623.GA30298@moraine.localdomain> <423EA27E.1090505@mtg.biglobe.ne.jp> <20050321114924.GA450@moraine.localdomain> <20050321221307.GA3567@moraine.localdomain> Message-ID: Hi Karl, Ok, I wasn't at the face-to-face meetings - I should have read the minutes. But then I was out of the loop for a while during those times. But where would someone new to the group pick up this information? It is likely that a new user would read the group charter, the use cases, and then the example in the specification. Lets look at each of these in turn. 1. If you look at the charter, it only mentions doing advance reservation of the resources - doesn't mention job submission. 2. The use cases talk in terms of SNAP, with the reservation that is being made by GRAAP being an RSLA. It also states that TSLAs (i.e. the running job) are created when something is submitted (something like) a batch queue. 3. And even if you look in Appendix 2 of the specification, you don't state whether or not the user needs to do something else to make the job "happen". (The only hint that this might automatically happen is that the user specifies many things here, far more than a system would need merely to reserve resources - but it's totally implicit.) So no wonder people are confused... Why don't you put together a simple informational document that shows the process of a user creating a job using WS-Agreement, the staging in of files, the execution, and staging out of results. Something that shows all the interactions between the user, the agreement provider, the resource manager, etc. The authors of the spec obviously have very clear intentions about this - they should be clearly stated somewhere! I think that such a document would be very valuable at this point. It could also be a valuable input to the BES group, to show you their intent - I didn't pick up on your viewpoint from your presentation in Seoul, and I think I was pretty awake at that point (you were lucky :-). The group might also want to consider updating the charter. Jon. On Mar 21, 2005, at 4:13 PM, Karl Czajkowski wrote: > Wow! I thought we'd discussed this ad nauseum in GRAAP face-to-faces, > so I neglected to mention it. > > I see GRAM as being obsolete once WS-Agreement is available to form > agreements bearing JSDL terms. The only bits of GRAM that might > need to remain are some extended operations or RPs on the Agreement > itself. > > karl > > > On Mar 21, Jon MacLaren loaded a tape reading: > ... >> The GRAAP-WG charter does not address job submission. It addresses >> resource allocation. We used advance reservation for computational >> jobs as a use case. However, we make clear that the claiming of the >> resources, i.e. the job submission part of that use case, is not >> something that the GRAAP-WG would address. >> >>> This is why I frame this as a misunderstanding/public relations >>> problem. There are not open questions for how WS-Agreement SHOULD >>> handle jobs except that we haven't publicized the the answers well >>> enough. :-) >> >> I can understand that the decoupling of the resource allocation from >> the job submission is only one architectural viewpoint. In private >> discussions that I've had with non-GGF participants, they have wanted >> to view the resource allocation, job submission, and job execution as >> a >> single "business transaction". That's a completely valid viewpoint. >> However, it is different from the one described in the charter, where >> we view these as separate concerns. >> >> Perhaps this is where people's misconceptions come from. >> >> Perhaps you could clarify exactly where you view a GRAM-type protocol >> fitting in with WS-Agreement? Perhaps some sort of sequence diagram. >> Do you envisage the user have a separate interaction with GRAM to >> create/submit/launch the underlying computational job? >> >> Jon. > > -- > Karl Czajkowski > karlcz at univa.com > From karlcz at univa.com Mon Mar 21 17:44:45 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 22 Mar 2005 06:44:45 +0700 Subject: [graap-wg] Telecon on 3/21 In-Reply-To: References: <423E5B7A.1010004@hpl.hp.com> <423E9323.4020409@mtg.biglobe.ne.jp> <20050321093623.GA30298@moraine.localdomain> <423EA27E.1090505@mtg.biglobe.ne.jp> <20050321114924.GA450@moraine.localdomain> <20050321221307.GA3567@moraine.localdomain> Message-ID: <20050321234445.GE3567@moraine.localdomain> On Mar 21, Jon MacLaren loaded a tape reading: > Hi Karl, > > Ok, I wasn't at the face-to-face meetings - I should have read the > minutes. But then I was out of the loop for a while during those > times. But where would someone new to the group pick up this > information? It is likely that a new user would read the group > charter, the use cases, and then the example in the specification. > Lets look at each of these in turn. > We're in agreement. That's why I said people do not understand how to use WS-Agreement and GRAAP-WG needs to do a better job of communicating its design goals and expected usage scenarios. :-) > Why don't you put together a simple informational document that shows > the process of a user creating a job using WS-Agreement, the staging in > of files, the execution, and staging out of results. Something that > shows all the interactions between the user, the agreement provider, > the resource manager, etc. The authors of the spec obviously have very > clear intentions about this - they should be clearly stated somewhere! > I think there was a momentary identity crisis in GRAAP-WG back about 1.5 years ago, when the generalization thought process was in full swing and some folks started reacting negatively to domain-specific instantiations as "out of scope." I hope we have that out of our systems now... > I think that such a document would be very valuable at this point. It > could also be a valuable input to the BES group, to show you their > intent - I didn't pick up on your viewpoint from your presentation in > Seoul, and I think I was pretty awake at that point (you were lucky > :-). > Really?? I feel like I am in the Twilight Zone... I thought I said explicitly that WS-Agreement is a generalization of the GRAM pattern for "creating a job" and could use JSDL instead of our GRAM job language. I then added that this had to be weighed against their milestones to decide whether to do it or take a more traditional approach, and gave due warning about the difficulty of rendering either type of interface on a short schedule, i.e. the devil is in the details, and the traditional approach is not necessarily the conservative approach since it can lead to repetition of mistakes. > The group might also want to consider updating the charter. > > Jon. > karl -- Karl Czajkowski karlcz at univa.com From maclaren at cct.lsu.edu Mon Mar 21 19:07:24 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Mon, 21 Mar 2005 19:07:24 -0600 Subject: [graap-wg] Telecon on 3/21 In-Reply-To: <20050321234445.GE3567@moraine.localdomain> References: <423E5B7A.1010004@hpl.hp.com> <423E9323.4020409@mtg.biglobe.ne.jp> <20050321093623.GA30298@moraine.localdomain> <423EA27E.1090505@mtg.biglobe.ne.jp> <20050321114924.GA450@moraine.localdomain> <20050321221307.GA3567@moraine.localdomain> <20050321234445.GE3567@moraine.localdomain> Message-ID: On Mar 21, 2005, at 5:44 PM, Karl Czajkowski wrote: > >> I think that such a document would be very valuable at this point. It >> could also be a valuable input to the BES group, to show you their >> intent - I didn't pick up on your viewpoint from your presentation in >> Seoul, and I think I was pretty awake at that point (you were lucky >> :-). >> > > Really?? I feel like I am in the Twilight Zone... > > I thought I said explicitly that WS-Agreement is a generalization of > the GRAM pattern for "creating a job" and could use JSDL instead of > our GRAM job language. I then added that this had to be weighed > against their milestones to decide whether to do it or take a more > traditional approach, and gave due warning about the difficulty of > rendering either type of interface on a short schedule, i.e. the devil > is in the details, and the traditional approach is not necessarily the > conservative approach since it can lead to repetition of mistakes. Fair enough - I expect that I was wrong about my state of awakeness. (This leads me to wonder what WG sessions I *was* awake for...) I still like the idea of an information document, though. Cheers, Jon. From karlcz at univa.com Mon Mar 21 20:00:21 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 22 Mar 2005 09:00:21 +0700 Subject: [graap-wg] possibility of H.323 conferencing Message-ID: <20050322020021.GK3567@moraine.localdomain> Carl Kesselman at USC/ISI has generously offered to let GRAAP-WG use their H.323 "MCU" which is basically a central controller to allow multi-way video and audio conferencing, including telephone bridging (by dialing a number in Los Angeles). He thinks it can host at least 16 participants, though I am not sure at what point it becomes silly to try to use video. :-) We would need to get a few willing experimentalists to try to test out the waters before actually scheduling a GRAAP-WG working session on it. I am trying to guage interest and I will then coordinate w/ people in his group to find out how we can test and use it without undue load on his staff. Are there GRAAP-WG participants willing to experiment with a software or hardware H.323 client on their end at possibly strange morning or evening hours? I will test gnomemeeting software on Linux from here, and standalone or PC-based Polycom video conferencing should also work fine. I will only be trying the audio capability at first, but those with video capability should be able to see one another too. I think there is a registration/manager process to associate H.323 client IP addresses w/ sessions or "rooms", so it requires a little more coordination than dialing a single remote peer. karl -- Karl Czajkowski karlcz at univa.com From t-nakata at cw.jp.nec.com Mon Mar 21 22:44:32 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Tue, 22 Mar 2005 13:44:32 +0900 Subject: [graap-wg] Telecon on 3/21 In-Reply-To: <20050321114924.GA450@moraine.localdomain> References: <423E5B7A.1010004@hpl.hp.com> <423E9323.4020409@mtg.biglobe.ne.jp> <20050321093623.GA30298@moraine.localdomain> <423EA27E.1090505@mtg.biglobe.ne.jp> <20050321114924.GA450@moraine.localdomain> Message-ID: <423FA2B0.6070707@cw.jp.nec.com> Hi Karl Czajkowski wrote: >On Mar 21, Toshiyuki Nakata loaded a tape reading: >... > > >>1)If you loook at the two layered picture of Agreeement Services and the >>lower level, Real services (Such as Job submission etc), My >>understanding is BES has to deal with the Serive layer beneath the >>Agreement Factory layer. >> >> >> > >I am not 100% certain that I understood your comment after this one, >because I want to read it as stating something close to what I think I >have been saying, but as I said at the BES BoF, this "Agreement + job >submission" view is a misunderstanding of WS-Agreement's service >abstraction. "Job submission" is not the service layer we would >envision beneath the Agreement management layer, because the >submission pattern is exactly what WS-Agreement is meant to address. > > Sorry I should not have used the word job-submission. I had meant to say Interfaces for the service layer which could include job creation >Specifically, agreements about "generic execution jobs" or "specific >kinds of job" are what we intended the basic agreement creation >pattern to handle. Creation==submission. > Am I correct in understanding that (Agreement ) Creation == (Job) submission? Best regards -- 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 karlcz at univa.com Mon Mar 21 23:07:31 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 22 Mar 2005 12:07:31 +0700 Subject: [graap-wg] Telecon on 3/21 In-Reply-To: <423FA2B0.6070707@cw.jp.nec.com> References: <423E5B7A.1010004@hpl.hp.com> <423E9323.4020409@mtg.biglobe.ne.jp> <20050321093623.GA30298@moraine.localdomain> <423EA27E.1090505@mtg.biglobe.ne.jp> <20050321114924.GA450@moraine.localdomain> <423FA2B0.6070707@cw.jp.nec.com> Message-ID: <20050322050731.GO3567@moraine.localdomain> On Mar 22, Toshiyuki Nakata loaded a tape reading: > >Specifically, agreements about "generic execution jobs" or "specific > >kinds of job" are what we intended the basic agreement creation > >pattern to handle. Creation==submission. > > > Am I correct in understanding that > (Agreement ) Creation == (Job) submission? > Yes, or to put it more concretely: wsag:createAgreement(...jsdl:job...) should be a reasonable replacement for gram:createManagedJob(...gram:job...). If we (Globus) do this and there are job-related mechanisms we wish to keep, we might augment the Agreement portType with those operations and/or RPs. Given the way JSDL has gone, it will be up to the context of the JSDL document in the Agreement to indicate that the agreement is about executing the job. They have the word "submission" in the JSDL name, but I think that is more about scoping the set of job-related information that is captured in the JSDL specification. A lot of what/why the JSDL document exists is left to the messaging context that makes use of the specification. For example, one could easily describe two JSDL-bearing agreement idioms: 1) Advance reservation for job, indicating that the initiator wants a promise that such a job can be accepted later. Additional schedule/deadline terms may be introduced since JSDL leaves them out of scope. One can imagine omitting parts of the JSDL or having some other markup/annotations to indicate that some parts are variable and will be fixed later in the "submission" agreement. 2) Job execution, indicating that the initiator wants a promise that such a job should be executed. One can imagine optionally referencing a reservation Agreement in this Agreement, either through the JSDL extensibility or through some other WS-Agreement extensibility. I would be interested in others' opinions on whether an extra bit of wrapping XML is needed around the JSDL in the service description to distinguish these kinds of agreement, versus some other guarantee term that distinguishes "execute job J" from "be able to execute job J". This is the whole subtle RSLA/TSLA/BSLA distinction from SNAP, and I believe it is largely an aesthetic issue to perfer it rendered one way or another... however, if we do not provide guidance on expected use, I expect all the early adopters of WS-Agreement will do wildly different things because there are too many combinatorial avenues for composing terms and concepts here. karl -- Karl Czajkowski karlcz at univa.com From t-nakata at cw.jp.nec.com Tue Mar 22 00:12:56 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Tue, 22 Mar 2005 15:12:56 +0900 Subject: [graap-wg] Telecon on 3/21 In-Reply-To: <20050322050731.GO3567@moraine.localdomain> References: <423E5B7A.1010004@hpl.hp.com> <423E9323.4020409@mtg.biglobe.ne.jp> <20050321093623.GA30298@moraine.localdomain> <423EA27E.1090505@mtg.biglobe.ne.jp> <20050321114924.GA450@moraine.localdomain> <423FA2B0.6070707@cw.jp.nec.com> <20050322050731.GO3567@moraine.localdomain> Message-ID: <423FB768.5070309@cw.jp.nec.com> Karl Czajkowski wrote: >On Mar 22, Toshiyuki Nakata loaded a tape reading: > > > >>>Specifically, agreements about "generic execution jobs" or "specific >>>kinds of job" are what we intended the basic agreement creation >>>pattern to handle. Creation==submission. >>> >>> >>> >>Am I correct in understanding that >>(Agreement ) Creation == (Job) submission? >> >> >> > >Yes, or to put it more concretely: > > wsag:createAgreement(...jsdl:job...) > >should be a reasonable replacement for > > gram:createManagedJob(...gram:job...). > >If we (Globus) do this and there are job-related mechanisms we wish to >keep, we might augment the Agreement portType with those operations >and/or RPs. > >Given the way JSDL has gone, it will be up to the context of the JSDL >document in the Agreement to indicate that the agreement is about >executing the job. They have the word "submission" in the JSDL name, >but I think that is more about scoping the set of job-related >information that is captured in the JSDL specification. A lot of >what/why the JSDL document exists is left to the messaging context >that makes use of the specification. > Yes, we do have something like that in mind ( of using JSDL document within WS-Agreement ..) > >For example, one could easily describe two JSDL-bearing agreement >idioms: > > 1) Advance reservation for job, indicating that the initiator > wants a promise that such a job can be accepted later. Additional > schedule/deadline terms may be introduced since JSDL leaves them > out of scope. > > One can imagine omitting parts of the JSDL or having some other > markup/annotations to indicate that some parts are variable > and will be fixed later in the "submission" agreement. > > 2) Job execution, indicating that the initiator wants a promise > that such a job should be executed. > > One can imagine optionally referencing a reservation Agreement in > this Agreement, either through the JSDL extensibility or through > some other WS-Agreement extensibility. > >I would be interested in others' opinions on whether an extra bit of >wrapping XML is needed around the JSDL in the service description to >distinguish these kinds of agreement, versus some other guarantee term >that distinguishes "execute job J" from "be able to execute job J". > Hmmm. in business oriented jobs we would have a life-cycle of Job reservation Deployment of the application (including data-bases) Starting the Application Stopping the Application Undeploying the Application And had assumed that the ageement provider which would understand this kind of job would be able to understand this without having it explicitly stated.. (Also, except for Jobreservation, Deploying/Starting/Stopping/Undeploying would be interfaces of the service provider and not the Agreement Provider.. (I am afraid I am getting off the WS-Agreement topic and so would stop here..) Best regards Toshi > >This is the whole subtle RSLA/TSLA/BSLA distinction from SNAP, and I >believe it is largely an aesthetic issue to perfer it rendered one way >or another... however, if we do not provide guidance on expected use, >I expect all the early adopters of WS-Agreement will do wildly >different things because there are too many combinatorial avenues for >composing terms and concepts here. > > >karl > > > -- 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 karlcz at univa.com Tue Mar 22 00:40:12 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 22 Mar 2005 13:40:12 +0700 Subject: [graap-wg] Telecon on 3/21 In-Reply-To: <423FB768.5070309@cw.jp.nec.com> References: <423E5B7A.1010004@hpl.hp.com> <423E9323.4020409@mtg.biglobe.ne.jp> <20050321093623.GA30298@moraine.localdomain> <423EA27E.1090505@mtg.biglobe.ne.jp> <20050321114924.GA450@moraine.localdomain> <423FA2B0.6070707@cw.jp.nec.com> <20050322050731.GO3567@moraine.localdomain> <423FB768.5070309@cw.jp.nec.com> Message-ID: <20050322064012.GS3567@moraine.localdomain> On Mar 22, Toshiyuki Nakata loaded a tape reading: ... > Hmmm. in business oriented jobs we would have a life-cycle of > > Job reservation > Deployment of the application (including data-bases) > Starting the Application > Stopping the Application > Undeploying the Application > > And had assumed that the ageement provider which would understand this > kind of job would > be able to understand this without having it explicitly stated.. > > (Also, except for Jobreservation, > Deploying/Starting/Stopping/Undeploying would be > interfaces of the service provider and not the Agreement Provider.. > > > (I am afraid I am getting off the WS-Agreement topic and so would stop > here..) > > Best regards > Toshi > The job life-cycle you describe is more along the lines of "job submission or service deployment with guarantees" than "advance reservation". All we need to do is add some performance guarantee terms together with the JSDL and the job host can handle all the planning in one step. This is an interesting area where job submission (or generically, service deployment) can be extended with guarantee terms without fundamentally changing the signalling protocol. I think the starting/stopping etc. are additional (optional) management operations on the newly deployed service. We have something similar in GRAM, where we support "hold states" that can pause the otherwise automatic lifecycle. Another rendering choice is whether these management operations are part of the service or part of the "container". We take the latter view in GRAM, so they would extend the Agreement interface which already represents our new transient container for jobs. The actual user job (deployed service) may or may not have any meaningful message interfaces of its own (web or otherwise). I think this is the way to generalize for BES in the way Andrew has advocated, where "jobs" may be of different types, e.g. a web service, a JVM, a fortran code, etc.! You can easily see how a broker might satisfy an abstract web service obligation by establishing more "concrete" agreements to run the underlying implementation components. Advance reservation, in the sense described in the GARA and SNAP work on which this was based, is the explicit decoupling of the "resource promise" from the binding of the resource to a service. It is a 2-phase protocol where one negotiates for the promise of capability and then later binds or "claims" the resource. It is not strictly necessary unless one needs to defer the binding decision or parameterization or deal with differences in cardinality, but it is what I was referring to when I described it separately from job-submission. This is a capability that multiple current batch schedulers possess, and I expect we should be able to expose it via WS-Agreement. karl -- Karl Czajkowski karlcz at univa.com From karlcz at univa.com Tue Mar 22 01:37:57 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 22 Mar 2005 14:37:57 +0700 Subject: [graap-wg] proposal: stateful async agreement Message-ID: <20050322073757.GV3567@moraine.localdomain> I reviewed all of the comments on the GGF tracker, and I do not see any real surprises relative to the "big issues" that have been in discussion. Here, I want to group together a set of possible resolutions that go together if we accept my earlier proposal to handle "asynchronous agreement" via a new stateful Agreement life-cycle. A. Agreements get a new life-cycle state "Pending" which means that an offer has been made but no obligations are in effect yet. The term-level status is undefined at this point. B. Agreements get a new life-cycle state "Rejected" which means that the offer was rejected and no obligations will ever be in effect. C. Agreements get a new life-cycle state "Observed" which means that an offer has been accepted and all obligations are in effect. The term-level status is meaningful at this point. This state captures the semantics of the entire lifespan of the Dec 2004 draft (module the confusion around termination). 1. The life-cycle model includes transitions Pending->Observed and Pending->Rejected but NOT Observed->Rejected. 2. Additional states may be warranted to try to resolve the many questions surrounding "termination" and "expiration." D. The existing createAgreement operation remains as an interaction where an input offer initiates a synchronous acceptance decision; the response is either a fault for rejection or an EPR to an Agreement that MUST already be in the Observed state. 1. The optional initiatorAgreement EPR is retained but the responder is under no obligation to invoke anything on this service. It is an optional avenue for the responder to monitor the "initiator's view" of their agreement. (And to attempt to initiate other control processes?) E. An optional AgreementAcceptance portType is introduced with two operations: acceptAgreement and rejectAgreement. 1. Both operations accept an empty input, as the association with an agreement is implicit via the WSRF addressing model. 2. An optional fault might be useful on rejectAgreement input to communicate why the offer was rejected? 3. These operations are only meaningful when the AgreementAcceptance service is in a Pending state. The operations synchronously change the service state to Observed or Rejected, respectively. 4. The AgreementAcceptance and Agreement portTypes may be merged to form a single service interface, and the state is shared between them. (What is the right way to do this in WSDL? Provide portType combinations in specification?) F. A new createPendingAgreement operation is introduced where an input offer initiates an asynchronous acceptance decision; the response is either a fault (fatal errors/rejection) or an EPR to an Agreement that MAY be in Pending, Observed, or Rejected state. 1. The responder MUST update its state RP to either Observed or Rejected following its decision. 2. The initiator MAY use alternate mechanisms to determine if and when the Agreement transfers to Observed, including but not limited to the querying of a state RP. Until the initiator determines the state as changed to Observed or Rejected, it SHOULD NOT assume the outcome. 3. An optional initiatorAcceptance EPR MAY appear in the input message, in which case the responder MUST invoke acceptAgreement or rejectAgreement to communicate its decision, in addition to updating its state RP. 4. An optional initiatorAgreement EPR MAY appear as in createAgreement. This EPR MAY be the same as the initiatorAcceptance EPR, if the service implements both interfaces. 5. Should the output allow an optional state indicator? I think it is simpler to say "no" and uniformly assume an interaction after creation. G. Topic "Changing Offers" is resolved as the input offer is accepted or rejected WITHOUT MODIFICATION by the agreement acceptance decision. Because of this, no response Agreement document is required in any of the above mechanisms. 1. Should there be an optional mechanism to retrieve the agreement document from the responder in such a way that it MAY be signed or otherwise held as proof of acceptance for auditing purposes? If so, does a queryable "agreement RP" satisfy this need? karl -- Karl Czajkowski karlcz at univa.com From t-nakata at cw.jp.nec.com Tue Mar 22 01:52:02 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Tue, 22 Mar 2005 16:52:02 +0900 Subject: [graap-wg] proposal: stateful async agreement In-Reply-To: <20050322073757.GV3567@moraine.localdomain> References: <20050322073757.GV3567@moraine.localdomain> Message-ID: <423FCEA2.5040405@cw.jp.nec.com> Hi karl thank you very much for your suggestion. Just to clarify.. May I understand that AgreementAcceptance portType is on the Agreement Initiator side and not on the Agreement Provider side? Best Regards Toshi > E. An optional AgreementAcceptance portType is introduced with two > operations: acceptAgreement and rejectAgreement. > > 1. Both operations accept an empty input, as the association with > an agreement is implicit via the WSRF addressing model. > > 2. An optional fault might be useful on rejectAgreement input to > communicate why the offer was rejected? > > 3. These operations are only meaningful when the > AgreementAcceptance service is in a Pending state. The > operations synchronously change the service state to Observed > or Rejected, respectively. > > 4. The AgreementAcceptance and Agreement portTypes may be merged > to form a single service interface, and the state is shared > between them. (What is the right way to do this in WSDL? > Provide portType combinations in specification?) > > -- 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 karlcz at univa.com Tue Mar 22 01:40:41 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 22 Mar 2005 14:40:41 +0700 Subject: [graap-wg] terminal fault type Message-ID: <20050322074041.GW3567@moraine.localdomain> I think we can safely remove the terminal fault type from the appendix. It is a leftover from the negotiation interface when we were perhaps trying to be too sophisticated. The idea was to be able to distinguish to kinds of fault when invoking against a stateful resource: 1) the usual kind, which means the operation failed 2) terminal kind, which means not only did it fail, but you broke the resource permanently :-) This can be handled by returning the regular kind of fault and then finding that there is a "resource unknown" fault on a future invocation, just like if the resource terminates asynchronously. We did suggest this topic to the WSRF folks and they didn't seem to make it a priority. I don't see why we should either. karl -- Karl Czajkowski karlcz at univa.com From karlcz at univa.com Tue Mar 22 01:53:34 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 22 Mar 2005 14:53:34 +0700 Subject: [graap-wg] proposal: agreement lifecycle end-games Message-ID: <20050322075334.GX3567@moraine.localdomain> I think the best solution to this termination/expiration mess is to separate completely the notions of "lifetime of obligations" and "lifetime of Agreement interface". A. The lifetime of obligations should be captured solely in term-level meta-data and/or domain-specific lifecycle models. Individual service or guaranatee terms MAY have expiration times on them that are set statically or renegotiated by a mechanism outside the scope of our first specification. Additionally, some obligations MAY last indefinitely or until some domain-specific events occur. B. The lifetime of the service interface SHOULD be greater than the effective lifetime of any obligations, but I guess I can accept that this may not be possible with limited Agreement implementation QoS. It is hard to be normative about such failure modes. C. I suggest that we drop (for now) any notion of terminating the obligations using WS-Agreement mechanisms. If we can find a clear proposal for handling such ammendment of obligations before the spec is done, I am not personally against reincorporating it in some form. D. I suggest that we defer to WS-ResourceLifetime for handling the termination of the Agreement resource itself, with the specification advocating the above "SHOULD" about Agreements outlasting their embedded obligations (B). E. We should introduce an agreement-wide state, complementing the proposed Pending/Rejected/Observed states, to represent the Complete or PostObserved condition where all terms have passed "out of scope" and into history. What is the best state name for this? F. Should we introduce any kind of "linger" time to indicate an interaction with WS-ResourceLifetime to commence an automatic countdown to Agreement destruction once it has reached the Complete or PostObserved state? karl -- Karl Czajkowski karlcz at univa.com From karlcz at univa.com Tue Mar 22 01:55:52 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 22 Mar 2005 14:55:52 +0700 Subject: [graap-wg] proposal: stateful async agreement In-Reply-To: <423FCEA2.5040405@cw.jp.nec.com> References: <20050322073757.GV3567@moraine.localdomain> <423FCEA2.5040405@cw.jp.nec.com> Message-ID: <20050322075552.GY3567@moraine.localdomain> On Mar 22, Toshiyuki Nakata loaded a tape reading: > Hi karl thank you very much for your suggestion. > Just to clarify.. > > May I understand that > > AgreementAcceptance portType is on the Agreement Initiator side and not > on the Agreement Provider side? > > Best Regards > Toshi > Yes. It is the return signal path for a symmetric (peer-to-peer) variant of the asynchronous exchange. Do you think we need an explicit responder-side polling interface too? I had hoped RP query would be enough for the ugly client-server pattern, since we can return the (Pending) Agreement EPR immediately. karl -- Karl Czajkowski karlcz at univa.com From karlcz at univa.com Tue Mar 22 02:08:01 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 22 Mar 2005 15:08:01 +0700 Subject: [graap-wg] composition/extension model for states? Message-ID: <20050322080647.GZ3567@moraine.localdomain> In both the term-level and my newly proposed agreement-level states, there is a modeling concern as to whether domain-specific or community-specific extensions of the state model are allowed. 1. [I do not like:] allowing arbitrary new states to replace existing states in the basic machine, e.g. the state machine can be in "no state" according to a basic client/observer who doesn't recognize extended states. 2. Allow "sub-states" which turn the basic state machine into a hyphergraph where specialized state transfers can happen "within" a generic state but transition rules between super states should be respected still. A. Encode sub-states as extensibility content within the basic state elements, meaning document structure follows the generic rules and extra content "flickers" within that structure. This approach can be applied recursively to extend extensions! B. Encode sub-states as sibling RPs to the basic state elements. This allows stacking/mixing of multiple state models but any consistency model between the various RPs is left unaddressed. C. Hybrid of (A) and (B) where basic non-extended content remains and a new extended variant is places alongside. This avoids the consistency issue of having to inspect both generic and specialized RPs, and also avoids requiring basic clients to filter or "project" extended states down to the base version they recognize. Do we have a clear consensus on which approach is advocated for WS-Agreement? I think extended states will be important both to address domain-specific things like "job states" as well as to compose with negotiation systems in the future. Thoughts? karl -- Karl Czajkowski karlcz at univa.com From t-nakata at cw.jp.nec.com Tue Mar 22 02:21:43 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Tue, 22 Mar 2005 17:21:43 +0900 Subject: [graap-wg] proposal: stateful async agreement In-Reply-To: <20050322075552.GY3567@moraine.localdomain> References: <20050322073757.GV3567@moraine.localdomain> <423FCEA2.5040405@cw.jp.nec.com> <20050322075552.GY3567@moraine.localdomain> Message-ID: <423FD597.3060308@cw.jp.nec.com> Karl Czajkowski wrote: >On Mar 22, Toshiyuki Nakata loaded a tape reading: > > >>Hi karl thank you very much for your suggestion. >>Just to clarify.. >> >>May I understand that >> >>AgreementAcceptance portType is on the Agreement Initiator side and not >>on the Agreement Provider side? >> >>Best Regards >>Toshi >> >> >> > >Yes. It is the return signal path for a symmetric (peer-to-peer) >variant of the asynchronous exchange. > If I understand correctly, except for the names and the arguments it is quite similar to what Takuya was proposing... (Please refer to the PPT to see if i am mistaken or not) | > Do you think we need an >explicit responder-side polling interface too? I had hoped RP query >would be enough for the ugly client-server pattern, since we can >return the (Pending) Agreement EPR immediately. > If we are to rely on WS-RP, I think we can rely on the RP query. I think this matter is still under discussion (No. 15 in my Comment list) https://forge.gridforum.org/forum/message.php?msg_id=1004 Best regards Toshi > >karl > > > -- 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: Usage of createAgreementAsync(3).ppt Type: application/vnd.ms-powerpoint Size: 25088 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20050322/22964625/attachment.ppt From karlcz at univa.com Tue Mar 22 02:28:55 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 22 Mar 2005 15:28:55 +0700 Subject: [graap-wg] proposal: stateful async agreement In-Reply-To: <423FD597.3060308@cw.jp.nec.com> References: <20050322073757.GV3567@moraine.localdomain> <423FCEA2.5040405@cw.jp.nec.com> <20050322075552.GY3567@moraine.localdomain> <423FD597.3060308@cw.jp.nec.com> Message-ID: <20050322082855.GB3567@moraine.localdomain> On Mar 22, Toshiyuki Nakata loaded a tape reading: > > >Yes. It is the return signal path for a symmetric (peer-to-peer) > >variant of the asynchronous exchange. > > > > If I understand correctly, except for the names and the arguments it is > quite similar to > what Takuya was proposing... (Please refer to the PPT to see if i am > mistaken or not) > Yes, I hope it is similar. I am just trying to do it in the same WSRF style as the existing features and rescue the existing draft's broken "symmetric agreement" mechanisms at the same time! > If we are to rely on WS-RP, I think we can rely on the RP query. > I think this matter is still under discussion (No. 15 in my Comment list) > > https://forge.gridforum.org/forum/message.php?msg_id=1004 > Ah, OK. I did not realize this was under discussion. karl -- Karl Czajkowski karlcz at univa.com From t-nakata at cw.jp.nec.com Tue Mar 22 02:40:51 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Tue, 22 Mar 2005 17:40:51 +0900 Subject: [graap-wg] proposal: stateful async agreement In-Reply-To: <20050322073757.GV3567@moraine.localdomain> References: <20050322073757.GV3567@moraine.localdomain> Message-ID: <423FDA13.3000204@cw.jp.nec.com> Sorry to ask many snippets of questions rather than chunk them to gether. If an initiator issed five different createPendingAgreement operations, May I understand that it is the initiator's responsibility to create 5 different initiatorAcceptance EPR so that the response might be discriminated properly? > F. A new createPendingAgreement operation is introduced where an > input offer initiates an asynchronous acceptance decision; the > response is either a fault (fatal errors/rejection) or an EPR to > an Agreement that MAY be in Pending, Observed, or Rejected state. > > 1. The responder MUST update its state RP to either Observed or > Rejected following its decision. > > 2. The initiator MAY use alternate mechanisms to determine if and > when the Agreement transfers to Observed, including but not > limited to the querying of a state RP. Until the initiator > determines the state as changed to Observed or Rejected, it > SHOULD NOT assume the outcome. > > 3. An optional initiatorAcceptance EPR MAY appear in the input > message, in which case the responder MUST invoke > acceptAgreement or rejectAgreement to communicate its > decision, in addition to updating its state RP. > > 4. An optional initiatorAgreement EPR MAY appear as in > createAgreement. This EPR MAY be the same as the > initiatorAcceptance EPR, if the service implements both > interfaces. > > 5. Should the output allow an optional state indicator? I think > it is simpler to say "no" and uniformly assume an interaction > after creation. > > -- 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 karlcz at univa.com Tue Mar 22 02:30:52 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 22 Mar 2005 15:30:52 +0700 Subject: [graap-wg] proposal: stateful async agreement In-Reply-To: <20050322082855.GB3567@moraine.localdomain> References: <20050322073757.GV3567@moraine.localdomain> <423FCEA2.5040405@cw.jp.nec.com> <20050322075552.GY3567@moraine.localdomain> <423FD597.3060308@cw.jp.nec.com> <20050322082855.GB3567@moraine.localdomain> Message-ID: <20050322083042.GC3567@moraine.localdomain> p.s. I do not think I am really proposing something new here, but trying to summarize the impact of the earlier discussions and hopefully get GRAAP-WG to a more explicit decision or discussion, instead of the implicit consensus we seem to be stuck on. :-) -- Karl Czajkowski karlcz at univa.com From t-nakata at cw.jp.nec.com Tue Mar 22 02:54:58 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Tue, 22 Mar 2005 17:54:58 +0900 Subject: [graap-wg] proposal: stateful async agreement In-Reply-To: <423FDA13.3000204@cw.jp.nec.com> References: <20050322073757.GV3567@moraine.localdomain> <423FDA13.3000204@cw.jp.nec.com> Message-ID: <423FDD62.20006@cw.jp.nec.com> The other option might be to pass the EPR of the Agreement as a parameter... Best regards Toshi Toshiyuki Nakata wrote: > Sorry to ask many snippets of questions rather than chunk them to gether. > > If an initiator issed five different createPendingAgreement operations, > May I understand that it is the initiator's responsibility to create > 5 different initiatorAcceptance EPR so that the response might be > discriminated properly? > >> F. A new createPendingAgreement operation is introduced where an >> input offer initiates an asynchronous acceptance decision; the >> response is either a fault (fatal errors/rejection) or an EPR to >> an Agreement that MAY be in Pending, Observed, or Rejected state. >> >> 1. The responder MUST update its state RP to either Observed or >> Rejected following its decision. >> >> 2. The initiator MAY use alternate mechanisms to determine if and >> when the Agreement transfers to Observed, including but not >> limited to the querying of a state RP. Until the initiator >> determines the state as changed to Observed or Rejected, it >> SHOULD NOT assume the outcome. >> >> 3. An optional initiatorAcceptance EPR MAY appear in the input >> message, in which case the responder MUST invoke >> acceptAgreement or rejectAgreement to communicate its >> decision, in addition to updating its state RP. >> >> 4. An optional initiatorAgreement EPR MAY appear as in >> createAgreement. This EPR MAY be the same as the >> initiatorAcceptance EPR, if the service implements both >> interfaces. >> >> 5. Should the output allow an optional state indicator? I think >> it is simpler to say "no" and uniformly assume an interaction >> after creation. >> >> > -- 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 karlcz at univa.com Tue Mar 22 03:02:47 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 22 Mar 2005 16:02:47 +0700 Subject: [graap-wg] proposal: stateful async agreement In-Reply-To: <423FDA13.3000204@cw.jp.nec.com> References: <20050322073757.GV3567@moraine.localdomain> <423FDA13.3000204@cw.jp.nec.com> Message-ID: <20050322090247.GD3567@moraine.localdomain> On Mar 22, Toshiyuki Nakata loaded a tape reading: > Sorry to ask many snippets of questions rather than chunk them to gether. > > If an initiator issed five different createPendingAgreement operations, > May I understand that it is the initiator's responsibility to create > 5 different initiatorAcceptance EPR so that the response might be > discriminated properly? > Yes, that is the idea... just like with the deliverNotification pattern in WS-BaseNotification. There is nothing particularly expensive about creating EPRs, e.g. new addressable resources. The alternative goes right back into the explicit correlation ID mess, which has all the same requirements for initiators keeping track of IDs and you still have to pass an EPR too. It hurts my brain to think about pairs for addressing. :-) Oh, I see your other email about using the Agreement EPR as a correlation ID. I think that is about the only way to upset the WSRF and anti-WSRF folks equally... ;-) I think EPRs should only be passed around when there is an expectation that a recipient will eventually invoke operations on it. karl -- Karl Czajkowski karlcz at univa.com From t-nakata at cw.jp.nec.com Tue Mar 22 03:17:23 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Tue, 22 Mar 2005 18:17:23 +0900 Subject: [graap-wg] proposal: stateful async agreement In-Reply-To: <20050322090247.GD3567@moraine.localdomain> References: <20050322073757.GV3567@moraine.localdomain> <423FDA13.3000204@cw.jp.nec.com> <20050322090247.GD3567@moraine.localdomain> Message-ID: <423FE2A3.7080409@cw.jp.nec.com> OK. I don't want to have both sides shooting/shouting at me :-) Best Regards Toshi Karl Czajkowski wrote: >On Mar 22, Toshiyuki Nakata loaded a tape reading: > > >>Sorry to ask many snippets of questions rather than chunk them to gether. >> >>If an initiator issed five different createPendingAgreement operations, >>May I understand that it is the initiator's responsibility to create >>5 different initiatorAcceptance EPR so that the response might be >>discriminated properly? >> >> >> > >Yes, that is the idea... just like with the deliverNotification >pattern in WS-BaseNotification. > >There is nothing particularly expensive about creating EPRs, e.g. new >addressable resources. The alternative goes right back into the >explicit correlation ID mess, which has all the same requirements for >initiators keeping track of IDs and you still have to pass an EPR >too. It hurts my brain to think about pairs for addressing. :-) > >Oh, I see your other email about using the Agreement EPR as a >correlation ID. I think that is about the only way to upset the WSRF >and anti-WSRF folks equally... ;-) I think EPRs should only be passed >around when there is an expectation that a recipient will eventually >invoke operations on it. > > >karl > > > -- 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 maclaren at cct.lsu.edu Tue Mar 22 16:39:35 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Tue, 22 Mar 2005 16:39:35 -0600 Subject: [graap-wg] proposal: agreement lifecycle end-games In-Reply-To: <20050322075334.GX3567@moraine.localdomain> References: <20050322075334.GX3567@moraine.localdomain> Message-ID: Good to see a thorough consideration of the lifetime issue. Other than agreeing entirely with dropping the terminate stuff for now, I just wanted to comment on one of the points you made: On Mar 22, 2005, at 1:53 AM, Karl Czajkowski wrote: > ... > F. Should we introduce any kind of "linger" time to indicate an > interaction with WS-ResourceLifetime to commence an automatic > countdown to Agreement destruction once it has reached the Complete > or PostObserved state? It may be OK to "garbage collect" the agreement after all the terms have successfully completed. But where one or more terms have been violated, the initiator will want to be able to point at the agreement for an arbitrary length of time afterwards. They may wish to seek compensation through some out-of-bands methods. Let me give a motivating use-case. Lets say that something goes wrong with the execution of my job. Perhaps we'd agreed that it would execute at 4pm, but it didn't start until 4.30pm. I am offered a partial refund, but want to argue for more. I'll do this by email, but will want to refer to the agreement in some way... Lifetime management for this sort of thing is hard. > > karl > Jon. From karlcz at univa.com Tue Mar 22 20:16:19 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Wed, 23 Mar 2005 09:16:19 +0700 Subject: [graap-wg] proposal: agreement lifecycle end-games In-Reply-To: References: <20050322075334.GX3567@moraine.localdomain> Message-ID: <20050323021619.GA9936@moraine.localdomain> I agree the lifetime management is hard. :-) I wonder if this sort of scenario is not a good point in time for the client/initiator to: 1) Use the Agreement interface to capture the status and/or other identifying information. 2) "Retire" the Agreement by allowing it to be destroyed. 3) Have offline compensation using the captured status and identifying information. As I have said before, I think there is a practical limit to what can be done in the online, automatic system view of WS-Agreement. Shutting down/destroying those interfaces should not necessarily destroy records but just shift the information out of the online message processing system and into audit/accounting. Trying to negotiate compensation between humans is definitely out of scope (and too hard) for WS-Agreement, I would say. I guess I would frame the question as what sort of support is needed to allow such conversations to continue after the Agreement is terminated, e.g. access to "final state" and/or naming information that can be passed around offline? karl On Mar 22, Jon MacLaren loaded a tape reading: ... > It may be OK to "garbage collect" the agreement after all the terms > have successfully completed. But where one or more terms have been > violated, the initiator will want to be able to point at the agreement > for an arbitrary length of time afterwards. They may wish to seek > compensation through some out-of-bands methods. > > Let me give a motivating use-case. > > Lets say that something goes wrong with the execution of my job. > Perhaps we'd agreed that it would execute at 4pm, but it didn't start > until 4.30pm. I am offered a partial refund, but want to argue for > more. I'll do this by email, but will want to refer to the agreement > in some way... > > Lifetime management for this sort of thing is hard. > > > > >karl > > > > Jon. -- Karl Czajkowski karlcz at univa.com From maclaren at cct.lsu.edu Wed Mar 23 09:31:16 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Wed, 23 Mar 2005 09:31:16 -0600 Subject: [graap-wg] proposal: agreement lifecycle end-games In-Reply-To: <20050323021619.GA9936@moraine.localdomain> References: <20050322075334.GX3567@moraine.localdomain> <20050323021619.GA9936@moraine.localdomain> Message-ID: If I can make my point clearer, I'm not saying that human negotiation should be part of WS-Agreement. But, the Agreement information has to remain available as long as it is needed by either party. This is hard to do when the Agreement is a WS-RF style resource (or a service). You proposed that you could allow some way for the initiator to "capture the status" from the Agreement interface. That'd be alright, provided that it was in some form which was signed by the other party. Otherwise, it's not much use - too easy to fake up. (Of course, the user still has to trust the agreement provider to give them this after things have gone wrong.) Just saying that shutting down the interface only moves the data to an audit/accounting system is all very well, but it gives me no idea of how I might retrieve that information, let alone in a standard way. However, if the definitive form of the Agreement were an XML document, signed by both parties, you wouldn't have these problems. People would just keep the agreement document until they felt they no longer needed it. You could still use something like the current Agreement interface for doing all the monitoring stuff. (The lifetime issues for that resource would be simpler.) I also believe, and always have, that having an agreement represented primarily as a document is a far more intuitive approach. I think that the advantages of this representation should be fully considered now. Jon. On Mar 22, 2005, at 8:16 PM, Karl Czajkowski wrote: > I agree the lifetime management is hard. :-) I wonder if this sort of > scenario is not a good point in time for the client/initiator to: > > 1) Use the Agreement interface to capture the status and/or other > identifying information. > > 2) "Retire" the Agreement by allowing it to be destroyed. > > 3) Have offline compensation using the captured status and > identifying information. > > As I have said before, I think there is a practical limit to what can > be done in the online, automatic system view of WS-Agreement. > Shutting down/destroying those interfaces should not necessarily > destroy records but just shift the information out of the online > message processing system and into audit/accounting. > > Trying to negotiate compensation between humans is definitely out of > scope (and too hard) for WS-Agreement, I would say. I guess I would > frame the question as what sort of support is needed to allow such > conversations to continue after the Agreement is terminated, > e.g. access to "final state" and/or naming information that can be > passed around offline? > > karl > > > On Mar 22, Jon MacLaren loaded a tape reading: > ... >> It may be OK to "garbage collect" the agreement after all the terms >> have successfully completed. But where one or more terms have been >> violated, the initiator will want to be able to point at the agreement >> for an arbitrary length of time afterwards. They may wish to seek >> compensation through some out-of-bands methods. >> >> Let me give a motivating use-case. >> >> Lets say that something goes wrong with the execution of my job. >> Perhaps we'd agreed that it would execute at 4pm, but it didn't start >> until 4.30pm. I am offered a partial refund, but want to argue for >> more. I'll do this by email, but will want to refer to the agreement >> in some way... >> >> Lifetime management for this sort of thing is hard. >> >>> >>> karl >>> >> >> Jon. > > -- > Karl Czajkowski > karlcz at univa.com > From karlcz at univa.com Wed Mar 23 10:42:30 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Wed, 23 Mar 2005 23:42:30 +0700 Subject: [graap-wg] proposal: agreement lifecycle end-games In-Reply-To: References: <20050322075334.GX3567@moraine.localdomain> <20050323021619.GA9936@moraine.localdomain> Message-ID: <20050323164230.GA12812@moraine.localdomain> Jon, I do think I understand what you are asking for. The difficulty lies, I think, in the fact that the "WS architecture" way of doing things is to treat security-related things like signature as orthogonal aspects that get folded into a service deployment. The underlying audit/proof problem you are concerned with requires the persistent naming and retention of protocol messages, e.g. "at time T0, party 1 initiated agreement with offer O" and "at time T1, party 2 accepted offer O" in some way that the eventual arbiter can believe them to be accurate historical data. I do not think WSRF makes it harder to think about this. The WS-Agreement resource is not a message, but an addressable representation of the online process within which these messages are correlated. The WSRF modeling approach we are using is about making this process or "session" manageable, in the sense of being able to incorporate these agreement processes into a larger worldview of discovery and monitoring systems, etc. So, the Agreement resource gives us a dynamic view of the "current" status, while I think contract resolution requires an archived view of different key messages/interactions in the process like "agreement happened" and "agreement was violated (or satisfied) during time interval I". I think the question here is whether this "proof of agreement" problem is in or out of scope for the WS-Agreement standard. We have already declared "proof of satisfaction/violation" to be out of scope, so I had assumed proof of agreement would be treated the same way. I think you are asking for "proof of agreement" to be made in scope. I do not know how to do this in a way that is not biased towards one security/trust model, so that makes me afraid to approach it. Can you provide a more concrete proposal, or at least argue for why proof of agreement is different than the larger proof of satisfaction/violation such that we should keep banging our heads on this for the first version of the standard? I'm not discounting the value of these proofs, but merely questioning whether they are tractable enough to put in scope... karl -- Karl Czajkowski karlcz at univa.com From maclaren at cct.lsu.edu Wed Mar 23 14:06:21 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Wed, 23 Mar 2005 14:06:21 -0600 Subject: [graap-wg] proposal: agreement lifecycle end-games In-Reply-To: <20050323164230.GA12812@moraine.localdomain> References: <20050322075334.GX3567@moraine.localdomain> <20050323021619.GA9936@moraine.localdomain> <20050323164230.GA12812@moraine.localdomain> Message-ID: <032d6bf1dd7c7ffc01e1e8568eda865b@cct.lsu.edu> No, I don't think I've explained it properly. It's a lot simpler that your reply suggests. I didn't say the agreement is a message, which you stated in your reply. I said that it should be a document. There is nothing to stop me sending a signed document as part of an XML message irrespective of the message-level/transport-level security stuff. The user proposes an agreement ("offer" to use the terminology in the spec.), and sends this as a signed document. If the respondent agrees, they sign the agreement too, and send it back. You do not need to retain all the messages - just this document, signed by both parties. Of course proof of agreement is out of scope. But if you have the agreement in the form I suggest, at least you give a *basis* on which people can do this. The current WS-Agreement specification doesn't do that. Jon. On Mar 23, 2005, at 10:42 AM, Karl Czajkowski wrote: > Jon, I do think I understand what you are asking for. The difficulty > lies, I think, in the fact that the "WS architecture" way of doing > things is to treat security-related things like signature as > orthogonal aspects that get folded into a service deployment. > > The underlying audit/proof problem you are concerned with requires the > persistent naming and retention of protocol messages, e.g. "at time > T0, party 1 initiated agreement with offer O" and "at time T1, party 2 > accepted offer O" in some way that the eventual arbiter can believe > them to be accurate historical data. > > I do not think WSRF makes it harder to think about this. The > WS-Agreement resource is not a message, but an addressable > representation of the online process within which these messages are > correlated. The WSRF modeling approach we are using is about making > this process or "session" manageable, in the sense of being able to > incorporate these agreement processes into a larger worldview of > discovery and monitoring systems, etc. So, the Agreement resource > gives us a dynamic view of the "current" status, while I think > contract resolution requires an archived view of different key > messages/interactions in the process like "agreement happened" and > "agreement was violated (or satisfied) during time interval I". > > I think the question here is whether this "proof of agreement" problem > is in or out of scope for the WS-Agreement standard. We have already > declared "proof of satisfaction/violation" to be out of scope, so I > had assumed proof of agreement would be treated the same way. > > I think you are asking for "proof of agreement" to be made in scope. I > do not know how to do this in a way that is not biased towards one > security/trust model, so that makes me afraid to approach it. Can you > provide a more concrete proposal, or at least argue for why proof of > agreement is different than the larger proof of satisfaction/violation > such that we should keep banging our heads on this for the first > version of the standard? > > I'm not discounting the value of these proofs, but merely questioning > whether they are tractable enough to put in scope... > > > karl > > -- > Karl Czajkowski > karlcz at univa.com > From karlcz at univa.com Wed Mar 23 20:44:14 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Thu, 24 Mar 2005 09:44:14 +0700 Subject: [graap-wg] proposal: agreement lifecycle end-games In-Reply-To: <032d6bf1dd7c7ffc01e1e8568eda865b@cct.lsu.edu> References: <20050322075334.GX3567@moraine.localdomain> <20050323021619.GA9936@moraine.localdomain> <20050323164230.GA12812@moraine.localdomain> <032d6bf1dd7c7ffc01e1e8568eda865b@cct.lsu.edu> Message-ID: <20050324024414.GB13983@moraine.localdomain> On Mar 23, Jon MacLaren loaded a tape reading: > No, I don't think I've explained it properly. It's a lot simpler that > your reply suggests. > > I didn't say the agreement is a message, which you stated in your > reply. I said that it should be a document. There is nothing to stop > me sending a signed document as part of an XML message irrespective of > the message-level/transport-level security stuff. > Nothing except for the same WS-A guidelines that we would now be violating in making a particular signature algorithm part of the standard. Which method would you suggest? I don't even know what identification standard we can assume for the agreement parties... PKI? Kerberos? ? Which community do we decide is _the_ community for WS-Agreement? I need PKI for Globus Toolkit deployment, but I am sure others need something else. So, if we factor out signature itself as something that must come from a profile of WS-Agreement and security specs, then all we have left is the initiator sending the document once (where it could possibly be signed) and the responder sending it once (where it could possibly be signed). We do not currently have the responder sending the agreement document, since it seemed "redundant" to the people who do not care about this signature dance. I see this as a justifiable reason to put it back in spite of its "redundancy". We could put it in the output of the createAgreement and the input of the acceptAgreement [if we go w/ the proposal I summarized again recently]. Or, we could say that the initiator MAY fetch it anytime after acceptance by fetching an RP containing the document, e.g. AcceptedAgreement, which would be nil until the acceptance decision is made. I don't know how to allow arbitrary signature content to appear within the WS-Agreement messages (where we currently have the agreement doc element). I do, however, think it is trivial to have the sending party sign the _entire_ message and use that rather than trying to embed signature at the application level. However, it seems impossible to mandate that "both" parties have signed the responder-generated document, since we do not have any way of specifying what it means to have signed it. I think that, too, would have to be in a secure-agreement profile. I am not sure it is even strictly necessary, when one can retain the two unilaterally signed messages and present them together to show agreement. karl -- Karl Czajkowski karlcz at univa.com From maclaren at cct.lsu.edu Thu Mar 24 09:40:01 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Thu, 24 Mar 2005 09:40:01 -0600 Subject: [graap-wg] proposal: agreement lifecycle end-games In-Reply-To: <20050324024414.GB13983@moraine.localdomain> References: <20050322075334.GX3567@moraine.localdomain> <20050323021619.GA9936@moraine.localdomain> <20050323164230.GA12812@moraine.localdomain> <032d6bf1dd7c7ffc01e1e8568eda865b@cct.lsu.edu> <20050324024414.GB13983@moraine.localdomain> Message-ID: <30794af39b4af5eb6aa560968bda81ce@cct.lsu.edu> On Mar 23, 2005, at 8:44 PM, Karl Czajkowski wrote: > On Mar 23, Jon MacLaren loaded a tape reading: >> No, I don't think I've explained it properly. It's a lot simpler that >> your reply suggests. >> >> I didn't say the agreement is a message, which you stated in your >> reply. I said that it should be a document. There is nothing to stop >> me sending a signed document as part of an XML message irrespective of >> the message-level/transport-level security stuff. >> > > Nothing except for the same WS-A guidelines that we would now be > violating in making a particular signature algorithm part of the > standard. Which method would you suggest? I don't even know what > identification standard we can assume for the agreement > parties... PKI? Kerberos? ? Which community do > we decide is _the_ community for WS-Agreement? I need PKI for Globus > Toolkit deployment, but I am sure others need something else. I'd imagined using XML Signature for doing this stuff. That allows a number of different methods for signing to be plugged in, and is certainly not specific to any signature algorithm, and I believe it does not fall foul of the WS-A guidelines you mention. If you feel it does, please send a precise reference to some text. For information on XML Signature, see: http://www.w3.org/TR/xmldsig-core/ I don't know a lot about Kerberos, and so I don't know how well that maps onto this idea. Of course, the point of signing something in this context is that you can later show that such-and-such an entity signed something. This must be valid outside of whatever exchange (session) is taking place at the time. Are Kerberos tokens appropriate for this purpose? > So, if we factor out signature itself as something that must come from > a profile of WS-Agreement and security specs, then all we have left is > the initiator sending the document once (where it could possibly be > signed) and the responder sending it once (where it could possibly be > signed). We do not currently have the responder sending the agreement > document, since it seemed "redundant" to the people who do not care > about this signature dance. I see this as a justifiable reason to put > it back in spite of its "redundancy". That would be a good step forward, assuming that you are not suddenly persuaded by what I've written above... > We could put it in the output of the createAgreement and the input of > the acceptAgreement [if we go w/ the proposal I summarized again > recently]. Or, we could say that the initiator MAY fetch it anytime > after acceptance by fetching an RP containing the document, > e.g. AcceptedAgreement, which would be nil until the acceptance > decision is made. I'd want the first suggestion. (I don't object to the second as an *additional* method.) > I don't know how to allow arbitrary signature content to appear within > the WS-Agreement messages (where we currently have the agreement doc > element). I do, however, think it is trivial to have the sending > party sign the _entire_ message and use that rather than trying to > embed signature at the application level. Again, see what I've written above. > However, it seems impossible to mandate that "both" parties have > signed the responder-generated document, since we do not have any way > of specifying what it means to have signed it. I think that, too, > would have to be in a secure-agreement profile. I am not sure it is > even strictly necessary, when one can retain the two unilaterally > signed messages and present them together to show agreement. > > > karl The semantics of what it means, in this context, to have signed the agreement are ours to define. Given that we all understand what it means when we sign a contract or Paper-Agreement, I think that this part is quite simple. Jon. From karlcz at univa.com Thu Mar 24 20:53:25 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Fri, 25 Mar 2005 09:53:25 +0700 Subject: [graap-wg] proposal: agreement lifecycle end-games In-Reply-To: <30794af39b4af5eb6aa560968bda81ce@cct.lsu.edu> References: <20050322075334.GX3567@moraine.localdomain> <20050323021619.GA9936@moraine.localdomain> <20050323164230.GA12812@moraine.localdomain> <032d6bf1dd7c7ffc01e1e8568eda865b@cct.lsu.edu> <20050324024414.GB13983@moraine.localdomain> <30794af39b4af5eb6aa560968bda81ce@cct.lsu.edu> Message-ID: <20050325025325.GB18777@moraine.localdomain> On Mar 24, Jon MacLaren loaded a tape reading: ... > I'd imagined using XML Signature for doing this stuff. That allows a > number of different methods for signing to be plugged in, and is > certainly not specific to any signature algorithm, and I believe it > does not fall foul of the WS-A guidelines you mention. If you feel it > does, please send a precise reference to some text. > > For information on XML Signature, see: > http://www.w3.org/TR/xmldsig-core/ > I have to admit that I am not an expert at the use of XML security standards, so I am largely echoing what I have been told by security and WS experts... > I don't know a lot about Kerberos, and so I don't know how well that > maps onto this idea. Of course, the point of signing something in this > context is that you can later show that such-and-such an entity signed > something. This must be valid outside of whatever exchange (session) > is taking place at the time. Are Kerberos tokens appropriate for this > purpose? > I don't know, but that is the thrust of my point. I am extremely uncomfortable stating that WS-Agreement should try to normatively define/choose a sessionless identification and signing model for agreement parties. I don't think we want to close it off from the communities who do not use such security models. I personally like PKI, but have learned that not everyone does. ;-) I really think this bottomless pit of options needs to be addressed in profiles outside WS-Agreement. But, the advice I have received is that it would be sensible to use XML-Signature "detached" signatures and put them in extended content as a sibling to the agreement document. So, at minimum WS-Agreement should make sure to have appropriate extension points to be able to trigger and exchange extra signature info. To me, this means having an extension model where something like a "request for signature" can be marked MANDATORY in an offer, meaning the responder MUST sign his acceptance message or reject the offer if he is unable/unwilling. In our zeal for extensibility of agreement terms, I am not sure whether we have kept extensibility for these sorts of signaling options. Can we agree on this as a compromise approach? I'd really like to focus on the generic WS-Agreement plumbing and enable experimentation and community-specific profiles to address these sorts of problems on top of the base specification. > >We could put it in the output of the createAgreement and the input of > >the acceptAgreement [if we go w/ the proposal I summarized again > >recently]. Or, we could say that the initiator MAY fetch it anytime > >after acceptance by fetching an RP containing the document, > >e.g. AcceptedAgreement, which would be nil until the acceptance > >decision is made. > > I'd want the first suggestion. (I don't object to the second as an > *additional* method.) > One minor variant, after having bounced this off some people outside GRAAP-WG, is that if we did the first we should retain an ability to do it with or without the verbose response message. I don't know if this should be multiple operations w/ different message typing, or one generic message with some optional control bits in the input to modify the required response? > The semantics of what it means, in this context, to have signed the > agreement are ours to define. Given that we all understand what it > means when we sign a contract or Paper-Agreement, I think that this > part is quite simple. > > Jon. I didn't mean the semantics of signature, but rather how we could specify the syntax of signature without delving into mechanism-specific stuff. In other words, I didn't know how to make a normative statement about presence or absence of signatures. It's a moot point, if we can agree on the more specific discussions above. karl -- Karl Czajkowski karlcz at univa.com From karlcz at univa.com Fri Mar 25 03:43:39 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Fri, 25 Mar 2005 16:43:39 +0700 Subject: [graap-wg] scoping thoughts Message-ID: <20050325094339.GE19936@moraine.localdomain> The recent thread between Jon and me has given me some added clarity as to the framing and scoping of the agreement problem space. Please consider the following as my view of how the agreement concept space is populated and which of these concepts are in or out of scope of WS-Agreement. Note, I have CAPITALIZED certain keywords that I think are the important concepts we need to tease apart. I thought this would be easier than reading HTML or LaTeX tags in the ASCII. :-) Do we have a concensus on these concept definitions and/or scoping? If so, I would be happy to try to rejigger the specification introductory text to better communicate this information. If not, I think it is crucial that we iterate on this until we do have consensus! karl In designing and presenting WS-Agreement, it is useful to define the concept space of agreement. 1. Agreement is a RELATIONSHIP between two parties. The core concept of WS-Agreement is that agreement is a relationship between two parties in which they are obligated to act in certain ways according to a notion of reciprocity. These obligations are necessarily domain-specific, and the reciprocity does not imply symmetry: one party may be obligated to complementary behaviors such as paying for service rather than returning service in kind. The semantics of this relationship are out of scope of WS-Agreement because they are domain-dependent. 2. WS-Agreement defines a PROTOCOL for establishing agreement. The fundamental resource management challenge being addressed by WS-Agreement is the standardization of a signaling protocol to allow temporary two-party agreement relationships to be established, maintained, and retired in a decentralized, multi-party, distributed system. These agreements modify, or parameterize, the behavior of the parties towards one another while respecting global system constraints on available resources etc. The mechanics and syntax of this protocol, except for the embedded domain-specific content, are within scope of WS-Agreement. 3. The WS-Agreement protocol encodes an agreement DOCUMENT which represents the nature of the relationship in order to facilitate agreement establishment. At minimum, WS-Agreement requires that one party OFFERs to establish agreement with an embedded agreement document. The other party must ACCEPT or REJECT this offer to establish (or not) the agreement relationship and bind the two parties. The syntax of this document, except for the embedded domain-specific content, are within scope of WS-Agreement. 4. The agreement document also is useful to represent the STATUS of the relationship for purposes of general system introspection and management. The presentation of the document and associated advisory metadata is within scope of WS-Agreement. 5. Another goal in some trust and accounting environments is to be able to DEMONSTRATE that an agreement relationship exists. The ability to demonstrate the existence of an agreement relationship may be valuable when resolving conflicts or in order to increase confidence in an agreement relationship between parties enjoying limited trust in one another. This demonstration of agreement can be facilitated by bilateral exchange of agreement documents with signature or some other means of visibility to a third party arbiter, whereas mere establishment of agreement between trusting parties may be accomplished with less data exchange. The ability to exchange agreement documents bilaterally is within scope of WS-Agreement, while the specifics of how one might sign such documents is out of scope and only supported through extension mechanisms. 6. Another goal is to be able to MEASURE the satisfaction of an agreement relationship. The measurement or validation of behavior of a party may be performed for different reasons by each party in the agreement and/or a third party. a) A party may measure its own behavior in order to adaptively stay within the terms of the agreement, to know whether it has done so, or to ADVISE the other party when the relationship cannot be satisfied. b) A party may measure the other party's behavior in order to RATE the reliability or trustworthiness of that party. c) A third party may AUDIT either party's behavior in order to facilitate resolution of conflicts (possibly in combination with demonstration of the agreement relationship). The self-monitoring behavior of an agreement party is out of scope of WS-Agreement, but the ability to advise other parties of past or imminent status changes is within scope. The monitoring of behaviors by the second or third party is out of scope of WS-Agreement. [Should an ability to advise a party of external observations of its behavior be in scope? It is not currently.] -- Karl Czajkowski karlcz at univa.com From pruyne at hpl.hp.com Mon Mar 28 00:19:02 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Mon, 28 Mar 2005 00:19:02 -0600 Subject: [graap-wg] telecon on March 28 Message-ID: <4247A1D6.5030500@hpl.hp.com> All, We'll have a telecon at our usual time on our usual day: Mon. afternoon US / Tues. Morning Asia. Dial-in and times will be the same: 4:00 Central Time US 866673-8466 or 702-477-6031 passcode: 8578310. --- Jim From maclaren at cct.lsu.edu Mon Mar 28 09:54:02 2005 From: maclaren at cct.lsu.edu (Jon MacLaren) Date: Mon, 28 Mar 2005 09:54:02 -0600 Subject: [graap-wg] proposal: agreement lifecycle end-games In-Reply-To: <20050325025325.GB18777@moraine.localdomain> References: <20050322075334.GX3567@moraine.localdomain> <20050323021619.GA9936@moraine.localdomain> <20050323164230.GA12812@moraine.localdomain> <032d6bf1dd7c7ffc01e1e8568eda865b@cct.lsu.edu> <20050324024414.GB13983@moraine.localdomain> <30794af39b4af5eb6aa560968bda81ce@cct.lsu.edu> <20050325025325.GB18777@moraine.localdomain> Message-ID: <6a1cc9f7ea58ba8180daba53bb58c894@cct.lsu.edu> On Mar 24, 2005, at 8:53 PM, Karl Czajkowski wrote: > On Mar 24, Jon MacLaren loaded a tape reading: > ... >> I'd imagined using XML Signature for doing this stuff. That allows a >> number of different methods for signing to be plugged in, and is >> certainly not specific to any signature algorithm, and I believe it >> does not fall foul of the WS-A guidelines you mention. If you feel it >> does, please send a precise reference to some text. >> >> For information on XML Signature, see: >> http://www.w3.org/TR/xmldsig-core/ >> > > I have to admit that I am not an expert at the use of XML security > standards, so I am largely echoing what I have been told by security > and WS experts... > > >> I don't know a lot about Kerberos, and so I don't know how well that >> maps onto this idea. Of course, the point of signing something in >> this >> context is that you can later show that such-and-such an entity signed >> something. This must be valid outside of whatever exchange (session) >> is taking place at the time. Are Kerberos tokens appropriate for this >> purpose? >> > > I don't know, but that is the thrust of my point. I am extremely > uncomfortable stating that WS-Agreement should try to normatively > define/choose a sessionless identification and signing model for > agreement parties. I don't think we want to close it off from the > communities who do not use such security models. I personally like > PKI, but have learned that not everyone does. ;-) I really think this > bottomless pit of options needs to be addressed in profiles outside > WS-Agreement. > > But, the advice I have received is that it would be sensible to use > XML-Signature "detached" signatures and put them in extended content > as a sibling to the agreement document. So, at minimum WS-Agreement > should make sure to have appropriate extension points to be able to > trigger and exchange extra signature info. To me, this means having > an extension model where something like a "request for signature" can > be marked MANDATORY in an offer, meaning the responder MUST sign his > acceptance message or reject the offer if he is unable/unwilling. In > our zeal for extensibility of agreement terms, I am not sure whether > we have kept extensibility for these sorts of signaling options. That sounds like a good way to support the behaviour I was looking for. > Can we agree on this as a compromise approach? I'd really like to > focus on the generic WS-Agreement plumbing and enable experimentation > and community-specific profiles to address these sorts of problems on > top of the base specification. Yes, the approach you mention above sounds fine. > >>> We could put it in the output of the createAgreement and the input of >>> the acceptAgreement [if we go w/ the proposal I summarized again >>> recently]. Or, we could say that the initiator MAY fetch it anytime >>> after acceptance by fetching an RP containing the document, >>> e.g. AcceptedAgreement, which would be nil until the acceptance >>> decision is made. >> >> I'd want the first suggestion. (I don't object to the second as an >> *additional* method.) >> > > One minor variant, after having bounced this off some people outside > GRAAP-WG, is that if we did the first we should retain an ability to > do it with or without the verbose response message. I don't know if > this should be multiple operations w/ different message typing, or one > generic message with some optional control bits in the input to modify > the required response? Again, no objection. I'd probably go for same operation, with an extra flag. Makes it easier to switch from using one to the other in code. And to all intents and purposes, you're doing the same thing... > >> The semantics of what it means, in this context, to have signed the >> agreement are ours to define. Given that we all understand what it >> means when we sign a contract or Paper-Agreement, I think that this >> part is quite simple. >> >> Jon. > > I didn't mean the semantics of signature, but rather how we could > specify the syntax of signature without delving into > mechanism-specific stuff. In other words, I didn't know how to make a > normative statement about presence or absence of signatures. It's a > moot point, if we can agree on the more specific discussions above. Done! Jon. > > > karl From pruyne at hpl.hp.com Mon Mar 28 17:22:46 2005 From: pruyne at hpl.hp.com (Jim Pruyne) Date: Mon, 28 Mar 2005 17:22:46 -0600 Subject: [graap-wg] minutes from 3/28 telecon Message-ID: <424891C6.3070906@hpl.hp.com> Minutes attached. We should be meeting next week at the same time. --- Jim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Mar2805-minutes.txt Url: http://www.ogf.org/pipermail/graap-wg/attachments/20050328/a406dae7/attachment.txt From karlcz at univa.com Mon Mar 28 19:45:33 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Tue, 29 Mar 2005 08:45:33 +0700 Subject: [graap-wg] JSDL cheat sheet Message-ID: <20050329014533.GA3526@moraine.localdomain> In the absence of a revised JSDL document w/ all the work items completed that were generated at GGF-13, here are some notes I took for myself on the basic structure and scope... Please note that there are two ways to look at the resource constraints (this is one of the most metaphysical aspects of job scheduling): 1) implied performance requirements via physical resource selection 2) qualitative features of the job configuration I think the JSDL view is more towards (2), meaning that the resource constraints describe basic "shape" of a job. They need to be complemented by more performance-oriented constraints including wall-clock lifecycle and/or performance of hardware (CPUs, interconnects, disks, hierarchical RAM, etc.). I think JSDL is extensible enough to insert performance constraints into its structure, so I do not know if it is better to do this or use an external annotation format for composing JSDL, performance metrics, and WS-Agreement. karl JSDL cheat sheet ---------------- There is an explicit understanding that the base JSDL doc element allows expression of homogeneous parallel jobs, and sequential jobs. To express heterogeneous parallel jobs, or heterogeneous "alternates" (a Unicore idea?), will require an enclosing context that presents a set of JSDL job documents w/ some way to interpret them for this purpose. In other words, a multi-job like syntax could represent either "do all these simultaneously" or "choose one of these that fits the resource pool". It will take some time for a new draft to settle out w/ all the revision decisions enacted. We pushed a lot of stuff out of scope and tried to fix a lot of warts. Here is a rough sense of the structure, without trying to write a schema right now: JobDefinition JobDescription JobIdentification ? JobName ? Description ? JobAnnotation * JobProject * xsd:any##other User ? ExecutionUserID ? ExecutionGroupID ? UserGroup * xsd:any##other * Application ? ApplicationName ? ApplicationVersion ? ExecutableApplication ? Executable Argument (xsd:string) * Environment (xsd:string) * attr: name=xsd:string Input ? Output ? Error ? WorkingDirectory ? PosixStackLimit ? PosixProcessLimit ? ... PosixMaxFilesizeLimit ? xsd:any##other * xsd:any##other? Resource ? HostName * ResourceCount ? CPUArchitecture ? TotalCPUCount ? TotalRAM ? ... PerResourceCPUCount ? PerResourceRAM ? ... DataStaging * FileName FileSystemID ? CreationMode DeleteOnTermination ? Source ? URL Target ? URL xsd:any##other ? xsd:any##other * xsd:any##other * The Input and Output elements are actually complex structures to do the expected things such as associating source/destination URLs with local filenames or filespaces. The types of many obvious things are xsd:string. The types of the "resource constraint" numerical limits will be a ValueRangeType that basically is something like this: sequence xsd:integer * xsd:integer * xsd:integer * xsd:integer xsd:integer * to allow the structured expressionf of their previous "string range value language" which allowed things like: a, b, c, d-e, f-, -g to give a mixed list of values, intervals, and semi-spaces. -- Karl Czajkowski karlcz at univa.com From t-nakata at cw.jp.nec.com Mon Mar 28 20:07:25 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Tue, 29 Mar 2005 11:07:25 +0900 Subject: [graap-wg] minutes from 3/28 telecon In-Reply-To: <424891C6.3070906@hpl.hp.com> References: <424891C6.3070906@hpl.hp.com> Message-ID: <4248B85D.10103@cw.jp.nec.com> #I had to leave early to get to my office in time for a meeting apologies. Comments List Updated with two more extra items 1)Includes url of the comment tracker and the document tracker. (You can directly go to the page by clicking on the url (at least on Netscape and IE6) 2)List of internal discussion which had not been in the public comments. Jim Pruyne wrote: > Minutes attached. We should be meeting next week at the same time. I think day light saving time starts in the US next week. So people in Asia, please wake up an hour early. Best regards Toshi > > > --- 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/20050329/2377369c/attachment.htm From t-nakata at cw.jp.nec.com Mon Mar 28 20:55:32 2005 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Tue, 29 Mar 2005 11:55:32 +0900 Subject: [graap-wg] minutes from 3/28 telecon In-Reply-To: <4248B85D.10103@cw.jp.nec.com> References: <424891C6.3070906@hpl.hp.com> <4248B85D.10103@cw.jp.nec.com> Message-ID: <4248C3A4.8070906@cw.jp.nec.com> The comments list was getting cluttered with TODO's etc, so I've added a new html which lists *only* the unresolved issues. I'll try to update both of these. Best regards Toshi Toshiyuki Nakata wrote: > #I had to leave early to get to my office in time for a meeting > apologies. > > Comments List Updated with two more extra items > 1)Includes url of the comment tracker and the document tracker. > (You can directly go to the page by clicking on the url (at least on > Netscape and IE6) > 2)List of internal discussion which had not been in the public comments. > > > Jim Pruyne wrote: > >> Minutes attached. We should be meeting next week at the same time. > > > > I think day light saving time starts in the US next week. > So people in Asia, please wake up an hour early. > > Best regards > Toshi > >> >> >> --- 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/20050329/1e76866c/attachment.htm From Chee-Kian.Koh at Sun.COM Tue Mar 29 10:10:27 2005 From: Chee-Kian.Koh at Sun.COM (Chee-Kian Koh) Date: Wed, 30 Mar 2005 00:10:27 +0800 Subject: [graap-wg] Negotiation Protocol Specification Message-ID: <2b0e7e2b1dec.2b1dec2b0e7e@hms-mail1.Singapore.Sun.COM> Hi all, I understand that this working group is currently working on a negotiation protocol named WS-AgreementNegotiation. I also know of another effort call WS-Negotiation, and so I'm wondering if these two are the refering to the same thing. Thanks. ----------------------------------------- Melvin Koh Chee Kian Grid Research Engineer Asia Pacific Science & Technology Center Sun Microsystems Inc. Website: http://apstc.sun.com.sg/ ----------------------------------------- From karlcz at univa.com Thu Mar 31 01:23:05 2005 From: karlcz at univa.com (Karl Czajkowski) Date: Thu, 31 Mar 2005 14:23:05 +0700 Subject: [graap-wg] updated draft Message-ID: <20050331072305.GE19228@moraine.localdomain> Jim has kindly posted version 12 of the draft, including comments and revisions by me. The comments emphasize my concerns about the existing presentation and content of some sections. The revisions attempt to add the extensibility needed for Jon's signature problem (without actually defining any signature-related syntax) and the "async" interfaces. I also removed the Terminate operation. I am sure there are presentation problems and inconsistencies, but hopefully this is a more concrete basis for further discussion of these proposed changes. Please ignore the appendix entirely. The main sections are intended to be normative and the appendix is unknown older content that I did not touch. karl https://forge.gridforum.org/projects/graap-wg/document/WS-AgreementSpecificationDraft.doc/en/12 -- Karl Czajkowski karlcz at univa.com