SOA is dead; long live Model-Driven SOA
A couple of weeks ago Anne Thomas Manes did give the year a headstart with her post SOA is Dead; Long Live Services. She states:
Although the word "SOA" is dead, the requirement for service-oriented architecture is stronger than ever. But perhaps that’s the challenge: The acronym got in the way. People forgot what SOA stands for. They were too wrapped up in silly technology debates (e.g., "what’s the best ESB?" or "WS-* vs. REST"), and they missed the important stuff: architecture and services.
And she ends with: And that’s where we need to concentrate from this point forward: Services.
A nice overview of the tail of this post is given on InfoQ. Some people disagree with her solution, they state: SOA is dead; long live the web. They see the Web-Oriented Architecture (WOA) as the solution.
I think we should talk less about the solution domain and more about the problem domain. As a business person I wouldn’t care about SOA, WOA, REST, WS*, services, etc. I would be interested in an IT landscape truly supporting my business. And yes, that will call for a certain architectural style, maybe for SOA as an architectural style. However, that’s not all: I also want it fast, I want to change it a lot, and I want it at low costs. What we truly need is Model-Driven SOA.
Talk about the problem domain
I’ve talked about Model-Driven SOA before (in 2007). One problem I’ve stated is that it is questionable whether enterprises can actually maintain a focused strategy long enough to align their core business processes with IT. The current dynamic business environments doesn’t give enterprises that time. The only way to fasten up this process is to let models drive the engineering of IT.
That’s why we should talk more about the problem domain. We have to capture todays business with formal models. We need enterprise-wide model repositories with editing tools supporting the generation of different views, refactorings, change impact analysis, etc. We have the language and tools in place to do so. See for example the recent adoption of Archimate by the Open Group and the upcoming use and support of BPMN.
Once you have modeled (part of) the problem domain you can start reasoning about what parts of the models have to be implemented with IT technology. These model parts have to be translated into models of the solution domain, i.e. models of services supporting the business.
What kind of models do we need in the solution domain? High-level models understandable by domain experts! So we have to use Domain-Specific Languages (DSLs) to specify these models. Such high-level models can be linked to the models of the problem domain, thereby enabling tracing. This leads to increased business-IT alignment. You can keep track of the reasons why you are making decisions in the solution domain, tracing all the way up to your business requirements. In addition it also allows you to analyze the impact of a change in the models of your problem domain and vice versa.
Don’t talk bytecode
Please don’t start talking bytecode in de solution domain! BPEL is bytecode, WSDL is bytecode, WS* is bytecode, etc. You have to establish a Model-Driven Engineering (MDE) process starting with the models of your problem domain, transforming them into models of the solution domain (this will need manual work), which on their turn can be transformed (automatic) in bytecode executable on appropriate engines.
Sounds great, but is it possible? Let’s start with the bytecode. In a previous post I researched the architecture requirements of Service-Oriented Business Applications (SOBA). Following from that post we need a couple of different service types to build SOBAs supporting todays business. The combination and integration of these services can be done with the Service-Component Architecture (SCA). In the SCA we define components publishing services. This definition is done with XML and is fully implementation independent. You will need an SCA container to run these components, but you just have to specify the interface and bindingtypes. The container will ensure the interoperability with other components and services. So, don’t discuss what technology you need to use for communication, just declare what technology your component uses. The container will ensure that you can communicate with components using other technology. The XML specifications of the SCA (the bytecode) can easily be generated from a higher level DSL, preferably a Domain-Specific Visual Language (DSVL).
The assemblies, components, and services itself can also be implemented with existing bytecode like BPEL, WSDL, or self-defined DSLs. I’m not going to describe this process in detail right now. You can read more on SOBA implementation or Model Driven Engineering (MDE) in previous posts (‘just’ combine them 😉 ). Engines executing this bytecode are already available, think about process engines implementing process services, business rule engines implementing decision services, and model driven frameworks also interpreting other kind of models for entity services (data), delivery services (user interfaces, task-based workflows), and activity services.
Model Driven SOA is necessary and possible! As stated before the tools and languages for modeling the problem domain (i.e. the enterprise) are available and standardized more and more. Tools for modeling the solution domain (i.e. IT / software) with DSLs are available too, as well as tools for defining custom DSLs. The bridge between these two, i.e. enterprise modeling and model driven development, is also becoming available, see for example this news item.
In Model-Driven SOA both the MDE process and architecture are important. Architecture guides the modeling of the solution domain, the generation of the bytecode, and the organization of the engines. See the place of architecture in Model Driven Engineering for more details. However, we need an architecture describing design principles, not an architecture describing what communication protocols or bytecode we need.
It is not my intention with this article to give a full, detailed implementation guide for Model Driven SOA. I just want to present a direction focusing on architecture principles combined with a model driven methodology.
So, not services, not WOA, but Model Driven SOA!
I believe in it! Do you?