- ogsa-wg - lists.ogf.org

RE: [ogsa-wg] BES query
by Ian Foster 15 Sep '05

15 Sep '05

Dave: My "proposal" was just a request that we have the "resolver EPR" in a separate specification. However, in a bit more detail, here are my opinions in this area: 1) The BES specification should just use EPRs, and not mandate the use of WS-Naming AbstractNames. Rationale: Such a requirement imposes a cost on BES users that they may not want to pay--for a benefit that they may not require. Mandating the use of WS-Naming names imposes an overhead in terms of both time (the cost of generating the AbstractName) and space (the storage that it requires). Yet: a) I may not need to perform the equivalence test that AbstractNames are introduced to allow. (E.g., I haven't thought deeply about this--but I can't recall that we've ever encountered that need.) b) I may need to perform an equivalence test, but not require the "globally unique in time and space" constraint that WS-Naming requires. [This constraint presumably constrains the form of the name that I can create, preventing me, for example, from using user-supplied strings.] c) I may need to perform an equivalence test, but want to do that at a different level: e.g., I may already maintain my own table of jobs for some other purpose, so the WS-Naming AbstractName just replicates unique data that I am already maintaining. If people WANT to pass around EPRs that have these AbstractNames in them (or other similar constructs with different constraints/semantics: e.g., "unique within my VO"), all power to them: but I don't see a reason to require this in BES or any other specification. 2) We should have a separate specification for the "resolver EPR" (and associated Resolver portType) and the "AbstractName" concept. Rationale: The "resolver" EPR is useful in a wide range of situations independent of the specific name syntax and semantics described in WS-Naming. I can imagine lots of places where I might use a resolver EPR. E.g., maybe in the BES case my jobs can migrate, and so I want the EPR that I get back to include a resolver EPR that I can use to determine its new location. But as noted above, I don't necessarily need an AbstractName in the BES case. Similarly for relocatable services: maybe I'll do a metadata query on a registry to get a service EPR (with a resolver EPR in it), then if the service is not where the registry says, contact the resolver to determine its new location. Again, I don't see that I will need AbstractName semantics here. Thus, given that we have two concepts that seem logically quite distinct, and that are certainly distinct in terms of when and how that will be used, I argue that they should be separated. 3) You also asked about three levels and about "human-oriented" vs. "abstract". These concepts are not in the WS-Naming spec, but for what it's worth, I don't see them as useful or relevant here. People use many sorts of "names" of different sorts, and they don't cleanly separate into three levels or into "human-oriented" or "abstract". E.g., if I'm implementing a replica location service, I often want to map first from a "logical file name" to a "site name" and then from there to a "physical location." Furthermore, if you build a system of this sort, you have to allow people to stick whatever names are convenient for them in at each level, because often these names come from elsewhere. Some users may make some of these names "human-oriented", others may not--it shouldn't matter to the service. Regards -- Ian. At 08:58 PM 8/30/2005 +0100, Dave Berry wrote: >Ian, > >I wonder whether you or one of your team could write a note about the >background to your proposals? It would help me to understand how they >fit into the wider architecture. At present I don't feel able to make >an informed contribution to the discussion. > >The current shape of OGSA (if I can call it "current" without biasing >the discussion) has three concepts relevant to this discussion: > >1. Three levels of naming (human-oriented, abstract, and address). >2. An implementation of abstract names as an EPR containing a string >and a resolver. >3. A service interface for BES that takes abstract names as >parameters. > >Each has associated questions raised by your concerns: > >1. Do you want to have fewer levels of naming across the architecture >or are you happy with the three listed here? > >2a. Are you happy that abstract names should be represented in this >way? >2b. What would a "resolver without an abstract name" resolve? When do >you need it in addition to or instead of an abstract name? Does it >fulfill a different function or is there some overlap? > >3. What should the BES interface accept instead of or as well as >abstract names? When do you need this functionality? How should the >interface cope with the different types of entity? > >I can make a guess at part of these answers but I'd rather read an >explanation from the horse's mouth. > >Best wishes, > >Dave. > > > >-----Original Message----- >From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of >Ian Foster >Sent: 30 August 2005 04:02 >To: Tom Maguire >Cc: Andrew Grimshaw; ogsa-wg(a)ggf.org >Subject: Re: [ogsa-wg] BES query > > >I'm interested in that question too. As I've said on quite a few >occasions, >I like the EPR + ResolverEPR (as in the original WS-RenewableReferences) >-- >that is a nice simple mechanism. I don't understand why we can't have >this >in a separate specification. > >Ian. > > >At 09:23 PM 8/29/2005 -0400, Tom Maguire wrote: > >So just to get some nomenclature correct. By WS-Names we mean an EPR > >that > >is profiled to > >contain both a ResolverEPR and an AbstractName. So what do we call an >EPR > >which just > >contains a ResolverEPR? > > > >Tom > > > >Ian Foster wrote: > > > >>I believe that the opinion was expressed by some at the San Diego > >>meeting > >>(e.g., by Steve Tuecke) that WS-Names should NOT be mandated. > >> > >>It certainly defines a nice way of using EPRs that will be useful in > >>some > >>situations. But it surely can't be the case that we always want to > >>mandate this particular set of extensions to EPRs. That requirement > >>certainly doesn't jibe with how we use them in all cases, for example. > >> > >>Ian. > >> > >> > >>At 09:25 AM 8/29/2005 -0400, Andrew Grimshaw wrote: > >> > >>>All, > >>> > >>>In the BES working group call last week the issue of naming came up. > >>>The > >>>current DRAFT specification calls for passing WS-Names in and out of >the > >>>various function calls. There was the question as to whether EPRs is >all > >>>that should be specified. We thought this is an OGSA issue: mainly is > > >>>OGSA endorsing the use of WS-Names where appropriate. Clearly I think >we > >>>should. But this should be discussed. > >>> > >>>Andrew > >> > >>_______________________________________________________________ > >>Ian Foster www.mcs.anl.gov/~foster > >><http://www.mcs.anl.gov/%7Efoster> > >>Math & Computer Science Div. Dept of Computer Science > >>Argonne National Laboratory The University of Chicago > >>Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. > >>Tel: 630 252 4619 Fax: 630 252 1997 > >> Globus Alliance, www.globus.org <http://www.globus.org/> > >_______________________________________________________________ >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 _______________________________________________________________ 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

8 17

Meaning of GRID finally revealed
by Ian Foster 15 Sep '05

15 Sep '05

(-: From http://www.broad.mit.edu/cgi-bin/news/display_news.cgi?id=159 The Genome Resources in Dengue (GRID) consortium brings together scientists from Broad's Microbial Sequencing Center and the global dengue research community. GRID scientists seek to understand how the virus interacts with its hosts and evolves under pressure from the human immune system. "We intend to illuminate how genomic diversity in the virus arose and how this variability relates to both the virus' evolutionary success and the array of disease outcomes in patients that result from infection," said Matthew Henn of the Broad Institute who spearheaded the formation of GRID and developed this project in collaboration with GRID scientists. _______________________________________________________________ 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

1 0

RE: [ogsa-wg] OGSA-WG F2F meeting back-to-back GGF14
by Djaoui, A (Abdeslem) 15 Sep '05

15 Sep '05

Hiro Unfortunately I have already booked my flight etc... and I can only make Thursday. Would it be possible to have Resource Management (info/data model) on the Thursday? Abdeslem ////////////// -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org]On Behalf Of Hiro Kishimoto Sent: Thursday, September 15, 2005 11:52 AM To: ogsa-wg(a)ggf.org; ogsa-bes-wg(a)ggf.org; byteio-wg(a)ggf.org; ogsa-d-wg(a)ggf.org; ogsa-rss-wg(a)ggf.org; cddlm-wg(a)ggf.org; OGSA-naming-wg(a)ggf.org; ogsa-authz(a)ggf.org; acs-wg(a)ggf.org; jsdl-wg(a)gridforum.org; graap-wg(a)gridforum.org Subject: [ogsa-wg] OGSA-WG F2F meeting back-to-back GGF14 Hi all, and sorry for the cross-posting. OGSA-WG is planning to have F2F meeting in Boston, back-to-back with GGF14. The meeting will be held on Thursday (9am-6pm) and Friday (8am-3pm) at IBM office in Boston, walking distance from GGF15 venue. The following is tentative agenda items we've listed up at Today's OGSA-WG call. - EMS architecture (CDDLM, ACS, GRAAP, RSS, JSDL, BES) - OGSA-naming session - Resource Management (info/data model) - OGSA-BES session - OGSA-data session (?) If you want to have another session or any specific day/time requirements on any of these sessions, please let me know. I am sorry for this late notice. I am clumsy to organize this F2F meeting since it is our first back-to-back one. Thanks, -- Hiro Kishimoto

1 0

OGSA-WG F2F meeting back-to-back GGF14
by Hiro Kishimoto 15 Sep '05

15 Sep '05

Hi all, and sorry for the cross-posting. OGSA-WG is planning to have F2F meeting in Boston, back-to-back with GGF14. The meeting will be held on Thursday (9am-6pm) and Friday (8am-3pm) at IBM office in Boston, walking distance from GGF15 venue. The following is tentative agenda items we've listed up at Today's OGSA-WG call. - EMS architecture (CDDLM, ACS, GRAAP, RSS, JSDL, BES) - OGSA-naming session - Resource Management (info/data model) - OGSA-BES session - OGSA-data session (?) If you want to have another session or any specific day/time requirements on any of these sessions, please let me know. I am sorry for this late notice. I am clumsy to organize this F2F meeting since it is our first back-to-back one. Thanks, -- Hiro Kishimoto

1 0

OGSA EMS Sequence Diagrams
by Stuart Schaefer 14 Sep '05

14 Sep '05

Hi, The slides in scenario #3 contain the detail that includes the provisioning steps. I do not see where in any of the sequence diagrams the CSG interacts with the ACS service. Candidate Sets are retrieved from the Execution Planning Services. The EPS works with ACS and should also be linked to Provisioning. If a service is already deployed and can be reused, I would presume that EPS would make this determination. The CDDLM system allows for this. Our presumption in CDDLM is that what is returned from the ACS is a parameterized template, that should be partially resolved during the Candidate Set Generation Phase and Resource Reservation Phase. But many parameters are not known until deployment time or runtime. So, prior to invoking a service container (StartActivityFromJSDL() in the first diagram of scenario #1), the CDDLM service can be used to complete the template resolution, deploy the required systems and prepare the job for execution. Not sure if the sequence diagrams need this level of detail. I think the only operations that are missing in the current CDDLM component model (container) are the commands to start and stop the actual job. We have taken care of all of the deploy, register, undeploy requirements as well as can support the "getState()" query from the Information Services. I would also add that we treat releasing resources and un-deploying configurations as different, environment specific operations. We can contribute the sequence diagrams that were created as part of our work and those created by the ACS team to show the detailed steps of provisioning. Would anyone like to see those? Thanks, Stuart Schaefer

2 1

Proposed agenda for Sept. 14th call
by Hiro Kishimoto 14 Sep '05

14 Sep '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on September 14th Wednesday from 5pm to 7pm (CDT). 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: 0914 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (if available) Agenda bashing 2) EMS architecture discussion (90 min) CDDLM in EMS architecture > CDDLM: > Dejan/Stuart: Thanks for attending this session. Sorry for any mixup > here. I hope you did get something useful from Jim's presentation. Based > on our discussions around CDDLM, here is what I captured: > > a. Hiro will send out the pointers to the interaction of EMS services > for the 3 scenarios that was developed at the last OGSA F2F. > b. Stuart will take a look and see how the CDDLM architecture would > address these scenarios and start and email thread in the OGSA mail > list. > c. Ravi would collect any difficult or long drawn discussion topics (as > suggested by the respondents) as agenda items for discussion at the next > OGSA telecom. > d. The OGSA WG will study the high level scenarios from CDDLM that were > the model for the CDDLM specs. Need to reconcile these into the EMS/OGSA > space. Meeting summary; https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050907/en/1 Related materials; http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/09/msg00032.html Stuart's comments; http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/09/msg00040.html 3) Wrap up (10 min) AOB <NEXT CALL> Sept. 19 (Mon) Architecture & Glossary 1.5, Basic Security Profile Sept. 21 (Wed) GGF15 & F2F preparation Sept. 26 (Mon) OGSA-AuthZ-WG, Information Modeling Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ ---- Hiro Kishimoto

1 1

OGSA Roadmap document - last call for comments
by Treadwell, Jem 13 Sep '05

13 Sep '05

Hi, I've uploaded v22 of the OGSA Roadmap document, with all known issues addressed. You can find it at http://tinyurl.com/9bspt. This is the last call for comments before submission to the GGF Editor for publication. If you have comments, please get them to me by 10 am US Eastern time on Friday, September 16th. If there are no significant comments I plan to submit the document on Friday afternoon. Thanks! - 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

No RM teleconference on the 13th
by Fred Maciel 13 Sep '05

13 Sep '05

Hi, No RM teleconference on the 13th -- not enough to discuss (and I'm in a business trip). Sorry for the reversal from my annouced plans. Please use e-mail for any discussions in the next couple of weeks. Regards, Fred Maciel Hitachi America R&D

1 0

OGSA Security Profile - Secure Channel 1.0
by Takuya Mori 12 Sep '05

12 Sep '05

Hi, The first draft of "OGSA Security Profile - Secure Channel 1.0" has been uploaded to the grid forge. Document URL: /projects/ogsa-wg/document/OGSA_Security_Profile_-_Secure_Channel_-_1.0/en/2 I'm sorry for my being late to upload this. (It took even longer than I expected.) ---- Takuya Mori moritaku(a)bx.jp.nec.com / tk-mori(a)isd.nec.co.jp System Platform Software Development Division NEC Corporation, Tokyo Japan

2 2

Update to OGSA 1.5
by Andrew Grimshaw 12 Sep '05

12 Sep '05

All, While explaining OGSA to some very technical folks last week it came up that the 1.0 document does not describe an "object model" so to speak. in other words, what are the "atoms", what is the minimum we assume, etc. For example, we assume: that resources have interfaces, that they process messages, that their behavior may be history dependent, that they are referenced with EPR's, that the atoms may have a unique AbstractName that they may be both servers and clients of other services We also seem to assume that there is some mechanism to get/set some form of metadata (resource properties) We seem to want to be able to find out what interfaces are supported (it is in base profile .. And I think should be in any profile - opinion) We seem to assume a factory pattern - though it is not explicit, and not part of lifetimes I am sure there are others. Comments? Should I write something up along this line for inclusion in the 1.5 document? Andrew

3 2