RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30
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@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
Dave Berry wrote:
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 think it looks like their state model, but considering the state of the service to be an enumeration of configurations is fairly perverse, and there does not seem to be any simple way of extending set of state transitions without developing a whole new spec on top of it. Maybe I'm wrong, but it feels like something being pressed into service to do that which it was not designed for. Not that that's something that's never happened before in this industry, oh no! :^) Or am I way off base here? Donal.
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
So to be precise, with regard to status, you have no idea when or if those specifications will be submitted to an SDO for standardization. Further you have no way of knowing when or if those specifications will be submitted to an SDO, given that there are most likely contractual obligations between the current set of authors to which you would never be privy and if you were would be precluded from disclosing. 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 owner-ogsa-wg@ggf.org wrote on 06/22/2005 07:45:03 AM:
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
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
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
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
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
they this, the source, 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
Three alternate answers: [1] MS has been giving *public* talks (I attended one two weeks ago) in which they publicly stated that they believed that "everything" would be in standards bodies within a year. I asked the speaker specifically with regard to WS-SecureConversation, WS-Trust, and WS-Management and the speaker said yes. I believe I followed up privately regarding WS-Transfer, WS-Enumeration, and WS-Eventing, and he said yes. He said that certain things are out of their control, of course, but that every intention is to have them these specs in standards bodies by the end of the year. Yes, I understand that this is an easy statement to attack, but I tend to believe him (MS realizes that every day these are NOT in a standards body is an opportunity lost, right?) Yes, I understand that the world is not so simple, but I tend to believe them. [2] Given that Don Ferguson and Francisco Curbera of IBM are co-authors of WS-Eventing, and given that you're employed by IBM, I would turn this around and ask you to see if you can ask internally to find out some publicly-disclosable answers, which you could then share with the rest of the community. [3] I've heard IPR issues as being the bugaboo regarding specifications as opposed to documents ratified by standards bodies. So I'll assume that you're referring to the IPR issues in the latter half of your email. If not, and you believe that these specs will never actually make it to a standards body, then you can ignore the following response (and perhaps focus on my response #1, above).... Regarding IPR, admittedly, IPR has never been something that I've had the time or interest to deeply understand (I'm an academic, remember?) So your statement (which I believe to refer to IPR) made me curious. In digging to try to find the IPR issues/statements for WSRF and WS-Eventing (for example), I'm even more confused. On one hand, here's the statement on the WS-Eventing spec: "BEA, Computer Associates, IBM, Microsoft, Sun, and TIBCO (collectively, the "Authors") each agree to grant you a license, under royalty-free and otherwise reasonable, non-discriminatory terms and conditions, to their respective essential patent claims that they deem necessary to implement the Specification." This seems pretty clear (and desirable for our community, right?) So what's the issue? That it might change before being submitted to a standards body? Please help me understand. I'm trying to figure out the comparable statement with regard to, say, WS-Resource Property, it doesn't seem to be as clear. The spec itself doesn't seem to say anything directly one way or the other, except to say in Appendix E ("OASIS takes no position regarding the validity or scope of any intellectual property or any other rights that might be claimed to pertain to the implementation or use of the technology described in this document....") On page 2, the spec *does* say "For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of WSRF TC Web page". This web page says that this TC operates under something called the "Legacy IPR Policy", which seems to be a very generic statement (nothing specific to WSRF -- just "no confidentiality requirements on contributions", "contributors must disclose known patents"). But nothing that I can find about royalty-free. Perhaps I'm missing it. So, can you tell me why the WS-Eventing is so bad compared to WSRF? As we all know, it's not like "because it's in OASIS, it's royalty-free", right? Thanks for clearing this up for me, 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 2:44 PM To: Marty Humphrey Cc: 'Ogsa-Wg'; owner-ogsa-wg@ggf.org Subject: RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30
So to be precise, with regard to status, you have no idea when or if those specifications will be submitted to an SDO for standardization. Further you have no way of knowing when or if those specifications will be submitted to an SDO, given that there are most likely contractual obligations between the current set of authors to which you would never be privy and if you were would be precluded from disclosing.
Tom
Freys 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
owner-ogsa-wg@ggf.org wrote on 06/22/2005 07:45:03 AM:
1. Please could you clarify the status of WS-Transfer, WS-Eventing
WS-Enumeration in the terms of the OGSA Profile template? I.e. have
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
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
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
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
and they this, the source, 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
owner-ogsa-wg@ggf.org wrote on 06/22/2005 04:13:17 PM:
Three alternate answers:
[1] MS has been giving *public* talks (I attended one two weeks ago) in which they publicly stated that they believed that "everything" would be in standards bodies within a year. I asked the speaker specifically with regard to WS-SecureConversation, WS-Trust, and WS-Management and the speaker said yes. I believe I followed up privately regarding WS-Transfer, WS-Enumeration, and WS-Eventing, and he said yes. He said that certain things are out of their control, of course, but that every intention is to have them these specs in standards bodies by the end of the year. Yes, I understand that this is an easy statement to attack, but I tend to believe him (MS realizes that every day these are NOT in a standards body is an opportunity lost, right?) Yes, I understand that the world is not so simple, but I tend to believe them.
If you wish to believe this that is your perogative. I on the other hand will wait and not hold my breath. As to opportunity lost; what is the incentive to standardize if developers are happy to work with specs that are not standardized?
[2] Given that Don Ferguson and Francisco Curbera of IBM are co-authors of WS-Eventing, and given that you're employed by IBM, I would turn this around and ask you to see if you can ask internally to find out some publicly-disclosable answers, which you could then share with the rest of the community.
As I mentioned in earlier thread typically co-authors are contractually obliged to one another with regard to joint work (read specs). Those agreements usually spell out ALL of the details of the joint work up to and including how agreement would be reached among the co-authors to bring to an SDO. Typically those joint agreements would preclude unilateral action on any one parties part with respect to the joint works. Additionally, some of those agreements preclude disclosure of the agreement details. With that in mind, IBM as a co-author of WS-Eventing intends to bring the WS-Eventing specification forward with the co-authors at some point. However, there is no definitive date and as a forward looking statement this statement of intent is subject to changes in business imperatives.
[3] I've heard IPR issues as being the bugaboo regarding specifications as opposed to documents ratified by standards bodies. So I'll assume that you're referring to the IPR issues in the latter half of your email. If not, and you believe that these specs will never actually make it to a standards body, then you can ignore the following response (and perhaps focus on my response #1, above)....
Regarding IPR, admittedly, IPR has never been something that I've had the time or interest to deeply understand (I'm an academic, remember?) So your statement (which I believe to refer to IPR) made me curious. In digging to try to find the IPR issues/statements for WSRF and WS-Eventing (for example), I'm even more confused.
On one hand, here's the statement on the WS-Eventing spec:
"BEA, Computer Associates, IBM, Microsoft, Sun, and TIBCO (collectively,
"Authors") each agree to grant you a license, under royalty-free and otherwise reasonable, non-discriminatory terms and conditions, to their respective essential patent claims that they deem necessary to implement
Specification."
This seems pretty clear (and desirable for our community, right?) So what's the issue? That it might change before being submitted to a standards
Please help me understand.
I'm trying to figure out the comparable statement with regard to, say, WS-Resource Property, it doesn't seem to be as clear. The spec itself doesn't seem to say anything directly one way or the other, except to say in Appendix E ("OASIS takes no position regarding the validity or scope of any intellectual property or any other rights that might be claimed to
to the implementation or use of the technology described in this document....") On page 2, the spec *does* say "For information on whether any patents have been disclosed that may be essential to implementing
specification, and any offers of patent licensing terms, please refer to
Intellectual Property Rights section of WSRF TC Web page". This web page says that this TC operates under something called the "Legacy IPR Policy", which seems to be a very generic statement (nothing specific to WSRF -- just "no confidentiality requirements on contributions", "contributors must disclose known patents"). But nothing that I can find about royalty-free. Perhaps I'm missing it.
So, can you tell me why the WS-Eventing is so bad compared to WSRF? As we all know, it's not like "because it's in OASIS, it's royalty-free", right?
Thanks for clearing this up for me, 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 2:44 PM To: Marty Humphrey Cc: 'Ogsa-Wg'; owner-ogsa-wg@ggf.org Subject: RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30
So to be precise, with regard to status, you have no idea when or if
specifications will be submitted to an SDO for standardization. Further you have no way of knowing when or if those specifications will be submitted to an SDO, given that there are most likely contractual obligations between the current set of authors to which you would never be privy and if you were would be precluded from disclosing.
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
owner-ogsa-wg@ggf.org wrote on 06/22/2005 07:45:03 AM:
1. Please could you clarify the status of WS-Transfer, WS-Eventing
WS-Enumeration in the terms of the OGSA Profile template? I.e. have
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
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
and they this, 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
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
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
I was not focused on IPR although that is an issue. Although not a first level issue. the the body? pertain this the those the through 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
-----Original Message----- From: Tom Maguire [mailto:tmaguire@us.ibm.com] Sent: Wednesday, June 22, 2005 4:52 PM To: Marty Humphrey Cc: 'Ogsa-Wg'; owner-ogsa-wg@ggf.org Subject: RE: [ogsa-wg] OGSA-MWS-BOF at GGF14 on Tues June 28, noon-1:30
owner-ogsa-wg@ggf.org wrote on 06/22/2005 04:13:17 PM:
Three alternate answers:
[1] MS has been giving *public* talks (I attended one two weeks ago) in which they publicly stated that they believed that "everything" would be in standards bodies within a year. I asked the speaker specifically with regard to WS-SecureConversation, WS-Trust, and WS-Management and the speaker said yes. I believe I followed up privately regarding WS-Transfer, WS-Enumeration, and WS-Eventing, and he said yes. He said that certain things are out of their control, of course, but that every intention is to have them these specs in standards bodies by the end of the year. Yes, I understand that this is an easy statement to attack, but I tend to believe him (MS realizes that every day these are NOT in a standards body is an opportunity lost, right?) Yes, I understand that the world is not so simple, but I tend to believe them.
If you wish to believe this that is your perogative. I on the other hand will wait and not hold my breath. As to opportunity lost; what is the incentive to standardize if developers are happy to work with specs that are not standardized?
I find this statement curious. Isn't this *PRECISELY* what we're talking about? That is, YOU (and I assume that you are not alone in this concern) are reluctant to pursue these specs in part because they're not standardized. So saying that "developers are happy to work with specs that are not standardized" doesn't seem quite right.
[2] Given that Don Ferguson and Francisco Curbera of IBM are co-authors of WS-Eventing, and given that you're employed by IBM, I would turn this around and ask you to see if you can ask internally to find out some publicly-disclosable answers, which you could then share with the rest of the community.
As I mentioned in earlier thread typically co-authors are contractually obliged to one another with regard to joint work (read specs). Those agreements usually spell out ALL of the details of the joint work up to and including how agreement would be reached among the co-authors to bring to an SDO. Typically those joint agreements would preclude unilateral action on any one parties part with respect to the joint works. Additionally, some of those agreements preclude disclosure of the agreement details. With that in mind, IBM as a co-author of WS-Eventing intends to bring the WS-Eventing specification forward with the co-authors at some point. However, there is no definitive date and as a forward looking statement this statement of intent is subject to changes in business imperatives.
While I understand that this can occur, I have no direct experience with this regard. I appreciate your comments here to clear things up. I (perhaps naively) am hoping for the best. -- marty Marty Humphrey Assistant Professor Department of Computer Science University of Virginia
(MS realizes that every day these are NOT in a standards body is an opportunity lost, right?)
If you wish to believe this that is your perogative. I on the other hand will wait and not hold my breath. As to opportunity lost; what is the incentive to standardize if developers are happy to work with specs
are not standardized?
I find this statement curious. Isn't this *PRECISELY* what we're talking about? That is, YOU (and I assume that you are not alone in this concern) are reluctant to pursue these specs in part because they're not standardized. So saying that "developers are happy to work with specs
that that
are not standardized" doesn't seem quite right.
My comment was wrt your assertion that MS realizes that NOT being in a standards body is an opportunity lost. I do not believe it can be characterized as a lost opportunity for MS if some set of developers (not me) think that it is fine to use those specs with them being in a standards body. What is their incentive? What additional benefit do they accrue from moving the spec into a standards body? Let me be absolutely clear. Entertaining these specifications as a basis for profile work in OGSA will be a disincentive for moving those specifications into an SDO.
My comment was wrt your assertion that MS realizes that NOT being in a standards body is an opportunity lost. I do not believe it can be characterized as a lost opportunity for MS if some set of developers (not me) think that it is fine to use those specs with
should be without not with....
them being in a standards body. What is their incentive? What additional benefit do they accrue from moving the spec into a standards body?
Let me be absolutely clear. Entertaining these specifications as a basis for profile work in OGSA will be a disincentive for moving those specifications into an SDO.
Let me be absolutely clear. Entertaining these specifications as a basis for profile work in OGSA will be a disincentive for moving those specifications into an SDO.
I understand and respect your belief here, but I don't think this is necessarily true. From what I've heard, the authors of these specs have existing plans to get these specs into standards bodies; These plans are clearly independent of GGF. I'd like to think that this might even serve as an INCENTIVE in a very minor way ("Oh, there's a community that wants to use these specs, but this community is reluctant because the specs are not in standards bodies? Well, we clearly want these specs to be used, so let's get them into standards bodies!") While I don't realistically think this would happen, I also don't believe that it will be a disincentive. -- Marty Marty Humphrey Assistant Professor Department of Computer Science University of Virginia
participants (4)
-
Dave Berry -
Donal K. Fellows -
Marty Humphrey -
Tom Maguire