Se me ocurren multitud de aplicaciones a coste 0 inicial:

• Portales : Liferay, Jakarta Pluto, OpenPortal, JBoss Portal …
• Brokers / ESB : ServiceMix, MULE ESB, openESB …
• Procesos de Negocio / BPM : jBPM, Intalio, Bonita Workflow …
• Servidores de Aplicaciones : Jboss, Glassfish …
• Frameworks para Servicios Web : Metro, Axis …
• Entornos de desarrollo : Eclipse, Netbeans …
• Testeadores de XML, Servicios Web, etc… : soapUI, PushToTest, HtmlUnit …
• Gobernabilidad : CentraSite, WSO2 …

Y muchas más, que posiblemente podrían constituir soluciones realmente complejas para cualquier tipo de empresa.

En este punto y viendo como las empresas se gastan miles de euros en soluciones de pago de diversos fabricantes; ¿no estaría mejor invertir ese dinero en desarrolladores, arquitectos… sus propios empleados al fin y al cabo, para que luego sus desarrollos fueran lo mejor posibles?

Ver como después de comprar las suites más caras del mercado, se realizan auténticas barbaridades en los desarrollos (por desconocimiento de las mismas o simplemente por no dedicarles el tiempo necesario) le deja a uno perplejo.

No estoy diciendo que una empresa deba estructurar su IT, en su totalidad a partir de Open Source. Quizá, para la parte más importante de su negocio, fabricantes de pago sea la mejor alternativa (al final, si pagas por un producto; en cierto modo, te aseguras que funciona… sino, el fabricante tendrá que responder ante él). Pero estoy seguro que en muchas ocasiones se desperdicia dinero en comprar herramientas que no se utilizan adecuadamente o que directamente se piensan que van a resolver los problemas por sí solas (cuando en realidad el saber utilizarlas adecuadamente tiene más importancia).

Es verdad que algunas empresas ya se están dando cuenta de ésto y cada vez más apuestan por herramientas de código libre. Incluso las administraciones públicas lo promueven en la teoría (aunque a veces la realidad sea muy distinta). Pero todavía queda mucho camino por recorrer…

En fin, habrá que esperar…

SOA está basado en estándares. Un ESB soporta estándares basados en la integración de sistemas distribuidos. Un ESB debe ser más distribuido que un broker EAI que centraliza la integración de distintos sistemas utilizando adaptadores propietarios y flujos de mensajes. Además, un ESB debe ser un intermediario de servicios que posibilita un conjunto de patrones tales como enrutado de mensajes y transformaciones de esquemas.

Los EAI suelen tener una arquitectura hub-and-spoke. Los ESB (salvo los que han evolucionado como tal a partir de un EAI) buscan un modelo federado donde multiples nodos tienen el conocimiento sobre como enrutar y transformar los mensajes.

¿Qué os parece? ¿Estais de acuerdo?

Según cuenta, lo principal es mantener una taxonomía simple basada en 4 tipos de servicios básicos que solo debería extenderse según las necesidades de cada empresa y siempre de una manera muy justificada y como medio para asegurar el entendimiento de todas las partes (negocio, técnicos, etc…).

Los tipos básicos son:

Servicios de Negocio : Servicios core de la empresa y del negocio, identificados por usuarios normalmente no técnicos y que cuando se coreografían representan casos de uso o escenarios de usuario. Se implementan con un lenguaje de definición de contrato (WSDL normalmente) y se nombran por alguno de los típicos verbos CRUD (Create, Read, Update y Delete). Un ejemplo sería, “recuperarCliente”.

Servicios de Empresa : Son servicios que implementan servicios de negocio (relaciones 1 a N o N a N). Identificados normalmente por Arquitectos IT son producto de orquestación de servicios. Además, para la transformación de los modelos de datos entre los servicios de empresa y los de negocio, se utilizan transformadores (como XSLT) normalmente en un bus de servicios. Un ejemplo sería “calcularCreditoBancario”.

Servicios de Aplicación : Servicios dentro del contexto de las aplicaciones (y que por tanto no se comparten al mismo nivel que los servicios de empresa o de negocio), que representan funciones específicas como validaciones o transferencias de datos. Son identificados por los desarrolladores de las aplicaciones. Un ejemplo sería “añadirDireccion”.

Servicios de Infraestructura : Servicios que dan soporte a nivel de toda la empresa, tales como logging, auditoría, seguridad… Normalmente son identificados por los desarrolladores de las aplicaciones o equipos de soporte a infraestructuras. Un ejemplo sería “escribeLog”.

Podeis leer todo el artículo aquí.

http://www.soasocial.com/

A la hora de diseñar servicios web que luego sirvan como base para crear orquestación de los mismos (y así generar valor añadido a las empresas con los procesos de negocio), para que sean fácilmente reorganizados o reorquestados según surjan las necesidades (en este punto, es donde SOA muestra su potencial); es necesario que tengan una base de datos totalmente orientados a negocio. Así, cuando hablemos de datos a este nivel, deberíamos hablar de conceptos totalmente relacionados con el negocio de la empresa, a un nivel lógico y funcional (tipos de datos como “cliente”, “contrato” o “servicio”).

La abstracción con una capa de datos permite ocultar la complejidad de los mismos, permitiendo una estructura totalmente organizada a nivel del middleware. El resultado de esto, es que una aplicación o servicio puede pedir datos a nivel lógico y de una manera totalmente organizada sin preocuparse por la capa más física.

Normalmente esta capa de datos, se construye con XML, pues es un estándar muy fácil de utilizar y que permite generar datos complejos (a la granularidad deseada) independientes de la capa física.
Para ello, se utilizan esquemas de datos XML (conocido como XSD).
Existen ya estructuras de datos XML a nivel de negocio totalmente “estandarizadas” por distintas empresas (ejemplos como ACORD para seguros, HR-XML para Recursos Humanos, etc…), aunque la definición de una estructura totalmente orientada al negocio de una empresa por la gente que tiene el conocimiento de la misma suele ser la mejor opción (a partir de una estructura de datos particular, si fuera necesario, siempre existen maneras de transformar los datos a otras estructuras sean más “estándar de facto” o no que la propia de cada uno).

Por esto generalmente la creación de una capa de datos en la creación de una Arquitectura SOA es un beneficio a la misma, ya que en caso de ser necesario reordenar los datos a nivel físico (cosas como por ejemplo, la restructuración de una base de datos) no debería afectarle a nivel lógico y por tanto tampoco a las aplicaciones y servicios construidos por encima.

Este último año ha sido muy intenso; he dedicado muchas horas a un nuevo proyecto, www.travenjoy.com; un nuevo buscador de viajes, que lanzamos hace unas semanas.

Y después de todo este año de trabajo y de mucho tiempo queriendo hacer este viaje; efectivamente, me voy a Japón!!!. Y para relatar mis andanzas por el país nipón, he creado un blog específico donde ir contando todo lo que me pase.

Pasate por

japon.travenjoy.com

y podrás ver fotos, videos y todo tipo de relatos del país del sol naciente.

Su nombre : “An Implementor’s Guide to Service Oriented Architecture - Getting It Right”, el cual está escrito por todo un elenco de expertos sobre SOA y pertenecientes a algunas de las empresas más influyentes del sector (Progress, AmberPoint, comité OASIS, etc…)

Cubre varios temas, incluyendo disertaciones sobre registros y repositorios, gestión del runtime y como hacer funcionar todo para el éxito de una Arquitectura SOA.

Sin duda, merece la pena echarle un vistazo.

Además, por parte de Oracle se continuará dando soporte a los productos de BEA que estén adquiridos, sin obligación de migración de los mismos por parte de los clientes.

Lo primero que resulta de esta fusión, es el Oracle Technology Network, resultado de las comunidades online de Bea (Dev2Dev) y de Oracle (Oracle Java Developer Community).

A nivel de productos, Oracle va a buscar completar una suite lo más extensa y perfecta posible en lugar de una estrategia de productos separados.

1. A nivel de SOA, según el Roadmap del producto, se distinguen 3 categorías:
   • Productos estratégicos : Productos de Bea que serán integrados directamente en Oracle Fusion Middleware, en un periodo máximo de 12-18 meses. Aquí se incluyen :
     • Oracle Data Integrator para integración de datos y ETL batch.
     • Oracle Service Bus, que unifica AquaLogic Service Bus y Oracle Enterprise Service Bus.
     • Oracle BPEL Process Manager para orquestación de servicios e infraestructura de composición de aplicaciones.
     • Oracle Complex Event Processor para procesamiento de eventos en memoria, integrado con WebLogic Event Server
     • Oracle Business Activity Monitoring (BAM) para monitorización de eventos de negocio y KPIs de procesos.
   • Productos a continuar y converger : Productos de Bea que serán rediseñados e incrementados para integrar con la suite de Oracle en un desarrollo continuo y mantenimiento por al menos 9 años. Aquí se incluyen :
     • BEA Weblogic Integration que convergerá en Oracle BPEL Process Manager
   • Productos a mantener : Productos de Bea que se continuarán manteniendo por un periodo de 5 años pero que no se busca integrar en la suite de Fusion. Aquí se incluyen :
     • BEA Cyclone
     • BEA RFID Server
2. A nivel de BPM, se intentará dar soporte tanto a BPEL para la ejecución, como BPMN para el modelado. Según Oracle hay 4 tipos de procesos de negocio : centrados en sistema, en tareas humanas, en documentos y en decisiones. Este punto es muy importante, ya que en el caso del BPM la estrategia a seguir en cuanto a la gama de productos de ambas plataformas, será la siguiente:
   • Productos estratégicos :
     • Oracle BPA Designer para modelado y simulación de procesos
     • BEA AL-BPM Designer para modelado iterativo de procesos
     • Oracle BPM, que convergerá como resultado de BEA AquaLogic BPM y Oracle BPEL Process Manager en un único motor de ejecución
     • Oracle Document Capture & Imaging para captura de documentos y workflows documentales con integración ERP
     • Oracle Business Rules como motor de reglas de negocio.
     • Oracle Business Activity Monitoring (como BAM)
     • Oracle WebCenter como interfaz de portal para visualizar la composición de procesos.
3. A nivel de Portales y Enterprise 2.0 tenemos por parte de Bea los productos de Aqualogic UI y Weblogic Portal. La convergencia en este caso será la siguiente:
   • Productos estratégicos :
     • Oracle Universal Content Management como repositorio de gestión de contenidos, seguridad, publicación, imagenes, registros y archivo.
     • Oracle WebCenter Framework para desarrollo de portal y servicios Enterprise 2.0
     • Oracle WebCenter Spaces & Suite como entorno de portal empaquetado con servicios de computación social.
     • BEA Ensemble para ensamblado de portales ligeros basados en REST.
     • BEA Pathways para analisis de interacciones sociales.
   • Productos a continuar y converger :
     • BEA WebLogic Portal que será integrado en el Framework WebCenter.
     • BEA AquaLogic User Interaction (AL-UI) que será integrado en el WebCenter Spaces & Suite
   • Productos a mantener :
     • BEA Commerce Services
     • BEA Collabra
4. A nivel de Gobernabilidad SOA la estrategia de conversión será la siguiente:
   • Productos estratégicos :
     • BEA AquaLogic Enterprise Repository para capturar, compartir y gestionar el cambio de elementos SOA a través de su ciclo de vida.
     • Oracle Service Registry para el UDDI
     • Oracle Web Services Manager para seguridad y gestión de políticas QOS en servicios.
     • EM Service Level Management Pack como consola de gestión para los niveles de tiempo de respuesta de los servicios y la disponibilidad de los mismos.
     • EM SOA Management Pack como consola de gestión para monitorización, traceo y gestión del cambio SOA.
   • Productos a mantener :
     • BEA AquaLogic Services Manager

Podeis oir el webcast del evento en inglés, directamente en la página de Oracle, obtener más información de los productos en la página de Fusion Middleware o simplemente esperar al 8 de Julio, que será cuando se anuncie el roadmap aquí en España.

Fuentes :

BPMS Watch
Column 2 by Sandy Kemsley
BEA Welcome and Oracle’s Middleware Strategy Briefing

El primero fue Mindreef, fabricante de herramientas que facilitan la creación de Arquitectura Orientadas a Servicios. Su producto estrella, SOAPscope facilita enormemente las pruebas y la gestión de los servicios web de una arquitectura SOA; tanto para analistas, arquitectos, desarrolladores y cualquier usuario implicado.

El segundo fue IONA Technologies, adquirido por 162 millones de dólares, y que con productos como FUSE, ORBIX o ARTIX ayudarán a completar la gama y el listado de soluciones ofrecidas por Progress (que recordemos ya tiene productos como Sonic ESB, Actional o Apama, su BAM estrella)

Está claro que tras adquisiciones como Bea por parte de Oracle, quedaban algunos movimientos pendientes de los grandes del sector, en un intento de ofrecer soluciones end-to-end lo más completas posibles.

Habra que ver ahora como se produce la integración de todas estas adquisiciones : si se plantean como soluciones independientes sin estrategia común o se plantea una estrategia central sobre la que articular todos los productos.

Durante los últimos meses, he estado inmerso con bastantes fuerzas en un proyecto personal que nace hoy para todo el público : TravEnjoy, un buscador de vuelos (y muy pronto lo será también de hoteles, coches…).

La principal característica de TravEnjoy, a nivel técnico, es que se ha diseñado desde su principio pensando en Servicios Web y en la posible evolución que pueda tener en un ambiente totalmente orientado a servicios.

Así, disponemos de una base de servicios web que nos permiten la integración con los distintos proveedores finales (aerolíneas, agencias de viajes online, etc…) y la unificación de todos ellos a un modelo de datos común para el proyecto (basado en el estándar OTA XML).

Hemos dejado sentada la base para la integración a través de un bus de servicios (concretamente con Open ESB) que nos permitirá realizar transformaciones de modelos o enrutamientos a distintos entornos según nuestras necesidades.

Para la interfaz final, nos apoyamos claramente en el framework Ajax, de Dojo Toolkit, que nos da unas capacidades de interacción y usabilidad increibles.

Todo el desarrollo se ha realizado en J2EE, con herramientas Open Source y con Glassfish como servidor de ejecución.

Puedes ir directamente a la web y empezar a probarlo:

www.travenjoy.com