Web Services Design for Governance

Agent-based and proxy-based approaches to Web Services design for governance, the associated semantics, and related benefits and trade-offs of each management approach are outlined in this tutorial.

Architecting an Effective Web Services Design

Every organization is unique, but in general the initial requirements for Web services management fall into two categories:

• Some organizations focus on the application of operational functions to their services to better implement and insulate changes as they happen. Such an environment is characterized by the need to have a great deal of flexibility in deploying services to different consumers, such as a large organization delivering shared services across the enterprise and beyond, or for securing Web services flexibly.
• Other organizations are more interested in the ability to understand what services are available and how they relate to each other, without impacting the existing service delivery architecture.

The first suggests a Web services proxy-based approach, while the second indicates a Web services agent approach. Actional supports each as outlined below.

Neither Web Services Design Approach is "Better"

Before discussing these two approaches in more detail, it is important to realize that neither approach is inherently better or worse than the other. (See our comparison of Web Services Tools) They are, in fact, complementary over the long term. What drives the starting point are the short-term concerns: where you're feeling the pain, and what capabilities are required to eliminate it.

Often, vendors play with words, making of the decision a semantic game rather than an open discussion on features and benefits. Let's propose some quick definitions to help you understand the discussion that follows.

A proxy can also be called an intermediary or a broker. In the terminology used in this essay, all three words are functionally equivalent. And, whether or not something is a proxy has nothing to do with "where" it runs, rather it has everything to do with "how" it runs. One sure giveaway: if you install the same piece of software as both an agent and/or a proxy, then what you end up with is either a bloated, low-performance agent, or a proxy with only partial functionality.

A Brief Description of Both Approaches to Web Service Design

A proxy has the following characteristics:

• Intrusive. It requires some configuration to take services under management. This is not a bad thing, it's just the nature of the beast.
• High-functionality. The proxy adds different, but important, functionality to that of an agent (it has an agent built in) for managing both services and the service infrastructure. Proxies provide critical functionality like service versioning (in coordination with UDDI if necessary), provisioning, message transformation, routing, cross-domain security protection, and so on.
• High performance, but not as good as an agent. Performance should start at the low (single) milliseconds but will increase as the intermediary does more to each message that passes through.

An agent has the following characteristics:

• Zero administration. Agents should have no configuration whatsoever with regard to visibility of the Web services being taken under management. Since there is no configuration required, you are able to avoid the disadvantage of rogue Web services and related Web service problems in the network that are unable to be managed. If there is a Web service on the network communicating with an application server that has an agent installed, it should be detected, you should be notified that it exists, and you should be able to apply policy to it.
• Very high performance. Agent performance should be measured in microseconds.
• Correlates flow through an application. Agents should be able to manage both inbound and outbound Web services calls from an application server (with just a single agent). Unbelievably, most solutions require two agents if they are to manage both inbound and outbound calls. Additionally, correlation should be done without any additional development, or development changes to the Web services.

In Summary

Two key points fall out of this semantic diversion about Web services design, proxies and agents:

• If it doesn't correlate flow through the application, it's not an agent. In fact, if it doesn't correlate flow, you can't do root cause analysis, so it's really not a complete management solution.
• Be careful on performance. In competitive benchmarks, some proxies have performed better than competitive agents!

Read further to understand how to make sense of these Web services design issues and to decide which solution – proxy-based or agent-based – is the right place to start.

For More Information

Discover the details of Actional's Web services design for governance: download the free webinar, Runtime Governance