Managing the Web services flow

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. 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’s 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.

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.