Hablamos sobre la evolucion de los servicios Web y hacia donde se encaminan los avances del futuro.
El mundo de los servicios Web está evolucionando a gran velocidad. En los últimos tres años, las especificaciones de los Servicios Web han sido definidas, refinadas y a veces, criticadas; se han lanzado kits de herramientas de servicios Web y los desarrolladores los han utilizado para construir sistemas, y los fabricantes han trabajado para garantizar la interoperabilidad. Al igual que con la infraestructura Web clásica, se está desarrollando e implantando tecnologías de servicios Web en paralelo, progresando a través de un ciclo de realimentación positivo. Aunque los servicios Web han progresado mucho en los últimos tres años, el trabajo sobre la plataforma continúa. Si vamos a desarrollar sistemas basados en servicios Web, es importante comprender dónde está la plataforma hoy y cual va a ser el futuro.
1 Servicios Web hoy
Actualmente, la plataforma de servicios Web ha sido desarrollada lo suficiente para crear aplicaciones distribuidas que se comunican enviando mensajes SOAP sobre HTTP. Esto no significa que no existan herramientas o marcos de trabajo de servicios Web que puedan hacer más cosas (por ejemplo, enviar mensajes SOAP sobre SMTP. Sin embargo, la mensajería basada en HTTP es la única opción de comunicación más generalmente soportada. La mayoría de las herramientas de Servicios Web mapea mensajes SOAP a invocaciones de métodos en objetos. Algunas proporcionan además un acceso directo al cuerpo de los mensajes SOAP, exponiéndolos como XML. Servicios de alto nivel como la seguridad se implementan generalmente de modo ad hoc, típicamente en el nivel de los protocolos de transporte.
La mayoría de los kits de herramientas de Servicios Web interoperan bastante bien, especialmente si nos limitamos a formatos de mensajes relativamente sencillos. Los miembros de la comunidad SOAPBuilders han realizado grandes mejoras sobre interoperabilidad organizando evaluaciones de SOAP y WSDL, y reuniéndose periódicamente para garantizar que sus kits de herramientas trabajan conjuntamente.
Muchos de los trabajos de la comunidad SOAPBuilders han sido necesarios en relación con varios aspectos de las especificaciones SOAP 1.1 y WSDL 1.1. El W3C dispone de grupos de trabajo focalizados en refinar ambas especificaciones, lo que debería aportar mejoras sustanciales. El grupo XML Protocol Working Group está trabajando en la especificación SOAP 1.2 mientras que el grupo Web Services Description Working Group está creando la especificación WSDL 1.2. Mientras tanto, IETF y OASIS están también trabajando en estandarizar especificaciones de servicios Web, incluyendo DIME y WS-Security.
Mientras que el trabajo en el W3C se centra en las nuevas versiones de las especificaciones del núcleo de los servicios Web, existe otra organización independiente que está prestando más atención a la interoperabilidad. La organización Web Services Interoperability Organization (WS-I) tiene como objetivo definir mejores prácticas para garantizar la interoperabilidad de los servicios Web. El grupo WS-I Basic Profile Working Group está actualmente desarrollando un conjunto de recomendaciones sobre cómo utilizar los protocolos básicos de los servicios Web como SOAP 1.1 y WSDL 1.1 para maximizar la interoperabilidad.
2 Servicios Web en el futuro
El trabajo sobre la plataforma de servicios Web continuará en el futuro, y aparecerán mejoras en tres áreas fundamentales. En primer lugar, se añadirán servicios de más alto nivel. Todo el mundo está de acuerdo en que debe existir un modo estándar de asegurar servicios Web, rutear mensajes, garantizar una entrega fiable de mensajes, definir semántica transaccional, etc. Estas características de propósito general se expanden más allá de los dominios del problema y no hay ninguna razón por la que cada desarrollador de servicios Web deba implementarlas individualmente. Microsoft, IBM y otros están realizando mucho trabajo en estas áreas. La iniciativa Global XML Web Service Architecture (GXA) define un conjunto de especificaciones sobre cómo implementar estos servicios de infraestructura en términos de mensajes SOAP (por ejemplo, de un modo neutral respecto del protocolo de transporte.
En segundo lugar, seguirán estandarizándose especificaciones. El ciclo de vida de las especificaciones de servicios Web típicamente progresa desde una propuesta hasta un estándar de facto y desde éste hasta un estándar real. Con SOAP 1.2 y WSDL 1.2 las peculiaridades finales están siendo elaboradas de las especificaciones SOAP y WSDL y algunas de las especificaciones de servicios de mayor nivel, como WS-Security, ya están en el periodo "de facto" en el proceso de estandarización. Las empresas siguen proponiendo nuevas especificaciones como añadidos a la plataforma de servicios Web y la industria en su conjunto necesitará acordar cuáles adoptar. Esas especificaciones necesitarán a continuación ser estandarizadas.
En tercer lugar, los kits de herramientas y marcos de trabajo seguirán mejorando. Además de servicios de más alto nivel como la seguridad y los objetos adjuntos, se añadirá soporte para protocolos de transporte alternativos como SMTP o TCP. De modo más importante, los modelos de programación migrarán desde los servicios de tipo RPC hacia servicios centrados en documentos, para promover un acoplamiento débil. Todos estos cambios ocurrirán en paralelo, mientras los desarrolladores continúan desarrollando e implantando sistemas basados en servicios Web.
3 Avances de futuro
Llegados a este punto, estaremos preguntándonos cómo podemos utilizar los servicios Web cuando la plataforma todavía está evolucionando. Las herramientas y marcos de trabajo de los servicios Web actuales proporcionan suficiente funcionalidad básica para desarrollar interesantes aplicaciones distribuidas que envían mensajes SOAP sobre HTTP. Algunos servicios de mayor nivel como WS-Security están empezando a cuajar con el soporte de diversas herramientas nuevas como el kit Web Services Development Kit. Otros servicios están todavía en fase de desarrollo preliminar a medida que las especificaciones se van revisando y las primeras implementaciones exponen áreas en las que las especificaciones necesitan solidificarse. Mientras tanto, podemos apoyarnos en mecanismos HTTP tradicionales para implementar seguridad y demás características.
Si queremos desarrollar servicios Web utilizando herramientas de Microsoft, tenemos varias opciones. Si todavía estamos utilizando Visual Studio 6.0 o algún otro entorno de desarrollo que no soporta el desarrollo de código gestionado, podemos crear y consumir servicios Web utilizando el kit de herramientas SOAP Toolkit. Si estamos utilizando .NET, podemos focalizarnos en los métodos Web de ASP.NET (a esto hace referencia la mayor parte de la documentación de .NET sobre los servicios Web). En cualquier caso, podemos aprender tanto como queramos sobre cómo funcionan los protocolos de mensajería y metadatos de los servicios Web. Cuanto más comprendamos la fontanería, más fácil será desarrollar nuestros propios servicios y utilizar servicios desarrollados por los demás.
También podemos experimentar con las nuevas especificaciones. La versión preliminar del kit Microsoft WSDK Technology Preview proporciona un soporte preliminar para las especificaciones WS-Security, WS-Routing y DIME. Podemos también implementar especificaciones por nosotros mismos, tanto utilizando extensiones sobre uno de los marcos de trabajo o kits de herramientas (por ejemplo, SoapExtensions en ASP.NET), como crear nuestra propia pila SOAP utilizando XML plano y las APIs HTTP. Esta opción no es para todo el mundo, pero si tenemos tiempo y recursos, obtendremos pronto una avanzada funcionalidad. Además, contribuiremos al desarrollo de la plataforma. El entendimiento colectivo de SOAP Y WSDL se mejoró sustancialmente gracias al intento de implementación de sistemas basados en ambos estándares por parte de múltiples usuarios. Cuanto más estrechamente trabajen los usuarios con las nuevas especificaciones, mejor resultará la plataforma de servicios Web global.
1 Servicios Web hoy
Actualmente, la plataforma de servicios Web ha sido desarrollada lo suficiente para crear aplicaciones distribuidas que se comunican enviando mensajes SOAP sobre HTTP. Esto no significa que no existan herramientas o marcos de trabajo de servicios Web que puedan hacer más cosas (por ejemplo, enviar mensajes SOAP sobre SMTP. Sin embargo, la mensajería basada en HTTP es la única opción de comunicación más generalmente soportada. La mayoría de las herramientas de Servicios Web mapea mensajes SOAP a invocaciones de métodos en objetos. Algunas proporcionan además un acceso directo al cuerpo de los mensajes SOAP, exponiéndolos como XML. Servicios de alto nivel como la seguridad se implementan generalmente de modo ad hoc, típicamente en el nivel de los protocolos de transporte.
La mayoría de los kits de herramientas de Servicios Web interoperan bastante bien, especialmente si nos limitamos a formatos de mensajes relativamente sencillos. Los miembros de la comunidad SOAPBuilders han realizado grandes mejoras sobre interoperabilidad organizando evaluaciones de SOAP y WSDL, y reuniéndose periódicamente para garantizar que sus kits de herramientas trabajan conjuntamente.
Muchos de los trabajos de la comunidad SOAPBuilders han sido necesarios en relación con varios aspectos de las especificaciones SOAP 1.1 y WSDL 1.1. El W3C dispone de grupos de trabajo focalizados en refinar ambas especificaciones, lo que debería aportar mejoras sustanciales. El grupo XML Protocol Working Group está trabajando en la especificación SOAP 1.2 mientras que el grupo Web Services Description Working Group está creando la especificación WSDL 1.2. Mientras tanto, IETF y OASIS están también trabajando en estandarizar especificaciones de servicios Web, incluyendo DIME y WS-Security.
Mientras que el trabajo en el W3C se centra en las nuevas versiones de las especificaciones del núcleo de los servicios Web, existe otra organización independiente que está prestando más atención a la interoperabilidad. La organización Web Services Interoperability Organization (WS-I) tiene como objetivo definir mejores prácticas para garantizar la interoperabilidad de los servicios Web. El grupo WS-I Basic Profile Working Group está actualmente desarrollando un conjunto de recomendaciones sobre cómo utilizar los protocolos básicos de los servicios Web como SOAP 1.1 y WSDL 1.1 para maximizar la interoperabilidad.
2 Servicios Web en el futuro
El trabajo sobre la plataforma de servicios Web continuará en el futuro, y aparecerán mejoras en tres áreas fundamentales. En primer lugar, se añadirán servicios de más alto nivel. Todo el mundo está de acuerdo en que debe existir un modo estándar de asegurar servicios Web, rutear mensajes, garantizar una entrega fiable de mensajes, definir semántica transaccional, etc. Estas características de propósito general se expanden más allá de los dominios del problema y no hay ninguna razón por la que cada desarrollador de servicios Web deba implementarlas individualmente. Microsoft, IBM y otros están realizando mucho trabajo en estas áreas. La iniciativa Global XML Web Service Architecture (GXA) define un conjunto de especificaciones sobre cómo implementar estos servicios de infraestructura en términos de mensajes SOAP (por ejemplo, de un modo neutral respecto del protocolo de transporte.
En segundo lugar, seguirán estandarizándose especificaciones. El ciclo de vida de las especificaciones de servicios Web típicamente progresa desde una propuesta hasta un estándar de facto y desde éste hasta un estándar real. Con SOAP 1.2 y WSDL 1.2 las peculiaridades finales están siendo elaboradas de las especificaciones SOAP y WSDL y algunas de las especificaciones de servicios de mayor nivel, como WS-Security, ya están en el periodo "de facto" en el proceso de estandarización. Las empresas siguen proponiendo nuevas especificaciones como añadidos a la plataforma de servicios Web y la industria en su conjunto necesitará acordar cuáles adoptar. Esas especificaciones necesitarán a continuación ser estandarizadas.
En tercer lugar, los kits de herramientas y marcos de trabajo seguirán mejorando. Además de servicios de más alto nivel como la seguridad y los objetos adjuntos, se añadirá soporte para protocolos de transporte alternativos como SMTP o TCP. De modo más importante, los modelos de programación migrarán desde los servicios de tipo RPC hacia servicios centrados en documentos, para promover un acoplamiento débil. Todos estos cambios ocurrirán en paralelo, mientras los desarrolladores continúan desarrollando e implantando sistemas basados en servicios Web.
3 Avances de futuro
Llegados a este punto, estaremos preguntándonos cómo podemos utilizar los servicios Web cuando la plataforma todavía está evolucionando. Las herramientas y marcos de trabajo de los servicios Web actuales proporcionan suficiente funcionalidad básica para desarrollar interesantes aplicaciones distribuidas que envían mensajes SOAP sobre HTTP. Algunos servicios de mayor nivel como WS-Security están empezando a cuajar con el soporte de diversas herramientas nuevas como el kit Web Services Development Kit. Otros servicios están todavía en fase de desarrollo preliminar a medida que las especificaciones se van revisando y las primeras implementaciones exponen áreas en las que las especificaciones necesitan solidificarse. Mientras tanto, podemos apoyarnos en mecanismos HTTP tradicionales para implementar seguridad y demás características.
Si queremos desarrollar servicios Web utilizando herramientas de Microsoft, tenemos varias opciones. Si todavía estamos utilizando Visual Studio 6.0 o algún otro entorno de desarrollo que no soporta el desarrollo de código gestionado, podemos crear y consumir servicios Web utilizando el kit de herramientas SOAP Toolkit. Si estamos utilizando .NET, podemos focalizarnos en los métodos Web de ASP.NET (a esto hace referencia la mayor parte de la documentación de .NET sobre los servicios Web). En cualquier caso, podemos aprender tanto como queramos sobre cómo funcionan los protocolos de mensajería y metadatos de los servicios Web. Cuanto más comprendamos la fontanería, más fácil será desarrollar nuestros propios servicios y utilizar servicios desarrollados por los demás.
También podemos experimentar con las nuevas especificaciones. La versión preliminar del kit Microsoft WSDK Technology Preview proporciona un soporte preliminar para las especificaciones WS-Security, WS-Routing y DIME. Podemos también implementar especificaciones por nosotros mismos, tanto utilizando extensiones sobre uno de los marcos de trabajo o kits de herramientas (por ejemplo, SoapExtensions en ASP.NET), como crear nuestra propia pila SOAP utilizando XML plano y las APIs HTTP. Esta opción no es para todo el mundo, pero si tenemos tiempo y recursos, obtendremos pronto una avanzada funcionalidad. Además, contribuiremos al desarrollo de la plataforma. El entendimiento colectivo de SOAP Y WSDL se mejoró sustancialmente gracias al intento de implementación de sistemas basados en ambos estándares por parte de múltiples usuarios. Cuanto más estrechamente trabajen los usuarios con las nuevas especificaciones, mejor resultará la plataforma de servicios Web global.
Benjamín González C.
Ingeniero de Sistemas