Visión general
La programación basada en componentes se ha hecho más popular que nunca. Hoy en día, casi no hay aplicación que no utilice componentes de algún tipo, normalmente de distintos proveedores. A medida que las aplicaciones se han vuelto más sofisticadas, también ha crecido la necesidad de aprovechar componentes distribuidos en máquinas remotas.
Un ejemplo de aplicación basada en componentes es una solución de comercio electrónico de extremo a extremo. Una aplicación de comercio electrónico que reside en una granja Web necesita enviar pedidos a una aplicación de planificación de recursos empresariales (ERP) back-end. En muchos casos, la aplicación ERP reside en un hardware diferente y puede ejecutarse en un sistema operativo distinto.
El Microsoft Distributed Component Object Model (DCOM), una infraestructura de objetos distribuidos que permite a una aplicación invocar componentes del Component Object Model (COM) instalados en otro servidor, ha sido portado a varias plataformas distintas de Windows. Pero DCOM nunca ha tenido una gran aceptación en estas plataformas, por lo que rara vez se utiliza para facilitar la comunicación entre ordenadores Windows y no Windows. Los proveedores de software ERP suelen crear componentes para la plataforma Windows que se comunican con el sistema back-end a través de un protocolo propietario.
Algunos servicios utilizados por una aplicación de comercio electrónico pueden no residir en absoluto en el centro de datos. Por ejemplo, si la aplicación de comercio electrónico acepta el pago con tarjeta de crédito de los bienes adquiridos por el cliente, debe solicitar los servicios del banco comercial para procesar la información de la tarjeta de crédito del cliente. Pero a efectos prácticos, DCOM y las tecnologías relacionadas, como CORBA y Java RMI, se limitan a aplicaciones y componentes instalados en el centro de datos corporativo. Dos razones principales para ello son que, por defecto, estas tecnologías aprovechan protocolos propietarios y que estos protocolos están inherentemente orientados a la conexión.
Los clientes que se comunican con el servidor a través de Internet se enfrentan a numerosas barreras potenciales para comunicarse con el servidor. En todo el mundo, los administradores de red preocupados por la seguridad han implementado enrutadores y cortafuegos corporativos para impedir prácticamente cualquier tipo de comunicación a través de Internet. A menudo se necesita un acto de Dios para que un administrador de red abra los puertos más allá del mínimo.
Si tienes la suerte de que un administrador de red abra los puertos adecuados para soportar tu servicio, lo más probable es que tus clientes no tengan la misma suerte. Por eso, los protocolos propietarios como DCOM, CORBA y Java RMI no son prácticos para Internet.
El otro problema, como ya he dicho, de estas tecnologías es que están intrínsecamente orientadas a la conexión y, por tanto, no pueden gestionar las interrupciones de la red con elegancia. Como Internet no está bajo tu control directo, no puedes hacer suposiciones sobre la calidad o fiabilidad de la conexión. Si se produce una interrupción en la red, la siguiente llamada que el cliente haga al servidor podría fallar.
La naturaleza orientada a la conexión de estas tecnologías también dificulta la construcción de las infraestructuras de carga equilibrada necesarias para lograr una alta escalabilidad. Una vez cortada la conexión entre el cliente y el servidor, no se puede simplemente dirigir la siguiente petición a otro servidor.
Los desarrolladores han intentado superar estas limitaciones aprovechando un modelo llamado sin estado programación, pero han tenido un éxito limitado porque las tecnologías son bastante pesadas y encarecen el restablecimiento de la conexión con un objeto remoto.
Dado que el procesamiento de la tarjeta de crédito de un cliente lo realiza un servidor remoto en Internet, DCOM no es ideal para facilitar la comunicación entre el cliente de comercio electrónico y el servidor de procesamiento de tarjetas de crédito. Como en una solución ERP, a menudo se instala un componente de terceros en el centro de datos del cliente (en este caso, por el proveedor de la solución de procesamiento de tarjetas de crédito). Este componente sirve como poco más que un proxy que facilita la comunicación entre el software de comercio electrónico y el banco comercial a través de un protocolo propietario.
¿Ve algún patrón? Debido a las limitaciones de las tecnologías existentes para facilitar la comunicación entre sistemas informáticos, los proveedores de software han recurrido a menudo a crear su propia infraestructura. Esto significa que los recursos que podrían haberse utilizado para añadir una funcionalidad mejorada al sistema ERP o al sistema de procesamiento de tarjetas de crédito se han dedicado, en cambio, a escribir protocolos de red propietarios.
En un esfuerzo por soportar mejor estos escenarios de Internet, Microsoft adoptó inicialmente la estrategia de aumentar sus tecnologías existentes, incluyendo COM Internet Services (CIS), que permite establecer una conexión DCOM entre el cliente y el componente remoto a través del puerto 80. Por diversas razones, CIS no fue ampliamente aceptado.
Estaba claro que se necesitaba un nuevo enfoque. Así que Microsoft decidió abordar el problema desde la base. Veamos algunos de los requisitos que debía cumplir la solución para tener éxito.
- Interoperabilidad El servicio remoto debe poder ser consumido por clientes de otras plataformas.
- Facilidad de uso de Internet La solución debería funcionar bien para dar soporte a clientes que acceden al servicio remoto desde Internet.
- Interfaces fuertemente tipadas No debe haber ambigüedad sobre el tipo de datos enviados y recibidos de un servicio remoto. Además, los tipos de datos definidos por el servicio remoto deberían corresponderse razonablemente bien con los definidos por la mayoría de los lenguajes de programación procedimentales.
- Capacidad para aprovechar las normas de Internet existentes La implementación del servicio remoto debe aprovechar al máximo los estándares de Internet existentes y evitar reinventar soluciones a problemas ya resueltos. Una solución basada en estándares de Internet ampliamente adoptados puede aprovechar los conjuntos de herramientas existentes y los productos creados para la tecnología.
- Compatible con cualquier idioma La solución no debe estar estrechamente vinculada a un lenguaje de programación concreto. Java RMI, por ejemplo, está estrechamente vinculado al lenguaje Java. Sería difícil invocar la funcionalidad de un objeto Java remoto desde Visual Basic o Perl. Un cliente debe poder implementar un nuevo servicio web o utilizar un servicio web existente independientemente del lenguaje de programación en el que se haya escrito el cliente.
- Compatibilidad con cualquier infraestructura de componentes distribuidos La solución no debe estar estrechamente vinculada a una infraestructura de componentes concreta. De hecho, no debería ser necesario adquirir, instalar o mantener una infraestructura de objetos distribuidos sólo para crear un nuevo servicio remoto o consumir un servicio existente. Los protocolos subyacentes deben facilitar un nivel básico de comunicación entre las infraestructuras de objetos distribuidos existentes, como DCOM y CORBA.
Dado el título de este libro, no debería sorprender que la solución creada por Microsoft se conozca como Servicios web. Un servicio Web expone una interfaz para invocar una actividad concreta en nombre del cliente. Un cliente puede acceder al servicio Web mediante el uso de estándares de Internet.
Elementos básicos de los servicios web
El siguiente gráfico muestra los elementos básicos necesarios para facilitar la comunicación remota entre dos aplicaciones.
Analicemos el propósito de cada uno de estos módulos. Como muchos lectores están familiarizados con DCOM, también mencionaré el equivalente en DCOM de cada building block.
- Descubrimiento La aplicación cliente que necesita acceder a la funcionalidad expuesta por un servicio Web necesita una forma de resolver la ubicación del servicio remoto. Esto se consigue a través de un proceso generalmente denominado descubrimiento. El descubrimiento puede facilitarse a través de un directorio centralizado, así como por métodos más ad hoc. En DCOM, el Service Control Manager (SCM) proporciona servicios de descubrimiento.
- Descripción Una vez resuelto el punto final de un determinado servicio web, el cliente necesita información suficiente para interactuar correctamente con él. La descripción de un servicio Web abarca metadatos estructurados sobre la interfaz que se pretende que consuma una aplicación cliente, así como documentación escrita sobre el servicio Web que incluya ejemplos de uso. Un componente DCOM expone metadatos estructurados sobre sus interfaces a través de una biblioteca de tipos (typelib). Los metadatos de la biblioteca de tipos de un componente se almacenan en un formato binario propietario y se accede a ellos a través de una interfaz de programación de aplicaciones (API) propietaria.
- Formato del mensaje Para intercambiar datos, un cliente y un servidor tienen que acordar una forma común de codificar y formatear los mensajes. Una forma estándar de codificar los datos garantiza que los datos codificados por el cliente serán interpretados correctamente por el servidor. En DCOM, los mensajes enviados entre un cliente y un servidor tienen el formato definido por el protocolo DCOM Object RPC (ORPC).
Sin una forma estándar de formatear los mensajes, desarrollar un conjunto de herramientas para abstraer al desarrollador de los protocolos subyacentes es prácticamente imposible. La creación de una capa de abstracción entre el desarrollador y los protocolos subyacentes permite al desarrollador centrarse más en el problema empresarial y menos en la infraestructura necesaria para implantar la solución.
- Codificación Los datos transmitidos entre el cliente y el servidor deben codificarse en el cuerpo del mensaje. DCOM utiliza un esquema de codificación binaria para serializar los datos contenidos por los parámetros intercambiados entre el cliente y el servidor.
- Transporte Una vez que el mensaje ha sido formateado y los datos han sido serializados en el cuerpo del mensaje, el mensaje debe ser transferido entre el cliente y el servidor a través de algún protocolo de transporte. DCOM soporta una serie de protocolos propietarios vinculados a una serie de protocolos de red como TCP, SPX, NetBEUI y NetBIOS sobre IPX.
Decisiones sobre el diseño de servicios web
Analicemos algunas de las decisiones de diseño que subyacen a estos componentes básicos de los servicios web.
Elección de protocolos de transporte
El primer paso fue determinar cómo se comunicarían entre sí el cliente y el servidor. El cliente y el servidor pueden residir en la misma LAN, pero el cliente podría comunicarse con el servidor a través de Internet. Por lo tanto, el protocolo de transporte debe ser igualmente adecuado para entornos LAN y para Internet.
Como he mencionado antes, tecnologías como DCOM, CORBA y Java RMI son poco adecuadas para soportar la comunicación entre el cliente y el servidor a través de Internet. Protocolos como el Protocolo de Transferencia de Hipertexto (HTTP) y el Protocolo Simple de Transferencia de Correo (SMTP) son protocolos probados en Internet. HTTP define un patrón de mensajería solicitud/respuesta para enviar una solicitud y obtener una respuesta asociada. SMTP define un protocolo de mensajería enrutable para la comunicación asíncrona. Veamos por qué HTTP y SMTP son adecuados para Internet.
Las aplicaciones Web basadas en HTTP son intrínsecamente apátridas. No dependen de una conexión continua entre el cliente y el servidor. Esto convierte a HTTP en un protocolo ideal para configuraciones de alta disponibilidad, como los cortafuegos. Si el servidor que gestionó la solicitud original del cliente deja de estar disponible, las solicitudes posteriores se pueden dirigir automáticamente a otro servidor sin que el cliente lo sepa ni le importe.
Casi todas las empresas disponen de una infraestructura compatible con SMTP. SMTP es muy adecuado para la comunicación asíncrona. Si el servicio se interrumpe, la infraestructura de correo electrónico gestiona automáticamente los reintentos. Al contrario que con HTTP, puede pasar mensajes SMTP a un servidor de correo local que intentará entregar el mensaje de correo en su nombre.
La otra gran ventaja de HTTP y SMTP es su omnipresencia. Los empleados han llegado a confiar tanto en el correo electrónico como en sus navegadores Web, y los administradores de red se sienten muy cómodos dando soporte a estos servicios. Tecnologías como la traducción de direcciones de red (NAT) y los servidores proxy permiten acceder a Internet a través de HTTP desde redes LAN corporativas que, de otro modo, estarían aisladas. Los administradores a menudo exponen un servidor SMTP que reside dentro del cortafuegos. Los mensajes enviados a este servidor se dirigirán a su destino final a través de Internet.
En el caso del software de procesamiento de tarjetas de crédito, se necesita una respuesta inmediata del banco comercial para determinar si el pedido debe enviarse al sistema ERP. HTTP, con su patrón de mensajes solicitud/respuesta, es muy adecuado para esta tarea.
La mayoría de los paquetes de software ERP no son capaces de gestionar los grandes volúmenes de pedidos que potencialmente pueden generarse desde la aplicación de comercio electrónico. Además, no es imprescindible que los pedidos se envíen al sistema ERP en tiempo real. Por lo tanto, SMTP puede aprovecharse para poner los pedidos en cola de modo que puedan ser procesados en serie por el sistema ERP.
Si el sistema ERP admite transacciones distribuidas, otra opción es aprovechar Microsoft Message Queue Server (MSMQ). Mientras la aplicación de comercio electrónico y el sistema ERP residan en la misma LAN, la conectividad a través de protocolos ajenos a Internet es menos problemática. La ventaja de MSMQ sobre SMTP es que los mensajes pueden colocarse y retirarse de la cola dentro del ámbito de una transacción. Si falla un intento de procesar un mensaje que se ha sacado de la cola, el mensaje volverá automáticamente a la cola cuando se cancele la transacción.
Elegir un esquema de codificación
HTTP y SMTP proporcionan un medio para enviar datos entre el cliente y el servidor. Sin embargo, ninguno de los dos especifica cómo deben codificarse los datos dentro del cuerpo del mensaje. Microsoft necesitaba una forma estándar e independiente de la plataforma para codificar los datos intercambiados entre el cliente y el servidor.
Dado que el objetivo era aprovechar los protocolos basados en Internet, la elección natural era el lenguaje XML (Extensible Markup Language). XML ofrece muchas ventajas, como la compatibilidad entre plataformas, un sistema de tipos común y la compatibilidad con los juegos de caracteres estándar del sector.
Los esquemas de codificación binaria como los utilizados por DCOM, CORBA y Java RMI deben abordar los problemas de compatibilidad entre las distintas plataformas de hardware. Por ejemplo, las distintas plataformas de hardware tienen distintas representaciones binarias internas de los números multibyte. Las plataformas Intel ordenan los bytes de un número multibyte utilizando la convención little endian; muchos procesadores RISC ordenan los bytes de un número multibyte utilizando la convención big endian.
XML evita los problemas de codificación binaria porque utiliza un esquema de codificación basado en texto que aprovecha los conjuntos de caracteres estándar. Además, algunos protocolos de transporte, como SMTP, sólo pueden contener mensajes basados en texto.
Los métodos binarios de codificación, como los utilizados por DCOM y CORBA, son engorrosos y requieren una infraestructura de apoyo para abstraer al desarrollador de los detalles. XML es mucho más ligero y fácil de manejar porque puede crearse y consumirse mediante técnicas estándar de análisis de texto.
Además, existe una gran variedad de analizadores XML que simplifican aún más la creación y el consumo de documentos XML en prácticamente todas las plataformas modernas. XML es ligero y cuenta con un excelente soporte de herramientas, por lo que la codificación XML permite un alcance increíble, ya que prácticamente cualquier cliente de cualquier plataforma puede comunicarse con su servicio web.
Elegir una convención de formato
A menudo es necesario incluir metadatos adicionales en el cuerpo del mensaje. Por ejemplo, es posible que desee incluir información sobre el tipo de servicios que un servicio Web debe proporcionar para satisfacer su solicitud, como el alistamiento en una transacción o información de enrutamiento. XML no proporciona ningún mecanismo para diferenciar el cuerpo del mensaje de sus datos asociados.
Los protocolos de transporte como HTTP proporcionan un mecanismo extensible para los datos de cabecera, pero algunos datos asociados al mensaje pueden no ser específicos del protocolo de transporte. Por ejemplo, el cliente puede enviar un mensaje que necesita ser enrutado a múltiples destinos, potencialmente a través de diferentes protocolos de transporte. Si la información de enrutamiento se colocara en una cabecera HTTP, tendría que ser traducida antes de ser enviada al siguiente intermediario a través de otro protocolo de transporte, como SMTP. Dado que la información de enrutamiento es específica del mensaje y no del protocolo de transporte, debería formar parte del mensaje.
El Protocolo Simple de Acceso a Objetos (SOAP) proporciona un medio independiente del protocolo para asociar la información de cabecera con el cuerpo del mensaje. Cada mensaje SOAP debe definir un sobre. El sobre tiene un cuerpo que contiene la carga útil del mensaje y una cabecera que puede contener metadatos asociados al mensaje.
SOAP no impone restricciones sobre el formato del cuerpo del mensaje. Esta es una preocupación potencial porque sin una forma consistente de codificar los datos, es difícil desarrollar un conjunto de herramientas que te abstraiga de los protocolos subyacentes. Es posible que tenga que dedicar bastante tiempo a ponerse al día sobre la interfaz del servicio Web en lugar de resolver el problema de negocio que tiene entre manos.
Lo que se necesitaba era una forma estándar de dar formato a un mensaje de llamada a procedimiento remoto (RPC) y codificar su lista de parámetros. Esto es exactamente lo que ofrece la Sección 7 de la especificación SOAP. Describe una convención de nomenclatura estándar y un estilo de codificación para los mensajes orientados a procedimientos.
Dado que SOAP proporciona un formato estándar para serializar datos en un mensaje XML, plataformas como ASP.NET y Remoting pueden abstraer los detalles por usted.
Elección de los mecanismos de descripción
SOAP ofrece una forma estándar de dar formato a los mensajes intercambiados entre el servicio web y el cliente. Sin embargo, el cliente necesita información adicional para serializar correctamente la solicitud e interpretar la respuesta. XML Schema proporciona un medio para crear esquemas que pueden utilizarse para describir el contenido de un mensaje.
XML Schema proporciona un conjunto básico de tipos de datos incorporados que pueden utilizarse para describir el contenido de un mensaje. También puede crear sus propios tipos de datos. Por ejemplo, el banco comercial puede crear un tipo de datos complejo para describir el contenido y la estructura del cuerpo de un mensaje utilizado para enviar una solicitud de pago con tarjeta de crédito.
Un esquema contiene un conjunto de definiciones de tipos de datos y elementos. Un servicio web utiliza el esquema no sólo para comunicar el tipo de datos que se espera que contenga un mensaje, sino también para validar los mensajes entrantes y salientes.
Sin embargo, un esquema por sí solo no proporciona información suficiente para describir eficazmente un servicio web. El esquema no describe los patrones de mensajes entre el cliente y el servidor. Por ejemplo, un cliente necesita saber si debe esperar una respuesta cuando se envía un pedido al sistema ERP. Un cliente también necesita saber a través de qué protocolo de transporte espera recibir solicitudes el servicio web. Por último, el cliente debe conocer la dirección de acceso al servicio web.
Esta información la proporciona un documento WSDL (Web Services Description Language). WSDL es un documento XML que describe completamente un servicio web concreto. Herramientas como ASP.NET WSDL.exe y Remoting SOAPSUDS.exe pueden consumir WSDL y crear automáticamente proxies para el desarrollador.
Como ocurre con cualquier componente utilizado para crear software, un servicio web también debe ir acompañado de documentación escrita para los desarrolladores que programen con él. La documentación debe describir lo que hace el servicio Web, las interfaces que expone y algunos ejemplos de cómo utilizarlo. Una buena documentación es especialmente importante si el servicio Web se expone a clientes a través de Internet.
Elección de los mecanismos de descubrimiento
Una vez desarrollado y documentado un servicio web, ¿cómo pueden localizarlo los clientes potenciales? Si el servicio Web está diseñado para ser consumido por un miembro de su equipo de desarrollo, su enfoque puede ser bastante informal, como compartir la URL del documento WSDL con su compañero un par de cubículos más abajo. Pero cuando los clientes potenciales están en Internet, hacer publicidad de su servicio Web de forma eficaz es una historia completamente diferente.
Lo que hace falta es una forma común de anunciar los servicios web. La Descripción, Descubrimiento e Integración Universales (UDDI) ofrece precisamente ese mecanismo. UDDI es un servicio de directorio centralizado estándar del sector que puede utilizarse para anunciar y localizar servicios Web. UDDI permite a los usuarios buscar servicios Web utilizando una serie de criterios de búsqueda, como el nombre de la empresa, la categoría y el tipo de servicio Web.
Los servicios web también pueden anunciarse a través de DISCO, un formato de documento XML propietario definido por Microsoft que permite a los sitios web anunciar los servicios que exponen. DISCO define un protocolo sencillo que facilita un estilo de hiperenlace para localizar recursos. El principal consumidor de DISCO es Microsoft Visual Studio.NET. Un desarrollador puede dirigirse a un servidor web concreto y navegar por los distintos servicios web expuestos por el servidor.
¿Qué le falta a los servicios web?
Es posible que se haya dado cuenta de que algunos elementos clave de una infraestructura de componentes distribuidos no están definidos por los servicios web. Dos de las omisiones más notables son una API bien definida para crear y consumir servicios Web y un conjunto de servicios de componentes, como el soporte para transacciones distribuidas. Analicemos cada una de estas piezas que faltan.
- API específica del servicio web La mayoría de las infraestructuras de componentes distribuidos definen una API para realizar tareas como inicializar el tiempo de ejecución, crear una instancia de un componente y reflejar los metadatos utilizados para describir el componente. Dado que la mayoría de los lenguajes de programación de alto nivel ofrecen cierto grado de interoperabilidad con C, la API suele exponerse como un conjunto plano de firmas de métodos C. RMI llega incluso a vincular estrechamente su API con un único lenguaje de alto nivel, Java.
En un esfuerzo por garantizar que los servicios Web sean independientes del lenguaje de programación, Microsoft ha dejado en manos de los proveedores de software individuales la vinculación del soporte de los servicios Web a una plataforma concreta. Más adelante hablaré de dos implementaciones de servicios Web para la plataforma .NET, ASP.NET y Remoting.
- Servicios por componentes La plataforma de servicios web no proporciona muchos de los servicios que suelen encontrarse en las infraestructuras de componentes distribuidos, como la gestión remota de la vida útil de los objetos, la agrupación de objetos y la compatibilidad con transacciones distribuidas. La implementación de estos servicios se deja en manos de la infraestructura de componentes distribuidos.
Algunos servicios, como la compatibilidad con transacciones distribuidas, pueden introducirse más adelante, a medida que madure la tecnología. Otros, como la agrupación de objetos y posiblemente la gestión del tiempo de vida de los objetos, pueden considerarse un detalle de implementación de la plataforma. Por ejemplo, Remoting define extensiones para dar soporte a la gestión del tiempo de vida de los objetos, y Microsoft Component Services da soporte a la agrupación de objetos.
Resumen
La programación basada en componentes ha demostrado ser una gran ayuda para la productividad de los desarrolladores, pero algunos servicios no pueden ser encapsulados por un componente que resida en el centro de datos del cliente. Las tecnologías heredadas, como DCOM, CORBA y Java RMI, son inadecuadas para permitir a los clientes acceder a servicios a través de Internet, por lo que Microsoft consideró necesario empezar desde abajo y crear un método estándar para acceder a servicios remotos.
Servicios web es un término genérico que describe un conjunto de protocolos y servicios estándar utilizados para facilitar un nivel básico de interoperabilidad entre aplicaciones. El apoyo que han recibido los servicios Web por parte de la industria no tiene precedentes. Nunca antes tantas empresas líderes en tecnología habían apoyado una norma que facilita la interoperabilidad entre aplicaciones, independientemente de la plataforma en la que se ejecuten.
Uno de los factores que contribuyen al éxito de los servicios Web es que se basan en estándares de Internet ya existentes, como XML y HTTP. Como resultado, cualquier sistema capaz de analizar texto y comunicarse a través de un protocolo de transporte estándar de Internet puede comunicarse con un servicio Web. Las empresas también pueden aprovechar la inversión que ya han realizado en estas tecnologías.