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 (business process information model)
- 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 information model (BPIM) is not intended for solving versioning issues for a specific service, that can be solved using message duck-typing or consumer-driven contracts. The BPIM 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 BPIM is about the agility of the business processes in your service-oriented solution.
Do not confuse the BPIM with the EAI CDM, they are similar concepts at different architectual layers. The BPIM 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 information model encompasses. Design the BPIM based on the CIM, ensuring that the model is canonical for each business process domain. The BPIM is targeted at the service composition layer, not at the data access services layer.
Related reading: SOA doesn’t need a Common Information Model
A business process information model (BPIM) 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 BPIM 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 BPIM have to contain data about business entites across all applications in your enterprise, i.e. the BPIM "customer" does not need to model the union of all the different customer fields from your CRM and ERP systems. This is why BPIM is different from a common information model (CIM) or the EAI Common Data Model [Hohpe/Woolf CDM pattern (355)].
The business process that need to know more about the referenced data of the dossier, will have to use services to look it up, as part of the service composition (orchestration). This is what is called the "pull model" in the Observer pattern [GoF] [Hohpe/Woolf Event Message (151)]. The business process can also augment the process state by calling services and adding data to the dossier. Thus, the mantra of making a slender model is "Ask For More".
Keeping the information model 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 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 model 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).
