- ogsa-wg - lists.ogf.org

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

23 Jun '05

Hi Steven, > > Try to steer the discusion past that one (or around it), so > that we can get > > to the next problem: > > The purpose of the BOF is to explore if there is interest in > developing > a second OGSA profile. I don't see this as a discussion point > within the > BoF unless their is overlap.. and isn't this what the GFSG examines? - When I sent that e-mail the agenda was not that clear, and in fact it still isn't -- it's time for a formal agenda listing what is going to be discussed, and especially what is *not* going to be discussed. Notice that I posted that e-mail as an attempt to make things clearer, and I'm saying that this subject is improductive and worth avoiding. - The word "second" above is important, because that's when it stops being "only one". So if the session leaders don't take care the "(1) Are multiple base profiles OK to begin with?" subject will come up, directly or indirectly, and a lot of time will be wasted in religious discussions among people who disagree with the GFSG policy. > > (3) What are the plans for the "WS-I-only" profile? > > What is being proposed is not a WS-I only OGSA profile. WS-I (basic & > security profiles) define a set of specifications and how Just to clarify, the use of quotation marks above was intentional due to the lack of a name, and I agree with what you said. > > I agree multiple basic profiles are bad idea wrt interoperability > > and architecture perspective. > > But may be critical to wider grid adoption which is why I believe GGF > accepts multiple approaches. IMHO it is a pity that this policy still > seems to be resisted... may be we should drop the O in OGSA? > > Recall, that the 'OGSI profile' did not gain wide adoption. Exploring > different approaches can only help to improve understanding. What is > important IMHO is to bring all approaches into a standards process so > that whatever mechanisms that are used are defined. Once > defined natural selection can drive their evolution. I won't be able to go to the MWS-BOF (I'll be in the OGSA-EGA session), so I'll leave my opinion registered here, very briefly. The risk is that if we leave it for the market to decide, the market won't choose against one or another profile, but it will choose against OGSA as a whole. The people willing to pay for OGSA functionality won't be able to get different components from different parties to work together because they won't fit the same profile, won't speak the same protocols, etc.. The fact that the architecture is theoretically unified will mean nothing because, from their point of view, in practice things simply do not work, period. OGSA as a brand will be meaningless. Who wins then? I have a few guesses, but I am not stupid enough to list them in public forum. Being sarcastic, on the letter "O", perhaps the GGF was truly Open around GGF6, when OGSA was just an architecture among many, nothing special. But the GFSG chose it as the "flagship architecture" of the GGF, stating at least a preference. Allowing multiple profiles without preferences moves things back in the direction of GGF6, which for some people is wonderful, and for others, disastrous. (Again, I'm being sarcastic, don't waste your time taking this too seriously). Regards, Fred Maciel Consensus is the absence of leadership -- Margaret Thatcher

3 2

Re: [ogsa-wg] Profile definition v13
by Tom Maguire 23 Jun '05

23 Jun '05

Yeah, I get it now. Checking on the history and starting internal discussions. 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 Davanum Srinivas <davanum(a)gmail.com> wrote on 06/23/2005 12:26:08 PM: > Tom, > > Have you read the IBM license for WS-Security > (http://www.ibm.com/ibm/licensing/977Q/2112.shtml) Apache will not > sign this license as-is. I can email you the details of our objections > to this license if you want me to. The concerns are VERY similar to > the concerns Apache had for sender-id > (http://www.apache.org/foundation/docs/sender-id-position.html) If > you read the IBM license (or Microsoft's) you will see that it is next > to impossible for an open source project to comply to the license > requirements. > > Thanks, > dims > > On 6/23/05, Tom Maguire <tmaguire(a)us.ibm.com> wrote: > > It is unclear to me after reading through the threads what is the license > > issue. > > > > 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 > > > > > > > > Steve Loughran > > <steve_loughran@h > > pl.hp.com> To > > Sent by: ogsa-wg <ogsa-wg(a)gridforum.org> > > owner-ogsa-wg@ggf cc > > .org davanum(a)gmail.com > > Subject > > Re: [ogsa-wg] Profile definition > > 06/23/2005 08:23 v13 > > AM > > > > > > > > > > > > > > > > > > > > Andreas Savva wrote: > > > I've uploaded v13 of the Profile definition. This includes a lot of > > > edits from Jem and from the review done in the last (yesterday) call. > > > > > > > > https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf- > ogsa-profile-definition/en/13 > > > > > > > > > > > > One little troublespot with the profile is that unless IBM and Microsoft > > are willing to adapt their IPR licensing policy for WSSecurity, there > > may shortly not be any functional open source WS-Security implementations > > > > the summary of the current state is: > > > > http://marc.theaimsgroup.com/?l=incubator-general&m=111894292828449&w=2 > > > > and the licenses in question are > > > > http://www.microsoft.com/mscorp/ip/standards/ > > http://www.ibm.com/ibm/licensing/977Q/2112.shtml > > > > Unless these two vendors come to an amenable position, there isn't going > > to be an apache implementation (and that includes an end to WSS4J), > > which is going to prevent it from entering the 'community' section, or > > being broadly used. > > > > Now, who was planning on using WSS4J in their products? > > > > -steve > > > > > > > -- > Davanum Srinivas -http://blogs.cocoondev.org/dims/

1 0

Profile definition v13
by Andreas Savva 23 Jun '05

23 Jun '05

I've uploaded v13 of the Profile definition. This includes a lot of edits from Jem and from the review done in the last (yesterday) call. https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-profil… Tom, Dave: Since you are the authors, one (or both) of you should review and accept or reject changes. Especially the ones that may affect the intended meaning. -- Andreas Savva

4 3

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

23 Jun '05

Hmm, it seems to me that they're more likely to be written by other groups than by OGSA-WG, and OGSA-WG should also be considered a domain-expert group, so I don't see any reason to call us out explicitly. For now I've removed "and their design teams" phrase - does anyone have any objection to just leaving it like that? Note also that in the intro para we do say that OGSA-WG "manages" the overall process. - Jem > -----Original Message----- > From: Hiro Kishimoto [mailto:hiro.kishimoto@jp.fujitsu.com] > Sent: Thursday, June 23, 2005 12:23 AM > To: Andreas Savva > Cc: Treadwell, Jem; Djaoui, A (Abdeslem); ogsa-wg > Subject: Re: [ogsa-wg] Minor comments on documents > > Hi Andreas, Jem, Abdeslem, > > I agree with Andreas. How about the following? > > "which are written and maintained by the OGSA-WG or the > appropriate domain-expert working groups" > > Thanks, > ---- > Hiro Kishimoto > > Andreas Savva wrote: > > Jem, Abdeslem > > > > I think it's inappropriate to mention design teams in this context, > > since they do not have a formal role. The document itself would be > > labelled as the output of the working group, not of the design team. > > > > Treadwell, Jem wrote: > > > >> 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 > >>> > >>> > >> > >> > >> > >> > > > > > > >

1 0

RE: [ogsa-wg] Minor comments on documents
by Djaoui, A (Abdeslem) 23 Jun '05

23 Jun '05

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

2 1

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

23 Jun '05

Marty, I don't know how much debate you want on the list before the BOF itself, but could you perhaps answer two questions to help set the context? 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.? 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. Dave. -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Marty Humphrey Sent: 21 June 2005 15:28 To: 'Ogsa-Wg' Subject: RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30 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

4 9

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