- ogsa-wg - lists.ogf.org

Profile Definition Document V1.3
by David Snelling 22 Dec '04

22 Dec '04

Folks, Here is the latest version of the Profile description document. There is a whole new section added by Tom "Profile Conformance". I accepted this section and many style edits. The document is clean and fairly easy to read. I have left in, or added, comments that people have raised on email. We will need to address these issue on a call sometime. Comments to the list please. -- 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

Re: [ogsa-wg] Profile documents
by Ian Foster 22 Dec '04

22 Dec '04

Dave's comment captures a major concern I have about how the profile notion seems to be evolving. A profile, in the sense of the WS-I profiles that formed at least the starting point for our discussion, documents a way of using well-established and widely used specifications. I believe we have fairly broad consensus for that definition. However, we are now introducing the idea of a "draft" profile that does not need to be grounded in adoption. In so doing, I fear that we abandon the discipline that will allow us to ensure that profiles represent authoritative statements on how to build Grid systems. GGFers will conclude that a profile is a way to respectability. We will start to see many proposals for profiles, many with no connection to implementation experience or adoption, and I don't see how we will be able to say yes to some and no to others, as we will have no clear rules for doing so. Working groups will start to produce their own profiles, as well. We will end up with a set of profiles that look as diffuse and ill defined as the current set of GGF working groups. Of course, some will be "draft" and some "recommended", but I think that distinction will be lost on the community. DAIS for me represents an excellent test case for what a profile should be. It's a nice piece of work and has at least one academic implementation. However, it hasn't seen any adoption by database vendors. That to me means that it doesn't belong in a profile. This is not to say at all that DAIS is not valuable, or that the DAIS team should not be working to get DAIS adopted by vendors. It's simply saying that a profile isn't the way to do it. Ian. At 09:22 AM 12/21/2004 +0000, Dave Berry wrote: >I definitely want to allow the DAIS spec in the first data profile. >This is partly the chicken and egg question; if a spec isn't in an OGSA >profile, people will be less inclined to implement it. This is >particularly applicable to the DAIS spec, because we want people to >implement it as part of their DBMS systems, not as a standalone >executable. (This is to avoid unnecessary copying of data in the >implementations). _______________________________________________________________ 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

3 2

RE: [ogsa-wg] Profile documents
by Dave Berry 21 Dec '04

21 Dec '04

On reading Ian's message, I wonder whether I was clear. I want the criteria for *submitting* a recommendation profile proposal to admit a spec that has a single implementation. This document will have to go through the normal process before it can become an actual recommendation. This is a similar (although stricter) process to any other recommendation document in the GGF and similar standards bodies. So this process should be well-understood in the community. The process will be stricter than the existing GGF process fir recommendation documents, at the existing process doesn't require any implementation to exist before submitting a recommendation, and has fewer criteria for acceptance as a recommendation. WS-I is primarily a reactive body. GGF needs to show leadership: we should steer the development of Grid technology. On occasion we will face the "chicken and egg" problem, in which people are reluctant to adopt a specification because it isn't part of a profile, but we can't make it part of a profile because it isn;t widely adopted. The process by which a submission becomes a full recommendation seems to me an excellent way of resolving this issue. Any profile document will exist in 'draft' form before it is submitted as a 'recommendation', just as any other specification. As I understand the aim of the profile template document, it is precisely to specify that profiles must have links to implementation experience and adoption, and to define the rules for creating them; i.e. it specifically addresses the concerns that Ian raises. I don't see a problem with 'draft' documents; everyone knows that documents go through a draft stage. Unless Ian's reference to 'draft' profiles was referring to "Informational" profiles? One concern of Ian's that isn't addressed by the profile template document is which bodies can produce profiles. The intention, I believe, is that the OGSA profiles have to be produced by the OGSA WG. I agree that we need some central body that controls the production of OGSA profiles. Dave. -----Original Message----- From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: 21 December 2004 13:04 To: Dave Berry; d.snelling(a)fle.fujitsu.com Cc: ogsa-wg Subject: Re: [ogsa-wg] Profile documents Dave's comment captures a major concern I have about how the profile notion seems to be evolving. A profile, in the sense of the WS-I profiles that formed at least the starting point for our discussion, documents a way of using well-established and widely used specifications. I believe we have fairly broad consensus for that definition. However, we are now introducing the idea of a "draft" profile that does not need to be grounded in adoption. In so doing, I fear that we abandon the discipline that will allow us to ensure that profiles represent authoritative statements on how to build Grid systems. GGFers will conclude that a profile is a way to respectability. We will start to see many proposals for profiles, many with no connection to implementation experience or adoption, and I don't see how we will be able to say yes to some and no to others, as we will have no clear rules for doing so. Working groups will start to produce their own profiles, as well. We will end up with a set of profiles that look as diffuse and ill defined as the current set of GGF working groups. Of course, some will be "draft" and some "recommended", but I think that distinction will be lost on the community. DAIS for me represents an excellent test case for what a profile should be. It's a nice piece of work and has at least one academic implementation. However, it hasn't seen any adoption by database vendors. That to me means that it doesn't belong in a profile. This is not to say at all that DAIS is not valuable, or that the DAIS team should not be working to get DAIS adopted by vendors. It's simply saying that a profile isn't the way to do it. Ian. At 09:22 AM 12/21/2004 +0000, Dave Berry wrote: I definitely want to allow the DAIS spec in the first data profile. This is partly the chicken and egg question; if a spec isn't in an OGSA profile, people will be less inclined to implement it. This is particularly applicable to the DAIS spec, because we want people to implement it as part of their DBMS systems, not as a standalone executable. (This is to avoid unnecessary copying of data in the implementations). _______________________________________________________________ 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

Teleconference minutes - Dec. 20, 2004
by Andreas Savva 21 Dec '04

21 Dec '04

Minutes attached. Minutes link: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20041220/en/1 or http://tinyurl.com/5fxfd/minutes-20041220/en/1 Link to reviewed profile template document: http://tinyurl.com/5fxfd/draft-ggf-ogsa-profile-template/en/1 -- Andreas Savva Fujitsu Laboratories Ltd.

2 1

Profile documents
by Dave Berry 21 Dec '04

21 Dec '04

Dave, I was slightly surprised at a couple of points in your proposed document. I'd be curious to understand the thinking behind them. The most surprising was to allow evolving standards as part of a published recommmendation. Doesn't this undermine the idea of a profile as being a stable entity that implementations can build to with confidence that it won't change underneath them? Related to this was the removal of the "stable" term. If I understand the document correctly, an "evolving" spec only has to exist in a standards body; it doesn't necessarily have to be submitted to that body. In GGF terms, it doesn't have to be submitted as a proposed recommendation. Have I got that right? Or are you using "evolving" where previously we used "stable", and "draft" where we previously used "evolving"? I was also surprised that there are no constraints at all on the specs that can be included in an Informational Profile. I guess that makes sense. I was slightly surprised that no-one challenged this, but I suppose most people are interested in the recommendation profiles. I definitely want to allow the DAIS spec in the first data profile. This is partly the chicken and egg question; if a spec isn't in an OGSA profile, people will be less inclined to implement it. This is particularly applicable to the DAIS spec, because we want people to implement it as part of their DBMS systems, not as a standalone executable. (This is to avoid unnecessary copying of data in the implementations). Best wishes, Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0

Happy Holidays
by Hiro Kishimoto 20 Dec '04

20 Dec '04

Word from Mark Linesch, GGF chairman. ---- Hiro Kishimoto -----Original Message----- From: Linesch, Mark Sent: Tuesday, December 21, 2004 2:21 AM Subject: [gfsg] Happy Holidays All, As we move into the final days of 2004, I wanted to thank everyone for their many contributions throughout 2004. Please extend my thanks also to the many workgroup and research group leaders and participants who dedicate their time and effort to our community. I am proud to be associated with so many talented and dedicated individuals. Thanks again for all your efforts this year. Here's hoping 2005 brings you and your loved ones much joy and success. Regards, Mark

1 0

Proposed agenda for Dec. 1st call
by Hiro Kishimoto 20 Dec '04

20 Dec '04

Hi all, The following is a proposed agenda for OGSA-WG telecon on December 1st Wednesday from 5pm to 7pm (CST). The dial-in number for Wednesday. Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://hiro.glance.net Session key: 1201 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 available) Agenda bashing 2) December F2F meeting discussion (30 min) Agenda discussion Any other update 3) Interested party list discussion (30 min) Revised template review. - http://tinyurl.com/5fxfd/OGSA_interested_party_survey - http://tinyurl.com/5fxfd/BusinessGrid_draft List of expected responders by F2F meetings 4) OGSA arch v1 document update (30 min) Continue with review of v1 public comments. Last spreadsheet: https://forge.gridforum.org/projects/ogsa-wg/documen/ogsa-v1-public-comment… 5) OGSA glossary update (10 min) Continue with review of glossary public comments. Last summary: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/10/msg00008.html 5) Wrap up (10 min) AOB Dec. 6th: No tele-con (Ravi is not available) Dec. 8th - 10th is F2F meeting in Washington D.C. <pending issues> ?) Process discussion until December F2F (?) Agenda items Design teams' deliverable and schedule Solicit attendees from related WG/RG/TCs https://forge.gridforum.org/projects/ogsa-wg/document/200412_draft_agenda_o… e/en/1 ?) Roadmap document review (?) > - Ian had some comments on the revised version and it was decided > that it would be better to have him on the call. The version of the roadmap that came out of the Sept 1st call is on gridforge: http://tinyurl.com/5fxfd/draft-ggf-ogsa-roadmap/en/2 ?) GGF12 Action Items () - Andreas will send out shortly ?) Aug F2F meeting Action Item review (?) Action: Heather to send details on the work WSDM is doing on Events. - Ravi and Andrew would like to be involved in this discussion. > Fred will keep an eye on work progress and inform the group > Andreas to send reminder to Heather again > Done Action: Andrew to check with Data team if producing a set of notes each detailing a decision and its rationale (Architecture (AR) notes) would be appropriate to solve the 'communication' problem (what OGSA-WG has discussed and decided) > - Andrew did not receive a positive or negative response so far > - Andrew to talk with people who brought it up; this will likely > not be before GGF12. Action: Frank to ask Ian for an MDS representative to join the Information Services design team > - Frank asked Ian; waiting for reply; will followup. Action: Jay to talk with Ian and Hiro and form a core design team to work on dependencies at architecture level (roadmap). > - Hiro will contact Jay Thanks, ---- Hiro Kishimoto

2 4

FW: [dais-wg] WSRF Embodiments and DAIS
by Dave Berry 18 Dec '04

18 Dec '04

FYI, the DAIS WG has raised the following issues with the OASIS WSRF group. -----Original Message----- From: Susan Malaika [mailto:malaika@us.ibm.com] Sent: 17 December 2004 10:21 To: dais-wg(a)gridforum.org; wsrf(a)lists.oasis-open.org Subject: [dais-wg] WSRF Embodiments and DAIS The Oasis WSRF group asked the GGF DAIS working group to consider the WSRF "WSDL 1.1 Binding Element Embodiment". An item was posted to the DAIS mailing list entitled "DAIS mapping and WSRF embodiments" on 23 November 2004. There has been discussion among the DAIS community on the use of the WSRF embodiments. Some of the DAIS community involved in the discussions are the implementers of the first open source version of DAIS known as OGSA-DAI; they are the first users of DAIS; they are active in promoting DAIS among data grid communities around the world. These are some interim conclusions: 1. Multiple kinds of DAIS Users It is still not clear if DAIS should mandate WSRF because some of the participants in the DAIS group rely on non-WSRF middleware. DAIS could go some way towards satisfying WSRF and non-WSRF users by placing the resource identifier in the DAIS messages (so a single DAIS message format could be used by both WSRF and non-WSRF DAIS users). A note on resource properties: * Resource properties requests cannot include resource identifiers in the message body. The resource identifier must be placed in the header. A suggestion for the WSRF group : * It would be helpful to know if specifying a resource identifier in the DAIS messages as well as in the header is acceptable to the WSRF folk. 2. Multiple resources in a single request (see below for use cases) Currently, each DAIS service request accesses a single resource, and the resource being accessed determines the underlying resources that should be accessed too, e.g., the exposed single resource can perform resource name mappings . In this case, the WS-Resource concept may (or may not) be used to represent the exposed resources in DAIS. (depending on whether DAIS adopts WSRF) In some proposed extensions and applications of DAIS, multiple resources of different types are accessed through a single service request. It is required that the multiple resources be visible to the client. The WS-Resource concept could be used to represent a collection of resources. An identifier to represent the collection could be placed in the header, while the individual resource identifiers in the collection could appear in the message content. A note on resource properties: * Resource properties requests could result in properties for all the resources in the collection being examined. (see below for alternatives for representing the resource properties documents) A suggestion for the WSRF group : * It would be helpful to know if representing a collection of resources as a WS-Resource is a recommended use of WSRF. 3. WSRF "WSDL 1.1 Binding Element Embodiment" If DAIS does adopt WSRF then the "WSDL 1.1 Binding Element Embodiment" is helpful because it permits a client supplied resource identifier to appear in the message header (in other words the resource identifier is not opaque to the client). However note that there are client side prerequisites for the "WSDL 1.1 Binding Element Embodiment", e.g., the client software would have to know to place the resource identifiers in the right place in the header A suggestion for the WSRF group : * It would be helpful to know if there are any tools that support embodiment "WSDL 1.1 Binding Element Embodiment" ................................................................. Use Cases ......... Here are some use cases for multiple resources in a single request: U1. In an interaction with a DAIS service, many resources may be created to represent the results of requests. There may come a time when several of these resources can safely be removed. In such a setting, the options are to: U1.1. Invoke something like "remove() => EPR representing resource" for each of the resources. U1.2 Invoke something like "remove([EPR representing resource-1, ...,EPR representing resource-n]) => EPR representing service" once. How would option U1.2 be modeled through WSRF? U2. In an interaction with a DAIS service, it may be necessary to aggregate multiple results sets and return the combined result set via ftp. In such a setting, the options are to: U2.1 Invoke something like "ftp (..) => EPR for resource1" for each of the resources and then aggregate the results on the client U2.2 Invoke something like : - "aggregate ([EPR representing resource-1, ...,EPR representing resource-n]) => EPR representing service" - "ftp (..) => EPR representing aggregated resource" (the result aggregation would be done at the server.) How would option U2.2 be modeled through WSRF? (BTW it is possible that a combined aggregate and ftp operation would be desirable) U3. In an interaction with a DAIS service, it may be necessary to issue a query over multiple databases and files. In such a setting, the options are to: U3.1 Invoke something like "query (..) => EPR for resource1" for each of the resources, returning each query result to the client, and then aggregate the results on the client (the result aggregation process could be very complex.) U3.2 Invoke something like "copy (..) => EPR for resource1" for each of the resources and then issue the queries locally on the client (this means having a query engine on the client.) U3.3 Invoke something like "query([EPR representing resource-1, ...,EPR representing resource-n]) => EPR representing service" once (the query result aggregation would be done at the server.) How would option U3.3 be modeled through WSRF? Alternatives for modeling resource properties documents for U1.2, U2.2, U3.3 ........................................................................ ..... <ResourceNames> <ResourceName>resource1</> <ResourceName>resourceX</> </> Or as complex as <Resources> <Resource> <ResourceName>resource1</> <ResourceType>RDB</> <ResourceSchema>....</> </> <Resource> ... </> </> A suggestion for the WSRF group : It would be helpful to know which modeling approach is preferred Thanks to everyone who contributed and reviewed this note. Happy Happy Holiday Season :-) Susan Malaika

1 0

Teleconference minutes - Dec. 15, 2004
by Andreas Savva 16 Dec '04

16 Dec '04

Minutes attached. Gridforge link: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20041215/en/1 or http://tinyurl.com/5fxfd/minutes-20041215/en/1 -- Andreas Savva Fujitsu Laboratories Ltd.

1 1

Data: date of next telcon
by Dave Berry 13 Dec '04

13 Dec '04

Dear all, I won't be available for the usual telcon slot this week. I doubt we will want to meet during (what is for most of us) the holiday season, so the next telcon will be on Wednesday January 5th. This will be at the usual time: 8.00am (PST) / 11.00am EST / 4.00pm (GMT) / 5.00 pm (CET). UK Dial In: 0845 245 0224 US Dial In: 18668380046 International Dial In: +44 1452 542309 PIN: 632065 (Reference Number: 2361592) Our main need is to progress the straw man architecture. I am setting aside some days in January to work on this. If anyone can progress parts of the straw man before then, the rest of us would be very grateful. Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

1 0