SOA management: Governance plus intermediaries

Web service deployments can sneak up on you. One group publishes a service for processing payments, another exposes the API for key functions in the HR system, and before you know it, you’ve got dozens or even hundreds of services. But this isn’t an SOA -- this is a mess. Management and governance are the business processes that turn that mess into an architecture that supports the business.

One of the key differences between services in a SOA environment and traditional IT applications is that services, as do products, have clearly defined functions and guarantees that target “consumers” -- applications or users that draw on services inside or outside the enterprise. This arrangement has implications for publication, reliability, and flexibility -- all issues that come under the broad header of “management.”

Services are published in a registry -- or more likely, a repository that contains additional metadata. The repository is the system of record for the enterprise’s full range of services. It’s also a place where potential consumers of services can discover them and query metadata to learn about them. Finally, the repository is a point of control that allows the enterprise to manage versioning and ensure compliance with internal and external requirements.

SOA control room

This last function is particularly crucial to managing an SOA. When you’re treating your service as if it were a product, it’s going to have longtime consumers who need to know that the application they’re building won’t stop working when you decide to upgrade your service.

When you’ve deployed dozens or even hundreds of services, knowing what’s out there is important. Even more important is knowing what consumers are expecting and what they’ve been promised. Repositories provide a place for storing contracts between service providers and consumers, which may describe expected service levels, expected load, and even pricing information.

Web services management tools provide a way to monitor the health of services, measure service levels, respond to exceptions, and send alerts for business and operational events. But management systems go beyond mere operational control, providing support for critical activities such as controlling who has access, logging transactions, and managing service API versioning.

Web services management systems, such as those offered by AmberPoint or Blue Titan, come in various shapes and sizes, but typically work by interposing themselves between the service provider and consumer. This works because Web services talk a common language: SOAP. The proxies, or gateways as they’re sometimes called, are controlled by a management console. This architecture provides a scalable, flexible way to control large numbers of services handling millions of transactions.

Proxies as intermediaries

You can think of proxies as policy enforcement points and the console as the place where policies are built. In a management system, a policy is a series of operations on the SOAP message. These operations can include encryption, decryption, message signing, signature validation, consumer authentication and access control, logging, XML transformation, and protocol conversions.