Web Services Position Paper
Lotus Development Corp.
March 10, 2001
A number of important technologies have already been proposed as the basis for further W3C work on Web Services. In addition to the ongoing work on XML Protocols  and the SOAP technology on which it is based , the W3C has acknowledged formal submissions relating to protocol attachments , and to security based on digital signatures . Undoubtedly, many other interesting proposals will be aired in the position papers submitted to this workshop.
Rather than add to the list of technical proposals, this paper discusses goals for the W3C workshop itself, and some other issues that seem important in preparing for the W3C to play a broader role in Web Services architecture.
Agreeing on The Problem to Be Solved
The term "Web Services" has come into vogue recently, but the range of meanings attached to it has been sufficiently broad as to cause confusion. We at Lotus believe that among the uses of the term is one that represents a compelling new approach to building applications on the Internet. It was in support of this particular vision that Lotus participated in the development of SOAP and now of the XML Protocol, and it is the same vision that motivates our support of additional work by the W3C on related technologies. Nonetheless, until all of us in the W3C come to a shared understanding of the needs and opportunities, our technical initiatives are likely to be poorly focused. We therefore recommend that a key goals of the Web Services workshop should be (1) to work toward a clear focused concensus on the essential characteristics of the Web Services architectures that we propose to purse and (2) to ensure that specific projects undertaken by the W3C be focused to provide a compatible and consistent framework to enable that specific view of Web Services. The remainder of this section outlines the Lotus view of Web Services and their significance.
The primary success of the web to date has been in supporting interactive access by people seeking information, or using applications. We and some others in the industry use the term Web Services to refer to a new and complementary architecture, in which applications are built to communicate with other applications over the Web. In this sense, applications provide services to each other. Viewed in another way, applications are built of course grained components which are themselves applications, accessible through RPC and/or messaging interfaces on the Web.
The role of the Web is central to this vision. Earlier approaches to application interconnection were essentially point-to-point. A typical EDI connection, for example, would be planned months in advance, and would provide a robust durable connection between just a pair of applications, typically in two separate organizations. Web Services suggests a much more dynamic and fluid model of interconnection, one that provides for applications the same flexibility that the Web has already brought to human users. Purchasing applications can be coded to connect dynamically to new suppliers, possibly selected from a continually changing directory of approved sources. Fulfillment applications can establish dynamic connections to shippers, and so on. This dynamic model of interconnection on a global scale presents new and unique challenges.
Web Services thus depend on the ability to provide appropriate security, reliability, and manageability to an extraordinarily broad range of organizations, dispersed throughout the world. The nature of the applications suggests that transactions, when used, will often be long running. Security mechanisms must interconnect rather than encapsulate systems which themselves use a broad range of security technologies. Indeed, there is not one but a range of security problems to be solved: protecting information from those not authorized to access it, authenticating participants, providing non-repudiation for certain activities, ensuring that messages are delivered intact, and so on. All of this must be done for applications which connect to each other dynamically and involving a continually changing set of organizational relationships on a global scale.
We encourage the W3C to invest in developing a compatible set of core technologies that will enable the development and deployment of these types of Web Services applications.
Some have used the term Web Services to define other application architectures. For example, the term has been applied to the development of modular interactive services that can be composed for end-users on a single display or portal. While such developments are also interesting and important, we recommend that they be identified by a different term, and that they not be the focus of W3C work on Web Services. In any case, as noted above, clear concensus on goals and core use cases is essential.
Many of the technologies needed to implement Web Services are also useful for other purposes. SOAP, for example, has also been used as a lightweight substitute for distributed object protocols within individual organizations. There will no doubt be temptations to build transactions, security, and other services focused not just on the needs for web scale interconnection of services, but also for a variety of other purposes. We believe that the W3C must focus squarely on interconnection technologies for use on the web itself, and avoid being diverted into the many other useful and related activities that suggest themselves. Of course, when modest additional effort can yield a superior technology with broad application, or when success on the web involves technologies behind the firewall too, the W3C should take the trouble to do it right. Nonetheless, early experience in the XML Protocol work group suggests that too broad a set of goals and use cases can be detrimental to focus progress on shared goals. Explicitly delineating and articulating our goals is vital.
Lotus Development supports initiation of activities in the W3C that will complement the existing XML Protocol work with a core family of related technologies to enable ubiquitous implementation of services on the World Wide web. These activities must be focused on a core shared vision for the range of applications to be supported and the practical constraints under which these applications will be deployed. Our work to date on XML protocols has shown that workgroups are likely to be composed of participants with a broad range of experience, but also differing assumptions about which problems are interesting to solve. Coming to consensus on our goals will be as important as basing our work on appropriate technologies. We recommend that the Web Services workshop be devoted to developing consensus on the overall Web Services model and goals, as well as to exploring particular technology initiatives that the W3C might undertake in support of those goals.