Managing the Web services flow

In distributed architectures, most of the interacting software components operated in a single trusted domain that was centrally managed. In the new decentralized model, interactions between components span organizational boundaries, making it difficult to manage, configure, monitor, and update the components from a single operations organization.

Core 3.0 from Confluent Software is a Web services manager that tackles this problem by providing a single point of configuration for far-flung Web service components. The architecture of Confluent Core is as distributed as the services that it manages. Core works through a set of active intermediaries called "gateways" or "agents," depending on how they are deployed.

Gateways are proxy servers that intercept requests, enforce policies, and then forward requests to registered services. For a gateway to serve as the proxy for a service, clients must be directed at the gateway instead of the service. Agents, on the other hand, are policy-enforcement plug-ins that are deployed inside a SOAP container. Consequently, the client of the service is unaware of the message interception that is necessary to enforce policies.

Multiple distributed gateways and agents can be configured and managed via a single policy manager and monitoring engine that is made up of three integrated but distinct tools: Core Manager, Core Monitor, and Core Analyzer. Together, these components bring centralized policy control to distributed Web services.

The Core suite also scores high with easy installation and setup, ready-to-use dashboards for system monitoring, and built-in business analysis tools.

There are some drawbacks. Core is expensive, and unlike hosted solutions such as Grand Central Communications' Web Services Network, Core can't function as a trusted intermediary between business partners. Furthermore, although Core can generate alerts and reports based on the contents of SOAP messages, the data filtering rules are limited; the ability to script more complex rules would be useful.

Policy pipelines

Core is organized around the idea of policy pipelines -- centralized repositories of policies used to control the behavior of managed Web services in a number of areas, including authentication and authorization, QoS (quality of service), load balancing, message transformation, service-level requirements, and other business needs. Core Manager is where new services are registered with the system and is where policy pipelines for those services are created and managed. Services can be added individually by using a reference to their WSDL description, or they can be selected from a UDDI directory.

One of the chief differences between the decentralized computing model defined by Web services and distributed computing models of the past is the shift in component ownership.

A pipeline is a linear series of steps. Each step can be individually created and edited. As new services are added to gateways and agents, default pipelines are created that perform authentication, access control, and logging for the request and the response. These default pipelines can be modified from a catalog of steps. For example, the administrator might choose to replace basic HTTP authentication with LDAP authentication or add a completely new step that performs message transformation based on XSLT.

In addition to managing policy pipelines, the Core Manager also controls important aspects of service delivery. The Manager supports HTTP and messaging-based service delivery and allows the user to configure what happens in the event of service failure. The Manager also sets policies in the gateways and agents that control parameters for QoS and SLAs.

One important feature of Core Manager is change management. As services are added, a version number can be included with the service. As clients request service, requests are automatically routed to the most recent compatible service.

Core Monitor is the operational companion to Core Manager. Using Core Monitor, systems administrators can monitor the availability, security, and performance of all the Web services deployed in the associated gateways and agents. The system can monitor access-control violations, message traffic, and service latency.

Core Monitor also tracks and monitors flows, which are collections of Web service invocations that have a common context and are identified using a correlation ID (correlation IDs are being standardized in the WS-Addressing specification). A flow might represent, for example, the several separate transactions required to process an order. These can be collected and viewed as a flow execution. By monitoring flow traffic, an operator can determine the percentage of each type of flow being executed and the Web service invocations that make up each flow type.

Having detailed information about the Web services being managed by a gateway or agent is useful in analysis and problem determination. This information is also useful for service-level enforcement. Core can ping Web services by using synthetic traffic or test them using real traffic. Using results from these tests, the availability of a service can be measured against the expectations set in Core Manager when the service was defined. Alarms can be set to warn of conditions that are out of specification, and actions to be taken are specified by a set of user-definable operational rules. What's more, all these operational conditions can be viewed in convenient, graphical dashboards.

Beyond monitoring

Anyone who has run a service on a network understands the difference between operational monitoring and business analysis. Operational monitoring will tell you whether you are meeting your SLA, but it doesn't help in answering questions that require business insight, such as capacity planning in a financial transaction system. BI (business intelligence) such as this results from correlating a set of measurements over a period of time.

Core Analyzer aids in the collection and reporting of such data through the use of rules that reach inside the SOAP message body and apply Boolean expressions to the message parameters. Creating reports on these parameters is fairly easy. Even so, the rules are not a full-blown programming language, so analysis more complicated than filtering on Boolean conditions would require pulling the data out of the tool.

In the same way that reports can be created based on the information inside the SOAP body, e-mail or SNMP alerts can be sent. Rules for reports and alerts can be triggered manually or scheduled for regular invocation. Message filtering is done offline on log files and thus does not place a load on the production system.

Confluent Core provides a scaffolding for building reliable Web-services-based applications. Core is software that you install on your equipment, not a service that you buy on a per-transaction basis. The upside is that all the pieces are under the control of your organization. The downside is that all the services to be managed have to be fronted with a Core agent or gateway. Perhaps more importantly, there's no third-party broker who can provide a trusted middle ground. Nevertheless, some IT managers in certain sectors, such as financial services, get nervous when they're not in control of all the pieces. Confluent Core provides an option that maximizes this control.

I installed Confluent Core 3.0 for Windows on Windows XP Pro running on a Pentium III machine with 256MB of memory. I used Sun Microsystems Inc.'s Java JDK 1.3; version 1.4 of the JDK is not yet supported. The "typical" installation includes Core Manager, Core Monitor, Core Analyzer, a gateway, and a default agent. Confluent Core can run on either BEA Systems WebLogic or Tomcat, and it will use Oracle, SQL Server, or MySQL as its database. Tomcat and MySQL are included with Core 3.0, so I used these servers in my test.

After starting Core, I configured it to be the broker for four different Web services, one with a fail-over URL. Two of these services I installed using their WSDL file, and the other two I selected from a UDDI directory. Using SOAP::Lite clients, I was able to exercise the broker services, explore policy management, including authentication, and test the operational monitoring and alarms. In my test configuration, the management console and the service gateway were operating on the same machine, but that needn't be the case.

Core comes with an installation manual and a comprehensive user's guide, both of which were helpful in getting the system set up and working. The user's guide explains each of the system's components in detail and discusses the various options for deploying them.

Join the newsletter!

Error: Please check your email address.

More about BEABEA SystemsGatewayGrand Central CommunicationsINSMySQLOracleSun MicrosystemsUDDI

Show Comments