The Service Registry/Repository, in addition to tracking services and consumers, can assist you in the management and storage of policies associated with your SOA Governance efforts. It can easily play the role of a policy information point, and some products can also act as the policy management point. It is even possible to have it act as a policy decision point, although this is less common.

Being a repository, clearly the most value offered by a service Registry/Repository is as a policy information point. A core concept of SOA is that of the service contract, which is a collection of policies that govern a relationship between a consumer and a provider. These policies should be captured in the service Registry/Repository, as it needs to capture service consumers, service providers, and most importantly, the relationship between the two.

In addition to the policies that govern the interaction between a consumer and a provider, which are typically more concerned with run-time behavior, the Service Registry/Repository can also be a point where policies that apply at design time are captured. For example, a common policy associated with the design of SOAP-based interfaces is that the interface is compliant with the WS-I Basic Profile. This policy can be captured in the repository as something that must be enforced on all assets that have a type of SOAP Service.

For the pre-project governance phase, once again, the service Registry/Repository can be used to capture services from the moment they are first identified, regardless of whether any implementation of the service exists or any approved project exists to build an implementation. The service can simply be given a status of "planned" or "needed". From that point, new efforts that are seeking funding can take these services into account as they plan out their high-level architecture. Likewise, the repository can be a source of project ideas where a strategic service has been identified and entered into the repository, but no project has been proposed and approved to create it. These services would be entered into the repository as they are identified as part of the analysis efforts to define business domain models.

The service Registry/Repository can also be used to determine when the appropriate time is to decommission a service. By tracking the relationships and versions, and through integration with a service management platform that can assist in attaching actual dollar costs, candidates for decommissioning efforts can be more easily determined.

It is useful to think of the service Registry/Repository as a service lifecycle and portfolio management tool. From the perspective of the service provider, it is a tool for tracking each release of the service, the contracts with all of the consumers, as well as all of the corporate policies that apply to service design efforts. From the perspective of the service consumer, it's a way to easily find services that may be appropriate, keep up with the planned roadmap for services in use, and manage the contracts with each of those services. From the perspective of the enterprise, it provides a complete view of all of the consumers and services that are available, their roadmaps, as well as a view of services that haven't yet been created, but have been identified.

As a lifecycle management tool, the Registry/Repository can also be a trigger for events that cause policy enforcement as part of project time governance to happen. For example, when a service interface is defined and stored in the repository, this should trigger a review of the interface to check for compliance against the enterprise policies associated with service interface design.

The challenge for these tools is that there are very few standards for specifying policies and for interacting with a Service Registry/Repository. Standards such as UDDI and ebXML provide some guidance in interacting with the registry, but each tool is likely to have its own custom information model for how it represents policies. As a result, any policy enforcement point that wants to leverage a Registry/Repository as a policy information point will likely require custom integration work. All in all, the Registry/Repository is really the cornerstone of the infrastructure associated with SOA Governance. If a Registry/Repository does not exist, the individual enforcement points must each maintain their own record of the services involved. This cannot only lead to redundant data stores, but also to gaps in the data coverage where automated enforcement of policies may not currently exist.

The next piece of technology is a service testing platform. As the name suggests, these tools are focused on testing services. They may be sold as an add-on module or extension of a broader application testing platform, or they may be standalone solutions focused exclusively on services. In addition to being a tool that can automate the project-time compliance checks, they can also be a source of many "out-of-the-box" policies that can be reviewed by the people responsible for your SOA governance efforts and incorporated into the enterprise policies if deemed appropriate.

In addition to checking service interfaces for compliance with interface policies, service testing platforms also play a key role in the definition of service contracts. A service provider needs to provide baseline performance information for capacity planning purposes, the baseline's information can be captured consistently for all services through the use of a standard service testing platform. Furthermore, the testing platform can also be used to test service consumers and assist in the efforts to establish thresholds for notification and throttling. Once again, a standard tool for this purpose can be very advantageous. By preserving test scripts for each individual service consumer (which, incidentally, can be stored in a service Registry/Repository), capacity tests can be executed that include background traffic from other consumers, giving a more accurate picture of the behavior of the production systems.

As is the case with most of the tools discussed here, integration with a Service Registry/Repository is an important factor to consider. In order to automate enforcement of service interface policies, the Registry/Repository must be capable of kicking off compliance tests executed by the testing platform automatically kick of compliance checks against documented policies in at the time an interface definition is stored in the repository.

The enterprise service bus, is primarily a policy enforcement point. All service traffic is intended to flow through the bus, making it an excellent place to enforce the policies associated with a service contract. An ESB can also be used to enforce some amount of project-time policies, simply because the ESB must be made aware of the service interface in order to make it available to service consumers. Normally, however, this takes place too late in the development process to be practical.

When evaluating enterprise service bus products, be sure to evaluate them from the perspective of policy enforcement points and service contracts. The product should provide a contextual model that easily allows the configuration of policies for the enforcement of service contracts. In utilizing an ESB, one must also be cautious to define your policies for run-time service interaction first, and then use the ESB to enforce them, rather than opening up the full range of capabilities of the ESB as the default policies for communication. Some ESB products have backgrounds in EAI technologies, and as a result, can still promote and integrate anything-to-anything mentality, which will not achieve any goals of reduced complexity in your environment.

XML appliances, are also policy enforcement points for run-time SOA governance. A difference between ESB products and XML appliances is that many ESB products tend to operate more like traditional software middleware. In fact, many ESB products have roots in EAI middleware technology. XML appliances, on the other hand, tend to have an operational model more similar to a network appliance than traditional middleware. Just as was recommended with ESBs, when evaluating these products, keep in mind the policy-driven mantra of configure, not code. Look closely at the contextual model of the appliance and how well it allows for the configuration of policies for the enforcement of service contracts between a service consumer and a service provider.

There is one additional differentiator between most of the XML appliances and the ESB products, and that is in the realm of security. At least two of the major XML appliances available took a path of supporting accelerated XSL transformation first, XML security second, and then full service intermediation third. As a result, the security features tend to be far more robust in the appliances, primarily in the area of threat protection. Threat protection is not normally something associated with a particular service consumer; rather, it is a set of policies that apply to all services, scanning all requests for malicious content, such as SQL injection. There are some consumer-specific policies that this enhanced scanning capabilities can enforce,

however, such as a restriction on the size of the message. Two consumers using the same service could easily have very different characteristics in the message sizes. For example, in an ordering service, a key strategic partner may always have many line items per order, thereby increasing the size of a typical message from them, while a smaller partner may typically have one or two line items per order. Most appliances can handle policies on message size quite easily.

For both ESBs and XML appliances, a limitation is in the management capabilities. They typically have some elementary management capabilities, but if you require sophisticated management of the run-time behavior where complicated analytics are performed and then fed back into the enforcement points for SLA enforcement, you may need to look at the next type of product, a service management platform.

Service management platforms, like both ESBs and XML appliances, are involved in run-time SOA governance, providing very similar coverage. These products may have fewer supported transport options than an ESB and fewer security capabilities than an XML appliance, but they typically provide more sophisticated management capabilities. Where ESBs and XML appliances can monitor and collect metrics, they typically only make these measurements available to some other analytics engine and/or dashboard. Service management platforms, however, include the analytics engine and dashboard. This analytic capability can allow the service management platform to inspect messages and track key metrics on a per service level, a per consumer level, per service broken down by consumer, and many other ways. It will also look at metrics from all monitoring points, so if you have a load balanced or clustered environment, you can see the rate of requests across all collection points, rather than seeing the rate of requests at one particular collection point. When enforcing the policies in a run-time service contract, this is an important consideration.

Furthermore, most service management products include both agents and gateways, which create additional flexibility in deployment. For example, most service management platforms include agents for ESBs; some even can work with certain XML appliances. Therefore, it is possible to use all three, leveraging ESBs where a large number of transports need to be supported and XML appliances at the perimeter for enhanced security, while deploying agents from a service management platform on both of them.

Service invocation and exposure frameworks are a key part of the policy enforcement mechanism that may be overlooked. When Microsoft finally made a statement regarding products in the ESB space in 2005, they stated that the two key components of their solution were BizTalk and Windows Communication Foundation (WCF). WCF is a framework for both invoking services and exposing logic as services. The biggest benefit of frameworks in the SOA governance space is that by using them, compliance with certain policies should be automatic. For example, if your organization has a policy on how identity should be represented on service messages, a framework can easily extract identity from the current consumer, format it in the appropriate way, and place it on the outgoing message. Depending on the framework involved, this may only involve a code annotation, a few lines of code, or perhaps nothing at all from the developer writing the service consumer. This certainly makes compliance the path of least resistance.