Grady Booch en espera...

Grady Booch en espera de una operación...

El complicado manejo de un ERP

Un colega español que propone un modelo colaborativo y abierto de consultoría, comenta un caso de implantación de un ERP desarrollado por una casa de software. Se puede agregar el caso a una lista de dramas típicos del problema, que afecta a las dos partes: la empresa que recibe el producto, y la que lo desarrolla y licencia. (Hace tiempo que tengo pendiente esta referencia...algún día hay que recomendarla.)

Finalmente, la Wiki de Plex

Recuerdo, hace ya bastante tiempo, haber comentado con un colega el valor de una Wiki, a propósito de la que Crossroads puso disponible. Bien, finalmente, Jeremy Hutchinson y Matthew Morris, de Desynit y Omelette Software, dieron el primer paso para construír una base de conocimiento sobre Plex. En los próximos meses, tenderá a convertirse en una fuente de primer orden de recursos sobre nuestra herramienta de modelado y generación. Eso espero...

Dos sitios para tener en cuenta

Simplemente para no olvidarme, y para cualquier interesado en el uso del UML y del EUP (Essential Unified Process), los papeles publicados por Ivar Jacobson y sus colaboradores. En particular, es de interés el papel sobre CMMI.
...y para no olvidar a Clive Finkelstein: el sitio de su consultora. Una vista a su evolución desde Information Engineering a hoy.

Una evaluación integradora de MDA/SF

En septiembre de 2005, Vicente Pelechano y Javier Muñoz, de la Universidad Politécnica de Valencia, publicaron un trabajo que compara, evalúa, y trata de sacar elementos positivos e integradores, de las estrategias de diseño dirigido por modelos y las factorías de software. El trabajo fue presentado en el II Taller sobre Desarrollo de Software Dirigido por Modelos, MDA y Aplicaciones (DSDM), en Granada (España).
En resumen, lo principal de la comparación:

Las Factorías de Software proporcionan una mayor guía para llevar a cabo el desarrollo de software, ya que recomiendan explícitamente el uso de líneas de producto, frameworks de implementación, patrones de diseño, etc.; mientras que MDA se centra en diferenciar entre la descripción del sistema de manera independiente de plataforma y las posibles realizaciones de esa especificación. MDA no proporciona indicaciones sobre cómo se deben diseñar los sistemas, se limita a recomendar que la generación del código se realice a partir de modelos.
Las Factorías Software promueven el uso de Lenguajes de Dominio Especifíco, mientras que MDA promueve el uso de UML, que es de propósito general. Esta es una de las diferencias más importantes entre los dos enfoques y la que, sin duda, es más polémica. Las Factorías de Software recomiendan la creación de lenguajes (de modelado) que permitan a los desarrolladores utilizar las primitivas más adecuadas para cada tipo de sistema. La OMG defiende que debe usarse UML, utilizando sus capacidades de extensión (profiles), cuando sea necesario, para expresar conceptos que no pueden representarse de forma directa en UML.
MDA proporciona lenguajes para la gestión de los modelos (UML, CWM, MOF, QVT), mientras que las Factorías de Software se limitan a describir técnicas que pueden utilizarse para este fin. Por ejemplo, en [6, cap. 8] se describe la posibilidad de especificar la sintaxis abstracta de los lenguajes específicos de dominio utilizando BNF o metamodelos, para estos últimos utiliza una notación similar a la propuesta por MOF. Sin embargo en el apéndice B de [6] se critica MOF desaconsejando su uso sin proponer ninguna alternativa.
MDA promueve explícitamente elevar el nivel de abstracción a la hora de especificar los sistemas, las Factorías Software permiten la creación de DSLs que representen directamente elementos de plataformas de implementación. En varios ejemplos, por ejemplo algunas figuras de [6, cap. 7], se muestran modelos que utilizan primitivas como ASP.NET Service o Windows Application. Siguiendo la estrategia MDA, un sistema debe especificarse utilizando modelos independiente de plataforma (PIM) que, posteriormente, podrán ser transformados o anotados para convertirse en modelos específicos de una plataforma (PSM).

Ventajas de MDA:

Define de manera clara la tecnología que recomienda utilizar para aplicar su enfoque: UML, MOF, QVT, etc. Esto facilita la tarea de construcción de un método a los desarrolladores que quieren aplicar este enfoque. Podemos contar con lenguajes ampliamente conocidos que, en gran parte, no necesitan de descripción y disponen de abundante documentación.
Está más tiempo en el mercado, ya que fue presentado con anterioridad a las Factorías de Software. Debido a esto, MDA ha sido más estudiado, discutido y
aplicado. Este aspecto facilita la aceptación de un método por parte de la comunidad de la Ingeniería del Software.
Ofrece un mayor soporte de herramientas que están empezando a madurar. Esto ocurre debido a dos causas: (1) OMG está compuesto por muchas empresas que desean ofrecer productos que sigan las especificaciones de OMG, y tal y como se ha dicho en el punto anterior, (2) MDA es conocido desde hace más tiempo. Por ejemplo, Eclipse es un entorno de desarrollo extensible, libre y promovido principalmente por IBM. Este entorno tiene una amplia comunidad que desarrolla extensiones para proporcionar funcionalidad muy diversa. Entre estas extensiones destaca EMF, una extensión para el metamodelado basado en el estándar MOF de OMG capaz de almacenar los modelos en formato XMI 2. También existe una extensión que proporciona una implementación del metamodelo de UML utilizando EMF, disponiendo en estos casos de implementaciones libres de los estándares de OMG. Por otra parte, las Domain-Specific Language Tools que Microsoft propone para construir Factorías de Software todavía se encuentran en fase de desarrollo, por lo que no son muy robustas y no pueden aplicarse en entornos de producción industrial.

Ventajas de Software Factory:

Proporcionan una completa guía metodológica a los desarrolladores. Con las Factorías de Software se definen de forma más clara y precisa los pasos que deben llevarse a cabo para construir un método que siga esa aproximación. Esto ha quedado patente en la sección 4.2, donde se ha descrito cómo se deberían aplicar cada una de las estrategias para crear un método para el desarrollo de sistemas pervasivos. La cantidad de información para la construcción de métodos que proporciona el enfoque de las Factorías de Software es mayor que la proporcionada por MDA, ya que éste último no da ninguna pauta sobre cómo se deberían implementar los sistemas.
Integra muchas áreas de la Ingeniería del Software que ya han sido investigadas y puestas en práctica (líneas de productos, patrones de diseño, construcción de frameworks, etc.). De este modo, este enfoque no parte desde cero, sino que integra el conocimiento de estos temas.
El principal promotor es Microsoft, por lo que su posición dominante en el mercado puede conseguir que el enfoque de las Factorías de Software acabe implantándose en la industria. Pese a ello, se debe tener en cuenta que OMG también auna un número importante de multinacionales del desarrollo de software, por lo que esta ventaja puede ser relativa.

MDA + Factorías de Software?
Cada uno de los enfoques discutidos hace énfasis en ciertos aspectos del proceso de desarrollo de software. Esto les confiere ciertas ventajas respecto al otro en aspectos específicos y claramente diferenciados. Una cuestión que surge rápidamente es ¿sería posible integrar los dos enfoques? Para ello deberíamos seguir las recomendaciones de ambos e integrar de algún modo líneas de productos, modelos de alto nivel de abstracción, frameworks de implementación, lenguajes de dominio especifico, los lenguajes de OMG, etc.
Seguir este enfoque integrador tiene una serie de ventajas:
1. La estrategia general del método está definida: línea de producto + framework de implementación + lenguaje de dominio específico.
2. Las técnicas a utilizar están definidas:
MOF + QVT.
3. Existen herramientas de soporte: EMF de Eclipse o MDR de NetBeans, por ejemplo.
4. Se pueden aplicar técnicas conocidas propuestas por las factorías de software, como los "feature models"para la construcción de la línea de producto o los patrones de diseño para el desarrollo de framework de implementación.

Por lo tanto, para desarrollar una método que integre MDA y Factorías de software habría que:
• Hacer uso de la estrategia metodológica que proponen las Factorías de Software; es decir, seguir un enfoque basado en:
1. el desarrollo de una línea de producto,
2. la construcción de un framework de implementación para los sistemas
que serán desarrollados siguiendo la línea de producto, y
3. la definición de un lenguaje de dominio especifíco (DSL) que permita capturar los requisitos específicos de cada uno de los sistemas utilizando las primitivas conceptuales más adecuadas para ese tipo de sistemas.
Construir el DSL de manera que:
1. proporcione primitivas conceptuales independientes de plataforma.
2. se especifique siguiendo las técnicas que propone OMG (creación de un
profile UML o definición de un metamodelo con MOF).

Cuando Software Factory no es una marca comercial

En algún momento, en otro sitio, se ha discutido sobre Software Factories, discriminando los dos conceptos involucrados en este nombre, devenido marca en manos de Jack Greenfield y otros. Pero la primera definición de SF fue la de la construcción de software siguiendo procedimientos "industriales". Repitiendo la definición comentada en otro lugar:

la Fábrica de Software refiere el sentido de producir con rapidez y calidad a través de procesos conocidos, repetibles y gerenciables, y principalmente, mejorables continuamente, no sólo por la incorporación de técnicas y herramientas en el desarrollo del software, sino porque se mantiene constantemente el foco sobre el mejoramiento del proceso de producción y cada uno de los pasos que esto acarrea. Aaen, Bøttcher y Mathiassen indican que el "término fábrica indica un compromiso a largo plazo, esfuerzos integrados - por encima de proyectos individuales- para mejorar las operaciones relativas al software".
Entre los significados de la fábrica de software, mencionan Aaen, Bøttcher y Mathiassen, "mejorar la efectividad del proceso, reducir la cantidad de retrabajo y reusar el ciclo de vida de los productos". De forma tal que se puedan obtener mejores resultados en menor tiempo y con menos costos, pero agregan que además sea una industria en la cual las actividades del desarrollo de software sean "predecibles lo que significa que los costos estimados y compromisos de cronograma pueden ser satisfechos, confiables lo que significa que la capacidad del proceso es conocida, mejora continua significa que la atención constantemente se concentra en mejorar el proceso y que el conocimiento y las habilidades para mejorar están establecidas. Todo esto debería ser logrado a través de la atención al proceso (mejoramiento) y no a los métodos o herramientas", lo que supone la utilización de métricas y técnicas aplicadas al proceso del software y apuntaría a la satisfacción de las dimensiones de la calidad enunciadas por Falconi Campos.(calidad intrínseca, entrega del producto, costo, motivacion de sus productores, seguridad). Falconi Campos, Vicente. TQC: Control de la Calidad Total (al estilo japonés). Bloch Editores S.A., Rio de Janeiro, 1994.)

Así, la utilización de métodos repetibles, mejorables, seguros y confiables, están entre los objetivos básicos de la construcción de software "industrial". El concepto de desarrollo basado en modelos de OMG (y otros) procura justamente la construcción de software confiable, no dependiente de la pericia de cada desarrollador integrante del proyecto, y que sea capaz de ser sostenible en el tiempo. A pesar de lo que Greenfield y otros sostenedores de la versión MS de Software Factories afirman, MDA (y otros proyectos relacionados) son excelentes conductores de estas ideas. Thales Research & Technologies de Francia muestra que es posible encarar un proceso SF basado en conceptos MDA. Participante activo en OMG, sostiene varios proyectos conducentes al desarrollo de aplicaciones basados en modelos convertidos luego en código, y uno de estos proyectos en curso trata de sostener una Fábrica de Software por medio de un constructor MDA. Un papel expuesto por Benoît Langlois y Daniel Exertier en OOPSLA 2004 detalla el proyecto a esa fecha. Su análisis puede servir para estudiar cómo usar el desarrollo basado en modelos para la construcción de sofware a gran escala:

A major issue in software engineering is software production improvement. This paper studies the objectives and the features of a model-driven software factory contributing to automate the production of software systems in evolving environments (specifications, standards, technology, and tools). Through these considerations, this paper introduces MDSoFa, a Model-Driven SOftware FActory tool developed at THALES meeting this need, and a set of technical and methodological lessons learned from this tool implementation and usage.(...)

In this paper, we analyze the combination of two approaches, model-driven engineering and software factory, to rationalize software production. The main interest of model-driven engineering is that model is the primary type for developing systems, e.g. from requirements down to code, and this in different perspectives, as domain, technical, or process. The main interest of software factory is software production automation, for going from a handcrafted to an industrialized software production and for allowing development time reduction and software quality improvement. In this vision, a model-driven software factory is a software factory where models are central with the main objective to ease and industrialize software production.(...)

A clear and predictive method of work needs standard domain, technical or process assets. Standardization can be international, enterprise, or project wide. Besides, a rationalized process implies not only rationalized activities but also engineering tools adapted to the defined engineering processes. The common denominator is to develop a systematic method of work, the way for automation. The interest is to create a synergy between standards, processes and tools, raising together the software production maturity level.(...)

A model-driven software factory is a combination of metamodels, expertise, tools and frameworks for producing output assets in an industrial way, that can be also metamodels, expertise, tools and frameworks, i.e. recursively, a model driven software factory can produce a model-driven factory. Depending on the focus of the produced assets, a software factory has the following functions:

• Model factory. In this case, models are produced automatically from models. For instance, a model transformation can be deduced from the application of a model transformation pattern on a domain metamodel.

• Expertise factory. In this case, the software factory produces specific or generic expertise from specific or generic expertise. For instance, model checks and wizards can be produced from a methodological metamodel and a generic expertise for model checking and assistance.

• Tool factory. In this case, the software factory produces tools or executable environments in a tool, as a tool-specific modeling chain.

• Framework factory. In this case, the produced asset is a framework.

• Software factory factory. As mentioned above, this specific case covers the reflective approach when all types of asset are involved in input and output of the software factory for producing a software factory.(...)

We focus now our interest on software factories producing modeling software factories, involving cooperation of heterogeneous domains and pieces of expertise, with development qualities to be respected. In the model-driven perspective, a software factory production can be seen as a mapping execution: the modeling environment is modeled at the metamodel level and the result of the software factory is the modeling environment that will be used by modeling users. (...)This software factory mapping is comparable to an abstract to concrete syntax mapping, or, in MDA terms, to a PIM (Platform Independent Model) to PSM (Platform Specific Model) mapping. A further step consists in instantiating the same software factory for different modeling tool platforms, each having its own specificities (tool-vendor UML metamodel, language, packaging, deployment protocol…) where target platform becomes a parameter to be considered during the software production. This is key for large companies where methodologies and practices are similar with different modeling tools.

Este es un proyecto en curso. No necesariamente es la única solución, pero sin duda sugiere mejores vías de construcción del software.

Más sobre MDA vs SF

Continuando una discusión abierta hace algún tiempo en The Server Side, Jack Vaughan expone sobre Software Factories brevemente, sólo para recordar que parecería que el principal objetivo de hablar sobre SF es desacreditar la iniciativa Model Driven Architecture. Sin embargo, en el marco de usuarios esperanzados en Visual Studio 2005 Team System, un puñado de observaciones críticas apuntan a la inconsistencia de este concepto en su desarrollo actual: en primer lugar, simplemente el remate del comentario de Vaughan.

Not discussed here, of course, is the idea that a key goal behind MDA is to create models that are high-level enough to be platform independent. Frankly, and for obvious reasons, this is not too often a driver in the MS camp

...es decir, evidentemente un punto fundamental en la discusión es la posibilidad de modelar con independencia de la plataforma, bajando el diseño a código, sea en Windows, Linux, Unix o AS400.
Pero es en la pequeña lista de respuestas, casi todas ellas desde el propio campo, donde se puede sacar más sustancia:
Dice Tad Anderson:

My frustration is with today, and the tools we are being handed today. With VSTS 2005 I lose XDE, I gain a DSL roundtrip class diagram modeling tool, and a bunch of Data Center modeling tools. So now I am stuck with the choice between Sparx, Borland, and some other tools to be able to do my job today. I don't have time to write a DSL UML tool so I can architect this project, and I wouldn't even if I had the time.

My frustration is not with your Software Factory movement, my frustration is with the gap that has been put in place by MS making us wait for your Software Factories movement to produce the tools and process frameworks we need to do our job. So I am not against your movement of Software Factories, I am against Microsoft's position of promoting it as what will be available, while providing nothing to us today

Otras intervenciones incluyen una defensa de SF de Aidas Ozelis, respondida detalladamente por Jon Kern, de OptimalJ.

The C Family of Languages

A propósito de los comentarios sobre John Vlissides , me interesé por el blog Lambda the ultimate, sostenido por Ehud Lamm, que también le dedicó una breve referencia. El caso es que Lambda...reúne un gran número de entradas de interés sobre lenguajes de programación, abiertos por paradigmas (Funcionales, Objeto-Funcionales, Lógico-Declarativos, Orientados a Objeto), y otros asuntos de fundamentación teórica. Agendarlo y seguirlo...
Viene al caso de la visión irónica de Billy Hollis sobre la "familia de lenguajes C", la republicación de un reportaje a Ritchie, Stroustrup y Gosling de julio del 2000, sobre el suceso de la familia, sus puntos de contactos, y sus diferencias, y reeditado en 2005 por Herb Sutter:

Among technical factors, C and C++ benefited from their closeness to machine and absence of artificial restrictions on what can be expressed. That allows low-level systems work to be done in these languages and for the full performance of a machine to be delivered to its users. Java benefited from running in its own virtual machine and from coming with a large set of libraries that decrease the time needed for a programmer to become productive. Unix gave a similar boost to C. In contrast, the C++ world suffers from fragmentation of its huge base of libraries, many of which are proprietary and supplied by competing vendors.(Stroustrup)

Qué hubiera hecho distinto?

There are a bunch of things that I'd do differently. There are a number of things that I'm not entirely happy with and it's not clear what the right answer is. I'm not really happy with the schism between interfaces and classes; in many ways it feels like the right solution wouldn't get in the way.

There have been a number of things -- like, for example, multiple return values -- that these days I kind of wish I had added. That was one where I really liked the feature and most other people just sort of went, "Huh?" Another one that sort of went that way was that I had been going down this route of having a bunch of stuff to do with preconditions and postconditions and assertions in an Eiffel-like way, and actually in the community of people who were using it at the time the average answer was, "Huh? Why would I ever want that stuff?" I think that the average developer today would say that too. But then there's a pretty reasonable crowd of people who believe in things like Design By Contract, and it's one of these things where a lot of people feel like, "If only the rest of the world was educated enough to understand what this is about, they'd be better off." And I actually kind of agree with that. The problem is that most of the world could actually care less.

There are some things that I kind of feel torn about, like operator overloading. I left out operator overloading as a fairly personal choice because I had seen too many people abuse it in C++. I've spent a lot of time in the past five to six years surveying people about operator overloading and it's really fascinating, because you get the community broken into three pieces: Probably about 20 to 30 percent of the population think of operator overloading as the spawn of the devil; somebody has done something with operator overloading that has just really ticked them off, because they've used like + for list insertion and it makes life really, really confusing. A lot of that problem stems from the fact that there are only about half a dozen operators you can sensibly overload, and yet there are thousands or millions of operators that people would like to define -- so you have to pick, and often the choices conflict with your sense of intuition. Then there's a community of about 10 percent that have actually used operator overloading appropriately and who really care about it, and for whom it's actually really important; this is almost exclusively people who do numerical work, where the notation is very important to appealing to people's intuition, because they come into it with an intuition about what the + means, and the ability to say "a + b" where a and b are complex numbers or matrices or something really does make sense. You get kind of shaky when you get to things like multiply because there are actually multiple kinds of multiplication operators -- there's vector product, and dot product, which are fundamentally very different. And yet there's only one operator, so what do you do? And there's no operator for square-root. Those two camps are the poles, and then there's this mush in the middle of 60-odd percent who really couldn't care much either way. The camp of people that think that operator overloading is a bad idea has been, simply from my informal statistical sampling, significantly larger and certainly more vocal than the numerical guys. So, given the way that things have gone today where some features in the language are voted on by the community -- it's not just like some little standards committee, it really is large-scale -- it would be pretty hard to get operator overloading in. And yet it leaves this one community of fairly important folks kind of totally shut out. It's a flavor of the tragedy of the commons problem.(Gosling)

y mucho más...

Oracle: interés en Open Source

Dana Blankenhorn comenta en los blogs de ZDNet el incremento de la presión de Oracle sobre nuevos objetivos de control: Recursos de la comunidad de código abierto, MySql en primer lugar. Primero, la compra de InnoDB, y ahora la compra de SleepyCat Software, soporte de Berkeley DB, que tambien puede ser usado como motor de MySql:

Sleepycat, too, can be used as a storage engine with MySQL. Shimp said that its acquisitions of Innobase and Sleepycat do not change Oracle's relationship with MySQL and that both companies will operate as stand-alone entities within Oracle.

Blankenhorn menciona lo que Sarah Lacey comenta en Business Week:

Oracle is in talks to buy at least three open-source software companies in deals that could be valued at more than $600 million, BusinessWeek Online has learned. The transactions would extend the 18-month, $18 billion spending spree by Oracle Chief Executive Larry Ellison that has engulfed PeopleSoft and Siebel Systems. They would also put Oracle in control of some of the most sought-after open-source projects. Overnight, Redwood Shores [Calif.]-based Oracle would rival IBM (IBM) as the prime evangelist of a movement that's revolutionizing how software is developed and distributed [see BW Online, 2/6/06, "Open Source's New Frontiers"].

Sin embargo, aunque Blankenhorn califica la situación del mercado ERP como duopolio, con Oracle y SAP como controlantes, estima que el código Open Source es de todas formas incontrolable:

In the end open source is a bit like water. It flows no matter what you do. Oracle is going to learn that, but it will take time.

John Vlissides

El 24 de noviembre del año pasado, siendo muy joven aún, murió John Vlissides, coautor de Design Patterns, y por lo tanto parte de la fundante Gang of Four. Un cáncer cerebral a los 44 años causó su desaparición. Me enteré sólo por un comentario en comp.object, el foro de OOD en Google. Quizá porque tuve demasiado que hacer en estos meses, esta fue la primera noticia que tuve de su muerte; luego encontré que incluso el Washington Post le dedicó un obituario. En particular, Ralph Johnson (GoF), le dedicó un recuerdo en su blog. Ironicamente, el resumen de su actividad en IBM, no es localizable en este momento...(Sólo un reportaje).
The Server Side también le dedicó una serie de memorias de personas que se formaron en el seguimiento de sus investigaciones (enlace en el título de esta nota).

Qué patrón de diseño usar para versionamiento?

Un interesante hilo de discusión se acaba de abrir en comp.object, el sitio de discusión sobre OOD en Google:

I need to implement a history/revision system. Such that there will be an object and as it's values change, the revision changes and there is a history of the old values. What is the correct design pattern to use to implement something like this?

HS Lahman y otros abren ideas sobre cómo tratar el versionamiento como objetos con historia. Para seguir, y si se anima, aportar.

CSS para principiantes

En Techrepublic, entre los cientos de recursos disponibles, un buen manual de aprendizaje de CSS y XHTML.

Mas sobre Google Talk y Open Federation

Sean Michael Kerner dedica un breve artículo a Open Federation, destacando la implementación del protocolo Jingle , base para un salto hacia VOIP:

The Jingle specification extends the XMPP protocol for VoIP and other P2P communications and uses.

Enlace al artículo en el título de esta nota.

Una visión irónica de la polemica C++/Java

Suelo encontrar entre los devotos de C++ y Java una oposición calurosa que tiende a elogiar sin críticas el bando propio, y negar todo en el lenguaje o arquitectura ajenos. Billy Hollis ofrece un resúmen sarcástico de la evolución de C a C++ y C#, que (no sin razón) incluye a Java en la familia. Al menos, puede ayudar a poner sobre la mesa los lados flacos de "la famila"...
Aunque ya pocos se sorprenderían, también se puede ironizar con BASIC.

CORBA-web Services: closely/loosely/thightly coupled?

En Middleware Matters, el blog de Steve Vinowsky (IONA), existe una discusión sobre CORBA y servicios web, acerca de un punto en común entre ellos: El intento de articular aplicaciones en ambientes heterogéneos, en forma de componentes, que ofrezcan servicios capaces de ser tomados sin necesidad de conocer detalles internos de implementación. ¿Por qué falló CORBA? (no hay duda sobre esto). ¿Corren el mismo riesgo los servicios Web? ¿Loosely Coupled está realmente logrado?.
Ver los comentarios de Michi Henning:

I agree with Mark that CORBA has failed on the Internet. We simply don't see public integration using CORBA among companies. Instead, CORBA is typically used for communication among application components that are developed by the same team, but is not used by companies to offer a public remote API that anyone could call. Sure, I can send CORBA messages over the Internet. But that's not the crux of the question. It's much more a question of whether unrelated parties use CORBA (or WS) to communicate: one party provides the server, and an unrelated party then uses the server, much like a person using a web browser accesses a web server. And I don't see either CORBA or WS being used that way (other than for trivial toy applications).

I also agree with Mark that WS is no more loosely coupled than CORBA. WS proponents claim that loose coupling is achieved by using XML, because XML can be parsed without a priori knowledge of the contents of a message. This is the famous "the receiver can ignore what it doesn't understand" argument. I see many problems with this argument:

- This idea of loose coupling passes the buck to the application. Basically, the sender sends a message that can have all sorts of data in it, and then the application, at run time, has to make sense of it somehow. This is a recipe for bugs because type checking is not enforced by a compiler, and not enforced by the distribution infrastructure.

- We have WSDL. But WSDL ends up creating type definitions that are just as tightly-coupled as IDL ones. (And everyone seems to agree that WSDL is important.) But, where does that leave loose coupling? We have XML at the protocol level, which is loose, and we have WSDL at the application level, which is not loose. There seem to be contradictory messages and intents here.

- Yes, I can define WSDL that makes things optional and types them "loosely", in some sense (just as I can define IDL that does that). But if I do this, the value of having a type system in the first place diminishes, and I'm back to passing the buck to the application, which then again has to figure out at run time (instead of at compile time) whether a particular received message actually makes sense. And note that it is the *application code* that is responsible for this, not the distribution technology, so I get to write type checking code in my applications over and over and over again...

- Even if I do define WSDL that is "loose" and makes lots of things optional, that typically doesn't help me. Loose coupling isn't of interest just for its own sake, but is of interest because people are looking for a way to solve the versioning problem: how can I evolve a distributed application over time without breaking everything that is deployed already, and without having to recompile and redeploy the universe? If I define WSDL that is "loose" to start with, so I get the loose coupling I so much need, by implication, I know in advance how the application will evolve: I put the "loose" bits in the WSDL definitions where I expect future variation in the data. But real life doesn't work that way. None of us is prescient and, as a rule, what makes the versioning problem so hard is that we *don't* know how an application will evolve in the future. In other words, people who say that I can solve the problem by writing "loose" WSDL are kidding themselves: the real world is not cooperative enough for this to work.

- The old argument of "the receiver can ignore what it doesn't understand" is fallacious. For one, versioning and loose coupling are not about just being able to send additional data, but also about changing existing data, operations, parameters, and exceptions. Moreover, real-world versioning is sometimes not about changing interfaces or data types but about changing *behavior*: it is common for someone to want to change the behavior of an operation for a new version of the system, but without changing any data types or operation signatures. Second, the assumption that things will work just because the receiver can "ignore what it does not understand" is very naive. What I don't know can hurt me as much as what I do know. (Would you sign a contract that I put in front of you when several paragraphs are written in a language you cannot understand?)

- Trying to achieve loose coupling at the protocol level is simply the wrong place in the abstraction hierarchy: the protocol is about moving bits back and forth, and about doing this reliably and efficiently. Loose coupling is about dealing with application-specific data types and interfaces and whether it's possible to gracefully evolve these over time. I don't see why I have to have a "loose" protocol in order to enable loose coupling.

If we are interested in loose coupling, multiple interfaces are a far better approach. Instead of trying to define one interface that is loose enough to accommodate all the possible variations, I define several interfaces, each of which accommodates exactly one variation. That way, each interface is strongly typed, but, collectively, all the interfaces together are loosely typed because they offer several alternatives for sending a message. Given that, what I need is a mechanism to select the interface that best suits my job, and a mechanism that lets the receiver of a message know which version is being addressed by the sender. Put those mechanisms into the distribution platform, so applications don't have to reinvent them all the time, and you have a workable answer to the "loose coupling" dilemma that doesn't require me to sacrifice static type safety, and that doesn't throw on-the-wire bandwidth and CPU cycles around as if they were growing on trees.

This idea works very well, and isn't new either: COM supports multiple interfaces, where a single object with a single object identity can present different personas to the world, and Ice has a mechanism called "facets" that allows versioning of distributed applications.

La discusión ofrece también una reseña de los problemas que atravesó CORBA, que no solo fueran técnicos, sino también comerciales, el mismo conflicto que sigue acompañando la elaboración de estándares hoy (los comentarios de Tom Welsh).
Un comentario de erwin enfría los entusiasmos:

I've done a limited nr of CORBA-based solution architectures and implementations a while ago. My feeling is that CORBA definitely is not a failure. I even see 2 big success areas: technological and analytical.

Technologically speaking, CORBA offers a robust and complete stack with a clear and well-documented approach on designing and implementing distributed solutions.
Only disadvantage : tool/server providers were not really interested in providing true interoperability...

The firewall issue is a fake argument.

One of the great values of OMG/CORBA that hasn't been mentioned yet, is the extensive analysis of what's needed for distributed applications. I have the feeling that lots of "new" paradigms arriving later can be seen as re-implementations of the CORBA standards/services etc.

Of course, with some specific variations, e.g. messages with some arbitrary text format that happens to be parseable by an XML-parser (and where lots of other acronyms can be applied to flabbergast any interested reader) i.o. a binary format.

In the web services domain, people are only starting to discover what's needed for a complete architecture stack.

There's a big chance that the result will indeed be a system that has similar services as CORBA, but this time with human-readable messages and the ability to flow through port 80.

Humans can imagine valid semantics for these messages. But is this really valuable? I agree with Michi Henning that in applications, semantics can not be derived/invented at run-time anyway, they have to be a-priori known (and coded), whether the msg is binary or text-based (with or without standard tools to parse the text).

The fact that people now seem to be willing to wait for a nr of years for this web services platform to stabilize and become more complete, and for tool/server providers to build more-or-less interoperable systems (e.g. MS and rest-of-world), seems to be more a new mindset in the SW-world than to be based on technological reasons.

I'm sure it would have been much easier/faster to provide interoperability on IIOP, but at the time MS could not do that as they were still positioning (D)COM as the holy grail.

But now, XML has such a huge mindshare that everyone is willing to invest in technological interoperability...

Byte-streams didn't have the same sex-appeal... ;-)

Loose coupling will never happen, at least not before we have application components with reasoning capabilities.

Ken Horn extiende la discusión en sus comentarios de su blog.
El debate se produce entre activos participantes de la construcción de medios de soporte de arquitecturas heterogéneas: Michi Henning propone ICE. Mark Baker propone REST. Harold Carr propone PEPt, y otros más...
La discusión, en el enlace del título de este artículo.

Google Talk toma vuelo

Google Talk se convierte en un sistema federado, y marcha a ser también multiplataforma: un sistema capaz de aceptar usuarios de otros sistemas de mensajería instantánea, siempre que mantengan un protocolo común, en este caso XMPP, usado por "Earthlink, Gizmo Project, Tiscali, Netease, Chikka, MediaRing, and thousands of other ISPs, universities, corporations and individual users". Por este camino se acaban los estancos de la mensajería instantánea (Messenger, Yahoo), sin otros requisitos que soportar el protocolo. En el futuro, soportará también SIP (VOIP, Video conferencia). Pero además, Google anuncia clientes de mensajería para Linux y Max OSX, además de aceptar clientes de otros proveedores: "The Google Talk service is built to support industry standards. You can connect to the Google Talk service using Google's own client, as well as many other IM clients developed by third parties".

Uno más que encuentra SilkTide

Encontré un proveedor de servicio que se testeó con SilkTide a modo de calificación, y busqué el sitio para ver cómo pudiera ser de útil. Lo usé para testear mi página y luego para hacerlo con este blog. Finalmente, busque el sitio con Google para observar hasta qué punto llegué tarde a conocerlo...
Un buen diagnóstico para quien quiera construír una página. Para más observaciones y recomendaciones, le quedan dos posibilidades: siga el enlace de Google, o visite el sitio. Por mi parte, trataré de seguir sus consejos, que en algunos casos coinciden con los lados flacos que ya conocía, y en algún momento resolveré...

Dilbert

Para seguirlo todos los días...(enlace en el título)

Control de cambios explicado por Jim Johnston

Johnston explica en dos artículos en CM/Crossroads, acompañado de gráficos y de algunos de los papeles de registro, distintos escenarios de control de cambios y configuración, útiles para armar un camino de control de cambios para quien lo necesite. Parte I; Parte II

Domain Specific Modeling explicado en tres palabras

Artículo publicado en Methods & Tools. Por ahora, ubicable en su lista de artículos corrientes. Luego, habrá que recurrir a los archivos por su título ("Domain-Specific Modeling for Full Code Generation", para los artículos de fin de 2005). Una discusión sobre el uso de UML para generación de código, y la presentación de la alternativa DSM con varios casos prácticos de ejemplo. Finalmente, la comparación con MDA.
En alguno de los artículos anteriores sobre DSM aquí, algún enlace apunta a éstas ideas. Pero bien, aquí está el original.