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

OGSA-BES DRAFT charter and F2F
by Andrew Grimshaw 18 Apr '05

18 Apr '05

All, Attached is the draft BES charter. Please comment in the next several days so we can get this off to the GFSG. A few other administrative things. 1) We are planning a face-to-face in conjunction with the OGSA F2F in London at the end of May. The OGSA F2F is May 23-24. We will have the BES F2F the day before - on Sunday the 22. 2) The proposed weekly teleconference time is 10 AM Eastern (US) on Thursdays (NOT including today.) It is not an ideal time for the folks in Asia. Midnight in Japan, and 10 PM in Thailand. We are working on finding a conference call number and will post in advance. Any ideas are appreciated. Andrew

2 2

ICSOC 2005
by Ian Foster 15 Apr '05

15 Apr '05

Dear All: I enclose a call for papers for ICSOC, which may be of interest to some of you. Regards -- Ian.

2 2

RE: Modeling State: Technical Questions
by Ian Foster 05 Apr '05

05 Apr '05

Paul: My apologies for the slow reply: I left on vacation soon after sending my email. Your notes all look good to me. I'm putting together a revised version of my discussion document that trys to capture these and other points. Ian. At 12:14 PM 3/11/2005 +0000, Paul Watson wrote: >Dear Ian, > >Having faithfully promised myself that I wouldn't spend more time on >discussions about low-level WS specs, I found myself drawn in as this is >a very interesting comparison (it reminded me of the excellent work done >in the DAIS WG to compare different approaches to database access >services). In particular, it gives me a concrete example that I can use >to ask some questions about the use of WSRF. Given that I come from a >non-WSRF background (my experience is with services that use the >approach in your option #3) much of what I've written below is about >understanding the motivation for switching to the WSRF approach. But, >I'd like to stress that this isn't intended to be hostile ... it's meant >to improve my understanding and (hopefully) move on the technical >debate. > >I was going to send it to you only, as you offered to collate feedback, >but as Dave Berry is proposing to discuss these options next week (and I >won't be there) and has posted on it, I thought that I'd send it to Dave >and others too as input to these discussions. > > > OPTIONS > > > > 1) (WSRF) > > > > The job handle is an EPR to a WS-Resource, in which case the case the > > WSRF operations can be used to get status and delete: > > > > send "GetResourceProperty(status)" to job-handle > > send "Destroy" to job-handle > > > >If there are other operations that need to be supported on jobs, e.g. >"suspend, resume, checkpoint, change priority"... then am I right in >thinking that these would be provided by application-specific operations >on resources that were not defined by WSRF? > >e.g. send "Suspend" to job-handle, >send "changePriority" to job-handle etc. > > > In addition, one will probably also want to be able to send requests > > to the job-factory, which is straightforward as there is no strong > > encapsulation in WSRF. E.g.: > > > > send "destroy(all-jobs-owned-by-ian)" to job-factory-web-service > >Given previous misunderstandings, it is good to see that your WSRF >example also includes some operations on the service. > >I think that the motivation for introducing operations on the service is >that these can then operate over a set of resources (e.g. >"all-jobs-owned-by-ian"). This reduces the number of messages (e.g. one >interaction with the service vs. one to each resource in the set of >"all-jobs-owned-by-ian"), and also allows the set of resources to be >selected using information encapsulated within the service (e.g. >"jobs-owned-by-ian", "jobs that have nearly reached their quota", "jobs >that have run for more than 24 hours"). Therefore, for similar reasons, >it would, I think, also be beneficial to define a "check-jobs-status" >operation on the service. This would allow, for example: > >check-jobs-status("all-jobs-owned-by-ian") > >Also, as, "all-jobs-owned-by-ian" defines a set of jobs, it would seem >reasonable to allow the consumer to specify the set of jobs by name: > >"destroy(job1,job27,job35)" >"check-jobs-status(job1,job27,job35)" > >(I may be wrong, but I think that the current naming proposal would >allow this by giving the consumer the abstract name for a resource as >well as the epr). > >These operations on the service are the sort I'd expect to see in option >#3 (as I'll explain below). So, I think that one could view option #1 as >taking the operations from option #3 and then adding to them a set of >operations on individual resources. > >These operations on the service allow a consumer to (I think) do >everything without using the operations on individual resources. This is >because these operations address the general case for a job submission >service... they provide operations over the set of resources >encapsulated by the service. They appear to have the advantage of >supporting and encouraging larger-grained operations, e.g. in one >message you can ask about a set of resources rather than just one. I >expect that will be important for performance, given the costs of >sending messages between web services. The operations on individual >resources seem to be a special case of the general case, and this raises >the question (to me) that if the job management service provides the >general case, then when is it better to use the special case? > > > 3) (Job id) The job-handle is a job-factory-specific string, > >I'd think that it could be an "abstract name" in OGSA naming terms >(though the naming proposal isn't fixed yet, so I may be wrong). > > > and we define > > job-factory-specific operations for manipulating the job, e.g.: > > > > send "check-job-status(job-handle)" to job-factory > > send "terminate-job(job-handle)" to job-factory > > > > #3 is very similar to #1 and #2: the message sent over the wire in > > each case contains the same information (operation name + Web service > > address + job-id-info). > >As described in my comments on option #1 above, I'd suggest that both >these operations should be defined to operate on a set of jobs (c.f. >option #1's "destroy(all-jobs-owned-by-ian)). > >e.g. the operations on the service would allow: > >"check-jobs-status(job1, job14,job27)" >"terminate-jobs(job2, job35)" > >Allowing multiple job names in a message is, I think, no more difficult >to implement, and naturally scales up to larger granularity operations >(e.g. one interaction with a service is enough to carry out actions on >1,2 or 500 jobs). > >Option #3 also differs from #1 and #2 as it does not rely on >ws-addressing (though it could use it). [A personal view is that I see >this as an advantage for those who want to design and build services now >or in the near future. This is because the service can use only >currently stable specifications found in the set "blessed" by >WS-Interoperability, and these are provided in an interoperable manner >by a wide range of existing WS platforms.] > > > What is different about #3 is that you have to manage this job-handle > > separately from the job-factory EPR. Also, you don't use the > > standardized WSRF/WSN operations. > > > > Have I captured all of the options that people think we should be > > considering? > > > >I note that Dave & Karl have now posted about the possible use of >ResourceGroups. I based the above on your message which did not discuss >their use, and so I wonder if it would therefore be helpful for someone >to produce a version of option #1 that creates and uses resourcegroups. > >This was a very good start for discussion, and I'd be interested on your >views on my comments above. > >Regards > >Paul. > > >-----Original Message----- > >From: Ian Foster [mailto:foster@mcs.anl.gov] > >Sent: 07 March 2005 04:47 > >To: Tony Hey; Frank Siebenlist > >Cc: Dennis Gannon; Samuel Meder; ogsa-wg; > >paul.watson(a)ncl.ac.uk; dave.pearson(a)oracle.com; > >savas.parastatidis(a)ncl.ac.uk; gray(a)microsoft.com; > >humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu; > >aherbert(a)microsoft.com; gcf(a)indiana.edu; mark.linesch(a)hp.com > >Subject: Modeling State: Technical Questions > > > >Dear All: > > > >In an effort to move forward this debate about "OGSA > >plumbing", I thought > >I'd attempt to describe the different positions that I've seen > >expressed. > >Perhaps people can read this quickly, and provide feedback as > >to where I > >have not captured things correctly. I'll be happy to collate > >responses sent > >directly to me and forward them, if there is interest. > > > > > >CONTEXT > > > >The context is that OGSA-WG needs to develop some low-level > >specifications, > >such as execution management services, that require modeling > >interactions > >that involve server-side state. E.g., in the following > >pseudo-code example, > >we request the creation of a "job": > > > > send "create(jsdl-specification)" to job-factory-web-service > > receive "job-handle" from job-factory-web-service > > > >I think that everyone accept that this sort of interaction is > >needed. (Let > >me know if not.) > > > >Where people differ in their views is with respect to what the > >"job-handle" > >should be and how we should represent operations on the job. > >I've heard > >three views expressed, as follows. > > > > > >OPTIONS > > > >1) (WSRF) > > > >The job handle is an EPR to a WS-Resource, in which case the > >case the WSRF > >operations can be used to get status and delete: > > > > send "GetResourceProperty(status)" to job-handle > > send "Destroy" to job-handle > > > >In addition, one will probably also want to be able to send > >requests to the > >job-factory, which is straightforward as there is no strong > >encapsulation > >in WSRF. E.g.: > > > > send "destroy(all-jobs-owned-by-ian)" to job-factory-web-service > > > >This approach exploits the standardized syntax and semantics for the > >various operations (GetResourceProperty, Destroy, etc.) defined by the > >WSRF/WSN specifications. > > > > > >2) (WS-Transfer) > > > >The job-handle is an EPR to a WS-Transfer resource, in which case the > >appropriate WS-Transfer operations can be used to get status > >and delete. > > > > send "Get" to job-handle > > send "Delete" to job-handle > > > >Assuming that there is no strong encapsulation in WS-Transfer > >either, one > >can also contact the job-factory directly when required: > > > > send "destroy(jobs-owned-by-ian)" to job-factory > > > >This approach exploits the syntax and semantics for the > >various operations > >(GetResourceProperty, Destroy, etc.) defined by the > >WS-Transfer specification. > > > >#2 is very similar to #1. One can argue the pros and cons of the two > >approaches. I'm concerned that you have to return the whole > >resource state, > >not just a single component (e.g., the status field). But that's a > >relatively minor issue. > > > > > >3) (Job id) The job-handle is a job-factory-specific string, > >and we define > >job-factory-specific operations for manipulating the job, e.g.: > > > > send "check-job-status(job-handle)" to job-factory > > send "terminate-job(job-handle)" to job-factory > > > >#3 is very similar to #1 and #2: the message sent over the > >wire in each > >case contains the same information (operation name + Web > >service address + > >job-id-info). What is different about #3 is that you have to > >manage this > >job-handle separately from the job-factory EPR. Also, you > >don't use the > >standardized WSRF/WSN operations. > > > >Have I captured all of the options that people think we should > >be considering? > > > > > >WHAT OGSA-WG SHOULD DO > > > >Given this characterization, I'd also be interested in > >people's views as to > >how OGSA-WG should proceed when considering specifications > >that involve > >this sort of interaction pattern. > > > >The majority of active participants OGSA-WG participants seem to favor > >option #1, but I've also heard people argue in favor of > >approaches #2 and #3. > > > >Tony Hey proposed, I think, that we should define > >specifications like job > >management in terms of some more abstract interface that can > >then be mapped > >to each of the approaches above, as desired. > > > >Frank Seibenlist observed that we can use WSRF/WSN as such an abstract > >interface: given an interface defined in terms of WSRF/WSN > >specifications, > >one can derive, via straightforward transformations, a concrete > >specification in the style of approach #2 or #3. > > > >Regards -- Ian. > > > > > > _______________________________________________________________ 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

3 5

[ogsa-wg | Basic Profile - 1350] WS-I Copyright/attribution/reference on front matter
by Sourceforge Tracker Monitor 31 Mar '05

31 Mar '05

A new artifact has been added: 1350 Submitted by: Tom Maguire Submitted date: 2005-03-31 12:41:49 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1350&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1350&group_id…) Summary: WS-I Copyright/attribution/reference on front matter Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1350 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Tom Maguire Last Modified: 2005-03-31 12:41:49 Submitted By: Tom Maguire Submit Date: 2005-03-31 12:41:49 Assigned To: &lt;None&gt; File(s): <None> Description: Front matter is largely taken from WS-I Basic Profile. Need to work the copyright issue/understanding with WS-I. View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1349] EDITORIAL - Abstract tighten up principles
by Sourceforge Tracker Monitor 31 Mar '05

31 Mar '05

A new artifact has been added: 1349 Submitted by: Tom Maguire Submitted date: 2005-03-31 12:38:15 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1349&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1349&group_id…) Summary: EDITORIAL - Abstract tighten up principles Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1349 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Tom Maguire Last Modified: 2005-03-31 12:38:15 Submitted By: Tom Maguire Submit Date: 2005-03-31 12:38:15 Assigned To: &lt;None&gt; File(s): <None> Description: This sentence -"Guided by these principles and operating in the wider technical domain of distributed system management and grid computing, we define here the OGSA Basic Profile 1.0, the first of what is expected to become a set of normative profiles addressing issues relating to distributed system management." needs to be cleaned up View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1348] EDITORIAL - Abstract needs WS-I refs
by Sourceforge Tracker Monitor 31 Mar '05

31 Mar '05

A new artifact has been added: 1348 Submitted by: Tom Maguire Submitted date: 2005-03-31 11:00:46 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1348&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1348&group_id…) Summary: EDITORIAL - Abstract needs WS-I refs Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1348 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Tom Maguire Last Modified: 2005-03-31 11:00:46 Submitted By: Tom Maguire Submit Date: 2005-03-31 11:00:46 Assigned To: &lt;None&gt; File(s): <None> Description: proper references for WS-I BP 1.1 and WS-I BSP 1.0 View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Basic Profile - 1347] EDITORIAL- Status of memo s/b recommendation
by Sourceforge Tracker Monitor 31 Mar '05

31 Mar '05

A new artifact has been added: 1347 Submitted by: Tom Maguire Submitted date: 2005-03-31 10:55:46 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1347&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1347&group_id…) Summary: EDITORIAL- Status of memo s/b recommendation Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1347 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Tom Maguire Last Modified: 2005-03-31 10:55:46 Submitted By: Tom Maguire Submit Date: 2005-03-31 10:55:46 Assigned To: &lt;None&gt; File(s): <None> Description: This text - "This document does not define any standards or technical recommendations." is wrong View the Basic Profile : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

Proposed agenda for March 30th EGA feedback call
by Hiro Kishimoto 31 Mar '05

31 Mar '05

Hi all, Tomorrow (March 30th) is NOT regular OGSA call but Enterprise Grid Alliance (EGA) feedback call. Even thought it is not regular one, you are very welcome to join. March 30th Wednesday from 5pm to 6pm (CST). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0330 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) EGA feedback discussion (60 min) GGF13 session #5 minutes (http://tinyurl.com/5fxfd/ggf13-minutes-session-5/en/1) > - The review document is intended as a starting point for a > discussion between EGA and OGSA-WG > - There is an EGA F2F beginning of April, which Andrew is scheduled > to attend. By that time OGSA (Hiro, Andrew, Jay) will finish a > review of the EGA OGSA version 1.0 review. Notes on the OGSA-WG's discussion of the EGA's review of OGSA https://forge.gridforum.org/projects/ogsa-wg/document/EGA_OGSA_Review_Discu… /en/1 Thanks, ---- Hiro Kishimoto

1 1

RE: [ogsa-wg] OGSA ByteIO WG charter
by Hiro Kishimoto 30 Mar '05

30 Mar '05

Mark's email bounced. ---- Hiro Kishimoto From: "Mark Morgan" <mmm2a(a)cs.virginia.edu> To: "'Hiro Kishimoto'" <hiro.kishimoto(a)jp.fujitsu.com>, "'ogsa-wg'" <ogsa-wg(a)gridforum.org> Subject: RE: [ogsa-wg] OGSA ByteIO WG charter Date: Wed, 30 Mar 2005 11:49:25 -0500 Just to let everyone know, the ByteIO group plans on having it's first telecon next Tuesday at 11AM Easter (8AM Pacific, and I "think" 4PM UK). Our agenda for that telecon includes the groups first discussion of the charter. More details to follow. -Mark > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Hiro Kishimoto > Sent: Wednesday, March 30, 2005 5:59 AM > To: 'ogsa-wg' > Subject: [ogsa-wg] OGSA ByteIO WG charter > > Hi all, > > GFSG asks me to send out revised OGSA-ByteIO WG charter draft > to OGSA-WG mailing list for your review. Two WGs should be > consistent and WG charter is binding document to materialize it. > > Please read them carefully and let me know if you have any comments. > Since GFSG will approve this WG on next Tuesday at earliest, yours > comment should be made by next Monday. If necessary, we can discuss > this topic at Monday call. > > The following is my comments. > > (1) Acronym, email address, web page should be the same, e.g.; > Acronym: OGSA-BIO > email list: ogsa-bio-wg(a)ggf.org > web page: https://forge.gridforum.org/projects/ogsa-bio-wg > > (2) OGSA infrastructure (first paragraph of scope section) It > should be based on "OGSA basic profile v1.0" instead of "WSRF." > > (3) Any other relevant information > This section should be described more specific in order to > make WG's documents will be consistent with OGSA-WG. > I prefer the following; > > As the ByteIO interface is intended to be part of OGSA, the > WG should have joint review discussion with OGSA-WG and > OGSA-D-WG before EVERY milestones, e.g. first draft > recommendation document review before GGF14. > > Thanks, > ---- > Hiro Kishimoto > > >

1 0

RE: [ogsa-wg] Draft charter for OGSA Data Architecture WG (promoting the design team)
by Dave Berry 30 Mar '05

30 Mar '05

We discussed the draft OGSA-D charter on today's design team call. You can find the minutes at http://tinyurl.com/3tjqa . I attach a revised version of the charter and the (unchanged) answers to the seven questions. One process question raised today is, if the OGSA-D WG were to produce a data profile recommendation document, what would be the process for issuing it as an OGSA profile? Would a document from the OGSA-D WG have the status of an OGSA profile (assuming that the OGSA WG agreed to it)? Or would the OGSA-D WG submit the document to the OGSA WG for formal release? Dave. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Hiro Kishimoto Sent: 28 March 2005 15:28 To: Dave Berry; 'ogsa-wg' Cc: 'Dave Pearson'; 'Mario Antonioletti'; 'Martin Westhead'; gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; 'Allen Luniewski'; Malcolm Atkinson; 'Susan Malaika'; 'Peter Clarke (UCL)'; 'David E Martin'; 'Peter Kunszt'; Ian.Bird(a)cern.ch; Erwin.Laure(a)cern.ch; Gavin.Mccance(a)cern.ch; 'Scott Oster'; 'Stephen Langella'; 'Shannon Hastings'; 'Manuel Pereira'; 'Ted Anderson'; 'Leo Luan'; 'Mark M. Morgan' Subject: RE: [ogsa-wg] Draft charter for OGSA Data Architecture WG (promoting the design team) Thanks Dave, I agree that this OGSA data architecture WG will develop informational data service architecture document which covers typical scenarios and detailed service descriptions. However, I don't know what the basic data profile looks like. Even though this WG will develop the basic data profile in the near future, I prefer not give a charter for profile development at this moment. I expect this WG will get clear outline of the date profile within a couple of months and then define the profile, deliberate within OGSA-D WG and with OGSA-WG and propose re-charter of OGSA-D to GFSG. Although it is overhead, but I think this procedure will guarantee necessary consistency between OGSA-WG and OGSA-D WG. Your thoughts? ---- Hiro Kishimoto > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf > Of Dave Berry > Sent: Monday, March 28, 2005 1:04 AM > To: ogsa-wg > Cc: Dave Pearson; Mario Antonioletti; Martin Westhead; > gtr(a)ast.cam.ac.uk; chappella(a)battelle.org; arun(a)sdsc.edu; > jxu(a)us.ibm.com; o.tatebe(a)aist.go.jp; Yves.Denneulin(a)imag.fr; > ppadala(a)cise.ufl.edu; ivm(a)fnal.gov; jalameda(a)ncsa.uiuc.edu; > annc(a)isi.edu; madsen(a)us.ibm.com; allcock(a)mcs.anl.gov; Allen Luniewski; > Malcolm Atkinson; Susan Malaika; Peter Clarke (UCL); David E Martin; > Peter Kunszt; Ian.Bird(a)cern.ch; Erwin.Laure(a)cern.ch; > Gavin.Mccance(a)cern.ch; Scott Oster; Stephen > Langella; Shannon Hastings; Manuel Pereira; Ted Anderson; Leo Luan; > Mark M. Morgan > Subject: [ogsa-wg] Draft charter for OGSA Data Architecture WG > (promoting the design team) > > Dear all, > > Please find attached a draft charter for the promotion of the OGSA > data design team to a working group. We will discuss this on > Wednesday's call (times below). Please mail any minor comments to me. > Major issues may need discussion on the mailing list or at telcons. > > Dave. > > Data telcon times: 7.30am PST / 10.30am EST / 4.30pm GMT / 5.30 pm > CET >

1 0