Rounding up Web services intermediaries

WSIs (Web services intermediaries) are a unique class of middleware for managing and monitoring Web services. Useful for everything but the smallest of Web services applications, WSIs provide important features such as message routing, security, exception handling, abstraction, message transformation, and logging.

As vendors fine-tune their products, add features, and improve usability, WSI options are getting better. Over the last few months, several new versions of WSI products have popped up: Actional Looking Glass 5.0, AmberPoint SLM (Service Level Manager) 2004, Grand Central BSN (Business Services Network) 4.0, and Infravio Ensemble 4.1 (the component I tested is now known as X-Broker).

Each of these products differs significantly in their approach to intermediating Web services, but a cursory review of their feature sets doesn’t readily reveal that difference. The significant contrast is in the metaphors they use for management and the presentation of information; each WSI emphasizes different aspects of the intermediary game. Grand Central 4.0 is a hosted service, whereas Actional’s approach zeroes in on service monitoring; Infravio uses contracts to define relationships; and AmberPoint SLM manages performance with service-level objectives.

Deciding which of these four tools is right for your organization will require careful consideration of your needs and the relative strengths of each product. Evaluate the WSI’s management metaphor and compare it with your organization’s engineering and operations philosophy. Also, be sure to evaluate the reporting and user interface based on your organization’s needs.

If you get those things right, any one of these products will provide you with a proven, stable management platform for building reliable Web services applications. They are polished, ready to work, and do what they advertise.

Grand Central BSN 4.0

As a hosted service, Grand Central is unique among the four products tested. There’s no software to buy or install: You simply go to their Web site and sign up. The hosted service has clear advantages in ease of setup and maintenance. Although some organizations don’t like the idea of their core messages going outside their internal network, this attitude is changing as more companies take advantage of “by-the-drink” services.

The core of Grand Central’s BSN provides a trustworthy, auditable, and convenient way for organizations to exchange Web services messages with other external parties. By using BSN 4.0 in combination with other services available on the Internet, building and offering services without owning any servers becomes possible.

BSN 4.0 adds several important new features for creating virtual applications. Perhaps most significant is the creation and execution of Web services processes inside the network; the most sophisticated of these features is the addition of a BPEL (Business Process Execution Language) engine.

BPEL is an executable, XML-based language for describing business processes, and BSN 4.0’s BPEL engine allows developers to create, combine, customize, and reuse dynamic business processes.

So far, Grand Central stands alone in its use of BPEL for complex Web services interactions that mirror business processes. In addition, BSN allows developers to build document routing processes and provides a browser-based visual programming tool based on DreamFactory for building the routes. Using the tool, a developer can create a routing process in a few minutes that delivers Web services messages to various developer-designed service pipelines based on message topic or sender.

A second new addition, necessary for supporting virtual apps, is a built-in, robust service directory so developers can share, discover, and access business processes. This is a feature not included in the other products reviewed, and it’s a handy one. Developers can create private directories of processes they’ve built and manage service consumers through the use of the directories’ access-control features. They can publish these services globally or just to partners.

The Web interface is used by developers who create, use, and publish Web services and by the operational personnel who manage them. I’d prefer that these functions were separated out more completely, because different groups are usually responsible for them.

By adding business process automation features such as a robust directory and a BPEL engine to an impressive connectivity engine, Grand Central may have created the first platform for building fully functional virtual applications.

Infravio Ensemble 4.1

Scaling Web services to numerous partners requires that the relationship management be as automated as possible. Many WSIs conceptualize the task of configuring the intermediary as a process of defining an end point as a proxy for the provider, defining an end point for the service consumer, and then configuring a pipeline of activities that are performed whenever a message moves from provider to consumer.

Infravio takes that one step further; the provider can produce a contract regarding the proposed actions and service levels. Better still, each relationship between an SOA (service oriented architecture) provider and consumer may be viewed as a service delivery contract.

With Ensemble, all of the actions in the pipeline are managed as terms in the contract. Managing each relationship from its contract eliminates translating between paper and the configuration file, which reduces errors.

The service delivery contract defines the authorized provider and consumer end points and sets forth the terms of the contract for logging, routing, security, and service levels. Multiple contracts can be defined for a particular service.

Here’s how the process works: A new service consumer visits your organization’s Ensemble server, registers as a user, and subscribes to services. Once approved, the consumer can browse available contracts, select one that is appropriate, and begin using the service. Different service contracts might be associated with different service levels, pricing, and so on.

Ensemble is extremely simple to use; part of the simplicity stems from its easy installation. More importantly, the contract metaphor provides a very natural way to think about service provisioning. Envisioning what happens between producer and consumer end points as a contract greatly simplifies the user interface. There is no way to manage Web services in Infravio outside of a contract, but it’s difficult to tell how limiting this would be in real-world practice.

The contracts specify logging tasks, including what events are logged, how logs are kept, and how alerts are handled. Contracts also provide a means of routing SOAP requests to achieve load balancing, fail-over, and service versioning. Advanced routing uses information about or within the SOAP message combined with XPath queries to select messages for XSL transformation.

The contracts specify the security aspects of message handling, including authentication and authorization via LDAP or SiteMinder, message signing, and encryption. Service-level terms specify handling priority for messages from different consumer end points and can fire alerts when handling times exceed a preset threshold. Reporting can be done on a per-service or per-contract basis, and includes customizable graphs of service activity and event tracking.

Compared to the other WSI products, Ensemble’s contract metaphor unifies the various features, giving it a very consistent interface that makes it seem like it has fewer bells and whistles — but that’s an illusion. Nevertheless, the interface is a significant departure from what most operations groups are used to and may prove a barrier to adoption.

Actional Looking Glass 5.0

When applications built from Web services fail, there are usually only a few recourses. One is to mine the log files for any indication of what caused the failure; this procedure may be useful in the event of hardware failure or software errors, but usually misses more subtle failure modes, such as resource starvation.

To catch everything, operators turn on detailed logging, but its high overhead usually masks the problem by changing the interaction of the services. Moreover, the failure might have been spurious and won’t reoccur during the detailed logging.

The root-cause analysis in Actional Looking Glass is based on a more sophisticated mechanism than log analysis. The solution consists of the Looking Glass Server, the Looking Glass Console interface, and multiple tools, including Link Explorer and Alert Analyzer. Looking Glass Console is limited to Microsoft platforms, although the server portion of Looking Glass and the Active Agents do run on multiple platforms.

Looking Glass focuses more intensely on the monitoring and management of Web services than the other WSIs in this test. One of the most significant features of Looking Glass Manager, the management component, is its ability to create flow maps on the fly from message traffic, which is useful in performing root-cause analysis of application failures.

Each Actional agent and intermediary constantly logs detailed operational data in a rolling buffer — similar to an aircraft’s black-box flight recorder — that causes no perceptible drag on the system. When a failure occurs, Looking Glass signals each agent and intermediary to capture and forward its rolling buffer; this information helps reconstruct the event. By following the flow and watching inputs and responses, or metadata about them, operators can drill into detailed operational data to determine the failure’s cause.

Another important feature is Looking Glass’s use of “service stabilizers.” Actional’s self-healing capabilities detect and fix problems immediately, based on your preset directions. Service stabilizers are configured in two steps: first, define the action to be taken to compensate for the problem; second, configure triggers for that action.

You may choose custom responses to any disruptions, but that can take time — the most difficult piece is finding appropriate compensating actions for every potential error.

When used in a gateway architecture, the compensating behaviors route around problems by sending traffic to alternate destinations. Actions for agents run as part of the application server itself, and can therefore change the behavior of the service.

Because the service stabilizers can be switched on and off manually, their effects can be built into new service deployments and tested in the development environment. In this way, ad-hoc compensations in the current version can be built into future versions as part of the tested deployment.

An important part of Actional’s approach to management is the notion of policy abstraction. All Web services management systems allow operational policies (such as security or auditing policies) to be applied to specific services, but policy abstraction allows policies to be defined for abstract document entities called “message fields.”

Message fields are not concrete fields in specific XML documents, but abstract notions such as document ID or name. Policies can be defined for these abstract message fields. For example, a policy might be defined to encrypt personally identifying information as an abstract concept based on message fields. Later, in development or operation, specific fields inside a concrete XML document can be mapped to the message fields and the policy will automatically apply.

Message fields represent an abstraction boundary that allows for separation of concerns. Although planning these abstractions can take some effort, once they are set up, they can significantly reduce the effort required to maintain policies. The abstractions also match developer roles to their skill sets; security personnel can write policies about encrypting fields without having to know the specifics of which fields are of interest in each concrete document.

Furthermore, abstract policies are reusable on multiple applications by simply mapping the message fields to the concrete XML document. Later, the policy can be updated once and applied to all the relevant documents automatically without development and operations having to be involved to write specific XPath queries or identify specific services.

AmberPoint SLM 2004

AmberPoint’s approach to the WSI challenge is to create multiple, stand-alone Web services tools that excel in specific areas and combine to form a full suite of tools for managing Web services. As one of those stand-alone components, SLM’s sweet spot is tracking and managing service performance and availability. Other tools in AmberPoint’s suite provide exception handling, logging and auditing, security, and versioning.

Service-level objectives are among the key organizing features of SLM’s interface, which defines service goals and then applies them to specific services or customers. AmberPoint supports multiple architectures for intermediating the Web services, including a proxylike gateway and container plug-ins. It also monitors services by forking the message flow in situations where you want minimum drag on the message traffic.

The simplest way to use SLM is to define service thresholds on specific Web services. With service thresholds, services are monitored without complex policy creation, and service monitoring can be done on a per-customer basis to combine the business view with the operational view. Setting thresholds is easy in the Web-based interface and takes just a few minutes.

SLM also creates agreements, which are more sophisticated than thresholds. Based on the notion of business calendaring, agreements provide detailed scheduling of performance monitoring while accounting for time zones, peak hours, effective dates, scheduled outages, and agreement versioning. Each customer can have multiple agreements differentiated by any combination of supported calendar events.

Service-level objectives are associated with each agreement to control the usage of a particular service or notify an admin when the service exceeds a specific target threshold. Graphical representations of the service-level objectives and the current status are displayed on an easy-to-read dashboard by sliding or fixed-time windows.

Violations of agreements show up on the dashboard as well, including the customer affected and the exact nature of the violation; interested parties subscribe to violation alert digests by e-mail or SOAP action. SLM provides a built-in reporting tool, but because the database that drives SLM is based on an open schema, third-party reporting tools such as Crystal Reports may be used to create custom reports as well.

Service-level objectives may be assigned to specific customers, and SLM also generates customer-specific alerts. Customer-specific reporting pages help account managers keep tabs on how their customers are faring.

As with Looking Glass’s service stabilizers, SLM will take compensating actions on agreement violations, such as redirecting requests or prioritizing them to address service problems. This allows SLM to perform tasks such as load balancing and fail-over.

AmberPoint also provides a free tool for developers called AmberPoint Express that debugs services by drilling down on specific time slots and messages within the time slot. Express gives developers a view of SOAP requests and responses and is easy to configure and use because it’s based on the self-configuring agents that discover their managed services.

A WSI Horse Race

These four WSI products have very different personalities and thus different deployment strengths. Infravio Ensemble excels at managing relationships with external partners, so if you have a large network that shares services often, it’s a good option. Grand Central’s BSN 4.0 provides a low-hassle way to get going and is a clear choice for automating business processes and translating between multiple data and transport formats.

Actional Looking Glass and AmberPoint SLM are the most like other management products that IT operations groups have used previously, so they’re good choices for mature IT shops. Looking Glass provides deep insight into complex Web services integrations. Because AmberPoint SLM is focused on managing service levels, it’s the tool of choice for shops offering multiple managed services to numerous customers with well-defined service-level agreements.

WSI selection depends on your organization’s Web services architecture and reporting needs. But no matter which of these four you choose, each provides all of the essential Web services management features that you’d expect from a Web services intermediary.