h1

SOA (Parte 1)

09/06/2008

Wizdoc [Icon By Buuf]

 Tips & Tricks.

Había una vez un paradigma de diseño de arquitecturas IT – si es que así lo podemos llamar – donde todos los sistemas y recursos de una organización se localizaban y eran ejecutados desde una computadora central o mainframe. Dicho paradigma, denominado monolítico, tenía como misión generar reportes mediante procesos por lotes para facilitar la toma de decisiones de la alta dirección.

Sin embargo, a partir de la década de 1960 y con la creación del microprocesador, este paradigma comenzó a menguar en favor de las arquitecturas cliente-servidor, donde una computadora (el cliente) generaba una petición a otra (el servidor), que tomaba dicha petición, realizaba un procesamiento y devolvía un resultado; todo ello a través de un medio electrónico.

Desde ese momento la información de una organización y los procesos que la "masajeaban" ya no residían en una misma máquina, lo que desembocó en una explosión de requerimientos de las unidades de negocio hacia sus respectivas áreas IT para diseñar, construir y liberar cada vez más soluciones de acuerdo a sus necesidades específicas. Con la venida del Internet se reforzó la tendencia, pues aunadas a los sistemas de apoyo a la toma de decisiones, ahora se demandaban soluciones IT para prácticamente cualquier ámbito dentro de la organización: desde catálogos, órdenes de compra o administración de los recursos humanos hasta soluciones de mensajería y chat.

Sin embargo, esta explosión de sistemas de información trajo consigo un problema de gestión de arquitecturas: conforme aumentaba el número de aplicaciones, mayor necesidad había de integrar la información y los procesos que operaban sobre ésta, degenerando en un esquema como se muestra a continuación:


Una arquitectura empresarial convencional.
[Click en imagen para ver a mayor escala]

Este desorden genera estructuras rígidas y difíciles de adaptar a los requerimientos de una organización o sus necesidades de negocio. Así entonces, se encontró que la mejor forma de atacar el problema era diseñando una arquitectura que hiciera provecho de las tecnologías que facilitaban la interconexión entre plataformas de un ambiente heterogéneo generando un nuevo modelo de implementación arquitectónica. CORBA y SOAP son las tecnologías de mayor relevancia, aunque EDI fue el precursor de dichas plataformas de integración.

¿El resultado? La Arquitectura Orientada a Servicios (Service Oriented Architecture – SOA):

SOA es un paradigma de diseño de arquitecturas empresariales que facilita la conexión de las diferentes aplicaciones y fuentes de información mediante componentes seguros y estandarizados (los servicios) de tal manera que puedan ser reutilizados y combinados de manera flexible para atacar las cambiantes prioridades del negocio:

Una Arquitectura Orientada a Servicios. Nótese que el Gestor de Procesos es el encargado de combinar los servicios para generar procesos coherentes que sirvan a las necesidades de la organización, mientras que el Directorio de Servicios funciona como una "Sección amarilla" que permite listar y encontrar todos los servicios que contiene la organización.


[Click en imagen para ver a mayor escala]

Los servicios que componen un SOA

Una arquitectura orientada a servicios está compuesta por unidades lógicas individuales que existen de manera autónoma sin estar aisladas totalmente unas de otras. Estas unidades deben ajustarse a una serie de reglas y principios que les permiten evolucionar de manera independiente, manteniendo al mismo tiempo cohesión entre ellas y hacia un estándar. Dichas unidades son conocidas como los servicios:

Cuando se realiza la transformación de una arquitectura convencional a un SOA, comúnmente la generación de servicios se implementa sobre soluciones con procesos claramente definidos:

Los servicios pueden encapsular fragmentos de lógica de negocio de diferente "tamaño", "peso" o complejidad.

Como puede apreciarse en el diagrama, podemos fragmentar los procesos en unidades lógicas más sencillas que encapsulen operaciones con mayor o menor complejidad; si generamos nuestro SOA a partir de aplicaciones implementadas bajo el modelo de Programación Orientada a Objetos (Object-Oriented Programming – OOP), esta tarea puede ser llevada a cabo con mayor facilidad pues las operaciones de los objetos pueden ser publicadas como servicios:

Un Objeto de Acceso a Datos (Data Access Object – DAO) y un componente de negocio (en este caso un Enterprise Java Bean – EJB) tienen publicados sus métodos como servicios.


[Click en imagen para ver a mayor escala]

Frecuentemente se asocia un SOA y los servicios que lo componen a los llamados web services o servicios web, sin embargo la implementación de web services no es un SOA por sí mismo ni un SOA tiene que estar compuesto necesariamente por web services: los web services son una plataforma de interoperabilidad que facilita la generación y envío de mensajes entre sistemas heterogéneos. Es decir, mientras existan (1) un protocolo de transporte y (2) un formato de codificación y decodificación de los mensajes, cualquier medio puede ser utilizado para construir un SOA:

• SOAP – Simple Object Access Protocol.
• CORBA – Common Object Request Broker Architecture.
• SNMP – Simple Network Management Protocol.
• FTP – File Transfer Protocol.
• SMTP – Simple Mail Transfer Protocol.

Por ejemplo, es posible construir un SOA basado en SOAP para definir el formato de los mensajes y SMTP como medio de envío. Dicho de otra manera: llamadas a través de mensajes XML sobre correos electrónicos para ejecutar los servicios (aquí se muestra un ejemplo de esta implementación en el lenguaje de programación Python).

Conclusiones

SOA es un paradigma de construcción de arquitecturas empresariales como en un momento lo llegaron a ser los sistemas monolíticos, el cliente-servidor o las arquitecturas de N-Capas. SOA es un compendio de todas las buenas prácticas de desarrollo e implementación de soluciones de hardware, software y gestión de sistemas basándose en la modularidad de componentes y procesos, agilizando el desarrollo de nuevas aplicaciones que sirvan a las necesidades de negocio de una organización. Por otro lado, un SOA no sólo se trata de UDDI, WSDL y HTTP: los web services sólo son una plataforma de interconexión mientras que SOA es un modelo arquitectónico.

Por el momento, sólo hemos visto la punta del iceberg. En el próximo post veremos que una Arquitectura Orientada a Servicios no sólo se trata de publicar servicios sin ton ni son, sino que la implementación – véase las "tripas" – de un SOA está compuesta por una multitud de elementos arquitectónicos como BPEL (Business Process Execution Language), XDMS (XML Document Management Server) o el tan cacareado ESB (Enterprise Service Bus).

One comment

  1. Bravo, una explicación muy puntual de lo que es SOA, preciso, conciso y deciso.!Graciaas.



Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: