Objetos vs Servicios (II)

Palabras clave:
Tiempo aproximado: 2 min.
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.