Uno de los mitos más extendidos es que SOA se puede comprar. Que viene en una caja que pueda vender cualquiera de las empresas de software (IBM, Oracle, Software AG, etc.). También, que la orientación a servicios es una forma de hacer las cosas que aparece de manera natural con el uso de determinadas herramientas. Por desgracia, esto no es así.

En realidad no hay ninguna tecnología, producto o framework que sea SOA. Se puede tener una orientación a servicios con tecnologías ya disponibles anteriormente y por contra, se puede disponer de las últimas tecnologías y no construir servicios, sino aplicaciones silo, de la manera que podemos entender como “tradicional”.

De hecho, SOA es neutral desde el punto de visto de la tecnología y el vendedor. En ultima instancia, es una forma de computación distribuida por lo que cualquier tecnología donde se pueda ejecutar programas de manera remota (la clásica Remote Producedure Call) y donde se pueda indicar el contrato del servicio (parámetros de entrada/salida) sería posible implementar una arquitectura orientada a servicios.

¿qué tecnología se puede usar para implantar SOA en la organización?

No hay una receta estándar para esto. Dependiendo de cada empresa y de su nivel de madurez puede haber una (seguramente más de una) forma de implementarla: La mejor forma de ilustrarlo, creo, sería poner dos extremos de esta implementación (ambos usados actualmente en un entorno de producción en grandes empresas).
La más simple sería:

  1. Los servicios se implementan mediante clases Java sencillas (JavaBeans del tipo POJO Plain Old Java Object).
  2. El contrato se indica mediante el interfaz Java (que define el comportamiento o funcionalidad de la clase pero no su implementación).
  3. Un repositorio o listado más o menos primitivo de los servicios (clases POJO) disponibles y su interfaz (puede ser desde un fichero de texto hasta una base de datos)
  4. La composición de nuevos servicios más complejos a partir de otros más sencillos se hacen mediante programación. El programador “orquesta” un servicio mediante la llamada o invocación a otras clases más sencilllas.
  5. Para la ejecución en remoto de estos servicios se pueden usar frameworks de código abierto que publican los servicios como servicios web de manera más o menos automática (por ejemplo Axis2 o Spring)

Por otro lado, una arquitectura más compleja y evidentemente más potente tendría lo siguiente:

  1. Los servicios de negocio se implementan mediante EJB 3.0 con persistencia JPA (Java Persistence API)
  2. El contrato de los servicios se indica mendiante WSDL (Web Service Definition Language)
  3. Se usa un Registry tipo UDDI para la publicación de los WSDL y el descubrimiento de los servicios en tiempo de ejecución.
  4. La composición de servicios se hace con una herramienta especializada con un interfaz para el programador que oculta el código fuente.
  5. Los servicios web se pueden ejecutar en remoto (es su propia naturaleza). Para evitar las proliferación de llamadas entre estos servicios (que pueden aumentar de manera exponencial). Se recomienda tener un Enterprise Service Bus al que se conectan todos los clientes y todos los servicios (abstrayéndolos de su localización física, su protocolo de comunicaciones y proporcionando una forma fácil de transformar los datos que fluyen de un servicio a otro).

¿estás de acuerdo con estas formas de implementar SOA? ¿cuál es la tuya?

Entradas relacionadas:

Comparte este artículo…

Anuncios