Saturday, 1 September 2007

Architectural Paradigms 2007

« ISO: Standards For Sale - No Standards for Standards | Main | Comparing ROA and SOA »

At work we are going through a period of architectural planning, focused around integrating our internal systems. There seem to be a mix of architectural paradigms that are in fashion these days, and I intend to explore them over a series of posts here. In my estimation the reasonable architectural paradigms to advocate in 2007 are:

Service Oriented Architecture (SOA), typically using SOAP as the dominant web service. This is probably the leading architecture motivating IT spending these days.
Event Driven Architecture (EDA), typified by asynchronous message notifications and message buses. Messages are often XML or serialized objects.
Resource Oriented Architecture (ROA), typically using REST based web services, often with XML payloads. This is a relative newcomer and represents a mesh of a backlash against SOA and a progressive fundamentalism over the symmantic web.

Ones I didn't include, and why:

Event Stream Processing (ESP), stateful analysis of streaming messages turning SQL on its head by storing queries and issuing data. This is just too new, but it's definitely an exciting area to watch. Maybe in 2008 the big debate will be over stateful vs stateless bus architectures.
Enterprise Service Buses (ESB), Many see EDA and web services as complimentary and wrap Enterprise Service Buses around both to handle routing, transformation, and encapsulation of providers and consumers. I see an ESB as an enabling ingredient, but not an architectural paradigm that stands alone. Bobby Woolf, co-author of Enterprise Integration Patterns agrees. That said, a good question is: "When should I mix in an ESB to my enterprise architecture?". I may blog on that separately.

OK, so the big question to resolve is SOA vs ROA for web services and then when to use messaging instead of web service calls. Maybe with good internal architectures, web services manifested as both SOAP and REST simultaneously are possible. Amazon S3 does this, for example.

SOA says to deploy solutions embodied within services that are reused at the system level. Service in the flavor I'm considering are generally constructed using XML and XML Schemas, and interoperate using SOAP and WSDL. WSDL really ties the whole thing together, providing a techncial description of the operations of the service and the XML inputs and outputs of each such operation. WSDL also provides the endpoint information too. Doing SOAP right requires tooling - nobody writes stuff by hand. Good tools take a WSDL document and generate everything you need. SOAP functions by taking an XML document, and wrapping it in an envelope and decorating it with headers. Operations, even simple ones are generally going to provide XML input and XML output.

ROA is a particular template for a RESTful web service, using URI's, HTTP, and XML. ROA names resources with URI's and accesses them via HTTP in a way that emphasizes conformance with the standard operations for HTTP. ROA adopts four principles: addressibility, statelessness, connectedness, and the "uniform" interface of HTTP operations.

I'll be exploring this in depth over the next few posts.

Technorati Tags: soa soap rest roa WebServices architecture