What could be better than combining two great buzzwords? :-) Using Domain-Specific Modeling to build applications in a Service Oriented Architecture is of course a good approach, bringing the normal DSM benefits of 5-10x better productivity and significantly better quality. But if you start by thinking about creating a modeling language for SOA, you may be going down the wrong parth. Let me explain why.

In general I’d suggest basing the modeling language on the concepts of the problem domain, not the solution domain. SOA is really more on the solution domain side of things, and that side is handled by the generators, not the modeling language. If many of the solution domain details are visible in the models, they are no longer at the high level of abstraction expected from DSM. This reduces the productivity of the modeler, and forces them to think on two levels simultaneously. It also makes the DSM solution brittle with respect to changes in the solution domain. Normally with DSM, if you change the solution domain (e.g. to switch to a different framework or architecture), only the generator needs to change (requiring work by one person), not the models (which would require work by many people). If implementation details are visible in the models, a change in the solution domain requires changes to all models, meaning extra work for many people.

The Digital Watch example in MetaEdit+ illustrates DSM principles quite nicely here. Initially we were only targeting an object-oriented, browser-based implementation: Java applets. We were able to keep the implementation details out of the models, though, so later we have been able to add new generators for an object-oriented mobile device implementation (MIDP on mobile phones -- see Section 4 here), and a low-level procedural language for embedded devices (C), all without any changes to the models.

We also have another example, not yet released, of database applications with a web page interface. One generator can produce applications running locally in a browser using Google’s Gears, with JavaScript and an SQLite database inside the browser; another generator will produce Python for the Google App Engine using a Python DataStore on Google’s server in the cloud. So there’s a desktop database application, or a client-server application -- and the models need say nothing about those implementation details.