MDA y SOA en una discusión

Hace tiempo que tengo pendiente mencionar una línea de discusión abierta en el grupo Service-Orientated-Architecture de Yahoo en Agosto del año pasado, sobre las relaciones y oposiciones entre la arquitectura orientada a servicios y el diseño orientado a objetos. Participan en el debate varios conocedores del problema (Gervas Douglas, Eric Newcomer, Stefan Tilkov), que permiten tener una visión detallada del alcance de la arquitectura, y cómo el diseño orientado a objetos encaja en SOA, disparada por un comentario del moderador del grupo, Gervas Douglas:

Model-driven and event-driven architectures are two technologies expected to have a big impact on developers over the next decade. And while many IT professionals are in the dark about much of Gartner's "Hype Cycle for Emerging Technologies," these architectures, along with AJAX apps, have very bright futures.
(...) Event-driven architecture (EDA) is a common style for distributed apps that are typically designed into modular, encapsulated, shareable components with event services. The services can be created through an app, an adapter or agent acting non-invasively. According to the report, those in the financial trading, energy trading, telecommunications and fraud detection industries have begun using EDA technology, along with the Department of Homeland Security. But Gartner says EDA is at least five years from mainstream maturity.
(...) As for Model-driven architecture (MDA), a technology from the Object Management Group, the process will turn the heads of developers simply for its increased flexibility through SOA. The technology distinguishes biz-level functionality from the technical complexity of its implementation, enabling the apps to be modeled by standards like Unified Modeling Language. This allows the models to operate free from potential platform limitations and instantiate them into specific runtime implementations using a target platform of choice. Fenn says
both MDAs and EDAs will find their niche with developers largely thanks to SOA and their bottom-line boosting perks.

...Y aquí comienza todo. Eric Newcomer desaconseja UML como elemento de diseño de servicios, y Tilkov y Steve Jones, le replican.

Newcomer:

I just want to point out that MDA is not a good fit for SOA since it's based on UML, which is object-oriented, not service oriented.

UML has some value for whiteboarding and design, but in general OO analysis and design is overly complex for SO.
(...en otro párrafo...) UML is a great whiteboarding language but not more. Its contribution to the industry is a consolidation of what previously were multiple varying design notations. UML is not, and never was, an executable language, and attempts to make it so are inevitable failures.

Jones:

I wouldn't be so quick to rule out MDA for SOA, we've had some great success with using MDA as an implementation approach for SOA. We model the services in our architecture approach and then massively speed up the delivery of them by using MDA. I don't think Gartner are suggesting that MDA is for the whole of an SOA, they talk about it being for a niche. If you view SOA as being architectural and MDA/EDA/SOAP/REST as being software implementation/architecture then MDA is a real contender in terms of productivity gains and quality control.
One word of warning though, MDA does require high quality people who can deal at the abstract level and still create a system that works operationally.

Tilkov:

First of all, MDA is not necessarily based on UML, it can also be used with MOF. For example, Eclipse's EMF, which contains an implementation of EMOF, can be used to build domain specific modeling languages that are not object oriented. These can then become part of an automated tool chain that would clearly qualify as "MDA compliant" (although there is no such thing).
Secondly, it's perfectly possible to use UML to model services. You model classes, including attributes and associations, and specify them as types for the single parameter in service classes' method signatures. What's not service-oriented about this?
Thirdly, what's the (simpler) modeling alternative you suggest?
MDA, or in fact any form of model-driven software development, has many pros and cons. There's also a lot to be said against UML (e.g. its complexity and number of features which are largely unused in practice); its OO features are, IMO, definitely not a problem for applying it to SOA, though.

La respuesta de Newcomer pone sobre la mesa la validez en este contexto, del diseño orientado a objetos:

Certainly you can use UML to create services - as has been mentioned many times in this forum you can really use any technology, including procedure oriented technologies such as COBOL or PL/I.

I agree EMF is simpler and it is easier with EMF to create a modeling language for services, and we are currently currently working along those lines at the Eclipse STP Project. Microsoft has recently also released a Web service software factory, which also looks on first glance to be more service oriented.

But the point is more about what's better suited to service orientation, and because UML is object oriented it forces the same kind of mental translation as you'd have to do in going from procedure orientation to object orientation or service orientation. Why not work with tools more suited to the SO concept?

Objects are really overkill for software design. I believe it's time to basically turn back the clock and reject objects as the conceptual basis of modeling software. OO creates more problems than it solves. (Implementing services using objects, procedures, queues, etc. is ok but let's not design them that way.) It is much better to model, design, and develop using services natively. Most software applications are designed around implmenting functions rather than things.

Tilkov defiende su concepción:

I honestly don't see this point. In OO modeling with UML, an interface containing methods (or operations, if you prefer) is a first class concept. As is something that implements this interface. Sounds very service-oriented to me.
You can use a UML class model to describe a graph of data objects, or entities, or whatever you prefer to call them. There's not a 1:1 mapping to XML, but many (excluding me) agree this is not a SOA requirement.
(...) If you argued that it's better to develop Web services are better developed starting with explicit XML document design, I would probably agree - but describing SOA as an abstract, architectural concept, and then rejecting a general,
abstract modeling language such as UML, seems contradictory.
What methodology (and *available* tooling) would you recommend to
someone who wants to model services now?

Jerry Zhu amplía la defensa de OOD:

The way I look at the SW technology evolution is that three layers from bottom up OO objects, Component Orieation objects (EJBs and COM) and Service Orienation objects (such as Web services).
You need OO concepts to build EJBs or COM objects that support a critical concept called Automation which support programmability. Service technoloygy is build on the Automation by replacing scripts with XML messages. By having a service layer on top, we can build new applications quickly by recomposing services through creating new XML documents that in turn reassemble EJB objects.
Without Service layer, when building new applications, we have to program using APIs that means learning curve and development experience. With Service layer
we only compose XML documents and the computer will do the API wiring for us therefore significant resource saving. This is only possible when we have complete
business/technical coverage by all the OO and CO objects.
Some may have two layers: procedural languages and Services. It is a short cut. It may work for building a Scooter but not a Jetfighter.
Accordingly I would say Service technology is a newer technology than Component technology (EJB/COM). It is not that Service technology has been around long time.
The appearance of Service technology is years after the appearance of EJB and COM.

Anne Thomas Manes puntualiza un aspecto limitante de SOA:

When building service-oriented systems, you don't want to make everything a service. Only those bits that are reusable should be exposed as services. Unfortunately, most of the current tooling out there tends to simply convert object interfaces into service interfaces.

Ashley McNeile agrega otro enfoque:

I don't know whether the work I have been doing is of interest in this context, but it may be. So here is a short description and references to some material.
I have had a long standing interest in behaviour modelling, and languages that support direct execution of such models. Recently I have been working with colleagues on a concept called "Protocol Modelling" that is based around the idea of composing partial behavioural descriptions using the parallel composition ideas of CSP (Tony Hoare's process algebra).
This approach leads to a programming style in which partial behavioural descriptions (which can, in theory, be built using any notation you like) are combined in the manner of "mixins", giving an expressive power that is similar to multiple inheritance.
The challenge in developing the approach has been to allow these mixins to be re-used safely across the definition of multiple behavioural entities (be they objects or processes -- we don't really distinguish between the two). The approach works well, but does lead to a radically different view of what is meant by "inheritance" and the mechanisms for achieving it. However, I think we are on the right track, as attempts to include the inheritance of behaviour into conventional inheritance schemes leads to nasty complications.
The resultant paradigm for defining executable behaviour models is as different from conventional OO as OO is different from 3GL.
The following two papers will give you some idea of what we have been doing. Both are referenced from the "News and White Papers" page of the Metamaxim website (http://www.metamaxim.com/pages/news.htm):
1. The paper "State Machines as Mixins" (see "Metamaxim article in The Journal of Object Technology" under January 2004)
2. The paper "Protocol Modelling" (see "Formal Semantics" under November 2004).
The first of these is a more general motivation of the ideas -- please read this one first. The second is an attempt to put the ideas on a more formal footing.
It is too early to say whether this approach has useful application to SO (in particular, process modelling), but I suspect that it does.

Invito a leer y analizar la discusión, que es una fuente de ideas sobre los alcances de las arquitecturas orientadas a servicios, y también sobre las fuerzas y debilidades de la orientación a objetos.