Desde ya hace unos años, dada la diversidad que existe en plataformas de desarrollo y aplicaciones desarrolladas en cada una de éstas, lo que se viene buscando es la interoperabilidad, léase, la comunicación y coexistencia entre todas estas aplicaciones.
En busca de esta comunicación, una de las Arquitecturas más usadas actualmente para el desarrollo de aplicaciones que existe es SOA (Arquitectura Basada en Servicios). SOA, no es un lenguaje ni un software, es un modelo que debemos seguir para implementar aplicaciones y que éstas puedan exponer ciertos "servicios", que pueden ser invocados o consumidos por otras aplicaciones.
Te muestro un ejemplo, digamos que acabas de terminar de desarrollar, para una misma empresa, dos aplicaciones , una aplicación encargada de manejar el ingreso y salida de materiales (Logística) y otra encargada de abastecimiento de materiales (Compra).
Imagínate ahora que son las mejores aplicaciones que hiciste hasta ahora, funcionan excelente, pero existe un pequeño problema. El encargado de comprar el material, no recibe notificación alguna cuando el material solicitado llega y vuelve a pedir más de ese mismo material. O peor aún, el encargado de logística a pesar de tener controlado su ingreso y salida de materiales, no expone esta información al resto de áreas de la empresa. En conclusión, pueden ser dos buenas aplicaciones pero funcionan como una isla, no se comunican, dificultando que la información fluya por las diversas áreas una misma empresa, como puedes ver este es un gran problema.
Si este ejemplo pasa en dos aplicaciones realizadas por una misma persona, imagínate que puede pasar con aplicaciones realizadas por diversos proveedores y quizás en diversas plataformas.
SOA, lo que propone es un modelo de trabajo donde las aplicaciones que se realizan, expongan parte de sus responsabilidades a otras que lo necesiten de forma que podamos armonizar el trabajo. Si hablamos de una empresa, para que podamos armonizar y soportar el trabajo entre la diversas áreas: Logística, Compras, Ventas, Finanzas, Contabilidad, etc . Ahora, esto no es una tarea sencilla, implica un arduo trabajo .
SOA, promueve la exposición de servicios por parte de una aplicación hacia otra, por lo que debemos tener en claro los siguiente conceptos:
| Proveedor | función cubierta por una aplicación que provee de un servicio a ser consumido por otra aplicación. |
| Consumidor | función cubierta por una aplicación que solicita de un servicio a un proveedor. |
| Servicio | exposición de una funcionalidad por parte de un proveedor, la cual es definida e implementada por una interfaz previamente establecida y la cual debe ser conocida por los consumidores. |
| Coordinación u Orquestación | Si hablamos de servicio, proveedores y consumidores, indudablemente no estamos hablando de UN servicio, sino de N servicios, lo mismo que proveedores y consumidores. Si tenemos N servicios, debemos de ser capaces de coordinar el trabajo entre estos de forma que asegurar el flujo y procesamiento de datos entre estos servicios definidos. |
Como puedes apreciar, no es una tarea sencilla. Es una tarea ardua de coordinación permanente, que empieza con una buena definición de los procesos y luego de las aplicaciones que den soporte a los procesos definidos.
SOA promueve el uso de servicios como exposición de las responsabilidades entre los aplicaciones (o sistemas) y para desarrollar esto ha encontrado en los Servicios Web, la mejor forma de poder implementar este concepto, dado que permite a un proveedor publicar un servicio y al consumidor consumirlo, utilizando un soporte independiente como los son WSDL (Estándar que permite definir cualquier servicio Web) y SOAP (Protocolo que define y permite como se puede intercambiar información, mediante el uso de XML). Veamos el siguiente gráfico
Como podemos ver en el gráfico anterior, podemos ver que como interactúan los proveedores con los consumidores sin importar de la plataforma que estamos hablando.
Ahora, si colocamos un concepto adicional como Orquestación vemos que la arquitectura SOA, toma un grado mayor de complejidad, debido a que estamos hablando no sólo de WSDL y SOAP, sino de conceptos como Seguridad, Transacción, Administración, Registro, etc, siendo estos siempre soportados por estándares independientes de los lenguajes en este caso, los WS.
Ahora, SOA, no es sólo servicios, bueno si lo es, pero siempre debemos ir un poco más allá, trabajar con SOA permite reutilizar los servicios existentes para construir otros, mejores o más complejos, de forma que podamos aprovechar el trabajo realizado anteriormente y no estar constantemente empezando desde cero. Pensar en servicios que pueden ser aprovechados por otros, permite realizar un mejor trabajo tanto dentro como fuera de tu organización.
Mira el siguiente gráfico para que veas los cambios que propone SOA en el desarrollo de aplicaciones.
SOA es realmente un tema bastante amplio, por lo que sólo he escrito acerca de las generalidades de esta arquitectura, te recomiendo leer más, dado que SOA viene siendo usado actualmente, esta en auge, y con las herramientas que tienen los lenguajes de programación puedes implementar mejores servicios para tus aplicaciones.
Artículos similares
Autor: Victor Parasi
Siempre es difícil escribir sobre uno mismo, qué contar, o por donde empezar, suele ser todo un dilema al momento de presentarse. Aquí vamos. Les diré que soy peruano, Ingeniero por vocación, dedicado a la docencia y siempre en la búsqueda de programar cada vez mejor. Aunque a veces algo terco, sé que no todo en la vida es blanco o negro. Existe el Open Source, y lo respeto pero me llevo mejor con el .Net. Si me hablas de preferencias, te digo que C#, C++, una buena película, colores oscuros, escribir, leer e investigar. Para terminar les diré que amo muchísimo a una mujer espectacular y que es la dueña de mi corazón.
Deja un comentario