Cuando se piensa en SOA muchos piensan en un conjunto de herramientas de ORACLE, IBM, TIBCO, SOFTWAREAG o incluso WSO2 que hacen maravillas y con solo instalarlas ya basta para garantizar el éxito y “hacer SOA”.
En la mayoría de los casos esto no es verdad pero sí representa una inversión fuerte de capital en la adquisición de estas herramientas y las licencias que las acompañan, claro con excepción de WSO2.
Digo que no es verdad porque SOA es arquitectura por encima de cualquier otra cosa, y sin una buena arquitectura que permita achicar la distancia entre tecnología y negocio pues de nada sirven las herramientas.
La tendencia actual es la de desarrollar o adquirir arquitecturas de referencia que permitan sobre la base de buenas prácticas probadas y comprobadas desarrollar soluciones propias.
Sin pensar en conceptos rebuscados de lo que es una arquitectura de referencia diré que es:
- Un conjunto de soluciones arquitectónicas,
- patrones arquitectónicos y de diseño,
- buenas prácticas,
- guías y restricciones de diseño, implementación y pruebas,
- forma de representar la arquitectura.
O sea que permite encapsular en una solución genérica un conjunto de respuestas para problemas de arquitectura. En el caso que nos ocupa problemas relacionados con la integración y la interoperabilidad que son solubles gracias a SOA.
Entre las ventajas de usar una arquitectura de referencia podemos encontrar:
- Se mejora la gestión del conocimiento ya que toda solución arquitectónica exitosa es incorporada a la arquitectura de referencia.
- Se incrementa la reutilización de soluciones. No más el reinventar la rueda.
- Se le da solución rápida a problemas complejos.
- Se puede adaptar a diferentes dominios: TELCO, salud, educación, sector industrial, sector petrolero, gobierno electrónico, etc. ver la siguiente imagen.
Para finalizar esta idea si combinamos la arquitectura de referencia con la tecnología de un suite dedicada a SOA y BPM y diseñamos o adquirimos una metodología que permita la evolución desde un arquitectura de referencia a una arquitectura concretar y además que permita alinear la tecnología con los procesos de negocio existentes, haciendo un correcto uso y gestión de los RRHH, pues tendremos los 3 componentes necesarios para garantizar el éxito de iniciativas SOA/BPM.
Para mí una arquitectura de referencia para SOA pasa por el siguiente esquema:
Si logramos tener una suite de herramientas que nos permitan desarrollar los componentes de cada capa, y si esta suite es gratis como es el caso de WSO2, y contamos con una metodología de desarrollo ágil y fácil de adaptar, entonces ya estamos armados hasta los dientes para afrontar proyectos SOA/BPM.
Entradas
Hola Jorge, como estas?. Soy novato en arquitecturas SOA y he comenzado a investigar dado la inicitiva de un proyecto Integrador. Te consulto para saber si estoy bien enfocado hacia la plataforma WSO2 o simplemente estoy divagando con algo que es realmente complejo de implementar. He visto toda la gama de productos que provee WSO2 pero me resulta dificil visualizar el escenario. Por ejemplo como proyecto integrador los requisitos son el utilizar Liferay como portal de Sitios empresariales y como interface de usuario, a su vez a partir del carro de compras de Liferay poder tener acceso (via pago o free) a aplicaciones basadas en BPM que se ejecuten en otro servidor. El mecanismo sería similar al API Manager de WSO2 para administrar estas aplicaciones (con la idea de que se suban y publiquen estas aplicaciones como un marketplace). Cada uso de estas Aplicaciones serían instanciadas por cada usuario que la adquiera.
ResponderEliminarLa propuesta es la orquestacion de Sistemas y aplicaciones reutilizables (si es que esta bien dicho).
Es posible manejar esta estructura con WSO2 y lo mas importante es el como puede desplegarse esta integración.
Si no es lo que creo tengo en mente, no hay mas que quedarme con Liferay y administrar las aplicaciones en el shop otorgando accesos manualmente a las aplicaciones.
Desde ya muchas gracias por tu ayuda.
Saludos
Juan
Hola Andrés, bueno verte por acá.
ResponderEliminartu escenario lo entiendo y a la vez no, pero deja ver si de conjunto sacamos algo en limpio :-D
yo primero probaría solo con el liferay a ver que tal, si con un marketplace puedo gestionar todo lo que quieres...porque que las aplicaciones estén basadas en BPM o SOA no significa que se cambie la forma de comprarlas desde el liferay no?
Ahora bien si lo que se quiere es que esas aplicaciones que los usuarios pueden comprar se integren por debajo, y de forma transparente a los usuarios finales o sea compro una appA y una appB y ambas necesitan estar integradas ahí wso2 si tendría mucho sentido, aunque para el tema de BPM sugiero mejor usar Bonita, pues el BPS de WSO2 aun está un poco verde...aunque hace meses que no lo reviso. Claro esa integración tendría que ya estar hecha desde un inicio, o al menos estar establecida la capacidad de integrarse, de modo que si compro solo appA, esta no depende de appB, pero si también compro la appB tenga alguna forma de indicarle a la appA que se integre a la appB que acabo de comprar...
como vez son 2 cosas por separado si es que entendí bien...usar el liferay para gestionar las compras a través de sus funcionalidades del carrito de compra y un marketplace, y usar wso2 para promover la integración interna entre las aplicaciones que se vendan en el portal desarrollado con liferay....
espero no haberme ido demasiado de la idea que expusiste jejeje...si es así al menos espero sirva para dar pie a un mejor entendimiento del escenario.
saludos.
Hola Jorge, gracias por tu respuesta. Lo que indicas sería una opción, pero basicamente la idea es usar Liferay para adquirir aplicaciones desde su administrador de carro de compras integrando Liferay a WSO2 IS y manejar las aplicaciones en BPM como lo hace en el API Manager de WSO2. Donde estas aplicaciones en BPM se puedan instanciar y desplegar por cada usuario que las requiera. O sea, lo mismo que el comportamiento de WSO2 Api Manager pero para aplicaciones.
ResponderEliminarSupongo que WSO2 ESB debería administrar estas aplicaciones?
Me explico mas o menos el escenario?
Gracias por tu ayuda.
Juan
Hola Andrés. Ya pudieron integrar el Liferay y el IS de WSO2? Si no recuerdo mal WSO2 estuvo trabajando sobre ese tema, creo que hay una entrada sobre como integrar ambas herramientas sobre escribiendo la capa de seguridad del Liferay.
ResponderEliminarNo veo como el ESB de WSO2 pueda hacer eso que quieres, al menos nunca lo he visto en el escenario que planteas.
Hola Jorge, gracias por tu comentario. Para ir cerrando la idea, quizas no me he explicado del todo bien y he estado viendo los productos de WSO2.
ResponderEliminarWSO2 Stratos (http://wso2.com/cloud/stratos/) es la plataforma que permite crear Saas y Cloud?
Con esta herramienta puedo mediante multi-tenant, etc, etc permite administrar las distintas Aplicaciones Web, Sitios Web y Sistemas Empresariales como Saas?
Gracias y disculpame por mis consultas algo desinformadas. :-)
Saludos
Juan
Si no me equivoco el multi tenant es para las diferentes herramientas de WSO2 que vienen con el Stratos. No para que despliegues una herramienta tuya, una appweb, y puedas tener varios tenants de ella. Para eso tendrías que tener un tenant del AS y desplegar en ese tenant la appweb y así.
ResponderEliminarHola Jorge, buen dia. Te envíe un mensaje por g+ . Me gustaria hacerte unas consultas. Si estas interesado escribime y vemos si podemos coordinar. Muchas Gracias.
ResponderEliminarSaludos
Juan
Hola @Juan Andres.
ResponderEliminarme podrías escribir directamente a isildurmac at gmail dot com porque no he visto el mensje que me comentas. Saludos.