I’m with the SOA Work Group at The Open Group conference in Toronto this week (see http://www.opengroup.org/toronto2009-apc).

The Work Group has been busy recently, completing its Governance Framework, helping to complete The Open Group’s Service Integration Maturity Model, and working with members of OASIS and the OMG to finish the joint paper “Navigating the SOA Open Standards Landscape Around Architecture,” which explains how the architecture-focused SOA standards of these bodies relate to each other.

There was so much to do that we started our discussions last weekend, and we made good progress on our Practical Guide to Using TOGAF for SOA, and on our SOA Reference Architecture. Today we moved on to the thorny question of SOA and Security, which we discussed in a joint session with The Open Group's Security Forum.

Security is often seen as a major problem for SOA but – and this was the thread we pursued in today’s discussion – perhaps this is looking at the problem the wrong way round.

Certainly, there are security problems associated with service chains, where some of the services in the chain may be outside the control of – or even not known to – the consumer, and where the identity of the consumer may not be known to all the services in the chain.

But really these problems are due, not to the use of services, but to the use of distributed software modules with multiple owners. They would arise whether the underlying facilities were provided as services or in some other form – as object methods that can be invoked remotely, for example. They have become associated with SOA because that is the form that cross-domain distributed computing usually takes these days.

In fact, SOA gives us a way of addressing these security problems. Security is a matter of

And, where the consumer is in turn providing services to others, the analysis can help determine the contractual level of security that can reasonably be offered for those services.

assessing and mitigating risks. The service principle provides an excellent basis for doing this.

The consumer can ask questions that help establish the levels of risk.

“What services am I using?” “Who provides them?” “What level of security are they contracted to provide?” “How far do I believe that they can and will meet their contractual obligation?” The answers to such questions enable the consumer to decide what security mechanisms to deploy.

And, where the consumer is in turn providing services to others, the analysis can help determine the contractual level of security that can reasonably be offered for those services.

This is not to say that SOA solves the security problems of cross-domain distributed computing. These problems are difficult, and there are aspects – such as the lack of a commonly-accepted standard identity framework – that SOA does not address. But, looked at in the right way, it is a positive, rather than a negative, factor. And that’s something!

Harding is Forum Director for SOA and Semantic Interoperability at The Open Group. He has been with The Open Group for over ten years, and is currently responsible for managing and supporting its work on semantic interoperability, SOA, and cloud computing. Chris can be contacted at c.harding@opengroup.org.

• SOA Divorced From Web Services?
• IBM Announces New Appliances and Security Consulting Services for Industry Standard Computing
• Burton Group to Address Security Architecture for the Future at Open Group Conference