Histórico

Servicios Web: sobre las bases de XML

Poco a poco, los responsables de TI van siendo conscientes de la importancia de los servicios Web, y de sus dimensiones reales para los negocios. Ha llegado el momento de poner en marcha los estándares para crear un nuevo entorno de negocios electrónicos ágiles e integradores. XML es la pieza fundamental.

No hay que fiarse al cien por cien del marketing: en los servicios Web el futuro aún no es hoy. De entrada, y en pocas palabras, los servicios Web son middleware basado en XML que representan la próxima generación de la programación orientada a objetos para comercio electrónico entre empresas. Common Object Request Broker Architecture (CORBA) y Distributed Component Model no lo consiguieron y EDI resultaba demasiado caro y especializado. Todo está en el midleware. No es sexy, pero es esencial.
En términos coloquiales, los servicios Web pueden ser considerados como “trozos” de código reutilizables que permiten a dos o más aplicaciones basadas en Web hablar entre sí. Este código podría ser empleado para construir nuevas aplicaciones, o para “envolver” aplicaciones heredadas. Implementando servicios Web en medio de los procesos –o funcionando como una aplicación independiente– las aplicaciones basadas en Web pueden compartir datos entre sí con independencia de lenguajes de programación o plataformas subyacentes.
Y como todos los enfoques orientados a objetos, los servicios Web han de basarse en un marco de referencia estandarizado para ser interoperativos. El primer conjunto de normas, actualmente en desarrollo, cubre el modo en que dichos servicios “hablan” entre sí, cómo describen qué funciones pueden efectuar y cómo se avisan entre ellos de su presencia.
Con estos servicios, el coste que representa la integración de aplicaciones sobre la Web debería reducirse considerablemente. Y todo indica que será sí. La integración es el corazón de los servicios Web; sólo de esa forma se puede ahorrar tiempo y dinero a la hora de realizar proyectos. Pero, por sí mismos, los servicios Web se reducen a integrar aplicaciones y datos. Para alcanzar un verdadero mundo sin fronteras y siempre interconectado son imprescindibles los estándares. Sin ellos, los servicios Web pronto se convertirán en la última generación de vaporware. Y los fabricantes lo saben.

Construyendo los estándares
La fundación de todos los estándares de servicios Web es XML, de donde parten tres normas críticas todavía en desarrollo: Simple Object Access Protocol (SOAP), Web Service Description Language (WSDL) y Universal Description, Discovery and Integration (UDDI).
SOAP es el protocolo de mensajes que permite a los servicios Web hablar entre sí. Un grupo de firmas –IBM y Microsoft entre ellas- crearon la versión 1.1 en abril de 2000, y a finales de ese año el World Wide Web Consortium (W3C) formalizó su proceso de normalización con la creación del XML Protocol Working Group. Y el pasado mes de julio publicó el primer borrador de trabajo SOAP 1.2.
WDSL, remitido en enero a W3C, permite a un servicio Web describir qué puede hacer, qué mensajes acepta y qué respuestas devuelve.
UDDI, finalmente, es un repositorio para localizar servicios Web. La versión 2 apareció en junio de 2001, y la tercera y ultima verá la luz este año. Sus creadores (Microsoft, IBM y Ariba) ya están efectuando pruebas de implementación.
Lo que falta aún por conseguir son estándares que aseguren la fiabilidad y el encaminamiento de los mensajes, las transacciones y workflow, y la seguridad. La seguridad es quizá la principal cuestión, especialmente cuando se comparte el código ejecutable.
En paralelo a estos esfuerzos de W3C, la Organization for the Advancement of Structured Information Standards está trabajando en ebXML, que tiene sus raíces en EDI, y en XML-RPC, esencialmente un homólogo ligero de SOAP.
Todo indica que todos estos desarrollos acabarán convergiendo. Pero los responsables de TI deberían observarlos muy de cerca para asegurarse de que los proclamados estándares lo son realmente, o no pasan de una edición renovada de las eternas luchas entre ingenieros y fabricantes. Y si hay que presionar a los suministradores para que sigan el camino común, adelante.

Duelo de titanes
Para empezar a introducirse en el mundo de los servicios Web lo primero es elegir una plataforma y herramientas de desarrollo.
Hay varias opciones. En este mercado hay varias firmas que ofrecen soluciones más o menos globales pero la elección básica se sigue reduciendo al lenguaje Java de Sun y su plataforma genérica Java 2 Platform Enterprise Edition (J2EE), o el lenguaje C# y la plataforma .Net de Microsoft.
Microsoft ha sido criticado por hacer .Net demasiado propietario, pero en su defensa hay que decir que la compañía ha adaptado su plataforma a una gran variedad de lenguajes diferentes. Por lo que a Sun se refiere, lo cierto es que Java correrá sobre una gran diversidad de plataformas. De hecho, varios fabricantes como IBM y BEA están ya basando sus ofertas en J2EE.
Lo esencial es que los servicios Web han de ser escritos para ser ejecutados en un entorno run-time determinado. Los escritos para .Net y dispositivos run-time de Microsoft no se ejecutarán en una plataforma J2EE. Sin embargo, gracias a SOAP, los servicios que corran sobre las dos plataformas podrán hablar entre sí.
Esto no impide, no obstante, la lucha comercial. No en vano Microsoft trata de conseguir el favor de sus seis millones de desarrolladores hacia C# y Visual Studio.Net. Además, ha puesto la marca .Net a nueve servidores para crear una infraestructura back-end de servicios Web. Y es que, como el propio Microsoft reconoce, los fabricantes no competirán en el ámbito de API, sino por los paquetes globales: herramientas de desarrollo, servidores y sistemas operativos.
Sun está desarrollando Sun Open Net Enviroment, una combinación del servidor de aplicación de iPlanet y de las herramientas de desarrollo Forte de la firma. Además, añade soporte SOAP y permitirá la conversión XML/Java con JaxPacks. La estrategia de la compañía descansa, pues, en ofrecer arquitecturas abiertas al tiempo que se compite en la implementación. Para ello, Sun planea además desarrollar servicios Web “inteligentes” que comprendan que están haciendo, para quién y por qué.
IBM, por su parte, está construyendo su estrategia Dynamic E-Business alrededor de WebSphere, DB2, Tivoli y Lotus. Además de los estándares, Tivoli contribuirá con funciones de seguridad y gestión, y Lotus diversas herramientas de colaboración, mensajería instantánea entre ellas. El compromiso de IBM con Java le está haciendo ignorar completamente C# .
BEA está haciendo una buena faena con su servidor de aplicaciones WebLogic y sus herramientas E-Business Productivity. Y Oracle ha construido su Oracle Dynamic Services (ODS) alrededor del recientemente lanzado Oracle 9i Application Server. ODS viene empaquetado con Internet Developer’s Suite de la compañía, que soporta tanto Java como XML usando Jdeveloper. También ha añadido soporte de SOAP.
HP, finalmente, puso en febrero su estrategia en servicios Web en manos de su servidor de aplicaciones NetAction, obtenido con la compra de Bluestone y de OpenView para la gestión de sistemas. En abril, añadió también herramientas de desarrollo mediante una alianza con WebGain.
Gar

Revista Digital

Revistas Digitales

DealerWorld Digital

 



Otros Contenidos

juniper Fabricantes
Registro:

Eventos: