Bulletproofing your SOA

Andrew Nash of Reactivity has an article on Bulletproofing your SOA, hat tip Gary Smith. SOA is about integration, so lots of viewpoints must be considered. Andrew Nash poses the following questions from the following perspectives:

The infrastructure we create to enable SOA should be considered by participants in the SOA development process from architects (“Where can I offload supporting services?”) to developers (“Who is taking care of policy implementation for me including privacy and security?”) through operations and security staff (“What policy settings are implemented in the infrastructure that allow me to make adjustments without involving the development folks?”)

The five key areas to address in the article are:

1. simulating the production environment in development.

2. articulate policies for consumers and providers and make trade-offs regarding compatibility, security and throughput

3. creating a suite of test messages for both the service customer and the service provider

4. exercise each consumer and provider separately to evaluate every policy and potential exception that may be encountered in production

5. virtualization and configuration must be verified as cost-effective and scalable

These rules ring true, and illustrate where projects go awry, as always it pays to look at security issues from both the service requester and service provider viewpoint. I particularly liked the section on executing tests which has a summary list of test cases:

Validation of acceptable and rejected authentication methods

Correct mapping of identities and translation of credentials

Can bilateral handshakes be handled efficiently?

Schema validation

Authorization – are trusted identities granted correct access to services?

Content-based routing: testing for a different routes and correct invocation of service choices

Message transformation

Protocol mediation

Firing malicious content at the service; what happens if there is bad, mal-formed content in the XML?

There is a lot of work to be done by gateways. People like to bash them, but if you don't have one you end up having to code a lot of stuff by hand, and expose your services to a lot more risk. So the question really becomes - do you invest in building a framework of patterns to handle all of these services or do you identify best of breed players to help to fill these gaps.