-k.

I feel somewhat frustrated when I read articles like Mark Barkers ‘The Lost Art of Separating Concerns‘. SOA is one of the most over used and under appreciated acronyms in our industry today. It’s unfortunate, because underneath the fluff, hype and vendor promises are solid architectural principles. Worst than the hype is the plethora of noise and misinformation, Marks article falls into this group. The intent of his article is to show how REST separates interface from implementation, while SOA/WS doesn’t. What it does is make the false assumption that in the SOA world services equal application interfaces.

While I was at ThoughtWorks I was ‘fortunate’ enough to work with Jim Webber, SOA proponent and all round nice guy. Jim is a fountain of knowledge and opinions on all things SOA. Until I met Jim I really wasn’t interested in the whole SOA phenomenon. There were just too many vendors offering it up as some form of silver bullet. Jim convinced me otherwise. Through conversations, careful guidance and the judicious use of his backhand (never suggest that SOAP and Web Services are CORBA wanna-bes) I came to an understanding of where an SOA fits in the development landscape.

A service-oriented architecture is not about using tools to create WDSL definitions from application interfaces defined in java or c#. It’s not about using tools to create application interfaces from WSDL. In fact it’s not about application interfaces at all. It’s about exchanging messages. These messages may be logically combined to form protocols and services.

In the current corporate world, for better or worst, the accepted message form is SOAP and WSDL is most often used to describe services. Unfortunately there is also a vendor supported tendency to blur the distinction between service definitions and application interfaces. Vendors (open source and commercial) tout the ability to ‘transparently’ enable web services from application interfaces or to generate application interfaces from WSDL definitions. In both cases we end up with service architectures that are tightly coupled to application implementation. An alternative approach is described by the proponents of MEST. MEST attempts to describe service-oriented architectures in terms of services, messages and architectural principles. It moves the focus from application interfaces to protocols built on patterns of message exchange. This focus allows you to design message protocols in line with business services. Because the focus in on the messages the services naturally exist independently of application interfaces. This disconnection allows application and service interfaces evolve independently. There is a small price to be paid in the form of adaptors but frameworks like Spring Web Services make this task quiet a bit simpler by focusing on message processing rather than service generation.