The Web services paradigm is poised to become the dominant form of distributed computing this decade and beyond. Indeed, A. T. Kearney, an EDS global consultancy, found that 75% of companies ranging from less than $50 million to more than $1 billion in revenues and across 20 vertical industries have already deployed one or more Web service.

The Benefits of Web Services
Enterprise integration is consistently one of the top three priorities of IT organizations and accounts for $50B in spending annually. Web services are becoming the technology of choice for solving pressing point-to-point integration needs because of the inherent benefits of the approach. Foremost among these benefits are cost reductions, business agility, and component reuse.

Cost Reductions
Reducing costs of an integration project as dramatically as 80% have gotten Web services a lot of attention. Merrill Lynch, DuPont, General Motors, Wachovia, NASDAQ, Continental Airlines, Dollar Rent-a-Car, JP Morgan Chase, and Zagat, to name a few, have used Web services for their recent application integration projects to drastically reduce their costs. In particular, Merrill Lynch was able to complete a project originally slated to cost $800,000 for $30,000; that gets a CIO's attention. At Motorola, in one project involving the reuse of an existing credit-card validation function by "wrapping" it as a Web service, the company was able to save over $100,000 in software development costs. The large cost benefit of Web services follows from how simply and rapidly they can be developed. In the past, enterprise integration required specialized – and sometimes downright esoteric – expertise. The programming skills necessary to use Web services for application integration are within the reach of the broad cadre of enterprise developers.

Agility – New Revenue
Cisco's John Chambers has said "the greatest contributions to corporate productivity, and consequently revenue, are likely to come out of dynamic changes to business processes." Business processes are hard to change when they are codified into inflexible monolithic applications. The component-based Web services model offers the promise of business agility by enabling the rapid and dynamic configuration of information assets for the maximization of revenue.

The advantage of business agility is apparent in the case of MCI, which was able to transform its business several years ago with its MCI "Friends and Family" plan. The ability for MCI to use the lists of a particular customer's friends and family to provide pricing incentives gave it a valuable competitive edge. All the other long-distance carriers were caught flat-footed, unable to respond to MCI for 18 months because their assets were locked up in ossified systems that froze their business processes.

Reuse – Maximizing Leveraged Investments
When you build a Web service interface between two internal systems today, you can easily justify the cost savings for that point-topoint integration alone. But the future value is magnified each time the service-oriented architecture (SOA) created by your Web service is used by other Web service projects in other parts of the organization. Once the service is created it is likely you can reuse the same interface, or a slightly modified version of it, for different purposes later. This versatility is essential to a business's ability to deliver different combinations of products or services to new markets, win market share from competitors, and create new shareholder value.

Dollar Rent-a-Car needs to provide accurate, to-the-minute, location-specific car inventory data to multiple consumers: travel agent systems, airline systems, travel Web sites, and all the Dollar desks in airports. Each of these consumers leverages the same Web service connection to Dollar's legacy systems.

Web Services Evolution
Web services, like any other new technology, will go through several stages of evolution and adoption. In this section we'll examine how Web services usage will evolve over the next halfdecade (see Figure 1).

First Phase: Tactical Deployment
The first phase of Web service adoption is characterized by widespread, but tactical, deployments. These typically involve exposing legacy data as a Web service for presentation in a portal or the creation of a point-to-point bridge between two different applications. Portals and Web services share a common goal: enabling a company's previous software investments to be combined and exploited easily in unanticipated, value-added ways. The second strong push for Web services is when companies are doing application integrations. Projects that are relatively low risk and represent "low hanging fruit" are typically chosen as initial Web service application integration projects.

Second Phase: Strategic Enterprise Middleware
For application integration, Web services are, without a doubt, the most compelling middleware technology we've ever seen. As first-phase deployments prove out the benefits, the complexity of Web services integrations will increase. Web services will start to become the middleware technology of choice for enterprises as they use it to integrate CRM, ERP, credit verification, and other customer-centric applications thereby lowering costs and providing better customer service.

As security standards mature in this second phase, enterprises will begin to more widely deploy Web services and attack high-value integrations with their trading partners. Indeed, even today a few innovative companies such as Dell, Dollar, Amazon, and Orbitz have aggressively deployed Web services to integrate supply chains or provide a richly integrated back end to an ecommerce application.

The Vision: Transformational Service-Oriented Architectures
In the third phase, Web services will become ubiquitous and will form the fabric across which distributed enterprise application components communicate. All new application development and all packaged applications will expose their functionality via Web services. Applications will be formed by composing their functionality out of Web service components distributed across network and administrative domains. Services will be discovered and consumed in a dynamic fashion. Unlike previous attempts to deliver on this vision, such as CORBA and DCOM, this time the "vision" is already showing some reality. It is already reality because four key areas never sufficiently addressed before are already solid and stable: an interface language (XML and WSDL), an information bus (the Internet), a flexible interface (XML documents), and a complete separation of interface from how applications are programmed (SOAP does not care if it talks to Java, C++, C#, or Cobol).

Operational Challenges
Understanding Production Web Services
Production Web services operations have special requirements related to but extending beyond traditional operational metrics. These new operational challenges, which are also essential requirements, include reliability, performance, and security.

Reliability
The measurement of Web service reliability requires a finer level of granularity than the determination of application, system, or network reliability. All Web services are not created equal, and some are more critical to the operation of a business than others. For instance, key Web services that perform such functions as a credit check or execution of a market sell order are vital components of a business process whose failure brings the entire business process to a halt. Others such as those that provide supplemental information like product information or weather details may be merely "nice to have."

Performance
The measurement of Web service performance has similar granularity requirements. The overall performance of a Web service is a relatively useless metric – you need visibility into the specific methods defined in a Web services WSDL interface description to understand whether observed delays might have a business impact. Method-level information is also necessary in order to isolate and optimize performance bottlenecks. Characterization of method performance may sometimes require visibility into the parameters associated with the method calls. These requirements mean the XML data stream must be observed; this poses a significant operational challenge itself.

Security
Security in the Web services world is an order of magnitude more complicated than that experienced with the Web browser. In the browserbased Web, transport layer security between two endpoints, such as that afforded by SSL, was all that was needed. Web services require the delegation of trust across domains (how do I know I can trust the entity that established your identity?) and monitoring whether security policies are being followed consistently and completely. Individual messages may need to be encrypted or signed or both in order to protect identity and security of participants and the information they are exchanging. The keys for encryption and decryption and the identity of the owner of the keys is exceedingly complex when the Web service endpoints are not all within a single organization that can authenticate parties to transactions. Constant monitoring of an individual's authenticated identity and of confidentiality and integrity of documents is an absolute requirement for keeping a Web service in compliance with business and regulatory security policies.

Unique Challenges
Web services also present their own unique operational challenges. The sheer number of services and their methods combined with the granularity at which they must be monitored presents new data management challenges. Furthermore, the verbosity of XML means that a significant number of transactions results in a large volume of data that must be monitored in order to provide operational visibility.

Moving to a service-oriented model means that services will be shared among different applications. This sharing, while introducing a cost benefit from reuse, results in more new operational requirements. You need to track how much resource is being consumed by the various service requestors. For example, there is the potential for one service requestor to overload the system, causing unacceptable performance for other consumers of the same service.

Multi-tier service infrastructures introduce the possibility of a cascade effect in the case of the failure of a Web service on whose data a service several hops away may rely. The ability to understand and trace the cause of failures across a Web service infrastructure becomes very important. Cross-enterprise usage of Web services requires a level of visibility into resources that are outside of your control. As resources are shared across organizational boundaries, monitoring data across these boundaries must be exchanged in order to maintain a handle on quality of service.

Limits of Established Technology
The previous generations of monitoring and management technology – specifically network, systems, and application management solutions – were architected to solve a different set of problems and do not apply to Web services.

Web Service Ignorance
Network management solutions focus on the layer of the application stack associated with the quality of network connectivity in a distributed environment; their primary concerns are the throughput and latency characteristics of networks. Systems management solutions focus primarily on the hardware layer of the stack and the health of the operating system. Application management solutions focus on the specific server processes involved in serving an application and characterizing the availability and performance of application interfaces. None of these solutions understands the notion of a Web service, let alone a method call or element within a message. The quantities they are able to characterize are at a different layer in the stack and hence cannot provide the granularity necessary to be effective at the Web services layer.

Monolithic and Inflexible
Previous generation solutions were also designed around a static IT infrastructure. These kinds of framework solutions often take several months to initially deploy and several more months to customize to specific customer needs. Because the managed systems were static and the interfaces between systems was proprietary, correct functioning was defined as "the server is up and the expected process is running." Web services, on the other hand, are about agility and dynamic change, with services being added and removed from applications in an organic fashion. Old-generation solutions are simply not agile enough to react to these changes.

Cross-Enterprise Myopia
The notion that all resources are controlled and owned by a central organization was presumed in the design of old-generation solutions. In the world of Web services, resources are spread across administrative domains, hence the systems that monitor and manage them will be under different spheres of control. Web services monitoring systems must be able to operate in such a federated management environment, sharing monitoring data as necessary to ensure proper quality of service.

Lack of Business Perspective
Web services are about enabling business processes. Through WSDL and SOAP, monitoring tools for the first time have a practical way of gaining visibility into the business context of messages. Older-generation solutions are not focused on the business information contained in the XML streams. Instead, they remain focused on system metrics and so cannot provide a business perspective on the systems they manage and monitor.

The New Architecture for Monitoring and Analysis
Meeting Operational Challenges
New monitoring systems are needed to meet the operational challenges brought on when deploying Web services. These systems should be easy to administer, provide powerful monitoring and visibility capabilities at fine granularity, and allow flexible ad hoc queries about the content and business value inside the XML messages. Furthermore, they must have very low overhead so as not to detrimentally impact the performance of the Web services they are monitoring. Systems to monitor Web services should be "good Web services citizens," by which we mean that they should adhere to the same principles that drive people to adopt Web services in the first place. Hence, these systems should be costeffective, lightweight, and nonintrusive to implement; standards-based; and compatible with all other systems and tools with which they might need to interact.

Cost-Effective and Nonintrusive
To be cost-effective, solutions must be easy to acquire and deploy. They must be affordable and scale with the size of your deployment. They should reduce the total cost of ownership (TCO) of your entire Web services infrastructure. The solution should require no additional coding or changes to network topology while providing full visibility into the HTTP, SOAP, and XML stream data. You should take care to avoid solutions that add new components into the architecture that could introduce single points of failure and costly additional hardware, software, or administrative requirements.

Flexible
Agility is the point of Web services so you need flexibility built into your monitoring system. The ideal system provides a "what if" level of control and flexibility, enabling near real-time monitoring and analysis of the application. The "what if" kinds of questions that will be asked about Web services will change constantly based on the changing roles of the observer (operations, business, executive) and changing business conditions. The system must have the ability to specify what operations, what performance metrics, what alerts, and what business metrics are of interest. These alerts must be translatable into events that provide actionable information through interfaces with established network or systems management tools.

Standards Based
Why develop an entire middleware strategy around Web services that is platform neutral, lightweight, and standards-based and throw that out the window with monitoring that creates a vendor-specific lock-in? The basic design principle of the monitoring system should be that it too is built out of Web services standards. This makes it work in heterogeneous environments, makes it easy to interface to other WScompatible tools and systems, and means all investments are protected.

Advanced Requirements
The basic requirements outlined above are the necessary minimum for any Web services monitoring solution. But to be truly effective and successful, the solution must also comply with a set of more advanced requirements. It must be very efficient and not impose any significant overhead on the Web service communications. It must be easy to administer even as the service scales to hundreds and thousands of distributed nodes. And it must provide business insight because critical business data that can give powerful, early insights to business trends are available through the XML Web service streams.

Efficient
To get visibility into the entire XML stream for ad hoc queries that can bring business value to light, and to do this with little or no performance impact, it is essential that the monitoring system have very low overhead. This requires a focus on monitoring, not on processing or transformation of the SOAP envelopes and payloads being observed. Acceptable latency penalties for stream processing should be on the order of a millisecond, not tens or hundreds of milliseconds as is typical for tools on the market today.

Easy to Administer
The ideal monitoring system introduces no additional burden for the operations staff tasked with ensuring their successful operation. Installation should be completely automatic, simple, and foolproof. Once installed, the system should automatically discover all running Web services and immediately provide value by logging and monitoring baseline characteristics about the Web services.

Business Insight
Business users need the ability to see and audit their organization's compliance with regulations that could have a major impact on the business. They will want to track business transactions and have the ability to ask questions about those transactions. Aggregating XML tags across sessions and across servers into coherent business transactions will be required to enable this. Just as operations staff wants alerts on functionality errors or performance issues, business users will need to set up notifications based on business conditions or thresholds critical to their business goals. Charts, graphs, and reports showing business usage and trends which provide insights that allow business analysts to have agility will prove invaluable to an organization's top and bottom lines.

Call to Action
There is no longer any doubt that Web services will become ubiquitous quickly. There is also no doubt that Web services will create a plethora of unmet operational challenges. Visibility of middleware that integrates applications is essential to business operational success. Web services are a completely new approach to middleware and, not surprisingly, new architectural approaches and practices are needed for successful monitoring as well.

If you have already deployed Web services in your production environment, you need to ensure the operational health and availability of these assets with Web services monitoring and analysis software. Even if you are just getting started with Web services, it's not too early to start building monitoring and analysis into your best practices. Don't wait until you feel the pain from putting your business-critical Web services into production naked.

As you begin to evaluate Web services monitoring software, keep in mind the reasons you have chosen to use Web services in the first place: lower TCO, greater investment leverage, and no vendor lock-in. Your Web services monitoring and analysis solution should not only preserve those benefits, but strengthen them. The design center for a truly effective monitoring and analysis system must be consistent with central Web service tenets – it must be cost-effective, flexible, nonintrusive, and standards based. The best architectures will have all these characteristics and be efficient, easy to administer, and provide significant business insight in addition to operational metrics.

About the Author
Dr. Jothy Rosenberg is a serial entrepreneur and the founder, director, and CEO of Service Integrity. Prior to this venture, Jothy cofounded GeoTrust, the world's second largest certificate authority and a major innovator in enterprise managed security solutions. He is also the author of How Debuggers Work and Understanding Web Services Security (2003; Addison-Wesley). Jothy holds several patents. jothy@serviceintegrity.com