On the Shoulders of Giants

Going through my SOA Governance white paper once more, I suddenly realised how many concepts and frameworks I was able to leverage in the process of proposing a "new" approach.

I'm reminded once more that even an "innovative" and unprecedented idea has to rest on prior ideas from other people. It's only proper that I formally acknowledge my debt to the following people and organisations:

• The BAIT Model: I think this came from the Meta Group, but I'm not sure. It's now such an established part of architectural scripture that its exact origins are now the stuff of legend. Anyway, whoever thought this up, thanks!
• TOGAF: The very name says it all - The Open Group Architecture Framework. My heartfelt thanks to The Open Group.
• Domain-Driven Design (DDD): I've always been impressed by Eric Evans's approach, and I'm glad I could build something on top of his work.
• Cohesion and Coupling: An oldie but a goldie. Stevens, Meyers and Constantine are to be heartily commended for what is perhaps the cornerstone of architectural analysis. If an architect understands no other concept, they should at least try and master the concepts of cohesion and coupling.
• Data on the Outside vs Data on the Inside: Pat Helland of Microsoft (at the time he wrote it) gets a much-deserved doff of the hat for this contribution. It's such a crucial piece of insight that it's amazing more people don't get it (Hey, you there using that outrage called Hibernate's "detached entities", I'm talking to you!)

In turn of course, I'm happy to offer the SOA Governance and SOA Management approach that I described to other practitioners to build upon further.

A Sanskrit verse comes to mind:

Na Chora Haaryam Na Cha Raja Haaryam,
Na Bhraturbhajyam Na Cha Bhaarakaari
Vyaye Krute Vardhta Eva Nityam,
Vidyaa Dhanam Sarva Dhanam Pradhaanam.

(No thief can steal it, neither can a king or government.
Siblings cannot ask for a share, and it's never a burden to carry.
It only increases when you spend it.
The wealth of Knowledge is the foremost of all wealth.)

The Domain Model, its Representation(s) and their Composition

Rajat, Vikrant (the latter's an outdated link) and I have been having these discussions for a while now. Our thinking is summarised in these two papers:

The first is an "astro-geological" meta-model that explains how the Domain Model relates to various internal and external Representations. It tries to unify the concepts of Domain-Driven Design (DDD) and Service-Oriented Architecture (SOA). A Domain Model is a system's own view of its Universe of Discourse. Representations are how the system allows external parties to view itself. SOA deals with representations that are decoupled from domain objects, and these representations could be noun-based (REST) or verb-based (SOAP/WS-*).

The second is a model for Representation Composition, which blends the concepts of Process Orchestration and Content Aggregation.

The analogy of the astro-geological meta-model is that the Domain Model is like the surface of the Earth (or any other planet). When these celestial orbs communicate with each other (the "astro" part of the meta-model), they exchange representations of their Domain Models rather than expose their Domain Models directly. This is classic architectural practice to avoid tight coupling between systems. The Domain Model includes State and Behaviour, so one could think of representations of State as well as Behaviour. We believe these are commonly known as REST and SOAP, though purists from both camps may take umbrage at the comparison ;-).

The Domain Model is implemented atop infrastructure (the "geo" part of the meta-model). Sometimes, it's in the form of data held in relational databases. Sometimes, it's functions coded in legacy systems. Again, these are representations of the Domain Model, some of State and some of Behaviour. O-R Mapping tools are commonly used to create representations of the State of a Domain Model built with an OO paradigm, and these representations are relational. Similarly, Behaviour in the Domain Model may be represented as procedures on a mainframe, with the appropriate loosely-coupled translation happening between the two.

The Domain Model itself does not have to be purely OO-based. Many different paradigms may be used to model a domain, - OO, AOP (aspects), Rules, Process definitions, etc. The key messages are that representations are always required whenever a Domain Model is to interface to any other entity, internal or external. These representations should be loosely coupled to the Domain Model.

Coming to Representation Composition, we believe this is where SOA really hits its stride. An enterprise consists of various Domains, each with its own model and its own external representations (SOAP or REST-based). The challenge is to weave greater meaning from these individual representations and thereby add value to the enterprise.

Process orchestration concentrates on the verb paradigm. While this is powerful and enables the composition of "sentences" that include compound verbs and conditional clauses, the relative neglect of primary nouns in this model is cause for concern. This is perhaps why content aggregation (and content management in general) occupy a separate niche. Mashups (and the older Portals) are stabs at content aggregation, but both suffer from limitations as described in the document. We don't see a rationale for this dichotomy between the composition of representations of State and the composition of representations of Behaviour. Both need to be managed using a common idiom, and true power and value-add will come from that composite model.

As mentioned before in this blog, the WSO2 Mashup Server comes close to delivering on this vision, so we don't think our model is vapourware. We're surprised that the WSO2 people are themselves rather understated about the capabilities of Mashup Server ("lightweight personal mashup server"). Hypothetically, if a JavaScript library is developed with classes corresponding to various components in a BPEL engine, and if an XSL transform is done from XPDL (the XML representation of a BPMN process diagram) to a set of JavaScript configuration statements, then we can run processes on the WSO2 Mashup Server just as we can do content aggregation today. One unified platform for "Representation Composition"! Consume SOAP or REST, compose in a noun-oriented or verb-oriented way, and expose in turn as SOAP or REST.

All of this is non-visual, and we already have a model for how the Presentation Tier should interface with a SOAP- or REST-based Service Tier. It's called SOFEA (Service-Oriented Front-End Architecture), which is described in this paper and discussed on this blog.

Comments as usual are welcome.

SOA Technology Best Practice

Let me formalise what's on my mind regarding SOA best practice.

1. Build your core application using the principles of Domain-Driven Design. This is your service implementation. Hint: If using Java, Spring/JPA is the way to go. EJBsaurus is dead.
   
2. Take the help of an off-the-shelf domain model like IFW for Banking and IAA for Insurance. This will let you build incrementally without experiencing refactoring pain as your model grows.
3. If the way your clients refer to your services emphasises verbs over nouns ("Jelly this eel"), you may want to look at SOAP-based Web Services, which are operation-oriented services. If your clients emphasise nouns over verbs ("Buy a ticket to the Spice Girls concert"), consider REST-based Web Services, which are resource-oriented services.
4. Model your interface contract using XML schema in either case. Layer SOAP or REST Data Interchange patterns over this basic XML document foundation.
   
5. Follow Contract-First Design. Do not generate your service interface from your implementation classes, even if your vendor gives you cool tools to do so painlessly (Hint: the pain comes later, when every change to your implementation breaks your service contract).
6. Use a meet-in-the-middle mapping approach to connect the XML documents in the contract to the domain model. Do not generate implementation classes from the service interface. The self-important JAXB library is a bad bug that's going around. Use JiBX or TopLink instead.
   
7. When building the Presentation Tier of an application that consumes services, use the SOFEA model.
   
8. If you want to do content aggregation using 2007 thinking, consider a mashup. If still stuck in 2003, use a portal server and jump through the associated hoops.
9. You don't need an ESB product, not now, not ever. Learn to see the "bus" in the way services are built and invoked. Remember that the web with its smart endpoints has comprehensively beaten the telco network with its smart network approach, even in voice communications. If you must use an ESB, deploy it in a decentralised, "smart endpoints" configuration. Obviously, a decentralised ESB is economically viable only with an Open Source product . A commercial one will force you to deploy it in a centralised architecture to save on licence costs (blech!).
   
10. You don't need an ESB product to do process orchestration either. Use BPEL engines at endpoints. If you need human workflow, use BPEL4People.
    
11. Open Source is the way of the future. Wake up and smell the coffee. For SOAP-based Web Services, consider Sun's Metro (formerly Tango) SOAP stack. For REST, consider Sun's Jersey (Java-based) or SnapLogic (Python-based). For an ESB (decentralised, of course), consider ServiceMix/CeltiXFire/FUSE. For process orchestration, including human workflow, check out Intalio.
    
12. Management of your services can be centralised even with decentralised services. That's not an argument for a centralised ESB either.
13. Take vendor education with a pinch of salt. Talk to fellow practitioners, especially the bold and the irreverent.