June 2005 - ogsa-wg - lists.ogf.org

RE: [ogsa-wg] Minor comments on documents
by Treadwell, Jem 23 Jun '05

23 Jun '05

Hi Abdeslem, my first thought was that that's too low level, but we do mention design teams elsewhere in the doc, so I've added it to both of these bullets. Thanks, - Jem > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Djaoui, A (Abdeslem) > Sent: Wednesday, June 22, 2005 11:20 AM > To: Treadwell, Jem; Hiro Kishimoto; Steven Newhouse; Tom Maguire > Cc: ogsa-wg > Subject: RE: [ogsa-wg] Minor comments on documents > > Jem > > After your sentence > > Service Description documents, which are written and > maintained by the > > appropriate domain-expert working groups, > > Should you add "or design teams" at the end. I am raising > this because for informations services there is no plan to form a WG. > > Abdeslem > > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org]On > Behalf Of Treadwell, Jem > Sent: Wednesday, June 22, 2005 3:21 PM > To: Hiro Kishimoto; Steven Newhouse; Tom Maguire > Cc: ogsa-wg > Subject: RE: [ogsa-wg] Minor comments on documents > > > Hiro/Steve/Tom, > > My comments also embedded... > > > -----Original Message----- > > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] > On Behalf > > Of Hiro Kishimoto > > Sent: Wednesday, June 22, 2005 9:29 AM > > To: Steven Newhouse > > Cc: ogsa-wg > > Subject: Re: [ogsa-wg] Minor comments on documents > > > > Thanks Steven, > > > > My comments inline <HK>. > > ---- > > Hiro Kishimoto > > > > Steven Newhouse wrote: > > > OGSA WSRF Basic Profile 1.0 (v018 June 13th 2005) > > > > > > Page 1: Status of this memo > > > Is there not a WSRF missing from this opening line? > > > e.g. '... write normative OGSA services based around the > > WSRF set of > > > specifications.' > > > > <HK> > > Good catch! Your text works for me. > > </HK> > > JT: I'll leave this one for Tom, as he has the pen again right now. > > > > > > OGSA Roadmap (v010 June 6th 2005) > > > > > > Section 2, Point 1, Bullet 3: Should these service description > > > documents not be 'owned' by the working group developing > > the service? > > > The text implies to me that the OGSA-WG writes them... > > which I don't > > > think is the case. > > > > <HK> > > Good point. Let's add something like "domain-expert WG writes this > > service description (scenario document) if appropriate." > > </HK> > > JT: Here's my update, in line (I think!) with Hiro's suggestion: > > * Service Description documents, which are written and > maintained by the appropriate domain-expert working groups, > describe the services in the area in natural language, > listing the interfaces and operations defined by each service. > > * Scenario documents, also written by domain-expert working > groups, demonstrate how these services can implement the use > cases, using a combination of natural language and UML. > > > > Section 2.2: > > > Should there not be some statement that OGSA profiles should be > > > developed/revised outside the OGSA-WG in theor own WG? > > > > <HK> > > I think they can if their Profile abide by OGSA branding guideline. > > </HK> > > JT: I inserted this text at what is now line 199, *before* > the para beginning "Members of the OGSA-WG": > > OGSA Recommended and Informational Profiles may be developed > either by the OGSA-WG or by domain-expert working groups, but > it is important to note that they must adhere to GGF's > forthcoming OGSA branding guidelines, which are discussed in > section 2.3. > > Let me know if you see any issues with this, as I'll be > posting this for final call very soon. > > Thanks! > > - Jem > >

3 2

RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30
by Dave Berry 22 Jun '05

22 Jun '05

Marty, The reason I asked about the status of the specifications was to clarify what sort of profile document could be produced at the present time. OGSA profiles are governed by a set of rules (https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-pr ofile-definition/en/12). Currently, if a group were to publish a profile document, it would have to be an Informational Profile. It could not be a Recommended Profile because the specifications are not yet in a standards body. Of course, this does not preclude people working on a draft profile with the intent of moving it into the publication process at some later date. I suggest that a question for the BOF to discuss is, given the above process, at what point does it become worth spending time on a draft profile? (I am not presuming an answer to this question one way or another). Switching to the question of WS-Enumeration, your answer seems to validate my initial concern. The issue that WS-Enumeration attempts to address is real and is considered in part by various working groups in the data area, but to me it doesn't seem part of a basic profile. Of course, the fact that I haven't seen a technical reason that links WS-Enumeration closely to the other specs doesn't mean that such a reason doesn't exist! Dave. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Marty Humphrey Sent: 22 June 2005 12:45 To: 'Ogsa-Wg' Subject: RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30 > 1. Please could you clarify the status of WS-Transfer, WS-Eventing > and WS-Enumeration in the terms of the OGSA Profile template? I.e. > have they been submitted to an SDO, are they draft or evolving, etc.? As you know, there is a 4-step process by which these specs will become standards: [1] "Develop", in which the spec is published; [2] "Broader Participation", in which there are feedback and interop workshops (resulting in possibly revising and republishing the specs); [3] "Standardization", in which the specs are submitted to a standardization body, which then can modify the spec as well and eventually ratify; [4] "Profiles", in which a separate document shows how to *combine* specs, generally resulting in a "subsetting" of the original specs. On Dec 1, 2004, Intel hosted a "feedback" workshop (step [2]), above, for WS-Enumeration and WS-Transfer. The companies attending the workshop included AMD, Computer Associates, Dell, HP, IBM, Intel, Microsoft, SAP, Sharp, Sonic, Sun, veritas, et. al. Although I can't entirely confirm this, it looks like the following companies brought implementations of WS-Enumeration/WS-Transfer to this workshop: Microsoft, Dell, Intel, NetIQ, Sun, and WebMethods. On Feb 19, 2004, Tibco hosted a "feedback" workshop for WS-Eventing. Attendees included Microsoft, BEA, IBM, NEC, Sonic, etc. On April 15, 2004, Microsoft hosted an "interop" workshop on WS-Eventing ("The outcome of the workshop was the demonstration of interoperability among all the 7 implementations." The seven implementations were from BEA, Canon, Epson, Microsoft, Ricoh, Sonic, and Systinet.) It looks like there will be another WS-Eventing workshop, although the date/time have not been announced. The most recent specs are: -- WS-Eventing: Aug 2004 (Authors: IBM, BEA, Computer Associates, Microsoft, Sun, and Tibco). This new version modifies the original version (Jan 2004, I believe) to reflect the workshops. -- WS-Enumeration: Sept 2004 (Authors: Systinet, Microsoft, Sonic, BEA, Computer Associates). This is the first version of the spec. -- WS-Transfer: Sept 2004 (Authors: Systinet, Microsoft, Sonic, BEA, Computer Associates). This is the first version of the spec. There's an interesting graphic that shows some of the progress from Microsoft's perspective here: http://msdn.microsoft.com/webservices/graphics/workshop-timeline.gif (this is taken from http://msdn.microsoft.com/webservices/community/workshops/default.aspx) > 2. I can see that WS-Transfer specifies some of the functionality of > WSRF and WS-Eventing is largely equivalent to WS-BaseNotification, but > what has WS-Enumeration to do with this? From a brief reading, it > seems to specify functionality that is independent of either stack. I can see this point -- in our initial designs and experimentation with WS-Transfer and WS-Eventing, we chose to not utilize WS-Enumeration. But we are increasingly considering WS-Enumeration as an important part of the story. >From Felipe Cabrera of Microsoft: "Many scenarios require data exchange using more than just a single request/response message pair. Types of applications that require these longer data exchanges include database queries, data streaming, the traversal of information such as namespaces, and enumerating lists. Enumeration, in particular, is achieved through establishing a session between the data source and the requestor. This session is established using the Enumerate operation, which provides an enumeration context that is then used in subsequent operations. Successive messages within the session transport the collection of elements being retrieved. No assumptions are made on the approach used by the service to organize the items that will be produced. What is expected is that under normal processing circumstances, the enumeration will produce all the underlying data before the end of the session.... In its simplest form, WS-Enumeration defines a single operation, Pull, which allows a data source, in the context of a specific enumeration, to produce a sequence of XML elements in the body of a SOAP message.... Three more request/response operations are defined in WS-Enumeration: Renew, GetStatus, and Release.... State information regarding the progress of the iteration can be maintained between requests by either the data source or the consuming service.... In addition to enumerating the data entities present in a Web service, it is convenient to be able to perform several basic operations on them. These operations are introduced in the WS-Transfer operation." I hope this helps, Marty Marty Humphrey Assistant Professor Department of Computer Science University of Virginia

2 1

RE: [ogsa-wg] call tonight
by Treadwell, Jem 22 Jun '05

22 Jun '05

FYI that I've picked up the pen again on the Definition doc, just in case anyone else is thinking about it - I'm addressing Hiro's comments. We can review it tonight. Tom, if you guys are getting the same weather we are I hope it's inside :0) - Jem > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of Tom Maguire > Sent: Wednesday, June 22, 2005 4:59 PM > To: 'Ogsa-Wg' > Subject: [ogsa-wg] call tonight > > Folks, > > Apologize. When I suggested Wednesday for BP discussion I > had forgotten that my son's graduation is this evening. > > Tom > > BP 1.0 v020 is on GridForge > > > 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

call tonight
by Tom Maguire 22 Jun '05

22 Jun '05

Folks, Apologize. When I suggested Wednesday for BP discussion I had forgotten that my son's graduation is this evening. Tom BP 1.0 v020 is on GridForge 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

Final call for OGSA Roadmap v1.0
by Treadwell, Jem 22 Jun '05

22 Jun '05

Hi, v14 of the OGSA Roadmap has been uploaded to http://tinyurl.com/9ssa9. I plan to submit the document to the GGF Editor this Friday, June 24th, so the deadline for comments is either midnight Thursday June 24th, in whatever timezone you happen to be in, or 8am US/Eastern in absolute time. Any comments received after that will be assigned to a tracker, and addressed during the public comment period. Thanks to all who have commented and contributed - the level of detail we've been working at today tells me we must have nailed all the big issues pretty well :0) - 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

RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30
by Djaoui, A (Abdeslem) 22 Jun '05

22 Jun '05

Hi For me the main issues to address are: A) Do we start from the web services design principle of COMPOSABILITY of specifications and profiles? B) If the answer is YES then how are we going to make sure that varoius new GGF profiles and specifications are indeed composable with each other. Once we have composable profiles it really doesn't matter how many profiles we have. You can use one them or all of them, it is less tidy than having one basic profile but its workable. If we throw away the design principle of composability, then I am afraid it is back to pre-OGSA pre-Web services era. Abdeslem -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org]On Behalf Of Subramaniam, Ravi Sent: Wednesday, June 22, 2005 6:29 AM To: Ian Foster; Marty Humphrey; Ogsa-Wg Subject: RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30 Hi Marty, The BOF and the motivations you describe sound like a good idea. It would be great to hear your perspectives especially since you have experience with the described specs (WS-RF/WSN and WS-T, WS-E, WS-Enum). I think this is also a good test for the general policy that OGSA has adopted of admitting different profiles that are consistent with the general architecture. There has been a discussion around "lack of interoperability" with multiple profiles but without visiting the profiles that are compatible with the architecture one cannot decide which is the most appropriate (from one or many of the criteria like implementation easy, expressiveness, composability etc). Prematurely deciding that only one profile is the right way to go may not be beneficial in the long run. Given the way the industry has evolved, there is a process of "natural selection" and the most sophisticated or theoretical best solution has not won out in most cases. I agree with Mark's observations. Theoretically the degrees of freedom in the number of profiles seem infinite but I don't think in reality it will pan out into the more than a few since the "affinity" of these specs to be in a profile would constrain the number. Having said this, it would still make sense to be concrete in your discussion of what would be the primary motivation of the BOF and subsequent WG. Your points in response to Ian's question could be added to the formal description of the intent of the BOF. Thanks for spawning this discussion. Ravi PS: I just read Fred's comments in this thread. I think his points make sense. You may want to state that the need for alternate profiles as a primary assumption (not to be debated) and move on to the salient aspects of what the alternate profiles to be debated in the BOF are. _____ From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Ian Foster Sent: Tuesday, June 21, 2005 7:43 AM To: Marty Humphrey; 'Ogsa-Wg' Subject: RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30 Marty: Thanks, that makes a lot of sense. And Mark puts it nicely: poetically, even (-: Ian. At 10:28 AM 6/21/2005 -0400, Marty Humphrey wrote: Hi Ian et. al., A very good question! ("can you define the goals of the BOF more precisely other than "not WSRF"?) I sent this email in part to hear from the community how "broad" they might like it to be. That is, we're being flexible. If someone wants to talk about one of these specific topics, we will certainly try our best to accommodate. Note that by default I believe the discussions will center around WS-Transfer, WS-Enumeration, WS-Eventing, et. al. I will talk about my team's use of WS-Transfer, WS-Enumeration, and WS-Eventing. I think we're in a very good position to discuss the pros and cons of these specs as compared with WSRF (as our project has implemented/used both). Let me answer the question in a different way. GGF Chair Mark Linesch said recently: "Our approach with the OGSA architecture along with our collaborative work on OGSA profiles is to: (1) describe 'the most traveled paths through the forest' rather than to dictate that there is only one path; and (2) to continue to highlight that multiple, overlapping paths may not be in the interests of the industry over time" ( http://news.taborcommunications.com/msgget.jsp?mid=403500 <http://news.taborcommunications.com/msgget.jsp?mid=403500&xsl=story.xsl> &xsl=story.xsl) Simply, we believe that there has been sufficient "hallway discussions" on BOTH (1) and (2) that it makes good sense to gather people to discuss BOTH of these topics in a realistic and productive way. - Marty Marty Humphrey Assistant Professor Department of Computer Science University of Virginia ________________________________________ From: Ian Foster [ mailto:foster@mcs.anl.gov] Sent: Tuesday, June 21, 2005 9:54 AM To: Marty Humphrey; 'Ogsa-Wg' Cc: 'Marty Humphrey' Subject: Re: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30 Marty, Steven: It is of course feasible, in principle, to define many different profiles for OGSA. E.g., one could build one on WS-Transfer and friends, one could build one that uses a different construct than the WS-Addressing EPR to address things, one could define one that uses JINI mechanisms, one could define one that uses CORBA, one could define one that renames all of the current WSRF and WS-Notification calls to be slightly different (oh wait, that's the first in the list (-: ), etc. Given the wide variety of possible alternative profiles, it would be helpful for those like me who are considering attending the BOF to know what more specifically what the goal of this work is going to be. The name doesn't provide any information, other than to imply, perhaps, that the interfaces on which the WSRF profile builds are not in some manner "minimal" and/or "simple." I.e., can you define the goals of the BOF more precisely other than "not WSRF"? Regards -- Ian. At 09:11 AM 6/21/2005 -0400, Marty Humphrey wrote: Folks, There have been a number of informal conversations lately about the feasibility/value/implications of a possible non-WSRF-based profile for OGSA. To bring all interested parties together at the same time, a BOF has been scheduled for Tuesday June 28 noon-1:30 (unfortunately at the same time as the EGA session, but there were no good times available). The agenda is still being finalized, but we expect to broadly discuss the pros/cons of such an effort, and, if the BOF attendees decide that such an effort would be valuable, produce a concrete plan for the formation of a Working Group. Here is the information that Steven Newhouse provided for the GGF organizers: "A BOF meeting to discuss the creation of a WG to define an OGSA Basic Profile that builds upon a minimal set of simple web services. The output of the group would be a document, similar in nature to the OGSA WSRF Basic Profile that would allow OGSA services to be rendered using an alternative set of WS specifications." I hope you can attend this (hopefully) productive and constructive session! -- Marty and Steven Marty Humphrey Assistant Professor Department of Computer Science University of Virginia _______________________________________________________________ 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/>

3 3

RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30
by Djaoui, A (Abdeslem) 22 Jun '05

22 Jun '05

Please see inlined comments <AD/>. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org]On Behalf Of Marty Humphrey Sent: Wednesday, June 22, 2005 4:57 PM To: 'Ogsa-Wg' Subject: RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30 I want to clarify this ... Yes, composability is certainly important, both with regard to the specifications/standards as well as the profiles. With regard to composability of *profiles*, everyone agrees that WS-I BP 1.1 supports composability, and WS-I "Simple SOAP Binding Profile 1.0" and WS-I "Attachments Profile 1.0" support composability, but no one would attempt to layer WS-I "Simple SOAP Binding Profile 1.0" onto WS-I "Attachments Profile 1.0" (or the other way around). So they're not "composable" in this sense. <AD> Yes I agree the change from BP 1.0 to 1.1 was partly driven by a need to allow COMPOSITION of RELEVANT profiles. For the the example 3 profiles above: If your web service is not using attachement you would compose BP 1.1 with SSBP1.0, if it is using attachements you will need to compose BP1.1 and AP1.0. These can be seen as different bindings. >From a user point of view these are the only meaningful compositions (you either want to use SOAP with attachement or without.). When there is a tight coupling between profiles, the profile document itself should state how it is intended to be used or composed with other profiles. If other binding protocols become available (MTOM for example) you would need BP1.1 with MTOM 1.0 or whatever. But of course you web service could support many bindings .... But I take your point that some compositions might not make sense. </AD> I see an analogous situation for some (all?) "OGSA Profiles" -- particularly the WSRF Profile and any potential profile coming out of this BOF. <AD> If by analogous situation you mean non composable, I disagree. A more sensible approach would be to allow all OGSA basic profiles to be implemented together, (although higher related profiles will only compose with their corresponding profile). This is starightforward when the profiles rely on different specifications. When they refer the same specification, care should be taken not to have contradictory statements that lead to non-composability problems. </AD> Note that you might say that a WSRF profile could layer on a "WS-I OGSA Profile", but then I would question the very existence/purpose of this "WS-I OGSA Profile" (as it would seem to add no functionality above WS-I Basic Profile 1.1 and WS-I Basic Security Profile 1.0). <AD> Yes I agree. I was thinking more along the lines of a new profile based on WS-Transfer and WS-Eventing. The new profile and WSRF profile should be made to live happily together. So people will have the choice of two OGSA stacks. But there shouldn't be anything stopping them from implementing both stacks. Abdeslem </AD> -- Marty Marty Humphrey Assistant Professor Department of Computer Science University of Virginia > -----Original Message----- > From: Tom Maguire [mailto:tmaguire@us.ibm.com] > Sent: Wednesday, June 22, 2005 8:01 AM > To: Djaoui, A (Abdeslem) > Cc: Ian Foster; Marty Humphrey; Ogsa-Wg; owner-ogsa-wg(a)ggf.org; > Subramaniam, Ravi > Subject: RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30 > > +1 to the composabiltiy aspect. Certainly you should be able to compose > any number of profiles together. Each one with their > own comformance claim. > > Tom > > 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 > > > > "Djaoui, A > (Abdeslem)" > <A.Djaoui(a)rl.ac.u To > k> "Subramaniam, Ravi" > Sent by: <ravi.subramaniam(a)intel.com>, "Ian > owner-ogsa-wg@ggf Foster" <foster(a)mcs.anl.gov>, > .org "Marty Humphrey" > <humphrey(a)cs.virginia.edu>, > "Ogsa-Wg" <ogsa-wg(a)gridforum.org> > 06/22/2005 06:36 cc > AM > Subject > RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 > on Tues June 28, noon-1:30 > > > > > > > > > > > Hi > > For me the main issues to address are: > A) Do we start from the web services design principle of COMPOSABILITY of > specifications and profiles? > B) If the answer is YES then how are we going to make sure that varoius > new > GGF profiles and specifications are indeed composable with each other. > Once we have composable profiles it really doesn't matter how many > profiles > we have. You can use one them or all of them, it is less tidy than having > one basic profile but its workable. > If we throw away the design principle of composability, then I am afraid > it > is back to pre-OGSA pre-Web services era. > > > Abdeslem > > > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org]On Behalf > Of Subramaniam, Ravi > Sent: Wednesday, June 22, 2005 6:29 AM > To: Ian Foster; Marty Humphrey; Ogsa-Wg > Subject: RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, > noon-1:30 > > Hi Marty, > > The BOF and the motivations you describe sound like a good idea. It > would be great to hear your perspectives especially since you have > experience with the described specs (WS-RF/WSN and WS-T, WS-E, > WS-Enum). I think this is also a good test for the general policy > that OGSA has adopted of admitting different profiles that are > consistent with the general architecture. > > There has been a discussion around "lack of interoperability" with > multiple profiles but without visiting the profiles that are > compatible with the architecture one cannot decide which is the most > appropriate (from one or many of the criteria like implementation > easy, expressiveness, composability etc). Prematurely deciding that > only one profile is the right way to go may not be beneficial in the > long run. Given the way the industry has evolved, there is a process > of "natural selection" and the most sophisticated or theoretical > best > solution has not won out in most cases. I agree with Mark's > observations. Theoretically the degrees of freedom in the number of > profiles seem infinite but I don't think in reality it will pan out > into the more than a few since the "affinity" of these specs to be > in > a profile would constrain the number. > > Having said this, it would still make sense to be concrete in your > discussion of what would be the primary motivation of the BOF and > subsequent WG. Your points in response to Ian's question could be > added to the formal description of the intent of the BOF. > > Thanks for spawning this discussion. > > Ravi > > PS: I just read Fred's comments in this thread. I think his points > make sense. You may want to state that the need for alternate > profiles as a primary assumption (not to be debated) and move on to > the salient aspects of what the alternate profiles to be debated in > the BOF are. > > > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf > Of Ian Foster > Sent: Tuesday, June 21, 2005 7:43 AM > To: Marty Humphrey; 'Ogsa-Wg' > Subject: RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, > noon-1:30 > > Marty: > > Thanks, that makes a lot of sense. And Mark puts it nicely: > poetically, even (-: > > Ian. > > At 10:28 AM 6/21/2005 -0400, Marty Humphrey wrote: > > Hi Ian et. al., > > A very good question! ("can you define the goals of the BOF more > precisely > other than "not WSRF"?) I sent this email in part to hear from the > community > how "broad" they might like it to be. That is, we're being flexible. > If > someone wants to talk about one of these specific topics, we will > certainly > try our best to accommodate. > > Note that by default I believe the discussions will center around > WS-Transfer, WS-Enumeration, WS-Eventing, et. al. I will talk about > my > team's use of WS-Transfer, WS-Enumeration, and WS-Eventing. I think > we're in > a very good position to discuss the pros and cons of these specs as > compared > with WSRF (as our project has implemented/used both). > > Let me answer the question in a different way. GGF Chair Mark > Linesch > said > recently: "Our approach with the OGSA architecture along with our > collaborative work on OGSA profiles is to: (1) describe 'the most > traveled > paths through the forest' rather than to dictate that there is only > one > path; and (2) to continue to highlight that multiple, overlapping > paths may > not be in the interests of the industry over time" > ( > > http://news.taborcommunications.com/msgget.jsp?mid=403500&xsl=story.xsl > ) > Simply, we believe that there has been sufficient "hallway > discussions" on > BOTH (1) and (2) that it makes good sense to gather people to > discuss > BOTH > of these topics in a realistic and productive way. > > - Marty > > Marty Humphrey > Assistant Professor > Department of Computer Science > University of Virginia > > > ________________________________________ > From: Ian Foster [mailto:foster@mcs.anl.gov] > Sent: Tuesday, June 21, 2005 9:54 AM > To: Marty Humphrey; 'Ogsa-Wg' > Cc: 'Marty Humphrey' > Subject: Re: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, > noon-1:30 > > Marty, Steven: > > It is of course feasible, in principle, to define many different > profiles > for OGSA. E.g., one could build one on WS-Transfer and friends, one > could > build one that uses a different construct than the WS-Addressing EPR > to > address things, one could define one that uses JINI mechanisms, one > could > define one that uses CORBA, one could define one that renames all of > the > current WSRF and WS-Notification calls to be slightly different (oh > wait, > that's the first in the list (-: ), etc. > > Given the wide variety of possible alternative profiles, it would be > helpful > for those like me who are considering attending the BOF to know what > more > specifically what the goal of this work is going to be. The name > doesn't > provide any information, other than to imply, perhaps, that the > interfaces > on which the WSRF profile builds are not in some manner "minimal" > and/or > "simple." I.e., can you define the goals of the BOF more precisely > other > than "not WSRF"? > > Regards -- Ian. > > At 09:11 AM 6/21/2005 -0400, Marty Humphrey wrote: > > Folks, > > There have been a number of informal conversations lately about the > feasibility/value/implications of a possible non-WSRF-based profile > for > OGSA. > > To bring all interested parties together at the same time, a BOF has > been > scheduled for Tuesday June 28 noon-1:30 (unfortunately at the same > time as > the EGA session, but there were no good times available). The agenda > is > still being finalized, but we expect to broadly discuss the > pros/cons > of > such an effort, and, if the BOF attendees decide that such an effort > would > be valuable, produce a concrete plan for the formation of a Working > Group. > > Here is the information that Steven Newhouse provided for the GGF > organizers: > > "A BOF meeting to discuss the creation of a WG to define an OGSA > Basic > Profile that builds upon a minimal set of simple web services. The > output of > the group would be a document, similar in nature to the OGSA WSRF > Basic > Profile that would allow OGSA services to be rendered using an > alternative > set of WS specifications." > > I hope you can attend this (hopefully) productive and constructive > session! > > -- Marty and Steven > > Marty Humphrey > Assistant Professor > Department of Computer Science > University of Virginia > _______________________________________________________________ > 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 >

1 0

RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30
by Fred Maciel 22 Jun '05

22 Jun '05

Hi all, > A very good question! ("can you define the goals of the BOF > more precisely other than "not WSRF"?) I sent this email in part to hear > from the community > how "broad" they might like it to be. That is, we're being > flexible. If someone wants to talk about one of these specific topics, we > will certainly try our best to accommodate. I think that different people will see this from different angles, and if we don't understand the different "problems" involved the BOF can get messy. So let me try to decompose the problem, hoping that it will help the steering of the BOF. (1) Are multiple base profiles OK to begin with? > Let me answer the question in a different way. GGF Chair Mark > Linesch said [...] Yes, but some of us (I included) think that multiple base profiles is a bad idea, no matter what Mark Linesch said. Suffices to say that this is a religious discussion, in which all sides have strong opinions beforehand, spend a long time in a heated discussion, but nobody is be able to change anybody else's opinion. The ones we had in the OGSA-WG weren't fun. Try to steer the discusion past that one (or around it), so that we can get to the next problem: (2) How do the protocols sets in this area (the WSRF+WSN set, and the WS-Transfer etc. set) compare to each other? That one should be an interesting one, especially to end FUD. I'm looking forward to what you have to say. That should give the background to: (3) What are the plans for the "WS-I-only" profile? > Here is the information that Steven Newhouse provided for the GGF > organizers: > > "A BOF meeting to discuss the creation of a WG to define an OGSA Basic > Profile that builds upon a minimal set of simple web services. The output of This seems to be the main subject of the BOF, right? As you said, you are being flexible, and you have an interest in (2), but if we don't take care we won't even get to (3) in 1 1/2 hour. Anything else? Regards, Fred Maciel Hitachi America R&D

4 4

ByteIO WG Status
by Mark Morgan 22 Jun '05

22 Jun '05

Hiro asked me to send out a short, 5 line status report for ByteIO. We are currently in the process of finishing the first draft, skeleton versions of both the recommendation document for ByteIO and for the Use Case Document. Our hope was to have these out before GGF but that isn't likely to quite happen. Instead, the documents will probably come out within a few weeks of GGF. In the mean time, discussions on the telecoms have lead us to adopt a dual interface model for byteio -- one supporting random block oriented access, and another for more stream like resources (i.e., with session state). These interfaces have in part been implemented in prototypes as proofs of concept. GGF will probably entail looking at these along with the use cases. -Mark -- Mark Morgan Research Scientist Department of Computer Science University of Virginia http://www.cs.virginia.edu mmm2a(a)virginia.edu (434) 982-2047

1 0

Teleconference minutes - 20 June 2005
by Andreas Savva 22 Jun '05

22 Jun '05

Minutes attached. Also https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050620/en/1 -- Andreas Savva OGSA Teleconference - 20 June 2005 ================================== * Participants Mike Behrens (R2AD, LLC) Francisco Vilar Brasileiro (UFCG) William Huey Hiro Kishimoto (Fujitsu) Takashi Kojo (NEC) Fred Maciel (Hitachi) Tom Maguire (IBM) Dejan Milojicic (HP) Andreas Savva (Fujitsu) Stuart Schaefer (Softricity) Ayla Debora Dantas de Souza (UFCG) Ravi Subramaniam (Intel) Jun Tatemura (NEC) Pete Ziu (Northrop Grumman) Apologies: Jay Unger, Andrew Grimshaw Minutes: Andreas Savva * CDDLM review The purpose of this preview is to prepare for the scheduled joint session at GGF14. CDDLM: Configuration Description, Deployment, and Lifecycle Management [Presentation available at https://forge.gridforum.org/projects/ogsa-wg/document/cddlm-ogsa-intro/en/1 ] This WG was seeded from work done for the SmartFrog research project. But there have been substantial contributions from other sources, namely Softricity, and NEC. The schedule has been aggressive. It has helped that the core number of members is small. There is a WSDM relation especially towards the end. CDDLM uses WSDM. There is also a relation with CIM. But CDDLM does not use CIM at the moment. (A joint session is planned to explore possibilities further.) The WG has two documents towards the end of the GGF publication pipeline: CDDLM Foundation and SmartFrog. There is also another document recently submitted: Configuration Description Language (XML spec.) Also the WG is doing a last call within the WG on two other documents: Deployment API and Component model. These documents conclude the work the WG set out for itself. CDDLM-WG has kept a low profile with respect to OGSA. Mostly due to the tight internal schedule but also because OGSA has been in flux. There is an understanding that the CDDLM-WG might have to revisit the first versions of its specifications and revise them; after getting implementation experience and to make them fit in OGSA better. There are three in-house reference implementations planned by HP, Softricity, NEC. Also an outside one (UFCG). CDDLM work uses WSDM. There have been a number of problems because of this decision but in general the group is happy with this choice. There is also thinking about doing an interop, picking up on the WSDM interop and adding own scenarios. CDDLM-WG would like to place itself on the OGSA Roadmap and also would like to know how it fits in the bigger OGSA picture. And what it might have to revise later to fit better in the architecture. There is also a relation with OASIS SDD TC and GGF ACS-WG. There might be a need to refactor the CDDLM specifications to fit better with the work planned by these groups. - Is CDDLM compliant with the WSDM specification? - The interfaces are based on the WSDM OASIS Standard. - WS-Addressing and WSRF are used. - The main problem has been the moving target that all these specs pose. Also the mismatch in the version of WS-Addressing specs that WSDM used (3 different versions) - Which parts of WSRF / WSN are used? - Get resource property, Query resource property - Base Notification - Resource lifetime - Joint sessions at GGF14 - CDDLM is most closely related to EMS. - BES assumes the container is already setup. But OGSA has not specified how that is done yet. So there is a clear point for CDDLM to plugin. In any case this is a good point to start the discussion. - Therefore the most appropriate OGSA sessions are sessions #4 (EMS Architecture, 6/28) and session #9 - Since few people in OGSA-WG are familiar with the CDDLM work a high level presentation and then drilling down would be a good way to start. - These sessions would be a good opportunity to start discussing the position of CDDLM in OGSA. - CDDLM-WG also has demos that they can show OGSA-WG - Also OGSA is planning a number of joint sessions with WSDM. This would be a good time for CDDLM-WG to ask questions or put forward requests to WSDM. (Especially since WSDM has a F2F planned for the next day.) - How is CDDLM planning to proceed? - Working in GGF has had a number of advantages. Keeping the number of participants small has allowed more progress in a short time. It is likely that some work will continue in GGF CDDLM-WG but might also refine or posibly move some work to other places. - Have to work out the CIM relation as well as relation to other groups. * GGF14 agenda review - Security session moved to 6/29; using the early bird session slot. - Noone on the call plans to join the GGF14 sessions by phone. Hiro will also ask on the list and if there is no interest he will *not* setup a bridge. - [2pm 6/29] WSDM Demo (perhaps on a blackberry or simulator) - There are many conflicts this time. But OGSA-WG cannot complain since it is using 12 sessions in total. - BES contact? Talk to Darren Pulsipher or Steve Newhouse; Andrew is on vacation. * Roadmap document review - Jem has made a number of changes based on feedback he received; including but not limited to Hiro's and Dave B's comments. - l.495: "CGS:" mention probably points to SRIM work. But CGS is no longer active and has handed that work over to DAIS. > Changed CGS to DAIS - l.465-470: Sentence deleted as unnecessary. - l.560-565: SCRM-WG will be formed this week. Also expect WS-Naming-WG to be approved. - l.394: needs revision (Jem to do and check with Mark) - Table 4.4: GWD-R-P is wrong. It should be GWD-R. Action: Andreas to send Jem the link to the document that defines the various document types (GFD.1) (done) Action: Andreas to send Jem the JSDL 1.0 link. (done) - Information and monitoring architecture section does not have any dates. (Only TBD). But there will not be discussion about this before GGF14. Agreed to leave it as is. - Is there a WS-addressing 1.0 implementation? - Amazon was mentioned as one company doing one. - IBM is doing an implementation. Also there is an Apache project doing an implementation. Action: Tom will check whether there is a public version of the BaseNotification 1.3 - BaseNotification 1.3 is draft and evolving - BaseNotification 1.2 is draft and not evolving - Reviewed all entries in the master spreadsheet, corrected them and added comments. Action: Jem will work out the last remaining details. He will then post a cleaned up copy to gridforge, announce a final call (within 1-2 days) and then submit to the GGF Editor. - Submit to the Editor deadline is Friday - Final call deadline is Thursday - Post cleaned up copy deadline is Tuesday or Wednesday latest. * Profile definition review - Andreas confirmed with Dave S and uploaded draft 11. - Accepted draft 10 changes; only new modifications show. These were reviewed last week and re-checked today. - Agreed that the Table does not have to be identical to the ones in the Roadmap or Profiles. It is enough to be reasonably close. Action: Jem will fix the table formatting, do an overall review and upload a new version. - There will be another review of this document on Wednesday * WSRF Basic Profile 1.0 review - The big change is in Appendix C. - Appendix A has also been updated - Appendix B: the extensibility points have been updated - Left the reference to BaseNotification to 1.2 - But will update to show changes to 1.3 - l.450: cleanup - l.395: Latha posted a comment about confusion around MUST/SHOULD usage. (The intention is not to encourage the use of UseNotify. But this will change again with the update to 1.3.) - If there is a public version of BaseNotification the BP will be updated to refer to 1.3 draft - Security followup (Marty's comment): Frank to provide some informative text. Otherwise waiting for followup during public comment. - Security writeup issue: Tom will confer with Takuya and update the specificaion. - A new version will be uploaded over the next couple of days. - A final review will be done at the next call (Wednesday). * GGF14 preparation - Jem will put some slides together for a Roadmap presenation. * Next call - WSRF Basic Profile and Profile Definition final review - GGF14 preparation

1 0