August 2005 - 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

OGSA-WG and fellow WG Winter F2F Survey
by Hiro Kishimoto 07 Sep '05

07 Sep '05

Hi all, and sorry for the cross-posting. OGSA-WG and fellow WGs are planning to have Winter F2F meeting in December or January. At the OGSA-WG F2F meeting in week before last, I took action item to ask all expected attendees for their availability for Winter F2F meeting. Please take the time to fill in the following online survey by next Monday (September 5th). We hope to decide date and city next week. Post the survey on a Web site - use this URL: http://www.zoomerang.com/survey.zgi?p=WEB224LBPWYVUT Thanks in advance, -- Hiro Kishimoto

1 3

Updated Roadmap document and Spreadsheet posted to gridforge for tonights call<EOM>
by Tom Maguire 31 Aug '05

31 Aug '05

Frey’s Law: “Every 5 years the number of architecture components double and the ability to comprehend them halves” Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601

1 0

RE: [ogsa-wg] BES query
by Dave Berry 31 Aug '05

31 Aug '05

Ian, As always, you raise interesting questions. Some I want to ask you about further; some I would like to see other people address. However, I was surprised by your reply about the "three levels" of naming. While WS-naming doesn't include these concepts, the OGSA v1.0 document does. They also form the basis of the GFS working group work that led to RNS and WS-Naming, and are important parts of EDG/EGEE, for example. That doesn't mean that you have to agree with it but I'm surprised that this issue wasn't resolved earlier. I'm also surprised that you give name equivalence as the main characteristic of an abstract name. I thought the main characteristic was that it was a persistent name that does not specify a particular location. (Although this could be a property of the WS-Name package rather than the string - see below). I'm afraid I don't follow your example of a file replication system. Clearly we need to name the separate entities involved and there may be many levels of indirection. I don't see why that is an argument against the three level approach. We don't need to have one "level" of name for each "level" of indirection. Turning to a question I'd like to see other people address: Ian's point about uniqueness within a particular context makes good sense to me. If a WS-Name is a combination of an arbitrary string and a resolver, isn't it the combination of the two that should be globally unique? E.g. if one WS-Name resolves "foo" to my hard drive and another resolves "foo" to Ian's, the two WS-Name packages themselves are still globally unique. I suppose this is why Ian took name equivalence as a key property. Do we perhaps need a scope notion in WS-Names, so that they may be valid within a VO, or globally unique, or have some other scope? I guess the counter to this is whether it is really such an imposition to create a globally unique string, given that UUIDs seem to do the job. Dave. -----Original Message----- From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: 31 August 2005 00:35 To: Dave Berry; Tom Maguire Cc: Andrew Grimshaw; ogsa-wg(a)ggf.org Subject: RE: [ogsa-wg] BES query 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 <http://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 <http://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 <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 <http://www.globus.org/>

1 0

RE: [ogsa-wg] Proposed agenda for Aug. 31st call
by Andrea Westerinen (andreaw) 31 Aug '05

31 Aug '05

Hiro, Do you know when the resource management work will be discussed? It seems to have fallen off the agenda for today (which is ok) and I would like to block my calendar to participate. Thanks, Andrea > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Hiro Kishimoto > Sent: Wednesday, August 31, 2005 2:58 AM > To: ogsa-wg(a)ggf.org > Subject: [ogsa-wg] Proposed agenda for Aug. 31st call > > Hi all, > > The following is a proposed agenda for OGSA-WG telecon on Aug. 31st. > 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: 0831 > See more explanation: > http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg > 00077.html > > 1) Early discussion (20 min) > Note taker assignment > Roll call > Telecon minutes approval (if available) > Dec or Jan F2F date/venue > Agenda bashing > > 2) Roadmap document review (60 min) > > - I've responded to all public comments. > > - Andreas created a new tracker for the next version. I've > opened two > > trackers based on public comments, and moved one that we > deferred in > > 1.0. > > - I've made all the editing changes except for the items below. > > - Waiting for new/updated sections from Tom & Takuya. > > - I haven't yet updated the tables from the spreadsheet - > I'll do that > > once the final sections are in place, to make all the dates > consistent. > > - I've uploaded the latest version of the standards spreadsheet to > > Gridforge, though it will need updating to add the B/P breakout > > documents > > > > On Wednesday's call we need to discuss use of OGSA as a trademark, > > which might result in more editing to make our use consistent. > > 3) OGSA WSRF Basic Profile review (30 min) > Tom has uploaded revised draft to GridForge. > https://forge.gridforum.org/projects/ogsa-wg/document/draft-gg > f-ogsa-wsrf-basic-profile/en/35 > > 4) Wrap up (10 min) > AOB > > <NEXT CALL> > ---- > Hiro Kishimoto > > -- > Hiro Kishimoto >

1 0

Teleconference minutes - 29 August 2005
by Andreas Savva 31 Aug '05

31 Aug '05

Minutes attached. Gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050829/en/1 -- Andreas Savva OGSA Teleconference - 29 August 2005 ==================================== * Participants Ravi Subramaniam (Intel) Latha Srinivasan (HP) Andreas Savva (Fujitsu) Takuya Mori (NEC) Tom Maguire (IBM) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu) Mike Behrens (R2AD, LLC) Minutes: Andreas Savva * Aug. 10 Teleconference Minutes: approved with no changes * OGSA Roadmap - Should have an OGSA trademark usage discussion - Tom will have updated sections for Jem by next call * August F2F evaluation - Consensus on the call that the meetings went well. - Probably set up the Dec/Jan one along the same lines - There is a GFSG meeting in January which some members will have to attend. Action: Hiro to do the usual survey for time/place. ** F2F minutes approval Andreas to do all necessary modifications. *** Day 1 - Attendee corrections: - Von's affiliation is NCSA - Add Ravi to participants (As a followup to the discussion Hiro has asked Frank to give the group information on security guidelines. Takuya to follow up with Frank.) Minutes approved with minor changes. *** Day 2 am: approved with no changes *** Day 2 pm - Add Component model to CDDLM documents list - Application Description should be Application Archive - "AA are the contents ..." should be revised to "AA provides the...." - "An archive description ..." should be changed ... to "i.e., dependencies. " - Minutes approved with minor modifications. *** Day 3 am - Change SOAP text: SOAP 1.2 is not compliant with BP 1.1 while SOAP 1.1 is. - Text starting with "As we move to implementing ..." should be moved under a different topic. Check meeting agenda for topic name. - Minutes approved with minor modifications *** Day 3 pm - Hiro to upload his presentation (re-charter) - Hiro to ask Steven N for his Glue presentation - Add Ravi to the attendees - Minutes approved with minor modifications *** Day 4 am - Approved with no changes *** Day 4 pm - Approved with no changes *** Day 5 am - Approved with no changes ** Other issues - Discussed and agreed that agenda topics should also be tracked. There is an existing tracker and the Chairs and Secretary will share the work of updating it. - Hiro to check what topics should be tracked from the minutes * Teleconference schedule review - 8/31 - Roadmap added - 9/5 - Labour day; no call - 9/7 - EMS discussion - Confirmed that Ravi can make it - Need to narrow down the agenda a bit more and decide if there is enough time to tackle all topics. - Hiro to follow up with chairs. - Architecture 1.5 moved to 9/14 - Resource information model changed to information model Action: Hiro will upload a revised version. * OGSA WSRF Basic Profile review - Major change is the removal/update of security section - Agreement at the F2F was to take the security sections/appendices out, require at least one security profile and then define more than one. - Changes to bring BP in line with the above. Remove list of security related profiles in Abstract - Removed section 8 (security) - Deleted normative and non-normative security related references - Changed appendices - Removed the EndpointKeyInfo element from schema. It now has to be defined in the appropriate security profile. - The referenced specifications table at the end needs update ** Security update - A conformant OGSA Basic Security 1.0 profile should expose a well known conformance claim, defined in wsdl - It is ok to have multiple claims - There MUST be a claim attachment. So it is a stronger statement than the WS-I profile claim attachement. - Have to state where it is attached (WS-I gives a choice of locations) - Agreed to attach to wsdl:portType (which is one of the WS-I choices) - Should the security profile be discussed in section 8 or in 1.2, or both? - Since the security profile(s) is not written yet it not clear how to discuss the relationship. In any case there is no restriction to stating profile relationships only in 1.2. - Agreed that some description should be added to section 1.2, with details in section 8 - Is claim attachment sufficient explanation or should there be more discussion on the requirements that a security profile should fulfill? - Security profile as envisaged right now only really covers secure communication - Agreed that it is not possible to describe the requirements such a profile has to satisfy at this point; besides the generic claim that the profile is compliant to the OGSA basic security 1.0 claim. - Each conformant security profile should define two conformance URIs: The well known conformance claim defined in the Basic Profile and an additional more specific claim to that security profile. - Agreed to change all namespace uris; delete the dates. Action: Tom to post revised versoin after the call - Ideally the BP should be submited together with the security profiles. - Tom and Takuya to try and coordinate to get all documents out at the same time (if possible) Action: Hiro to arrange for additional time slots on calls as needed for reviewing the security profiles. * Next call - It is not possible to discuss information modelling this week - Fred is planning to do an internal call next week tuesday. - Agreed to re-schedule for after Sep 19. - Roadmap and BP review for the next call.

1 0

Proposed agenda for Aug. 31st call
by Hiro Kishimoto 31 Aug '05

31 Aug '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Aug. 31st. 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: 0831 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) Dec or Jan F2F date/venue Agenda bashing 2) Roadmap document review (60 min) > - I've responded to all public comments. > - Andreas created a new tracker for the next version. I've opened two > trackers based on public comments, and moved one that we deferred in > 1.0. > - I've made all the editing changes except for the items below. > - Waiting for new/updated sections from Tom & Takuya. > - I haven't yet updated the tables from the spreadsheet - I'll do that > once the final sections are in place, to make all the dates consistent. > - I've uploaded the latest version of the standards spreadsheet to > Gridforge, though it will need updating to add the B/P breakout > documents > > On Wednesday's call we need to discuss use of OGSA as a trademark, which > might result in more editing to make our use consistent. 3) OGSA WSRF Basic Profile review (30 min) Tom has uploaded revised draft to GridForge. https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-wsrf-b… 4) Wrap up (10 min) AOB <NEXT CALL> ---- Hiro Kishimoto -- Hiro Kishimoto

1 0

Re: [ogsa-wg] BES query
by Hiro Kishimoto 31 Aug '05

31 Aug '05

Tom's email bounced. -- Hiro Kishimoto Date: Mon, 29 Aug 2005 21:23:58 -0400 From: Tom Maguire <tom.maguire(a)suscom.net> To: Ian Foster <foster(a)mcs.anl.gov> Cc: Andrew Grimshaw <grimshaw(a)cs.virginia.edu>, ogsa-wg(a)ggf.org Subject: Re: [ogsa-wg] BES query 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/> >>

1 0

RE: [ogsa-wg] BES query
by Andrew Grimshaw 30 Aug '05

30 Aug '05

Tom, As written in the current DRAFT - a WS-Name is an EPR that MUST contain an AbstractName and MAY contain a ResolverEPR. We do not have a "name" at this point for an EPR that has a ResolverEPR only. Andrew -----Original Message----- From: Tom Maguire [mailto:tom.maguire@suscom.net] Sent: Monday, August 29, 2005 9:24 PM To: Ian Foster Cc: Andrew Grimshaw; ogsa-wg(a)ggf.org Subject: Re: [ogsa-wg] BES query 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/> >

1 0

BES query
by Andrew Grimshaw 30 Aug '05

30 Aug '05

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 EPR's 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

3 3