- ogsa-wg - lists.ogf.org

OGSA Basic Profile 1.0 v006 Draft uploaded to gridforge
by Tom Maguire 18 Jan '05

18 Jan '05

The latest draft of the OGSA BP has been uploaded to the 'working drafts/basic profile' folder. This will be the draft that we will be discussing on the Wednesday 1/19/05 telecon. https://forge.gridforum.org/projects/ogsa-wg/document/OGSA_Basic_Profile_1.… Tom

2 1

RE: [ogsa-wg] OGSA-EMS Meeting Agenda (2005-01-17)
by Subramaniam, Ravi 17 Jan '05

17 Jan '05

Hi, Thanks for all the responses. It is in a way heartening to see this both from a participation perspective and with respect to my sanity. I was uncomfortable with the way the EMS discussion going with trying to "nail down" something without having any wood to nail to. I thought I was seriously missing something and decided to go with the "flow". I also had this uncomfortable feeling that my attempts to do the right thing were being misunderstood by some. I think we are not ready from "a reasonable agreed upon architecture" to the "candidate set of specs for a profile". I also thing the value of OGSA is from defining the architecture which acts as the scaffolding for the many specifications that are each being developed with a narrow focus (not bad in itself since that is their stated purpose). These specifications for the most part are "works in progress" and one or two that are ready or close to ready do not make a profile for an areas like EMS. We are also not agreed on the concepts in the architecture as the current exercise in re-labeling the concepts indicates. We have a strawman but more work is necessary to vet the architecture. On the other hand, we have implementations (or implementations in flight) in and around this space. From what I know/understand most are capable of scheduling execution but not managing execution. I am, therefore, uncomfortable basing the architecture definition on a few examples which could leave out other legitimate examples. We need to drive more participation and arrive at a desired architecture. This activity need not take a long while and can be in parallel to activities going on in candidate specs. Also as more implementations adopt some of these lower specs we will have more data points. I wanted to add my 2 cents to this discussion. It looks like we may want to modify the agenda to discuss the issues raised. ??? Talk to you later today. Ravi -----Original Message----- From: Christopher Smith [mailto:csmith@platform.com] Sent: Monday, January 17, 2005 11:48 AM To: Fred Maciel; 'David Snelling'; Hiro Kishimoto Cc: 'Ian Foster'; Subramaniam, Ravi; ali(a)epcc.ed.ac.uk; andreas.haas(a)sun.com; andreas.savva(a)jp.fujitsu.com; asm100(a)doc.ic.ac.uk; D.Snelling(a)fle.Fujitsu.com; darrenp(a)cadence.com; dejan(a)hpl.hp.com; flon(a)isi.edu; grimshaw(a)cs.virginia.edu; hornwp(a)us.ibm.com; jian(a)xcerla.com; jon.maclaren(a)man.ac.uk; naber(a)man.poznan.pl; nitzberg(a)pbspro.com; 'OGSA-WG'; pruyne(a)hpl.hp.com; Rajic, Hrabri; ramin.yahyapour(a)udo.edu; Scott.Jackson(a)pnl.gov; sjn5(a)doc.ic.ac.uk; tkojo(a)mvi.biglobe.ne.jp; troney(a)ncsa.uiuc.edu; Uwe.Schwiegelshohn(a)udo.edu; v.sander(a)fz-juelich.de; Wolfgang.Ziegler(a)scai.fraunhofer.de Subject: Re: [ogsa-wg] OGSA-EMS Meeting Agenda (2005-01-17) On 17/1/05 10:57, "Fred Maciel" <fred-m(a)crl.hitachi.co.jp> wrote: > >> 3) A Job Management WSDL spec - would be nice, but to >> do it right we need WSDM first. > > How about JSDL? Works without WSDM (but yes, should work better with WSDM). > JSDL is not intended to be a document format to encapsulate job state. It is very clearly focused on the definition side of things. Other document formats and manageability interfaces will be required for job management. Basing this on WSDM seems to be the "right thing" to do. -- Chris

1 0

Re: OGSA-EMS Meeting Agenda (2005-01-17)
by David Snelling 17 Jan '05

17 Jan '05

Folks, On 17 Jan 2005, at 19:24, Andrew Grimshaw wrote: > I think it is premature to think about a profile except in general > terms of what we think should go in it. I think we need to think about > spec’s, forming working groups to generate those specs, and so on. > (Forming working groups involves charters, BOF’s, etc.) Agreed. It is definitely too early to talk about profiling EMS (even candidate profiles). But, we really do need a WG started to define a minimal set of interfaces that actually allow us to run "hello World" on a Grid. I'm not sure I agree with, or really understand, Andrew's terms below, but then that is what a WG is all about. > In particular I think we should focus on the basic services we have > identified so far (or as they were renamed to avoid confusion): > > Service containers > Actors > Solutions > Solution Factories > Actor descriptors – which may be the same as something another group > is working on – a description of the execution component. Hiro help me > here. > > And so on. We then need to make sure all of the players who may want > to be included are contracted: e.g., Globus, EGEE, > OMII, SGE, Platform, PBS, Virginia, and who ever else wants to be > involved. I would add to this list Unicore, NAREGI, and China Grid all of which have running interfaces parallel to the GRAM interface in Globus. All these groups have suggested to me in the past few days that they want to join a WG on this topic. OMII is discussing it actively. JSDL is ready for a delivery mechanism, .... In short, a BoF is in order. -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

1 0

Data: Proposed agenda for Wednesday 19th January
by Dave Berry 17 Jan '05

17 Jan '05

Dear all, Here is a proposed agenda for the data telcon on Wednesday January 19th, which will be at the usual time of 8.00am (PST) / 11.00am EST / 4.00pm (GMT) / 5.00 pm (CET). UK Dial In: 0845 245 0224 USA Freephone: 1866 838 0046 International Dial In: +44 1452 542309 PIN: 632 065 (Reference 2483651) 1) Early discussion (5 min) Note taker assignment Roll call Agenda bashing 2) Update on outstanding actions (5 min) - Simon to flesh out his metadata question for discussion in a broader group. 3) Update on OGSA Profile work (5 mins) 4) Update on upcoming meetings (10 min) - UK meetings, Feb 1-2? - OGSA F2F, Chicago, Feb 14-16. 5) Architecture issues (30 min) - Is data transfer a service? - Is there any standards activity w.r.t. replication? Should we organise a workshop / F2F meeting on this topic? - Do we need a standalone cache service? - Other questions 5) Wrap up (5 min) AOB DONM Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

Information for GGF13
by Hiro Kishimoto 16 Jan '05

16 Jan '05

To GGF13 attendees ---- Hiro Kishimoto -----Original Message----- From: Ann M. Collins Subject: [gfsg] More Info for GGF13 Grid Forum Korea has a great website with loads of information on GGF13. Please check it out and share the information! http://www.gridforumkorea.org/ggf13/index.htm Thanks! Ann ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ann M. Collins Director, Events & Conferences Global Grid Forum Tel: +1-630-252-4679 Fax: +1-630-252-4466 Mobile: +1-630-715-1943 Mail to: collins(a)ggf.org

1 0

OGSA-EMS Meeting Agenda (2005-01-17)
by Subramaniam, Ravi 15 Jan '05

15 Jan '05

Hi, Here is the agenda for this Monday's teleconference. As agreed at the last F2F we will be focusing on developing an EMS interoperability profile. We will use the Draft Profile template (Tom, Dave) as a reference (attached for you convenience). We encourage persons who are active in relevant GGF and other standard organization WG and people who are very familiar with relevant standards to attend these meetings to provide the right and informed perspectives and inputs. If you would be willing to educate the rest of the participants on one or more applicable standards that you are very familiar with please let me know and I can schedule some time. These would be brief overviews that would lead to more detailed discussions in future as we narrow on the appropriate set. Please send me pointers to definitive documentation on any standards that you feel should be part of the EMS profile. I will compile these as references for those who need to delve deeper. Dial-In Date: January 17th, 2005 (Monday) Time: 5 - 7 PM (CST) 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 <http://ogsa.glance.net/> Session key: 0117 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html Agenda: 1. Roll Call (5 mins) 2. Agenda Bashing (10 mins) 3. Ratification of previous minutes (5 mins) 4. EMS profile discussion (tentative) (90 mins) a. Catalog applicable standards b. Review known standards wrt to the architecture c. Identify initial set 5. Opens and wrap up. (10 mins) Thanks! Ravi

1 0

How to make effective use of WS-BaseFault in GFF specs
by Steve Loughran 14 Jan '05

14 Jan '05

Hello, I'm looking for some pointers on how people have made effective use of WS-BF in specifications, and what is the general best practise. 1. How do people wrap SOAPFaults? Do they define a WrappedSoapFault extension of BaseFault? Do they extract the unofficial extra fields, like the Axis HttpFaultCode and stack trace? 2. What is the i18n policy on descriptio? Is it assumed to be in en-us or whatever the implementor chooses. Given that <description> is allowed multiple times, a language attribute would let me return messages in different languages. Does anyone do that in conjuction with the appropriate xml:lang attributes? 3. How do people handle native language exceptions? Have the framework generate a SOAPFault and wrap it, or redo all the work themselves? I'm planning on having a fairly generic 'DeploymentFault' with extra info that I want for diagnosis (hostname, process identifier, stack trace), and under there a few more faults (WrappedSoapFault, LanguageFault) with extra data. All my operations will declare DeploymentFault as their sole return type; the Java equivalent of 'throws Exception'. That way future implementations get scope to add more stuff. For specific faults which do not need to add new fields, I am not going to type them, but just use the BaseFault/ErrorCode element with different QNames for each fault. Thoughts? -Steve

1 0

Teleconference minutes - January 12, 2005
by Andreas Savva 13 Jan '05

13 Jan '05

Minutes attached. Ref: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050112/en/1 -- Andreas Savva OGSA Teleconference - January 12, 2005 ====================================== * Participants Mike Behrens (R2AD, LLC) Bill Horn (IBM) Mark Morgan (UVa) Andreas Savva (Fujitsu) Jem Treadwell (HP) Jeffrin J. Von Reich (HP) Apologies: Fred Maciel, Ravi Subramaniam, Hiro Kishimoto, Dave Snelling, Andrew Grimshaw Minutes: Andreas Savva * Jan 10 minutes approval postponed for next call * OGSA Version 1.0 and Glossary status Discussed status and process to finalization: OGSA version 1.0 still has an incompletely updated EMS section. The Glossary may be affected by this update. It was agreed that this review was final for the other parts of the two documents and that a subsequent (partial) review should be done just for the updated text. Subsequent reviews to be done by email: to the list and to each person mentioned on the Authors list. Target submission is as soon as possible and definitely within January. The OGSA version 1.0 and Glossary are to be submitted to the Editor together. Their submission will also be coordinated with the CMM document submission, in so far as determining and using the final GFD numbers in the citations. ** Glossary Document walkthrough of draft 8 (not on gridforge yet) Jem has accepted all changes from previous edits. Changes showing are those from Hiro and from some comments from Olegario. - Some additions of terms for consistency and also to put definitions against the shorter entry. - Naming update: deleted 'uniquely' from the general definition (ref: Andrew's mail) - Deferred discussion around 'task' until the EMS section is finalized. - Agreed to remove 'lightweight' from the SOAP definition - Agreed to remove initial sentence from 'Security considerations.' It is not a valid reason for security considerations not being applicable. - To update the GFD for the CMM document (when known) Jem will upload a new draft to gridforge and wait for the final version of the OGSA document. ** OGSA version 1.0 Document walkthrough of draft 21 (from gridforge) Changes are relative to the version submitted for public comment. (And will be accepted for the next draft.) - Abstract updated to be more specific on what the document covers. - Copyright and IPR statement moved to the back - Added Glossary mention as well as Glossary section pointing to the Glossary document. - Changed the statement about the next version being a recommendation to more general statement about recommendation documents (to reflect current consensus). - Discussed Ian's comment about defining virtualization further. Agreed that it is not necessary to go in more detail at the moment (not beyond what's in this document and the Glossary) - To update the copyright notice: 2002-2005 - Lighter color scheme for Figures 1-3 is better but some text is still difficult to read. Agreed to review figures for legibility once more and make sure the text is clearly visible. - Agreed to change "SOAP as the primary transport" to "SOAP as the primary message exchange format" in infrastructure services. - Agreed to change the examples after the "unit of work to be managed" in EMS to specifically state "OGSA application or legacy." (And will revisit this section for a final review) - Discussed 'job is a resource' statement and agreed that some clarification is necessary; re-arranging text to put this statement to the end of the paragraph might be clearer. - Need to revisit spelling once more to make sure it is only US spelling as agreed in previous reviews (some words still remain). - CIM/WBEM is ok as is (even though it should really be just WBEM). - Naming udner Information services is not updated yet. Andreas to update according to Andrew's email. - References: [OGSA RM] bookmark seems broken. Andreas to update. Andreas will upload a new (hopefully final) version and mail authors and the list for a final review.

1 0

Proposed agenda for Jan 12th (5-7pm CST) call
by Andreas Savva 12 Jan '05

12 Jan '05

Here's the proposed agenda for the Wednesday, January 12, 5pm to 7pm (CST), call. [A number of people might not be able to make it or might have to leave early. So this is likely to be a short call, perhaps only one hour: 5pm to 6pm.] ----- Dial-in numbers: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service: URL: http://ogsa.glance.net <== ** NEW ADDRESS ** Session key: 0112 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html ----- 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (if there is quorum) * Jan 10 call: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050110/en/2 Agenda bashing 2) OGSA version 1.0 and Glossary (semi-)final review Review the documents in preparation for re-submission to the GGF Editor. The review is limited to issues raised in the public comments and subsequent revisions to address them. (No post-v1 discussion.) We will not go through the documents in detail; please review them in advance. Note: There are still a few open issues with the latest drafts. If these issues are addressed and final drafts are ready we will do a final review. Latest drafts: OGSA version 1.0: https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-spec/en /21 or http://tinyurl.com/5fxfd/draft-ggf-ogsa-spec/en/21 Glossary: https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-glossar y/en/16 or http://tinyurl.com/5fxfd/draft-ggf-ogsa-glossary/en/16 3) Wrap up (10 min) AOB Next call schedule: Jan. 17 (5pm-7pm CST) EMS design team Jan. 19 (5pm-7pm CST) Basic profile discussion -- Andreas Savva Fujitsu Laboratories Ltd.

1 0

Teleconference minutes - January 10, 2005
by Andreas Savva 11 Jan '05

11 Jan '05

Minutes attached. Gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050110/en/1 -- Andreas Savva OGSA Teleconference - January 10, 2005 ====================================== * Participants Dave Berry (NeSC) Abdeslem Djaoui (RL) Ian Foster (ANL) Andrew Grimshaw (UVa) Bill Horn (IBM) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Tom Maguire (IBM) Mark Morgan (UVa) Takuya Mori (NEC, ANL) Andreas Savva (Fujitsu) Dave Snelling (Fujitsu) Ravi Subramaniam (Intel) Jem Treadwell (HP) Jay Unger (IBM) Minutes: Andreas Savva * January 5 minutes approved with no changes * Basic profile draft review Very early draft uploaded to Gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/OGSA_Basic_Profile_dr… - Fairly close in structure to profile template. It is an early draft and incomplete. - Some discussion at the beginning on extensibility and why interoperability does not apply. - Includes Addressing, Resource, Resource Lifetime, Service Group, Base Faults. - Addressing: Reference properties: - If there is a policy extensibility it must be the first one - Sender cannot construct the EPR (might be problematical; how to check) - Signatures? - Which version of WS-Addressing is used or is WS-Addressing discussed in generic terms? - Statements assume the version submitted to W3C. - WS-Addressing statements relate only (/mainly) to EPRs - (Message information and faults not fleshed out (MIH)) - Should Resource be included in the basic profile. Does the resource access pattern preclude 'generic' web services? - Need clarification of client using OGSA (what it can expect) vs service that is in OGSA (what it must provide and how). - An 'ogsa service' must be one that implements the profile (or parts of the profile) in the defined manner. - As such web services are not precluded; but they will not be 'ogsa services' - This is a point for further discussion and it was agreed that a section to address this issue should be added: What the client has to understand and what is required of services that participate. - For example the client would have to understand EPRs - The second point is what this document is describing - Is everything included in the profile or are more additions planned? - Still incomplete. For example, base notification will probably be added. - How about protocols? - This basic profile is an extension of the WS-I basic profile. As such, what is included in the WS-I basic profile is also included here. - Note that there is no a requirement to implement everything in the profile. Often the statements are of the form: "if something is done it must be done this way" so if something is not implemented all the related statements do not apply. - For example, UDDI: no requirement to use but if used then it must be used in the way that the WS-I basic profile describes - Also note that the OGSA basic profile does not (cannot) reduct/remove restrictions from the WS-I profile. - As a general description approach see R1003: - WS-I allows for optional QName for wsdl:service; an instance that the ogsa profile might want to impose a stricter restriction. - It was agreed that this is ok as a technique (and defering agreement on content for now) - Should the basic profile also include security? - Different thoughts of how to include security. It might be too complex to include it at this moment. - Perhaps do a base profile and a security base profile separately first and then talk about how they should be used together. - Agreed that the numbering used in the document is confusing. Need to come up with a clearer method. ** 1.12 Resource embodiment Again here it might be a good idea to separate the requirements on the clients and services. ** 1.14 Get resource property Set or Query are not included. As an example, at a later point 'query' might be included as an option. The profile could then mandate what is required for this functionality, if provided. In other words, the original specification allows support for many query languages, but the profile could state that as minimum support for XPath version x.y.z must be provided. (Without precluding different or extended query mechanisms on properties.) ** 1.16 Scheduled Termination - Different levels of compliance are also possible. For example, suppose that 'Scheduled termination' must be supported. It could be supported by providing the operation but returning a fault, or it could be supported and implemented according to some optional method described in the original specification. - In other words, all the profile typically says is that the operation must return a valid response (and valid responses are according to the original specification). - Again it might be possible to place more restrictions on the required semantics than what the original spec intended. But the original spec might have been defined the way it was for certain reasons. Care is needed. ** 1.17 Mandates SGs for collections - Phrasing seems overly restrictive; might want to allow for other mechanisms to provide the semantics of the collection - Clarified that statement relates to "if service groups are implemented" it is not intended to preclude other mechanisms for collections. ** Other In general, note that restrictions in the original specifications still apply. - Any Missing functionality? - Naming: It should be part of a base profile even though there are no hard standards yet. - 'Base' here refers more to the maturity of the specifications rather than their place in the architecture. - Renewable References: not much progress yet. There was a proposal to push it into WS-Addressing group in W3C. Not sure how it will evolve. - Providing required resource properties definition and metadata on them - e.g., mandate the WSRF optional metadata on resource properties themselves? - WSDM - Not sure if it will be part of the basic profile. May be one level up. But some parts of it might belong at a lower level: e.g., identity. ** Next steps: Tom has the pen. He will pass it to Dave S tomorrow. Next time to review this draft: Next Wednesday Jan. 19 ** Proposal to draw up a list of all relevant standards and references to them to make it easy to read up and follow the discussion. Ravi volunteered to do a first draft. * Next F2F agenda https://forge.gridforum.org/projects/ogsa-wg/document/agenda_for_2005_Feb_m… - Hotel in question is Westin (O'Hare Airport) - Andrew to follow up with hotel reservation - (Might want to have the conference room for an extra day at the end for a separate (non-OGSA) meeting) - Add Ravi to the list of participants - Main topic is Basic profile discussion. Current schedule proposal splits this discussion across 2 days. - Agreed that it would be more efficient to keep the Basic profile discussion on the same day and split the day into a discussion of the different sections of the profile - So Monday is dedicated to the base profile exclusively: Work out the detailed schedule later on - Tuesday: move on to other topics: EMS, Data, Naming - Proposal to have EMS & Data refactoring before the EMS & Data profile discussion - Is there enough representation from the Data team? - Andrew and Mark will be attending. - Dave B cannot make it. He will raise the issue on the Data call this week. - What is the difference between session (5.2) and the earlier EMS session? Discussion of the architecture versus the profile. - Proposal to discuss the EMS profile on the next EMS call agenda: Discuss which standards should be included. * GGF13 session schedule update Reference: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/01/msg00009.html Proposal for Information services to share the Resource Management section - There has been some interest from INFO-D group to make a presentation to the OGSA-WG; maybe 20 minutes. No specifics yet. - Consensus that it would be ok to make the RM session a shared session for this purpose if necessary. Work out the details later. * Next call - Review of OGSA version 1.0 and Glossary drafts (final review if possible) - Hiro, Andrew, Dave S will not be available (GFSG F2F) - Jem can only attend for the first hour - Andreas to send out agenda; this is likely to be a short call.

1 0