Web services promise many advantages, such as faster development time, the ability to link disparate business systems together, enhanced software modularity, and increased congruence between business process models and computational architectures. With these in mind, many organizations are considering a Web services-based architecture, but as with any new endeavor, initial implementations meet with practical challenges.

Like any new technology paradigm, the goal of utilizing and adapting Web services into a system is to provide value with a low total service cost (TSC). Establishing a concrete TSC is futile because each organization will use its own metrics for determining the total service value. The proper calculation of a TSC, however, will include certain base factors: total number of connections, length of time it takes to integrate, length of continuous uptime, and appropriateness to business needs.

To achieve this goal, organizations need to change the way they've traditionally thought about software development. The value of a Web service exists in both the service and the network it lives on. That's why the success of a Web services-based architecture will lie in the design, wiring, and deployment of the system.

This article provides a roadmap to the successful implementation of a Web service-based system. It focuses on the technical issues, including network latency and multiple points of failure, as well as business issues, such as the legality of transmitting data to outsourced Web services and the challenge of dealing with a larger number of software suppliers. With proper planning, the new Web services architecture can provide companies with reduced development time, enhanced software modularity, and a radically reduced total cost of ownership.

The Problem of Network Traffic
A major technical issue in deploying Web services is the performance of the network. Web services generate heavier network loads than traditional client/server architectures. A Web services-based application connects to many services from different servers and even from multiple locations. Any connection between services, which reside on different machines, will increase traffic. A more subtle increase is derived from the nature of the communication protocols used by Web services.

In a client/server environment, messages between machines could be custom-designed and binary-based and, therefore, relatively terse. But XML-RPC and SOAP, the protocols commonly used by Web services, are heavier communication protocols because of their reliance on XML, and they increase traffic. Additionally, traffic that leaves the local high-speed network may use a slower Internet connection and may require encryption, which consumes more resources and increases the total payload size. Although none of these costs can be eliminated without sacrificing the abstraction and distribution advantages of Web services, proper planning and design will minimize the impact on the system as a whole.

Smart Service Design
There are several approaches to alleviating high system costs, the most attainable being smart service design. Traditionally, architectures that used a large array of small, refactored components were generally preferred because they allowed systems to grow and change more easily with fewer development dependencies. In the new Web services architecture, not every component needs to be a Web service. The power and value of Web service technology is to connect medium-sized computational service offerings into large-scale computational service offerings, while minimizing the maintenance and scaling costs of running the services in production environments.

Using services that are too small bloats resource consumption, but services that are too large negate the power of composition. When designing a Web service, selecting the optimal size of its problem domain will provide the maximum TSC. Another imj portant design decision is the message content. Using apropos data structures will reduce the amount of extraneous and duplicated information sent across the network. Sending only the information that is absolutely needed not only reduces the size of the messages but also enhances the flexibility and reusability of the service.

When large records need to be sent and the service performs multiple operations on them, it may be worthwhile for the service to cache the data at the request end point. Subsequent requests could then send a reference to the data instead of the entirety. Designing your system with a reasonable number of medium-sized services using well thought-out messages is the most effective way to use the power of the network without being overrun by it.

Connectivity Solutions
The complexity brought on by a Web services architecture manifests itself most directly in the proliferation of network interconnections. Managing the unavoidable increase in the TSC from this architecture requires a two-pronged approach: selecting the correct connectivity solution and the appropriate distribution architecture.

In selecting the correct connectivity, attention should be paid to the type of network connections used. Given that a high-speed LAN is always more preferable to a distributed WAN, a coordinated hosting facility provides a compelling business case. This facility is a host that specializes in Web services and has hosting agreements with many different Web services vendors (see Figure 1). All the services hosted at the coordinated facility can communicate over a high-speed LAN. Current hardware can move local data quickly, rendering the network portion of the TSC close to zero. By having data travel only on physically secure pipes behind protection systems (e.g., firewalls, proxies, etc.), the need for encryption is reduced, easing the cost and complexity of regulatory compliances.

Systems handling sensitive information not only have to maintain tight physical security but complex business practices as well. Trustworthy Web service hosts and consolidated providers could offer the required compliance in these instances. This is especially important with Web services since data may visit and be exposed at multiple locations before processing is complete.

Clearly, the technique of coalescing Web services into a single location provides great advantages in terms of network usage, but it's not always practical. One facility may not have agreements with all the service vendors a system uses. Multiple facilities may be desirable for redundancy, or maybe a special location handles sensitive information while a cheaper facility is used for the other services in the architecture. Due to the number of possible service fault points created by a geographically dispersed Web services architecture, a close inspection of the TSC must be made.

The use of leased lines can offer many benefits of a single facility while providing the advantages of distributed facilities. Since the data travels on a dedicated connection, the need for encryption is lessened, keeping message sizes small. Leased lines also have high bandwidth. The other major option is to connect across the open Internet, which is easier and cheaper, but also slower, and requires more operational diligence due to possible security, transactional, latency, and transmission concerns.

Services Hosted in Same Location
When deciding how services will interconnect, consider performance requirements of the entire system in terms of maximum acceptable latency, the budget for deployment, the need for security, and the desirability of outsourcing hosting, maintenance, and service management. The best performance can be achieved when all services are hosted in the same physical location. Emerging techniques for Web service optimization and dynamic resource balancing are specialized, proprietary, and generally unavailable to in-house development teams unless they are custom-built.

The Proliferation of Relationships
Just as the use of third-party Web services increases the demand on network resources, there is additional work in establishing and maintaining business relationships with the vendors providing the Web services used. If the utilized Web services are relatively large, standalone applications, there would be fewer services in the system and partnerships would not be much of a problem. When connecting many services into a grand application, however, such as using Web services to model a business process, more vendors are likely to be involved. While UDDI and WSDL make it easier to find, subscribe, and bind to these services, they don't change the need for mutual understanding by the buyer and seller about Service Level Agreements (SLA), costs. If a service is hosted by a vendor and it provides adequate performance for a large application, the agreement may be straightforward, but if the service needs to be hosted in-house or with a third party, special negotiations may need to occur.

Additionally, issues involving the quantification of a TSC for a given Web service can be and complex. Even though the UDDI exposes many services, it doesn't provide a grading system to determine the value of a given Web service. The value of a system can't actually be known because there are no metrics to measure the service offered (in terms of uptime, latency issues, or availability, for example).

Furthermore, the value of a service can't be assumed simply because it was designed by a reputable firm. The TSC of a given Web service is actually affected more by the company deploying the service than it is by the company that created the service. Thus, a given Web service can be deployed by three different companies and have three different TSCs. One of the benefits of Web services is being able to automatically redirect to a backup provider in case the primary fails.

Each Web service used may require additional technical diligence to ensure that the service meets the application's requirements. The architecture may increase a company's resources requirement due to the increase in the complexity and custom development of the integration. If not properly thought out, the hidden costs of managing relationships with many service vendors may hemper an otherwise successful Web services project.

One way to avoid this problem is to use a few fairly complete services. This negates much of the usefulness of a Web service-based architecture but will alleviate the need to have multiple relationships. Broad integration, even interbusiness integration, will require a larger number of interacting services. Modularity and reusability are also sacrificed when using only a few large services. Service failover can also be sacrificed to reduce the number of interactions necessary when the primary provider can give adequate uptime assurances. Initially, using only a few services is an easy way to approach the technology, and existing systems can be slowly migrated.

As Web services become more widespread, the problem of relationship proliferation will have to be addressed. An important impact of this new architecture is the need for closer and more consistent communication between a company's technical staff and the in-house partnership staff. Web services that are deployed outside of the organization are in fact partnerships. Staff, dedicated to vendor partnerships, can take on additional responsibilities related to Web service vendors, but they must work closely with the development team to ensure that every provided service meets their technical requirements.

Additionally, the technical team needs to assume the responsibilities for scoping a given Web service and its integration. Good communication between the Web service provider and a partnership staff member will add to the success of the Web services-based system.

Legal Issues and Data Regulations
Using Web services increases the load on the computer network, the number of relationships that need to be managed, and also the corresponding legal work that must accompany the myriad agreements. Beyond this lurks another challenge in deploying a Web services-based system. Because of the way Web services distribute data to each other - to multiple locations, and even to multiple businesses - careful consideration must be given to the way data is handled, stored, and transmitted to ensure compliance with privacy laws and data exchange regulations.

U.S. and international privacy laws are still evolving, and an ill-conceived Web services system may become unlawful, even if currently compliant. European laws are much tougher and may exclude some of the most obvious ways to connect Web services together. Industry-specific regulations must also be considered. A healthcare system might not be allowed to send patient data to a Web service hosted outside the company. A financial system may have special authentication requirements.

Additionally, current privacy statements may exclude the transmission of personally identifiable information. What if a remote Web service caches this information? Has it been given out to another company? By being distributed among multiple service providers, a Web services-based application encounters more than the usual amount of legal issues.

Tiptoeing Through the Snarl
Complying with regulations requires a high awareness and an active posture. The primary legal complication with Web services is in the way data moves through the system to multiple service vendors. If all services can be hosted in-house, then the issues are no different than in a traditional computing system. If outside services are used, however, all current regulations must be reviewed with the Web services architecture in mind. What data will be sent where? Where and when will it be stored? Who has access to the data during any part of the process?

Web services vendors should be required to produce an explicit statement about how their service stores or manipulates the data, including second-level Web services they use. With these considerations in mind, review existing privacy statements, data use agreements, relevant laws, and any other possible restriction on the use, transmission, or storage of the data the Web services system will manipulate. Even after the system is confirmed compliant and deployed, the liquid nature of current regulations requires diligent attention to emerging changes.

The concept of Web services can actually help manage this legal complexity. By using a Web service, which specifically understands and complies with data exchange regulations, the burden of building and continually changing your system for compliance is reduced. When using a Web service host or dealing with a consolidated provider, additional compliance claims might be made about the interactions between multiple services in the offered group. Using such a suite of services further reduces the legal analysis needed.

Multiple Points of Failure
A final challenge in planning a Web services-based system is coping with multiple points of failure. If a system or application is developed by subscribing to and wiring together multiple Web services, what happens when one of the services goes down? It could affect the entire process. What about maintaining transactional integrity? If the first stages of the process are completed successfully but later stages fail, rollbacks may be necessary on parts of the system that never displayed an error, and any data that didn't complete the entire process needs to be retried - or else it will be lost.

Fortunately, these difficulties are not unique to systems composed of Web services, and reliability techniques are well known. Redundancy is the keyword. Multiple independent network connections, automatic rerouting to duplicated hardware components, and even redundant power sources will multiply uptimes. Of course, building such reliable infrastructure correctly is tricky and definitely carries a cost, but there are many hosting companies with the required specialties. No matter how reliable the hardware system is, there will be failures. What then?

Web Services to the Rescue
Beyond the usual precautions, a Web services architecture can provide additional contingency operations. Because of the modular nature of a well-designed Web services system, when one service does fail, the request can be rerouted to an identical service on a different machine, at a different location, or even to a different vendor entirely. If done correctly, multiple points of failure can become multiple points of reliability. To achieve this reliability, an early understanding of what services need to be duplicated has to be addressed early in the service development cycle. Existing standards, such as WSDL, have mechanisms for supporting failover, but implementation requires either some kind of orchestration software or special code written into each module that calls a Web service. If the effort is given, however, even more clever resource management techniques are opened.

Service Spawning
If a system is built to dynamically redirect Web service requests, then a technique called service spawning can be used to provide redundancy, relieve bottlenecks, and use hardware resources efficiently. Service spawning is the technique of starting and stopping services on the fly, as they are needed, where they are needed. If one machine goes down, the Web service it was hosting can be automatically started on another machine, and the requests can be redirected. Similarly, new service instances can be started if the response times drop below a certain threshold, automatically clearing up bottlenecks. Using service spawning, a given Web service will be available as long as some hardware, a network connection, and the spawning software are functional.

Another way a Web services-based system can turn multiple locations to its favor is by using a service request proxy. Instead of invoking a Web service directly, the request is queued on a proxy. If the Web service goes down, the proxy retains all the request information and can redirect to another service. This also helps maintain transactional integrity, although response times may be impacted if the proxy is not colocated with the Web services themselves. If it's colocated, then it potentially has the same vulnerability as the resources running the services. If a service goes down, does the proxy go down as well? If the proxy goes down, is there another route to the service? One method is to build the forwarding queue into the software that makes the Web services calls. This eliminates the impact on response time and avoids adding maintenance on a separate piece of software. If orchestration software is used to build the Web services system, it should have queuing and redirection built in.

Unprecedented Uptimes
Achieving success with Web services is not straightforward and requires attention to many aspects of the project. The complexity of the Web services architecture is not in any one aspect of the system, but in the broad range of technologies and understanding that's required to deliver this architecture. The complexity of obtaining a good TSC can be a daunting task. But by taking a systematic approach to the problem and decomposing it into the four major aspects - transmission latencies, service refactoring, architecture and bindings, and deployment - it's possible to provide some benchmarks to say that one process is better than another.

Network latencies from remotely distributed systems can be handled by collecting services into a single facility. Taming the large number of software partners might initially involve reducing the number of services used, but long-term solutions are to be found from companies that coordinate a variety of Web services into a single billing and contact point. A smart architecture uses just the right amount of Web services and can help reduce network load and mitigate the number of software partners. Legal concerns revolve around the transfer of data between many Web service providers, and privacy statements, privacy laws, and industry regulations should all be reviewed with a Web services system in mind. Services that handle sensitive information may be hosted in-house or specially designed to handle data in a compliant manner.

Finally, a Web services system without proper redundancy will be less reliable than traditional systems, but if the correct techniques are used, systems using Web services can achieve unprecedented uptimes. The highly touted advantages of Web services are possible but not automatic. Careful consideration of the preceding factors can help guide a project through to a successful completion with a substantially lower TSC.

Author Bios:
Timothy Olson's consulting experience developing intranets and e-commerce backends led naturally to his recent work developing a UDDI and SOAP-enabled enterprise integration tool. He currently serves as chief scientist for the Web services development company Xenobit Corporation. tolson@xenobit.com

Mason Ham is an accomplished entrepreneur and Web services advocate. He is currently the president and CEO of Zambit Technologies, Inc., a Web service hosting and deployment company. mlham@zambit.com