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.

¿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.

Y es en este punto cuando nos planteamos como realizar pruebas correctas de la arquitectura para comprobar que realmente estamos construyendo una arquitectura orientada a servicios y no una simple aplicación muy cara.

La verdad, cuando hablamos de testear una Arquitectura SOA, tenemos que plantearnos ciertas cuestiones y elegir las herramientas adecuadas; ya que difiere bastante de la forma tradicional de probar aplicaciones normales.

Es importante tener en mente la arquitectura, sus partes, sus dominios; e intentar dividir la misma en partes pequeñas que sean más faciles de probar; para posteriormente ir probando la integración de las mismas hasta llegar a un punto de arquitectura más o menos global.

Por ello, ante todo, tenemos que tener en mente unos objetivos a conseguir durante las pruebas de nuestra arquitectura:

1. Los servicios son y deben ser siempre reutilizables. Es una de las máximas de SOA y si no conseguimos eso, posiblemente la arquitectura estará abocada al fracaso.
2. Agilidad en los cambios: los procesos y la orquestación de servicios buscan la facilidad de composición de los mismos. Un cambio debería ser rápido y fácil de hacer si la capa base de servicios es la correcta y funciona correctamente.
3. Monitorización : ey! eso que llaman BAM. Es importante tener siempre visible nuestra arquitectura, en tiempo real; para detectar errores, cuellos de botella y otros factores que indiquen la necesidad de un cambio para la optimización de la misma.
4. Interoperabilidad : SOA habla de reutilización y como tal nuestra arquitectura al nivel más alto posible debería ser así. No solo se trata de que nuestros servicios sean reutilizables en referencia a nuestra arquitectura; sino que incluso lo sean de cara al exterior. Las posibilidades de reutilización entre empresas debe ser importante: por ello, cuanto más estándar, mejor que mejor.

Testear una arquitectura SOA pasa por tener en cuenta los dominios de la misma que debemos asegurar en fiabilidad y consistencia; esto es, que debemos probar:

1. Pruebas a nivel de servicio: Son la base de SOA y por tanto la base de toda la arquitectura. Probarlos a nivel de su funcionalidad es importante; pero más importante es probarlos asegurandonos su reutilización (incluso habrá ya servicios como composición de otros).
   Es importante, tener en cuenta que los servicios no son aplicaciones en sí mismas y por tanto deben ser probados atendiendo a ese factor (son independientes, aislados, sin estados, etc…). La mejor manera para probarlos es definir los casos de prueba de los servicios y ejecutarlos para comprobar su correcto funcionamiento.
   Además, hay que tener en cuenta que los servicios son autónomos (sin dependencias de otros servicios) y con una granularidad adecuada (no se trata de que sean ni muy atómicos ni muy complejos; las necesidades determinarán en cada caso como deben ser; pero es importante que tengan un sentido a nivel funcional para la empresa).
2. Pruebas a nivel de seguridad: intentar probar los servicios con una capa de seguridad añadida desde el principio puede ser más complejo de lo que parece. Es mejor probarlos de manera simple y aislados y luego probar la capa de seguridad que tenga nuestra arquitectura añadida a los servicios.
3. Pruebas de orquestación: como estamos hablando de composición; en algún momento tendremos orquestación de servicios y este dominio debería ser probado a partir de unos servicios fiables y seguros. En este momento estaremos hablando de pruebas que determinan la correcta comunicación entre servicios; el trabajo de manera conjunta.
   Estaremos hablando también de procesos de negocio (pruebas a nivel BPM) por lo que debemos verlo como una capa superior a probar.
4. Pruebas de gobernabilidad: la gobernabilidad de SOA es algo muy importante y en buena medida puede ser determinante para la consecución satisfactoria de nuestra arquitectura. Es importante probar las políticas de las distintas capas que se hayan definido, los ciclos de vida y cualquier concepto de gobernabilidad que se haya introducido y deba ser probado.
5. Pruebas de integración: bueno, más o menos tenemos todo probado; solo quedaría verlo en producción sin ningún error.
   Antes de eso es importante hacer pruebas de integración de nuestra arquitectura. El objetivo de estas pruebas es principalmente, determinar el correcto funcionamiento de las interfaces de comunicación de los distintos componentes.

Aunque no lo parezca, probar una arquitectura SOA definiendo diversos niveles y dominios de aplicación es realmente importante; ya que sino podemos encontrarnos con desagradables sorpresas.

Por ello, es recomendable que esta fase de pruebas (el Plan de Pruebas) este siempre presente en la planificación de cualquier arquitectura de este tipo.

Articulos Interesantes:

What is SOA test?
SOA Testing
SOA World – Approaching SOA Testing
Ready to Test SOA, Web Services, ESBs and BI?

SaaS tiene sus origenes en ASP (Application Service Provider), cuya misión era almacenar paquetes de software de manera centralizada que luego se instalaban en diversos clientes (los cuales pagaban por ello a distintos niveles: departamental, unipersonal, etc…). La idea, era que la tediosa tarea de mantener actualizados los paquetes de software y en perfecto funcionamiento recayera en gente propietaria del ASP y no en los distintos clientes que pudieran utilizarlo.

Quizá por evolución, quizá por los inconvenientes de esta soluciones (imagina actualizar software por medio de una red con velocidades de hace 15 años: podría llegar a ser una tarea insufrible), surgió SaaS como una nueva manera suministrar aplicaciones a los distintos clientes.
La principal diferencia de SaaS con respecto a ASP radica en que en el caso de SaaS el acceso es por medio de un navegador de internet (son clientes ligeros), tanto en el uso de los paquetes como la administración de los mismos. Además, el concepto de SaaS se basa en los Servicios Web y la solución de API por medio de WSDL’s para su reutilización.

Después de esta pequeña introducción, está claro porque SaaS es realmente un gran amigo de SOA. Aquí, entran en uso nuevamente conceptos como SOA Global: imaginemos cientos y miles de servicios web con distintas funcionalidades que se expongan siempre bajo un mismo formato (WSDL) y se permita su reutilización sin importar donde estén o quien los gobierne.

Otro concepto bastante usado en los mismos terminos que SaaS y SOA juntos, sería el de Composición de Aplicaciones o también llamados Mashups: ahora se han puesto de moda, servicios como Dapper, Kapow o Yahoo Pipes; que nos permiten juntar en cuestión de minutos y en un mismo contexto fuentes de información totalmente diversas y de distintos tipos. Todo ello, nuevamente, gracias al uso de estándares e interfaces de uso común.

Es decir, tenemos SaaS como una forma de proveer servicios web; tenemos mashups como una forma de componerlos en aplicaciones compuestas; la pregunta es: ¿y donde cae SOA en este saco?

Yo creo que la respuesta es bastante fácil: tradicionalmente se ha pensado en SOA como una forma de crear arquitecturas en un entorno empresarial para organizaciones de diversas indoles. Pero creo, que hay que ir un paso más alla, y es precisamente ahí donde las grandes empresas pueden ofrecer servicios de cara al exterior como una nueva fuente de ingresos. Los servicios web de la SOA Global, una SOA no empresarial, sino de Internet; donde poco importe la empresa que los suministre sino la posibilidad de tenerlos accesibles a cualquier nivel y cualquier propósito.
Imagina que la omnipotente Telefónica expusiera servicios para uso público que permitieran consultar el saldo de una persona o alguna forma de enviar sms con cargo al usuario. O que alguno de los grandes bancos españoles expusiera servicios para consulta de cuentas bancarias.
Vale, se que en algunos casos más de uno me diría que eso no son servicios que un banco o una empresa de telecomunicaciones debería dejar usar de cualquier manera, ya que las implicaciones de seguridad que tienen son enormes.
Pero la realidad es que la tecnología está ahí, y realmente es algo factible y que permitiría la creación de aplicaciones de cualquier tipo y totalmente orientadas al usuario final.

Creo que a medida que SOA se vaya introduciendo más y más en las empresas, se empezará a dar soluciones orientadas al publico general (ya no vale solo un megaportal empresarial para los usuarios de la empresa, hay que expandirse más alla, dar la posibilidad a terceros de usar la tecnología existente para construir nuevas aplicaciones). ¿Por qué no utilizar todos los medios disponibles a nuestro alcance para ofrecer servicios mucho más abiertos y con muchas más posibilidades?

En los últimos meses, en el proyecto personal en que ando metido me he dado cuenta de que las empresas son muy reticentes a dejarte usar sus servicios y sus sistemas. Vaya, encima de que estoy dándoles un nuevo canal de ingresos, ponen pegas. Sí, vale, yo también lo hago por el interés, pero, ¿no repercute de manera beneficiosa para ambos?. Yo creo firmemente que es así y por ello voy a seguir evolucionando mi idea en ese sentido…

Links interesantes:

Is Web 2.0 The Global SOA?
Soa4All
SaaS, Composite Applications, and SOA: Understanding their Differences and Making Them Work Together

Este año, me han invitado a participar como miembro del comité cientifico-técnico, lo cual es un honor y espero estar a la altura (gracias a Jose Carlos del Arco, el gran precursor de estas Jornadas por su trabajo y dedicación a algo que ya es una referencia en el mundo SOA y de los Servicios Web en España).

Los temas principales de interés de las jornadas este año son (entre otros):

1. Fundamentos de los servicios Web y SOA
2. Tecnología y servicios Web
3. Ingeniería de servicios Web
4. Aplicaciones de los servicios Web y SOA

Desde aquí mi apoyo y promoción de este evento para que cada año pueda mejorar en todos los sentidos y ser el mejor punto de encuentro principalmente entre empresas y universidades en lo que a Servicios Web y SOA se refiere.

(Más información en la página oficial del evento)

Orquestación (Web Service Orchestration) y Coreografía (Web Services Choreography) se suelen ver como dos aproximaciones para la Composición de Servicios Web, pero tienen matices (la principal diferencia entre orquestación y coreografía es el alcance):

Si buscaramos la definición de Orquestación y Coreografía en un diccionario obtendríamos algo tal que así:

• La Orquestación es el estudio y práctica de ordenar la música para una orquesta. Es decir, consiste en decidir que instrumentos deben tocar qué notas en una pieza de música.
• La Coreografía es la ordenación y movimiento de los bailarines en el escenario. Es decir, consiste en decidir como debe ser el movimiento de los bailarines en el escenario al ritmo de la música.

Después de estas "definiciones" podríamos hablar de similitudes entre orquestación y música; al igual que de coreografía y danza (o bailarines). El problema es que esto no termina de dejar claro las similitudes y diferencias entre Orquestación y Coreografía aplicadas a los Servicios Web.

Cuando hablamos de Orquestación, debemos hablar de WS-BPEL y por tanto de procesos ejecutables. Es decir, la Orquestación podría verse como la ejecución de un proceso de negocio definido en WS-BPEL y que puede ser ejecutado por un motor BPEL.
Cuando hablamos de Coreografía, debemos hablar de WS-CDL (Web Services Choreography Description Language) y por tanto de colaboración entre actores; es decir, de interacciones entre servicios web.
Hay que verlo desde una perspectiva distinta, WS-BPEL (Orquestación) es un mecanismo para el intercambio de mensajes desde una visión más detallada a través de un proceso (un flujo de control). Y WS-CDL (Coreografía) es una visión más abstracta y descriptiva de los actores que intercambian mensajes para ejecutar varios proceso particulares (varios flujos de control).

WS-CDL tiene como propósito definir la interoperabilidad necesaria para crear un sistema compuesto por servicios web. La Coreografía nos permite especificar las reglas de unión y trabajo colaborativo (entendiendo por colaboración, una función/es de negocio surgidas de la interacción cooperativa de múltiples actores. Es lo que normalmente se entiende por un proceso de negocio global donde se modela el estado de negocio (por ejemplo, BPSS – Business Process Specification Schema)) de diversos servicios web.
Por el contrario, WS-BPEL se centra en la composición de nuevos servicios a partir de otros ya existentes. BPEL nos proporciona una manera de describir el comportamiento interno de qué necesitan los servicios para trabajar conjuntamente y así poder crear otro servicio como composición de los primeros.

No se si queda claro o simplemente genera más confusión. ¿Que opinais al respecto?

Links interesantes:

Web Services Orchestration Using BPEL
Service Orchestration vs. Service Choreography by John Reynolds
What is… choreography? What is… orchestration? on Digital Walkabout
OASIS Web Services Business Process Execution Language (WSBPEL)
WS-Choreography Definition Language (WS-CDL)

Ando metido en un proyecto personal de estos que llaman ahora "Web 2.0" y en una primera instancia el uso que voy a dar al bus de servicios es para integrar numerosos servicios web.
Mis necesidades iniciales son transformación de datos y conversión de protocolos (a futuro posiblemente necesite orquestar servicios, por lo que bpel como lenguaje será perfecto ya que JBI puede incluir un componente específico para ello). Y todo esto para cientos de servicios web a integrar… creo que un ESB llena a la perfección mis requisitos.

Siempre he tenido que trabajar con ESB’s comerciales y nunca me había puesto a mirar detenidamente las diferencias entre los Open Source del mercado. El caso es que me propuse realizar una pequeña prueba para ver cual escogía (partiendo de dos esquemas XSD de datos y un XSLT de tranformación, utilizar un componente JBI de conversión de datos para hacerlo funcionar).

Creo que me voy a quedar con Open ESB. Me ha parecido el más rápido e intuitivo de instalar/configurar/implementar (partiendo de cero) para una pequeña prueba de transformación de datos con XSLT. Y además, me apetece probar GlassFish y NetBeans (vienen en el mismo paquete). Acostumbrado a los JBoss/Weblogic y a Eclipse quiero probar la "gran alternativa" de la cual he leido muy buenas críticas.

¿Habéis trabajado vosotros con alguno de estos ESB? ¿Qué os han parecido? Cualquier ayuda/consejo será agradecida

La especificación BPEL4People fue creada para modelar a gente dentro de la definición de procesos BPEL. Específicamente, podrá visualizarse una actividad denominada "Actividad de Persona"; igual que una estándar de invocación de servicio web; pero con un contexto adicional asociado.

Por su parte, WS-HumanTask suministra el API y el motor de ejecución para BPEL4People. Se encargará de definir cómo debe ser la tarea, la manera de crearla y de dar un conjunto de API’s para su interacción.

El estándar BPEL no incluye definiciones para incorporar tareas humanas. No obstante, todos los proveedores de herramientas BPM que soportan BPEL; incorporan desarrollos propios que soportan las interacciones humanas (normalmente como "worklists" que permiten reclamar, reasignar o ejecutar tareas por medio de personas). El problema es que dichos desarrollos son propietarios y en ningún caso estandarizados; por lo que aparece un problema de portabilidad entre fabricantes; dificilmente salvable sin una estandarización como la que

BPEL4People propone un patrón de interacción de 5 tareas de proceso distintas:

En el primer patrón, la tarea se especifica dentro de la actividad humana. En el segundo, se especifica dentro del Proceso BPEL, por lo que puede ser reutilizada por numerosas actividades dentro de dicho proceso.
En el tercer patrón, la tarea es externa al proceso BPEL, por lo que puede ser llamada por varios procesos. Este modelo permite que una tarea pueda ser llamada por varios motores de procesos, incluso de diversos fabricantes (por lo que se da solución al problema de la portabilidad).
El patrón cuatro, es como el tercero, salvo porque la exposición de la tarea se define a través de un interfaz WSDL (de esta manera, implementaciones tales como la transaccionalidad, requerirán de implementaciones estandarizadas como WS-Transaction; mientras que en el anterior patrón, dichas características quedan a merced de la implementación que haga cada propietario).
Por último, el patrón quinto, es como el cuarto, salvo porque la tarea es llamada desde una Actividad de Invocación estándar, en lugar de una actividad humana

Links interesantes:

WS-BPEL Extension for People
Proyecto BPEL4People en SourceForge.net

En este caso, se trata de un curso de Servicios Web y Programación SOA con un temario más que interesante y enfatizando en 4 areas:

• New Java APIs for Web Services (JAX-WS, JAXB 2.x, REST)
• WSIT (Project Tango)
• SOA Technologies (BPEL, JBI, Open ESB)
• GlassFish (Java EE 5, JBI runtime, Service Engines, etc.)

El curso comienza el próximo 24 de Agosto; y a todos los que se inscriban y realicen el trabajo asignado se les entregará un diploma.

Tienes toda la información al respecto del curso en Javapassion.com

Además, si quiereis ver más pósters parecidos, podeis hacerlo en ITPoster.net, donde además de estos dos ya vistos aquí, tienen otros sobre temas como UML, ITIL, POEM, etc..