The Web services paradigm promises enterprises a flexible and robust infrastructure for assembling loosely coupled systems. Organizations can expose existing functionality to trading partners inside the company, within a consortium, and across an industry. Interfaces are well specified using WSDL, and communication is standardized as SOAP messages.

Vendors are rushing to release technology previews showcasing SOAP and WSDL support. These previews are great for learning the new paradigm and implementing toy Web services. For the Web services paradigm to thrive, these technology previews must mature into useful platforms supporting real applications. Press releases already tout the traditional enterprise infrastructure touchstones of performance, scalability, reliability, and security. But many current implementations are limited and don't have the architecture required to support mission-critical systems.

The Web services container provides a first-class environment for deploying, running, and managing Web services. In this article I present the requirements for a Web services container, which addresses the weaknesses of currently available SOAP implementations. The container embodies a collection of features necessary for substantial real-world use of Web services products. Its successful implemen-tation is a prerequisite for products that plan to deliver enterprise Web services features.

Web Service Infrastructure Requirements
Web services will establish new connections between widely disparate computing environments. The industry has done connectivity before and many companies know that enterprise connectivity mandates a certain set of requirements. Experienced vendors will bring to the market Web services products that perform and scale well, and are reliable and secure. But even these traditional product evaluation points have Web service-specific implications:

• Performance: The standard requests-per-second metric is not critical at this stage. Web services hold the promise of automating manual connectivity and replacing e-mail, manually constructed chron jobs, ftp scripts, and even proprietary or custom data exchange over HTTP. The critical resource is not processor time or bandwidth; it's systems development expertise. To be successful, a Web service infrastructure must facilitate radically faster implementation and deployment than current approaches. As the paradigm is adopted and becomes widespread, traditional system throughput metrics will be more relevant. Note that the most applicable measurements won't resemble the test-lab metrics reported by middleware vendors. Rather, look to see quality of service and performance measurements based on real deployments and designed to parallel the numbers collected by application service providers. Sustained daily transaction volume, median response times, and hourly data flow rates for a deployed system will be better reflections of the real-world performance that can be achieved in a widely distributed environment that includes public networks and geographically distributed systems.
• Scalability: Most current Java Web service implementations are constructed using an existing HTTP server infrastructure. Most are simple servlet code generation systems. Web servers and servlet engines have been carefully tuned over the last few years to provide good scalability across many connections and lots of hits. Unfortunately, these are the wrong metrics. Most Web pages are 10-20k in size. Most HTTP posts come from HTML forms and are 2-4k. The toy Web services published today include mortgage calculators, stock quote services, and mortgage calculators. These demos won't stress scalability. However, when Web services are deployed throughout the enterprise, they'll be carrying messages of 10 or 100 megabytes in both directions. Servlet engines will need to be re-tuned to carry this kind of payload.
• Reliability: Web services sessions are currently stateless. This makes failover and other fault tolerance measures relatively easy to implement. However, sophisticated Web services applications will be constructed and many will require stateful connectivity. Vendors like IONA that have developed clustered, fault-tolerant J2EE, JMS, and CORBA implementations will leverage this infrastruc-ture to deliver the same features to Web services customers. In the near term, look for Web service products to deliver these features by leveraging transports that are more sophisticated than HTTP. JMS, TCP, SMTP, and even FTP come to mind. Enhancements to HTTP, like the proposed HTTPR, will improve the reliability of what is sure to be the most common transport in the short term.
• Security: This one is obvious, but not trivial. It's one thing to let a customer send you a credit card number over the Web. Sending part of your accounts receivable database to a collection service is something else altogether. A security breach that effects one transaction implies radically different liabilities in these two examples. Another crucial point: current business-to-business and enterprise integration solutions connect a relatively small number of well-known participants. As Web services become common, the permutations of participants and service offerings will explode. While authentication will be required, seamless authorization and credentialing system integration will be essential.

Web Services Characteristics
Most Web services will be constructed to expose existing functionality to new partners. Web services will be gateways with interfaces tailored to specific usage patterns or even specific partners. Where IT systems are updated slowly with new features exposed quarterly, Web services will be constructed using eXtreme Programming techniques and updated biweekly. Web service platforms must support rapid, seamless rollout of new or improved Web services. Furthermore, the most robust platforms will support multiple versions of the same Web service.

In these early days the Web services infrastructure itself will evolve rapidly. IT systems may upgrade their infrastructure yearly, but groups implementing Web services will want to move immediately to the latest release of their chosen Web service platform to gain improved interoperability, new data type support, and enhancements in the enterprise characteristics listed above. It must be possible to upgrade the Web services platform with minimal impact on running services.

Many Web services will be implemented using HTTP as the SOAP transport. However, some early adopters will require (or discover that they require) the high quality of service that can only be delivered in the short term by using a more mature transport.

Standards-based Web services won't be constructed by hand, but rather assembled using an infrastructure product such as IONA's XMLBus. This is possibly the most significant benefit to be gained from WSDL, SOAP, and related JCP initiatives. Proprietary products have simmered for several years now and IT organizations have been manually building a few Internet-based services with some success. For example, the U.S. Postal Service has an offering at www.uspswebtools.com. These early Web services efforts have been relatively few because implementation requires a high level of skill, knowledge of cutting-edge technologies, and often a willingness to commit to a vendor's proprietary solution. The latter characteristic is perhaps the most painful, because efforts not based on standards offer no hope of interoperability.

The maturing Web services standards let vendors construct and promote competing products that are interoperable, comparable, and offer enormous developer productivity gains. They allow IT organizations to benefit from this paradigm without vendor lock-in and without developing the high levels of expertise required to build a custom solution. In short, the standards are central to the creation of a new infrastructure market. Successful projects will employ complete solutions that deliver an easy-to-use infrastructure for developing and deploying Web services.

Web services are new and not widely understood. Most IT organizations have no experience with or knowledge of the related standards. Widespread adoption can't be achieved by small groups of specialized consultants. How is it possible that this new paradigm will become common infra-structure?

The answer is that current IT staff will expose existing systems as Web services. These developers have an intimate understanding of existing systems and in many cases a solid understanding of distributed development or systems integration. This current skill set is largely sufficient. Successful Web services products won't impose a substantial learning curve. Instead, they'll deliver easy-to-use GUI tools and clear documentation to facilitate rapid successful use of the paradigm without requiring an in-depth knowledge of arcane marshalling details and new APIs.

Current SOAP Implementations
Most serious SOAP implementations on the market today are Java-based and have leveraged all relevant parts of the Java platform. They are J2EE or, more specifically, servlet applications. A single servlet or JSP, sometimes called a SOAP listener, receives incoming SOAP requests. Requests are parsed and dispatched to application logic implemented in local Java classes, remote EJBs, or on other platforms. Some variations generate a unique servlet for each Web service. This servlet and an associated runtime library must then be deployed into the host environment.

The benefits of these approaches include ease of implementation, rapid time-to-market, and a time-tested platform. This architecture, however, suffers from a serious flaw: these SOAP implementations are presented to users as J2EE applications rather than as enterprise platforms for distributed computing. In this context, SOAP message handling is a second-class addition to a platform and not a platform itself. An HTTP servlet-based implementation is subject to the following additional flaws:

• The SOAP implementation architecture is specific to the HTTP protocol. As new protocols are added, users may not be presented with a consistent view of their Web services. It may, for example, require several different steps to activate a single Web service on different protocols. In addition, the interfaces exposed to the Web service implementation are likely to be transport-specific.
• Class version conflicts between individual Web services, the SOAP servlet, dispatchers, and the application server will be difficult and awkward to resolve.
• The deployment model requires that the application logic behind a Web service be visible to the host application server. This often requires that classes and libraries are included in the classpath, which means that the application server must be restarted to deploy a new Web service.
• Web services consist of a collection of configuration data, WSDL, generated code, references to application implementation, and possibly SOAP dispatch code. The developer must correlate these different elements and manually deploy them in a configuration acceptable to the SOAP servlet. This architecture does not provide for bundling these resources to allow reliable deployment of a tested Web service to a production environment.
• Web services require unique management interfaces. Listed alongside 800 deployed servlets, a Web service servlet will not be clearly identified as a unique and powerful resource to be carefully administered.

A Web Service Container
A product capable of supporting projects with the characteristics listed above will provide a first-class environment for deploying and running Web services. A "Web service container" is under development and has three primary characteristics:

• Ubiquity: Containers will be imbedded within a wide variety of platforms so that a vendor's Web services solution can be made available to virtually any project. Containers will be constructed to reside within an enterprise's existing applications. An analogy might be helpful: the Java virtual machine can be described as a hardware platform. Application servers are operating systems running on this platform. The Web service container is analogous to a network layer that facilitates communication between disparate systems. A critical feature of viable Web service containers is support for many host environments. The Web service container is not simply an extension to J2EE. Hosts will, of course, include major J2EE implementations but containers must also run in enterprise integration servers, message brokers, CORBA servers, and even proprietary environments developed by IT organizations. This ubiquity is necessary if functionality hosted on existing systems is to be exposed as Web services.

  To facilitate rapid evaluation and adoption by potential customers, containers will also be capable of running standalone using lightweight or reference implementation host environments. These standalone versions will likely evolve into full-fledged SOAP Servers. In addition to multiple host environments, the container will support multiple protocols. Most Web service implementations currently support HTTP. Look to see the industry leaders extend implementations to support JMS, SMTP, TCP, and other common delivery vehicles.

• Usability: Management interfaces and JMX instrumentation will facilitate deployment and administration. Graphical Web service builder tools will facilitate the assembly of Web services from existing functionality. The builder environment will be integrated with the container to facilitate rapid round-trip build, deploy, and test cycles. Savvy vendors will produce tools that are approachable by administrators and analysts who don't have deep systems engineering backgrounds.
• Consistency: Java-based HTTP SOAP dispatchers are frequently implemented as servlets. They utilize third-party class libraries to manipulate XML, introduce proprietary code, and maintain state within the servlet environment. Functionality to be exposed as a Web service is typically contaminated by these components. Web service containers will isolate application functionality from the container's implementation and host peculiarities. Further more, containers will provide interfaces that allow services to participate in the service life cycle and access the runtime environment. As the container is extended to support additional hosts and transport mechanisms, this environment must be implemented consistently.

Installation
A clean installation process is a hallmark differentiator of products from frameworks and technology previews. Web service containers will be designed to install directly into running host application servers without changing the host environment. Containers that force XML parser upgrades, mandate specific versions of open source code, or require any changes in the classpath or executable path are unacceptable. IT environments are complicated already and containers can't introduce the possibility of conflicts.

Once installed, the container's functionality will be tightly integrated and appear as a new feature of the host environment. When the host is running, the container is running.

Sophisticated containers will also provide for in-place upgrades to accommodate the rapid evolution of the platform. Users will be able to upgrade the Web service container while it's up, running, and servicing requests. The running services will immediately benefit from a new version's improved performance, scalability, or interoperability. New services can be developed that leverage the new version's additional features.

Build
Web service builders that allow systems analysts to assemble new services will complement containers. Business integration vendors will push toward the ideal no-programming model by delivering builders that support increasingly sophisticated data flow and type mapping specification tools. The builder and container will be tightly integrated to allow rapid round-trip build, deploy, and test cycles. A good test of this integration is the degree to which the builder supports the expression of different mapping choices. Robust containers will allow, for example, a Java Date to be mapped to an xsd:dateTime or let a user extract the year and map it to na xsd:short. An integrated builder will support these container options.

Containers will complement the builder's GUI-based Web service assembly paradigm with programming APIs. Vendors are working to standardize the critical APIs through the JCP process, but don't expect Web service portability any time soon.

When evaluating containers, be wary of systems that offer only part of this picture. Products that attempt a complete no-programming approach and eschew all APIs have no safety net for the inevitable GUI shortcomings. Conversely, products that can't automate the construction of even moderately sophisticated services offer little in developer productivity enhancements and will require extensive Web services expertise.

Deploy
Containers will introduce some form of bundling that couples all materials required for a service. This bundling will likely be accomplished through a zip archive similar to J2EE WARs and EARs. As with the J2EE environment, the purpose of this bundling is to allow for atomic deployment of individual service implementations and to isolate the impact of deploying a new or modified Web service.

Deployment must have no effect on other Web services and other applications running in the host environment. It must never be the case that a newly deployed Web service disrupts operation of the underlying IT application. Under no circumstances should deployment require a restart of the Web services container or the host application server environment. It must be possible to deploy and run a service in a variety of settings without re-bundling. Don't expect Web service archives to be compatible between vendors, but do require that a vendor support the same bundling on all platforms and across all protocols.

Container vendors will provide tools that facilitate assembly and deployment of Web services specified during the build process. Sophisticated implementations will let users simultaneously deploy bundled Web services to containers running in multiple host environments and supporting different transport protocols. An acceptable platform must support live update of running services.

Run
Products that are based on a container infrastructure will support bindings to multiple existing transports. This is a key differentiator. Current HTTP servlet-based technology previews and frameworks aren't designed to support JMS or TCP. Even if your first Web services product doesn't require a fault-tolerant transport, don't make the mistake of choosing a product that won't support these needs in the future. As with any new paradigm, look to companies that are investing in a long-term infrastructure and not flashy demos.

Manage
Deployed Web services will be a critical element of IT operations. They must be managed as first-class elements, not as special purpose servlets. Container-based implementations will support complete management solutions probably based on JMX. Management capabilities will include the ability to activate and inactivate services as well as modify tracing levels and view service statistics. Management will likely be integrated with deployment and enterprise host features like clustering, such that through an administration console, running containers and their associated services can be replicated for scalability and fault tolerance.

Conclusion
No vendor will deliver all of these features in the first releases. But when evaluating platforms, ask questions about the infrastructure. Ensure that your pilot projects succeed not just in constructing a proof of concept, but in evaluating the platform's suitability for the next quarter's deployed system and next year's mission-critical initiative. The Web service container features described above will be difficult to achieve without a suitable architecture. Use them as yardsticks to measure the progress your vendor is making toward a reliable platform.

Author Bio:
Ben Bernhard is the IONA XMLBus engineering manager. He is responsible for the product's technical directions and implementation. The XMLBus includes a Web Services Builder that allows rapid construction of Web Services from existing systems and the industry's first Web Services Container. ben.bernhard@iona.com