Los principios SOA desde una visión estratégica

por

Con esta entrada vamos a dar comienzo a una serie de posts donde comentaremos los principios SOA, tratando de desmenuzarlos desde el punto de vista estratégico, aportando nuestra experiencia. En definitiva, compartiendo nuestro punto de vista.

 

Desafortunadamente, no existe un único organismo internacional que abandere las especificaciones sobre lo que es SOA, sus fundamentos, sus principios, etc. De hecho, si buscáis en la red la entrada “SOA principles”, encontraréis cerca de seis millones de entradas. Así que, al igual que ocurría con la definición de SOA, no tenemos más remedio que escoger entre tanta información.

 

Los principios de diseño SOA deben estar presentes en todo momento en una estrategia SOA

 

El sitio que recomiendo está en la sección correspondiente de este blog. En esta serie vamos a recorrer los principios SOA que propone Thomas Erl y su grupo de trabajo, y trabajaremos sobre ellos.

 

Pero antes, voy a aportar mi granito de arena a la lista de principios SOA, y voy a aprovechar esta entrada introductoria a la serie para plantear una idea que a menudo utilizo como “principio SOA inicial” o “fundamental”. Su enunciado suele ser efectivo para ayudar a cambiar de enfoque a los profesionales acostumbrados a los métodos tradicionales de integración, tan alejados de la estrategia SOA.

 

Este principio SOA puede enunciarse así:

 

Ningun Sistema de Informacion se integra con otros sistemas, sino que se integra unicamente con la Organizacion, mediante su Catalogo de Servicios SOA.

 

Para quienes estamos acostumbrados a la orientación a servicios, este principio resulta bastante evidente, pero en foros donde existe poca o ninguna experiencia en SOA, acostumbrados a los enfoques tradicionales de integración de sistemas, este principio dice mucho.

 

Ante el clásico requerimiento “el sistema A se integra con el sistema B”, este principio SOA dice que:

  • El sistema A no tiene que hablar con otro proveedor, el del sistema B, para intercambiar información sobre formato de los datos o el mensaje a intercambiar.
  • En vez de eso, tiene que hacer lo que determina la organización en sus normas de interoperabilidad y en su Catálogo de Servicios, en definitiva, lo que determina la oficina de Gobernanza.
  • En el lado tecnológico, que es normalmente el más cercano a los enfoques tradicionales, su punto de comunicación para el envío y recepción de la mensajería es el ESB de la organización, y no el sistema B.

 

De hecho, el propio enunciado del requerimiento ya es incorrecto: bajo este principio no tiene sentido hablar de “el sistema A se integra con el sistema B”. Lo correcto es que “el sistema A necesita usar (consumir) estos servicios“, o bien que “el sistema B debe proveer estos servicios“.

 

La idea central aquí es esta: quién provee los servicios que consume A, o quién consume los servicios que provee B, carece por completo de importancia para los extremos.

 

Lo verdaderamente relevante es el negocio, la posibilidad de reutilizar un servicio existente y las necesidades de rendimiento, tráfico, etc que plantea en cada caso de uso.

Te puede interesar

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Sigueme en las redes

Share This