Objetos vs Servicios

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