RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30
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@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
Dave, You bring up a valid concern regarding the Informational Profile vs. Recommended Profile. I, too, do not presume to answer the question regarding WHEN to pursue this (if ever) one way or the other-- although I *am* leaning toward moving forward with this effort, soon, given sufficient community interest. Microsoft has stated many times that they are following this four-step process for a very deliberate reason: in effect, to *NOT* get "bogged down" in a standards body, modifying specs and then re-performing interop tests, waiting for everyone to come to consensus (and perhaps add their own little pet protocol/mechanism/whatever). That is, they would argue that their current four-step process directly facilitates fast-ratification in a standards body such as OASIS, because so much work (e.g., interop in the workshops) takes place *BEFORE* going into standards bodies. This of course argues that -- if true -- there is reason for this OGSA-based profiling to move forward, and now (to restate slightly, IF it is to move forward, THEN it should move forward now). I'm not necessarily convinced that this is true, but the optimist in me would like to believe so. But again, you're right -- this is certainly a reasonable topic for discussion in the BOF! -- Marty Marty Humphrey Assistant Professor Department of Computer Science University of Virginia
-----Original Message----- From: Dave Berry [mailto:daveb@nesc.ac.uk] Sent: Wednesday, June 22, 2005 6:08 PM To: Marty Humphrey; Ogsa-Wg Subject: RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30
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@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
participants (2)
-
Dave Berry -
Marty Humphrey