sapienti sat: Making SOA Ready for the Enterprise

The Challenge

Service Oriented Architecture (SOA) is rapidly becoming the mainstream of business computing. The key difference between SOA and previously existing architectural approaches to software development is that it treats its building blocks (services) as business components by combining both functional (operations, messages, faults) and non-functional (security, QoS, versioning, lease) characteristics in a service description. A key to successful implementation of SOA lies in a SOA Governance Platform, which would provide an infrastructure for creating, communicating, and enforcing corporate policies and managing compliance regarding those characteristics across the organization.

The greatest challenge of building enterprise SOA Governance solution is that the set of characteristics defining governance for an organization or industry is as unique as that organization or industry itself. And although many of the core characteristics of SOA services have been identified, not all of them are applicable to every SOA implementation and at the same time each organization is likely to have some unique SOA governance requirements in a form of additional characteristics. More so, for most SOA Implementations these sets of characteristics are likely to change with time, as a result of natural business evolution and increased SOA Capability Maturity level. Finally, even when the list of characteristics or governance aspects stays the same, the implementation of those aspects is likely to change with time as a result of many factors, including: adoption of new and changes to existing standards, changes to regulatory and compliance requirements and changes to the overall IT infrastructure.

Existing Solutions

There is a broad set of Governance solutions in the market today which fall into three main categories:

1. Registry-based governance solutions, such as HP Systinet which provide a place for registering and classifying services, allow publishers to associate them with metadata, enforce workflows on the registration process and allow users to search for and discover services. Although metadata associated with services could serve multiple purposes including describing non-functional characteristics, the registries do not interpret or use it in any meaningful way. Most importantly, registry-based solutions only address the first two of the core governance functions (create and communicate) and do not address enforcement and compliance management.
2. Run-time governance solutions, such as AmberPoint do address enforcement and compliance management, but do it in a fairly rigid way that does not meet the real post-pilot governance needs of most organizations. Main problem with these solutions is that each one selects a fixed set of governance aspects (Security, Monitoring, Management and Fault Analysis for AmberPoint) and implements each one in a particular way (for example AmberPoint delegates security enforcement to either of Netegrity, Oblix, or Tivoli, but not Sun Access Manager; while SOA Software uses its own implementation of Reliable Messaging). Also since most of these solutions rely on external registries and repositories, they do not support coordinated creation, communication and enforcement of even those aspect that they address. So an organization that tries to implement a comprehensive governance solution based on one of these products has to live with the consequences, including:
   • Not having the support for the aspects which it needs but the vendor did not include in the solution.
   • Having to pay (in terms of actual cost, complexity, footprint and performance) for the aspect which it does not need but the vendor did include in the solution.
   • Having to accept the way how the vendor implemented each of the aspects they support.
3. Point governance solutions, such as WebSphere Business Services Fabric which offers industry-specific SOA Framework and Service libraries, and Forum Systems which concentrates on SOAP message-level security. These solutions address their respective problems in isolation and can not meet the needs of an organization looking for a comprehensive governance solution.

Neither of those solutions can address the fundamental problems outlined in the first section of this posting.

Introducing Aspect-Based Governance

An aspect-based governance platform (such as the one in the diagram below) allows users to define a set of aspects that realize their current governance requirements in their entirety, manage and communicate the statements about these aspects through the use of Governance Contracts that we will describe later, enforce them through customizable Aspect Enforcement Methods or through a delegation mechanism. These aspects can include a combination of universal service characteristics, such as security, versioning, monitoring, management and lease; common but less frequently used service characteristics, such as request throttling, regulatory compliance and usage chargeback; as well as unique service characteristics, specific to each customer.

The advantages

Aspect-based Governance allows the adopters of SOA to define, implement and manage governance solutions in such a way that best suits their organization and business model. It provides the final piece in the SOA puzzle that allows it to fulfill its original promise of aligning Business and IT capabilities of the enterprise. It gives organizations the flexibility to implement governance functions in a way that makes the best use of their existing IT infrastructure, and the flexibility to choose which of the (often competing) SOA-related standards to support. It does all of this without forcing them to pay (in either monetary or non-monetary terms) for the functionality they do not need today. And most importantly it gives them the ability to change their mind about any of those decisions without affecting service consumers, producers and the rest of their SOA Ecosystem.

A proper implementation of Aspect-based Governance supports ordering the execution of aspect enforcement methods, and defines mechanism for accumulating and communicating context information, so that aspect methods can take advantage of each other’s functionality (e.g. a chargeback method can rely on the user authentication that happened earlier within the security method to tie service invocations to the correct billing party).

By maintaining a complete separation between the implementation of service and aspect enforcement methods, Aspect-based Governance removes most of the compliance burden from service consumers and producers and allows incremental adoption and rollout of governance solutions.

It manages the risk and ensures future interoperability by abstracting the services from the standards layer.

It allows organizations to easily implement, integrate and manage in a uniform way custom aspects meeting their unique Governance requirements. For example one military client looking for a SOA Governance solution had a requirement that a poorly written service should not be able to disclose classified information to subjects without sufficient clearance. With our aspect-based governance platform we were able to meet this requirement through a straightforward Censorship Aspect which can compare classification level of the returned document or its parts with the clearance level of the requesting party, and take a necessary corrective action. Once this was done, Censorship can be managed in the same way as any other aspects, e.g. included into the governance contract used for all services that deal with classified information.

How is it different from what’s out there

I believe that my team and I get the credit for launching introducing the concept of aspect-based SOA governance, however it has became somewhat popular and I have seen it cropping up in the messaging both within and outside Sun. However the key differentiator is that everything I have seen so far uses the term aspect to describe technical (and typically fairly low level) concepts like JBI caching or Layer 7 Encrypt Response Massage assertion, while the idea behind governance aspects was to represent business-level concerns. In addition our SOA Governance solution:

1. Provides support for all core SOA characteristics as well as any additional ones required by the enterprise without forcing the users to implement the characteristics that have no current business value in their domain.
2. Provides uniform implementation, treatment, communication and enforcement of common and unique aspects. For example in order to support the Censorship aspect described above in a governance solution based on any of the existing products would require a custom implementation outside of the aegis of the platform, that should be administered and managed through separate means.
3. Maintains complete separation between service implementations and service aspects.
4. Allows incremental adoption and rollout of governance solutions.
5. Supports of all existing and future SOA-related standards without forcing users to lock into any particular standards or profiles.
6. Allows users to switch between competing standards or between proprietary and standard aspect implementations as the SOA ecosystem evolves.
7. Supports all aspects current and future of service governance without forcing them to accept any arbitrary decisions on which governance aspects they should implement or how these aspects should be implemented through aspect execution engine.
8. Provides a variety of aspect implementation mechanisms, including POJOs, EJBs, JMS Consumers, and Web Services and allows adding new ones like .NET, native libraries, etc.
9. Directly supports all facets of SOA Governance including Analysis-, Design- and Run-time Governance.