 |
|
|
Abstract
The W3C chartered the Web Services Architecture (WSA) Working Group to describe the architectural principles underlying Web services that transcend vendor-specific concerns and uses. The working group has made significant progess toward a consensus definition of the core concepts and relationships that characterize web services. It has made more progress in aligning the architectural principles of service oriented architectures, Web services, and the Web itself, while noting the areas in which the principles of the Web and the Web services domain do not fully overlap. The WSA accepts that we operate in an environment where "One True Standard" is very unlikely to emerge even for limited domains; WSA offers a framework for dealing with diversity and evolution. Finally, WSA begins from todays reality where humans provide the semantic "glue" that make Web services work, but envisions that this process that will become more automated, but slowly. In the short run, the WSA document aligns with the Semantic Web by noting that the document itself can be thought of as an ontology for Web services, and presents a formalization of large parts of the architecture using OWL, the W3C Web Ontology Language.
Keywords
Table of Contents
There are very many Web services specifications that have been publicized by the organizations that created them, and the sheer bulk has created immense confusion among developers and analysts. Some specifications overlap one another in functionality to a greater or lesser degree. In many cases, it is unclear whether specifications are competitive or complementary because they use different terminology to describe the same thing, or similar terminology to describe different concepts. It is also generally unclear what the normative status of these specifications might be: Some are "real" standards or recommendations from reputable organizations, others proto-standards in active development, still others good ideas that are being taken seriously, but many are essentially marketing fluff.
There are a variety of technical, business, and political reasons for this situation, but they are too difficult to try to untangle. It is not even clear that this confusing situation is a "bad thing" given the rapid evolution of knowledge and technology in the Web services field. Arguably, premature standardization on inappropriate specifications could hurt the field as badly as a lack of standardization. Nevertheless, the situation appears confusing and contentious even to those who spend much of their time trying to figure it out!
The W3C, realizing that it was being called upon to help understand and shape the Web services sector, chartered the Web Services Architecture Working Group in early 2002. Key points in the charter include:
The working group will come up with a document describing a modular, XML-based architecture of Web services.
The architecture must be cleanly integrated with the Web architecture.
The architecture must be platform-independent and independent of any programming model or mode of communication.
The architecture document will identify the technologies necessary for Web services to be used, described, discovered, and interact with each other in relatively complex ways.
The Working Group will also provide a model of the various Web services efforts at W3C can use the same concepts and terminology, and can clearly model the boundaries and interfaces between them, so that the scope of new Working Groups created to address each piece of is unambiguously defined.
The Working Group may also suggest a glossary used by Web Services specifications in order to ensure the consistency of Web Services terms.
The Working Group will also assess the relationship with the work conducted in the Semantic Web Activity.
There are a number of architectural whitepapers from various vendors and consortia that attempt to provide a similar service. What distinguishes the WSA effort from these?
Vendor architectures propose what should happen, WSA tries to analyze what is happening.
W3C hopes to provide a vendor-neutral framework that steps back from the hype.
W3C places high priority on aligning WSA with its other architectural efforts, especially the TAG's "Architecture of the World Wide Web".
Things got "interesting" fairly quickly once the WSA WG got down to business. It was definitely challenging to define exactly what some common terms really mean, partly because they were invented for marketing purposes rather than technical purposes, and partly because different organizations interpreted them in different ways. It's asking a lot for an industry-wide technical group to achieve consensus on matters about which their employers are hotly disputing in public! Likewise, the relationship between Web services and the Web and the Semantic Web is rather controversial within the W3C itself. Web services make it easier for programs to work together over the Web, but can the semantics of their interaction be formalized and automated? Let's briefly survey some of the more time-consuming discussions.
While the WG was working on the Requirements document, someone innocently suggested that it would be good to offer a definition of what we meant by "Web services". About 18 months and megabytes of email later, the following definition was finally accepted as a consensus:
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
This might seem somewhat straightforward, but it describes the outcome of a rather deep discussion of the role of XML, SOAP, WSDL, and HTTP in thenormativedefinition of a Web service upon which the WSA is built. Probably the simplest way to phrase the question is: "Should an application that sends and retrieves instances of a well-defined XML schema to another application via HTTP be considered a "Web service? What's the point of insisting on SOAP and WSDL if the features of SOAP are not needed and the features of WSDL are handled by direct communication between programmers?" The short answer is that the WSA WG is not by any means denying that an "XML over HTTP" application might be a "web service" in some sense, but that this definition is too unconstrained for the purposes of the WS architecture.
There is no doubt that HTTP+XML works well for common, simple scenarios: and provides a platform on whichapplications can useto build reliable messaging, transactions, security, etc.http://seanmcgrath.blogspot.com/2003_06_08_seanmcgrath_archive.html#200423565WSA, however, wishes to specify how these facilities can be built into theinfrastructure. The current state of the art, which WSA attempts to document, is to use SOAP headers and the SOAP processing model to implement advanced features, and WSDL to describe them. In short, SOAP/WSDL may be overkill for many applications, but are necessary to ground the WSA.
"Service Oriented Architecture" provides the larger context for WSA. Like "Web services", "SOA" means different things to different people, and sorting it all out is a challenge. (A cynic might note that "SOA" has the sort of hype-factor in 2003 that "Web services" had in 2001).
Most discussions of SOA don't say much about what a "service" is, just that it is a unit of software that "does some work" or "performs some business function." . WSA was unable to come up with anything more profound. Ideally services provide some business level function, that is, a real "service" to a user rather than a low-level operation.
In any event, the whole point of a service in an SOA is not what the service does, but how other services and higher level applicatons interact with it. Unlike concrete software such objects or components, services are exposed as an abstraction: one does not "call" or "invoke" a service, one "converses" with it by exchanging messages.
Hao He, a member of the WSA WG, put the distinction between objects and services quite nicelyhttp://www.xml.com/pub/a/ws/2003/09/30/soa.html
The CD player offers a CD playing service. Which is nice because you can replace one CD player with another. You can play the same CD on a portable player or on your expensive stereo. They both offer the same CD playing service, but the quality of service is different. The idea of SOA departs significantly from that of object oriented programming, which strongly suggests that you should bind data and its processing together. So, in object oriented programming style, every CD would come with its own player and they are not supposed to be separated.
The most crucial point in understanding services and SOA is that each service clearly specify a "contract" defining what it will deliver in response to which messages. (The WSA document avoids the word "contract" because we definitely donotwant to imply some legal or business-level agreement between the parties, but the word captures the "I will do this if you do that" informal sense of the term). Other terms such as "interface" are
Observations on SOA based on the WSA experience:
SOA best practice is to make each service autonomous and self-contained so that overall system behavior doesn't depend on side effects of other services. Unfortunately, however, modeling applications as collections of autonomous services is "plain hard work"http://www.cbdiforum.com/public/news/index.php3?id=1284SOA implementations have to be designed or carefully evolved, they can't be auto-generated with fancy tools
"Loose coupling" is the result of a well-designed, carefully-implemented, and properly-deployed SOA application, not something inherent in the definition, the specs, or the tools.
Services may be implemented with objects or components BUT object references, constructors, lifecycles, serializations, etc., should not be exposed in the "service contract." In other words, the requester of a service shouldn't need to know if it is implemented with objects, humans, or trained monkeys, so long as the defined message conversation between the requester and supplier of the service yields the promised result.
The WSA is required to be aligned as closely as possible with the W3C Technical Architecture Group's (TAG) "Architecture of the World Wide Web"http://www.w3.org/TR/webarch. This document describes the Web as "an information space in which the information objects [are] referred to collectively as resources." The key architectural concepts of the Web Architecture document are:
Identification. Each resource is identified by a Uniform Resource Identifier (URI).
Interaction. Web agents exchange information via messages; these messages arise as the result of actions requested by a user or called for by a rendering engine while processing hypermedia-aware data formats. Protocols define the syntax and semantics of agent interactions, as well as the sequence of interactions expected for a given task.
Representation. Messages carry representations of a resource. A resource communicates everything about its state through these representations, which are built from a non-exclusive set of data formats, used separately or in combination (including XHTML, CSS, PNG, XLink, RDF/XML, SVG, and SMIL animation).
WSA attempts to build from / extend the Web architecture to the greatest extent possible. Some possible points of divergence include:
Humans design, describe, and program web services, but automated agents do most of the actual work
WSA is protocol-neutral. For example, WSA must support any “transport” protoco; l Is a COBOL program on a mainframe accessed with SOAP messages over MQ-Series via an HTTP gateway “on the web” ? Reasonable people disagree!
Much of the discussion within WSA on the relationship between the Web and Web services centered on the "Great REST Debate". http://webservices.xml.com/pub/a/ws/2002/02/06/rest.html“REpresentational State Transfer”(REST) is an architectural style introduced in a Ph. D thesis by Roy Fielding, which purports to explain the Web’s success.http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm The mailing lists of WSA and other W3C Web services groups saw strong arguments being made that:
the RPC style of most early Web services technologies doesn't scale to the Internet
state should be maintained only in resources, exchanged in messages rather than via side effects
Set of actions should be generic (e.g. HTTP verbs)
It became clear that Web services CAN be RESTful; whether they SHOULD be is in considerable dispute, and there is no end in sight to that dispute. The WSA attempts to unite REST and "distributed objects" styles in a common framework rather than choosing between them.
The "REST" perspective has definitely been taken very seriously in the WSA working group as well as the W3C groups developing SOAP 1.2 and WSDL 1.2.
SOAP 1.2 supports HTTP and REST more fully than the early drafts did.
The "Web services are distributed objects over the Internet" position is much less tenable than it seems two years ago
"Asynchronous Document exchange" approaches are getting mindshare at the expense of "RPC" approaches.
There is an increasing tendency to use Web URIs in specs when a universal identifier is needed.
State management much more explicitly mentioned in Web services discussions in recent months.
But it has not prevailed overall. Many existing Web services run on secure intranets in which the limitations of the RPC style are less significant than the ability of that style to work easily with existing software and development tools. Likewise, many of the purported advantages REST offers to Web services can be achieved by leveraging XML itself, e.g. the "visibility" of messages to intermediaries.
In its charter, the WSA Working Group is directed to define the scope of activities that are needed to fill identified needs for specifications in the Web services arena. There has been one such need identified, for a standardized set of SOAP and WSDL extensions to facilitate the definition and operation of multi-part, long-running, stateful Web services interactions.
In late 2002, the WG noted that several apparently overlapping proposals having to do with Web services orchestration, choreography, and business process modeling had either been submitted to W3C or had been released by other consortia. WSA recommended to W3C that a working group be formed to standardize a WS Choreography language to provide a standardized solution to this space. The W3C management and Advisory Board agreed, and the new working group got underway in early 2003.
A vendor group had proposed a Business Process Execution Language; the W3C solicited this as an input to the WS Choreography effort, but the developers decided to start an OASIS technical committee to do this instead of making it available to W3C. W3C WS Choreography working group chose to try to minimize overlap with the BPEL effort. That is, while BPEL and WS-Choreography arose from similar ideas and proto-requirements, they are moving in different directions. In the BPEL processing model, there is one agent in charge, executing the processes as prescribed by a Business Process Language document. A Choreography, however, is an interaction among equals, each guided by the Choreography Description Language document.
There are three documents in active development at this time. It is not clear as of this writing whether all will be moved along the Recommendation track, whether they will be combined, whether work will be suspended on some, etc. The documents are:
Web Services Architecture
Web Services Glossary
Web Services Usage Scenarios
An additional, non-normative document is also being considered -- an annotated list of the most significant specifications in the Web services arena.
One popular book [Software Architecture in Practice]defines a software architecture as "the structures of a system, which comprise software components, the externally visible properties of those components, and the relationships among them." The "normative" portions of the Web Services Architecture document follow that format: The overall "structure" of the architecture is presented, then the details of each concept, its definition in terms of observable properties, and its relationship to other concepts are described. The text is illustrated by diagrams (developed using a "mind mapping" visualization tool, not UML notation) that shows how the concepts are inter-related.
The W3C OWL ontology language http://www.w3.org/TR/owl-features/is used for the formal description of the concepts and relationships. The normative status of this formalism is unclear as of this writing: Few working group members are comfortable enough with OWL to authoritatively state that the formalism matches the group consensus. The actual expertise in translating the prose in the document to OWL is supplied by collaborators at Carnegie-Mellon University. Whatever its official status, the process of specifying the WSA document using formal semantics helps find ambiguities and inconsistencies in the prose description. For example, consider this fragment:
<!-- Restriction: a message can have at most one description -->
<!-- inferred from the wording "...may have a... -->
<owl:Class rdf:about="Message">
<rdfs:comment>
A message can have at most one message description
</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#describedUsing"/>
<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">
1
</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
What follows are my personal observations as a participant in the process, and not remarks "from the chair:"
Perhaps it was unrealistic to charter WSA WG as a Recommendation track activity. It is not at all clear to me that the technology is mature enough or the industry politics stable enough to really come to an authoritative statement on the matters before the WG. Microsoft's withdrawl from the working group after it recommended chartering a Web Services Choreography group had the mixed effect of making it easier to come to consensus on controversial matters, but giving that consensus less authority in the industry. Perhaps if the group is rechartered, it should be considered more of a forum in which architectural issues can be discussed within the framework of an evolving reference architecture, and less of an attempt to "nail jelly to a tree" by coming up with a Recommendation on the architecture of the Services Web. (FWIW, I believe the TAG should do the same thing; the burden of trying to speak authoritatively on matters we understand poorly and are changing faster than we can realistically understand them opresses them too, as far as I can tell from a distance).
The process of defining slippery terms such as "service" or "Web services" is immensely frustrating and probably looks like pointless Scholasticism to many observers, but I think it was quite valuable. The main point of the WSA exercise, in retrospect anyway, was to find what Web services approaches really have in common across vendors, consortia, and paradigms. Several vendors have written nice whitepapers laying our their sense of the Web services architecture and the definitions of the concepts within it. Unfortunately, these are often edited or at least vetted by marketing departments, and marketing people are trained to differentiate rather than unify. Likewise, technology people tend to complicate, WSA tried to simplify.
The WSA document is rather abstract and seldom references specific technologies beyond XML, SOAP, and WSDL. I see this as a strength, although admittedly it is rooted in the necessity of reaching consensus among companies that have different perspectives on the specific specifications. Abstracting away the details can help prevent premature "blessing" of one specific approach, and disentangling causes from effects helps focus on what is really important.
For example, "Loose Coupling" is intrinsic to many definitions of SOA or Web services. It became clear to us during the WSA discussions that various architectural properties combine to produce loosely coupled systems, so loose coupling is an "emergent" property of Web services architectures. Some of the properties that combine to produce systems that are loosely coupled in practice include extensibility of message interfaces and protocols; asynchrony, which allows decoupling in time; statelessnes, which minimizes dependence on earlier interactions; etc.
The W3C chartered the Web Services Architecture (WSA) Working Group to describe the architectural principles underlying Web services that transcend vendor-specific concerns and uses. The working group has made significant progess toward a consensus definition of the core concepts and relationships that characterize web services. It has made more progress in aligning the architectural principles of service oriented architectures, Web services, and the Web itself, while noting the areas in which the principles of the Web and the Web services domain do not fully overlap. The WSA accepts that we operate in an environment where "One True Standard" is very unlikely to emerge even for limited domains; WSA offers a framework for dealing with diversity and evolution. Finally, WSA describes some of the ways in which the technologies emerging from the Semantic Web initiative can assist Web serivces developers. It begins from todays reality where humans provide the semantic "glue" that make Web services work, but envisions that this process that will become more automated, but slowly. In the short run, the WSA document aligns with the Semantic Web by noting that the document itself can be thought of as an ontology for Web services, and presents a formalization of large parts of the architecture using OWL, the W3C Web Ontology Language.
Clearly all is not rosy in the Web services community, and I believe that the WSA analyses have helped illuminate some of the more important challenges.
Handling diversity - It's clear that we're not close to having a single standard format/protocol for every "box" in the WSA Finding the right tradeoff between openness and standardization will be difficult. Industry / Organization politics makes this harder, but probably not as much as some accounts suggest.
Automating semantic-level features- The WSA document explicitly incorporates humans as the "programmers" who more or less hard code semantics into todays Web services. This is less that ideal; it would be desireable to automate the discovery of Web services meeting a specific business need and to more automatically resolve the subtle incompatibilities in business vocabularies between service producers and requesters. The W3C Semantic Web initiative has produced technologies such as OWL that may help here, and many proprietary efforts in this area are being tried by various vendors as well. It will be interesting to see how this all shakes out, or whether humans will remain as the only semantically competent agents in real Web services for the forseeable future.
Performance - There are increasing concerns that the standards-based, optimized for interoperability foundations of today's Web services put processing demands on Web services users that are somewhat difficult to meet with today's hardware (not to mention economic constraints). The W3C held a workshop to explore this topic in September 2003 http://www.w3.org/2003/07/binary-xml-cfp.html, and some participants gave papers showing an order of magnitude overhead of XML-based technologies compared to their proprietary and binary predecessors. While others argued that this is due more to the immaturity of XML processing code than the intrinsic inefficiency of XML, there is clearly a challenge here to find the right tradeoff between the interoperability benefits of the standards and the necessity of meeting real businesses' performance needs.
A final thought: Clearly Web services are "aligned with" the Web and XML, but the realities of building enterprise-scale services that meet strict reliability and security requirements while leveraging the Web's infrastructure and mindshare have produced tendencies to both subset and extend the core Web and XML specifications. For example, there is clearly a requirement for Web services to be protocol neutral (so as to accomodate the existing Message-Oriented Middleware infrastructure) rather than being tied to the core URI-aware FTP and HTTP protocols. Likewise, the performance requirements of mission-critical services have forced Web services developers to implicitly subset the XML specification (DTDs and everything defined in a DTD are forbidden in SOAP, for performance and security reasons), and to consider alternative serializations of the XML Infoset. These are all controversial at best in the traditional XML community. One can forsee both the dangers of fragmentation and the strengths of diversity in all this; I for one believe that the XML and Web technologies will be strengthened by the evolutionary pressures imposed on them by Web services.
  |
Design & Development by deepX Ltd. |