Arquitectura Orientada a Servicios (SOA)

Aviso Importante

2007-06-22T18:24:00.000+02:00

Hola a todos.

Por problemas familiares hacía mucho tiempo que no publicaba en el blog. Ahora parece que se han solucionado, y por tanto aprovecho este post para comunicaros que próximamente seguiré publicando, y resolviendo cualquier duda que me queráis plantear.

Muchas gracias a todos y un saludo

Artículo Tecnológico: "WSDL: El contrato de un Servicio"

2006-12-12T08:39:00.000+01:00

Ahí va una pequeña historia.

"Pablo es un desarrollador que está realizando un portal corporativo para una empresa farmacéutica. Una de las funcionalidades del portal es incluir un buscador de internet. Como Pablo es muy listo, sabe que el mejor buscador que existe es Google, y por tanto decide navegar por la web para ver si encuentra alguna información sobre el algoritmo de búsqueda que utiliza este famoso buscador.

Después de interminables horas de búsqueda, descubre que Google ofrece su buscador en forma de Servicio Web. En ese momento Pablo piensa... ¿Por qué construir algo que ya existe, es bueno, y puedo utlizarlo aunque mi portal esté desarrollado en Java?

Por lo tanto Pablo decide utilizar el Servicio Web de Google. Pero ¿Cómo utilizarlo? ¿Qué datos debe enviar? ¿Qué datos va a recibir? ¿Cuales son las funcionalidades que ofrece el Servicio de Google?

Toda esta información que necesita Pablo debería estar en algún lugar, ya que es imprescindible para acceder al Servicio."

Desde el punto de vista de los negocios, todas las respuestas a las preguntas de Pablo definen el contrato entre el cliente (el que usa el Servicio) y el proveedor (quien lo implementa), ya que indica las pautas a seguir por cada una de las partes.

Pues bien, WSDL (Web Service Description Language) es el lenguaje estándar definido por el W3C para describir un Servicio Web y crear ese contrato. No es un documento obligatorio, pero es muy importante que sea estándar ya que así se podrá acceder de manera dinámica a los Servicios.

Es muy importante entender WSDL porque es la parte fundamental para desarrollar Servicios. No es necesario saber construir un documento WSDL (ya que lo construyen automáticamente las herramientas de desarrollo), pero sí entenderlo. Este es el objetivo de este artículo.

La versión actual de WSDL es la 2.0, pero en este artículo se describirá la 1.1, ya que no todos los servidores soportan la última versión.

WSDL es un lenguaje basado en XML creado para definir el interfaz de los servicios. Un documento WSDL está divido en dos partes claramente diferenciadas:

Parte concreta: Es la parte que define el "como" y "donde".
Parte abstracta: Es la parte que define qué hace el servicio a través de los mensajes que envía y recibe.

El esquema simplificado de un documento WSDL es el siguiente:

A continuación se detalla brevemente cada una de las partes que componen un documento WSDL. En la parte abstracta tenemos:

types: Esta etiqueta define las estructuras de datos que se utilizarán para construir los mensajes de petición como de respuesta. Estas estructuras de datos pueden construirse con cualquier lenguaje, pero lo más normal es hacerlo con XML Schema. Este apartado es el más complicado sobre todo cuando tengamos que construir estructuras de datos muy complejas.
message: Describe los mensajes que se van a intercambiar entre el cliente y el Servicio Web. Un mensaje puede estar dividido en varias partes, por ejemplo, si en un mensaje queremos enviar datos y una imagen.
portType: Define el conjunto de operaciones que soporta el Servicio Web. Una operación no es más que un grupo de mensajes que serán intercambiados. Cada operación puede enviar o recibir al menos un mensaje cada vez.

En WSDL 1.1 existen 4 tipos de operaciones:

+ Unidireccional: El Servicio recibe un mensaje y no genera ninguna respuesta.

+ Petición / Respuesta: El Servicio recibe un mensaje y responde con otro.

+ Solicitud / Respuesta: El Servicio envía un mensaje y recibe una respuesta.

+ Notificación: El Servicio envía un mensaje, y no recibe respuesta.

Aunque WSDL 1.1 define los 4 tipos de operaciones, sólo soporta las 2 primeras.

En la parte concreta tenemos:

binding: Describe como formatear los mensajes para interactuar con un Servicio determinado. WSDL no define un estándar para formatear mensajes. Para ello utilizar la extensibilidad para definir como intercambiar los mensajes usando SOAP, HTTP, MIME, etc...
services: Este elemento indica donde se encuentra el Servicio usando la etiqueta . Cada etiqueta define el formato de los mensajes, y la dirección donde se encuentra el servicio que acepta mensajes en ese formato.

Como conclusión, el interfaz de un Servicio es el componente fundamental ya que define lo que ofrece el Servicio. Es muy importante dedicarle todo el tiempo necesario, ya que cualquier modificación provocará cambios en el resto de nuestras aplicaciones.

Artículo Tecnológico: "El IDE ha muerto, viva el ISE"

2006-08-29T18:09:00.000+02:00

IDE son las siglas de Integrated Development Environment, es decir entorno de desarrollo integrado. Estamos hartos de oir esta palabra, y de asociarla a la típica herramienta de desarrollo como el famoso Websphere Studio Application Developer. Pero, ¿Estas herramientas son capaces de soportar el desarrollo de aplicaciones SOA? Rotundamente no.

Para que una herramienta sea capaz de soportar el desarrollo de aplicaciones SOA, es necesario que cumpla con una serie de características principales:

Ofrecer la posibilidad de desarrollar código en un lenguaje determinado.
Ofrecer todas las capacidades necesarias para construir servicios.
Ofrecer la capacidad necesaria para diseñar procesos de negocio.

Actualmente los IDE sólo ofrecen la primera característica y un sucedaneo de la segunda. Por esta razón, las grandes empresas que ofrecen herramientas, han tomado la decisión de evolucionar las herramientas de desarrollo que ofrecen, y crear así los ISE (Integrated Service Environment). Un ISE no es más que un IDE, pero con las funcionalidades necesarias para permitir diseñar y desarrollar servicios (sobre todo servicios web) y procesos de negocio. Por lo tanto, si estás pensando desarrollar una aplicación SOA, te recomiendo que sigas leyendo este artículo.

En este artículo no se pretende indicar cual es la mejor herramienta, si no proporcionar un rango de herramientas disponibles para que así podais seleccionar la que mejor se adapte a vuestras necesidades. La primera toma de decisión será si deseamos una herramienta de pago o bien una herramienta de software libre.

En cuanto a software libre, la herramienta por excelencia es Eclipse. Como muchos sabreis esta herramienta permite el desarrollo de aplicaciones Java, con lo cual para que soporte servicios es necesario añadir algún plug-in. En este sentido hay dos posibilidades:

Utilizar un plug-in de pago. El más utilizado es MyEclipse IDE.
Utilizar un plug-in libre. Se puede utilizar las web tools de eclipse group, pero son menos potentes que las anteriores.

La otra posibilidad al software libre son las herramientas de pago. las tres herramientas de pago más utilizadas son las siguientes:

WebSphere Studio Application Developer Integration Edition: Es la herramienta de IBM y como su nombre indica es una evolución del famoso WebSphere Studio Application Developer. Es muy importante reseñar aquí que IBM ha decidido cambiar el nombre a su herramienta de desarrollo, y por tanto el WSADIE se llama ahora Rational Application Developer for WebSphere Software o RAD. Esta herramienta tiene las siguientes características:

Editores visuales basados en Eclipse.
Soporte para el diseño y desarrollo de servicios web (Compatible con WS-I).
Diseñador de WorkFlows compatible con WS-BPEL.
Posee un depurador de procesos.

La característica de esta herramienta es que todas sus funcionalidades están integradas en el mismo entorno, lo que es bastante útil al no tener que instalar otras aplicaciones extra.

WebLogic Integration: Herramienta de desarrollo de Bea. Sus características son:

Editores visuales propios.
Soporte para servicios web.
Diseñador de workFlow propietario aunque en breve será compatible con WS-BPEL.

Esta herramienta también es muy utilizada. Posee la misma característica que RAD, es decir, tiene absolutamente todo integrado en la misma herramienta. Para mí el gran defecto de esta herramienta es que abusa del uso de asistentes, haciendo que la persona que utiliza la herramienta a veces no se entere de lo que está haciendo.

Oracle SOA Tools: Conjunto de herramientas para el desarrollo SOA de Oracle. Posee las siguientes características:

Editores visuales (incluidos en la herramienta JDeveloper).
Soporte para el diseño y desarrollo de servicios web (incluido en la herramienta JDveloper), además posee compatibilidad WS-I.
Herramienta para diseñar WorkFlows compatible con WS-BPEL.
Posee un potente monitor de procesos de negocio.

El inconveniente de Oracle SOA Tools es que todas las funcionalidades no están incluidas en una sola herramienta, si no que son un conjunto de herramientas. Eso sí, Oracle SOA Tools es la más potente.

Como conclusión a este artículo, indicar que si estáis probando herramientas, no desestimeis las de pago, porque tanto IBM como Bea como Oracle ofrecen versiones de prueba completas en su web (en la sección "Enlaces de Herramientas" teneis los links para descargarlas). Aprovechaos porque es muy interesante probarlas todas y construid vuestras aplicaciones SOA.

Aviso Importante

2006-08-22T12:59:00.000+02:00

Hola a todos. Quiero informaros que a partir de ahora, los artículos del blog serán de tres tipos:

Artículos metodológicos: Son aquellos referentes a metodología de desarrollo de aplicaciones SOA. Los artículos recogerán las diferentes fases y entregables de una aplicación SOA mediante un ejemplo.
Artículos tecnológicos: Son los artículos que tratarán sobre todas las tecnologías existentes alrededor de los Servicios Web. Se hará todo mediante casos prácticos, y se implementará el ejemplo utilizado en los artículos metodológicos.
Referencias a otra documentación: Son artículos donde se comentará y proporcionará documentación extra para que la podais consultar.

Saludos

Modelado de servicios

2006-08-18T12:36:00.000+02:00

Después de todos los artículos del blog, una cosa ha quedado clara: "una aplicación SOA está formada por un conjunto de servicios interconectados cuyo objetivo es automatizar uno o varios procesos de negocio".

Por tanto, a la hora de construir una aplicación SOA, el elemento sobre el que debemos enfocar nuestros esfuerzos es el concepto de servicio. En este punto surgen una serie de preguntas:

¿Cómo puedo saber cuántos servicios se deben crear?
¿Qué tipos de servicios existen?

La primera pregunta es demasiado compleja para contestarla en un solo artículo. Por tanto, me centraré en la última.

¿Qué tipos de servicios existen?. Esta pregunta se la hace todo desarrollador a la hora de enfrentarse a una aplicación SOA. Existen varias clasificaciones dependiendo de su autor. A mí me gusta la más simple, porque a la vez me parece la más práctica para tener una visión general de una aplicación SOA.

Existen básicamente tres tipos de servicios, dividos en base a sus funcionalidades:

Servicios controladores: Son los encargados de recibir las peticiones de los clientes y realizar las llamadas necesarias a otros servicios (en la secuencia adecuada) para devolver una respuesta. Es decir, son los servicios encargados de coordinar al resto de servicios. Si analizamos bien este tipo de servicios, nos daremos cuenta de que representan a los procesos de negocio que queremos implementar, ya que un proceso de negocio no es más que un conjunto de tareas ejecutadas en una determinada secuencia para obtener un objetivo.
Servicios de negocio: Son los servicios que representan una tarea de negocio, y que forman parte de un proceso de negocio. Este tipo de servicios suelen ser poco reutilizables porque están orientados a resolver una tarea muy puntual.
Servicios de utilidad: Son aquellos servicios que se caracterizan por representar una tarea altamente reutilizable. Existen dos tipos, los servicios orientados al negocio que representan una tarea de negocio altamente reutilizable entre aplicaciones y los servicios tecnológicos encargados de encapsular una determinada tecnología y por tanto altamente reutilizables (ej: servicio de acceso a bases de datos relacionales).

con lo cual, una aplicación SOA la podemos dividir en tres capas. La capa de recepción de peticiones (servicios controladores), la capa de tareas (servicios de negocio) la capa de lógica reutilizables (servicios de utilidad).

Principios de la orientación a servicios

2006-06-22T16:04:00.000+02:00

Un problema con el que nos podemos encontrar a la hora de construir una aplicación SOA es si la aplicación construida realmente es una aplicación "SOA Compliant". Para comprobar si una aplicación lo es, la mejor forma de hacerlo es chequeando que la aplicación cumpla con los Principios de la Orientación a Servicios.

No existe una definición estándar de cuales son los Principios de la Orientación a Servicios, por lo tanto, lo único que se puede proporcionar es un conjunto de Principios que estén muy asociados con la Orientación a Servicios. Estos Principios según Thomas Erl son:

Los Servicios deben ser reusables: Todo servicio debe ser diseñado y construido pensando en su reutilización dentro de la misma aplicación, dentro del dominio de aplicaciones de la empresa o incluso dentro del dominio público para su uso masivo.

Los Servicios deben proporcionar un contrato formal: Todo servicio desarrollado, debe proporcionar un contrato en el cual figuren: el nombre del servicio, su forma de acceso, las funcionales que ofrece, los datos de entrada de cada una de las funcionalidades y los datos de salida. De esta manera, todo consumidor del servicio, accederá a este mediante el contrato, logrando así la indepencia entre el consumidor y la implementación del propio servicio. En el caso de los Servicios Web, esto se logrará medienta la definición de interfaces con WSDL.
Los Servicios deben tener bajo acoplamiento: Es decir, que los servicios tienen que ser independientes los unos de los otros. Para lograr ese bajo acoplamiento, lo que se hará es que cada vez que se vaya a ejecutar un servicio, se accederá a él a través del contrato, logrando así la independencia entre el servicio que se va a ejecutar y el que lo llama. Si conseguimos este bajo acoplamiento, entonces los servicios podrán ser totalmente reutilizables.
Los Servicios deben permitir la composición: Todo servicio debe ser construido de tal manera que pueda ser utilizado para construir servicios genéricos de más alto nivel, el cual estará compuesto de servicios de más bajo nivel. En el caso de los Servicios Web, esto se logrará mediante el uso de los protocolos para orquestación(WS-BPEL) y coreografía (WS-CDL).
Los Servicios deben de ser autónomos: Todo Servicio debe tener su propio entorno de ejecución. De esta manera el servicio es totalmente independiente y nos podemos asegurar que así podrá ser reutilizable desde el punto de vista de la plataforma de ejecución.
Los Servicios no deben tener estado: Un servicio no debe guardar ningún tipo de información. Esto es así porque una aplicación está formada por un conjunto de servicios, lo que implica que si un servicio almacena algún tipo de información, se pueden producir problemas de inconsistencia de datos. La solución, es que un servicio sólo contenga lógica, y que toda información esté almacenada en algún sistema de información sea del tipo que sea.
Los Servicios deben poder ser descubiertos: Todo servicio debe poder ser descubierto de alguna forma para que pueda ser utilizado, consiguiendo así evitar la creación accidental de servicios que proporcionen las mismas funcionalidades. En el caso de los Servicios Web, el descubrimiento se logrará publicando los interfaces de los servicios en registros UDDI.

Cuando se desarrollan aplicaciones SOA es muy útil y necesario tener en cuenta siempre estos principios, ya que nos van a dar las pautas necesarias para tomar ciertas decisiones de diseño complejas.

Como se habrá podido observar, una característica muy importante de los Principios de la Orientación a Servicios, es que todos ellos se inter-relacionan. El siguiente gráfico muestra la inter-relación de los diferentes principios:

Como se puede observar en el gráfico, el objetivo de la Orientación a Servicios es obtener software totalmente reutilizable a través de un conjunto de técnicas y principios como los descritos anteriormente.

SOA y los Servicios Web (II)

2006-06-09T12:46:00.000+02:00

Este artículo se centra en el segundo tipo de Arquitecturas Orientadas a Servicios, que yo he denominado SOA de segunda generación.

Es el tipo utilizado actualmente, porque está basado en el SOA tradicional, añadiendo lo necesario para cubrir sus carencias. Es decir, proporciona los elementos necesarios para cumplir con todos los principios de la orientación a objetos.

El esquema básico de una SOA de segunda generación es el mostrado en el siguiente gráfico:

Como se puede observar, una SOA de segunda generación está formada por un conjunto de Funciones y por la Calidad del Servicio.

La Funciones están formadas por:

Transporte: Mecanismo utilizado para trasladar las peticiones desde el cliente, hasta el proveedor del servicio, y viceversa.
Protocolo de comunicación: Es el sistema de comunicación entre el cliente y el proveedor de servicios.
Descripción del servicio: Es un esquema utilizado para describir qué servicio es, como se le puede invocar, y cuales son los datos necesarios para realizar su invocación.
Servicio: Es la implementación del servicio.
Proceso de negocio: Es una colección de servicios, invocados en una determinada secuencia, con un conjunto particular de reglas para satisfaces un requisito de negocio.
Registro de servicios: Es un repositorio de servicios y datos, usado por los proveedores de servicio y publicar los servicios, y para los clientes, donde buscarlos.

La calidad del servicio por:

Política: Son un conjunto de reglas bajo las cuales, un proveedor de servicio hace que el servicio esté disponible para los clientes (WS-Policy).
Seguridad: Son un conjunto de reglas que podrían ser aplicadas en la identificación, autorización y control de acceso a los servicios, por parte del cliente (WS-Security).
Transacción: Conjunto de atributos que podrían ser aplicados sobre un grupo de servicios para devolver un conjunto de datos consistentes (WS-Transaction, WS-Coordination).
Gestión: Conjunto de atributos que podrían ser aplicados para gestionar los servicios proporcionados (WS-Manageability).

Es decir, las SOA de segunda generación se basan en ampliar su funcionalidad mediante el uso de los estándares WS, que proporcionan funcionalidades como gestión de transacciones, seguridad, etc..

SOA y los Servicios Web (I)

2006-06-06T14:51:00.000+02:00

En la actualidad el concepto de SOA ha resurgido, gracias al auge y madurez de una nueva tecnología: los Servicios Web.

Los Servicios Web se han convertido en el estandarte de SOA, ya que esta tecnología posee un conjunto de características que permiten cubrir todos los principios de la orientación a servicios, no como otras posibles tecnologías de implementación como colas de mensajes o CORBA.

Centrándonos en los Servicios Web, podemos decir que con ellos se pueden generar dos tipos de Arquitecturas Orientadas a Servicios:

Arquitectura Orientada a Servicios Tradicional.
Arquitectura Orientada a Servicios de segunda generación.

En el presente artículo describiré la primera de ellas.

La SOA Tradicional es aquella que utiliza los principios y tecnologías básicos de los Servicios Web. Esto significa utilizar SOAP como lenguaje de intercambio, WSDL como lenguaje para la descripción de los servicios y UDDI para la publicación o registro de los mismos. En el dibujo que se muestra a continuación, se puede ver la estructura básica de funcionamiento de una SOA tradicional.

En el gráfico anterior, se puede observar la existencia de tres roles claramente diferenciados:

Cliente del servicio: Es el que solicita la ejecución del servicio web, y por lo tanto el que lo consume.
Proveedor del servicio: Es el encargado de implementar el servicio web y ofrecerlo a los clientes.
Registro del servicio: Es un repositorio donde se almacenan las descripciones de los servicios, para que así los clientes puedan buscar el servicio web que mejor se adapte a sus necesidades.

La secuencia de ejecución es la siguiente:

1. El proveedor del servicio da de alta el servicio web en el registro. Para realizar esto, el proveedor almacena en el registro el documento de descripción de este.

2. El solicitante del servicio busca en el registro un servicio web que pueda adaptarse a sus necesidades.

3. Una vez seleccionado el servicio, el solicitante lo invoca mediante el envío de un mensaje SOAP, en el cual se indica la acción a realizar y los datos de entrada.

4. El servicio web recibe la petición y ejecuta la funcionalidad. Para finalizar envía un mensaje SOAP al solicitante con los resultados obtenidos.

Por lo tanto, una SOA tradicional estará compuesta por un conjunto de servicios que reciben y envían mensajes SOAP en base a una descripción WSDL. Este tipo de arquitecturas hoy en día es muy utilizado, pero no es el más óptimo debido a que no porpociona una serie de características esenciales a la hora de crear una Arquitectura profesional. Estas características son:

Seguridad
Transaccionabilidad
Garantía de entrega
Orquestación
Coreografía
Direccionamiento
etc...

Estas características las ofrecen las SOA de segunda generación, que serán el tema central de otro artículo.

Elementos esenciales de una Arquitectura Orientada a Servicios

2006-05-09T12:32:00.000+02:00

En las Arquitecturas Orientadas a Servicios, el elemento básico es el servicio. Pero únicamente con este concepto, no podríamos diseñar una arquitectura SOA.

Cuatro son los elementos esenciales necesarios para la construcción de una Arquitectura Orientada a Servicios:

Operación: Es la unidad de trabajo o procesamiento en una arquitectura SOA.
Servicio: Es un contenedor de lógica. Estará compuesto por un conjunto de operaciones, las cuales las ofrecerá a sus usuarios.
Mensaje: Para poder ejecutar una determinada operación, es necesario un conjunto de datos de entrada. A su vez, una vez ejecutada la operación, esta devolverá un resultado. Los mensajes son los encargados de encapsular esos datos de entrada y de salida.
Proceso de negocio: Son un conjunto de operaciones ejecutadas en una determinada secuencia (intercambiando mensajes entre ellas) con el objetivo de realizar una determinada tarea.

Por lo tanto, una aplicación SOA estará formada por un conjunto de procesos de negocio. A su vez esos procesos de negocio estarán compuestos por aquellos que servicios que proporcionan las operaciones que se necesitan ejecutar para que el proceso de negocio llegue a buen término. Por último para ejecutar esas operaciones es necesario el envío de los datos necesarios mediante los correspondientes mensajes.

12 pasos para migrar a un entorno SOA

2006-05-02T00:07:00.000+02:00

En la gran mayoría de los casos, el desarrollo de una Arquitectura Orientada a Servicios, suele ser la solución adoptada a la horas de migrar aplicaciones antiguas a nuevos entornos.

Esto se debe a que una arquitectura SOA, aporta ventajas como escalabilidad, flexibilidad, reutilización, etc... (ya sabeis que opino yo de esto. Es verdad siempre y cuando se haya destinado un gran esfuerzo [tiempo+ dinero] a desarrollar esa arquitectura SOA).

Para realizar una migración, es necesario diseñar un plan de ejecución. Pues bien, David S. Linthicum, gurú en el campo de SOA, ha definido en este documento los 12 pasos que deberían seguirse para realizar una migración con plenas garantías de éxito.

Es un documento muy recomendable, puesto que nos puede proporcionar una visión global de la complejidad a la hora de migrar a SOA. Ahora bien, no penseis que el documento va a solucionar vuestros problemas y dudas trascendentales, puesto que en él se indican cuales son los pasos en un plan de migración, pero no se centra en las técnicas y herramientas para acometer ese plan.

¿Quién define las pautas de SOA?

2006-04-08T20:18:00.000+02:00

Mucha gente se pregunta qué organismo es el encargado de estandarizar o por lo menos gestionar SOA. La respuesta es muy sencilla puesto que no hay ningún organismo que pueda hacerlo, ya que SOA es un concepto abstracto, el cual se rige única y exclusivamente por los principios de la Orientación a Servicios.

Pero entonces, ¿No hay manera de controlar la evolución de SOA? ?Cada fabricante podrá hacer lo que quiera?. Estas preguntas tienen una respuesta sencilla. Para comenzar, es necesario dejar un aspecto muy claro. Los Servicios Web, CORBA, MQSERIES, etc... son posibles tecnologías que se pueden utilizar a la hora de implementar una Arquitectura Orientada a Servicios y estas tecnologías si que están estandarizadas y gestionadas por diversas organizaciones. Por lo tanto, las organizaciones que dirigen el rumbo de SOA, son aquellas que estandarizan las diferentes tecnologías utilizadas para implementar una Arquitectura Orientada a Servicios.

Como ejemplo, voy a poner el caso de los Servicios Web. Realmente los Servicios Web están formados por diferentes tecnologías, y por ello son varias las organizaciones que participan en su gestión. Concretamente son tres las organizaciones involucradas:

World Wide Web Consortium: Organismo muy conocido porque es el encargado de la estandarización de HTML y XML ( y tecnologías relacionadas). Referente a los Servicios Web, es el encargado de gestionar el protocolo de comunicación de los Servicios Web (SOAP), y el lenguaje de descripción de interfaces (WSDL). Más recientemente, W3C también se ha dedicado a estandarizar algunas de las extensiones WS-* de los Servicios Web. Concretamente se encarga de WS-CDL (Web Services Choreography Description Language) y de WS-Addresing.

El W3C se caracteriza por ser muy formales y rigurosos a la hora de definir y gestionar tecnologías y protocolos, ofreciendo siempre las mejores garantías.

OASIS: Anteriormente conocida como SGML Open, cambió su nombre para redirigir sus acciones de SGML hacia XML. Esta organización es bastante conocida por gestionar dos tecnologías muy conocidas. Es el encargado de desarrollar el estándar UDDI para el registro de Servicios Web, y también se encarga de gestionar la especificación ebXML es cual es un estandar para el intercambio de datos entre aplicaciones B2B. Actualmente también se encarga de desarrollar extensiones WS-* para los Servicios Web. Estas extensiones son WS-BPEL creada para la orquestación de Servicios Web y WS-Security para todos los aspectos relacionados con la seguridad.

Web Services Interoperability: Este organismo es reciente (apareció en 2002), y su principal objetivo es asegurar que se utilizan los estándares adecuados y no definirlos ni desarrollarlos. Por ello, este organismo ha definido un documento llamado perfíl básico (Basic Profile), en el cual se indican cuales son los estándares que se deberían utilizar para diseñar arquitecturas interoperables. Es decir, este documento es utilizado como mecanismo para generar arquitecturas SOA "compliant". Actualmente también se han preocupado por un aspecto tan importante como la seguridad, y han publicado un perfíl de seguridad básico (Security Basic Profile) cuya finalidad es la misma que el anterior perfíl, pero relacionado con la seguridad. Además esta organización ha prometido seguir publicando perfiles para distintos aspectos relevantes de las arquitecturas.

Como resumen, indicar que es necesario tener en cuenta las directrices y evolución de estas tres organizaciones a la hora de diseñar Arquitecturas Orientadas a Servicios mediante Servicios Web.

pero, ¿Qué es realmente SOA?

2006-03-29T17:17:00.000+02:00

"SOA son las siglas de Arquitectura Orientada a Servicios..." Muchos libros comienzan con la frase anterior, y para mí es un error tremendo. En la actualidad, el mundo de las Tecnologías de la Información se ha convertido en un gran monstruo que mueve millones de euros. Este monstruo para sobrevivir y evolucionar tiene que utilizar técnicas publicitarias para introducir nuevas tecnologías que van a revolucionar la industria, pero que al final se quedan en meras anécdotas tecnológicas que no aportan nada especial ni revolucionario.

Mucha gente piensa que SOA va por este camino, y que únicamente es un conjunto de siglas creadas por la industria, no existiendo nada por detrás. Este pensamiento lo ha creado sobre todo esos movimientos publicitarios de marketing y la explotación comercial por parte de las empresas del concepto de SOA.

Siento decepcionar a algunos excépticos, pero SOA sí significa algo y es lo que pretendo demostrar con este pequeño artículo. Para comenzar a explicar el término SOA, lo primero no es indicar lo que significan las siglas (para mí lo menos importante), si no determinar lo que SOA no es, para así desasociar esta palabra con conceptos totalmente erroneos. A continuación relato afirmaciones erroneas acerca de SOA:

"SOA es un término publicitario": Esta afirmación en parte es cierta debido a que muchas empresas están utilizando este concepto como mera publicidad de sus actividades. Pero hay que tener clara una cosa, y es que la Orientación a Servicios no es un concepto abstracto y sin sustancia. La Orientación a Servicios define un paradigma de desarrollo de aplicaciones basado en una serie de principios como la reutilización, abstracción, independencia tecnológica, etc...
"SOA es el nuevo nombre de los Servicios Web": Esto es rotundamente falso. La Orientación a Servicios existe desde hace aproximadamente 15 años (en esa época ni se pensaba en los Servicios Web) y por supuesto se puede implementar con distintas tecnologías como Colas de Mensajes y CORBA. Actualmente debido a la aparición de los Servicios Web, la Orientación a Servicios ha resurgido, ya que la mejor implementación de los principios de Orientación a Servicios es mediante los Servicios Web, y sobre todo a partir de la aparición de las extensiones de estos (WS-*).
"Con SOA el desarrollo de aplicaciones es rápido y flexible": Es una afirmación cierta si a continuación añadiéramos un "pero". Ese pero es que esa rapidez y flexibilidad no es instantánea. Es necesario un proceso lento en el que la empresa que aplique SOA sea capaz de asimilar los nuevos comportamientos que implica el utilizar un nuevo paradigma para el desarrollo de aplicaciones. Es decir, que SOA aporta muchas ventajas, pero a su vez aplicar todos los principios de la Orientación a Servicios es complejo y se necesita tiempo y expertos en el tema.

Con esta reflexión paso a definir según mi criterio qué es una Arquitectura Orientada a Servicios. Para mí SOA son un conjunto de servicios tanto de negocio como tecnológicos que interactuando entre ellos, proporcionan la lógica necesaria para construir aplicaciones de una manera rápida y cumpliendo siempre con los principios de la Orientación a Servicios (los cuales definiremos en otro artículo). Además SOA proporciona una serie de guías y recomendaciones para conseguir los objetivos que se impone una organización a la hora de desarrollar aplicaciones.