Vous êtes sur la page 1sur 13

Servicios Web.

Estndares, Extensiones y Perspectivas


de Futuro
Vicente Pelechano
Departamento de Sistemas Informticos y Computacin
Universidad Politcnica de Valencia
pele@dsic.upv.es

Resumen. Internet introduce un nuevo entorno donde el software se va a


ofrecer y acceder como servicio. Los servicios web proporcionan la plataforma
ideal para conseguir la completa integracin de los procesos de negocio de una
organizacin con diferentes organizaciones. Este documento presenta una
introduccin a los servicios web, las tecnologas y estndares bsicos (SOAP,
WSDL, UDDI) para el correcto desarrollo de los servicios web. Adems se
presenta, con perspectivas de futuro, una visin general de las distintas
extensiones que se estn desarrollando en la actualidad.

Introduccin

En los ltimos aos la mayora de procesos de negocio han cambiado en


flexibilidad, interconectividad y autonoma debido a las condiciones del mercado, a
los nuevos modelos organizacionales y a los escenarios de uso de los sistemas de
informacin. En este contexto, Internet y el Web estn cambiando la forma en la que
se ofrecen los negocios y los servicios a la sociedad global, y en la que estos negocios
interoperan. Esta tendencia nos lleva a sistemas de informacin conectados e
integrados a travs de la infraestructura que proporciona Internet. Internet introduce
un nuevo entorno donde el software se va a ofrecer y acceder como servicio. Los
servicios web proporcionan la plataforma tecnolgica ideal para conseguir la
completa integracin de los procesos de negocio de una organizacin con diferentes
organizaciones. Los servicios web prometen ser el mecanismo adecuado para la

Vicente Pelechano

implementacin de las Arquitecturas Orientadas a Servicios (SOA)1 para sistemas de


informacin integrados y distribuidos.
Este documento se estructura en los siguientes apartados: en el apartado 2 se
presenta una introduccin a los servicios web, se proponen definiciones del concepto,
los beneficios que conlleva su aplicacin, y algunos ejemplos y tipos de aplicaciones.
En el apartado 3 se introduce una breve presentacin de las tecnologas, protocolos y
estndares bsicos (SOAP, WSDL, UDDI) para el funcionamiento de los servicios
web. Por ltimo, el apartado 4 presenta un anlisis y una categorizacin de las
distintas extensiones y nuevos protocolos que se estn desarrollando actualmente, as
como un informe sobre la problemtica del desarrollo de propuestas alternativas de
estndares. Para finalizar se identifica el nivel de adopcin de los estndares
desarrollados.

Servicios Web.

La evolucin vertiginosa de Internet y el negocio electrnico necesita de tecnologas


software que faciliten la conexin de informacin, sistemas, dispositivos y
personas. Desde la aparicin del Web los procesos de negocio ofrecidos a travs del
Web han ido mejorando, en una primera fase (1995 aprox.) se inicia el inters por el
desarrollo de Portales fomentado la presencia de las empresas, en un segunda fase
(1997 aprox.) se implanta el Comercio electrnico y las transacciones a travs de
Internet (eCommerce), en una tercera fase (desde 1999 hasta la actualidad) se inicia
lo que se llama la Economa Digital con el desarrollo e implantacin de los negocios
(eBusiness), las empresas (eEnterprises) y los mercados (eMarkets) electrnicos.
Los mercados electrnicos constituyen la nueva generacin de negocios digitales
proporcionando bienes y servicios de carcter electrnico que sustituyen a los
tradicionales. Dichos servicios pueden integrarlos otras empresas en sus modelos de
negocio: mensajera, reserva de vuelo, etc. En este contexto estamos evolucionando
hacia empresas y relaciones virtuales a travs de Internet con clientes cada vez ms
exigentes.
Los Servicios Web constituyen un esfuerzo para construir plataformas distribuidas
para el Web que den un soporte adecuado, como mecanismo de implementacin, a la
Economa Digital. Los Servicios Web son la ltima evolucin tecnolgica desde el
clsico modelo cliente/servidor, el middleware distribuido mediante sistemas basados
en RPC, monitores TP, brokers de objetos, monitores de objetos o la orientacin a

Segn el marco conceptual WSA (Web Services Architecture) propuesto por W3C [1,2], una SOA es un
tipo especfico de sistema distribuido en el cual los agentes son servicios.

Servicios Web. Estndares, Extensiones y Perspectivas de Futuro

mensajes (MOM), pasando por el middleware de integracin de aplicaciones (EAI),


los sistemas de Workflow y por ltimo la tecnologa web clsica y los Sitios Web (o
Portales). La nueva evolucin tecnolgica debe: permitir la interoperabilidad
Universal, la amplia y rpida adopcin y un soporte eficiente de entornos abiertos.
Los servicios web para tener xito y promover su rpida implantacin a nivel mundial
deben cumplir los siguientes requisitos:
Basado en Estndares.
Soporte a la Pervasividad (Everywhere, Everytime, Everyplace).
Requerir una cantidad mnima de infraestructura (conjunto mnimo de
estndares).
Permitir la integracin de aplicaciones de manera flexible.
Estar centrado en Mensajes y Documentos, no en APIs.
2.1 Definicin de Servicio Web
Una definicin genrica de Servicio Web es: Una aplicacin accesible a otras
aplicaciones a travs del Web. El UDDI consortium (www.uddi.org) introduce la
siguiente definicin Self-contained, modular business applications that have open,
Internet-oriented, standards-based interfaces, la referencia mundial en el mundo
Web W3C lo define como es un sistema software identificado por una URI, cuyos
interfaces pblicos y enlaces se definen y describen usando XML. Su definicin puede
ser descubierta por otros sistemas software. Estos sistemas pueden interactuar con el
servicio Web de la forma prescrita por su definicin, usando mensajes basados en
XML a travs de protocolos estndares de Internet, y por ltimo, una definicin
precisa disponible en Webopedia (http://www.pcwebopedia.com/) dice a
standardized way of integrating web based applications using XML, SOAP, WSDL
and UDDI open standards over an Internet protocol backbone, XML is used to tag the
data, SOAP is used to transfer de data, WSDL is used for describing the services
available, and UDDI is used for listing what services are available. En definitiva, un
servicio web expone funcionalidad a un consumidor, es una URL programable y
proporciona mecanismos para invocar operaciones de forma remota (a travs de
Internet), est basado en estndares web (HTTP, XML, SOAP, WSDL, UDDI, y ms
que vendrn), puede implementarse en cualquier lenguaje y en cualquier
plataforma, actuando como caja negra (componentes reutilizable y alquilables).
2.2 Arquitecturas Orientadas a Servicios. SOA
Los servicios web han puesto (de nuevo) de moda las Arquitecturas Orientadas a
Servicios (SOA). SOA es una forma de arquitectura para sistemas distribuidos (SD)
caracterizada por las siguientes propiedades:

Vista Lgica: El servicio es una abstraccin (vista lgica) de los programas,


bases de datos, procesos de negocio, etc., definido en trminos de lo que
hace (llevando a cabo una operacin de negocio).

Vicente Pelechano

Orientacin a Mensajes: El servicio se define formalmente en trminos de


los mensajes intercambiados entre agentes proveedores y solicitantes, y no
est basado en las propiedades de los agentes. La estructura interna del
agente (lenguaje de programacin, BD, proceso, etc.) se abstrae en SOA.
Esto permite incorporar cualquier componente o aplicacin a esta
arquitectura decorando estos componentes con software de gestin y
conversin.

Orientacin a la Descripcin: Un servicio se describe con metadatos


procesables. La descripcin da soporte a la naturaleza pblica de SOA: slo
se incluyen en la descripcin aquellos detalles que se exponen pblicamente
y son importantes para el uso del servicio. La semntica de un servicio debe
documentarse, directa o indirectamente, por su descripcin.

Granularidad: Los servicios tienden a usar un pequeo nmero de


operaciones con mensajes relativamente complejos.

Orientacin a la Red: Los servicios tienden a usarse a travs de la red,


aunque este no es un requisito absoluto.

Neutral a la Plataforma: Los mensajes se envan en un formato estndar y


neutral a la plataforma, distribuido a travs de los interfaces (XML).

En general, SOA y Servicios Web son apropiados para aplicaciones:

Que deben operar a travs de Internet, donde la fiabilidad y la velocidad no


se puede garantizar;

Donde no existe habilidad de gestionar la instalacin de forma que todos los


solicitantes (clientes) y proveedores se actualicen a la vez;

Donde los componentes de un SD se ejecuten en distintas plataformas y


distintos productos;

Donde una aplicacin existente necesite exponerse para ser usada a travs de
la red y pueda decorarse como un Servicio Web.

Figura 1. Arquitectura Orientada a Servicios

Servicios Web. Estndares, Extensiones y Perspectivas de Futuro

En trminos de modelos de interaccin abstractos [6], una arquitectura SOA como


podemos apreciar en la figura 1 requiere de las siguientes interacciones:
1. Un servicio web publica su definicin (WSDL) en un repositorio / directorio /
registro distribuido (UDDI).
2. El consumidor del servicio web busca la definicin del servicio en el
repositorio.
3. El repositorio usa la informacin de la definicin (WSDL) para enlazar con el
servicio y enviar peticiones (SOAP) al servicio que ofrece el proveedor de
servicios.

Estndares y Tecnologas Subyacentes. Infraestructura Bsica

La infraestructura mnima que requieren los Servicios Web se puede definir en


trminos de:
Lo que va en la red: Formatos y protocolos de comunicacin
Lo que describe lo que va en la red: Lenguajes de Descripcin de Servicios
Lo que nos permite encontrar y almacenar dichas descripciones:
Descubrimiento de Servicios.
3.1 La Pila de las Tecnologas.
Las especificaciones que se han desarrollado para implementar estos mecanismos
(en muchas propuestas [3,4,5] se presentan como una pila de tecnologas donde las
especificaciones superiores hacen uso de las inferiores, ver figura 2) son:
1. HTTP: (Hypertext Transfer Protocol) HTTP es un protocolo estndar de W3C
para la transferencia de documentos en Internet. Los Servicios Web lo utilizan
como mecanismo de comunicacin. Es un protocolo genrico y sin estado.
2. XML: (eXtensible Markup Language) lenguaje que deriva de SGML, diseado
para representar y transferir datos estructurados, separa datos de formateo y
transformacin, se utiliza como base para definir los formatos de.
3. SOAP: (Simple Object Access Protocol, www.w3.org/2002/ws/), ofrece los
mecanismos de comunicacin bsicos para el envo de mensajes en formato XML,
permitiendo la invocacin remota de servicios. Normalmente funciona sobre
HTTP, pero no siempre. SOAP es el sine qua non de los servicios web.
4. WSDL: (Web Services Description Language, www.w3.org/TR/wsdl), es un
formato basado en XML (desarrollado por IBM y Microsoft) para describir de
manera formal servicios WEB.
5. UDDI: (Universal Description, Discovery, and Integration, www.uddi.org), es un
directorio que contiene un registro/repositorio de descripciones de servicios Web.

Vicente Pelechano

Figura 2. La pila de los Servicios Web

3.2 SOAP (Simple Object Access Protocol). El Formato de los Mensajes.


SOAP (en su versin actual 1.2, recomendado por W3C en 2003) define un protocolo
que da soporte a la interaccin (datos + funcionalidad) entre aplicaciones en entornos
distribuidos y heterogneos, es interoperable (neutral a plataforma y lenguajes de
programacin, independiente del HW y protocolos. Funciona sobre la infraestructura
(Estndares) existente en Internet. SOAP define cmo organizar informacin usando
XML de forma estructurada y tipada para intercambiarla entre distintos sistemas.
3.2.1 Qu especifica SOAP?
SOAP especifica:
Un formato de mensaje para una comunicacin unidireccional,
describiendo cmo se empaqueta la informacin en documentos XML.
Un conjunto de convenciones para usar mensajes SOAP para
implementar el patrn de interaccin RPC, definiendo cmo los clientes
pueden invocar un Procedimiento Remoto enviando un mensaje SOAP
y cmo los servicios pueden responder enviando otro mensaje al
llamador.
Un conjunto de reglas que una entidad que procesa mensajes SOAP
debe seguir, definiendo en particular los elementos XML que una
entidad debe leer y entender, as como las acciones que deben toma si no
entienden el contenido. Reglas de Codificacin de los Datos.
Una descripcin de cmo se debe transportar un mensaje SOAP sobre
HTTP y SMTP. Se definirn Bindings a otros protocolos de
transporte en futuras versiones de la especificacin
3.2.2 El Formato del Mensaje
SOAP intercambia informacin mediante mensajes. Los mensajes se utilizan como
envoltorios que la aplicacin utiliza para guardar la informacin que quiere enviar.
Cada envoltorio contiene dos partes: Una cabecera (opcional) y un cuerpo
(obligatorio). La cabecera y el cuerpo pueden tener mltiples subpartes en forma de
bloques de la cabecera y bloques del cuerpo (ver figuras 3 y 4).

Servicios Web. Estndares, Extensiones y Perspectivas de Futuro

Figura 3. Formato de un Mensaje SOAP

Figura 4. Mensaje SOAP

3.3 WSDL (Web Services Description Language). El Lenguaje de Descripcin.


WSDL creado originalmente por IBM, Microsoft y Ariba (actualmente en la versin
1.2). Tiene el rol y el propsito similar al de los IDL de las plataformas middleware.
Un archivo WSDL es un documento XML que describe los Servicios Web, en
particular sus interfaces. Como caracterstica que lo diferencia de los IDL es que
WSDL debe definir los mecanismos de acceso (protocolos) a los servicios Web. (IDL
no los define en el middleware convencional porque se suponen por defecto). Otra
caracterstica diferenciadora es la necesidad de definir (en la especificacin) la
localizacin del servicio (puntos finales). La separacin de interfaces y enlaces de
protocolos, y la necesidad de incluir informacin de localizacin permite la definicin
de especificaciones modulares. WSDL permite definir interfaces ms complejos y
expresivos permitiendo definiciones de interacciones asncronas y diferentes
paradigmas de interaccin, y la posibilidad de combinar o agrupar operaciones.

Vicente Pelechano

Figura 5. Estructura de un Documento WSDL

3.3.1 Estructura de un Documento WSDL


El documento WSDL de un servicio proporciona dos piezas de informacin bsicas:
(1) una parte o interfaz abstracta (independiente de la aplicacin) y (2) una parte
concreta que define los enlaces a protocolos e informacin de los puntos finales de
acceso al servicio (ver figura 5).
La parte abstracta esta compuesta por:
Definiciones de Port types: anlogos a los interfaces en los IDL. Cada port
type es una coleccin lgica de operations.
Cada operation define un intercambio simple de mensajes.
Un message es una unidad de comunicacin representando un intercambio
de datos en una nica transmisin lgica.
Un sistema de tipos (types) usados por las operations (por defecto XML
schema).
La parte concreta esta compuesta por:
Definiciones de Bindings: se especifica la codificacin de los mensajes, y
los enlaces a protocolos de todas las operaciones y mensajes definida en un
port type.
Definiciones de Ports: se especifica en qu direccin (URI) se puede
acceder la implementacin del port type. Definen un punto final (lugar de la
red) donde est el servicio.
Definiciones de Services: definen una agrupacin de Ports.
De esta forma WSDL se utiliza para describir un Servicio Web en trminos de los
mensajes que acepta y genera, acta como contrato entre un consumidor (cliente) y
dicho Servicio. WSDL puede describir puntos finales y sus operaciones sin
especificar el formato de los mensajes o los protocolos de red (Simple Object Access
Protocol (SOAP) 1.1, HTTP-GET/POST y MIME) a los cuales el punto final esta
ligado. En el desarrollo se utiliza como entrada a los compiladores de Stubs y
Proxies (ver ejemplo en figura 6).

Servicios Web. Estndares, Extensiones y Perspectivas de Futuro

Figura 6. Ejemplo de archivo WSDL

3.4 UDDI (Universal Description, Discovery, and Integration). El Repositorio de


Servicios.
UDDI, creado originalmente por IBM, Microsoft y Ariba, desde su versin 3 (en
2002) ha pasado a manos de OASIS (www.oasis-open.org) que a partir de ahora va a
determinar su futuro y extensiones.
UDDI se concibi como un Registro de Negocio = Servicio de Directorio y
Nombrado sofisticado. Especifica un marco para describir y descubrir Servicios Web.
UDDI define estructuras de datos y APIs para publicar descripciones de servicios en
el registro y para consultar el registro para buscar descripciones publicadas. Las APIs
de UDDI estn especificadas con WSDL y con SOAP Binding, lo que permite
acceder a ellas como Servicios Web.
La especificacin UDDI tiene dos objetivos esenciales: (1) ser un soporte a los
desarrolladores para encontrar informacin sobre servicios web y poder construir
clientes, (2) facilitar el Enlace Dinmico de Servicios Web, permitiendo consultar
referencias y acceder a servicios de inters.
3.4.1 Modelo de Informacin. Estructura de Datos de UDDI
La informacin en un registro UDDI se almacena en ficheros XML con una estructura
jerrquica (ver figura 7). Los elementos de esta estructura son:
businessEntity: es el elemento top-level, describe un negocio o una entidad
que ha registrado un servicio en UDDI. Ejemplos: Departamento de
Contabilidad, Servidor de Aplicaciones Corporativo. Este elemento soporta
informacin estndar tal como nombre, descripcin, e informacin de contacto,
as como informacin de metadatos (por ejemplo: identificadores y categoras).

10

Vicente Pelechano
businessService: describe un Servicio Web que ha sido expuesto por una

entidad de negocio, soporta el nombrado de un Servicio Web y lo asocia con una


entidad de negocio y con la informacin de binding. Soporta la asignacin de
categoras al Servicio Web (industria, productos, cdigos geogrficos, etc.).
bindingTemplate: describe la informacin tcnica necesaria para enlazar con
un Servicio Web en particular. Este elemento soporta el nombrado de un Servicio
Web y su asociacin con una entidad de negocio e informacin de binding. La
informacin de binding se describe como un punto de acceso que posee un
atributo llamado UrlType utilizado para especificar los siete tipos de puntos de
entrada: mailto, http, Https, Ftp, Fax, Phone, Other.
tModel: (Technology Model). Estructura de Metadatos Genrica para representar
cualquier concepto o construccin (definiciones de protocolos, ficheros WSDL,
XML schemas, Espacios de Nombres, esquemas de categoras, etc.).

Figura 7. Estructura de Datos UDDI

Extensiones y Perspectivas de Futuro

Los servicios web y SOA prometen la integracin universal de aplicaciones, sin


embargo esta afirmacin actualmente es bastante vaga, ya que mirando de cerca el
estado actual nos damos cuenta de algunos agujeros en fiabilidad, seguridad,
orquestacin, soporte a sistemas legados y a la semntica. En general, los servicios
web son tiles para necesidades simples como obtener informacin de los portales
web, pero las aplicaciones crticas y complejas son otra historia [7]. Este ltimo tipo
de aplicaciones demanda nuevos estndares que estn todava en desarrollo.
4.1 La Pila de Protocolos y Estndares
Estos estndares, extensiones y protocolos se estn proponiendo en el contexto de
un marco modular que permita a los desarrolladores utilizar slo los mdulos o
aspectos necesarios para sus servicios web. No existe una propuesta estndar de Pila
de Protocolos, una de las ms actualizadas se presenta en la figura 8 extrada de [8].
Entre este tipo de protocolos y estndares podemos destacar algunos muy necesarios

Servicios Web. Estndares, Extensiones y Perspectivas de Futuro

11

para la total implantacin de los servicios web; stos dan soporte a la fiabilidad del
envo de mensajes (WS-ReliableMessaging, WS-Eventing, WS-Addressing),
seguridad (WS-Security ratificado por OASIS y WS-I, SAML (Security Assertion
Markup
Language),
WS-Policy,
WS-SecurityPolicy,
WS-Trust,
WSSecureConversation) y orquestacin (BPEL (Business Process Execution Language)
complementada con WS-Transaction, WS-Coordination, WS-Choreogrphy y WS-CAF
(Composite Application Framework)) diseados para facilitar la implementacin de
transacciones y procesos de negocio complejos.

Figura 8. Pila Actualizada de los Protocolos

4.2 Protocolos Adicionales


Si se tiene en consideracin la figura 8, se puede observer que el conjunto de protocolos es
bastante complete, aunque existen aspectos que no estn completamente tratados:
Gestin. El comit tcnico de OASIS WSDM est todava desarrollando su trabajo
en fases muy tempranas. WSDM proporcionar estndares para la Gestin y Uso de
Servicios Web (MOWS y MUWS respectivamente).
Acuerdos a Nivel de Servicio y Negocio. El grupo de trabajo WSA de W3C ha
identificado esta necesidad pero todava no existe ninguna propuesta en este mbito.
WS-Security. Existen algunos elementos de WS-Security que no se han publicado
todava (WS-Authorization y WS-Privacy).

4.3 Desarrollo de Propuestas Alternativas


El grado de consenso de la industria en el mbito de los protocolos de los Servicios Web es
elevado (al menos en lo que respecta a la infraestructura bsica). Aunque se han desarrollado
propuestas alternativas en algunas reas, la formacin de grupos de trabajo en W3C u OASIS
ha llevado muchas veces a la convergencia de todas las partes interesadas.

12

Vicente Pelechano

Existen actualmente algunas reas donde se mantienen propuestas alternativas, por ejemplo
en Reliable Messaging, Orchestration, y Transaction Coordination. Estas alternativas se han
visto reflejadas por grupos de empresas como IBM/Microsoft por una parte y Sun/Oracle por
la otra.
Sin embargo, este ao Microsoft y Sun han iniciado un acercamiento y una mayor
cooperacin en el mbito de los Servicios Web. Un ejemplo de esta situacin ha sido que Sun
se ha unido a BEA, IBM, Microsoft y SAP AG para proponer la ltima versin de WSAddressing al W3C. Lo mismo ha ocurrido con especificaciones como WS-MessageDelivery,
con la actualizacin de WS-Eventing permitiendo la interoperabilidad de sta con
especificaciones como WS-Notification.
Este tipo de movimientos son bienvenidos y auguran una colaboracin futura en aspectos
como la coordinacin, las transacciones y la coreografa.
Tambin ha existido un solapamiento entre los Servicios Web y la iniciativa ebXML.
ebXML utiliza SOAP a nivel de transporte, pero tiene su propio registro y orquestacinAunque ebXML es un estndar aprobado y robusto, su aplicabilidad es ms reducida que los
Servicios Web. ebXML se considera una evolucin de EDI cuya principal orientacin el
dominio de los negocios electrnicos B2B. Los Servicios Web estn diseados para dar soporte
a un mayor nmero de requisitos y escenarios de uso, por lo que ebXML probablemente
evolucionar para adoptar los protocolos adicionales de los Servicios Web cuando stos
maduren y sean aprobados. Parte del trabajo del grupo ebSOA de OASIS es evolucionar la
arquitectura ebXML y dirigir la transicin hacia la adopcin de ms protocolos basados en los
Servicios Web.

4.3 Proceso de Estandarizacin


Aunque la propuesta de protocolos para Servicios Web ha sido un rea de trabajo muy
movida y con un crecimiento rapidsimo, su transicin a estndares abiertos es inevitablemente
mucho ms lenta. Existen muy pocos protocolos finalizando su proceso de estandarizacin de
forma adecuada. En la definicin de estndares existen principalmente dos grupos implicados
en el mbito de los Servicios Web:
World Wide Web Consortium (W3C) - http://www.w3c.org/
Organization for the Advancement of Structured Information Standards (OASIS) http://www.oasis-open.org/

4.4 WS-Interoperability (WS-I)


WS-I (http://www.ws-i.org/) es un grupo de la industria abierto que se creo en 2002 para
promover la interoperabilidad de los Servicios Web a travs de plataformas, sistemas
operativos y lenguajes de programacin. WS-I juega un papel muy til dando soluciones a
algunas de las siguientes cuestiones:
Las especificaciones estndares estn siempre abiertas a interpretaciones. WS-I
proporciona guas y herramientas para ayudar a medir el grado de fidelidad o ajuste
de las implementaciones al estndar y permitir su interoperabilidad
Como lo estndares evolucionan, es necesario entender qu difiere entre versiones
para poder interoperar.
Se publicarn perfiles (profiles) de interoperabilidad que reflejen los requisitos que
deben cumplir las implementaciones de los estndares.

4.5 Adopcin
El estado actual de adopcin de los protocolos presentados se puede ver en la figura 9.

Servicios Web. Estndares, Extensiones y Perspectivas de Futuro

13

Figura 9. Adopcin de los Protocolos


Los niveles de adopcin significan:

Specification: Slo existe una especificacin en formato borrador. Cualquier uso


requiere codificacin manual.

Experimentation: algunos vendedores proporcionan implementaciones


tempranas que permiten la experimentacin, pero no se recomiendan para el uso
en produccin.

Early adoption: Existen implementaciones robustas y el protocolo est


estandarizado o finalizando su estandarizacin, lo que recomienda su uso por las
organizaciones.

Mainstream: el estndar se ha ratificado o existe una adopcin de facto a gran


escala
Por ejemplo, Microsoft proporciona WSE (Web Services Extensions) que son
implementaciones de las especificaciones WS-Security (estndar de OASIS, 2004), WS-Policy
(Experimentation), WS-SecurityPolicy, WS-Trust, WS-SecureConversation y WS-Addressing
(Specification).

Referencias

1.

Web Services Architecture, W3C Working Group Note, D. Booth, H. Haas, F. McCabe, E.
Newcomer,
M.
Champion,
C.
Ferris,
D.
Orchard,
11
February
2004
(http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/.)
Web Services Architecture Usage Scenarios, W3C Working Group Note, H. He, H. Haas, D. Orchard,
11 February 2004 (http://www.w3.org/TR/2004/NOTE-ws-arch-scenarios-20040211/.)
E. Newcomer, Understanding Web services: XML, WSDL, SOAP, and UDDI, Addison-Wesley,
Boston, Mass., May 2002.
F. Curbera et. al., Unraveling the Web Services Web: An Introduction to SOAP, WSDL, and
UDDI, IEEE Internet Computing, vol. 6, no. 2, March/April 2002, pp. 86-93.
D. Chapell. Distributed Computing Tomorrow: Web Services and Beyond, Microsoft Tech-Ed
2002, Barcelona.
S. Vinoski, Web Services Interaction Models Part 1: Current Practice, IEEE Internet Computing,
vol. 6, no. 3, May/June 2002, pp. 89-91.
B.
Sleeper.
The
five
missing
pieces
of
SOA.
September
10,
2004
http://www.infoworld.com/article/04/09/10/37FEwebservmiddle_1.html
L. Wilkes. The Web Services Protocol Stack en CBDI Web Services Roadmap - Guiding the
Transition to Web Service and SO. http://roadmap.cbdiforum.com/reports/protocols/

2.
3.
4.
5.
6.
7.
8.

Vous aimerez peut-être aussi