The website SOAPatterns.org has a wealth of SOA Design Patterns that is worthy of detailed study and exploration. Although I personally think the book SOA Design Pattern by Thomas Erl is 2/3rds filled with vacuous patterns, the website which was created while the book was being written has a wealth of valuable contributions. In fact, if you ever read the book, you would immediately notice that the insightful contributions come from the contributors and not the original author. This is a bit unfortunate since historical Design Patterns books have been mostly about written in collaboration. The 5 volume series “Pattern-Oriented Software Architecture” that was first compiled from 1996 to 2007 is one of my favorites. My big beef with the Erl book is that most of the credit goes to Erl, while he has provided the most mediocre of contributions.
However I digress. The topic of this entry is about the other Design Patterns that unfortunately didn’t make it into the book. My objective is to give a brief summary of some of the more interesting ones. So with little fan fare, here’s my list of interesting SOA design patterns from the candidate list:
- Consumer-processed Composition (Balasubramanian, Carlyle, Pautasso) – I would call this pattern “Integration at the Glass”. In general by deferring execution logic to when it is bound to a consumer then one can achieve the more flexibility.
- Enterprise Domain Repository (Lind) – I would prefer the name “Multi-source domain objects”. This is a common problem with legacy systems and the handling of which should be any SOA toolbox.
- Entity Endpoint (Balasubramanian, Carlyle, Pautasso ) – This pattern comes naturally in a ReSTful architecture. However even for WS-I or CORBA based systems, there needs to be a mechanism to exchange URLs or pointers so that one can resolve entities. I would call this pattern “Durable Reference”. It is indeed surprising that many SOA based initiatives treat this capability as an afterthought.
- Entity Linking (Balasubramanian, Webber, Erl, Booth) – This pattern again comes for ReSTful architecture. State exists in the clients and state transitions are achieved by the URL linking. This I would call “Trampoline Control Flow”.
- Endpoint Redirection (Balasubramanian, Carlyle, Pautasso)
- Another ReSTful pattern. This in general is about redirecting an invocation to another service. This mechanism is quite useful in managing the evolution of a system. For example, a service may redirect a request to the an upgraded service.
- Forwards Compatibility (Orchard)
– An interesting pattern that is useful for Service evolution in that it maintains backward compatibility and supports extensions in the communications between services.
- Idempotent Capability (Wilhelmsen, Pautasso) – The simple identification of the idempotency of services is a critical feature in building optimal distributed systems.
- Legacy Router (O’Brien) – There is a generalization of this pattern in that every dynamic system must begin from a well know landmark. This pattern exists in many dynamic discovery based P2P networks.
- Message-Based State Deferral (Balasubramanian, Carlyle, Pautasso) – This again is a consequence of a ReSTful based approach. The idea however is relevant for distributed systems in that there are benefits in maintaining state in the client or in the message that is exchanged between services.
- Service Virtualization (Roy) – There seems to be a common theme among many patterns in that greater flexibility is achieved if the reference to a service is a virtual one that who’s behavior can change dynamically.
- Validation by Projection (Orchard) – Seems to be a subset of Partial Validation, I’m unsure as to what the difference is, however I will give the pattern the benefit of the doubt since afterall both patterns are written by the same authors.
Many of these patterns are clearly inspired by ReST architecture ( a book is in the works to address this). Also, I’ve purposely ignored those patterns that involve optimizing the resource allocation in a distributed systems with the exception of the Idempotent Capability pattern. For SOA, the emphasis is in pursuing flexible architectures in favor of optimal ones. So its best that focus be kept, lest we be distracted and prematurely optimize our architectures.
My hidden agenda in why I am exhaustively covering the SOA Design Patterns is that I have a Pattern Language of my own in the works. Over time I will discuss this in more details.