Service-Oriented Architecture

In last month's article, we discussed the motivation for SOA governance and the areas where governance should be applied. We also pointed out that, while SOA governance is not a shrink-wrapped product that you can simply implement off-the-shelf without also addressing important organizational and procedural issues, putting the right software mechanisms into place enhances the ability to automate the enforcement of policies and controls.

 This article outlines the key moving parts of an SOA governance system that performs such policy-related functions.

At a basic level, an SOA governance system should facilitate governance across the service lifecycle from design time to run-time to change time. It should allow polices to be defined and created, and provide mechanisms for these policies to be enforced at each phase of the service lifecycle. (See Figure 1)

The main components of this system include:

• A registry that acts as a central catalog of business services
• A repository for storing policies and other metadata related to the governance of the services
• Policy enforcement points, which are the agents that enact the actual policy enforcement and control at design time, run-time, and change time
• A rules engine for managing the declaration of policies and rules and automating their enforcement
• An environment for configuring and defining policies and for managing governance workflows across the service lifecycle

Registry
A registry is usually identified as one of the first requirements of SOA adoption and registries play an important role in governance. In simple terms, a registry is a catalog or index that acts as the "system of record" for the services in an SOA. A registry isn't designed to store the services themselves rather it indicates their location by reference. Having a centralized catalog of services is significant from an organizational perspective because it enables the easy discovery, reuse, and management of services.

An SOA registry typically fulfills the following functions:

• Stores service descriptions, information about their end-points (the network resource where the service functionality is implemented), and other technical details that a consumer requires to invoke the service such as protocol bindings and message formats
• Allows services to be categorized and organized
• Allows users to publish new services into the registry and to browse and search for existing services
• Maintains service history, allowing users to see when a service was published or changed

As the place where services are made known in the SOA, a registry is also a natural management and governance point. For ex-ample, compliance requirements - such as conformance with the WS-I Basic Profile or the use of specific namespaces and schemas - might be imposed on services before they can be published in the registry. Or, as services are registered or changed, the registry can also trigger approval and change notification workflows so that stakeholders are alerted to changes. As such, a robust registry is an important component of any SOA governance solution.

Another important factor is the interoperability of the registry with other components of the SOA infrastructure. OASIS provides a platform-independent standard for registry interoperability known as UDDI (Universal Description, Discovery, and Integration). UDDI defines a Web Services-based programming interface that allows different consumer applications, tools, and runtime systems to query the registry, discover services, and interact as required to provide management and governance capabilities. While it's not a prerequisite for an SOA registry to be based on UDDI, it is the most commonly adopted standard and ensures the greatest degree of compatibility with other products in the environment.

Repository
While the registry plays a central role in policy enforcement, the registry itself doesn't provide sufficient context for the breadth of SOA governance requirements described in this article. For example, policies - in the form of rules and restrictions that are enforced on services - and consumer/provider service-level agree-ments are generally not constructs that are stored in a registry (for one reason, they aren't constructs that are known to UDDI). So another data store, usually referred to as a repository, is needed to store governance-related artifacts and support the full complexity of managing service metadata throughout the service lifecycle.

The term "repository" is used in many different contexts - for example, a data repository (SQL database), a document repository (file system), or a source code repository (version control system) - but in the context of SOA governance, the repository can be thought of as a centrally managed policy store.

Among other things, a governance repository should support the following capabilities:

• An information model or taxonomy for representing and storing organizational and regulatory policies that can be translated into rules that are enforced by the SOA governance system. It should be possible for policies and rules to be interpreted by people or machines (and sometimes both) as appropriate.
• Audit capabilities for tracking the trail of changes and authorizations applied to assets in the repository context.
• Identity management capabilities and role-based access controls to ensure that only appropriate parties have access to policies.
• A notification system and content validation capabilities to provide additional assurances that policies are well-formed, consistent, and properly applied.

The requirement for a logically centralized repository is particularly important for codifying and enforcing a single "official" set of policies across the organization. However, the actual repository itself may have a federated architecture for scalability and for using the repository across different geographic regions, multiple lifecycle constituencies, and corporate boundaries.

The Advantages of an Integrated Registry/Repository
While the registry and repository have been discussed as separate concerns, in practice there are many benefits to combining the two functions into a single entity. To function properly together as a system, the registry and repository should maintain a consistent view of service definitions, service versions, consumer and user identities, and other information. Implementing them as separate products creates the burden of duplicate data entry, sets up the need to synchronize information, and increases the risk of inconsistencies between the two.

When the registry and repository are unified with a single normalized and standards-based information model and underlying datastore, the integrity of both governance-related metadata and the information model can be assured. The unified approach also eases the enforcement of policies that apply across the boundary between the registry and the repository.

Standard registry capabilities can be offered by an integrated registry/repository with a UDDI interface to the policy repository that allows access to the relevant data.

Policy Enforcement Points
So far the role of the registry and repository has been established and the case made for an integrated registry/repository to create a consistent policy context. These policies, in turn, need to be enforced. In an SOA governance system this function is ful-filled by policy enforcement points.

The places where policies are actually applied and enforced - the policy enforcement points - change depending on the lifecycle stage. During design time, the registry/repository itself is the point of enforcement. During runtime, policies are generally enforced by the underlying message transport system that connects service providers with consumers. Finally, during change time, policies are typically enforced by the IT management system.

Design-Time Enforcement: Registry/Repository
Since the registry/repository is the system of record for both service interfaces as well as the assets, attributes, and metadata associated with them, it provides a logical point at which to enforce policies about the design of these particular artifacts. Design-time policies are typically applied as artifacts - which could include WSDL files, schema definitions, process models, and project documentation - are checked into the registry/repository.

The following features are desirable in the design-time policy enforcement point:

• Identity management: To establish rights and responsibility in the registry/repository it's first necessary to identify users (for example, via an LDAP-based identity systems or other directory), service consumers, and other participants. Identity is also important for metering usage, logging for audit purposes, and applying approval requirements and other govern-ance processes on an individual or role-based basis.
• Access control: Coupled with identity management, the system should offer fine-grained access configurations over all aspects of registry/repository assets. This includes the ability to secure assets as well as policies, governance processes, and asset classifications.
• Automated notifications and approvals: The ability to trigger events in response to Create, Read, Update, or Delete activities in the registry/repository allows alerts, approval processes, content validation scans, and other actions to be auto-mated. These triggers might be applied either before or after the interaction in question. For example, a policy might be established that a design review approval is needed before an object is created in the registry/repository.
• Content validation: Content (in the form of assets that are checked into the registry/repository) should be scanned and validated according to their type and pre-configured compliance checks. Common validations include WSDL validation, XML schema validation, testing for namespace violations, schema validation, and other interoperability-related scans. For example, service consumers expect interfaces to be well formed and interoperable, so the registry/repository should automate the process of scanning and assuring that WSDL documents are well formed and conformant with WS-I interoperability profiles.
• Audit trails: A fundamental capability for establishing accountability is the ability to track interactions between participants and the registry/repository, along with the sequence and details of those activities. This record can be used for governance enforcement "after the fact" and to establish usage patterns for guiding process improvements.

Runtime Enforcement: Message Transport
Runtime policies are enforced by the SOA mediation layer - which will typically be a SOAP/HTTP-based message transport - along with the registry/repository that fulfills the function of service discovery and policy store. As an intermediary between service providers and consumers, the message transport can exercise policy controls transparently to the underlying services and to the message flows between them.

Without SOA, the ability to control applications in this manner is restricted both by the scope and capabilities of the underlying platform. When different applications are integrated, it is generally difficult to apply a common policy context to the integrated result. A typical challenge is enforcing access security when two applications with different user communities are integrated. For example, application A automatically draws data from application B, but application A users aren't authorized to use application B. How do you now control the data that users have gained access to in application A? With the intermediation provided by the message transport, it becomes possible for a distributed network of services to share a common policy-managed context. This is a powerful capability that emerges as a direct result of SOA.

Since runtime policies are typically applied to messages that flow across the message transport system, the specific types - and level of sophistication - of runtime policies that can be defined and enforced depend on the capabilities of the underlying intermediary.

Desirable runtime policy enforcement capabilities include the following:

• Consumer identification and security: Identifying consumer applications to prevent unauthorized access to services; configuring the security of services at runtime and enforcing policies such as encryption (for message confidentiality), digital signatures (for message integrity and nonrepudiation), and logging for tracing and tracking.
• Routing rules: Configuring runtime routing rules to address performance, version management, and other opera-tional requirements. Variations include: content-based routing (examining a message's content to determine where to route it according to specific rules, for example, processing certain types of orders via a different process); version-based routing (to support version management and the deprecation of services); and preferential quality-of-service routing (giving consuming applications different processing priorities based on business priorities and defined service levels).
• Transformation rules: Translating between different message transports and technology protocols to facilitate applica-tion connectivity, or transforming data between consumer and provider.
• Service Level Agreement (SLA) management: Policies for managing performance and availability to match the require-ments of an SLA, for example, routing a request to a backup service in the event of a failure of the primary service provider, or balancing the request load across additional back-end service to improve performance.
• Logging, monitoring, and alerting - Collecting service-level data and establishing rules based on aggregate counters for response time, throughput, errors, and other transaction data so that alerts can be generated when there are violations to predefined SLAs.

Finally, while the intermediary and registry/repository are logically decoupled, a dependency exists to the extent that the in-termediary has to understand and interpret the policies defined in the registry/repository. As such, it's advantageous to have a message transport system and registry/repository that are interoperable out-of-the-box; otherwise, this is an integration issue that the implementer has to address.
Change-Time Enforcement: IT Management System

Whereas design- and runtime policy have "hard" gates - approval for access to the registry/repository and connectivity via the message transport - change-time enforcement relies to a greater extent on IT change management practices and procedures than on enforced control points. Nevertheless, the IT management system - collectively, the set of systems management software tools and services that the IT organizations uses to manage, monitor, and control their business applications and software infrastructure - and the registry/repository combine to play an important role in change-time governance.