Tools for Taming Web Services Management
Tools for Taming Web Services Management
By: Matthew Fuchs
Dec. 31, 2003 12:00 AM
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
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
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.
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.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week