I’m in two minds about Service-Oriented-Architecture (SOA). On the one hand it seems obvious that future systems will need to inter-operate increasingly in order to gain business benefits without requiring complete software development projects. On the other hand, I am distinctly under-impressed by the current approaches to SOA, and even by the emphasis on services rather than the equally applicable resources, messages, or processes as the integration building blocks.
Here are a bunch of conflicting views on this area which have collected in my “blog this” queue over the last few days:
InfoQ Article: Will Cloud-based Multi-Enterprise Information Systems Replace Extranets?
Will Cloud-based Multi-Enterprise Information Systems Replace Extranets? (confusingly, a different article with the same title!)
Meme Agora: Tactics vs. Strategy (SOA & The Tarpit of Irrelevancy)
Enterprise Java Community: Extend the Data Grid With Hub-less Messaging
Services & Workflows: SOAP and REST with WCF and WWF
Year of the cloud
SOA equals Integration?
From an SOA architectural view, Business Process Management and workflow orchestration seems an obvious component of a large system. However, when I see this idea moved wholesale into the world of REST, I worry that a significant point has been missed.
InfoQ: IBM’s BPM Zero Project: RESTful Worflow Management
The part of BPEL workflow orchestration which makes sense when used with traditional services (presented via SOAP or other RPC mechanisms) is the connecting together of displarate executable chunks into a larger executable chunk. In effect, BPEL used as an over-arching programming language.
The point that is missed when this approach is applied to REST is that REST is not about executable services, but about resources. A REST-style of over-arching connection would somehow represent disparate resources as a larger resource. This is not at all what BPEL orchestration does.
The practical upshot of this is that SOA workflow management can only work with REST resources which may also be considered as executable services. While such things do exist, they are an unusual and very rare subset of REST. Attempting to integrate REST resources using BPEL typically leads to one of three outcomes: (1) the integration is limited to those resources which are also services, and thus is so limited as to be hardly useful. (2) useful resources are converted or wrapped to appear as executable services, defeating the point of REST. (3) The project is abandoned as impossible, or simply fails.
As a simple “litmus test” for whether you are making effective and proper use of REST: Will your application still work if all the collaborating “services” are replaced by simple files or static web pages? If not, then you need to work harder at understanding REST.
When I first encountered Duncan Cragg’s “REST dialogues” I was not sure how they would develop. As I have read more, I have become progressively more impressed. Cragg uses the style of a Socratic dialogue with an imaginary “eBay architect” to teach about the nature and use of REST techniques as an alternative to more traditional approaches such as SOAP and SOA.
Recent dialogues on Business Conversations and The Distributed Observer Pattern are particularly thought-provoking, but the whole growing series is definitely worth a read.
The REST Dialogues
One of the things which has often baffled me about Service-Oriented Architectures (SOA) is the idea of some kind of registry. It’s a common sight in architecture diagrams and serves the role of tying together service providers and consumers in some automated (and ideally automatic) way.
In practice, of course, there is hardly ever a foolproof way of determining whether a service is appropriate to the needs of a consumer. Sure, it may implement the correct interface, but is it actually the correct implementation? What has happened in every case I have encountered is one of two things: (a) each interface only has one implementation, the directory lookup becomes trivial, and all that smart matching software sits idle, or (b) the registry or the protocol is manually hacked to force particular consumers to associate with particular service implementations, in which case all that smart matching software just gets in the way.
Martin Fowler describes an alternative, the “Humane Registry”.
MF Bliki: HumaneRegistry
Another interesting-looking Qcon presentation for the “to watch” queue. I’m getting a bit bored with the X eye for the Y guy title meme, though.
InfoQ: REST Eye for the SOA Guy
A relatively simple, but still interesting, article about the issues faced by distributed architectures .
InfoQ: Opinion: Multiple Processor Computing Challenges go Beyond Purely Technical Issues
One of the key tenets of the Service-Oriented Architecture (SOA) approach to software system design is the idea of loose coupling. In some cases it is pragmatically obvious whether one service is loosely or tightly coupled to another, but in the general case it can be tricky to determine. With that in mind InfoQ have produced an article on the topic.
InfoQ: Loose Coupling in SOA Defined
It seems as if the term SOA (Service-Oriented Architecture) has become confused with the implementation technology (often WS-* web services). Some pundits are now trying to create a new term “WOA” (Web-Oriented Architecture) to describe a service-oriented approach using native web technologies such as HTTP, URLs and REST.
ZapThink have taken a look at these terms and their implications: WOA is Me – Another Acronym? WOA and SOA