- ogsa-wg - lists.ogf.org

Re: [ogsa-naming-wg] Re: [ogsa-wg] Abstract names in BES
by Hiro Kishimoto 11 Nov '05

11 Nov '05

Ian's email bounced. -- Hiro Kishimoto Date: Thu, 10 Nov 2005 15:46:52 -0600 (CST) Subject: Re: [ogsa-naming-wg] Re: [ogsa-wg] Abstract names in BES From: itf(a)mcs.anl.gov To: "Frank Siebenlist" <franks(a)mcs.anl.gov> Cc: "Mark McKeown" <zzalsmm3(a)nessie.mcc.ac.uk>, "Donal K. Fellows" <donal.k.fellows(a)manchester.ac.uk>, ogsa-wg(a)ggf.org, ogsa-naming-wg(a)ggf.org, ogsa-bes-wg(a)ggf.org I'm concerned that the following two notions may be inconsistent: a) WS-Names should be globally unique (Andrew) b) The WS-Name can be used to pass a LSF jobid (Chris) Or is Chris proposing that LSF be changed to generate its jobids with whatever scheme WS-Naming proposes to ensure global uniqueness? (If it doesn't, then I don't think that Chris can guarantee that the names that LSF generates and the names that someone else generates will not collide.) Ian. >> Mark McKeown wrote: > >>>> Hi Donal, >>>> >>>> >> >>>>>>>> Regarding Chris's desire to be able to pass the LSF jobid >>>>>>>> back to the client somehow - it could be included in the EPR's >>>>>>>> Metdata, possibly RDF could be used to mark up the Metadata >>>>>>>> to indicate that it is a LSF jobid. In this way the Address >>>>>>>> IRI can be kept opaque. >>>>>>>> >>> >>>>>> That would seem to me to be needless disambiguation. Surely it is just >>>>>> up to the service that mints the abstract name to understand it; there >>>>>> is no inherent need for it to explain what that means to anyone else. >>>>>> >> >>>> >>>> I am not sure I understand your comment - you don't seem to >>>> be disagreeing with me... >>>> >>>> Frank wants to use the EPR's wsa:Address IRI as an AbstractName, >>>> Chris wants to send a LSF jobid to the client and the W3C >>>> recommends that IRIs should be opaque. One way to include >>>> the LSF jobid in the EPR is to embed it into the wsa:Address >>>> IRI, this might help make it unique and the client could extract >>>> it from the IRI - however the W3C recommends that IRIs >>>> should be opaque. >>>> > >> >> Well, I also believe that it's better to keep the IRIs opaque and was >> suggesting to use the complete IRI itself as an alternative jobId. >> >> Whether that could work depends on the use cases we have to consider... >> >> -Frank. >> >> -- >> Frank Siebenlist franks(a)mcs.anl.gov >> The Globus Alliance - Argonne National Laboratory >> >>

3 2

RE: [ogsa-wg] Re: [ogsa-bes-wg] Abstract names in BES
by Subramaniam, Ravi 10 Nov '05

10 Nov '05

Hi, I am sorry I missed today's call (combination of a partial conflict and the old habit of expecting the call at 3:00-5:00 Pacific). I may be missing something that has already been covered. Apologies for any redundant discussion. I thought that BES is a focus on the container and not the jobs. It is a job execution environment but the abstract names (if any) should be generated before the request reaches the BES container since the job factory is in the job manager or some such entity. I am not seeing the connection between abstract names for jobs and BES. An abstract name for a container makes sense in this context. In this case, a job id may not be appropriate. I would expect that abstract names have a form that is independent of the type of resource or entity that is referred to by this abstract name. The specific aspects that are determined by type would have to be in the payload. As I was typing this, I saw Mike's email. I would agree that something like a GUID would be appropriate. Alternatively a URI that is parameterized in a domain/application manner may also work (this may accommodate the job id requirement that Chris mentions below while having a similar form for other resources/entities too). Abstract names would be unique (as we all know) but I would expect have a validity lifecycle attached to them (could be as simple as at Time to Live possibly embedded in the name). I would not expect that these are for ever persistent and available but may be driven by policy. Expecting otherwise may put a big burden on the implementation. Is the abstract name an optional or required in all cases (whether embedded in the EPR or not i.e. resolved)? I would vote for it to be optional since in some instances generating the name may not be necessary. An example is an ephemeral job (i.e. < 15 - 30 sec for the lifetime). We have many of these jobs in our environment and these are the ones that really stress our schedulers in many of our production pools. The effort to generate and assign and manage abstract name may not be worth the overhead here. An EPR is all that we may have (hopefully the simplest and really necessary parts in the EPR). Thanks! Ravi ________________________________ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Christopher Smith Sent: Wednesday, November 09, 2005 5:38 PM To: Ian Foster; ogsa-wg(a)ggf.org; ogsa-naming-wg(a)ggf.org; OGSA-BES-wg(a)ggf.org Subject: [ogsa-wg] Re: [ogsa-bes-wg] Abstract names in BES For a mapping of BES to LSF, I would put something like a job id in the abstract name, so that it could be used outside the web services world (say with a CLI). Sure, it could be put in the payload of messages, or retrieved via some explicit call, but it seems reasonable to use the abstract name for this. -- Chris On 9/11/05 17:28, "Ian Foster" <foster(a)mcs.anl.gov> wrote: I found the call today very helpful. One thing that I wanted to get clarification on is the requirement that motivates a desire for "abstract names" in BES. I've heard one, which is that some entity may be handed two or more references (EPRs) to jobs, and want to know which of these are (not) unique. Are there others? Regards -- Ian.

1 0

service/resource identifier on the wire?
by Frank Siebenlist 09 Nov '05

09 Nov '05

In the past I've advocated that we need an AbstractName equivalent as a service/resource identifier on the wire, i.e. present in the soap message. During the last conference call it was mentioned that at the ws-naming F2F it was discussed that this was not needed. Could someone explain what the arguments were? What the discussion was about exactly? (maybe the f2f-minutes would be nice too ... hint, hint ;-) ) Thanks, Frank. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

4 5

RE: [ogsa-wg] RE: One paragraph describing your expectations from the deployment component
by Milojicic, Dejan S 09 Nov '05

09 Nov '05

Hi Andrew, I presume we will have a chance to discuss this during the meeting today, but here is my attempt in summarizing what CDDLM has discussed this morning. > -----Original Message----- > From: Milojicic, Dejan S > Sent: Monday, November 07, 2005 8:31 AM > To: 'Andrew Grimshaw'; 'Andrew Grimshaw' > Cc: 'Hiro Kishimoto'; 'Stuart Schaefer'; ogsa-wg(a)ggf.org; > 'cddlm-wg(a)ggf.org' > Subject: RE: [ogsa-wg] RE: One paragraph describing your > expectations from the deployment component > > Thanks Andrew, > > We will get back to you before the meeting on Wednesday and > we can discuss it in more detail at the meeting. Thank you > very much for taking the time to summarize your expectations, > it will go a long way towards clarifying how CDDLM can > contribute to EMS. I am forwarding your email to the CDDLM > mailing list. > > Best regards, > > Dejan > > > -----Original Message----- > > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] > On Behalf > > Of Andrew Grimshaw > > Sent: Monday, November 07, 2005 8:21 AM > > To: Milojicic, Dejan S; 'Andrew Grimshaw' > > Cc: 'Hiro Kishimoto'; 'Stuart Schaefer'; ogsa-wg(a)ggf.org > > Subject: [ogsa-wg] RE: One paragraph describing your > expectations from > > the deployment component > > > > Dejan, et al, > > > > There are two basic things that EMS needs (in my opinion): > > 1) The ability to identify on which hosts an activity can execute > > because either the executable for the activity is installed > - or CAN > > BE installed. > > 2) The ability to direct that the necessary components for > an activity > > be installed and configured in/on a container - whether that means > > binaries and libraries, licenses, databases, whatever. > > > > In both cases I do not want the activity started. > > > > Let me dive a bit deeper into both: > > 1) The information needed to determine where an activity > can execute - > > either directly, or after some deployment step is needed by RSS so > > that it can make scheduling decisions. While it is not sufficient > > information to make scheduling decisions, it is necessary. > (Other info > > could include load, whether a particular user has privileges or the > > necessary currency, etc.) By definition, CDDLM is not primarily intended to support this functionality. We think that some sort of information service should provide this information. Having said that, CDDLM can still provide some support in this direction (which is maybe 20% of what you need if not less): a) CDL can capture dependencies of deployed components on certain resources which can compared against what is supported on nodes (information provided by other means) and used to decide if/where you can deploy components, and b) CDDLM engines can return information on what has been deployed on them (this is not something that we have specified so far, but it naturally falls under CDDLM). > > 2) Once a placement decision has been made then we must ensure that > > the application/activity is ready to run on the selected container > > resource. In the current JSDL model - all of the information is > > carried in the executable information. > > For more interesting, non-legacy, components latter, it is > likely that > > the mechanism in JSDL will not suffice. Thus, something like: > > Deploy("name of application/component", "name of container > resource") > > > > Where each of the "names" are either path names in a > directory based > > service or EPR's of some sort. CDDLM is primarily focused on deliverying the functionality you have described above. You can take a look at how we utilize it using our deployment APIs, submission language, and component model. One should be able easily to wrap up our functionality to accomplish the interfaces and support requierment you outline in 2) above. Thanks, Dejan. > > Andrew

1 0

RE: [ogsa-naming-wg] service/resource identifier on the wire?
by Maguire_Tom＠emc.com 09 Nov '05

09 Nov '05

So my recollection of the conversation is that I pointed out that AbstractName as currently defined in WS-Naming will not flow on the wire. The discussion from that point forward was about whether or not the AbstractName needed to flow on the wire. There were those that argued that you could make the argument that it was not necessary on an invocation. I suspect that this perspective only considers certain interaction (equivalency for instance). If the AbstractName is used for Authorization policy then I would imagine that it must flow on the wire. There was a thread on this that dealt with a binding of an AbstractName to wsa:Address. Tom -----Original Message----- From: owner-ogsa-naming-wg(a)ggf.org [mailto:owner-ogsa-naming-wg@ggf.org] On Behalf Of Frank Siebenlist Sent: Wednesday, November 09, 2005 1:19 PM To: Andrew Grimshaw Cc: ogsa-wg(a)ggf.org; ogsa-naming-wg(a)ggf.org Subject: Re: [ogsa-naming-wg] service/resource identifier on the wire? Andrew Grimshaw wrote: > Frank, et al, > Let me make sure I understand your question. > > When you say "on the wire" do you mean "must be present in the soap header"? > Yes. > If so, then the discussion was to change the document to state that > the endpoint receiving the message MUST NOT assume that the header > contains the abstract name. The "endpoint" in this case refers to an > endpoint that is being "named". Thus, it cannot be used for dispatch. > > I cannot recall who suggested this (it might have been Tom, I cannot > recall though). The motivation was that because not all elements of > the WS-Address are guaranteed to be included in the header by all tooling. > I'm not sure if I understand what the discussion was related to. It is clear that the current AbstractName element will not end-up in the soap-header. This was the reason for me to suggest the use of the Address as an alternative to the AbstractName and by using a profile to add the right uniqueness properties to the Address such that it can be used as an identifier. Are there issues with the tooling and the address value, and how it ens up in the soap header? And even more important: does the current ws-naming working group believes that having a service/resource identifier that is also present in the message is important enough to standardize its use? -Frank. > -----Original Message----- > From: owner-ogsa-naming-wg(a)ggf.org > [mailto:owner-ogsa-naming-wg@ggf.org] On Behalf Of Frank Siebenlist > Sent: Tuesday, November 08, 2005 11:49 PM > To: ogsa-wg(a)ggf.org; ogsa-naming-wg(a)ggf.org > Subject: [ogsa-naming-wg] service/resource identifier on the wire? > > In the past I've advocated that we need an AbstractName equivalent as > a service/resource identifier on the wire, i.e. present in the soap message. > > During the last conference call it was mentioned that at the ws-naming > F2F it was discussed that this was not needed. > Could someone explain what the arguments were? What the discussion was > about exactly? > > (maybe the f2f-minutes would be nice too ... hint, hint ;-) ) > > Thanks, Frank. > > -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

AI: Proposal for OGSA-WG policy regarding EPRs, WS-Names and such
by Maguire_Tom＠emc.com 09 Nov '05

09 Nov '05

Sorry for the delay. It has been an exceptionally long day..... An OGSA compliant service when returning a reference MUST use a WS-Addressing EndpointReference (EPR). An OGSA compliant service MAY return a profiled usage of a WS-Addressing EndpointReference (EPR). An OGSA compliant service SHOULD return a WS-Naming profiled WS-Addressing EndpointReference (EPR) where appropriate. An OGSA compliant service MUST NOT require that a specific profiled usage of a WS-Addressing EndpointReference (EPR) be returned. Therefore an OGSA compliant service MUST NOT require that a WS-Naming profiled WS-Addressing EndpointReference (EPR) be returned. The reasoning for this is quite simple. The architectural construct for OGSA is a WS-Addressing EndpointReference. WS-Naming presupposes a particular client interaction. Clients may or may not use this particular interaction style (equivalence checking). In particular, placing the requirement that all implementations of a particular portType must return a WS-Naming profiled EPR may be onerous, especially considering that the interaction being fulfilled by the service might never be exercised by the consumer. In general, OGSA would be better served if clients that required such profiled use selected only services that can provide that information. This area, metadata discovery and exchange, is something that OGSA should be addressing. There were further arguments that were raised during the telecon discussion that would be more appropriately addressed to the WS-Naming WG. Thanks, Tom Senior Technologist, CTO Office EMC²|SMARTS 44 South Broadway 7th Floor White Plains, NY 10601 Office: +1-914-508-3477 Mobile: +1-845-729-4806 Email: maguire_tom(a)emc.com <mailto:maguire_tom@emc.com> If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea. Antoine de Saint-Exupery

1 0

Proposed agenda for Nov. 9th call (CDDLM/ACS/GRAAP joint call)
by Hiro Kishimoto 09 Nov '05

09 Nov '05

Hi all, Apologies for cross-posting *ATTENTION* From Oct. 31 and onward telecon starts one hour earlier 5pm EST = 4pm CST = 2pm PST = 10pm UK = 7am JST OGSA-WG revised charter draft has been accepted by GFSG with no change. Congratulations! https://forge.gridforum.org/projects/ogsa-wg/document/OGSA-WG-Charter-2005/… The following is a proposed agenda for OGSA-WG telecon on Nov. 9th Wednesday from 4pm 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: 1109 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 (Nov. 7th) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051107/en/1 Since SC05 is next week, can we have a quorum next week? Agenda bashing 2) CDDLM/ACS/GRAAP joint EMS discussion (60 min) > From F2F minutes; > - Action: Agreed on two-pronged approach for CDDLM(+ACS) on one > side and EMS on the other to describe their approaches in > more detail and to then unify those approaches. (Note > these are 3 separate actions.) > - Action(1): CDDLM team volunteered to look into two issues that > were identified as requirements and report back in an > OGSA call > 1. Where to draw the line in the (CDL) provisioning tree > (see above) > 2. How to provide the cost of configuration Dejan already sent out their discussion summary to the list; http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/10/msg00026.html OGSA-WG has already reviewed their summary (see Nov. 7 minutes) and will give these feedbacks to them. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051107/en/1 > - Action (2): Andrew provide one paragraph describing his > expectations from the deployment component. (done) > Using this paragraph, CDDLM-WG provides a feedback on > how they match his expectations. Andrew's description; http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/11/msg00013.html > Actions(3): > - RSS-WG to produce abstract interface (and responsibilities) of EPS > and CSG. > - Clarify responsibilities/functionality of JM > - Andreas to send detailed EMS draft (pre OGSA 1.0) document to > Steven N. EMS team is working on "composition roadmap" https://forge.gridforum.org/projects/ogsa-wg/document/proposed-ems-roadmap/ > Action(4): Set up a team to explore WS_Agreements issues more, > especially relating to allocation and QoS assurance. And > come back to OGSA-WG on how to use WS-Agreement (possibly > evolved) with EMS. Clarify > - How WS-Agreement possibly needs to change to fit in OGSA > EMS > - Set the first review after 30 days; check what can be > done. > - Volunteers: Steven Newhouse (to lead), Dave Berry, Chris > Smith, (Jim Pruyne; not present >GRAAP-WG to confirm) 3) OGSA naming policy discussion (30 min) Tom will have the written proposal (agreed on the previous call) 4) Information model discussion (20 min) > Action: Andrew to review and point out what is needed for the > BES container > - Goal: A preliminary set of attributes that are > needed for the BES container 5) Common UML tool review (if time permit) > - Mike Behrens has some experience with a number of the listed > tools. He volunteered to check out the rest and give an > evaluation next week > - export/import as one required feature > > - One of the IBM participants will follow up and confirm the > procedures needed and that everyone can use the RSM tool, if the > group decides to go with it. 6) OGSA workshop at Israel Grid Alliance (if time permit) Steve Crumb ask us to send a rep to Tel Aviv before or after GGF16. > In my continued efforts to get an OGSA expert to Israel to discuss > the architecture to a primarily technical audience, Avner and I have > settled on the proposal of having an OGSA half-day workshop > immediately after (or before) the Athens event. This would allow for > someone to be roughly in the same geographic area making a quick, > one-day hop to Tel Aviv much more doable. 7) Wrap up AOB <NEXT CALL> Nov. 14 (Mon) OGSA-AuthZ joint call Basic Security Profile document review, Architecture & Glossary 1.5 Nov. 16 (Wed) EMS architecture, information model & CIM profile Nov. 21 (Mon) Architecture & Glossary 1.5 Profile Definition Update Nov. 23 (Wed) NO call (Thanksgiving) Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 0

Glossary 1.5 draft 1 uploaded
by Treadwell, Jem 08 Nov '05

08 Nov '05

Hi, I've uploaded the current working draft of the Glossary - it's available at http://tinyurl.com/dwx8k. - Jem ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com>

1 0

Teleconference minutes - 7 November 2005
by Andreas Savva 08 Nov '05

08 Nov '05

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051107/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 7 November 2005 ===================================== * Participants Pete Ziu (Northorp Grumman) Jay Unger (IBM) Jem Treadwell (HP) Frank Siebenlist (ANL) Andreas Savva (Fujitsu) Darren Pulsipher (Xango) Takuya Mori (NEC) Tom Maguire (EMC) Chris Jordan (SDSC) Hiro Kishimoto (Fujitsu) Mike Behrens (R2AD, LLC) Apologies: Ellen Stokes, Fred Maciel Minutes: Andreas Savva * November 2 minutes approved with no changes * Profile Definition 1.0 update - Public comment has finished. There are a small number of comments but nothing major. - The GGF Editor has not officially returned the pen to OGSA-WG. The group will start preparing a new version. - Jem will take the pen and make an initial draft. - Tom will take the pen after Jem. * EMS, CDDLM, GRAAP joint call preparation ** CDDLM discussion preparation Reviewed Dejan's meeting notes from October 12 in preparation for the next call. - No issue with communication between CDDLM and ACS via data services (option 2) but eventually details of this interaction should be filled in. - ACS does not place restrictions on the application data it stores. It is up to EMS(CSG) to decide what is where. Action: Hiro will talk with the RSS-WG (owners of the CSG spec) and ask them to outline in a memo what information they expect to have and where it may be coming from (ACS, Information Services, etc.) - [And match that against what the ACS spec already defines.] - Estimate of deployment time - Agreed that this is not a high-priority item at the moment. - Defining the interface and not detailing how the estimation is carried out is a reasonable first step. (Estimation could be history based and also involve some prediction when deployment requests are received for the first time.) - Should this be a simple interface receiving a CDL fragment or one that unwinds a bigger CDL tree? For example, ask for estimates for deploying a CDL tree made of (A,B,C,D) (and considering deployments may be done in parallel) or ask separately for each A,B,C,D part? - Also in the more complex form what should happen if there is history for deploying B,C,D but not A. - Agreed that initially this interface may be very simple: either returns an estimate for whatever CDL (simple or complex) it receives; or "don't know" - Probably need a new sequence diagram to show the relative positioning of this service. [Need to decide when in the EMS Roadmap it appears.] - Hiro will follow up on other issues with Jay ** WS-Agreement discussion preparation - Not sure what the state of this work is as there has been no update from the volunteer team. * Glossary 1.5 review - Client/Service provider/Service requestor - Not sure if these are really needed. The definitions look ok so include them for now. - ACID : leave as is - CSG: leave as is - Component: Jem and Andreas to discuss offline - Context: leave as is - IPC: leave as is - Legacy program: leave as is - Manageability: Refer to WSDM and WS-Manageability specs for consistency (Jem) - Management: Revised definition Action: Jem will update the working glossary copy and the trackers. Action: Andreas to check the use of the term 'use case' in the Architecture document. * Naming proposal status update - Recap of key points from last call - Tom will have the written proposal (agreed on during the previous call) ready within the day. * Basic Security Profile - Draft not ready - postponed for next week * Teleconference schedule ** Next call - EMS discussion first; followed by Naming proposal review - UML tool review (given time) - Mike will send out his evaluation to the list before the call * Next week - SC'05 is next week. - Next Monday: OGSA-AuthZ joint call. (Deliverables, charter, collaboration topics, etc.) Action: Takuya to invite the OGSA-AuthZ team to the call.

2 1

Proposed agenda for Nov. 7th call
by Hiro Kishimoto 08 Nov '05

08 Nov '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Nov. 7th Monday from 4pm to 6pm (CST). *ATTENTION* From Oct. 31 and onward telecon starts one hour earlier 5pm EST = 4pm CST = 2pm PST = 10pm UK = 7am JST The dial-in number for Monday; Free: +1-866-639-4741 Toll: +1-574-935-6703 PIN: 8980700 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 1107 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 (Nov. 2nd) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051102/en/1 Agenda bashing 2) CDDLM/ACS/GRAAP joint call preparation (10 min) This Wednesday is a joint call with CDDLM/ACS/GRAAP in order to review progress after GGF15. EMS team needs to get ready for it. > From F2F minutes; > - Action: Agreed on two-pronged approach for CDDLM(+ACS) on one > side and EMS on the other to describe their approaches in > more detail and to then unify those approaches. (Note > these are 3 separate actions.) > - Action(1): CDDLM team volunteered to look into two issues that were > identified as requirements and report back in an OGSA call > 1. Where to draw the line in the (CDL) provisioning tree > (see above) > 2. How to provide the cost of configuration Dejan already sent out their discussion summary to the list; http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/10/msg00026.html > Actions(2): > - RSS-WG to produce abstract interface (and responsibilities) of EPS > and CSG. > - Clarify responsibilites/functionality of JM > - Andreas to send detailed EMS draft (pre OGSA 1.0) document to > Steven N. EMS team is working on "composition roadmap" https://forge.gridforum.org/projects/ogsa-wg/document/proposed-ems-roadmap/ > Action(3): Set up a team to explore WS_Agreements issues more, > especially relating to allocation and QoS assurance. And > come back to OGSA-WG on how to use WS-Agreement (possibly > evolved) with EMS. Clarify > - How WS-Agreement possibly needs to change to fit in OGSA > EMS > - Set the first review after 30 days; check what can be > done. > - Volunteers: Steven Newhouse (to lead), Dave Berry, Chris > Smith, (Jim Pruyne; not present >GRAAP-WG to confirm) 3) Common UML tool (20 min) > - Mike Behrens has some experience with a number of the listed > tools. He volunteered to check out the rest and give an > evaluation next week > - export/import as one required feature > > - One of the IBM participants will follow up and confirm the > procedures needed and that everyone can use the RSM tool, if the > group decides to go with it. 4) Basic Security Profile document review (60 min) Takuya will post revised draft before the call. 5) Glossary 1.5 discussion (20 min) Jem will lead several open issues in Glossary 1.5. 6) Wrap up (10 min) AOB <NEXT CALL> Nov. 9 (Wed) EMS architecture, CDDLM/ACS/GRAAP joint call information model & CIM profile Nov. 14 (Mon) OGSA-AuthZ joint call Basic Security Profile document final review, Architecture & Glossary 1.5 Nov. 16 (Wed) EMS architecture, information model & CIM profile Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

2 4