Sod arquitecturas basadas en servicios

Arquitectura Orientada a Servicios
[Pick the date]
Sistemas Operativos Destribuidos
Arquitectura
Orientada a
Servicios
Trabajo Practico – UNLAM - 2012

1Introducción
1
ÍNDICE
Introducción.................................................................................................................................................2
Qué es SOA? ..............................................................................................................................................3
Conceptos Relevantes ................................................................................................................................4
Servicio....................................................................................................................................................4
Interfaz definida o Contrato de Servicio ..................................................................................................4
Entreprise Service Bus............................................................................................................................5
WEB Services .............................................................................................................................................6
XML, base de los Web Services..............................................................................................................8
Estándar SOAP .....................................................................................................................................10
Estándar WSDL.....................................................................................................................................12
Estándar UDDI ......................................................................................................................................14
Seguridad con Web Services....................................................................................................................17
WS-Security (WSS)...................................................................................................................................19
Transacciones con Web Services.............................................................................................................20
WS-Coordination ...................................................................................................................................21
WS-Transaction.....................................................................................................................................23
Bibliografía ................................................................................................................................................24

2Introducción
2
INTRODUCCIÓN
Las empresas necesitan poder interconectar los procesos, personas e información tanto con la propia
organización como -atravesando sus fronteras- con subsidiarias y socios comerciales. La falta de
integración entre los componentes de IT –sistemas, aplicaciones y datos- hace difícil obtener una
respuesta rápida y efectiva ante los cambios que afectan de forma natural a los negocios. La
inflexibilidad genera costes, reduce la capacidad de respuesta ante los clientes, compromete el
cumplimiento con las normativas legales, y afecta negativamente a la productividad de los empleados.
En suma, una deficiente integración es uno de los problemas más importantes a los que la
organizaciones deben hacer frente para mantener su competitividad y garantizar su crecimiento.
La Arquitectura Orientada a Servicios (SOA, ServiceOrientedArchitecture) supone una estrategia
general de organización de los elementos de IT, de forma que una colección abigarrada de sistemas
distribuidos y aplicaciones complejas se pueda transformar en una red de recursos integrados,
simplificada y sumamente flexible. Un proyecto SOA bien ejecutado permite alinear los recursos de IT
de forma más directa con los objetivos de negocio, ganando así un mayor grado de integración con
clientes y proveedores, proporcionando una inteligencia de negocio más precisa y más accesible con la
cual se podrán adoptar mejores decisiones, y ayuda a las empresas a optimizar sus procesos internos y
sus flujos de información para mejorar la productividad individual. El resultado neto es un aumento muy
notable de la agilidad de la organización.

3Qué es SOA?
3
QUÉ ES SOA?
La Arquitectura SOA establece un marco de diseño para la integración de aplicaciones independientes
de manera que desde la red pueda accederse a sus funcionalidades, las cuales se ofrecen como
servicios. La forma más habitual de implementarla es mediante Servicios Web, una tecnología basada
en estándares e independiente de la plataforma, con la que SOA puede descomponer aplicaciones
monolíticas en un conjunto de servicios e implementar esta funcionalidad en forma modular.
¿Qué es un servicio exactamente? Un servicio es una funcionalidad concreta que puede ser descubierta
en la red y que describe tanto lo que puede hacer como el modo de interactuar con ella.
Desde la perspectiva de la empresa, un servicio realiza una tarea concreta: puede corresponder a un
proceso de negocio tan sencillo como introducir o extraer un dato como “Código del Cliente”.
Pero también los servicios pueden acoplarse dentro de una aplicación completa que proporcione
servicios de alto nivel, con un grado de complejidad muy superior –por ejemplo, “introducir datos de un
pedido”-, un proceso que, desde que comienza hasta que termina, puede involucrar varias aplicaciones
de negocio.

4Conceptos Relevantes
4
CONCEPTOS RELEVANTES
SERVICIO
Un servicio en SOA es una función de aplicación empaquetadacomo un componente reutilizable para
ser usado en unproceso de negocio.
El servicio proporciona información o facilita el cambio dedatos de negocio de un estado válido y
consistente a otro.
La implementación concreta de un servicio SOA no esimportante. A través de protocolos de
comunicación biendefinidos, los servicios pueden ser invocados de manera quese hace hincapié en la
interoperabilidad y en la transparenciade localización.
Los elementos que se componen un servicio son:
Interfaz: contrato entre proveedor y consumidor. Define la forma y el procedimiento para
acceder a su funcionalidad
Lógica de negocio: implementación propiamente dicha
Canal de comunicación: el medio físico y el conjunto de procedimientos parar poner en contacto
(típicamente de forma remota) a los consumidores del servicio con su proveedor
INTERFAZDEFINIDAOCONTRATODESERVICIO
Forma parte de la esencia misma de un servicio. Para que se considere un servicio, su interfaz de
entrada/salida (su contrato con el cliente) tiene que estar explícitamente declarado. Los campos que
forman parte de este interfaz deben estar correctamente tipados y ser conocidos. Con la ayuda de los
estándares como WSDL y XSD, el contrato del servicio está auto descrito.
Por consiguiente, los servicios web con un campo de entrada y otro de salida, en el que se inserta a su
vez un XML como contenido (que no está descrito en ninguna parte) no puede considerarse un servicio
web, a pesar de que parece que son los que más abundan.
Las aplicaciones SOA publican sus servicios y no saben quien los va a usar ni donde, estandofuera del
control de la aplicación. Publican un contrato (interface) que se mantendrá constante a lo largo del ciclo
de vida del servicio. El ciclo de vida de un servicio diferencia entre los servicios en producción y en
desarrollo, para los servicios en producción nunca se modificará su interface sino que en su lugar el
servicio se marcará como en desuso y se notificará a sus consumidores que hay una nueva versión del
servicio disponible que deberán usar.

5Conceptos Relevantes
5
Es fundamental la separación entre la interface y la implementación. El usuario de un servicio sólo
necesita (y debe) conocer la interface. La implementación puede cambiar a lo largo del tiempo sin que
para ello deba afectar a sus consumidores.
ENTREPRISESERVICE BUS
Otro concepto muy asociado a SOA y que también conviene aclarar es el de ESB (Enterprise Service
Bus). A diferencia de SOA, ESB sí es una tecnología o producto software. Puede definirse un ESB como
la Infraestructura que sirve como el backbone de las Arquitecturas Orientadas a Servicios (SOA). Un
ESB permite a una empresa, conectar,mediar, y controlar la interacción entre diversas aplicaciones y
servicios a lo largo de entornosaltamente distribuidos yheterogéneos.
SOA de por sí puede aportar una gran potencia y flexibilidad a una organización sin necesidad de utilizar
un ESB, pero sin un ESB es muy complicada la gestión y mantenimiento de los procesos SOA y el
escalado de la arquitectura en caso de ser necesario. Normalmente un ESB debe proporcionar a una
organización por un lado un sistema de mensajería robusto de alta disponibilidad y altamente escalable
que permita garantizar la comunicación entre los distintos servicios y aplicaciones de la organización
independientemente de su localización geográfica, y por otro lado un mecanismo que permita fácilmente
la definición de nuevos procesos o su posterior modificación orquestando los servicios existentes en la
organización. Además debe proporcionar funcionalidades avanzadas como la de enrutamiento de datos
dinámico basado en el contenido de estos.

6WEB Services
6
WEB SERVICES
Un error muy común es confundir servicios, componentes que forman una arquitectura SOA, con
servicios web. Los servicios web son una forma de implementar estos servicios, pero no es obligatorio
que los servicios estén implementados como servicios web aunque sí es lo más común.
Los Servicios Web son piezas de Software que utilizan un conjunto de Protocolos y Estándares que
sirven para intercambiar datos entre aplicaciones. Este intercambio de información es posible gracias a
que estos componentes utilizan los mismos protocolos y Estándares y por lo tanto no importa el lenguaje
de programación, plataforma o Sistema Operativo en el que se ejecuten, estos van a poder
comunicarse.
Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y reglamentación de
los servicios Web.
El siguiente listado muestra una serie de protocolos base de los Servicios Web.
 XML (eXtensibleMarkupLanguage):Metalenguaje usado en Servicios Web para especificar los
lenguajes y protocolosnecesarios
 SOAP (Simple Object Access Protocol): Protocolos sobre los que se establece el intercambio.
 WSDL (Web ServicesDescriptionLanguage): Es el lenguaje de la interfaz pública para los servicios
Web. Es una descripción basada en XML de los requisitos funcionales necesarios para establecer
una comunicación con los servicios Web.
 UDDI (Universal Description, Discovery and Integration): Protocolo para publicar la información de
los servicios Web. Permite comprobar qué servicios web están disponibles.

7WEB Services
7
Ventajas de los Servicios Web.
 Proporcionan Interoperabilidad entre aplicaciones de Software, independientemente de la
tecnología o plataformas en las que estén desarrollados.
 Fomentan los protocolas basados en texto lo que permite acceder y entender más fácilmente su
contenido.
 Promueve la integración de servicios localizados en geografías distintas para brindar servicios más
completos.
 Permite la reutilización de las funcionalidades encapsuladas en los servicios web.
 Facilita la recombinación de servicios para proveer funcionalidades más completas.
Así, el conjunto de características de los servicios web permiten que sean la base de una arquitectura
Orientada a Servicios. Esto es los servicios que puede proporcionar una institución son organizados en
unidades atómicas que va a permitir su utilización y recombinación con la finalidad de brindar
servicios más complejos o con una mayor cantidad de características. A esta organización de servicios
se le denomina Cartera de Servicios Web.

8WEB Services
8
XML, BASE DE LOS WEB SERVICES
El XML Es un metalenguaje, dado que todo paquete XML describe en forma universal cualquier tipo de
archivo. Es decir permite contener su léxico propio, sintaxis, semántica y pragmática, desligando la
información del formato con que fue creada. En efecto, XML transforma completamente la creación y el
uso de software, revolucionando la comunicación entre aplicaciones o entre equipos, dado que ofrece
un formato de datos universal, que permite adaptar o transformar fácilmente la información y transmitirla
con estructura.
XML es una generalización más exacta y precisa que el HTLM. En efecto el HTML es un lenguaje que
describe una pagina Web desde un archivo plano, incorporando TAGs bajo una sintaxis predeterminada.
HTML = Texto + TAGs + Sintaxis Predeterminada
Sin embargo, en XML – que también es un archivo de texto plano - se marca TODO. Cualquier
información transmitida por un XML está perfectamente estructurada, las TAGs no son fijas, sino
variables según el subformato. Es decir, todo se transforma a un componente compuesto por
componentes que se abren y cierran por TAGs, que permite transmitir toda la información concerniente.
XML = Texto + TAGs + Sintaxis según contenido y contexto a comunicar
XML estructura la información en un árbol. Es decir, un paquete de datos o un documento cualquiera, el
XML lo referencia en contenido, forma y localización como una componente, que a su vez esta formado
de componentes, y así sucesivamente. Cada componente podría tener texto y/o más componentes.
Ejemplo XML
<?xml version="1.0"?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>

9WEB Services
9
El XML se completa mediante una “hoja de estilo”, que es una descripción de cómo debe verse una
información en un determinado medio. A un mismo documento XML se le pueden aplicar distintas hojas
de estilo según convenga. Por ejemplo usando una hoja de estilo por cada medio en la que se debe
representar la información6.
El XML sirve para que múltiples programas interpreten correcta y definidamente cualquier tipo de dato.
Es decir, XML sirve para que algunos programas conversen entre ellos sin intervención humana, sino
también implica facilitar la arquitectura de procesos distribuidos. Los Servicios Web son un caso
particular de esta arquitectura y XML es su lenguaje base

10WEB Services
10
ESTÁNDAR SOAP
En el núcleo de los servicios Web se encuentra el protocolo simple de acceso a datos SOAP, que
proporciona un mecanismo estándar de empaquetar mensajes. SOAP ha recibido gran atención debido
a que facilita una comunicación del estilo RPC entre un cliente y un servidor remoto. Pero existen
multitud de protocolos creados para facilitar la comunicación entre aplicaciones, incluyendo RPC de
Sum, DCE de Microsoft, RMI de Java y ORPC de CORBA.
Una de las razones principales es que SOAP ha recibido un increíble apoyo por parte de la industria.
SOAP es el primer protocolo de su tipo que ha sido aceptado prácticamente por todas las grandes
compañías de software del mundo. Compañías que en raras ocasiones cooperan entre sí están
ofreciendo su apoyo a este protocolo. Algunas de las mayores Compañías que soportan SOAP son
Microsoft, IBM, SUN, Microsystems, SAP y Ariba.
SOAP proporciona un mecanismo estándar de empaquetar un mensaje. Un mensaje SOAP se compone
de un sobre que contiene el cuerpo del mensaje y cualquier información de cabecera que se utiliza para
describir le mensaje. A continuación tiene un ejemplo:
Un mensaje debe estar dentro de sobre de SOAP bien construido. Un sobre se compone de un único
elemento envelope el sobre puede contener un elemento Header y puede contener un elemento body.
Si existe, la cabecera debe ser el elemento hijo inmediato del sobre, con el cuerpo siguiendo
inmediatamente a la cabecera.
El cuerpo contiene la carga de datos del mensaje y la cabecera contiene los datos adicionales que no
pertenecen necesariamente al cuerpo del mensaje.

11WEB Services
11
Además de definir un sobre de SOAP, la especificación de SOAP define una forma de codificar los datos
contenidos en un mensaje. La codificación de SOAP proporciona un mecanismo estándar para serializar
tipos de datos no definidos en la parte 1 de la especificación del esquema de XML.
La especificación de SOAP también proporciona un patrón de mensaje estándar para facilitar el
comportamiento de tipo RPC. Se emparejan dos mensajes de SOAP para facilitar la asociación de un
mensaje de petición con un mensaje de respuesta.
La llamada a un método y sus parámetros se serializan en el cuerpo del mensaje de petición en forma
de una estructura.
El elemento raíz tiene el mismo nombre que el método objetivo, con cada uno de los parámetros
codificado como un subelemento.
El mensaje de respuesta puede contener los resultados de la llamada al método o una estructura de
fallo bien definida. Los resultados de la llamada a un método se serializan en el cuerpo de la petición
como una estructura. Por convenio, el elemento raíz tiene el mismo nombre que el método original al
que se añade result. Los parámetros de retorno se serializan como elementos hijo, con el parámetro de
retorno en primer lugar. Si se encuentra un error el cuerpo del mensaje de respuesta contendrá una
estructura de fallo bien definida.
Por convenio, el elemento raíz tiene el mismo nombre que el método original al que se añade result. Los
parámetros de retorno se serializan como elementos hijo, con el parámetro de retorno en primer lugar.
Si se encuentra un error el cuerpo del mensaje de respuesta contendrá una estructura de fallo bien
definida.

12WEB Services
12
ESTÁNDAR WSDL
WSDL (Web ServiceDescriptionLanguage) 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.
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.

13WEB Services
13
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 . 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.
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.

14WEB Services
14
ESTÁNDAR UDDI
Cuando todas las aplicaciones son locales, es muy sencillo encontrar lo que desea. Sin embargo,
cuando posee un sistema distribuido, tal como el de servicios web, no posee el beneficio que brinda un
repositorio centralizado. Los sistemas distribuidos también son propensos al cambio. Este es el mundo
en el que se creó UDDI. Se creó con dos finalidades. En su encarnación inicial, fue concebida como una
clase de “Registro Universal de Empresas”. La idea era que las empresas podrían buscar socios
utilizando uno de los tres métodos que se describen a continuación:
 "Páginas blancas": Las páginas blancas eran como las páginas blancas de una guía telefónica, en
las que uno puede buscar información acerca de la empresa. Por ejemplo, si usted conocía el
nombre de la empresa, podría encontrar su ubicación, cómo contactarla, y más aún, a quién
contactar dentro de esa organización.
 "Páginas amarillas": Las páginas amarillas, otra vez, eran como las páginas amarillas de la guía
telefónica, en las que se pueden buscar empresas en función de una clasificación. UDDI especificó
varias taxonomías que las empresas podrían utilizar para clasificarse a sí mismas. Por ejemplo, si
se buscaban artículos deportivos, podría buscar empresas con el código 339920 del Sistema de
Clasificación de Industrias de Norteamérica (NAICS).
 "Páginas verdes": No, no existen páginas verdes en su guía telefónica, pero la idea era que las
empresas pudieran utilizar este método de búsqueda para encontrar socios comerciales que habían
implementado un servicio en particular. Por ejemplo, puede realizar una búsqueda de empresas
mediante un tipo de búsqueda que calcula la distancia utilizando los códigos postales.

15WEB Services
15
UDDI fue también concebida como un modo de mantener la ejecución de aplicaciones distribuidas a
largo plazo. La idea era que se podría copiar en caché la información acerca de cómo accederá a un
servicio en particular, y si su cliente iba a la quiebra, la aplicación iría automáticamente nuevamente
hacia el registro y verificaría si se había cambiado la información. De haber cambiado, podría
simplemente realizar los cambios en su aplicación (automáticamente, en un mundo ideal) y reintentar su
solicitud.
La información contenida en un registro UDDI contiene cinco tipos diferentes:
 businessEntity, o la organización corporativa real. Esto puede significar una organización global o
puede ser una filial o subdivisión.
 publisherAssertion, o la relación entre varias businessEntities. publisherAssertions deben ser
reclamadas por ambas partes para ser válidas (por lo cual no se puede reclamar que se trata de
una subdivisión de otra empresa) a menos que ambas entidades sean responsables ante el editor o
excepto que ambas partes ingresen al registro por la misma cuenta de usuario.
 bindingTemplate, el cual es esencialmente la especificación de una interfaz del servicio. Puede ser
implementado por múltiples businessServices.
 businessService, o un servicio provisto por un negocio. Entonces, puede parecer simple, pero en el
mundo de UDDI no significa necesariamente que se trata de un servicio web. Por ejemplo, se puede
especificar el servicio de soporte telefónico de su empresa (lo cual significa el número telefónico real
que marca el usuario y todo lo que ello conlleva) como un servicio UDDI. Por supuesto, no se
obtendría un documento WSDL ficticio, pero constituiría un servicio que brinda su empresa.
 tModels, o modelos de metadatos. Al investigar la UDDI, Francis llega a la conclusión de que el
tModel constituye quizás el motivo principal por el que no comenzó a tener éxito, tal como se
esperaba. Como registro de servicios, usted esperaría encontrar una manera directa de especificar
la interfaz de un servicio, tal como lo hace WSDL. Pero, tal como se especifica, no era la intención
que UDDI se relacione exclusivamente con servicios web, y fue designado con mucha más
flexibilidad. tModels un punto de ayuda para los documentos XML, tal como lo veremos más tarde,
pero de hecho, tienen como finalidad especificar información acerca de algo vía un servicio, negocio
o algo más.
UDDI posee la reputación de ser extremadamente compleja, pero en esencia está conformada por los
cinco tipos de datos detallados anteriormente, combinados con cuatro operaciones: Find (Encontrar),
Get (Tomar), Save (Guardar), y Delete (Borrar). En otras palabras, las notas de especificación de UDDI
establecen que se puede realizar lo siguiente con los datos:
 find_xx: Estos métodos, tales como find_businessEntity, find_businessService, etc., brindan una
manera de poder buscar un registro en el registro de UDDI. Estos métodos devuelven la clave que

16WEB Services
16
identifica al objeto.
 get_xx: Una vez que posee la clave única para identificar un objeto, puede utilizar get_xxmethods,
tal como get_businessService etc., para recuperar el propio objeto real. Por ejemplo,
get_businessService permite visualizar todo el objeto businessService, desde el cual puede obtener
la información que necesita.
 save_xx: Tal como seguramente ha podido ya adivinar, estos métodos agregan información a la
base de datos o alteran información que ya se encuentra en la base de datos.
 delete_xx: Estos métodos, tales como delete_bindingTemplate, delete_tModel, etc., toman la clave
única del objeto como parámetro y la sacan de la base de datos. El comportamiento real de estos
métodos depende de lo que está eliminando. Por ejemplo, dado que tModels son frecuentemente
referentes de otros objetos de la base de datos, no pueden ser eliminados; en lugar de ellos se los
oculta.

17Seguridad con Web Services
17
SEGURIDAD CON WEB SERVICES
La seguridad es uno de los mayores desafiados en una entidad financiera o de otro rubro donde
manejen web services para comunicarse entre empresas.
IBM dice, que si no hay seguridad en los Web Services los tres mayores riesgos son:
 Transacciones sin autorización
Alguien que posea un cliente no autorizado, puede enviar mensajes SOAP a el data center para obtener
dinero. Esta transacción no es autorizada.
Para solventar este problema se pueden utilizar los mecanismos de WS-Security. Un ejemplo puede ser
que se incluya una combinación de id/password en el mensaje SOAP.
 Los mensajes están en texto legible, es decir sin encriptación
El número de cuenta o el balance que viajan en el paquete SOAP puede ser leído por un sniffer en la
red. Este problema se puede solventar utilizando SSL ya que así se encriptan los mensajes.
 Los mensajes SOAP son susceptibles a la modificación, no existe integridad
Mientras el mensaje SOAP está viajando a su destino (un cliente del web Service), este puede ser
interceptado en el camino y el atacante puede modificar el mensaje, por ejemplo cambiando el número
de cuenta a la cual se va a hacer el depósito.
Diagrama de implementación de seguridad en Web Service:

18Seguridad con Web Services
18
Servicios que se deben implementar en un Web Services para la seguridad:
 Identificación: La parte o cliente que acceso a un recurso, debe poder identificarse con el sistema.
 Autenticación: Debe existir un procedimiento para verificar la identidad de quienes accedan al
sistema.
 Autorización: Deben existir un set de transacciones para que el cliente sea habilitado.
 Integridad: La información no puede cambiarse en el viaje de un Web Service a un cliente y
viceversa.
 Confidencialidad: Nadie puede leer la información que viaje entre el cliente y el Web Service.
 Auditoria: Todas las transacciones deben ser guardadas, para que en caso de un problema estas
puedan ser analizadas.
 No-Repudiación: Ambas partes deben estar habilitadas para proveer un documento legal, a una
tercera parte para que siempre sea la misma información la que se envié el servidor, como la que
recibe el cliente y viceversa.

19WS-Security (WSS)
19
WS-SECURITY (WSS)
El WS-Security (WSS) es una extensión del protocolo SOAP que define mecanismos para proteger la
integridad y confidencialidad en los mensajes mediante el uso de SAML, Kerberos, tokens o los
certificados X.509, además de la encriptación y las signaturas XML.
En primer lugar, tenemos que tener en cuenta que WS-Security no es un nuevo tipo de servicios web ni
de seguridad. WS-Security define cómo utilizar mecanismos existentes para proporcionar autenticación,
confidencialidad e integridad a los Servicios Web. De este modo, en lugar de definir un estándar desde
cero, resuelve el problema de la autenticación mediante el uso de Kerberos y certificados X.509, se cifra
con el XML Encryption y se firma con la XML Signature tras preparar los datos mediante el
XML Canonicalization.
Una de las características del WS-Security es que es un framework que integra los anteriores
estándares en el mensaje de tipo SOAP de modo que se puede aplicar tanto a trozos del documento
como a su totalidad e independientemente de los protocolos de transporte. WS-Security define una
cabecera de SOAP para almacenar la información de seguridad de tal modo que si se implementa una
signatura digital, esta cabecera incluirá la información necesaria asociada como, por ejemplo, el
resultado de la misma.
En la siguiente figura se muestra un ejemplo de flujo de mensajes utilizando el WS-Security.
El Security TokenService es el servicio de validación empleado, es decir, Kerberos, certificados X.509 o
un sistema consistente en user/password. El procedimiento consiste en un cliente que solicita
los tokens necesarios para dar seguridad a la transmisión y, a partir de aquí, los añade
convenientemente al mensaje y los manda al servidor. Éste es capaz de validar la integridad,
confidencialidad y no repudio del mensaje y, a continuación, puede responder al cliente.
AUTENTICACIÓN

20Transacciones con Web Services
20
UsernameToken: se utiliza un nombre de usuario junto con una contraseña para validar al
cliente. En este caso, el cliente debe signar el mensaje y el servidor puede comprobar la
veracidad calculando la firma del mensaje recibido y comparándola con el valor recibido.
En el caso de utilizar certificados X.509, el mensaje puede ser firmado utilizando una clave
privada. Entonces, el mensaje debe contener el certificado en un BinarySecurityToken. Se
recomienda firmar también el certificado con la clave privada.
ENCRIPTACIÓN
Dado que WS-Security no define nuevos estándares sino que se basa en los ya existentes, para la
encriptación se puede usar criptografía de clave pública o privada, simétrica o asimétrica. Normalmente,
se realiza a través del ya antes mencionado XML Encription, que permite cifrar tanto partes de un
documento como su totalidad y que se caracteriza por cifrar contenido, por lo que se puede mantener la
estructura de XML
FIRMA
Para firmar los documentos se pueden utilizar los tres métodos de autenticación mencionados
anteriormente. Sin embargo, también se ofrece la posibilidad de aplicar la XML Signature, la cual define
la sintaxis adecuada para las signaturas digitales que se pueden implementar. Además, también se
incluye el modo de comprobar su veracidad, así como el modo de generarlas. Se distingue de otras
opciones (com el PGP) por soportar la firma de sólo unaparte del árbol XML (también se ofrece la
posibilidad de que dos mensaje que difieran por ejemplo en un espacio, tengan la misma firma).
TRANSACCIONES CON WEB SERVICES
Podemos definir un servicio transaccional como aquel que guarda información usando una transacción
de base de datos. Si hablamos de servicios Web, habitualmente la transacción comienza cuando se
inicia el servicio y finaliza tras completarse la operación al no soportar unirse a una transacción ya
existente en el sistema que los invoca.
Ahora bien, como comentábamos antes, en una integración basada en servicios, su principal utilidad es
proporcionar interoperabilidad para el intercambio de información entre diferentes sistemas. Por tanto,
no es fundamental que las operaciones se realicen en una misma transacción. De hecho, en una
orquestación de servicios donde se realiza un flujo de llamadas a varios servicios, es habitual incluir
mecanismos de compensación para poder realizar el roll back de las operaciones si, tras haber
realizado de forma satisfactoria la llamada a N servicios, la llamada al servicio N+1 no se realiza de
forma correcta.

21
En general siempre se puede enfocar el diseño de los servicios de forma que las diferentes operaciones
que tengan que agruparse dentro de una misma transacción se puedan implementar en un mismo
servicio, y en caso de no poder ser así, siempre se puede incorporar los mecanismo de compensación
que permitan deshacer las operaciones en el orden adecuado.
Pero, en el caso de necesitar implementar transacciones distribuidas entre varios servicios Web, ¿es
posible?¿qué opciones hay disponibles? Si revisamos los estándares especificados en OASIS,
organismo encargado de desarrollar estándares abiertos para el intercambio de información con
servicios Web, encontramos:
 WS-AtomicTransaction v1.2
 WS-BusinessActivity v1.2
 WS-Coordination v1.2
Se tratan de especificaciones de reciente aprobación (febrero 2009), en los que han participado la
mayor parte de los líderes de la industria, Oracle, Microsoft, IBM, SAP, RedHat, etc, que han
incorporado, en algunos casos sólo de forma parcial, implementaciones en las versiones más recientes
de sus principales productos.
WS-COORDINATION
Proporciona una infraestructura para dar soporte a formas concretas decoordinación (protocolos de
coordinación)
Método para introducir identificadores únicos en los mensajesintercambiados entre los servicios
(Coordinationcontext, cabecera SOAP)
Método para informar de la dirección de un servicio Web que participa en laconversación
(Registration interface)
Método para informar del rol que asumen en una conversación (Activationinterface)
Estos objetivos son logrados de forma independiente del protocolo de coordinación ejecutado por los
participantes.

22
Entre los componentes que se encuentran en WS-Coordination podemos mencionar las abstracciones
utilizadas en la descripción de las interacciones entre un coordinador y sus participantes :
 CoordinationProtocol: Corresponde al conjunto de reglas a las cuales una conversación debe
ajustarse al momento de su desarrollo (descripción del protocolo de coordinación).
 CoordinationType: Corresponde a la especificación del tipo de protocolo utilizado, vale decir, un
valor de coordinationtype representa una conversación concreta.
 CoordinationContext: corresponde a la estructura de datos utilizada para detallar la conversación a
la cual pertenecen los mensajes SOAP intercambiados.
En cuanto a las formas de interacción que es posible encontrar entre un coordinador y sus participantes
podemos mencionar:
 Activación: esta interacción ocurre cuando un participante solicita a un coordinador la creación de
un nuevo contexto de coordinación, vale decir, la creación de una nueva conversación.
 Registro: Esta interacción ocurre cuando un participante se registra en un coordinador para
participar en una conversación.
 Interacciones específicas del protocolo: Estas interacciones ocurren cuando el coordinador y los
participantes registrados intercambian mensajes específicos del protocolo de coordinación de
conversación.
En resumen WS-Coordination aporta la capacidad de registrar a los sistemas que tomaran parte en un
proceso de negocio y generar un contexto con información (tanto del registro como de la coordinación)
para entregarla a los otros sistemas participantes en el proceso de negocio.

23
WS-TRANSACTION
WS-Transaction se apoya en la infraestructura de WS-Coordination, la cual modela el contexto de la
transacción. Esta especificación tiene su origen como ya lo habíamos mencionado en el contexto de las
bases de datos y es utilizado en entornos distribuidos cuando dos o más Web Services están
involucrados en una interacción (conversación) y las operaciones invocadas no son independientes. El
objetivo final es que todas las operaciones sean ejecutadas con éxito, o en caso contrario ninguna de
ellas sea ejecutada. Las transacciones en Web Services poseen algunas diferencias notables con las
generadas en bases de datos, entre las cuales podemos mencionar que el tiempo que cuesta en
completar un transacción en Web Services es muchísimo más largo de lo que toma en una base de
datos debido a que en los Web Services es posibles ejecutar complejos procesos de negocios; otra
diferencia es que se amplia la variedad de recursos y operaciones a aplicar sobre ellos.
La especificación de WS-Transaction fue publicada el año 2002 por IBM, Microsoft y BEA. La cual
especifica un protocolo estándar para la ejecución de transacciones en entornos de Web Services. La
especificación establece dos tipos de transacciones:
 AtomicTransactions: Corresponde a transacciones atómicas o de corta duración, en las cuales se
conserva la idea de las propiedades ACID (Atomicidad, Coherencia, Aislamiento y Durabilidad) en
un sentido muy estricto, lo que resulta en que todas las operaciones dentro de una transacción se
ejecutan con éxito o no se ejecuta ninguna. Este tipo de transacciones por lo general resultan en
entornos muy confiables.
 Business Activities: Corresponde a transacciones de larga duración en la cual las propiedades ACID
son flexibilizadas. Las operaciones son todas invocadas a los participantes, los cuales después de
su ejecución informan al coordinador si estas operaciones han sido completadas con éxito. Si
alguna de estas operaciones falla, se requiere la ejecución de operaciones de “compensación” ya
que acá los cambios son permanentes desde el principio, por tanto si la operación falla se deberá
realizar operaciones que permitan deshacer los cambios.
De los dos tipos de mecanismos de transacción, el más utilizado para implementar procesos de
negocios complejos es por transacción BusinesActivities.

24Bibliografía
24
BIBLIOGRAFÍA
 http://www.ibm.com/developerworks/ssa/webservices/newto/index.html
 http://www.revista-ays.com/DocsNum08/SOA/roncero.pdf
 http://www.desarrolloweb.com/articulos/1557.php
 http://www.ibm.com/developerworks/ssa/webservices/tutorials/ws-soa1/section5.html
 Whitepaper: La arquitectura SOA de Microsoft® aplicada al mundo real
 http://iaaa.cps.unizar.es/docencia/SW/8.Coordinacion@.pdf
 http://www.fing.edu.uy/inco/grupos/lins/documentos/soa/ws/LINS_Introduccion_a_WS.pdf

Sod arquitecturas basadas en servicios

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Sod arquitecturas basadas en servicios

Similar a Sod arquitecturas basadas en servicios (20)

Último

Último (20)

Sod arquitecturas basadas en servicios