AccessMyLibrary provides FREE access to millions of articles from top publications available through your library.
Significant portions of the productivity gains enjoyed by businesses over the past decades are attributable to the adoption of new information technology (IT). At some point the economic balance shifts; businesses start putting more emphasis on reducing the cost of supporting existing IT functions than on adding new function. Today, many businesses are striving to improve the overall cost-effectiveness of their IT investments by reviewing business needs and cutting costs. These efforts typically include leveraging existing assets, consolidating redundancies, and laying a foundation for future growth. This trend is fueling the move from tightly coupled componentized systems to loosely coupled service-based systems, such as those based on service-oriented architectures (SOAs) employing standards-based interfaces. (1,2)
To illustrate the differences between componentized systems and service-based systems, we make an analogy with the air transportation industry. This industry moves passengers arriving by means of ground transportation into airplanes, flies them to a destination, and discharges them into ground transportation at the destination. Airplanes, an essential part of the story, are constructed from large collections of tightly integrated components. According to Boeing, a single 747-400 ** airplane contains more than 6 million parts, (3) demonstrating that the componentized system approach can work for very complex systems. Even so, the overall air transportation system is best conceptualized as a composition of "choreographed" services: fuel services, food services, baggage services, air traffic control services, and ground transportation services, to name just a few.
Air transportation depends on both component strategies and service strategies. What forces drive businesses toward one approach or the other? One way to address this question is to observe some of the differences between integrated components and choreographed services.
Componentized systems tend to be deeply hierarchical, with components constructed from subcomponents that are themselves constructed from other subcomponents. When a componentized system malfunctions, the misbehaving subcomponent must be identified and repaired or replaced. For example, frequent airline passengers may be familiar with delays associated with airplane malfunctions. Drilling down into such "vertical" component hierarchies to identify the root cause of failure is the strength of today's diagnostic tools, which are often built into complex systems.
How does this contrast with the choreographed services environment? Services have well-defined and broadly available interfaces with a predictable or specified quality of service. They are typically accessed by different types of consumers. Services generally provide a complete usable unit of work, and equivalent services are frequently available as alternatives. Indeed, interchangeable services are the basis for competition. When a service fails, the preferred remedy may be substitution rather than repair. For example, if a fuel truck breaks down, any airline passenger would expect a replacement truck to be dispatched rather than waiting for the broken truck to be fixed. Unlike componentized systems, the domain of control and visibility for the consumer of the service generally stops at the service interface This service environment leads to numerous "horizontal" interaction patterns that take the form of a broad and shallow hierarchy.
The challenge in managing and understanding service composition is dealing with this horizontal complexity. When systems are composed of multiple independent business processes, the mapping between such processes and the applications executing in the IT layers may not always be obvious. Consider such fundamental tasks as verifying the correctness of a workflow or locating performance bottlenecks, where logs from a variety of servers must be collated and interpreted. This is difficult even when the number of servers is small and may become impractical as horizontal complexity increases.
The emergence of SOAs in the IT industry is driven by the same pressures that have shaped the air transportation system. Web Services Navigator (4) has been designed and built from the ground up to address the challenges of horizontal complexity in the service environment and its associated patterns of usage. This tool relies on the Data Collector for IBM Web Services Navigator (5) to capture events. The tool then correlates the events, models the transactions they represent, and extracts patterns of execution from the model. The tool thus reconstructs individual transactions from end to end and produces visual abstractions, such as service topologies and flow patterns, as well as concrete views of transaction flows and data content. The abstract views reduce large volumes of execution data to forms more meaningful to humans. They can reveal important business trends that are obscured in concrete views and at the same time, can link to the associated detailed data when needed.
Because SOAs conform to open standards, the Data Collector for Web Services Navigator can capture application execution data in the middleware. Consequently, developers and operations staff can take advantage of visualization technology without modifying their applications, either before or after deployment, even when their environment includes a mixture of programming languages and operating platforms.
In the next section of this paper, we describe the five views that are used by Web Services Navigator to display information. The two sections that follow illustrate a number of cases in which the tool has proven useful; we show first how the tool was used to diagnose a number of problems in business logic, and then we show a number of cases in which the tool helped diagnose problems in the IT layer. The problems presented in this paper were encountered in real Web Services-based applications developed within IBM or for customers of IBM. In particular, two applications were used to illustrate the tool features: an online order validation service and a retail point-of-sale system. Next, we briefly discuss the Data Collector. Then, in "Architecture and implementation," we describe the general architecture of the tool and discuss a number of implementation issues of interest: compensating for clock skews among nodes, our algorithm for laying out topology graphs, and identifying transaction patterns. We discuss related work, and we conclude with a summary.
The Web Services Navigator described in this paper is a research project. It is publicly available from the IBM alphaWorks * Web site and is included in a recently released product from IBM. (6) A previous version is also available from IBM. (7)
THE VISUALIZATION TOOL
The Web Services Navigator visualization tool is a plug-in feature for the Eclipse Version 3.0 platform, (8) an open framework for interactive tools. Web Services Navigator offers a new perspective with five new views of the execution of Web Services applications, as shown in Figure 1. It can co-exist with, but does not depend upon, other tools (9,10) and products (11) based on the Eclipse platform.
[FIGURE 1 OMITTED]
This section describes the five new views presented by Web Services Navigator: Service Topology, Transaction Flows, Flow Patterns, Statistics Tables, and Message Content. Examples of how each view visualizes problems are illustrated in later sections of this paper and in a companion article (12) published on IBM alphaWorks.
The Service Topology view, on the upper right side of Figure 1, shows a graph of the services involved in an application and the message flows between them. The boxes represent individual Web services: each is labeled with the name of the service (at the top of the box), the name of the machine that hosts the service (below the service name), and the names of one or more operations that the service provides (shown in gray background). The colors of the boxes indicate different host machines, and all services hosted by the same machine are displayed in the same color. The arrows between boxes represent Web service requests and are labeled with the number of requests captured. The circumstances that produced this particular view will be discussed in a later section.
When the cursor (mouse pointer) is moved near a node or an edge, information such as the total number of requests and the total number of bytes transmitted is displayed in a small "tooltip" window overlaid on the view.
The Transaction Flows view, on the left side of Figure 1, shows a time sequence of the Web services involved in an application and the message flows between them. The columns represent individual Web services and are labeled with the names of the services and the machines that host them. Each service and host machine is labeled in the same color as the Service Topology view. Arrows represent Web service requests and responses, and vertical bars represent processing of a request. Transactions are separate flows of connected arrows and vertical bars. Each transaction is drawn in a unique color. The colors of the labels and transactions are not related. Time proceeds from top to bottom; it may be represented conventionally, in seconds, with a scale running down the right-hand side of the view; or, time may be represented in logical steps, in proper sequence but with all events evenly spaced, regardless of their actual duration. The logical representation of time may reveal details within dense clusters of events, and across widely spaced events, that are obscured in the conventional representation. Additional information can be displayed in tooltip windows by moving the cursor over service names, machine names, message arrows, and processing bars.
The Flow Patterns view, …