SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
|
| News: Cover Stories |  |  |
| W3C Forms New Web Services Resource Access (WS-RA) Working Group. |
Contents
W3C has announced the formation of a new Web Services Resource Access (WS-RA) Working Group as part of the W3C Web Services Activity, chartered through June 30, 2010. The WS-RA Working Group will produce W3C Recommendations for a set of Web Services specifications by refining the WS-Transfer, WS-ResourceTransfer, WS-Enumeration, WS-MetadataExchange, and WS-Eventing Member Submissions contributed in March 2006 and August 2008. The five W3C Member Submissions serving as input specifications were contributed (variably) by BEA Systems, Computer Associates, Fujitsu, Hitachi, IBM, Intel, Layer 7, Microsoft, Progress Software, Red Hat, SAP AG, Software AG, Sonic Software, Systinet (A Mercury Division), Tibco, WSO2, Xerox. Bob Freund (Hitachi) serves as the WG Chair, and Yves Lafon is the W3C Team Contact.
The WS-RA Working Group is chartered to standardize a general mechanism for accessing and updating the XML representation of a resource-oriented Web Service and metadata of a Web Service, as well as a mechanism to subscribe to events from a Web Service. Because the submitted specifications are relevant to other standardization efforts that rely on resource access and event subscription mechanisms, the Web Services Resource Access Working Group is expected to complete its work in a timely fashion.
"The submitted specifications define SOAP-based mechanisms for interacting with the XML representation behind a resource-oriented Web Service, accessing metadata related to that service, as well as a mechanism to subscribe to events related to that resource. In summary:
Web Services Transfer (WS-Transfer) defines the basic Create, Read, Update, Delete (CRUD) operations against resource-oriented Web Service data. It describes a general SOAP-based protocol for accessing XML representations of Web service-based resources. In particular, it defines how to invoke a simple set of familiar verbs (Get, Post, Put, and Delete) using SOAP, where an application protocol may be constructed to perform these operations over resources. Web Services Resource Transfer (WS-RT) enhances WS-Transfer operations, through the extensibility points, with the addition of fragment and batched access. It is intended to form a core component of a unified resource access protocol for Web services. The operations described in this specification constitute an extension to the WS-Transfer specification, which defines standard messages for controlling resources using the familiar paradigms of "get", "put", "create", and "delete". The extensions deal primarily with fragment-based access to resources to satisfy the common requirements of WS-ResourceFramework and WS-Management. Web Services Enumeration (WS-Enumeration) provides a protocol that allows a resource to provide a context, called an enumeration context, to a consumer that represents a logical cursor through a sequence of data items. It describes how to enable an application to ask for items from a list of data that is held by a Web service. In this way, WS-Enumeration is useful for reading event logs, message queues, or other data collections. Web Services Metadata Exchange 1.1 (WS-MetadataExchange) defines a mechanism by which metadata about a Web Service can be retrieved. When used in conjunction with WS-Transfer, WS-ResourceTransfer and WS-Enumeration, this metadata can be accessed and managed just like any other Web Service resource. It defines how metadata can be embedded in Web service endpoint references, and how Web service endpoints can optionally support a request-response interaction for the retrieval of metadata. Web Services Eventing (WS-Eventing) allows interested parties to subscribe to a series of notifications from a resource oriented Web Service. It describes how to construct an event-oriented message exchange pattern using WS-Addressing concepts, allowing Web services to act as event sources for subscribers. It defines the operations required to manage subscriptions to event sources, as well as how the actual event messages are constructed.
New publications expected from the WS-RA Working Group include W3C Recommendations for the output specifications of this Working Group. The Working Group may organize the structure of the specifications into one or more documents. A test suite will be created, intended to promote implementation of the Candidate Recommendation, and to assess interoperability between these implementations. Optionally, the WG may produce a primer that includes guidance on the use of the specifications. Optionally, the Working Group may produce new charter for follow-on work on these specifications per the World Wide Web Consortium Process Document.
The WS-RA Working Group deliverables will be based on W3C Recommendations (SOAP Version 1.2, WS-Addressing 1.0, WSDL 2.0, WS-Policy 1.5) and aligned with ISO 29361:2008 (WS-I BP 1.1). However, the Working Group should also consider conformance to the forthcoming profiles WS-I is finalizing assuming they achieve WS-I "Final Material" status before the Working Group completes its deliverables. The WG will work to minimize overlap and maximize composability with other Web Services specifications. In order to avoid disrupting the interoperability of existing implementations, the new Recommendations should remain compatible with protocols and formats that depend on them, and offer a smooth migration path from submission to standard.
The Working Group is expected to demonstrate at least two interoperable implementations of each deliverable during the Call for Implementations step of the set of features not marked as "at risk" for each Recommendation specification.
The five Member Submissions (submitted specifications) relevant to WS-RA are:
Web Services Transfer (WS-Transfer). W3C Member Submission. September 27, 2006. This version URI: http://www.w3.org/Submission/2006/SUBM-WS-Transfer-20060927/. Latest version URI: http://www.w3.org/Submission/WS-Transfer/. Previous version URI: http://www.w3.org/Submission/2006/SUBM-WS-Transfer-20060315/. Authors: Jan Alexander (Systinet), Don Box (Microsoft), Luis Felipe Cabrera (Microsoft), Dave Chappell (Sonic Software), Glen Daniels (Sonic Software), Radovan Janecek (Systinet), Chris Kaler (Microsoft), Brad Lovering (Microsoft), Raymond McCollum (Microsoft), David Orchard (BEA), Savas Parastatidis (Microsoft), Jeffrey Schlimmer (Microsoft), Igor Sedukhin (CA), and John Shewchuk (Microsoft). Copyright © 2004-2006 BEA Systems Inc., CA, Microsoft Corporation, Inc., Sonic Software, and Systinet (A Mercury Division).
Submitted March 01, 2006 by David Orchard (BEA Systems), Kirk Wilson (Computer Associates), Kyle Young (Microsoft), Glen Daniels (Sonic Software), Petr Dvorak (Systinet, A Mercury Division). "We suggest that the Consortium make this submission available for consideration by members or other third parties." Inquiries from the public or press about this Submission should be directed to: May Petry (BEA Systems), Kirk Wilson (Computer Associates), Ari Bixhorn (Microsoft), Trip Kucera (Sonic Software), or Ian Bruce (Systinet, A Mercury Division).
W3C Team Comment on Web Services Transfer (WS-Transfer) Submission, by Philippe Le Hégaret and Hugo Haas:
"WS-Transfer is a SOAP-based protocol for manipulating resources and their representations. One can create, modify, delete resources, as well as retrieve representations of those resources. Resources are defined as 'entities addressable by an endpoint reference that provide an XML representation'. For the purpose of creating new resources, resource factories are introduced, defined as 'Web services that can create a new resource from an XML representation'.
This protocol is built using the SOAP messaging framework, both version 1.1 which is a W3C Member Submission and version 1.2 which is a W3C Recommendation, and the WS-Addressing Member Submission. It does not define, however, a URI to identify the SOAP module defined as per the SOAP 1.2 specification.
There is an obvious parallel between WS-Transfer and the Hypertext Transfer Protocol (HTTP/1.1) and the Web itself...
WS-Transfer can therefore be seen as an underlying protocol-independent version of HTTP, i.e., bringing the capabilities and properties of the Web and HTTP in contexts where HTTP is not used. The use of WS-Transfer is not limited to non-HTTP transports, and can also be used when HTTP is used as a communication tunnel.
While the resources manipulated are entities that 'provide an XML representation', the use of the SOAP Message Transmission Optimization Mechanism along with WS-Transfer would allow one to efficiently manipulate other types of entities such as binary ones.
However, there is one important difference between WS-Transfer resources and Web resources: their identification. While resources are identified by URIs on the Web as explained in section 2 of the Architecture of the World Wide Web, Volume One, WS-Transfer identifies them with endpoint references as defined by the WS-Addressing Member Submission, which means that WS-Transfer resources are potentially identified by more than just a URI, making them unsuitable for referencing and use in other Web technologies, e.g., in the context of traditional Web links or RDF assertions... [see subsequent TAG Note]
WS-Transfer does not have all the features of HTTP regarding the manipulation of representations, such as caching, or content and language negotiation. However, the extensibility of SOAP would allow to add such capabilities incrementally, and it can benefit from the use of existing SOAP extensions such as WS-Security for security, or WS-Reliability or WS-Reliable Messaging for reliability..."
Web Services Resource Transfer (WS-RT). W3C Member Submission. August 12, 2008. This version URI: http://www.w3.org/Submission/2008/SUBM-WSRT-20080812/. Latest version URI: http://www.w3.org/Submission/WSRT. Authors: Brian Reistad (Microsoft Corporation), Bryan Murray (HP), Doug Davis (IBM), Ian Robinson (Editor - IBM), Raymond McCollum (Editor - Microsoft Corporation), Alexander Nosov (Microsoft Corporation), Steve Graham (IBM), and Vijay Tewari (Intel Corporation). Copyright © 2008 HP, IBM, Intel Corporation, and Microsoft Corporation, Inc.
Submitted August 12, 2008 by Paul Lipton (CA), Kazunori Iwasa (Fujitsu), Matsuki Yoshino (Hitachi), Steve Holbrook (IBM) and Wayne Carr (Intel). "We suggest that the Web Services Resource Transfer specification be standardized in the new Working Group suggested by CA, Fujitsu, IBM and Oracle in their note to the W3C Membership. Inquiries from the public or press about this Submission should be directed to: Robert Gordon (CA), Kazunori Iwasa (Fujitsu), Matsuki Yoshino (Hitachi), and Matthew Berry (IBM).
W3C Team Comment on Web Services Resource Transfer (WS-RT), by Yves Lafon:
"WS-RT defines how to use WS-Transfer to Create, Read, Update and Delete "Web service Resources" or fragments of such resources. In this Submission, Web service Resources are defined as being accessible using an endpoint reference (EPR), so not directly by a URI, and creation of new Web service Resources are handled by specialized Web services: Resource factories.
Operations can be performed on the entire resource, on one fragment, or on several fragments of this resource. The selection of fragments depends on a Dialect, an URI used to identify the kind of selection done. In the Submission, QName, XPath Level 1 (a profiled version of XPath 1.0 defined in this Submission) and XPath 1.0 are used.
Actions meant to update a Web service Resource (PUT, CREATE and DELETE) are not protected using a validator (see ETag and conditionnal requests in HTTP/1.1), leading to the lost update issue. In the case of multiple fragments, or multiple resources, the processing is not defined in case only one of those fragments or resource generates a fault, nor the compensation actions that might be performed in this case..." Web Services Enumeration (WS-Enumeration). W3C Member Submission. March 15, 2006. This version URI: http://www.w3.org/Submission/2006/SUBM-WS-Enumeration-20060315/. Latest version URI: http://www.w3.org/Submission/WS-Enumeration/. Authors: Jan Alexander (Systinet), Don Box (Microsoft), Luis Felipe Cabrera (Microsoft), Dave Chappell (Sonic Software), Glen Daniels (Sonic Software), Chris Kaler (Microsoft), David Orchard (BEA), Igor Sedukhin (Computer Associates), Miroslav Simek (Systinet), and Marvin Theimer (Microsoft). Copyright © 2004-2006 BEA Systems Inc., Computer Associates, Microsoft Corporation, Inc., Sonic Software, and Systinet (A Mercury Division).
Submitted March 01, 2006 by David Orchard (BEA Systems), Kirk Wilson (Computer Associates), Kyle Young (Microsoft), Glen Daniels (Sonic Software), Petr Dvorak (Systinet, A Mercury Division). "We suggest that the Consortium make this submission available for consideration by members or other third parties." Inquiries from the public or press about this Submission should be directed to: May Petry (BEA Systems), Kirk Wilson (Computer Associates), Ari Bixhorn (Microsoft), Trip Kucera (Sonic Software), or Ian Bruce (Systinet, A Mercury Division).
W3C Team Comment on Web Services Enumeration (WS-Enumeration) Submission, by Hugo Haas:
"WS-Enumeration is a SOAP-based protocol for 'XML elements that is suitable for traversing logs, message queues, or other linear information models.' This protocol is built using the SOAP messaging framework, both version 1.1 which is a W3C Member Submission and version 1.2 which is a W3C Recommendation. It does not define, however, a URI to identify the SOAP module defined as per the SOAP 1.2 specification.
The core concept of this protocol is an enumeration context, which "allows the data source to provide a session abstraction [..] to a consumer that represents a logical cursor through a sequence of data items". WS-Enumeration supports similar expiration and filtering capabilities as WS-Eventing, also submitted as a W3C Member Submission..." Web Services Metadata Exchange 1.1 (WS-MetadataExchange). W3C Member Submission. August 13, 2008. This version URI: http://www.w3.org/Submission/2008/SUBM-WS-MetadataExchange-20080813/. Latest version URI: http://www.w3.org/Submission/WS-MetadataExchange/. Authors: Keith Ballinger (Microsoft), Bobby Bissett (Sun Microsystems (Inc.), Don Box (Microsoft), Francisco Curbera (Editor) (IBM), Don Ferguson (IBM (no longer affiliated with IBM)), Steve Graham (IBM (no longer affiliated with IBM)), Canyang Kevin Liu (SAP), Frank Leymann (IBM), Brad Lovering (Microsoft), Raymond McCollum (Microsoft), Anthony Nadalin (IBM), Savas Parastatidis (Editor) (Microsoft), Claus von Riegen (SAP), Jeffrey Schlimmer (Editor) (Microsoft), John Shewchuk (Microsoft), Bill Smith (Sun Microsystems (Inc.), Greg Truty (IBM), Asir Vedamuthu (Microsoft), Sanjiva Weerawarana (IBM (no longer affiliated with IBM)), Kirk Wilson (CA), Prasad Yendluri (Software AG). Copyright © 2004-2008 CA, International Business Machines Corporation, Microsoft Corporation, Inc., SAP AG, Sun Microsystems, Inc., and Software AG.
Submitted August 13, 2008 by Paul Lipton (CA), Bob Freund (Hitachi), Steve Holbrook (IBM), Toufic Boubez (Layer 7), Michael Champion (Microsoft), Jaime Meritt (Progress Software), Mark Little (Red Hat), David Burdett (SAP AG), Prasad Yendluri (Software AG), Shivajee Samdarshi (TIBCO), Jonathan Marsh (WSO2) and Shriram Revankar (Xerox). "We suggest that the consortium make this submission available for consideration in charter discussions for a possible Recommendation-track working group." Inquiries from the public or press about this Submission should be directed to: Robert Gordon (CA), Matsuki Yoshino (Hitachi), Matthew Berry (IBM), Dimitri Sirota (Layer 7), Eileen Rumwell (Microsoft), John Stewart (Progress Software), Mark Little (Red Hat), Lindsey Held (SAP AG), John Conley (Software AG), Phillip Tree (TIBCO), Katie Poplin (WSO2) and Armon Rahgozar (Xerox).
W3C Team Comment on Web Services Metadata Exchange 1.1 (WS-MetadataExchange), by Yves Lafon:
"WS-MetadataExchange defines how metadata relative to a specific Web Services endpoint might be addressed and retrieved, using WS-Transfer. A Web Service may be defined by a set of metadata documents in order to allow other services or clients to interact with it. WSDL (describing the concrete binding used to communicate with it, the overall messaging operation as well as the message and data structures), WS-Policy (describing the requirements that a client should meet while talking to this service) and XML Schema (used in WSDL, or externally to describe the structure and data types of the messages) are the metadata documents addressed by this Submission, although the mechanism is open to other kind of metadata.
In this document, the version of WSDL used is WSDL 1.1 [W3C Member Submission] and the version of WS-Policy is also the W3C Member Submission. More recent W3C Recommendations are available, see WSDL 2.0 and WS-Policy 1.5.
This Submission defines an encapsulation mechanism, used to transport and identify the metadata and its type (Policy, WSDL, Schema). In the definition of a Metadata Section, several properties are used: (1) Dialect: Identifying the type of Metadata; (2) MetadataReference: The Endpoint Reference (EPR) of the metadata resource; (3) Location: The URL of the metadata resource... The Dialect property might be seen as being in conflict with the use of Media Types used to identify the different formats, however the fact that XML Schema does not have a specific Media Type (it uses application/xml) makes this addition a solution to the negotiation of the metadata.
Also there are different way to access those metadata, via an Endpoint Reference, or an URL. In the case of an URL, it is not clear that there will be a direct retreival using the native protocol of the URL, or a SOAP interaction using WS-Transfer at that particular URI. In the latter case comments made about WS-Transfer apply. It is also possible to embed metadata fragments in an EPR, but in this case the issue of the authoritative version of those metadata is open..." Web Services Eventing (WS-Eventing). W3C Member Submission. March 15, 2006. This version URI: http://www.w3.org/Submission/2006/SUBM-WS-Eventing-20060315/. Latest version URI: http://www.w3.org/Submission/WS-Eventing/. Authors: Don Box (Microsoft), Luis Felipe Cabrera (Microsoft), Craig Critchley (Microsoft), Francisco Curbera (IBM), Donald Ferguson (IBM), Steve Graham (IBM), David Hull (TIBCO Software), Gopal Kakivaya (Microsoft), Amelia Lewis (TIBCO Software), Brad Lovering (Microsoft), Peter Niblett (IBM), David Orchard (BEA Systems), Shivajee Samdarshi (TIBCO Software), Jeffrey Schlimmer (Microsoft), Igor Sedukhin (Computer Associates), John Shewchuk (Microsoft), Sanjiva Weerawarana (IBM), and David Wortendyke (Microsoft). Copyright © 2004-2006 BEA Systems Inc., Computer Associates International Inc., International Business Machines Corporation, Microsoft Corporation, Inc, and TIBCO Software Inc.
Submitted March 01, 2006 by David Orchard (BEA Systems), Kirk Wilson (Computer Associates), Steve Holbrook (IBM), Kyle Young (Microsoft), Don Mullen (Tibco). "We suggest that the Consortium make this submission available for consideration by members or other third parties." Inquiries from the public or press about this Submission should be directed to: May Petry (BEA Systems), Kirk Wilson (Computer Associates), Ron Favali (IBM), Ari Bixhorn (Microsoft), or Holly Lawrence (Tibco).
W3C Team Comment on Web Services Eventing (WS-Eventing) Submission, by Hugo Haas:
"WS-Eventing is a SOAP-based protocol to subscribe to notifications. The subscriber receives event messages from an event source, and can manage its subscription with a subscription manager. This protocol is built using the SOAP messaging framework, both version 1.1 which is a W3C Member Submission and version 1.2 which is a W3C Recommendation. It does not define, however, a URI to identify the SOAP module defined as per the SOAP 1.2 specification.
The protocol also uses the WS-Addressing Member Submission, on which the Web Services Addressing Working Group has based WS-Addressing 1.0. In particular, the concept of endpoint references (EPR) defined is WS-Addressing is used to communicate the addresses of the subscriber, event source, and subscription manager.
A subscription corresponds to a subscription manager EPR, i.e., WS-Eventing does not define as part of its protocol the concept of subscription identifier in its protocol. Should a Web service act as a subscription manager for more than one subscriptions, the specification defines a wse:Identifier element of type xs:anyURI to be used as a reference parameter in the subscription manager EPR. It might have been useful to have this concept part of the protocol to allow identification of subscriptions in other contexts.
The delivery mode of the notification messages is open. The specification defines a Push mode, which is delivery mechanism where the source sends event messages to the sink as individual, unsolicited, asynchronous SOAP messages. The XML Protocol Working Group is working on a one-way underlying protocol binding for SOAP 1.2 which will allow such delivery over HTTP.
A subscriber can request the subscription to a specific subset of event messages from the event source by using filters. The dialect used for this filtering is open as an extensibility point. The specification defines how to use XPath 1.0 for this filtering.
Finally, the specification defines a @wse:EventSource that can be used in WSDL service descriptions to indicate that an Web service endpoint is an event source and supports WS-Eventing subscription requests, which is only defined for the WSDL 1.1 Member Submission. This WSDL extension could also be used in WSDL 2.0, once a mapping to the WSDL 2.0 component model is defined..."
Excerpted from the statement of scope:
"The following list of features is intended to focus the work of the Working Group and ensure its timely completion:
The definition of basic Create, Read, Update, Delete (CRUD) operations that provide capabilities to create, read, update and delete a Web Service's XML representation and the binding of these operations to SOAP. A mechanism to allow a requester to retrieve metadata, or references to metadata, related to a Web Service and a mechanism to allow embedding of such metadata, or references to such metadata, in an Endpoint Reference (EPR). The defined capability must provide for retrieval and embedding of specific items of metadata such as WSDL, XML Schema and WS-Policy. The referencing of metadata must allow for both EPR or URL style references. The definition of Web service operations (e.g., Enumerate, Pull, etc.) to enable a consumer to request and manage an enumeration context, and retrieve data items from an enumeration context for a data source. These operations must define details of SOAP messages for the request and response as well as one or more filter dialects to select the data that would be sent to the consumer. The ability to work efficiently with large datasets is important. The definition of Web Services operations (e.g., Subscribe, Unsubscribe, etc.) to create and manage subscriptions to events that are delivered via Web Services.
- The definition of one or more filter dialects, such as XPath, that can be used in subscriptions to indicate interest in messages with specific content.
- Mechanisms to allow a subscriber to specify the means by which an event is delivered and the definition of a push-based delivery mode.
A mechanism by which a Web Service can advertise, through its metadata, such as WSDL and WS-Policy, the capabilities it supports from among the features defined by the Web Service Resource Access specifications.
In addition to the points listed above, the Working Group may address the following optimization-related topics:
A mechanism by which a fragment of the XML representation of a resource can be identified for the purpose of accessing, updating or deleting it. [I.e.,] (a) The definition of one or more common expression dialects to identify these fragments. The capabilities in listed above should be designed so that they can be implemented efficiently. For example, it may be desirable to allow the batching of similar requests into a single request.
- Announcement
- WS-RA Working Group
- W3C Web Services
- Background to WG Formation
- WS-Transfer, WS-Enumeration, WS-MetadataExchange, WS-ResourceTransfer. June 20, 2008. See the posting from Jeff Mischkinsky on behalf of IBM, Oracle, CA, and Fujitsu.
- W3C Technical Architecture Group White Paper for the W3C Workshop on Web of Services for Enterprise Computing. By Noah Mendelsohn (IBM Research, Cambridge, MA) for the W3C Technical Architecture Group (TAG). January 10, 2006. "The W3C TAG has expressed interest in this area by means of a white paper."
- Cover Pages Stories
[November 14, 2008] "WS-Resource Access Activity Begun At W3C." By Mark Little. From InfoQueue. "Back in 2006 several specifications were submitted to W3C, including WS-Eventing and WS-Transfer, but never became standards. Over the intervening time there have been a number of implementations of these specifications, but no obvious sign of standardizing them. Of course that didn't stop others pushing competing standards elsewhere, such as WS-Notification. With the warming relations between competing standards efforts in Web Services (e.g., reliable messaging as well as transactions) it seemed only inevitable that something would happen. Well now the W3C has announced the creating of the Web Services Resource Access Working Group... No mention of the other overlapping standards or specifications though... It's obviously very early in this new standards effort, but will this lack of interoperability emphasis have significant knock-on effects to the adoption of whatever standards eventually emerge?" [November 12, 2008] TAG Resolution endorsing W3C Team Comment on the identifications of WS Transfer resources. Posted by Stuart Williams(TAG Co-Chair, HP Labs, Bristol) on behalf of the W3C Technical Architecture Group (TAG): FYI, during their distributed meeting of the 6th November 2008, the TAG reached concenus on the following resolution which is relevant to the recently announced "Web Services Resource Access Working Group": "RESOLUTION: Regarding the WS-Transfer submission: (1) We agree with the Team Comment noting that WS-Transfer resources are potentially identified by more than just a URI, making them unsuitable for referencing and use in other Web technologies, e.g., in the context of traditional Web links or RDF assertions. (2) There is a risk, depending on how WS-Transfer operates over HTTP, that WS-Transfer might not benefit from existing deployed infrastructure such as proxies." This is Tracker Issue ACTION-190, 'Make the above resolution visible on www-tag'. [November 12, 2008] "WS Resource Access working group starting at W3C." By William Vambenepe. "The most obvious potential pushback against this effort is the questionable architectural need to redo over SOAP what can be done over simple HTTP. Along the lines of Erik Wilde's 'HTTP over SOAP over HTTP' post. But I don't expect too much noise about this aspect, because even on the blogosphere people eventually get tired of repeating the same arguments...While I understand the 'WS-Transfer is just HTTP over SOAP over HTTP' argument, this is not my problem with this group. For one thing, this group is not really about WS-Transfer, it's about WS-ResourceTransfer (WS-RT) which adds fine-grained resource access on top of WS-Transfer. Which is not something that HTTP gives you out of the box. You may argue that this is not needed (just model your addressable resources in a fine-grained way and use 'hypermedia' to navigate between them) but I don't really buy this. At least not in the context of IT management models, which is where the whole thing started. You may be able to architect an IT management system in such RESTful way, but even if you can it's too far away from current IT modeling practices to be practical in many scenarios (unfortunately, as it would be a great complement to an RDF-based IT model). On the other hand, I am not convinced that this fine-grained access needs to go beyond 'read' (i.e. no need for 'fine-grained write'). The next concern along that 'HTTP over SOAP over HTTP' line of thought might then be why build this on top of SOAP rather than on top of HTTP. I don't really buy this one either..."
|
 | Receive daily news updates from Managing Editor, Robin Cover.
 |
|
