March 12, 2001
It it an exciting time for the distributed computing community. A combination of social and technical forces appears to be finally moving us towards the goal that some computing pioneers perceived over 30 years ago - a world where a network of collaborating programs can interact with each other through a common language, and a spectrum of devices from phones to automobiles to supercomputers will be able to share useful features with each other. And despite strong cases for systems such as CORBA, EJB, and DCOM, it appears that the momentum around simple XML-based protocols may overtake these more traditional approaches and form the backbone of such a world, in much the same way the web has grown into the standard for distributed human-computer interaction today.
The XML Protocol group is already attempting to guide the evolution of this space from the bottom up. From the group charter:
The goal is a layered system which will directly meet the needs of applications with simple interfaces (e.g. getStockQuote, validateCreditCard), and which can be incrementally extended to provide the security, scalability, and robustness required for more complex application interfaces.
This goal is a laudable one, and although the current XML Protocol group hopes to define the foundation of such a system, many factors which are recognized as crucial for widespread acceptance and interoperability have been declared explicitly out-of-scope. This workshop brings the minds of the membership directly to bear on these topics, something Allaire has been hoping to see occur since early last year.
Our focus as a company can be summed up simply - empowering people with technology. We very much believe the combination of several factors makes Web Services a technology better suited to that focus, and to building the service-oriented web, than other distributed computing systems such as RMI or DCOM.
This brief paper will describe these areas, explain what we believe is needed to better achieve the promise of universal interoperability, and finally suggest a role we hope to see the W3C fill in the evolution of Web Services. We assume familiarity with all the basic concepts behind SOAP and XML Protocol.
We can sum this up with three statements.
1. Web Services are web-like.
2. Web Services are orthogonally extensible.
3. Adoption of Web Services is selectively complex.
The web, by standardizing some very basic technologies (HTTP, HTML, CGI) and emerging at precisely the right time, has achieved a truly wonderful goal - allowing practically anyone, regardless of their operating system or programming ability, to share information. In a similar way, we hope that XML-based protocols, with their simple core, have emerged at the right time to move us towards the world we mentioned in the introduction.
Some of the powerful features which hide behind the web's simple interface, and which have enabled it to scale as well as it has, include caching and proxies. SOAP, and XML Protocol, integrate the concept of "intermediaries" into the base level protocols. Building networks of services with these tools will naturally encourage the same sorts of "horizontal extensibility" (adding features and functions by inserting nodes into the message path) we see today on the browser-based web.
The design of orthogonally extensible protocols is geared towards distributed evolution. This means that one company can create, for instance, a security extension for their products, and they are not required to hold up their development to go through any bureaucracy about standardized element names, message patterns, etc. This is fabulous news for developers. However... while orthogonal extensibility is one of the greatest strengths of SOAP (and the forthcoming W3C XML Protocol), it is also one of the factors which threatens the very promise of the technology - interoperability. As has been discussed frequently, entities who wish to use SOAP/XML Protocol to achieve business-level connectivity with partners will certainly require services such as security, reliable messaging, and non-repudiation, all of which can be built as "vertical" extensions (extension by adding 'modules' into protocol messages). However, if no leadership is present as the growing developer community builds their systems, we are going to end up with twenty different "message-id" headers, and thirty different authentication modules, making it a lot more difficult to achieve the web-like "anyone can talk to anyone" ideal. We need to find a good balance point between providing tools and standards to make engaging the service-oriented web easy, and also encouraging innovation. (hint: this is where the W3C comes in)
Allaire's focus since our inception has been making the web easy to build. We wanted to make sure to provide tools that allowed web developers to get their job done without requiring them to understand a huge breadth of technology to get started - but also enabling them to build systems which reflect more complex requirements such as scalability, robustness, and component-based development. XML Protocols fit in well with this philosophy; use-cases that have come up in the community range from "a cellphone with no real XML parser wants to query the temperature from a weather server" all the way up to ebXML-like cases for implementing a legally binding business contract with a partner across the net.
XML is great technology - it enables flexibly encoding almost any kind of structured data in a way which doesn't mandate any particular parsing, language, or operating system environment. However, unless both the sender and receiver of a given chunk of XML know a lot about what to expect, it doesn't buy us a whole lot in terms of interoperability (in a way, supporting XML is rather like saying "we support ASCII"). In the same way, XML Protocols are a very effective and simple model for inter-application communication, but unless the applications involved know a lot more about how to talk to each other than just "use SOAP", it's unlikely they will be able to fulfill the benefits we discussed in the last section.
At a minimum, applications must know:
Now, as discussed in the "orthogonal extensibility" section, all of this can be created by individual companies. But that wouldn't really buy much for the world, as every company would need to custom-build systems to talk to every other company who has a different model for these areas.
It is our strong belief that if Web Services are to succeed, some higher-level standards need to appear, especially in the areas of service descriptions, service discovery, and basic enterprise-level extensions such as security, reliable messaging, and transactionality.
So what should the W3C XML Protocol Activity be doing about this growing tide? There are two roles we see the W3C taking in this space: As a provider of standards, and as a source of "best practice" information.
We would suggest that at least two new working groups be considered, to work in the following areas:
We would also suggest that the W3C investigate how to provide an arena for collecting and communicating de facto standards which arise in the community to fill the gaps which may be perceived in the initial XML Protocol specification. These areas include further transport bindings, binary data transfer, etc.
Finally, we hope that the W3C will strive to provide guidance and best practices in this space, as it has before with HTML/HTTP.
The basic message is this. We must allow, and encourage, innovation in the Web Services space. But if we hope Web Services to evolve into a true platform for a global network of applications, we also must provide a richer and more solid foundation for interoperability. The W3C's experience and leadership in growing the web make it the right forum in which to bring together the thought-leaders in this area, and to provide the right set of community standards and guidance to achieve a Web Service platform which empowers developers at all levels.
We believe this is a very exciting time for the distributed computing community, and the potential of the service-enabled web is enormous. We at Allaire look forward to helping it happen.