W3C Web Services Workshop
Position Paper

Preparing for the Web Services Paradigm

Brian D. Eisenberg
[email protected]
Program Director, eBusiness Technologies
DataChannel, Inc. http://www.datachannel.com

March 5, 2001

Introduction

Currently, the application space is moving away from tightly coupled, monolithic software applications, to systems of loosely coupled, dynamically bound components. This shift is being fueled by the rapid, and often chaotic evolution of Web Services standards and technologies. Over the past 6 months, key industry players have been working to advance these standards and technologies that are bringing about the next paradigm shift. One only has to look as far as Microsoft's .NET Platform, IBM's Web Services strategy, the UDDI Project, ebXML, and other wide-sweeping initiatives to see how Web Services are transforming the application environment. We are witnessing a migration away from client/server-based applications to the delivery of more precise application logic exposed as modularized Web Services that can be created, published, discovered, and invoked on the fly.

To prepare for the Web Services paradigm, companies of all sizes need to carefully assess the current state of affairs in the Web Services arena. As the technologies evolve and are standardized, it will become increasingly important for companies to put in place a plan for integrating and migrating their core competencies to the Web Services model. This process spans virtually all components in today's modern enterprise - from the network and IT infrastructure, to back-end legacy applications, and finally to bleeding edge Web Services. Further, as Web Services platforms grow out of their infancy, companies will need to develop comprehensive plans for supporting their legacy systems, while at the same time, embracing these new and exciting technologies. This paper explores some of the issues that companies should consider when developing their Web Services strategy.

A New Paradigm in Application Development?

In this new distributed, service-based environment, transactions in the form of XML message exchanges may be automatically initiated by independent calling applications (not necessarily a browser). Next generation Web Services will be described, published, discovered, and invoked at run-time in a distributed network environment (generally, the Internet). This model will allow for just-in-time integration and deployment of modular bits of application logic for performing specific business tasks.

Unlike today's software packages, which are typically made available through licenses based on a per-user or site-pricing model, Web Services will most likely be licensed according to a "pay as you go" subscription-based pricing model. This has the potential to significantly reduce the IT-related costs for supporting software within the enterprise. Rather than having to buy monolithic software packages, wherein users might only use a fraction of the whole package, the Web Services model allows users to pick and choose the precise bits of functionality that are needed to perform a specific task. Additional savings may be realized from having the ability to invoke and dis-invoke Web Services as needed. This may be a compelling reason for companies to evolve support for the Web Services model.

Important Issues to Consider in the Web Services Paradigm

In the emerging Web Services environment a number of important issues need to be taken into consideration and should be explored by the various organizations currently working on Web Services standards and technologies. These issues include:

Scalability and performance
Security
Reliability and quality of service (QoS)
Legally binding service level agreements
Error handling and notification

Scalability and Performance Questions

· What happens when 25,000 users concurrently hit a single Web Service? An aggregate Web Service?

· How will IT departments support an aggregation of Web Services within their enterprise infrastructure when the individual Web Services may be distributed across the Internet from n number of providers?

· How will Web Service providers efficiently manage their "clients"?

· What kind of network and IT infrastructure will be required to support Web Services from both the provider and requestor endpoints?

Security Questions

· Should employees be allowed to pull down any Web Service from a public registry or is there a need to implement some type of access control to restrict access?

· How will Service Providers effectively secure the Web Services they expose?

· In an aggregate Web Service scenario (e.g. a full blown B2B supply chain service that spans multiple partners and/or customers), how will information being sent across the wire be secured in such a way that processing intermediaries only unpack and process information that relates to them?

Reliability and Quality of Service (QoS)

· What guarantees do I have that a particular Web Service will be accessible 24/7/365?

· What happens when a Web Service fails? Who do I call? How do I figure out where the problem lies?

· What happens when a complex aggregate Web Service fails? Who do I call? Who do I blame? Should I trace the packet (message) and see where it stopped?

Legally Binding Service Level Agreements

· What kind of service level agreements do I need to put in place to ensure the highest level of quality?

· What are the legal ramifications for the Web Services paradigm?

Error Handling

· What happens when a Web Service fails?

· What kind of notification will I receive?

· How should I configure my black box processing applications to deal with Web Services failures?

· What kinds of error reporting mechanisms are needed to properly track the flow of Web Services XML Messages.

· How should I deal with rollback scenarios and bottlenecks that may arise in an aggregate Web Service when things go south?

Converging on Standards, Competing on Implementations

Over the past several years, we've witnessed the proliferation of XML-related standards & technologies. After the standardization of core XML standards, which typically fall under the auspices of the W3C, many vendors’ forged head with the vertical application of these core XML standards. To a certain extent, this resulted in the proliferation of XML-based vocabularies (DTDs and Schemas) along vertical industry segments. This resulted in "silo systems" and vocabularies that were used within specific vertical industry segments. Vendors in the XML community eventually realized that the continued proliferation of purely vertical-oriented applications of XML standards and technologies were not beneficial to the Internet Industry. It was generally agreed upon that some level of convergence was needed to help bring XML into the mainstream. To address these issues, key players in many of today's standards and technology initiatives (ebXML, SOAP, XML Protocol, UDDI, OASIS) are now working more closely with one another to foster convergence and interoperability.

As the W3C expands its coverage of Web Services standards and technologies, it will be critical to establish relationships with the various industry organizations and vendors that are developing standards and technologies in the Web Services domain. Any future activities and/or working groups that are chartered under the auspices of the W3C should coordinate their activities with these groups to achieve the highest level of composability and interoperability. Additional liaison activities should seek to minimize the amount of overlap and duplication of Web Services standards and technologies.