- ogsa-wg - lists.ogf.org

RE: [ogsa-wg] OGSA-BES-07Mar2005
by Dave Berry 08 Mar '05

08 Mar '05

I have a couple of thoughts about the proposed interface (quite apart from the "WSRF?" Discussion). I post them here because they might be relevant to the general question of the "multiple arguments" pattern. 1. The getActivityStatus operation takes an array argument and returns an array of array of strings. This looks like a design written by a C programmer(*). In the context of a Web Service interface, wouldn't it be more appropriate to return an XML document? It should be possible to define a simple XML schema that nests activity statuses under activity IDs, posibly restricting the range of permitted activity statuses (rather than using arbitrary strings). This would be more robust and self-documenting than relying on positional arguments in arrays. (*) I'm not implying that programming in C is bad per se, just that it's inappropriate for this level of interface. 2. The getActivityStatus and terminateActivity operations take an array of activity IDs. This means that the client has to include logic for deciding which IDs to pass in. An alternative might be to use a query language, so that the client could specify sets of activities that meet certain criteria. E.g. a simple query might specify "all activities owned by this client" (assuming a definition of ownership...). More complex queries might specify: - "all activities that have been running for more than x minutes" - "all activities that have failed to start" - "all activities taking more than X megabytes" - "the activities with IDs in this list" (i.e. providing the same behaviour as an array parameter). This may at first seem an ambitious suggestion, but of course we can use an existing query language rather than develop a new one. If the activities can be represented as a virtual XML document, then the query language can be XPath or XQuery. 3. We need to clarify when operations use abstract names and when they use addresses. This is a general question across the architecture, but it is particularly apparent here because we see clear differences between the proposals. Also, what happens when a job is migrated from one service to another? I realise that this is outside the scope of OGSA-BES, but the answer to that question may constrain the design here (or vice versa). Dave. > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Steven Newhouse > Sent: 07 March 2005 21:45 > To: ogsa-wg > Subject: [ogsa-wg] OGSA-BES-07Mar2005 > > Document for tonight's discussion. > > Steven > -- > ---------------------------------------------------------------- > Dr Steven Newhouse Tel:+44 (0)2380 598789 > Deputy Director, Open Middleware Infrastructure Institute (OMII) > Suite 6005, Faraday Building (B21), Highfield Campus, > Southampton University, Highfield, Southampton, SO17 1BJ, UK >

2 1

RE: [ogsa-wg] Proposed (DRAFT) Agenda for Basic EM BOF
by Dave Berry 08 Mar '05

08 Mar '05

I thought this was what Andrew meant. Anyway, it is important that people taking part in the new WG realise that they are constrained by decisions made in the overall group. They can of course raise issues to be decided in the overall group, with the BEM service(s) as examples of why the issues are important. But we don't want to end up in a situation where (say) DAIS implements the "multiple arguments" pattern one way and OGSA-BEM implements it a different way. Dave. > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of David Snelling > > I would agree with Ian here based on our agreement at the Washington > F2F. There we agreed the our ptofiles would be consistent with the > architecture. I believe this should also apply to these spawned WGs. > Technically however, the forming WG could charter its self to be > constrained to the current EMS model. I would prefer that charter > support the same "invariant" model we use for profiles. This would > allow the EMS model to be modified in light of lessons learned in the > new WG.

1 0

A thought
by Andrew Grimshaw 08 Mar '05

08 Mar '05

Since Brussels the OGSA working group (including design teams) have had three face-to-face meetings - in Washington DC, Chicago, and London. They have - spent over eighty hours on group teleconferences - flown over 200,000 miles to face-to-face meetings - spent over 100 person nights in hotel rooms - eaten countless muffins and sweet rolls - gained more kilos than we can count

3 2

[ogsa-wg | Basic Profile - 1316] Should Basic Profile v1 rely on Naming Profile
by Sourceforge Tracker Monitor 08 Mar '05

08 Mar '05

A new artifact has been added: 1316 Submitted by: Tom Maguire Submitted date: 2005-03-07 21:06:08 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1316&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1316&group_id…) Summary: Should Basic Profile v1 rely on Naming Profile Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1316 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Last Modified: 2005-03-07 21:06:08 Submitted By: Tom Maguire Submit Date: 2005-03-07 21:06:08 Assigned To: &lt;None&gt; File(s): <None> Description: What if any WS-Addressing reqt should be in BP if that is true 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 - 1315] Remove WS-SecureConversation, WS-Policy and OGSI Non normative refs
by Sourceforge Tracker Monitor 08 Mar '05

08 Mar '05

A new artifact has been added: 1315 Submitted by: Tom Maguire Submitted date: 2005-03-07 20:21:41 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1315&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=780&aid=1315&group_id…) Summary: Remove WS-SecureConversation, WS-Policy and OGSI Non normative refs Project: Open Grid Services Architecture Tracker: Basic Profile Artifact ID: 1315 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Last Modified: 2005-03-07 20:21:41 Submitted By: Tom Maguire Submit Date: 2005-03-07 20:21:41 Assigned To: &lt;None&gt; File(s): <None> Description: not ref'd in any way in spec 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

NAREGI slides
by Kazushige Saga 08 Mar '05

08 Mar '05

Dear all, I'm Kazushige Saga of NAREGI project. I'm sending two slides which are requested in the meeting today. We would like to make presentations of them in some OGSA sessions in GGF13. Thanks, Kazushige Saga Center for Grid Research and Development (NAREGI), National Institute of Informatics web: http://www.naregi.org/index_e.html tel: +81 3 4212 2824 　　fax: 　　+81 3 4212 2802

1 0

OGSA-BES-07Mar2005
by Steven Newhouse 07 Mar '05

07 Mar '05

Document for tonight's discussion. Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK

1 0

RE: [ogsa-wg] Data: Proposed agenda for Wednesday 9th March: NEW TIME
by Dave Berry 07 Mar '05

07 Mar '05

If anyone rushed to download the current version of the architecture straw man document, you may want to download it again, as I have just uploaded a revised version. I will attempt to add more changes during the week - there is lots left to do... Dave. > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Dave Berry > Sent: 07 March 2005 15:50 > 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] Data: Proposed agenda for Wednesday 9th > March: NEW TIME > > Dear all, > > Here is a proposed agenda for the data telcon on Wednesday March 9th, > which will be at the NEW agreed time of 7.30am PST / 10.30am EST / > 3.30pm GMT / 4.30 pm CET. > > UK Dial In: 0845 245 0224 > US Dial In: 1866 838 0046 > International Dial In: +44 1452 542309 > > PIN Number: 632 065 > > > 1) Early discussion (5 min) > Note taker assignment > Roll call > Minutes approval (attached) - > https://forge.gridforum.org/projects/ogsa-wg/document/Minutes_ > 23rd_Febru > ary_2005/en/1 > Agenda bashing > > 2) Update on outstanding actions (5 min) > - Dave to write draft charter for ByteIO WG > - Mark to prepare document describing the draft ByteIO interface > - Simon to mail the list about different types of metadata: data > resource vs. service. > - Mark to mail around URL of notes from London meeting > - Dave to revise the current "straw man" document for next week > - Dave to prepare concrete proposal for initial data profile (ByteIO, > RNS, DAIS, GridFTP?) > > 3) GGF13 main session preparation (10 min) > As part of the main OGSA outreach session, I will give a > presentation on > the data design team and the work we've done so far. I'd like to > discuss this with the team on this call. > > 4) GGF13 BOF preparation (10 min) > We have a BOF scheduled about the ByteIO interface. I have sent out a > draft charter for the proposed WG. I would like to discuss how we > should structure the BOF session. > > 5) GGF13 Profile preparation (10 min) > Our first design team session is earmarked for discussion of > an initial > data profile, probably containing DAIS, SRM, ByteIO and possibly > GridFTP. RNS has been put in a naming profile. I would like > to discuss > how we should structure the discussion. Also, it would be > very helpful > if someone would volunteer to write a first draft of a > profile document. > > 6) Architecture update (15 min) > I have put the current draft on GridForge - see > https://forge.gridforum.org/projects/ogsa-wg/document/OGSA_Dat > a_Architec > ture_Straw_Man/en/1. We have a session booked to discuss > this at GGF13, > where we will concentrate on data architecture. > > 7) Wrap up (5 min) > AOB > > Dave Berry > Research Manager, National e-Science Centre > 15 South College St., Edinburgh > Tel: +44 131 6514039 > >

1 0

Teleconference minutes - 28 February 2005
by Andreas Savva 07 Mar '05

07 Mar '05

Minutes attached. Gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050228/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 28 February 2005 ====================================== * Participants Jay Unger (IBM) Jem Treadwell (HP) Ravi Subramaniam (Intel) Latha Srinivasan (HP) Andreas Savva (Fujitsu) Steven Newhouse (OMII) Mark Morgan (UVa) Tom Maguire (IBM) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu) Andrew Grimshaw (UVa) Dave Berry (NeSC) Mike Behrens (R2AD, LLC) Minutes: Andreas Savva * GGF13 update - Hiro will add the dial-in number to the GGF13 sheet - ByteIO BoF is at the same time as the Basic Profile review (session #2 conflicts #11) - BES BoF conflicts with Data architecture (session #8 conflicts with #12) - Andrew is therefore double booked; he will probably be in BES. - #3: Probably do this as a BoF as agreed at the February F2F. The proposed group is probably in the Architecture Area so Andrew is the AD. - Andrew to arrange logistics - Also contact Manuel to find out if he'll be attending GGF13 (Confirmed attendance during the call) - #4: No draft document. Not sure how advanced things will be but will prepare for a discussion. Maybe an open-floor session without long presentations - #5: No draft document. - #6: Basic profile: Was naming and security pulled out? If so how far does this session cover. - Naming: probably everything relating to ws-addressing goes to another (naming) profile. (Something to discuss later.) - Security: not sure whether taking it out completely is good or not. Security is something to 'bake-in' to every spec. Tom and Dave decided to keep the current text in the BP and revisit this issue later. - #9: - What is the intended outcome of this session? - It's not clear whether this is a discussion/educational session or not, or how things will fit together. More likely a discussion, exploration style session. - Is there a list of standards? Or is there any consensus on what the architecture needs? (model driven) - OGSA version 1.0 has a resource management section but the ideas have not been applied consistently throughout. (Which entities are resources and which are not. What does that mean in each case, and is the treatment consistent and so on.) - Part of the work is in the EM/data design teams; with some/other work in the RM team. - Fred is working to bring things together for this session - (Need traceability of requirements back to OGSA version 1.) - Gaps in profiles and how to address them - A side-discussion from the EM profile discussion. - What to do with such gaps? - If something is really missing and it is needed - Ask the spec owners to fill it in (or find owners) - Fill it in the profile (assuming a relatively small and easily bounded gap) - Deliverables review - Three docs submitted so far - Two more from the original list remain to be submited: Data and Roadmap - Roadmap - Ian is working on the Roadmap. Hiro will check the status with him. - Agreed that the draft should go through a group review first before sending it to Stacey. - Data - Ask DaveB. (Hiro) - Visa for Korea: - [If you are unsure contact the nearest Korean embassy.] - A tourist visa should not be used if you are travelling for business. - Information on how strict Korean Immigration is varies. - Jay has more details from the Korean embassy. Email him if you need it. * EM refactoring doc (20050228) [Posted to gridforge after the call https://forge.gridforum.org/projects/ogsa-wg/document/ogsa-ems/en/2] - Fig. 2 : business process/ workflow / ... / tasklet - Trying to describe the scope of area (so includes business process to tasklet) - Including business process here might raise concerns since there is a lot of work outside the grid on this. - Clarified that the intention is not the modelling of the business process but what is needed in the environemnt to support its execution. - Terminology issue: Should these terms be used (clearly overloaded) or should different terms be used (ref: Terms proposed by Andrew & Mark) - Fig 3 (demand - supply) - Added "execution plane" and "control plane" - Control plane 'controls' execution/provisioning activity - Trying to draw out similarity with other capabilities, e.g., data - Resource model would be part of a Resource Management framework - The group is working from both ends but there is a large gap between the lower level work (leading to a profile) and work at this level. - Obviously the situation is not ideal. It is a balance between the desire to do something that will last vs not being able to achieve anything within this year (and taking on the risk of some re-work later on) - A concern raised is whether there is really an incremental path to fill the space or not. - BES focus is 'job focus' ('work push'). Ravi also wants to have the opposite perspective of a resource 'pulling' a job ('work pull') included. - Could be done as extension to the current proposal at a later point (in any case it is not precluded) - OGSA EM v1 identified some core functionality; BES focuses on the simplest function within that picture. The expectation is that there will be a build-up from that base to do other functionality at a later stage. (E.g., CGS) - Next steps? - CGS is one likely candidate - To try and define CGS the following would also be needed: - How jobs describe resources (e.g., JSDL) - How resources describe themselves - And also have to 'unify' across capabilities (Ravi) - Jay argued that this is 'not a unification' but a 'relation'. - Model of how to manage data as data (can be used by the manager) - And a view/facet of that model that can be projected or used by the CGS - This view does not need to be the same as the manager's; only what is required by the CGS - Agreed that this is a good topic to discuss at the EM architecture session. Ravi to prepare for kicking off this discussion. * BES BoF preparation - Andrew, Mark, Steve have had a short call on logistics (who will present, etc) - Andrew to send out draft answers to the 7 questions - Steven will send out revised version of the draft API document (but refinement of this document is not the main focus of activities at the moment) - Will review these again before GGF13 (probably Mon Mar 7) * AOB ** Resource Management followup - Fred is working on a concrete proposal on how to proceed: - Resource modelling has to be done by both sides at the same time. The two sides being the capability (e.g., EM, Data) and the resource modelers (e.g., straight with the DMTF via the resource management team) - A draft document is nearly ready and will be distributed soon. - The CGS co-chair, Tom Rooney, is also interested and is getting involved in this activity. ** BP review postponed for next call

1 0

Modeling State: Technical Questions
by Ian Foster 07 Mar '05

07 Mar '05

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.

1 0