With power comes responsibility. The promise of Service Oriented Architecture (SOA) offers significant opportunity for service reuse and the realization of a fully integrated enterprise. But left unchecked, the flexibility enabled by an SOA will result in a Wild Wild West of enterprise IT. To properly harness the power of SOA while delivering value for the enterprise, certain controls are essential. Incorporating service discovery, service security, service management, and policy governance in a ubiquitous and transparent framework is essential to the success of any enterprise SOA deployment.

With power comes responsibility. The SOA computing model offers tremendous promise to integrate the enterprise and enable reuse. But with this power comes the responsibility for its proper use. If an organization doesn't exercise sufficient control over the flexibility enabled by SOA principles, chaos will ensue.

To effectively realize the benefits of service orientation, some notions must be applied to harness its inherent flexibility for the benefit of the organization. Effective SOAs employ service discovery, service governance, service security, and service management in proper proportions. Each of these critical notions has to be understood independently and as they relate to each other. When they're combined into one seamless architecture the whole is more than the sum of its parts.

Publish-Find-Bind Notion
At the heart of a Service Oriented Architecture is the Publish-Find-Bind notion. This paradigm of loosely coupled computing is depicted in Figure 1.

Under this computing paradigm a service provider exposes its services (as service end-points) and waits for consumers to invoke those services. (Step 1 - Publish.) To find those consumers who would benefit the most from using its services, the provider "advertises" its services by publishing its offerings in a registry. This registry (usually either UDDI or ebXML standards-compliant) maintains a database of all services published in the enterprise along with details about that service to aid the consumer's discovery process. In practice, this information usually includes a WSDL file, which contains its invocation signature, as well as the URI of the end-point(s) where the service offer resides. The registry may also contain a full repository to hold additional details about each service's functions and characteristics.

Once a service is published in the enterprise registry an interested consumer may query the registry looking for services that meet his needs. (Step 2 - Find.) Developers then construct their systems using the services that they discover in the registry. The final step in a loosely coupled interaction (Step 3 - Bind) occurs at runtime. At execution time the consumer binds to the provider using the end-point URI supplied by the registry during the Find operation.

Under the Publish-Find-Bind loosely coupled paradigm, providers and consumers need not be familiar with each other prior to service consumption. The power of this notion introduces significant opportunity for chaos. For example, how to ensure that only authorized consumers can access a given service? How to ensure that all service providers secure their services properly from unauthorized consumers? How to ensure that organizational standards are followed throughout the enterprise SOA? To manage the power inherent in the loosely coupled model, additional layers of control must be introduced to ensure the benefits of SOA are realized while maintaining order.

Publish-Time Governance
Without control over an enterprise SOA, an unbounded number of internal service providers will expose and publish all manner of services for use by any consumer. A layer of governance must be introduced into this process at publishing time to ensure only high-quality services are published and that those services conform to enterprise standards. This is known as change time governance.

With change time governance, the registry validates the published service against a set of rules established by the enterprise and rejects any service provider that attempts to publish a service that doesn't conform to all established policies. Rejected services can't be consumed by an enterprise-level consumer. These policies can perform any number and manner of checks against the published service before registering it as an enterprise service. For instance, the governance tool can mandate that all enterprise service offerings follow the WS-I Basic profile and that they follow the doc/literal SOAP encoding (critical for successful WSDL first-design methodology). Many organizations adopt a specialized SOAP header for all enterprise-level Web Service invocations. These organizations frequently employ change time governance to validate compliance with those headers. Service offerings that lack this standard enterprise SOAP header are rejected and denied publication in the registry.

Figure 2 shows where the change time governance function occurs in the loosely coupled lifecycle (step 1a - Validate). This governance tool (sometimes part of the registry product) manages all the corporate SOA policies.

Runtime Intermediaries
To inject control over an enterprise SOA, an intermediary must be injected between all consumer-provider interactions. This intermediary, usually referred to as a Policy Enforcement Point (PEP), can then perform a number of functions necessary to bring order to an SOA in real-time:

1. Runtime governance enforcement
2. Security-related functions
3. Management activities

These functions are done transparently to both the consumer and the provider (save for some impact on invocation performance). Figure 3

illustrates the process by which this intermediary is introduced into the publish-find-bind paradigm.

After change time publishing and governance validation (Steps 1 and 1a), the registry notifies the PEP that it will be acting as the intermediary for the given service (Step 1b above). The PEP then responds to the registry with the new end-point at which the enterprise can access the original service. Subsequently, all inquiries to the registry for this service will return the new end-point established on the PEP (Step 2). This process is known as end-point re-writing. All enterprise level interactions with this service will go through this intermediary.

All consumers attempting to bind to the given service (Step 3) will in fact be binding to a PEP acting as the provider. It's at this point that the intermediary can perform its critical functions. Once the PEP has completed its work (assuming all went well) the consumer is bound to the provider (Step 4). From that moment onward the PEP's work is done and it removes itself from the interaction (i.e., it effectively hard-wires the consumer to the provider).

Runtime Governance
With an intermediary in place the architecture can be used to ensure that all service invocations throughout the enterprise conform to established organizational standards. The PEP is used to enforce this runtime governance. For instance, service consumers that attempt to consume a service without the proper enterprise SOAP header can be rejected. Keep in mind that service providers would be unaware that a consumer attempted to consume their service in a way that breaks organizational policies.

Figure 4 shows the addition of runtime governance to our loosely coupled lifecycle. Step 3a shows the PEP validating the consumer against the organization's runtime governance policies before letting the consumer bind to the provider's service offer.

Runtime Security
A PEP is frequently used to handle security-related functions such as authorization. Moving much of the security-related functionality to a PEP can significantly reduce the security overhead burden otherwise the responsibility of the service providers. This strategy lets the service providers concentrate on their core functionality. Additionally, these security-related functions can be consolidated in one place (the PEP), fostering re-use and administration benefits. These are significant benefits of the SOA paradigm and one of the driving forces behind the adoption of SOA.

Step 3b in Figure 5 shows the PEP invoking a Policy Resolution Service (PRS) to authorize the consumer's request to consume a particular service. To determine a consumer's eligibility to invoke a given service, the PEP forwards the consumer's request to the PRS. The PRS extracts identity information from the consumer's SOAP header (which usually conforms to the WS-Security standards and contains a SAML assertion, which are beyond the scope of this article) and authorizes the consumer using the policies in its policy store.

If a consumer isn't authorized to consume the service that he attempts to access, he is rejected by the PEP (a WS-Security SOAP error is returned) without the knowledge of the service provider.

Web Service Management (WSM)
A PEP can also be used to do transparent Web Service management. This capability lets an organization monitor the "health" of its enterprise SOA. Metrics can be gathered for each and every service invocation. Capturing this data lets an organization:

1. identify when services become unavailable and take proactive action
2. identify the most popular services in the enterprise
3. identify the consumers that consume the most services in the enterprise
4. capture response times of all enterprise Web Services
5. compile availability figures of all enterprise Web Services

The addition of Web Service management is shown in step 3c of Figure 6.

WSM can take action when a service becomes unavailable. WSM can proactively, and without the knowledge of the consumer, redirect the Web Service call to an alternative end-point. WSM can also notify the registry that a given end-point is unavailable and suggest an alternative end-point where the service can be found.

In more advanced installations, WSM periodically provides automatic feedback to the registry with metrics on service availability, response time, or other relevant characteristics. This data can then be used by consumers to identify the best (most highly available, fastest responding, etc.) service for their needs.

Performance Considerations
The PEP has a host of responsibilities, each of which may consume significant computing resources and introduce latencies. To alleviate this bottleneck PEPs can be implemented using specialized hardware. These XML/PKI-aware devices can significantly reduce the impact (processing delay) when introducing an intermediary between each Web Service consumer and provider. Numerous vendors offer such devices today, sometimes called Application Oriented Networking (AON) gear.

Putting It All Together
A real-world SOA blends service discovery, governance, security, and management. The most effective SOA deployments will factor in all of these controls. Without these controls harnessing an enterprise SOA, the enterprise IT equivalent of the Wild Wild West will surely result.