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

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?

5 Comments Added

Join Discussion
  1. Jean-Jacques Dubray January 28, 2009 | Reply

    yes, in fact it is the only way. We have a pretty good idea of the architecture behind SOA but old tools and old run-times (OO based) introduce too much complexity to reach the true potential of SOA. Since it is unlikely that large vendors will overhaul their product suite now that we understand the principles behind SOA, Model-Driven SOA is the only way. Overtime, the run-time will grow behind it as optimizations are needed.

  2. Johan den Haan January 29, 2009 | Reply

    Hi Jean-Jacques,
    Nice to hear you thinking along the same lines.
    “Overtime, the run-time will grow behind it as optimizations are needed.”
    Yes, and the big challenge will be to have your models executing on (or integrated with) a runtime of both legacy and new stuff. SCA can help a lot, but as we see with the current differences in WSDL styles, integration won’t become as easy as we want it to be.

  3. Andrey Bulat May 1, 2009 | Reply

    In connection with this discussion (SOA is dead or alive) I should draw attention on two facts (I can make a mistake but for me they are significant):
    1. SOA is an attempt to integrate business needs, environment (where service will be used), policy (including safety and security), reusability, discovery and many other things that should be elaborated before implementation.
    2. If we try to examine what is Web Service from the point of implementation we can see similarity with approaches like COM (component object model) but at the next level of interoperability: there are same principles like independent stateless components, concept of interface (that can be excluded from realized component)and its detachment from realization, behavior that depends on invoked component (address of the component) but predefined by interface and/or types to be used in this interface etc.
    Main goal of COM was reusability and main goal of SOA is interoperability but from the customers point of view there is no difference (either COM as a platform of alive information system or SOA as a platform for cloud computing).
    In my opinion when we speak about technological difficulties (I mentioned COM because the same discussions were 10 year ago in connection with implementation of COM components) I completely agree with opinion that implementation of required protocol stack can costs. But:
    1. There are realizations (quite expansive) that already implement this stack (the sample is MS BizTalk Server) and usually used in Intranets of big companies.
    2. There are libraries that can help to create and publish services (moreover there is MS guidance package “Web Service Factory” that provide walk-through to build service as a multi tier application)
    In connection with assertion that architecture it is to sophisticated if we follow all WS* recommendations we should remember that if we make one simple service that is well known to all (including potential) customers of service, it could be redundant to use UDDI, WSDL, SOAP etc., but is we consider service that will operate in complex environment that need security, transactions, building of new services at the base of already implemented, etc. we will either realize all this requirements in code or at the declarative level and actually that it is the aim of SOA.
    In connection with Model-Driven Architecture – it is an approach that will provide great benefits and experience of my colleagues shows that it can decrease working time of realization of simple project more that 5 times. But it is complementary to SOA approach! Web Services are stateless proxies to business operations that can be modeled and code can be generated automatically using this models (an certainly it can include generation of WS infrastructure)
    So I don’t think that SOA is dead (at least as an approach to get business e-service using Internet transport protocols and as a good practice how to implement and publish this web service). Poor results (as it was mentioned in this discussion) from my point of view connected with semantic interoperability and samples of implementation at companies where this problem is absent.

  4. Johan den Haan May 2, 2009 | Reply

    Hi Andrey,
    Thanks for your detailed comments! I totally agree with you that SOA isn’t dead, it just passed the hype status.
    However, I think that it is very important to follow a Model-Driven Development methodology, which gives you the agility you need in current business environments.
    At the other side you’ll also need an architecture guiding the development of easy to change applications. So, we need SOA too.
    That’s why I’m arguing that we need Model-Driven SOA.

Leave a Reply