JUnit 4.4 en Maven Central Repository

Ha costado pero ya está en el repositorio central de Maven la última versión de JUnit (4.4). Siento el ataque de vanidad, pero hoy ha sido la única alegría que he tenido y necesitaba una gotita de alegría... :-)

SCA

He estado leyendo el libro "Service-Oriented Architecture (SOA): Concepts, Technology, and Design" de Thomas Erl y he llegado al convencimiento (entre otras muchas cosas) de que para hacer "verdadero SOA" son necesarios:

• una infraestructura que haga posible la localización y la colaboración (síncrona o asíncrona) entre servicios
• buscar un modelo a partir del cuál poder diseñar los servicios como componentes estándar (independientemente de la infraestructura en la que se desplieguen)
  

Respecto al segundo punto, leyendo, leyendo y navegando, navegando, he llegado a una serie de artículos de IBM sobre integración usando SOA. Tras leer varios de ellos (reconozco que no todos), he visto que SCA sería una posible solución. Para los que quieran una introducción rápida a SCA, creo que es mejor acudir a la fuente directamente. En la web de OpenSOA se define el modelo en UML, por si eso ayuda en algo a su comprensión. Lo mejor de todo es que ya hay incluso especificación para API Java y ejemplos de cómo usar JAX-WS para implementar un componente "SCA-enabled".

SCA es una propuesta OASIS (por lo que se garantiza que Microsoft también participa y que, por tanto, está garantizado el éxito en la interoperabilidad). A mí, sin embargo, me queda la duda (y me gustaría mucho que alguien me lo explicara) sobre qué diferencia hay entre SCA y JBI y entre SCA y WSIT. Lo que pasa es que la gente de Glassfish parece un poco escéptica al respecto de adoptar SCA (al menos tal cual está ahora definida). Ya le pregunté "in person" a Eduard Pelegrí y me contestó que él veía más factible una convergencia a medio/largo plazo de JBI (Sun) y SCA (IBM).

De todos modos, vamos a ver, que yo sepa... SOA no sólo se puede implementar con .NET o con J2EE... ;-)

Objetos vs Servicios (II)

Acabo de encontrar otro artículo similar al anterior donde se trata (aunque tangencialmente) bastante más acertadamente (en mi opinión) la diferencia entre OO y SO.

Permitidme que plagie tal cual el contenido del apartado que me interesa resaltar:

SOA and object orientation

Some practitioners consider SOA a direct evolution of OO, considering services as objects or components on steroids (see Resources [10]). This is as far from reality as it can get. The similarities do not extend beyond system decomposition for definition and encapsulation for implementation.

Additional features of objects, such as inheritance and polymorphism, are not applicable to SOA. What really sets the two apart is usage and programming model (similar to the differences between instance-based and service-based collaborations, described in Resources [11]).

• In OO, multiple object instances of the same type (potentially existing simultaneously) are distinguished based on their internal state, representing a particular execution context. As a result, the object's life cycle is controlled explicitly by its consumer through an object creation.

  Every object exposes multiple methods, which are bound to a particular instance (execution context) and allowed to manipulate variables on a given instance.

• In SOA, services support not the execution context of a particular consumer but rather the state of the enterprise resources associated with the particular service. Typical service invocation is stateless; the notable exception to this rule is a conversational composite service, which typically has an execution context, supporting a particular conversation.

  As a result, the service life cycle is not associated with a life cycle of any particular consumer -- it exists regardless of whether a particular consumer invokes it or not. The resulting programming model is the direct invocation of the service, without its explicit creation.

This difference has a profound impact on the interface definition for objects and services. In OO, multiple methods defined on the interface always physically belong to the same instance of the object because they are bound to the same execution context. In contrast, since services don't have an execution context, the association of methods in the service interface is purely logical.

The service (and consequently service interface) effectively represents a namespace providing a logical grouping of service methods, which are otherwise independent entities with their own quality of service requirements, security, versioning strategy, endpoint address, and so on. To make a programming language analogy: every method of the service is similar to a FORTRAN subroutine/function, which can exist and be executed independently from others.

Este artículo trata también sobre una "vieja" discusión (al menos nosotros la hemos tenido en Degesys) sobre si los servicios deben ser sin estado o con estado... lógicamente han ganado los servicios sin estado porque es lo que toda la literatura explica, pero al menos a mi me queda la duda de... ¿y cómo se hace entonces una cesta de la compra en una arquitectura orientada a servicios? ¿Se persiste siempre la cesta de la compra en la base de datos, se guarda en la sesión web o se tiene un SFSB entre la aplicación web (o swing) y los webservices? :-(

Por lo demás, el artículo es realmente muy completo y clarificador. Os lo recomiendo.

Objetos vs Servicios

Por fin he encontrado un artículo donde se compara la orientación a objetos y la orientación a servicios. Además, de paso, explica también bastante claro cómo se debe diseñar orientado a servicios.

Lo que puede parecer un poco chocante es que no se dice por qué en SOA se prescinde de cualidades de la orientación a objetos (OO) largamente probadas en la ingeniería del software. Se dice que:

Como frecuentemente se crea un modelo de caso de uso aislado para cada dominio del problema (y por tanto para cada projecto de desarrollo) el dibujo a gran escala de la empresa queda difuminado en muchos casos. Es más, por varias razones, los modelos de caso de uso no siempre están sincronizados con sus homólogos BPM (modelos de procesos de negocio).

Es como si todo el mundo hubiera concluido que OO es muy difícil para esos miles y miles de programadores tontos, que abundamos por doquier y que no somos capaces de entender los procesos de negocio (a la vista están los resultados). Si os digo la verdad, creo que tienen parte de razón porque todos los días compruebo que somos artesanos del software (con todo el respeto para los artesanos, por supuesto), de modo que no se puede confiar mucho en nosotros para construir productos que realicen todo lo que quieren los clientes...

Conceptualmente, en SOA hay 3 niveles de abstracción principales:

• Operaciones: Transacciones que representan unidades lógicas de trabajo individuales. La ejecución de una operación causará normalmente que se lean, escriban o modifiquen uno o más registros de datos persistentes. Las operaciones SOA se comparan directamente con métodos OO. Tienen una interfaz específica y estructurada y devuelve respuestas estructuradas. Igual que para los métodos, la ejecución de una operación en particular puede conllevar la invocación de otras operaciones.
• Servicios: Representan agrupaciones lógicas de operaciones. P.ej., si vemos el PerfilDeCliente como un servicio, entonces Buscar Cliente por número de teléfono, Listar clientes por nombre y código postal y Guardar datos de un nuevo cliente representan las operaciones asociadas.
• Procesos de Negocio: Son un conjunto de acciones o actividades que se ejecutan con objetivos de negocio específicos en mente. Los procesos de negocio normalmente coordinan varias llamadas a otros servicios. Ejemplos de procesos de negocio son: Crear un nuevo empleado, Vender productos o servicios y Completar pedido.
  En términos SOA, un proceso de negocio consiste en una serie de operaciones que son ejecutadas en un orden secuencial de acuerdo a un conjunto de reglas de negocio. La secuenciación, selección y ejecución de operaciones es dnominado coreografía de servicios o procesos. Normalmente, servicios coreografiados son invocados a fin de responder a eventos de negocio.

Quedaría discutir cuál cómo debemos diseñar los componentes que implementan estos servicios. Supongo que depende un tanto del grano del componente en cuestión, pero sospecho que, dado que los servicios de más bajo nivel (las operaciones) son equiparables a los métodos de un objeto, no toca mucho hablar de OO en este punto, y si subimos al nivel superior, los procesos de negocio se definen como algo casi procedural (un programa BPEL es muy parecido a un programa COBOL) ;) Nos quedaría ver qué pasa justo en medio... en la capa de servicios de negocio... pero creo que es mejor dejar para otro momento la discusión entre modelo rico y modelo anémico... :$