WSJ Management

As Web services move beyond opportunistic implementations and proof-of-concept deployments to support enterprise-wide services in mission-critical applications, the need for Web services management becomes ever more pressing. While Web services present a tremendous opportunity for organizations to improve coordination and integration both within the enterprise and with old and new business partners, dealing with a multitude of partners with changing requirements in an open heterogeneous environment also provides new opportunities for failure. These problems can be mitigated through the use of policies representing proper procedures and best practices. It is the role of Web services management to allow users to choose procedures, establish best practices, and then enforce them in real time.

I will discuss the touch points for applying these policies and some means of organizing them so your Web Services Management Platform (WSMP) doesn't become, itself, unmanageable. We use two organizational techniques for this: service views, a way of organizing Web service operations for different audiences; and policy groups, a way of organizing policy decisions applicable to multiple operations. First we will show how management concerns arise from an examination of Web service messages and then show how these two concepts provide an effective means of organizing management policies.

Web Services Management Areas of Concern
In choosing what to manage, there is an inevitable trade-off between processing that happens in the manager and processing that happens in the Web service. At one end is information that must be tracked globally for the whole network to function, or policies that must be consistently applied across many services. At the other is processing that is more application specific, but more easily handled by the manager and can insulate the application from changes, such as transformations into and out of standard formats. Perhaps the best way to show the many ways management can impact message processing and provide stability is to observe the handling of a message or two by a Web Services Manager. Listing 1 presents a short Web service message - in particular, a Simple Object Access Protocol (SOAP) message. Looking at this message, we can ask a number of WSM-related questions:

• Mitigating outside attacks: Along with the message, we have the (alleged) IP address of the originator. How many times has this IP attempted to access this service? Have there been a slew of unsuccessful attempts indicating an attempt to break into this service or related ones? Should we block this IP? Should we shut down the service? Who do we inform?
• Information security (encryption/signature): The message contains a WS-Security header block indicating a signature for certain parts of the document. Who signed these elements? Where is the Certificate Authority (CA) for this signature? Is there critical information that hasn't been signed? Is there information that needs to be encrypted given its source or destination? If we need to sign/encrypt it, which key do we use?
• Access control: Who is this message from/ to? How do we identify them? Are they allowed to access the service they are contacting? Once we identify them, do we need to switch credentials to access the ultimate service? Do we need to filter information in the Web service's response? If they have no access rights, who do we inform?
• Metering/resource management: Is there a cost to access this service? What account should be used? How much do we charge?
• Quality of service and service-level agreements: Is the service up? What is its response time? Given two simultaneous requests, which is serviced first?
• Quality assurance: Is the message valid according to its schema? If I've transformed the message, is the new message valid? Do the values make sense? Is it the expected response?
• Standards implementation and conformance: Because SOAP itself allows so much variability, other groups, such as WS-I, have specified best practices for conforming SOAP messages. Is this a SOAP message? Is it SOAP1.1 or SOAP1.2? Is it WS-I Basic Profile compliant?

Because of the heterogeneity of the network and the variety of clients that need to access an ever-burgeoning list of Web services, the answers to these questions can vary considerably depending on who (requestor) is sending what (message) over the network (channel) to whom (receiver/base service). This tuple (sender, message, channel, receiver) is the key to these different answers. Any set of answers represents a policy, a specification of how your system will react to a particular set of circumstances.

The sheer amount of work required to support the entirety of this agenda makes implementing a management capability on a Web service-by-Web service basis prohibitively expensive. Clearly the work required to build a management capability from scrap far overshadows the cost of implementing any single Web service.

Organizing Policies and Services
XML provides the possibility to directly examine and operate on the message stream, and many common policies require examining, if not actively manipulating, the message. Therefore, WSMPs tend to use an intermediary or broker architecture; messages between the requestor and the base service first pass through the manager. The manager sees a sequence of structured messages from a particular network port destined for another network port. While it is possible to design policies exclusively at the message level, this inevitably leads to diminishing returns. In a complex environment, the set of if-then-else conditions to first determine the (sender, message, channel, receiver) tuple and then answer our list of questions will be torturously complex. With no abstraction level above the message, all the decision logic must be specified explicitly, while a more abstract view would answer many of them implicitly. Additional layers up the stack include the operation level, the port level, the service level, and even, in the other direction, the XML element level. In addition to messages, there are the requestors to consider as well. Service views and policy groups are two techniques to organize these various levels according to the changing requestor/message/channel/operation mix so they can be managed in concert, rather than in conflict, in a way that simplifies rather than complicates.

The key standard for organizing Web services is the Web Services Description Language (WSDL). WSDL organizes operations by endpoint and specifies the structures for messages to those endpoints. It has also become the focal point for specifying other information about services. A <definition> element contains a list of services, ports, bindings, and operations. Nevertheless, what may appear as a logical organization of operations from the developer's viewpoint may no longer be so when looked at from other perspectives. Different sets of users will be allowed access to different sets of operations with different access rights using different authentication mechanisms. Mixing all of these in a single WSDL is dangerous.

But there's no reason to see a WSDL <definition> as universally valid. We can treat a WSDL <definition> element as a protocol for a provider to communicate a permitted set of operations and policies to a specific set of users. Internally, we can link a given <definition> with a particular set of policies about messages, ports, and operations. We take a particular set of (sender, message, channel, receiver) decisions about some set of services and formulate those as a set of policies. From those policies we generate a <definition> element reflecting those policies, and send it to the particular requestors to whom we wish to apply those policies. The <definition> can therefore serve as a tool for management and a mechanism for conveying policies, with different sets of users receiving different WSDLs, even with different addresses, although the underlying operations may be the same.

We call each of these a service view by analogy to the database view of SQL. In many ways, this is an extension of the WSDL <binding>, which provides for multiple serialization formats for Web services messages, depending on the characteristics of the recipient. Another analogy is to interfaces in traditional programming languages, such as Java. In Java, a single object can support any number of interfaces, with each different interface including a subset of the methods of the class. A client object sees another object by the interface provided, without knowing about the underlying class and any other methods available.

For example, in Listings 2a and 2b we see abbreviated WSDL for two services - purchase orders and support - where there may be a variety of clients, or service requestors, some internal to the organization and some external. Both services, though, are designed for internal customers.

In Listings 3a and 3b we can see two different service views of these operations. In each case we've organized a subset of the operations into a single port with a new address, combining operations from both underlying services. Immediately we've divided our users into two groups that will access different mixes of our underlying base services through different routes. In Listing 3a, the "AcmeSpecialService", authentication is specified by adding username and password fields. This is accomplished differently for the RPC- style SubmitIssue from the document-style SendPurchaseOrder. In the first case, extra parts can be inserted directly into the message. In the second, because everything needs to tie back to a W3C schema, we create a new namespace to house the extra elements and then add them to the message. In Listing 3b, the clearly more sophisticated ZenithSpecialService, we've added features. For example, we've added a WS-Security header to the mix, specifying the use of WS-Security as the access mechanism. This also requires importing the WS-Security schema. We've added a WS-I Basic Profile (BP) conformance claim and associated header. But because BP doesn't support RPC encoding, a document-style equivalent needs to be generated (including a new schema corresponding to the namespace). These indicate different levels of integration, depending on the sophistication of the clients.

In essence, the service view allows a constellation of concerns - service requestors, operations, formatting, authorization, and authentication - to be unified in a single view. While the number of different combinations of these is astronomic, in reality there will be very few. With a service view, the actual combinations can be brought together and easily managed by a set of consistent policies. The original service, now hidden behind and protected by the view, remains the same. Other policies not directly describable by the WSDL can still be segregated by view. For example, the authentication mechanism used can be assigned on a per-view basis. Then policies regarding requestors from a particular location - such as Acme - need only be tested for messages coming to specified ports - as only requestors from the targeted group will be authenticated.

The other organizing principle, the policy group, provides a mechanism to specify policies applying to operations in multiple views, or to a subset of a view. For example, a service view can provide a mapping from requestor to role, but the rights granted to a role may be linked to the underlying operation and be consistent across views. A role can be used to control access to operations within a view (in a traditional access control fashion) or enable content-filtering policies to control the content of a message (limiting the size of a purchase order is a commonly used example).

Additionally, there may be policies applicable to a variety of operations, regardless of which views they appear in. A policy that cuts across both service view and policy groups would be a policy to prevent a requestor from seeing information concerning other organizations. The Web service in Listing 3b allows customers at Zenith access to the ListOpenIssues operation. A logical policy would be to restrict Zenith to viewing only its own issues, but the underlying operation may not be able to do so. A policy employing a filter could implement this for the Zenith view, but a more general policy would be to apply this restriction to any organization with access to the underlying operation. This can be implemented by a filter to stop the message, or a transformation to excise the information. The policy would apply across many operations, but the identity of the requesting organization comes from the view. As different operations have different structure, the filter or transformation would need to be attached to the underlying operation. The policy would be applied across all operations, using either a service view-supplied organization name and the operation-specific filter or information from the incoming message. Were these not present, the policy would fail.

At present there is no uniform way to describe the variety of policies that may be applied to Web services. WS-Policy, a set of proposals related to WS-Security, may provide a means for naming the policies being applied to a particular service view; however, policy implementation will undoubtedly remain proprietary to different Web service management products. The degree to which they are automated will also vary from WSMP to WSMP.

Conclusion
I've described a number of practical issues related to forming effective policies for managing Web services as messages flow back and forth. Given the large number of these and the multitude of ways they can interact, we've described two mechanisms, service views and policy groups, that provide an effective means of organizing policies into different coherent groups and reflecting those groups out to partners as WSDL. By presenting different specific WSDLs to different groups, an organization can succeed in controlling the cacophony of different agreements and capabilities of many partners, as well as insulating the underlying base services from the filtering, authentication, authorization, and other ancillary processing performed at the management layer.

The field of Web services management is still in the early stages, but already it has shown itself to be a complex area requiring new techniques beyond previous management tools. New complexity generally requires new abstractions to reorganize information and keep it from degenerating into chaos; service views and policy groups are techniques to control the additional requirements and possibilties of Web services. Without this, Web services themselves will become a drain on the organizations that deploy them. But they sit at the bottom of a new stack of management issues surrounding Web services. Above this are other exciting areas, such as business process orchestration and real-time business intelligence. What new techniques will be added to the list will become apparent as this technology moves to maturity.