As departments and organizations in the enterprise adopt Web services, the importance of managing and securing, and in some cases, extending these services to partners, grows. Using a centralized platform to do it reduces the effort and cost involved, while upping security. Web Services Manager from Oracle is designed to meet the challenge of stitching together services in large enterprises into a single management system.

The Web services management functionality in WSM is built on the following basic components:

• Policies: Sets of rules, transformations, and/or constraints that are applied to inbound and outbound service requests.
• Gateways: These components are the enforcement points for policies and serve as proxies to Web services, isolating them from clients. Gateways can be put in front of any Web service, hosted in any environment, local or remote.
• Agents: Similar to gateways in enforcing policies; however, agents execute in-process on the server the Web service is hosted on and intercept all incoming and outgoing service traffic. They offer more tightly integrated control over individual operations on a service.
• Monitor: Collects data from gateways and agents and presents them to administrators in graphical format.

For purposes of this review, I have created a series of Web services for personal data management: a music collection service, a movie collection service, a workout log service, and a ledger for tracking basic expenses. WSM will be used to manage, secure, and monitor these services.

Gateways
As mentioned, gateways in WSM serve as proxies to Web services. Their behavior is similar to the Controller component of a Model-View-Control (MVC) application. A gateway serves as the entry point for service calls and routes traffic to the appropriate back-end Web service based on the content of the request document.

Establishing a gateway is as simple as assigning it a name and a URL. The URL will ultimately serve as the endpoint for all Web services managed by the gateway. Once created, each applicable Web service must be registered. WSM can read service descriptions directly from a WSDL file or from a UDDI registry.

Figure 1 shows the service registration screen for a gateway created to serve as the entry point for the personal data management services already created. In this example, the Workout Service will be imported from a WSDL file. WSM requires a service name, version, the URL of the WSDL document, and the protocol on which the service operates. Once imported, WSM creates a new service URL and WSDL document that point to the gateway, hiding the true endpoint of the service from the calling clients.

Notice that Figure 1 highlights one of the most powerful features of WSM: the ability to transfer between protocols. Out-of-the-box, WSM's gateways can transfer SOAP over HTTP(S) to a JMS or IBM MQ Series messaging system. The system can also be extended to support additional custom protocols. This capability provides the immediate benefit of exposing internal, heterogeneous Web services on a single protocol.

With all services registered in the gateway, WSM must be configured to route incoming service requests appropriately. The system provides an XPath-based content-routing mechanism that supports inspection of either the SOAP Envelope or a SOAP Attachment. (Note: When inspecting an attachment, its content must contain XML and be referenced in the SOAP Envelope according to the SOAP with Attachments specification.)

In the case of the gateway we just created, the content-routing instructions must be established for each of the registered data management Web services. For example, the routing instruction for adding a record in the movie collection service is based on the XPath statement:

soap:Envelope/soap:Body/wsj:Action = AddMovie

As shown in the XPath statement example, routing instructions are namespace-aware. WSM automatically presents an input field for each referenced namespace in the statement.

When messages are received by the gateway, content routing is done in the order in which the instructions appear in the console. This order may be adjusted manually to optimize processing efficiency.

Agents
WSM agents are in-process components that are installed directly into the application server and operate as a client or server. Client agents are used when an application acts as a client to other Web services. Server agents are used when an application is exposed as a Web service to calling clients.

Unlike gateways in which service calls are routed based on their content and/or operation, all requests to or from an application on a server with an agent installed are processed by the agent. On Java servlet containers, agents can be deployed as JAX-RPC handlers or as servlet filters. Out of the box, Oracle supports Apache Tomcat with Axis, BEA WebLogic, and Tibco BusinessWorks. The new release will include support for Microsoft IIS as well as IBM WebSphere.

Setting Policies
There's a high degree of flexibility in the policy administration in Oracle WSM. Each policy consists of a set of pipelines that in turn is a collection of individual steps. WSM comes prepackaged with steps for encryption, decryption, authentication, authorization, logging, quality of service monitoring, SAML and XML transformation. Customized steps can also be developed based on the WSM framework.

A policy consists of four separate pipelines:

1. Pre-Request Pipeline
2. Request Pipeline
3. Response Pipeline
4. Post-Response Pipeline

There is no restriction in the steps that can be executed in any of the pipelines. The product documentation recommends that enterprise-wide policy steps be maintained in the pre- and post- Pipelines, while service-specific policy steps be maintained in the request and response pipelines.

To illustrate, I've modified the expenses ledger service to use a slightly different document structure. The service itself will support both document structures. Instead of modifying the client for the new structure, however, I will insert steps to transform the incoming and outgoing document via XSL. To configure this in the system, WSM simply requires a valid URL or physical file location for the stylesheet.

Once configured and deployed, the calling client sends the original document to the server, the gateway intercepts it and transforms the document via the newly configured XSL pipeline step, routes the document to the appropriate service, gets a response, transforms the document back to its original form, and returns the result to the calling client.

Monitoring
WSM also provides a solid set of monitoring and analysis tools for managing services. Data is presented to administrators in a dashboard display that can be customized to target specific information. Alerts can be configured to identify specific service conditions. For example, WSM supports latency checks to ensure that managed services are operating according to predefined service levels. This is just one example of its wide variety of management and monitoring capabilities.

Summary
Managing, securing, and extending individual Web services applications in an enterprise is a daunting challenge that grows with the increased adoption of the technology. Oracle's WSM helps meet that challenge by providing a strong platform for defining and enforcing security policies. Its monitoring capabilities help organizations meet service levels and identify potential bottlenecks. Additionally its support for multiple platforms makes it applicable to many different environments. Overall, Oracle's WSM delivers on Web services management and administration and is a good option for enterprises.

SIDEBAR:
Company Info
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
Web: www.oracle.com
Phone: 1.800.ORACLE1

http://www.oracle.com/technology/products/ias/index.html