InfoQ has posted an interview with Jim Webber of ThoughtWorks about "Guerilla SOA", where he talks about how to design scalable SOA solutions that are evolvable and allow innovation in the different services that make up the solution.The advice he offers covers topics that I have written about in my posts these last months: - Share business messages owned by the business people (ECDM)
- SOA has no operations, only business messages delivered to letter boxes - services exchange messages to fulfill business processes
- Services cannot be invoked, they just receive event+payload messages and decide if and how to process it: "Could you possibly have a look at this message and maybe if it suits you do some processing on it" (semantic covenant: the service is always right)
- Business processes are workflows; you need to model long-lived conversations beyond request/response (SSDL, check out the Soya WCF SSDL toolkit at SourceForge)
This architectual style is coined MEST, as it resembles REST: it is based on message exchange through a uniform interface - the letterbox. As you will see, MEST is a decoupled scalable design pattern along the lines of EDA.
Listen to the interview and read the transcript: Jim Webber on "Guerilla SOA"
The business process event canonical domain model (ECDM) is not intended for solving versioning issues for a specific service, that can be solved using message duck-typing or consumer-driven contracts. The ECDM is for mediating semantics between independent and autonomous services, allowing the services to be composed into biz processes and still be able to evolve each service separately. The autonomous SOA tenet should be used to achieve shared services and interchangeagility rather than focusing solely on reusability. A service is not autonomous before you can use the scissors on parts of a business process and replace the service by e.g. outsourcing it.
Indeed, service versioning is important for the evolvability of the service itself, but the ECDM is about the agility of the business processes in your service-oriented solution.
Do not confuse the SOA ECDM with the EAI CDM, they are similar concepts at different architectual layers. The ECDM will contain a subset of the common information model (CIM), but is rather focused on the data+business documents and semantics of the business events and processes that the ECDM encompasses. The ECDM is targeted at the service composition layer, not at the data access services layer.
Related reading: SOA doesn’t need a Common Information Model
An business process event canonical domain model (ECDM) is a model that is focused on the business events and the data+documents+messages needed as part of orchestrating the events into business processes by composing services. A central part of the creating the model is to keep the model as small as possible (like a "least common denominator" of the data), only passing the state of the process as part of the events. The data and business documents represent the state of an instance of a business process (what Jack van Hoof calls a dossier) and is all a business process step should need to know to be able to perform its actions.It is important to recognize that the ECDM does not encompass all information that some part of a business process might ever want or need to know, it just needs to contain enough reference data. Neither does the ECDM have to contain data about business entites across all applications in your enterprise, i.e. the ECDM "customer" does not need to model the union of all the different customer fields from your CRM and ERP systems. This is why ECDM is different from a common information model (CIM) or the EAI Common Data Model [Hohpe/Woolf CDM pattern (355)]. The process services that need to know more about the referenced data of the dossier, will have to use other process, capability/activity or entity services to look it up. This is what is called the "pull model" in the Observer pattern [GoF] [Hohpe/Woolf Event Message (151)]. The process step can also augment the business process state by calling other services and adding data to the dossier. Thus, the mantra of making a slender model is "Ask For More".Keeping the ECDM small is very important wrt to maintenance of the model, afterall the main purpose of the model is to mediate semantics in the service bus and its orchestrations of events and services. The number of mappings between the different elements (messages+dossiers and services) of a model will grow and change over time, thus having small model elements are crucial to keep the ECDM maintainable. In addition, split your model into separate domains/bounded contexts and make context maps, as this makes the total number of mappings smaller. The key maintenance advice is to keep the model elements small (smaller mappings) and the number of mappings between model elements to a minimum (less mappings).
