Introducción a los servicios web y Microsoft .Net

XSLT, hojas de estilo
Introducción a XML
Curso de Microsoft .NET
Página principal del grupo GeNeura

Introducción: Microsoft y su estrategia de dominación mundial

Cada vez que Microsoft desarrolla un producto nuevo, tiene como objetivo principal acaparar una parte sustancial del mercado al que va dirigido. A Microsoft no le gustan las medias tintas, y si algún producto no tiene éxito, o bien carga todos sus recursos para hacerlo un éxito, o lo abandona.

Microsoft .NET, o dot-Net, , es más que un producto, una nueva estrategia que va a abarcar todos los productos de la Microsoft, desde Office hasta la consola XBox, pasando por su servicio Microsoft network, MSN.

Lo que ocurre es que, como en tantos otros casos, .NET se encuentra dentro de un entorno en el cual hay muchos más productos y aplicaciones. Y que, en este caso, a diferencia de casi todos sus productos anteriores, Microsoft ha abierto hasta cierto punto su entorno, de forma que todo el mundo pueda participar en él.

El entorno dentro del que se encuadra .Net es una internet que está cambiando de ser centrada en las personas, y basada en los contenidos, a estar centrada en las aplicaciones, y basada en los servicios. Estas aplicaciones y servicios forman parte de lo que se llaman servicios web. Trataremos, para empezar, de estos.

Servicios Web

Modelo de capas de los servicios web

Un servicio web es un servicio, con un interfaz definido y conocido, al que se puede acceder a través de internet. Igual que una página web está definida por un URL (Uniform Resource Locator), un servicio web está definido por un URI (Uniform Resource Identification) y por su interfaz, a través del cual se puede acceder a él. Igual que una página web puede ofrecer cotizaciones de la bolsa, un servicio web que haga lo mismo presentará un interfaz para que se pueda acceder fácilmente, una vez que se conozca el interfaz, a la aplicación. De esta forma, las aplicaciones se convierten en clientes que integran servicios web procedentes de diferentes proveedores, y además, se abre la posibilidad de que se cobre por uso del servicio, no por cada copia de la aplicación vendida. Este es uno de los aspectos que más gusta a Microsoft: la posibilidad de acabar de una vez por todas con la piratería, a base de alojar partes importantes de las aplicaciones en sus propios servidores, no en el ordenador del cliente.

Los servicios web se dividen en servicios de transporte (los protocolos del nivel más bajo, que codifican la información independientemente de su formato, y que pueden ser comunes a otros servicios), de mensajería, de descripción y de descubrimiento. En la parte más baja se encuentran los servicios de transporte, que establecen la conexión y el puerto usado. Generalmente se usa HTTP, el mismo protocolo que la WWW, pero en se puede usar también SMTP (el mismo protocolo que el correo electrónico), FTP (File Transfer Protocol), o BEEP (blocks extensible exchange protocol), un protocolo específico para servicios web, que, a diferencia de los anteriores, no es cliente-servidor, sino "entre pares"; los dos ordenadores entre los que se establece la comunicación actúan como clientes y servidores a la vez. Es además extensible, y está especificado en XML; por eso se está haciendo mucho más popular para aplicaciones web. Un ejemplo de uso de Beep sería el siguiente:


RPY 0 0 . 0 124 
Content-Type: application/beep+xml

<greeting>
<profile uri="http://xml.resource.org/profiles/TLS" />
<profile uri="http://xml.resource.org/profiles/SEP" />
<profile uri="http://xml.resource.org/profiles/sasl/OTP" />
<profile uri="http://xml.resource.org/profiles/sasl/..." />
</greeting>
END


<start number="1">
<profile uri="..."> ... </profile>
<profile uri="..."> ... </profile>
</start>

<close number="1" code="200" />

En este ejemplo (procedente de esta presentación) se declaran una serie de perfiles de canales, y se abre un canal, para cerrarlo finalmente (close)

De ahí hacia arriba, están los servicios de mensajería, que especifican cómo se tiene que codificar el mensaje, que contiene los datos que se intercambian, entre el cliente y el servidor. El protocolo más usado en esta capa es el SOAP. Este protocolo puede usar cualquiera de los transportes anteriores, se pueden escribir clientes y servidores en cualquier lenguaje, y usa XML como lenguaje para especificar los mensajes. XML-RPC (Remote Procedure Call mediante XML), un método de llamada remota a procedimientos usando XML, que usa como capa de transporte HTTP; a diferencia de SOAP, que puede usar cualquiera. Es bastante popular entre la comunidad de bloggers, por el API que proporciona. Hay otros métodos que se pueden usar, tales como ebXML, que ni se ha acabado a tiempo ni ha alcanzado popularidad, y la forma más simple, servir simplemente páginas XML sobre protocolo HTTP. Por ejemplo, una petición de SOAP tendría la forma siguiente:


POST /examples HTTP/1.0
User-Agent: Radio UserLand/7.0 (MacOS)
Host: localhost:81
Content-Type: text/xml
Content-length: 474
SOAPAction: "/examples"

<?xml version="1.0"?> 
  <SOAP-ENV:Envelope
		SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
        xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
        xmlns:xsd="http://www.w3.org/1999/XMLSchema" 
        xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"> 
    <SOAP-ENV:Body> 
      <m:getStateName xmlns:m="http://soapware.org/"> 
        <param1 xsi:type="xsd:int">41</param1> 
      </m:getStateName> 
    </SOAP-ENV:Body> 
 </SOAP-ENV:Envelope>

En este ejemplo se llama a una función llamada getStateName, a la cual se le pasa un parámetro llamado param1.

Los servicios deben de especificarse, para que una aplicación sepa de forma automática qué formato usar para comunicarse con un servicio. Para ello se usa principalmente WSDL, web services description language, que permite especificar la dirección de un servicio y el interfaz que se usa para acceder a él, sea SOAP o HTML. Los ejemplos de WSDL son bastante prolijos: éste, por ejemplo, describe una aplicación para apoyar snowboarders en una competición.

Por último, en la capa más alta, está UDDI, Universal Description, Discovery, and Integration, un protocolo que lleva WSDL un poco más allá, permitiendo no sólo describir servicios web, sino productos, la empresa en sí, y cómo está dispuesta a llevar a cabo transacciones. El Registro UDDI permite buscar negocios, servicios por categorías, y te devuelve informacións sobre cómo acceder a ellos. En este artículo de MSDN explica cómo se produciría el diálogo con un servicio UDDI, mediante mensajes XML.

Todo esos protocolos y servicios constituyen una constelación de servicios web, a los cuales se están apuntando muchas empresas, tales como iSOCO y Logic Factory. Y, como perejil de todas las salsas, ahí está Microsoft. Microsoft .Net acepta los estándares de todas las capas, en lo único que varía es en la forma preferida de acceder a los servicios y programarlos, y usa XML de forma extensiva en todos los servicios. Sin embargo, .Net provee una serie de elementos que permiten acceder a estos servicios Web, si no de una forma más fácil, por lo menos de una forma adaptada especialmente a ellos.

Componentes de Microsoft .Net

Modelo de capas de .NET

El componente principal de .NET, que está en la capa más baja de su modelo de capas, es el Common language runtime (CLR), o máquina virtual común. Se trata de un programa, que se puede ejecutar, en principio, en cualquier sistema operativo, y que provee de una serie de servicios que se pueden usar desde diferentes lenguajes de programación. Esta máquina virtual se ha liberado, aunque de forma limitada, dando lugar a Rotor, una implementación de fuente compartida, y de la cual existen versiones para Windows, BSD, y, desde junio de 2002, Linux. Asimismo, hay otras implementaciones no basadas en el código de Microsoft; la principal es el proyecto Mono, de Ximian, que tiene la mayor parte de las funcionalidades de Rotor. La especificación de este CLR se quiere convertir en un stándard ECMA, de forma que pueda haber diferentes implementaciones de la misma, y diferentes lenguajes basados en ella.

Los ejecutables CLR, están escritos en un lenguaje denominado MSIL (Microsoft intermediate language), similar al Java bytecode; en principio, cualquier programa escrito en MSIL (aunque nadie escribe en MSIL, se supone que lo hacen los compiladores) puede ejecutarse en cualquier sistema operativo donde funcione un CLR; el formato de esos ficheros se denomina portable executable o PE. Además, el fichero ejecutable contiene metadatos, que informan sobre las funciones y tipos que implementan. Pero el concepto de ejecutable va un poco más allá: en .NET se usan ensamblajes (assemblies), que pueden incluir partes de código, datos, códigos de seguridad, y todo lo necesario para convertirlo en código móvil y fiable (en el sentido de que esté firmado por alguien), que se pueda mover por la Internet.

Los ensamblajes, a su vez, contienen metadatos, en un apartado denominado manifiesto (igual que sucede en los .jar de Java).

Estos ejecutables y ensamblajes pueden ser generados a partir de diferentes lenguajes de alto nivel, pero los lenguajes deben de incluir dos cosas: un sistema común de tipos (CTS, common type system) y un sistema común de lenguajes (CLS, common language specification). El sistema común de tipos indica los tipos que tiene que soportar el lenguaje: tipos valor (por ejemplo, un entero; una variable entera contiene un valor) y tipos referencia, que apuntan a estructuras de datos dinámicas. Sin embargo, a diferencia de los lenguajes habituales, donde el tipo fundamental es un tipo valor, y las referencias son accesorias, y deben desreferenciarse para trabajar con ellas, en .NET el tipo fundamental es un objeto, y, de hecho, cualquier tipo valor se puede convertir en una referencia "encajándolo" (boxing). Por ejemplo:


int i = 1; // i es de tipo valor
object box = i // box es de tipo referencia

Por supuesto, también se puede hacer la operación contraria, desencajar, que es análoga a los typecastings en Java o C+:


int i = (int) box;

El CTS añade soporte para una serie de tipos que no se suelen encontrar en otros lenguajes: eventos (métodos que responden a un suceso determinado), propiedades (métodos para establecer y recuparar valores de variables de instancia) e indexadores, similares a los iteradores usados en otros lenguajes.

En cuanto a la especificación común de lenguaje (CLS), son una serie de reglas básicas requeridas para integración del lenguaje, que garantice que el código intermedio generado desde cada uno de ellos sea interoperable con los otros. Hasta ahora, hay una serie de lenguajes propios de Microsoft: J# (se pronuncia J-sostenido, o J-Sharp, similar al Java), F# (derivado del OCAML, un lenguaje funcional), y además, VB.Net, Perl.Net, Python.net. El más popular probablemente es C#, que ha sido vilipendiado como un hermano bastardo de Java, al que, efectivamente, se le parece, pero que es un lenguaje totalmente diferente, con bastantes cosas originales. Todos los lenguajes usan el mismo conjunto básico de servicios, proporcionados por el CLR: entrada salida, acceso al filesystem, acceso a servicios remotos y acceso a datos.

El XML está totalmente integrado con el C#: un programa permite pasar la definición de una clase a un fichero XML en formato XSchema (un formato que permite especificar, a su vez, el formato en el que se tiene que escribir un documento).

Hay una serie de problemas en este entorno: la disponibilidad del código fuente, ya que el MSIL se puede desensamblar con relativa facilidad, y además, tiene los metadatos que complementan más todavía la legibilidad del código; por eso, en caso de que no se quiera publicar el código, hay que hacer uso de algún tipo de técnica de enmascaramiento. El siguiente problema son las prestaciones, problema común a todo tipo de máquina virtual; sin embargo, con el compilador JIT (Just in Time, similar al que tienen las máquinas virtuales Java), se trata de obtener el máximo rendimiento del código, compilándolo sólo cuando se le cargue por primera vez. Y, por supuesto, siempre planea sobre todo esto la sombra de la historia pasada de Microsoft: un estándar cerrado, que puede ser cambiado arbitrariamente, puede dejar fuera del negocio a todos los que se hayan apuntado al carro. Otro problema adicional es la falta de servicios de autentificación. Inicialmente, se iba a usar Passport, que luego se convirtió en Hailstorm, para acabar siendo "My Services". Finalmente, por falta de apoyo por parte de la industria, Microsoft decidió suprimirlo. Nadie quería, como es natural, que fuera Microsoft quien autentificara a sus clientes, por mucho que sea Microsoft.

Otro posible problema son los virus; como cualquier formato ejecutable, el PE se puede infectar con virus, y si el CLR se convierte en ubicuo, puede tener bastantes posibilidades de propagación. Eso, en parte, se tratará de evitar con la firma e IDs asignados a ensamblajes, pero, aún así, se pueden coger virus si te fías de una firma que no es fiable.

Otros componentes de .Net

Los demás componentes de .Net permiten extender a todos los productos de Microsoft la funcionalidad de .Net:

Usando .Net

Hay dos vías principales: la vía Microsoft y la "otra" vía. Ambas son gratuitas; como el entorno está en sus principios, todas las herramientas, por el momento, son gratuitas.

La vía Microsoft incluye bajarse el .Net framework SDK junto con el primer service pack. Estos paquetes incluyen todo lo necesario para desarrollar aplicaciones para .NET: entorno, CLR, ASP.NET. Para usarlo, es necesario tener un Windows de la familia NT: NT, 2000 o XP; no funciona sobre Windows 2X. Un producto comercial, Visual Studio .NET, sirve también para desarrollar .Net en un entorno mucho más amigable, y hace mucho más fácil usar los formularios que son parte del entorno, WinForms y WebForms. Recientemente, también ha sacado Microsoft, como herramienta gratuita, Web Matrix para desarrollar ASP.NET de forma visual.

La otra vía incluye varios proyectos libres y gratuitos. Para empezar, si se trabaja en Windows, FreeBSD, o, desde junio 2002, Linux, se puede usar Rotor, el CLR 'fuentes compartidas' de Microsoft. La otra alternativa es Mono, una implementación del compilador de C#, el CLR y de la librería básica de clases de C#. Actualmente está en la versión 0.12. No existe ninguna previsión de cuándo se va a sacar la versión 1.0, aunque más o menos se sabe qué es lo que incluirá. La licencia de C# es libre, al igual que la documentación. Otra alternativa, aunque mucho menos desarrollada, es dotGNU, que trata de crear una plataforma de servicios web libres,(por lo pronto se llama portable.Net) y un sistema de autentificación (que se denominan Identidades Virtuales), pero no se encuentra tan desarrollado como Mono.

Competidores y futuro de .Net

Como principal competidor se presenta J2EE, Java 2 Enterprise Editition, una versión de Java con librerías de clase añadidas, que usa la máquina virtual Java, y tiene muchas características similares a .Net, como se indica en esta comparativa. Java es un lenguaje bastante maduro, con soporte de cientos de librerías fuera de las básicas, y con una comunidad bastante extensa. En ese sentido, C# vs. J2EE puede tratarse de una batalla "comunidad" frente a Microsoft, y no está claro quién la va a ganar. Lo que sí está claro es que Microsoft apuesta por .Net, como centro de su estrategia, y que cuando Microsoft apuesta por algo, acaba ganando. Es posible que coexistan las dos plataformas, y es posible que se abran la una a la otra; por ejemplo, que haya intérpretes CLR que corran dentro de una JVM o viceversa.

La apuesta que no se puede perder es la apuesta por los servicios web, y aplicaciones basadas en XML. Todos los grandes de la industria apuestan por ellas, y gran parte de las aplicaciones de cara al usuario, el middleware y los servidores entenderán y servirán XML. Es decir, que independientemente de la plataforma, XML será el vencedor.

Bibliografía y enlaces relacionados con .Net

Libros relacionados con Microsoft.NET y servicios web

Understanding Web Services: XML, WSDL, SOAP, and UDDI por Eric Newcomer, que presenta una visión general de los principales "lenguajes" de los servicios web, tratando estos en general, sin usar ningún lenguaje en particular.
Como siempre, los libros de O'Reilly son garantía de calidad, y Web Services Essentials (O'Reilly XML) de Ethan Cerami no podía ser menos. Es una introducción bastante general, con diferentes partes dedicadas a XML-RPC, SOAP, UDDI y WSDL.
Otro libro de O'Reilly: .Net framework Essentials (segunda edición) Thuan L. Thai, Hoang, Q. Lam Es una introducción general al entorno, con capítulos dedicados a cada una de sus partes: Common Language Runtime, XML y servicios web, y formularios (WinForms y WebForms).
Quién mejor para hablarnos de .Net que la propia Microsoft Press: Introducing Microsoft .NET, por David S. Platt es también una introducción de todas las partes del entorno .Net, sin meterse en mucha profundidad.

Una serie de sitios que tratan con .Net, de diversa calidad, son GotDotNet, un sitio de Microsoft, DotNetWire, y dotNet101, un sitio para principiantes. En español he encontrado este sitio que habla de C# y MS, aunque los popups son un tanto insoportables.

La discusión sobre este tutorial en barrapunto es bastante enriquecedora. Puedes aportar tu granito de arena, si te apetece.


Juan Julian Merelo Guervos
Last modified: Tue Jul 9 08:52:49 CEST 2002