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.
A policy might say, “When consumer A sends a message to service B, decrypt it, check the access token in the header for authenticity and proper permissions, transform the body of the message to match Version 1 of the service if it’s in Version 2 format, and then log the message for later auditing -- and if the amount in field X is greater than $100,000, alert Joe in sales.” The response from the provider can be similarly massaged and redirected.
In a traditional application, all of this would have to be built into the application itself, but in SOA, these functions can be layered onto a service. Most management systems allow operations personnel to create templates and apply them to every service in a given class, ensuring that policies are consistently applied.
The buddy system
Many companies find it advantageous to deploy separate development and production repositories, promoting services from the former to the latter when they have passed QA and met interoperability requirements. You should also consider the need for redundancy. It’s not unreasonable to deploy continually updated copies of the repository in geographically dispersed sites.
Management system proxies can typically be configured to fail-over to other proxies in the same array for redundancy, but similar concerns for geographic distribution apply to not just the proxies but the management console as well. Just as important is the need to get repository and management systems that work together. After all, if you’re going to go to all the trouble of entering metadata and other service information in your repository, you don’t want to have to re-enter it in the management console.
Deploying a few pilot Web services without a repository and management system in place is fine. But when you get serious about building an SOA, you can’t skimp on these important pieces. Repositories and management systems work as a team, yoked together to yield stable, reliable, and highly available services.