Service-Oriented Architecture

As such, managing the SOA lifecycle is an intrinsic part of SOA governance. In general, SOA lifecycle management revolves around:

• Ensuring the quality, performance, and applicability of services that are published;
• Providing a way for consumers to discover and reuse services and other artifacts;
• Managing versions, security, and the state-change of services and other artifacts; and
• Assessing and managing the impact of change across a network of consumers.

Although it's a common mistake to treat the requirements of providers and consumers similarly, their needs are quite unique. Because of the loosely coupled nature of providers and consumers in an SOA, there are actually two parallel yet distinctly different lifecycles at work in an SOA.

Service providers focus on the lifecycle of individual services as they are designed, built, and deployed. In general the provider lifecycle is centered on:

• Understanding and managing the service requirements;
• Managing service access and visibility;
• Publishing information to support the reuse of services; and
• Managing an infrastructure to deliver on quality-of-service commitments.

The consumer lifecycle is quite different. It involves:

• Exploring service availability and capabilities;
• Validating the conformance of services;
• Negotiating terms of usage with providers;
• Validating and reporting on quality of service; and
• Discovering and responding to changes in services that are consumed.

Proper SOA governance depends on a strategy that addresses the needs and concerns of both provider and consumer lifecycles. Such a strategy offers the structure, control, and discipline necessary to encourage good and discourage bad behaviors.

Policy Management
An SOA policy defines configurable rules and conditions that affect services during design time and at runtime. The nature of SOA - highly distributed, heterogeneous, and very dynamic - means that it's critical for SOA artifacts to be governed by such specific business, technical, and regulatory policies.

An initial step in policy definition is to turn existing service rules - which often exist as soft-copy documents - into a set of standard, reusable policy files that can be associated with services. Linking service and policy lets you automatically validate services and enforce specific policies.

Once they're defined, policies are used throughout the service lifecycle. For example, they're used to validate services at design-time, well before they're released to consumers, and they're used to enforce specific standards and behaviors at runtime.

The goal, of course, is to first ensure that quality issues and non-conformance are detected before services are put into production. Once in production, organizations should ideally implement runtime policy management capabilities for monitoring and automatically enforcing policies during service use.

The key aspects of SOA policy management include:

• Policy Definition: Transforms paper-based guidelines and rules into configurable electronic policies that provide the foundation for reuse and automation.
• Design-Time Enforcement: Automatically validates services in the design cycle to isolate policy conformance issues before the services are published.
• Runtime Enforcement: Enables Policy Enforcement Points to trigger events and actions (typically restrictive) automatically at runtime when services fail to conform to specific policies.
• Policy Lifecycle Management: Offers full control and management of policies from creation to retirement, including managing and maintaining the associations to business services.

Contract Management
Contracts are critical for communicating and enforcing policies, as well as other requirements in a heterogeneous and distributed IT environment. Just as a business contract ensures a healthy commercial relationship, a service contract ensures a healthy provider/consumer relationship.

Contracts are typically unique to a specific provider/consumer relationship and serve as the container for both formal policies, as well as agreements that are unique to the parties.

To put this in context, consider the example of renting a car. The rental agency is the provider, the renter is the consumer, and the car is the service. The contract defines information about the provider (the rental agency) and the consumer (the renter). It also specifies the service (the car), the terms and conditions (the policies), and any other provisions or agreements that are unique to the provider and consumer (for example, pre-paying for fuel). This contract is the basis for an agreement to bind the deal. A service contract is no different in complexity or purpose.

SOA Metadata Management
Effective SOA governance is ultimately the result of combining policy, process, and metadata. Metadata, or data about data, is the set of policies and descriptions of business services that let you discover and appropriately use those services. In the context of our discussion, metadata is all the information that would be centrally published to a UDDI registry.

There are three kinds of metadata generally associated with SOA:

• Business information, which includes data such as service type (for example, order entry) and line-of-business focus (for example, retail banking).
• Technical information required to consume or invoke a service, including transport type, authentication, interfaces, and implementation.
• Governance information, comprising the various policies and agreements discussed previously, along with information that identifies the relationships and dependencies between SOA elements, such as the service version or references to associated policies.

In the world of tightly coupled implementations, metadata is usually defined in the code of systems and applications. SOA requires this metadata to be externalized - that is, decoupled from the native system - so that these independent services can be classified and governed.

Conclusion
The promise of SOA is powerful and appealing. But what's apparent as organizations peel back the layers of SOA is that it radically changes traditional IT architectures. While SOA promises untold opportunities, it also introduces new challenges and risks that you must manage and mitigate.

The concept of SOA governance, while still somewhat nascent, is already a prerequisite for a successful SOA implementation. As with any sound management practice, SOA must be seen as a first-order concern with requirements that you must factor into your organization's SOA strategy at the very earliest stages of implementation because, simply put, without an effective governance strategy, SOA can lead to chaos.

Resources

• Oracle SOA resource center: www.oracle.com/soa
• Systinet SOA resources: www.systinet.com