SOA's Dirty Little Secret

David Linthicum, InfoWorld's Real World SOA blogger, recently offered up a wealth of white-papers on SOA specific topics.

I read through a few of his papers and they were certainly informative and insightful, but the one thing missing from all of them was mention of SOA's most important component - the architecture. David definitely enlightens readers on standards, transaction management (WS-AtomicTransaction is excellent reading - if you're desperate to cure a bout of insomnia), and general SOA issues including his "12 Steps to SOA". Shouldn't the first step be admitting you need a SOA? But there's nothing about the delivery of SOA-focused applications, which necessarily requires a well-planned architecture.

It's as if everyone forgot that SOA is an architectural design pattern and not a set of extremely dry standards. Oh, it's given lip-service, but no one is really addressing what it means except to focus on the impact of SOA on software development. SOA stands for Service Oriented Architecture, not service oriented applications.

Side track SOA is an acronym and not just an abbreviation, because it can be pronounced as a "word", like SCUBA. A little English lesson never hurt anyone, and I thought this was a fun fact learned from the copy desk at Network Computing that I'd share. Of course, I'm a bit of a word freak and also think playing WebBoggle for hours is a great way to spend some of my free time. 

There's more to building a SOA than just defining a set of business services, implementing and then deploying them "out there, on the network, somewhere". There are architectural questions that need to be asked and the answers addressed with a suitable architecture to ensure that those services are going to be fast, secure, and available.

1. Where are you going to deploy those business services?

What's your network and application architecture look like?

2. How will applications access those service?

What protocols will be used? SOAP/HTTP? SOAP/JMS? FTP? SMTP?

3. When will applications be accessing the services?

What's the usage pattern for the service? What times are peak periods of access?

4. Why will applications be using the services?

Are any of these applications mission-critical? Customer facing? Part of a business partner network? A supply chain? Are there response time requirements or bandwidth limitations?

5. Who has access to the service and its operations? 

Does Bob have access rights to GetEmployeeSalary? Probably not!

6. What applications are using the services?

You have a dependency map, right? You've done an impact analysis on the effects of an outage for this service or change to its interface, right?

The 5-W's (and the H - what's up with that, anyway?) are good for more than just journalism and reporters. The 5 W's form the basis on which you can begin to understand the basic infrastructure focused needs of your services and the applications that make use of them.

Without a solid infrastructure on which you can deliver the services and applications that make up your SOA, supporting WS-AtomicTransaction or WS-Coordination is pretty irrelvant. It's hard to coordinate services when they can't reliably talk to each other because of a poorly designed architecture. It's difficult to enforce transactional boundaries when they need to be granular enough to support the possiblity that a single service in the process might not be available or responding poorly.

The "A" in SOA relies heavily on a well-designed network infrastructure that supports the fast, secure delivery of services and keeps them available regardless of application access patterns.

Imbibing: coffee