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…

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.

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

¿Realmente creeis que tiene sentido acuñar un nuevo término para algo como ésto?

Veamos un poco de que se trata:

Según los expertos en materia, "WOA es un estilo arquitectural, subconjunto de SOA, basado en la WWW con requisitos adicionales: links globales, descentralizado y procesador del estado de las aplicaciones a través de mensajes autodescriptivos".
Incluso, se refieren a WOA como "un conjunto de protocolos Web como HTTP y XML para suministrar una aproximación a los servicios web más simple y escalable".
Dion Hinchcliffe, va más alla, al hablar de WOA como "un uso de servicios via REST".

¿Pero tiene sentido hablar de otro nuevo término? Yo creo que no; se puede hablar de WOA (si realmente la "moda" quiere ponerle un nuevo término) pero creo que no pasa de ser una especialización de SOA (y por tanto parte de él).

Creo que al hablar de teorias es más importante el sentido general de los conceptos, aunque en la práctica es más poderosa la especialización.

De hecho, si te pasas al plano práctico y piensas en la implantación de SOA en una empresa, verás que las complicaciones pueden ser miles.
En cambio, si implementas un "WOA" puede ser más fácil conseguir una aproximación a la misma (hoy en día los conceptos de Web 2.0 están de moda y todos quieren tener algo de eso en su empresa) y a partir de ahí tener la semilla sobre la que germine una Arquitectura SOA a un nivel más global y teórico.

Según la descripción del propio documento, pretende ser abstracta en naturaleza, describiendo una posible plantilla o modelo sobre la cual construir una arquitectura concreta de SOA desde tres puntos de vista:

1. El Negocio a través de los Servicios : como conducir el negocio al contexto de SOA.
2. La Realización de los Servicios : los requisitos para construir una arquitectura SOA.
3. El Propietario de la Arquitectura SOA : la Gobernabilidad y Gestión de los sistemas implicados en la arquitectura.

Será interesante su lectura…

Más información en la página oficial del Comité Oasis

2 días de presentaciones, demos y paneles de expertos donde se volvieron a reunir la mayoría de los fabricantes de productos SOA/BPM y diversas empresas de servicios implantadores de estas tecnologías.

Faltaron algunos de los grandes como Bea Systems o Software AG, aunque se pudo extraer de los asistentes un poco la evolución de los productos, novedades y, para mi lo más interesante, los casos de exito de diversas empresas ya "expertas" en implantación de tecnologías SOA/BPM.

Además, se entregaron los primeros premios SOA Awards que se llevó Vitria casi por duplicado (M30 como "mejor herramienta de integración" y el proyecto "SERVEI DE TELECOMUNICACIONS D´ANDORRA" como "mejor implementación SOA", con productos Vitria nuevamente).

Lo que si denoté en cierta medida y comentándolo con gente que también asistió al evento, es la reincidencia una vez más en cuestiones bastantes elementales como "qué es SOA y qué no es SOA". Fue algo que se pudo ver como parte de algunas presentaciones de manera repetitiva y que a estas alturas provoca hasta cansancio.

Creo que la empresa española (representada por la mayoría de los asistentes al evento) sabe de sobra qué es SOA; es algo que se les ha metido por activa y pasiva los últimos años en numerosas conferencias, eventos y demás presentaciones de mano de la jungla de proveedores del mercado.

Señores, implementemos SOA!! dejémonos de contar qué es y qué no es; creo que a estas alturas la mayoría de la gente ya tiene una idea bastante clara.
Creo que es el momento de dar el paso y comenzar proyectos con estas tecnologías. Incluso para proyectos ya existentes y "veteranos de SOA", habría que ir un poco más allá y empezar a implementar cosas como Gobernabilidad, BAM o Virtualización…

En fin, veremos a ver… ]]> http://www.espaciosoa.net/2008/04/30/soa-forum-2008/feed/ 0 http://www.espaciosoa.net/2008/04/17/gobernabilidad-como-solucion-a-los-errores-en-soa/ http://www.espaciosoa.net/2008/04/17/gobernabilidad-como-solucion-a-los-errores-en-soa/#comments Thu, 17 Apr 2008 14:32:08 +0000 Kike http://www.espaciosoa.net/2008/04/17/gobernabilidad-como-solucion-a-los-errores-en-soa/ En otra ocasión ya hablé de Gobernabilidad en Arquitecturas SOA y de la importancia de su adopción casi desde el inicio del proyecto; como un método muy recomendado (y casi necesario) para la consecución satisfactoria del mismo.

Normalmente, muchos de los errores más comunes en proyectos SOA, tienen como solución la aplicación de una buena ejecución de gobernabilidad en la arquitectura:

• Centralización de la información de los servicios: A medida que nuestra arquitectura crece y crece, el número de servicios puede llegar a ser inmanejable. Es frustrante que una de las máximas en SOA sea la reutilización de los servicios que se van desarrollando; y una y otra vez vemos como se rehacen y duplican los mismos desarrollos por equipos y departamentos distintos que no tienen conocimiento del total de los servicios existentes en la empresa y por tanto de las funcionalidades disponibles.

  La solución a este problema pasa por la utilización de un registro y repositorio de servicios; tan importante como necesario para centralizar toda la información existente. Así, gracias a ello, podremos rápidamente ver toda la colección de servicios que nos son accesibles, cual es su funcionalidad, como se pueden utilizar, etc…

• Buenas prácticas de diseño: A menudo se crean servicios y más servicios; y uno de los principales problemas que nos encontramos es que en el momento en que se diseñaron no se pensaron para ser reutilizados más allá del ambito para el que fueron creados. Eso a menudo provoca que la reutilización sea bastante compleja o que haya que rediseñarlos o modificarlos para hacerlos más reutilizables.

  El problema de la remodelación de servicios radica principalmente en que suele venir acompañado de un impacto a los clientes del mismo que ya los estén utilizando y por tanto la modificación de estos (como si de una cadena se tratara). Por ello; es importante aplicar buenas prácticas de reutilización a la hora de construir servicios de tal manera que sean totalmente susceptibles de ser utilizados por cualquier cliente potencial.
  Además; es sumamente importante que los desarrollos estén probados correctamente a todos los niveles (funcionalidad, seguridad, etc..) y que cumplan políticas de interoperabilidad (WS-I) para la aceptación de los mismos en el sistema de gobernabilidad de la arquitectura.

• Explotación correcta de los servicios: Cuando los servicios llegan a sistemas de producción; a menudo no hay un control exhausto o correcto que indique el uso de los mismos.
  Es importante la utilización de herramientas de monitorización que nos permitan tener controlados en todo momento los servicios que están siendo utilizados; asi como los clientes que están teniendo, etc… a fin de poder dimensionarlos correctamente y permitir que puedan ejecutarse sin provocar cuellos de botella.
• Despliegues controlados / mantenimientos de versiones: El número creciente de versiones, dependencias, etc… hace que a veces halla problemas a la hora de desplegar y redesplegar nuevos desarrollos o correcciones de los ya existentes.
  Por ello, es importante controlar las versiones y las dependencias que se van creando; para que si algo sale mal, cuestiones tan importantes como un rollback de la instalación, sea rápido, fácil y sencillo. Iniciativas como OSGi posiblemente serán muy importantes en el futuro ya que solucionarán bastantes de estos problemas.

La gobernabilidad en SOA es muy importante. Preguntas como

• ¿Qué ocurre si se cambia un servicio?
• ¿Cómo se puede asegurar la calidad de un servicio?
• ¿Cómo podemos asegurar que un servicio (nuevo o existente) cumple con las políticas de calidad y de seguridad establecidas por la empresa?
• ¿Cómo podemos asegurar el rendimiento y los SLA de los servicios?

deben ser cotestadas con un Plan de Gobernabilidad SOA.