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

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

Con el tiempo, OSGi ha evolucionado más allá de un simple uso para redes domésticas (como fue concebido inicialmente) a un modelo de contenedor capaz de solucionar muchos de los problemas que existen actualmente en los servidores de aplicaciones (empaquetado, abstracción de los paquetes, carga dinámica de los mismos, dependencias, gestión del ciclo de vida, versionados, etc…).

En OSGi, un paquete o componente es poco más que un jar tradicional de Java, con sus interfaces, implementaciones y un fichero manifiesto. Dicho componente se podrá definir por cierta meta-información de su fichero manifiesto que especificará los servicios exportados y los permisos necesarios para poder ser reutilizados por otros componentes.
Además, OSGi nos permitirá la gestión del ciclo de vida del software (tales como instalación, parada, redespliegue, arranque o desinstalación de paquetes) chequeando las dependencias existentes para el paquete tratado y evitando conflictos de ejecución.
Nos permite también la gestión de versiones de los paquetes, permitiendo la coexistencia de distintas versiones según necesidades y dependencias establecidas.
Por último, OSGi nos permite un modelo de Programación Orientado a Servicios (aquí basa su modelo en SOA), ya que (al contrario de EJB o RMI que necesita definir interfaces remotas) los servicios son publicados y registrados en el contenedor automáticamente durante la carga de los mismos.

Actualmente, todos los que usamos el framework de Eclipse 3.0, estamos usando OSGi de manera indirecta (Eclipse lo adoptó y de hecho fue uno de los mayores propulsores de OSGi en su momento; ahora evolucionado al Proyecto Equinox).
Lo importante, es la adopción de este modelo como parte de las estrategias para los productos de diversos fabricantes (Apache Felix, Newton, BEA mSA, etc…) y principalmente en el lado del servidor (que es donde OSGi puede sacar su mayor potencial a relucir como parte de los servidores de aplicaciones).

Algunos hablan de OSGi como el próximo middleware universal, las posibilidades de descubrimiento y reutilización de servicios y las posibles alianzas entre OSGi y Spring (suma todas las características enunciadas sobre OSGi a la facilidad de uso de Spring a base de inyección de dependencias y la programación orientada a aspectos) o entre OSGi y SCA (en este sentido OASIS tiene pendiente la estandarización de SCA).

Links interesantes:

OSGi Alliance
An Introduction to OSGi on the Server Side
Interesante discusión sobre si OSGi es SOA
Power Combination: SCA, OSGi and Spring
On SOA, OSGi and More
Universal Middleware: What’s Happening With OSGi and Why You Should Care

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

Vamos a explicar un poco que es REST, como funciona y porqué podría convertirse en algo cotidiano (en un futuro no muy lejano) para los Arquitectos SOA si las previsiones son ciertas.

El término se originó en el año 2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno de los principales autores de la especificación del protocolo HTTP y ha pasado a ser ampliamente utilizado por la comunidad de desarrollo.

REST es, según algunos, la mejor manera de crear interfaces para servicios web que promulguen ante todo el débil acoplamiento (como una de las máximas y prioritarias definiciones de un servicio web).
REST depende directamente del protocolo HTTP (Hypertext Transfer Protocol) en un sentido de petición-respuesta (request-response) utilizando un conjunto
simple y pequeño de operaciones bien definidas: POST, GET, PUT y DELETE.
En REST, un recurso es expuesto a través de una URI (Uniform Resource Identifier); y la idea es que REST permita cambiar el estado de un recurso a través de una de las 4 operaciones antes descritas.

Es importante diferenciar REST de RPC (Remote Procedure Call); ya que éste último lo que hace es invocar un procedimiento en un sistema remoto.

Pongamos un ejemplo para verlo mejor:

1. REST nos permite llamar a un recurso "Libro" que puede tener expuesto cientos de URI’s. Por ejemplo, http://miweb/libro/ciencia-ficcion/viaje-a-la-luna se refiere a un registro o recurso concreto de Libro dentro de la categoría de ciencia ficción.
2. Para modificar la información en dicho registro, REST utiliza POST o PUT para enviar un XML en dicha URI y posteriormente conseguir la información a través de GET.

Lo primordial en este ejemplo, es darse cuenta de que lo importante es el "nombre", no el "verbo" (como es el caso de RPC o servicios web tradicionales). Si utilizaramos RPC, lo más parecido al ejemplo de REST, sería llamar a una función getLibro() al que se la pasaría un identificador de dicho libro. El hecho de utilizar REST simplifica mucho la forma de hacerlo.

Los servicios web no están focalizados en recursos, sino en operaciones. Podemos disponer de un servicio web con cientos de operaciones, cada una de las cuales especifica la manera en que se comportará ante una petición y como manejará el XML entrante para dar una respuesta concreta.

Es importante diferenciar un servicio web con multitud de operaciones (para borrado, modificación, petición, etc…) de multiples servicios web para implementar todas las operaciones posibles. Esta sería la diferencia más palpable entre estilo RPC y estilo documento (RPC-style vs. Document-style).
El caso de REST sería más próximo al estilo documento, ya que únicamente nos tenemos que encargar de enviar un XML a una URI definida para un conjunto mínimo de 4 operaciones. Aquí, la utilización de REST es mucho menos acoplada que la utilización de RPC, ya que se minimiza el impacto por cambios en la interfaz de datos intercambiados.

REST implica el cambio de estado de un recurso, pero sin definir la operación (son siempre 4 fijas). Pero lo que haga cada una de esas operaciones depende de la implementación final para cada recurso que se haga.

No obstante, REST no es la panacea: en ocasiones SOAP se antoja mejor que REST para dependiendo que implementación sea necesaria.

SOAP lleva siempre asociado la definición de servicio web. Y como tal, su definición a través de un WSDL.
REST por el contrario no ofrece esta posibilidad. REST es mucho más sencillo, es lo más optimo para simplificar una interfaz a utilizar por
consumidores externos (el ejemplo más claro lo tenemos con Google, que expone sus servicios web via REST y da como respuesta un xml con formato de
sindicación RSS o ATOM) o cachear resultados a nivel de recursos.
Pero si queremos implementar cosas más complejas necesitaremos SOAP: Por ejemplo, REST lleva asociado HTTP como único protocolo de transporte. Si tenemos necesidad de utilizar otro tipo de transporte como JMS, SOAP si es válido, pero no así el caso de REST.
Además, en niveles de seguridad, la pila WS-* (concretamente con su definición de WS-Security a nivel de mensaje) permite un mayor nivel de
securización que REST (que se implementa en caso de necesidad a nivel de HTTP como transporte).

REST, SOAP…. SOAP y REST. No creo que sean incompatibles ni que uno vaya a ser el ganador. Creo que ambos tienen su hueco y dependiendo de la necesidad será más recomendado utilizar uno u otro. Lo que si es claro, es que REST va a dar mucho que hablar de aquí a poco tiempo, de hecho se está utilizando ya ampliamente (la sindicación de blogs por RSS o ATOM utilizan REST; Google expone sus servicios web como REST, eBay y Amazon ofrece una interfaz REST para sus desarrolladores, etc…)

Links interesantes:

The benefits and limitations of REST
REST según Wikipedia
RestWiki
How I Explained REST to My Wife
Building Web Services the REST Way
REST for the Rest of Us
"Representational State Transfer (REST)" PhD dissertation by Roy T. Fielding