|
DEVELOPER: Web Services
Managing Web Services
By Mike Lehmann
Taking advantage of SOAP on the wire
If you think the term Web services is loosely defined in the industry, try looking for a clear definition of Web services management. Some think it is as simple as Web service configuration, monitoring, auditing, and logging. Others speak more abstractly, using terms such as service virtualization, notifications, protocol mediation, and provisioning.
Let's explore this area, which frequently comes up as soon as you move from working with a handful of Web services to more-full-fledged business scenarios in which dozens of Web
services are tied together in a business process or composite application.
Web Services Component Management
At the lowest level, a Web service is just another program executing on your back-end infrastructure. From a management perspective, there are some core basics you expect a platform to provide for Web services management. These include deployment, configuration, and security support, combined with some basic monitoring and diagnostics.
With Oracle Application Server Control, the management console of Oracle Application Server 10g, these basics are well covered, as shown in Figure 1. By using this browser-based environment, you can easily manage
any J2EE Web service.
Figure 1: Oracle Enterprise Manager 10g, Application Server Control
As the industry moves to J2EE 1.4, this console will evolve to enable developers to configure and monitor all the new artifacts from the JAX-RPC standard, including JSR 109 configuration, JAX-RPC handlers, and, moving forward, Web services reliability, transactions, and security. This integrated management console represents a key value in standardizing JAX-RPC as part of J2EE—the management infrastructure your J2EE server offers will apply equally well to Web services as it does to classic J2EE components.
In the Oracle Application Server Containers for J2EE 10g (OC4J) Developer Preview 10.0.3, where I have built JAX-RPC examples (see NextSteps), the management infrastructure underlying Application Server Control has been extended to include Java Management Extensions (JMX). Here, the previous capabilities are still available but the new management console will configure and monitor Web services via standard JMX MBeans. To look at the Web service MBeans through a JMX browser directly, go to http://127.0.0.1:8888/adminoc4j of your OC4J 10.0.3 Developer Preview and query on Web service MBeans.
The Difference with SOAP
Although managing the Web service as a component offers a compelling start to managing Web services, it overlooks the key aspect that makes most Web services different from binary-protocol-based
programming models such as CORBA
and DCOM: Web services are a messaging technology in which the messages on
the wire are XML-based (Simple Object Access Protocol [SOAP]) and are described by XML (Web Services Description Language [WSDL]).
In my last column, I explained how
to write a JAX-RPC handler to do content-based SOAP logging and auditing. The power of that approach is the ability to intercept, query, and manipulate a raw XML message en route to its destination.
This approach involves several issues, despite the immediate attraction of full access to the message on the wire. For example, for a relatively generic utility such as logging or auditing, it isn't particularly simple and declarative—a handler has to be custom-written and configured for each Web service. Although handlers make hard things possible, they don't make easy things simple.
If you step back even farther and imagine running Web services in a heterogeneous environment—likely the most common use case for Web services, because at their core, they are an integration technology—handlers become even more problematic, because they are specific to JAX-RPC and do not work if your Web service endpoint is implemented in C, Visual BASIC, or Perl.
|
Original Inbound SOAP Message Body | SOAP Message Body With New Parameter |
...
<env:Body>
<ns0:getEmpSalaryElement>
<String_1>7369</String_1>
</ns0:getEmpSalaryElement>
</env:Body>
...
|
...
<env:Body>
<ns0:getEmpSalaryElement>
<String_1>7369</String_1>
<salary_type>Commission</salary_type>
</ns0:getEmpSalaryElement>
</env:Body>
...
|
Table 1: Example of how requirements of inbound SOAP message can change
Managing the Message
A more general approach is to put an intermediary between the service consumer and the service provider. Intercepting wire-level traffic to do out-of-band processing is not a new idea. It is already used in the Web world by hardware and software to implement load balancing, acceleration, routing, and caching.
Once you realize that you can not only inspect and manipulate the content of the SOAP message but, through WSDL, also have a full understanding of the format of the message, its operations, and its endpoints, the possibilities of this approach become quite interesting.
For example, take a simple use case based on the Employee salary service from my last column. This service takes an employee number and returns the matching salary information. Imagine that after several months of operation, the service starts being used by several major entities within the company and that many people are requesting that it include commission information as well. The developers decide to ask the users of the service to alter the inbound message, which previously was just an employee number, to have an extra parameter, <salary_type>, indicating whether salary, commission, or both salary and commission should be returned. Table 1 shows the difference between the two formats.
In an ideal world, both the provider and the users of the Web service would alter their environments simultaneously to support the new parameter, and the system would be upgraded. In the world of Web services, where the provider and the consumers often have different priorities, unrelated upgrade schedules, and often hard-to-change infrastructures, the logistics of these upgrades are staggering.
The solution? There are many options with a management layer that understands the message on the wire. One option is to look on the wire for messages with the old signature and route them to an old implementation—a simple versioning solution. Another approach is to transform old-style messages without the <salary_type> parameter to include a default value. This type of implementation abstraction is called service virtualization.
The result of this approach is that
the service provider can upgrade on a schedule independent of the service consumers'. Better yet, because the management process happens on the wire, independent of implementation, it is
possible to upgrade even if your back-end environment consists of heterogeneous Web service implementations. Correspondingly, the service consumers can choose to upgrade or take advantage of the new feature on their own schedule.
There are many practical uses for this infrastructure. What if your customers are demanding SOAP messaging but you have been unable to upgrade your binary-based back-end infrastructure? You can use this approach to mediate between an inbound SOAP protocol and a binary protocol in your back end. Or, you could route the message to different machines, based on factors such as the type of customer sending the message or the need to schedule machine upgrade cycles.
It is with this thought process and emerging prototype implementations that much hyperbole has emerged around Web services management. It is a natural complement to other emerging Web services standards in reliability, security, transactions, grid, and even business process management. But the important thing to remember is that it is not magic; it is simply taking advantage of and innovating with the inherent features that Web services bring to the table.
Standards, Standards, Standards
There is already a concerted effort under way to enable management of Web services as a resource. The standard most vendors are pursuing is Web Services for Distributed Management (WSDM), an OASIS effort that will do for Web services what Java Management Extensions (JMX) did for J2EE applications: provide a vendor- and implementation-independent way to treat heterogeneous Web services as manageable resources.
What the standard practically turns into is a set of Web services and operations each Web service implementation will be expected to provide—operations for configuration, monitoring, and other management tasks. If implemented according to the standard, any Web service will be manageable by a WSDM-compliant management infrastructure.
The OASIS WSDM technical committee began its standards efforts in February 2003 and continues to work on a 1.0 standard, expected in mid-2004.
And in the next major release of the Oracle Application Server, expect to see Web services management as an area that will get increasing attention.
Mike Lehmann (mike.lehmann@oracle.com) is a principal product manager for Oracle Application Server Containers for J2EE.
| 
Bookmark
