- graap-wg - lists.ogf.org

terminal fault type
by Karl Czajkowski 22 Mar '05

22 Mar '05

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

1 0

Telecon on 3/21
by Jim Pruyne 22 Mar '05

22 Mar '05

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

5 16

possibility of H.323 conferencing
by Karl Czajkowski 22 Mar '05

22 Mar '05

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(a)univa.com

1 0

Minutes of the GRAAP session at GGF13
by Wolfgang Ziegler 18 Mar '05

18 Mar '05

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" Minutes of GRAAP session at GGF13 Seoul 16th of March 2005 Session chair: Wolfgang Ziegler, Notetaker: Philipp Wieder (for the slides of the session visit the GRAAP page at gridforge) - ~20 participants - legal stuff, sign-in sheets circulated - agenda presented, announcement that this is just a reporting session, no work on the spec. is done (none of the authors present) - result of Public Comment Period - we received 36 comments (some of them collected at GGF12 in Brussels and inserted by Heiko) - 29 of them addressed and most of them resoveld, some still in discussion (see slides for status) - went through comments (slide presentation) - Jon MacLaren clarified his position on comment #12, he still thinks that seperation of the doc should be carried out to separate protocol, format, etc. - Jon clarified comment #14, GGF recommendations should not rely on standards which are not finalised yet. Wolfgang: We changed this in the spec. to make more explicit which specs are already finalised and which not. Some of the standards in progress could be finalised before/during the second public comment period which will reduce this problem. The group will try to react on changes in referred specs. - #18 discussed heavily on the mailing list, but still far from being resolved - comments #28-#30 and #33 to #36 will be discussed during the following weeks - Questions: state of the specification, will there be major changes? Answer (Wolfgang): No further, except for - asynchronous operation (#2, still under discussion) - termination (#18, ongoing discussion) and - removal of related agreements (#3, done), But the changes are important enough to have a second public period comment. - The group will try to set up dedicated telecons (or AG meetings) to resolve the open issues like asynchronous operation and termination - Next steps - presented schedule for the next months - Stephen Pickles reported that Karl Czaikowski is less optimistic than Wolfgang wrt to resubmission date (3-6 vs 3 month) - Question: Will editor time be as long as for the first submission? Answer (Stephen): Pipeline works more quickly now. - Question: Is it just resolving comments or also bringing in new issues? Answer (Wolfgang): No formal decision, but try to defer new issues to later. - Group thinks about f2f meeting before GGF14 to clarify comments and reach a final agreement on spec. Comment from Stephen: To achieve this such a meeting has to be announced this week. - Comment Jon: Suggestion that authors come to GGF meetings, since it is the best occasion for others to have f2f with them. - Question: Following up activity or closing down the group once the spec. is done? Answer (Wolfgang): When the second comment period is over and the revised spec. has been sent to the editor, the group will move back to original focus and address the negotiation. - Comment Stephen: One should think about experience docs/primer wrt the implementations to get to recommendation (not mandatory). Answer (Wolfgang): there has been some (discontinued) work on a primer and there are several attempts to (partly) implement the spec - so it should not be too difficult to come up with such a document - Comment: It would be good see milestones on a primer. Jon offers to feed training material into writing process.

1 0

minutes from 3/14/05 telecon
by Jim Pruyne 18 Mar '05

18 Mar '05

They are attached. I hope everyone's enjoying GGF. --- jim Attendees --------- Heiko Toshi Takuya Art Jim Asit Agenda ------ Update on status of previously discussed issues and the process JSDL is at GGF this week. OGSA BEMS is having a BoF, Karl will be presenting, but WS-Agreement is secondary to Globus portion of his presentation. Of importance, probably, is getting WS-Agreement listed as part of OGSA profiles more so than any of the sub-groups. Issue 25: Allow compensation type to be an unbonded list. Agreed that this is a good idea. **Action: make the change as suggested in the comment. Heiko to do so. Issue 26: TerminalFaultType (and ContinuingFaultType) seem to be defined but not used. Also points out that faults are defined within the text of the document. **Action: Remove if no one seems to care. This points out that we have no faulting scheme defined. Do we need faults defined more precisely? How does this relate to general termination. **Check with Alain and Karl to see if it has any meaning or is left over from something else. Issue 27: What is the name of the agreement optional, this seems dangerous? We don't know how to name it in general. If we are in the document-domain where there are no EPRs, we don't know what naming scheme to use, so we've left it optional. We may wish to revisit this decision and think of a more general method. We also do not have any other specific field for filling in a unique id for the agreement, so this field is assumed to fill that role. **Action: revisit this discussion on a future meeting. Suggestion: See if we can get some sort of experience reports at least by GGF14, possibly as an extra session at that GGF.

2 1

More async/asymmetry comments
by Karl Czajkowski 18 Mar '05

18 Mar '05

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(a)univa.com

3 6

[Fwd: RE: [ogsa-wg] Proposed (DRAFT) Agenda for Basic EM BOF]
by Jim Pruyne 09 Mar '05

09 Mar '05

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 <grimshaw(a)cs.virginia.edu> To: 'Ian Foster' <foster(a)mcs.anl.gov>, <ogsa-wg(a)ggf.org> 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(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] *On Behalf Of *Ian Foster *Sent:* Monday, March 07, 2005 5:39 PM *To:* Andrew Grimshaw; ogsa-wg(a)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 <http://www.mcs.anl.gov/%7Efoster> 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 <http://www.globus.org/>

1 0

[Fwd: Re: [ogsa-wg] Proposed (DRAFT) Agenda for Basic EM BOF]
by Jim Pruyne 07 Mar '05

07 Mar '05

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 <foster(a)mcs.anl.gov> To: Andrew Grimshaw <grimshaw(a)cs.virginia.edu>, <ogsa-wg(a)ggf.org>, 'Karl Czajkowski' <karlcz(a)univa.com>, Kazushige Saga <saga(a)grid.nii.ac.jp> 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 <http://www.mcs.anl.gov/%7Efoster> 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 <http://www.globus.org/>

1 0

minutes from Mar. 7 telecon
by Jim Pruyne 07 Mar '05

07 Mar '05

Are attached. --- Jim Minutes from Mar. 07 '05 Teleconference Attendees --------- Jim Pruyne Toshiyuki Nakata Wolfgang Zeigler Heiko Ludwig Agenda ------ - GGF - Wolfgang: Plan is to go over the comments that we have addressed so far. Would like a couple of slides from the last GGF for background material. Session is on the 16th. - Discussion on asynchrony and termination is difficult, and hard to do in off-line method. We'd like to have an on-line (at least phone call) discussion. **Action: Jim to ping interested parties directly to see when we can set this up. Perhaps related to GGF. - We'll have a call next week at the usual time even though GGF participants will not be able to attend. Issue 16 & 17: **Action: we will add these snippets in. Heiko will add these by copying from the full schema in the appendix. Issue 19: **Action: Change "Service Description Terms" into "Service Terms" in figure 2. Make similar changes in 4.2 as far as terminology. Change service description terms to service terms and add sentence introducing the different sub-types of service terms. Completed by Jim on-line. Issue 20: Glossary to the front: **Action: We will move glossary to the beginning as suggested a couple times. Figure 1 labels: **Action: add the initiator label. Completed by Jim on-line. Issue 21: Deferred to future discussion. ** Side issue: What is the limit to how long we have to respond to the comments? Are we moving fast enough? Reminders: Jim to continue discussion with JSDL people on the time to meet and engage the OGSA execution service. Asit suggests not closing comments until we have these discussions. Issue 23: **Action: Corrected by Jim on-line. Issue 24: Discussion: yes, this is what we done. **Action: Send request for clarifying e-mail to Tiziana to make sure that we're understanding the request correctly, ideally pointing to an example in the doc. Heiko will contact her.

1 0

Direct URL for doc. comments
by Jim Pruyne 07 Mar '05

07 Mar '05

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

1 0