On the left side of the Workbench view is the registry navigator. This is where the tried/true enterprise taxonomy is configured. In the example, I have configured a fictitious enterprise called "ACME Financial," as well as an "Account Services" service provider sub org (which hosts the "AccountManagerService" in view) and an "Account Services Clients" sub org that ostensibly consumes the service internally. Then there is an external partner organization called "ACME Distributors" that also consumes the account manager service. Notice that each organization and sub-organization has a "Services," "Contracts," and "Management Points" folder to contain associated artifacts. We will shortly see that it is the contracting process in the tool that generates much of its power. However, before moving on let me point out some of the interesting actions on the right side of the view.

There are three types of services that the system knows about: registry services, physical services, and virtual services. Registry services are those that are somewhere in the design process but not yet necessarily managed in a container. You don't even need a WSDL to create a registry service, just a thought that a service of some sort is needed. Once it is entered into the registry, workflow and collaboration ensues toward the ultimate provisioning of a production service in a managed container. Along the way, compliance policies are applied to service artifacts as configured in policy templates associated with each life-cycle stage in the process, which is itself configurable. There are stock compliance policies that ship with the tool, like WS-I Basic Profile 1.1 compliance. Custom polices are added as XQuery expressions against service artifacts like WSDLs.

Registry services that are managed at some point become physical services. Physical services can also be created immediately if the container they are to run on has an agent. Just work your way through a simple wizard to associate a WSDL and management point and your service will be under management, and at the beginning of your established publishing cycle. Virtual services are hosted on stand-along management points and are used, not surprisingly, for mediation. The tool has compelling mediation capabilities including semantic mediation (XSLT transforms), transport mediation (SOAP to MQ, BEA-JMS, etc.), message styles (SOAP to POX, RSS, and REST), message exchange patterns (synch/asynch), reliable messaging formats with correlation, and security token formats (like Kerberos to SAML). With the addition of the Blue Titan mediation platform, the tool is able to mediate across a dizzying array of standards versions and differing standards interpretation impedances. I would go so far as to say that it is very difficult to effectively govern without a pretty far-reaching set of mediation capabilities.

Contracts and SLAs
The heart and soul of the tool is its contract and SLA management functionality. Contracts are active in the sense that they govern the utilization of services at runtime and track the relationship between provider and consumer from relationship inception through versioning and SLA changes. This is the fulfillment of the closed-loop governance vision and SOA Software has trademarked the contracting process in the tool, calling it an "Active Contract"TM. Contracts are negotiated between consuming organizations and service providers and can be applied to services down to the operation level. The tool provides configurable workflow around negotiation of service capabilities (highlighting the importance of mediation again in the context of being able to meet client demands), policies, and SLAs. Figure 2 illustrates a common SLA policy template being configured in the tool and which tracks average response time, usage count, and fault count. Figure 3 illustrates the creation of a dynamic management policy with a service consumer throttling rule. A contract could be negotiated that would establish an SLA based on the template created and a dynamic management rule that would throttle access to the service for client requests from the consuming organization under the contract when the SLA was violated and the associated alert issued.

Monitoring and Auditing
The tool provides excellent monitoring and auditing functionality. Alerts can be set up for performance and policy violation metrics, tailored to different consumers, channels, and thresholds. Dashboards are customizable to services, service groups, organizations, and roles. Audit trails provide a comprehensive view of policy violations and actions taken. The integrated view of service performance with respect to contracted policies in the context of the service life cycle and position in the enterprise taxonomy leads to great situational awareness. This is the beauty of closed-loop governance.

Other Features
In the interest of time and space, I will lump together some of the remaining features of the product that I can think of. First, I should mention rogue/unknown service discovery. Embedded management points that spot service traffic in their containers that are not in the registry cause those services to appear as "discovered services" in the Workbench view. Policies can be configured to deal with such services, e.g., block them, alert administrators, etc. Also, there is a whole aspect to the tool that deals with value governance. Value governance is a phrase that refers to being able to manage service consumption in business terms. By assigning arbitrary value to service transactions, even basing the value on the message context, e.g., a dollar value indicated by an XPath expression into the message SOAP Body, a value model can be created around strategic services. Such a model can support a pay for play charging model, which certain businesses (think SaaS) desire. The one last feature that bears mentioning is the Java and .NET delegation APIs. These APIs allow service clients to delegate service calls to a delegator, which interacts with the tools's policy repository to create a compliant service call based on the security policies in force for the service.

Conclusion
Governance is an overloaded word in SOA, and indeed an overloaded concept. Most enterprises that I am aware of would do well establishing a subset of the broader governance aspects tailored to their immediate needs - "nuts and bolts governance." To be effective, governance must be platform independent, adaptive to client consumption and service provider needs, and closed-loop in the sense that situational awareness is provided. I think SOA Software's recent revision of Service Manager (version 5.0) coupled with Workbench 5.0 serves these functions in fine fashion.