March 2001
Web Services, as currently envisioned by the IT community, are promising to combine the benefits, but avoid the drawbacks of today's World Wide Web technologies and component object technologies. The World wide Web is currently mainly used for (almost) unlimited interactive human access to documents and applications over the Internet. While the Web is based on open and simple Internet standards, today's object technologies are often based on proprietary, heavy weight standards, are relying on complex LAN infrastructure and are thus not well suited for the Internet. Interoperability between different component technologies is a serious problem. This paper describes Software AGs vision on Web Services - what problems they should solve by which means in order to be able to to provide the foundation for new generation application technology.
Web Services are programmable, distributed application components accessible on the web using solely standard Internet protocols. As opposed to the current 'document web' which is specialized on human interaction, Web Services are designed to be accessed by programs to form a new application architecture, the 'application web'. In our view, a Web Service application is built from three major Web Service components:
It is essential for the acceptance of Web Services that they are based on established Internet infrastructure. This in fact imposes the usage of of the HTTP, SMTP and FTP protocols based on the TCP/IP family of transports.
XML (and related technologies like namespaces, schema, stylesheets, transformations) has become a widely accepted standard for describing content exchanged over the Internet and is thus an ideal format to be used by Web Services. However, as there are many other widely used data formats which are not XML and also aren't easily convertible into XML, a concept for combining both XML and non-XML data is required.
The format of messages exchanged between Web Services clients and Web Services should be vendor neutral and should not carry details about the technology used to implement the service. Also, the message format should allow for extensions and different bindings to specific transport protocols. SOAP and ebXML Transport are specifications which fulfill these requirements. We expect that the W3C XML Protocol Working Group defines a successor standard.
Web applications require sound security concepts including encryption, authentication and authorization. There are are industry standards available (e.g. SSL, digital certificates) to solve these demands independently. However, we believe that security issues cannot be handled fully outside the scope of a Web Services messaging protocol (like e.g. SOAP does). This would lead to different, non-compatible solutions, compromising the basic ideas of web services.
Serious Web applications require transaction concepts. Traditional two-phase commit transactions which use to be short lived are not well suited for Web Services. What's required is a concept which fits well for distributed transactions. Defining such a system is without any question quite a challenging task.
As the main Internet protocol HTTP is per se stateless, Web Service application need to handle state in a different manner than typical client server applications which maintain state-full connections. This implies a programming paradigm shift towards 'stateless (client) programming'.
In order to avoid the need for Web Service clients to 'hard-wire' all details about the communication with a given Web Service, it is essential that Web Services provide implementation neutral descriptions of their interfaces. Then it is possible to make use of tools and runtime libraries on the client side to generate and validate messages. The Web Service Description Language (WSDL) is a promising candidate for a standard service description language.
Last but not least, Web Service registries are an important building block in a flexible and modular Web Service application architecture. Web Service providers store information about themselves and the services they are offering in a Web Service Registry. Web Service clients can then discover available Web Services and get detail information by searching the registry. Universal Discovery, Description and Integration (UDDI) is a candidate standard for Web Service registries.
We expect that the W3C XML Protocol Working Groups succeeds in defining a standard XML protocol (replacing SOAP and ebXML TR) which is widely accepted by the industry. In our opinion, issues like security and transactionality should also be part of the groups activity. We would also like to see W3C standardisation (or at least integration) efforts on Web Service descriptions (e.g. starting with WSDL) and Web Servide Registry (e.g. starting with UDDI) specifications.
Web Services are composed from three major Web Service components: Web Service clients, Web Service registries and Web Services themselves (a Web Service Registry is in fact itself a Web Service, and a Web Service can also be a client of a different Web Service). Web Service providers are publishing information about themselves and the offered services in a Web Service Registry. A Web Service should provide a service description defining its interfaces. All Web Service components communicate via a standard (XML-based) messaging protocol which is transported over standard Internet transport protocols.