A Framework for Model-Driven SOA
A couple of weeks ago I gave an overview of two scientific publications researching a framework (or methodology) providing end-to-end guidance and assistance to refine and transform business models created by business experts into IT models and then to IT implementation. I tend to refer to these frameworks as Model-Driven SOA, because they focus on using models to construct an IT implementation complying to SOA principles.
However, I didn’t elaborate on the practical applicability of these studies. I asked you for your opinion. From the comments on the article and the discussion in the LinkedIn MDA group triggered by this article, it became clear to me that there’s a need to describe Model-Driven SOA in more detail before we can sufficiently compare different approaches and discuss the needed models, languages, and transformations.
In this article I present a generic framework describing Model-Driven SOA. I first describe the common terms in system development, like design, engineering, and architecture. After that we can apply these terms to a Service-Oriented Architecture (SOA) based development process. Finally, I want to define the requirements making this SOA system development process a Model-Driven Engineering approach.
System development is the bringing about of a new system or of changes to an existing system. The system development process comprises all activities that have to be performed in order to arrive at an implemented system. Such a development process can be described by the Generic System Development Process (GSDP) as introduced in  and recently described in more detail in . Figure 1 exhibits the GSDP. At first sight it can looks a bit abstract, but give me a moment to explain it and I hope you’ll see that it’s in fact an easy and powerful way to explain the common terms in software development.
Figure 1 – The Generic System Development Process 
I have explained this process before in a post on the definition of architecture. So, for details I refer to that post. However, the process has slightly changed over the years as did my view on it. I will therefore briefly explain this generic system development process again.
The GSDP always concerns two systems, the object system (i.e. the system which is going to be developed) and the using system (i.e. the system that is going to use the functionality of the object system). If we, for example, want to build a human resource management (HRM) information system, this HRM information system is the object system. The using system is the HRM department. People are often referring to the using system as the problem domain, while they call the object system the solution domain.
While in a lot of cases no construction model of the using system exists, we need to reconstruct the higher level models from the implementation. This process is known as reverse engineering. Let’s look again at our HRM system example. Before we can build an HRM information system supporting a certain HRM department we need to know what to support. We need to describe the using system and the only way to come to this description is to use reverse engineering. In case of the HRM department reverse engineering means talking with the people (the "implementation" of the using system) to learn how their work is performed.
The design process is split into function design and construction design. Function design starts from the construction of the using system and ends with a functional (black-box) model of the object system. This functional model describes the external behavior of the object system in terms of the using system, it doesn’t talk about the construction of the object system. The functional model of an HRM information system can for example be describe with use cases.
Construction design starts with the functional model and ends with a construction (white-box) model of the object system. As shown in Figure 1 multiple construction models can exist on different abstraction levels.
The engineering of a system is the activity in which the highest level constructional model is converted into lower level models until the implementation model is constructed. Dietz defines the highest level constructional model as the ontology of a system, i.e. a model of the construction of a system that is completely independent of the way in which it is implemented . This can be compared to the Platform Independent Model (PIM) in the Model Driven Architecture (MDA). In practice it is often the case that not all constructional models are defined, in most cases only the implementation model (the lowest level constructional model) is defined in a programming language (e.g. Java, C#, C++).
Implementing a system means assigning technological means to the constructional elements in the implementation model . In case of an implementation model expressed in a programming language, the implementation is the compilation of that model to a specific platform. Once a system is implemented it can be put into operation.
The last part of the generic system development process is "architecture". Dietz uses the prescriptive notion of architecture, in contrast to the descriptive notion of architecture. The descriptive definition defines architecture as ‘blue-prints’, but the GSDP already refers to this by "constructional model" or "ontology". The prescriptive notion of architecture sees architecture as a consistent and coherent set of design principles. In the generic system development process, architecture is split into functional principles guiding the function design and constructional principles guiding the construction design.
Service-Oriented Software Development
It’s time to tailor the generic system development process to a service-oriented development process. Lot’s of SOA definitions exist, but I prefer to see SOA as an architectural style. Figure 2 shows the service-oriented development process, based on the generic system development process.
Figure 2 – The Service-Oriented Development Process
As shown in Figure 2 the using system is an organization (or part of an organization) which can be modeled with an organization model. Such a model can consist of process models or just textual descriptions. The organization model needs to be reverse engineered from the organization’s implementation, which is in most cases a group of people and optionally already existing software.
The object system is an ICT system, to be designed and implemented to support the organization. The design, consisting of function and construction design, is guided by architecture principles. In case of a service-oriented development process the design is guided by SOA principles. A good overview of SOA principles is given by Thomas Erl in his book "Principles of Service Design" .
While the functional model of the software to build is defined with a set of services, the function design step consists of service identification and service specification. First the set of needed services is identified based on the organization model, next each service is specified in more detail (preferably using a standardized template). I’m just giving the outline of a generic service-oriented development process, so the details of question like "what exactly is a service?" and "how to specify a service?" are left for future ramblings.
The next step in the process is to take the functional specification consisting of service specifications and to design the construction of the needed ICT system which is going to provide these services. Following the Service Component Architecture (SCA) services can be grouped in components, which in their turn can be implemented with other components. Hence, service-oriented construction design consists of component identification. The highest level constructional model can for example be described by an SCA-based model.
The SCA also specifies how components can be implemented. Example component implementation possibilities are Java, .NET, and BPEL. So, the engineering step consists of specifying component implementations using Java, .NET, or BPEL, resulting in an implementation model consisting of artifacts described in these languages. This implementation model can be "implemented" on technology thereby resulting in the final software application, i.e. a Service-Oriented Business Application. Implementation of the implementation model means deploying all constructed artifacts to an SCA container.
Model-Driven Service-Oriented Software Development
Now what distinguishes SOA from Model-Driven SOA? I’ve already stated the term "model" a couple of times in the previous section and in Figure 2, but does that make the described service-oriented development process model driven? Model-driven engineering is based on formal models which are transformed into other models until the lowest level model can be executed with an engine or until code can be generated from that model (for more explanation read this introduction into model-driven software development). As we saw in the previous section the models are not necessarily formal and the implementation model is directly specified in a programming language. So, what are the requirements for Model-Driven SOA?
First, each model needs to be formal, i.e. it needs to be specified in a well-defined language. As we know from the previous the following models are needed:
- Organization model – for example specified in BPMN.
- Service model – mostly consisting of service specifications which are represented with a table listing some properties.
- Component model – for example specified using the SCA assembly specification.
- Component implementation model – each component can be specified with a set of connected Domain-Specific Languages (DSLs), meaning that a component implementation model can be considered as a multi-model.
Second, each model (except for the first model) is linked to the previous model, derived from the previous model, or a refinement of the previous model. The following steps are part of a Model-Driven SOA process:
- Reverse engineering – an organization model is manually created.
- Function design – a service model is derived from the organization model, whether this can be automated or not depends on how formal the organization model is. In most cases this is handiwork. Elements of the service model are linked to the organization model to enable tracing.
- Construction design – a component model is derived from the service model. This is again a manual job.
- Engineering – a component implementation model is a refinement of the component model. Implementation elements are specified in detail using DSLs.
- Implementation – the component implementation model is implemented on technology, i.e. the models specified using DSLs are executed on high-level engines. The result is a Service-Oriented Business Application.
Multiple roles are involved in such a process using different tools. An important aspect for the success of a Model-Driven SOA approach is the ability to specify DSLs which are both high-level and directly executable. Constructing such DSLs can be quite a challenge, I gave an overview and 7 recommendations for DSL development in my previous post.
A second important aspect for Model-Driven SOA is the traceability of decisions throughout the model chain. It should be possible to trace a model element in the component implementation model back to the organization model and the other way around.
This also leads to the last important aspect for Model-Driven SOA I want to mention: change propagation. The organization model and service model are very useful for gaining a quick insight in the function of the system. The real power of these models will become available if a change in the organization model leads to an automatic impact analysis on the service model. The same should hold for changes in the service model and how they affect the organization model and component model.
If you look back at Figure 2, I think it is a good recommendation that models which are connected horizontally (organization model – service model – component model) do not automatically propagate changes, they should report inconsistencies and provide a change impact analysis. Vertically connected models (the models used in the engineering step) will need automatic change propagation to provide productivity improvements, otherwise you’re half of the time busy with keeping the models consistent. In case of organization, service, and component models, you should be busy with that because in the consistency between these models lay most of the design decisions.
I hope this article gave you more insight in my ideas with respect to Model-Driven SOA. I have only described the framework including the needed models and transformations between these models. An important aspect to talk about in the future is the languages these models are specified in, i.e. the exact form of these models. Other aspects are needed tooling and technology (runtime engines). Moreover, every time we talk about such a model-driven approach, we shouldn’t forget these 10 misperceptions and challenges of Model-Driven Development.
I’d like to hear your thoughts on this model-driven SOA framework! I’m also interested in your experiences with using a model-driven approach to build software supporting (part of) an organization. What are your important learned lessons? What challenges are you dealing with?
 J.L.G. Dietz and J.A.P. Hoogervorst. Enterprise Ontology and Enterprise Architecture – how to let them evolve into effective complementary notions. GEAO Journal of Enterprise Architecture, 1, 2007.
 J.L.G. Dietz. Architecture – Building strategy into design. Academic Service, The Hague, The Netherlands, 2008.
 Thomas Erl. Principles of Service Design. The Prentice Hall Service-Oriented Computing Series from Thomas Erl. Prentice Hall, Upper Saddle River, NJ, USA, 2007.
Photo by Ride My Pony