Servicios Web

Servicios Web en plataforma .
NET - Manual completo Página 1 de 52
Servicios Web en
plataforma .NET
Manual por: DesarrolloWeb.com [http://www.desarrolloweb.com/] Versión on-line:
"Tu mejor ayuda para aprender a hacer webs" http://www.desarrolloweb.com/manuales/54
Introdución a los servicios web

“Toda la información disponible para cualquier persona, en cualquier lugar, a través
de cualquier dispositivo.”
Esta frase acuña quizás el sueño de todos los que de una u otra forma se relacionan con las
tecnologías de la información, partiendo desde una gran compañía tecnológica hasta un simple
usuario de una planilla Excel. La pregunta es: ¿Será esto posible?
A mediado de la década de los 90 y con la aparición de Internet y su posterior masificación a

niveles jamás pensados, ha existido siempre la necesidad e inquietud por parte de las empresas
desarrolladoras de software de buscar o contar con la manera de lograr la integración entre
sistemas heterogéneos, cuando hablo de sistemas heterogéneos me refiero tanto al software
como al hardware. Para tal efecto muchas compañías fueron creando de forma individual la
mejor manera de lograr esta integración. Muchas empresas comenzaron una loca carrera para
generar la mejor tecnología integradora de sistemas, pero a medida que la competencia se
hacia cada vez más fuerte, la integración se hacia cada vez más difícil.
Debido a la gran masificación de Internet a niveles insospechables y al gran impacto causado

por las tecnologías de la información en las ultimas dos décadas del siglo pasado, la manera de
hacer negocios y la comunicación entre las personas y las empresas cambió de una manera
rotunda. Bajo este contexto se hacía cada vez mayor la necesidad de integrar y compartir
información entre distintas plataformas de software y hardware.
Las empresas se percataron que era imposible crear una plataforma integrado de forma
individual, así que decidieron atacar el problema de raíz. Para esto decidieron que en vez de
crear la mejor plataforma integradora, era mejor buscar un leguaje común de intercambio de
información aprovechando los estándares existentes en el mercado.
Bajo este contexto nacen los Servicios Web basados en XML, los cuales son el objeto de estudio
del presente manual.
OBJETIVOS
Conocer y entender el significado y alcance le los Servicios Web XML.
Esto implica entender el contexto global en el cual se desarrollaron los Servicios Web para así
conseguir de manera práctica la adopción e implementación de dicha tecnología, también
conocer sus principales ventajas así como sus limitaciones desde un punto de vista de una
tecnología que esta en continuo desarrollo.
Dimensionar los nuevos cambios de paradigmas informáticos producto de la

implementación de Servicios Web.
Esto quiere decir poder dimensionar que esta tecnología viene a cambiar la forma en que se
comunicaban las distintas aplicaciones y la forma en que se accede a la información que reside
en distintas plataformas y aplicaciones desde diversos tipos de equipos y dispositivo de
comunicación.
Ampliar el conocimiento de todas las tecnologías asociadas a los Servicios Web.

Servicios Web en plataforma .NET - Manual completo Página 2 de 52
De manera general o detallada conocer las tecnologías asociadas a Servicios Web. Ya que de
alguna manera, más temprano que tarde, nos encontraremos inmersos en ellas.
Dejar un documento escrito que sirva de base para los futuros estudiantes que se
interesen en descubrir nuevas tecnología.
La intención del presente documento no es solo la de explicar el contexto de los Servicios Web,
si no también transmitir al lector un numero de nuevos conceptos y tecnologías que en la
actualidad están en pleno desarrollo y en adopción por diversas empresas. Todo lo anterior
pretende incentivar al lector a que investigue y descubra nuevas herramientas con las cuales
logre estar un grado por encima del resto en lo que a informática se refiere.
Una visión general I

Web Services y la evolución hacia la Economía Global
Las aplicaciones web actuales ya no son suficientes. El modelo actual de negocio electrónico no
facilita la integración de las aplicaciones de Internet con el resto de software de las empresas.
Si las compañías quieren extraer el máximo beneficio de Internet, los sitios web deben
evolucionar. Este es el contexto en el que surgen los web services. Los web services son
componentes software que permiten a los usuarios usar aplicaciones de negocio que comparten
datos con otros programas modulares, vía Internet. Son aplicaciones independientes de la
plataforma que pueden ser fácilmente publicadas, localizadas e invocadas mediante protocolos
web estándar, como XML, SOAP, UDDI o WSDL. El objetivo final es la creación de un directorio
online de web services, que pueda ser localizado de un modo sencillo y que tenga una alta
fiabilidad.
La funcionalidad de los protocolos empleados es la siguiente:
z XML( eXtensible Markup Language): Un servicio web es una aplicación web creada en
XML.
z WSDL (Web Services Definition Service): Este protocolo se encarga de describir el web
service cuando es publicado. Es el lenguaje XML que los proveedores emplean para
describir sus web services.
z SOAP (Simple Object Access Protocol): Permite que programas que corren en diferentes
sistemas operativos se comuniquen. La comunicación entre las diferentes entidades se
realiza mediante mensajes que son rutados en un sobre SOAP.
z UDDI (Universal Description Discovery and Integration): Este protocolo permite la
publicación y localización de los servicios. Los directorios UDDI actúan como una guía
telefónica de web services.
Aunque la idea de la programación modular no es nueva, el éxito de esta tecnología reside en

que se basa en estándares conocidos en los que ya se tiene una gran confianza, como el XML.
Además, el uso de los web services aporta ventajas significativas a las empresas. El principal
objetivo que se logra, es la interoperabilidad y la integración. Mediante los web services, las
empresas pueden compartir servicios software con sus clientes y sus socios de negocio. Esto
ayudará a las compañías a escalar sus negocios, reduciendo el coste en desarrollo y
mantenimiento de software, y sacando los productos al mercado con mayor rapidez. La
integración de aplicaciones hará posible obtener la información demandada en tiempo real,
acelerando el proceso de toma de decisiones. La evolución de Internet hacia los web services,
mejorará los resultados globales de las empresas, reduciendo sus gastos y guiándolas hacia una
mejora progresiva de la calidad. La adopción de la tecnología de servicios web por la industria
es el primer paso hacia una economía global.
Posibles riesgos
Las expectaciones alrededor de esta tecnología son grandes, porque el mercado de aplicación
es muy amplio. Pero también tiene sus puntos oscuros:
z Los web services hacen uso de las mismas tecnologías que han sido atacadas en tantas
ocasiones. Usando web services, la seguridad de una empresa puede verse
comprometida. La ausencia de técnicas de seguridad estándar es un obstáculo para la
adopción de la tecnología.
z La calidad de un web service es un parámetro que no queda demasiado claro, pero cuya
medida es fundamental a la hora de desarrollar un servicio maduro.
Una visión general II

Seguridad
Actualmente, los web services están siendo ampliamente aceptados por las empresas para el
desarrollo de software de uso interno. De este modo, los servicios pueden implementar toda su
funcionalidad y permanecer seguros tras el Cortafuegos de la compañía. Los desarrollos
actuales no ayudan a la cooperación entre las empresas ya que no hay ningún estándar
establecido sobre las técnicas de seguridad. Debido a la tecnología que es usada por los web
services, y en concreto al uso de SOAP, las técnicas de seguridad convencionales que se han
venido usando en Internet, ya no son suficientes. Con SOAP, cada mensaje simple que se
intercambia realiza múltiples saltos y es rutado a través de numerosos puntos antes de que
alcance su destino final. Es por ello que los web services necesitan tecnologías que protejan los
mensajes desde el principio hasta el final. Existen un conjunto de técnicas que se pueden usar
para garantizar la seguridad a nivel de mensaje. Estas son:
z Encriptación XML: Evita que los datos se vean expuestos a lo largo de su recorrido.
z Firma Digital XML: Asocia los datos del mensaje al usuario que emite la firma, de modo
que este usuario es el único que puede modificar dichos datos.
z XKMS y los Certificados: XKMS (XML Key Management Specification) define web services
que se pueden usar para chequear la confianza de un certificado de usuario.
z SAML y la Autorización: SAML (Security Assertion Mark-up Language) hace posible que
los web services intercambien información de autentificación y autorización entre ellos, de
modo que un web service confíe en un usuario autentificado por otro web service.
z Validación de datos: Permite que los web services reciban datos dentro de los rangos
esperados.
Además, también hay técnicas que permiten mantener la seguridad a otros niveles. La
seguridad en UDDI permite autentificar todas las entidades que toman parte en la publicación
de un web service: proveedor, agente y consumidor del servicio. De este modo, nadie podrá
registrar servicios en el papel de un proveedor o hacer uso de ellos sin contar con los permisos
adecuados.
Calidad
Actualmente ya existen en el mercado algunas herramientas específicamente diseñadas para

medir la calidad de los web services, pero sigue siendo necesaria una estandarización sobre
este tema. Los resultados sobre la calidad de diferentes web services, servirán como parámetro
de comparación y ayudarán al consumidor a decantarse por un servicio u otro. Para que un web
service se ejecute con corrección y satisfaga las expectativas creadas, a parte del precio, habrá
que tener en cuenta una serie de parámetros como por ejemplo, que los resultados obtenidos
del mismo sean los esperados o que el entorno de uso sea amigable. Otro elemento a tener en
cuenta es la integración. Aunque teóricamente los web services proporcionan conectividad con
cualquier software de un modo transparente, cada proveedor de servicios puede adoptar
soluciones diferentes que resultan más o menos adecuadas para el consumidor. Analizando la
escalabilidad se comprobará el grado de modularidad y flexibilidad del servicio. Por último,
también sería interesante analizar las características que ofrece el proveedor de web services.
Actualmente no hay definidos estándares sobre este tema, pero la mayoría de las empresas ya
está demandando algún tipo de acuerdo o contrato con los proveedores, de modo que se pueda
garantizar la calidad y la fiabilidad de los servicios por los que se paga.
Estandarización
Los web services están basados en el estándar XML, que ha sido universalmente aceptado. Pero
la situación para el resto de protocolos es bien distinta. La mayor parte de ellos se encuentran
todavía en desarrollo y pueden ser objeto de cambios. Esa es la razón por la que la mayoría de
las empresas están esperando a que estos protocolos sean más universales antes de
profundizar en esta tecnología. Actualmente, ni SOAP, ni WSDL, ni UDDI han sido oficialmente
reconocidos por ningún organismo de estandarización. SOAP es el único que en este momento
está en consideración por el World Wide Web Consortium y se encuentra cercano a la
estandarización. SOAP y WSDL están siendo ampliamente usados, pero de momento UDDI no
ha tenido el mismo éxito. El principal motivo es que las técnicas de seguridad son todavía muy
inmaduras y las compañías prefieren hacer uso de registros privados para dar soporte a
intercambios privados de web services. En febrero de este año, algunas de las empresas más
importantes en el desarrollo de Negocio Electrónico como IBM, Intel, Microsoft o Oracle, han
creado el WS-I: organización para la Interoperabilidad de los Web Services. El objetivo de dicha
organización es la promoción de la estandarización de los web services de modo que se fomente
la cooperación e interoperabilidad entre las compañías y mercados.
Algunos ejemplos
Las principales compañías del mundo han empezado a desarrollar soluciones mediante la
tecnología de los web services. Algunos ejemplos son:
z Microsoft: Recientemente ha anunciado la disponibilidad de su primer web service,

llamado MapPoint .Net. Mediante este servicio, el usuario podrá conocer su localización
exacta y otros datos adicionales relacionados con su posición actual, como información de
tráfico, rutas posibles o puntos comerciales cercanos.
z IBM: Ha implementado una solución basada en los web services llamada e-Business on
Demand. Esta solución permite la construcción de Extranets que ayuden a las empresas a
ver los catálogos de productos, realizar y localizar pedidos o chequear el estado del
inventario en tiempo real.
z Líneas Aéreas Escandinavas: Estas líneas aéreas han desarrollado un servicio web que
permite a los usuarios comprar billetes y chequear el estado de los vuelos, mediante el
uso del teléfono móvil.
Conceptos e ideas de Web Services
"Los web services son componentes software que permiten a los usuarios usar aplicaciones de
negocio que comparten datos con otros programas modulares, vía Internet. Son aplicaciones
independientes de la plataforma que pueden ser fácilmente publicadas, localizadas e invocadas
mediante protocolos web estándar, como XML, SOAP, UDDI o WSDL. El objetivo final es la
creación de un directorio de online de web services, que pueda ser localizado de un modo
sencillo y que tenga una alta fiabilidad."
"Los servicios web son la revolución informática de la nueva generación de aplicaciones que
trabajan colaborativamente en las cuales el software esta distribuido en diferentes servidores."
"Los servicios XML Web son los bloques de construcción de la computación distribuida en el
Internet. Usted puede crear soluciones al usar los múltiples servicios de XML Web desde varias
fuentes que trabajan en conjunto-independientemente de dónde residan o cómo fueron
implementadas."
XML Web Services

Antes de continuar y con el propósito de dejar al lector con una idea lo más clara posible acerca
de el concepto de Web Services (Servicio Web), quiero citar una definición que rescate al asistir
a una charla técnica de XML Web Service en Microsoft en octubre del 2003 cuyo expositor fue el
señor Marcos Escovar.
"Un Web Service es un componente de software que se comunica con otras aplicaciones
codificando los mensaje en XML y enviando estos mensaje a través de protocolos estándares de
Internet tales como el Hypertext Transfer Protocol (HTTP). Intuitivamente un Web Service es
similar a un sitio web que no cuenta con un interfaz de usuario y que da servicio a las
aplicaciones en vez de a las personas. Un Web Service, en vez de obtener solicitudes desde el
navegador y retornar paginas web como respuesta, lo que hace es recibir solicitudes a través
de un mensaje formateado en XML desde una aplicación, realiza una tarea y devuelve un
mensaje de respuesta también formateado en XML.
Microsoft y otras empresas lideres están promocionando SOAP como estándar de los mensajes
para los Web Services. Un mensaje SOAP se parece mucho a una carta : es un sobre que
contiene una cabecera con la dirección del receptor del mensaje , un conjunto de opciones de
entrega (tal como la información de encriptación), y un cuerpo o body con la información o data
del mensaje.
Microsoft y otros proveedores líderes promocionan los Web Services como un modelo de
programación para la comunicación entre aplicaciones. Estas compañías piensan que la
conexión de aplicaciones a través de la Internet mejorará la capacidad de las empresas para
trabajar conjuntamente con sus socios de negocio, proveedores y clientes. Creando una capa de
Web Services sobre una aplicación corporativa existente, las organizaciones podrán permitir
que sistemas externos puedan invocar las funciones de la aplicación a través de Internet (o una
intranet corporativa) sin tener que modificar la aplicación misma. Por ejemplo, varias
compañías están hoy en día creando Web Services que actúan como front end para aplicaciones
de entrada de órdenes que están residentes internamente en un mainframe. Estas compañías
permiten a los sistemas de compras de sus clientes enviar órdenes de compra a través de la
Internet. Poner una capa de web services sobre las aplicaciones existentes es una solución muy
interesante para integrar las aplicaciones desarrolladas por los diferentes departamentos y así
reducir los costos de integración."
Ahora que ya tenemos una breve noción de lo que es un Web Services nos introduciremos en
aspectos un poco más técnicos.
Requisitos de un Web Service
z Interoperabilidad: Un servicio remoto debe permitir su utilización por clientes de otras

plataformas.
z Amigabilidad con Internet: La solución debe poder funcionar para soportar clientes que
accedan a los servicios remotos desde internet.
z Interfaces fuertemente tipadas: No debería haber ambigüedad acerca del tipo de dato
enviado y recibido desde un servicio remoto. Más aún, los tipos de datos definidos en el
servicio remoto deben poderse corresponder razonablemente bien con los tipos de datos
de la mayoría de los lenguaje de programación procedimentales.
z Posibilidad de aprovechar los estándares de Internet existentes: La
implementación del servicio remoto debería aprovechar estándares de Internet existentes
tanto como sea posible y evitar reinventar soluciones a problema que ya se han resuelto.
Una solución construida sobre un estándar de Internet ampliamente adoptado puede
aprovechar conjuntos de herramientas y productos existentes creados para dicha
tecnología.
z Soporte para cualquier lenguaje: La solución no debería ligarse a un lenguaje de
programación particular Java RMI, por ejemplo, esta ligada completamente a lenguaje
Java. Sería muy difícil invocar funcionalidad de un objeto Java remoto desde Visual Basic
o PERL. Un cliente debería ser capaz de implementar un nuevo servicio Web existente
independientemente del lenguaje de programación en el que se halla escrito el cliente
z Soporte para cualquier infraestructura de componente distribuida: La solución no
debe estar fuertemente ligada a una infraestructura de componentes en particular. De
hecho, no se bebería requerir el comprar, instalar o mantener una infraestructura de

objetos distribuidos, solo construir un nuevo servicio remoto utilizar un servicio existente.
Los protocolos subyacentes deberían proporcionar un nivel base de comunicación entre
infraestructura de objeto distribuidos existentes tales como DCOM y CORBA.
Bloques Constructivos de Servicios Web
En el siguiente grafico se muestran los bloques constructivos principales necesarios para

facilitar las comunicaciones remotas entre aflicciones.
Descubrimiento
UDDI,DISCO
Descripción
WSDL, Esquema XML, Docs
Formato de Mensaje
SOAP
Codificación
XML
Transporte
HTTP,SMTP y otros
Figura II.1: "Bloques constructivos de Servicios Web"
z Descubrimiento: La aplicación cliente que necesita acceder a la funcionalidad que

expone un Servicio Web necesita una forma de resolver la ubicación de servicio remoto.
Se logra mediante un proceso llamado, normalmente descubrimiento (discovery). El
descubrimiento se puede proporcionar mediante un directorio centralizado así como por
otros métodos ad hoc. En DCOM, el servicio de descubrimiento lo proporciona el
Administrador de control de servicios (SCM, Services Control Manager).
z Descripción: Una vez que se ha resuelto el extremo de un servicio Web dado, el cliente
necesita suficiente información para interactuar adecuadamente con el mismo. La
descripción de un servicio Web implica meta datos estructurados sobre la interfaz que
intenta utilizar la aplicación cliente así como documentación escrita sobré el servicio Web
incluyendo ejemplo de uso. Un componente DCOM expone meta datos estructurados
sobre sus interfaces mediante una biblioteca de tipo (typelib). Los meta datos dentro de
una typelib de componente se guardan en un formato binario propietario a los que se
accede mediante una interfaz de programación de aplicación (API) propietaria.
z Formato del mensaje: Para el intercambio de datos, el cliente y el servidor tienen que
estar de acuerdo en un mecanismo común de codificación y formato de mensaje.
El uso de un mecanismo estándar de codificar los datos asegura que los datos que
codifica el cliente los interpretará correctamente el servidor. En DCOM los mensajes que
se envían entre un cliente y un servidor tienen un formato definido por el protocolo DCOM
Object RPC (ORPC).
z Codificación: Los datos que se trasmiten entre el cliente y el servidor necesitan
codificarse en un cuerpo de mensaje. Dcom utiliza un esquema de codificación binaria
para serializar los datos de los parámetros que se intercambian entre el cliente y el
servidor.
z Transporte: Una vez se ha dado formato al mensaje y se han serializado los datos en el
cuerpo del mensaje se debe transferir entre el cliente y el servidor utilizando algún
protocolo de transporte. DCOM dispone de varios protocolos propietarios como TCP, SPX,
NetBEUI y NetBIOS sobre IPX.
SOAP (Simple Object Access Protocol)

¿Qué es SOAP?
Son las siglas de Simple Object Access Protocol. Este protocolo deriva de un protocolo creado
por David Winer, XML-RPC en 1998. En su sitio web, Userland, http://www.userland.com/ se puede
encontrar multitud de documentación acerca de este primer protocolo de comunicación bajo
http mediante XML. Con este protocolo se pedían realizar RPC o remote procedure calls, es
decir, podíamos bien en cliente o servidor realizar peticiones mediante http a un servidor web.
Los mensajes debían tener un formato determinado empleando XML para encapsular los
parámetros de la petición. Con el paso del tiempo el proyecto iniciado por David Winer interesó
a Importantes multinacionales entre las que se encuentran IBM y Microsoft y de este interés por
XML-RPC se desarrollo SOAP."
En el núcleo de los servicios Web se encuentra el protocolo simple de acceso a datos SOAP, que
proporciona un mecanismo estándar de empaquetar mensajes. SOAP ha recibido gran atención
debido a que facilita una comunicación del estilo RPC entre un cliente y un servidor remoto.
Pero existen multitud de protocolos creados para facilitar la comunicación entre aplicaciones,
incluyendo RPC de Sum, DCE de Microsoft, RMI de Java y ORPC de CORBA. ¿Por qué se presta
tanta atención a SOAP?
Una de las razones principales es que SOAP ha recibido un increíble apoyo por parte de la
industria. SOAP es el primer protocolo de su tipo que ha sido aceptado prácticamente por todas
las grandes compañías de software del mundo. Compañías que en raras ocasiones cooperan
entre sí están ofreciendo su apoyo a este protocolo. Algunas de las mayores Compañías que
soportan SOAP son Microsoft, IBM, SUN, Microsystems, SAP y Ariba.
Algunas de las Ventajas de SOAP son:
z No esta asociado con ningún lenguaje: los desarrolladores involucrados en nuevos

proyectos pueden elegir desarrollar con el ultimo y mejor lenguaje de programación que
exista pero los desarrolladores responsables de mantener antiguas aflicciones heredadas
podrían no poder hacer esta elección sobre el lenguaje de programación que utilizan.
SOAP no especifica una API, por lo que la implementación de la API se deja al lenguaje de
programación, como en Java, y la plataforma como Microsoft .Net.
z No se encuentra fuertemente asociado a ningún protocolo de transporte: La
especificación de SOAP no describe como se deberían asociar los mensajes de SOAP con
HTTP. Un mensaje de SOAP no es más que un documento XML, por lo que puede
transportarse utilizando cualquier protocolo capaz de transmitir texto.
z No está atado a ninguna infraestructura de objeto distribuido La mayoría de los
sistemas de objetos distribuidos se pueden extender, y ya lo están alguno de ellos para
que admitan SOAP.
z Aprovecha los estándares existentes en la industria: Los principales contribuyentes
a la especificación SOAP evitaron, intencionadamente, reinventar las cosas. Optaron por
extender los estándares existentes para que coincidieran con sus necesidades. Por
ejemplo, SOAP aprovecha XML para la codificación de los mensajes, en lugar de utilizar su
propio sistema de tipo que ya están definidas en la especificación esquema de XML. Y
como ya se ha mencionado SOAP no define un medio de trasporte de los mensajes; los
mensajes de SOAP se pueden asociar a los protocolos de transporte existentes como
HTTP y SMTP.
z Permite la interoperabilidad entre múltiples entornos: SOAP se desarrollo sobre los
estándares existentes de la industria, por lo que las aplicaciones que se ejecuten en
plataformas con dicho estándares pueden comunicarse mediante mensaje SOAP con
aplicaciones que se ejecuten en otras plataformas. Por ejemplo, una aplicación de
escritorio que se ejecute en una PC puede comunicarse con una aplicación del back-end
ejecutándose en un mainframe capaz de enviar y recibir XML sobre HTTP.
Anatomía de un mensaje de SOAP
SOAP proporciona un mecanismo estándar de empaquetar un mensaje. Un mensaje SOAP se

compone de un sobre que contiene el cuerpo del mensaje y cualquier información de cabecera
que se utiliza para describir le mensaje. A continuación tiene un ejemplo:
Figura III.1: "Anatomía de un mensaje SOAP"
El elemento raíz del documento es el elemento Envelope. El ejemplo contiene dos

subelementos, Body y Header. Un ejemplo de SOAP valido también puede contener otros
elementos hijo en el sobre.
El sobre puede contener un elemento Header opcional que contiene información sobre el
mensaje. En el ejemplo anterior, la cabecera contiene dos elementos que describen a quien
compuso el mensaje, y posible receptor del mismo.
El sobre debe contener un elemento body el elemento body (cuerpo) contiene la carga de datos
del mensaje. En el ejemplo el cuerpo contiene una simple cadena de caracteres.
Un mensaje debe estar dentro de sobre de SOAP bien construido. Un sobre se compone de un
único elemento envelope el sobre puede contener un elemento Header y puede contener un
elemento body. Si existe, la cabecera debe ser el elemento hijo inmediato del sobre, con el
cuerpo siguiendo inmediatamente a la cabecera.
El cuerpo contiene la carga de datos del mensaje y la cabecera contiene los datos adicionales
que no pertenecen necesariamente al cuerpo del mensaje.
Además de definir un sobre de SOAP, la especificación de SOAP define una forma de codificar
los datos contenidos en un mensaje. La codificación de SOAP proporciona un mecanismo
estándar para zerialisar tipos de datos no definidos en la parte 1 de la especificación del
esquema de XML.
La especificación de SOAP también proporciona un patrón de mensaje estándar para facilitar el
comportamiento de tipo RPC. Se emparejan dos mensajes de SOAP para facilitar la asociación
de un mensaje de petición con un mensaje de respuesta.
La llamada a un método y sus parámetros se serializan en el cuerpo del mensaje de petición en
forma de una estructura.
El elemento raíz tiene el mismo nombre que el método objetivo, con cada uno de los
parámetros codificado como un subelemento.
El mensaje de respuesta puede contener los resultados de la llamada al método o una
estructura de fallo bien definida. Los resultados de la llamada a un método se serializan en el
cuerpo de la petición como una estructura. Por convenio, el elemento raíz tiene el mismo
nombre que el método original al que se añade result. Los parámetros de retorno se serializan
como elementos hijo, con el parámetro de retorno en primer lugar. Si se encuentra un error el
cuerpo del mensaje de respuesta contendrá una estructura de fallo bien definida.
Por convenio, el elemento raíz tiene el mismo nombre que el método original al que se añade
result. Los parámetros de retorno se serializan como elementos hijo, con el parámetro de
retorno en primer lugar. Si se encuentra un error el cuerpo del mensaje de respuesta contendrá
una estructura de fallo bien definida.
XML: el lenguaje de los Servicios Web

En este apartado conocemos por así decirlo el lenguaje sobre el cual se soportan los servicios
Web, su nombre es XML. No es intención explicar detalladamente la sintaxis de este lenguaje si
no más bien no evocaremos a aspectos más generales como sus orígenes, sus características
principales y porque es el lenguaje escogido para desarrolla servicios Web.
Vista general de XML
El código html permite insertar menús, tablas, imágenes o bases de datos en los documentos,
pero no permite al usuario que maneje esos elementos como mejor le convenga con la
poderosa ayuda del ordenador. Esa es la principal novedad que XML aporta.
Con HTML se pueden hacer accesos a información comparativa en diferentes tiendas por
ejemplo, pero nada más. Con XML el usuario podrá ordenar los datos o actualizarlos en tiempo
real o realizar un pedido.
La información que manejan las empresas es uno de sus principales activos. Pero lo normal es
que esa información esté fragmentada, en diferentes departamentos, ordenadores conectados o
no, etc. El reto ahora está en interrelacionar toda esa información para rendir todo su potencial
y ponerlo a trabajar para aumentar los beneficios o reducir los costes. Para realizar esto se
necesita un estándar de almacenamiento estructurado que es lo que nos ofrece XML.
Una gran cantidad de gente ha oído hablar últimamente de XML y mucha gente que es una
especie de HTML pero más avanzado. Pero todo el mundo lo que debería preguntarse es qué es
exactamente XML y qué aplicaciones tiene actualmente. De estas dos cuestiones el mayor error
que se suele cometer es considerar a XML un HTML extendido.
Lo que sí tenemos más o menos claro es que XML es un lenguaje de Marcas, pero qué es
exactamente un lenguaje de marcas.
Lenguajes de Marcas
En los años 60, IBM intentó resolver sus problemas asociados al tratamiento de documentos en
diferentes plataformas a través de GML (Generalized markup Language.
El principal problema era que cada aplicación utilizaba sus propias marcas para describir los
diferentes elementos. Las marcas son códigos que indican a un programa cómo debe tratar su
contenido y así, si se desea que un texto aparezca con un formato determinado, dicho texto
debe ir delimitado por la correspondiente marca que indique como debe ser mostrado en
pantalla o impreso. Y lo mismo ocurre con todas las demás características de cualquier texto.
Ejemplos pueden tenerlos en mente los usuarios de WordPerfect.
Conociendo este sistema y conociendo a la perfección el sistema de marcas de cada aplicación

sería posible pasar información de un sistema a otro sin necesidad de perder el formato
indicado. La forma que IBM creó para solventar esto se basaba en tratar las marcas como texto
accesible desde cualquier sistema, texto plano, código ASCII. Y la norma se denominó GML
(General Modeling Language.
Más tarde GML pasó a manos de ISO y se convirtió en SGML ( ISO 8879), Standart Generalized
Markup Language. Esta norma es la que se aplica desde entonces a todos los lenguajes de
marcas, cuyos ejemplos más conocidos son el HTML y el RTF.
Los lenguajes de marcas no son equivalentes a los lenguajes de programación aunque se

definan igualmente como "lenguajes". Son sistemas complejos de descripción de información,
normalmente documentos, que si se ajustan a SGML, se pueden controlar desde cualquier
editor ASCII. Las marcas más utilizadas suelen describirse por textos descriptivos encerrados
entre signos de "menor" (<) y "mayor" (>), siendo lo más usual que existan una marca de
principio y otra de final.
Se puede decir que existen tres utilizaciones básicas de los lenguajes de marcas: los que sirven
principalmente para describir su contenido, los que sirven más que nada para definir su formato
y los que realizan las dos funciones indistintamente. Las aplicaciones de bases de datos son
buenas referencias del primer sistema, los programas de tratamiento de textos son ejemplos
típicos del segundo tipo, y aunque no lo parezca, el HTML es la muestra más conocida del tercer
modelo.
¿Qué es XML?
XML, es el estándar de Extensible Markup Language. XML no es más que un conjunto de reglas
para definir etiquetas semánticas que nos organizan un documento en diferentes partes. XML es
un metalenguaje que define la sintaxis utilizada para definir otros lenguajes de etiquetas
estructurados.
En primer lugar para entenderlo bien hay que olvidarse un poco, sólo un poco de HTML. En
teoría HTML es un subconjunto de XML especializado en presentación de documentos para la
Web, mientras que XML es un subconjunto de SGML especializado en la gestión de información
para la Web. En la práctica XML contiene a HTML aunque no en su totalidad. La definición de
HTML contenido totalmente dentro de XML y por lo tanto que cumple a rajatabla la
especificación SGML es XHTML (Extensible, Hypertext Markup Language.
Desde su creación, XML ha despertado encontradas pasiones, y como para cualquier tema en
Internet, hay gente que desde el principio se deja iluminar por sus expectativas, mientras otras
muchas lo han ignorado.
Historia de XML
XML fue creado al amparo del Word Wide Web Consortium (W3C) organismo que vela por el
desarrollo de WWW partiendo de las amplias especificaciones de SGML.
Su desarrollo se comenzó en 1996 y la primera versión salió a la luz el 10 de febrero de 1998.

La primera definición que apareció fue: Sistema para definir validar y compartir formatos de
documentos en la web.
Durante el año 1998 XML tuvo un crecimiento exponencial, y con ello me refiero a sus
apariciones en medios de comunicación, menciones en páginas web, soporte software, etc.
Respecto a sus objetivos son:
z XML debe ser directamente utilizable sobre Internet.

z XML debe soportar una amplia variedad de aplicaciones.
z XML debe ser compatible con SGML.
z Debe ser fácil la escritura de programas que procesen documentos XML.
z El número de características opcionales en XML debe ser absolutamente mínimo,
idealmente cero.
z Los documentos XML deben ser legibles por humanos y razonablemente claros.
z El diseño de XML debe ser preparado rápidamente.
z El diseño de XML debe ser formal y conciso.
z Los documentos XML deben ser fácilmente creables.
z La concisión en las marcas XML es de mínima importancia.

z Esta especificación, junto con los estándares asociados (Unicode e ISO/IEC 10646 para
caracteres, Internet RFC 1766 para identificación de lenguajes, ISO 639 para códigos de
nombres de lenguajes, e ISO 3166 para códigos de nombres de países), proporciona toda
la información necesaria para entender la Versión 1.0 de XML y construir programas de
computador que los procesen.
Principales características
z Es una arquitectura más abierta y extensible. No se necesita versiones para que puedan
funcionar en futuros navegadores. Los identificadores pueden crearse de manera simple y
ser adaptados en el acto en internet/intranet por medio de un validador de documentos
(parser.
z Mayor consistencia, homogeneidad y amplitud de los identificadores descriptivos del
documento con XML (los RDF Resource Description FrameWork), en comparación a los
atributos de la etiqueta del HTML.
z Integración de los datos de las fuentes más dispares. Se podrá hacer el intercambio de
documentos entre las aplicaciones tanto en el propio PC como en una red local o extensa.
z Datos compuestos de múltiples aplicaciones. La extensibilidad y flexibilidad de este
lenguaje nos permitirá agrupar una variedad amplia de aplicaciones, desde páginas web
hasta bases de datos.
z Gestión y manipulación de los datos desde el propio cliente web.
z Los motores de búsqueda devolverán respuestas más adecuadas y precisas, ya que la
codificación del contenido web en XML consigue que la estructura de la información
resulte más accesible.
z Se desarrollarán de manera extensible las búsquedas personalizables y subjetivas para
robots y agentes inteligentes. También conllevará que los clientes web puedan ser más
autónomos para desarrollar tareas que actualmente se ejecutan en el servidor.
z Se permitirá un comportamiento más estable y actualizable de las aplicaciones web,
incluyendo enlaces bidireccionales y almacenados de forma externa (El famoso epígrafe
"404 file not found" desaparecerá).
z El concepto de "hipertexto" se desarrollará ampliamente (permitirá denominación
independiente de la ubicación, enlaces bidireccionales, enlaces que pueden especificarse y
gestionarse desde fuera del documento, hiperenlaces múltiples, enlaces agrupados,
atributos para los enlaces, etc. Creado a través del Lenguaje de enlaces extensible (XLL).
z Exportabilidad a otros formatos de publicación (papel, web, cd-rom, etc.). El documento
maestro de la edición electrónica podría ser un documento XML que se integraría en el
formato deseado de manera directa.
Estructura del XML
El metalenguaje XML consta de cuatro especificaciones (el propio XML sienta las bases
sintácticas y el alcance de su implementación):
z DTD (Document Type Definition) Definición del tipo de documento. Es, en general, un
archivo/s que encierra una definición formal de un tipo de documento y , a la vez,
especifica la estructura lógica de cada documento. Define tanto los elementos de una
página como sus atributos. El DTD del XML es opcional. En tareas sencillas no es
necesario construir una DTD, entonces se trataría de un documento "bien formado"(well-
formed) y si lleva DTD será un documento "validado" (valid).
z XSL (eXtensible Stylesheet Language) Define o implementa el lenguaje de estilo de
los documentos escritos para XML. Desde el verano de 1997 varias empresas informáticas
como Arbortext, Microsoft e Inso vienen trabajando en una propuesta de XSL (antes
llamado "xml-style") que presentaron a W3C. Permite modificar el aspecto de un
documento. Se puede lograr múltiple columnas, texto girado, orden de visualización de
los datos de una tabla, múltiples tipos de letra con amplia variedad en los tamaños. Este
estándar está basado en el lenguaje de semántica y especificación de estilo de documento
(DSSSL, Document Style Semantics and Specification Language, ISO/IEC 10179) y, por
otro lado, se considera más potente que las hojas de estilo en cascada (CSS, Cascading
Style Sheets), usado en un principio con el lenguaje DHTML. "Se espera que el CSS sea
usado para visualizar simples estructuras de documentos XML (actualmente se ha
conseguido mayor integración en XML con el protocolo CSS2 (Cascading Style Sheets,
level 2) ofreciendo nuevas formas de composición y una más rápida visualización) y, por
otra parte, XSL pueda ser utilizado donde se requiera más potencia de diseño como
documentos XML que encierran datos estructurados (tablas, organigramas, etc.)(2)".
z XLL (eXtensible Linking Language) Define el modo de enlace entre diferentes enlaces.
Se considera que es un subconjunto de HyTime (Hipermedia/Timed-based structuring
Language o Lenguaje de estructuración hipermedia/basado en el tiempo, ISO 10744) y
sigue algunas especificaciones del TEI (Text Encoding Initiative o Iniciativa de codificación
de texto). Desde marzo de 1998 el W3C trabajo en los enlaces y direccionamientos del
XML. Provisionalmente se le renombró como Xlink y a partir de junio se le denomina XLL.
Este lenguaje de enlaces extensible tiene dos importantes componentes: Xlink y el
Xpointer. Va más allá de los enlaces simples que sólo soporta el HTML. Se podrá
implementar con enlaces extendidos. Jon Bosak establece los siguientes mecanismos
hipertextuales que soportará esta especificación:
z Denominación independiente de la ubicación.
z Enlaces que pueden ser también bidirecccionales.
z Enlaces que pueden especificarse y gestionarse desde fuera del documento a los
que se apliquen (Esto permitirá crear en un entorno intranet/extranet un banco de
datos de enlaces en los que se puede gestionar y actualizar automáticamente. No
habrá más errores del tipo "404 Not Found").
z Hiperenlaces múltiples (anillos, múltiples ventanas, etc.).
z Enlaces agrupados (múltiples orígenes).
z Transclusión (el documento destino al que apunta el enlace aparece como parte
integrante del documento orígen del enlace).
z Se pueden aplicar atributos a los enlaces (tipos de enlaces).
z XUA (XML User Agent): Estandarización de navegadores XML. Todavía está en
proceso de creación de borradores de trabajo. Se aplicará a los navegadores para
que compartan todas las especificaciones XML.
XML y Los Servicios Web
Finalmente ahora que ya conocemos algo más sobre XML no queda responde ¿porque XML es
utilizado en los servicios Web? Si recapitulamos todo los capítulos anteriores seguro ya
tendremos alguna pista para esta pregunta, pero para hacerlo más práctico diremos que se
utiliza XML porque:
z Es un estándar abierto es decir que es reconocido mundialmente ya que muchas

compañías tecnológicas integran en sus software compatibilidad con dicho lenguaje. Esto
quiere decir que la gran mayoría de software de escritorio de sistema operativo,
aplicaciones móviles permiten la compatibilidad con XML esto lo hace muy potente a la
hora de permite la comunicación entre distintas plataformas de software y hardware (y si
bien recordamos este es el sentido final de los Servicios Web).
z Simplicidad de sintaxis esto quiere decir que es muy fácil de escribir código en XML y la
representación de los datos es casi entendible por cualquier ser humano. Esto lo hace
muy flexible a la hora de querer reprensar datos de cualquier especie, bastara con contar
con cualquier editor de texto y aprende unas cuantas intrusiones básicas y ya esta en
condiciones de escribir código XML el cual será soportado o entendido por cualquier
aplicación que pueda leer documentos XML. El hecho de que XML sea tan fácil de codificar
y de entender lo hace el lenguaje ideal para utilizarlo en los servicios Web.
z Independencia del protocolo de Transporte, el hecho de que XML es un lenguaje de
Marcado de Texto, no necesita de ningún protocolo de trasporte especial, solo necesita de
un protocolo que pueda trasferir texto o documentos simples. Esto nos trae a la memoria
que en mercado existen muchos protocolos con estas característica como lo son los mas
conocidos en HTTP y SMTP por nombrar algunos. Volviendo la tema de los servicios Web
una de las característica de estos es la independencia del protocolo de trasporte.
WSDL para la documentación de Servicios Web

El esquema XML por sí solo no puede describir totalmente un Servicio Web. Supongamos que se
ha creado un servicio Web Calculadora. Este servicio Web expone los métodos sumar y restar.
Ambos métodos aceptan dos enteros y devuelven un único entero con el resultado; sumar
devuelve la suma de los dos enteros y restar devuelve su diferencia.
En un esfuerzo para describir cómo interacciona un cliente con el servicio Web se define un
esquema para los mensajes que se intercambiarán entre el cliente y el servidor. El esquema
contiene una definición de un tipo de complejo para los mensaje de petición y repuesta para los
métodos sumar y restar. Recuerde que el objetivo último es que los desarrolladores no tengan
que investigar en las definiciones del esquema intentando descifrar cómo interaccionar con el
servicio Web. En lugar de ello se quiere describir el servicio de forma que una herramienta
pueda descifrarlo y crear un proxy por el cliente.
Además de la información que proporciona el esquema, ¿Qué más necesita conocer el cliente
para invocar los métodos que expone el Servicio Web Calculadora? Como el cuerpo de un
mensaje de SOAP puede contener cualquier cosa que no invalide el XML los mensajes de SOAP
se pueden combinar para disponer de una amplia variedad de patrones de intercambio de
mensajes. Los patrones de intercambio de mensajes para el Servicio Web Calculadora son
bastante inmediatos pero una asociación formal entre los mensajes de petición Sumar y Restar
y sus mensajes de respuesta asociados eliminarían cualquier posible ambigüedad.
Una descripción formal de los patrones de mensaje resulta aún más importante en el caso de
Servicio Web más complejos. Algunos servicios podrían aceptar una petición pero no enviar la
respuesta correspondiente devuelta al cliente. Otros podrían solamente enviar mensajes al
cliente.
Además, el esquema no contiene información sobre cómo acceder al Servicio Web. Como SOAP
es independiente del protocolo, se intercambiarán los mensajes entre el cliente y el servidor de
numerosas formas. ¿Cómo se sabe si hay que enviar un mensaje mediante HTTP, SMTP o
cualquier otro protocolo de transporte? Más aún, ¿cómo se sabe la dirección la que hay que
enviar el mensaje?
El lenguaje de descripción de servicios Web (WSDL, Web Service Description Language) es un

dialecto basado en XML sobre el esquema que describe un servicio Web. Un documento WSDL
proporciona la información necesaria al cliente para interaccionar con el servicio Web. WSDL es
extensible y se pude utilizar para describir, prácticamente, cualquier servicio de red, incluyendo
SOAP sobre HTTP e incluso protocolos que no se basan en XML como DCOM sobre UDP.
Dado que los protocolos de comunicaciones y los formatos de mensajes están estandarizados
en la comunidad del Web, cada día aumenta la posibilidad e importancia de describir las
comunicaciones de forma estructurada. WSDL afronta esta necesidad definiendo una gramática
XML que describe los servicios de red como colecciones de puntos finales de comunicación
capaces de intercambiar mensajes. Las definiciones de servicio de WSDL proporcionan
documentación para sistemas distribuidos y sirven como fórmula para automatizar los detalles
que toman parte en la comunicación entre aplicaciones.
Los documentos WSDL definen los servicios como colecciones de puntos finales de red o
puertos. En WSDL, la definición abstracta de puntos finales y de mensajes se separa de la
instalación concreta de red o de los enlaces del formato de datos. Esto permite la reutilización
de definiciones abstractas: mensajes, que son descripciones abstractas de los datos que se
están intercambiando y tipos de puertos, que son colecciones abstractas de operaciones. Las
especificaciones concretas del protocolo y del formato de datos para un tipo de puerto
determinado constituyen un enlace reutilizable. Un puerto se define por la asociación de una
dirección de red y un enlace reutilizable; una colección de puertos define un servicio. Por esta
razón, un documento WSDL utiliza los siguientes elementos en la definición de servicios de red:
z Types: contenedor de definiciones del tipo de datos que utiliza algún sistema de tipos (por
ejemplo XSD).
z Message: definición abstracta y escrita de los datos que se están comunicando.
z Operation: descripción abstracta de una acción admitida por el servicio.
z Port Type: conjunto abstracto de operaciones admitidas por uno o más puntos finales.
z Binding: especificación del protocolo y del formato de datos para un tipo de puerto
determinado.
z Port: punto final único que se define como la combinación de un enlace y una dirección de
red.
z Service: colección de puntos finales relacionados.
A continuación se detalla un poco más en profundidad cada uno de estos elementos
Elemento types
El elemento Types contiene información de esquema referenciado en el documento WSDL. El

sistema de tipos predeterminado que admite WSDL es de esquema de XML. Si se usa esquema
de XML para definir los tipos que contiene el elemento Types el elemento schema aparecerá
inmediatamente como elemento hijo.
Se puden utilizar otros sistemas de tipo tipos por extensión. Si desea, utilizar otro sistema de
tipo pude aparecer un elemento de extensibilidad bajo el elemento Types. El nombre de este
elemento debería identificar el sistema de tipos utilizados. En este capítulo se limitará a tratar
el esquema de XML porque es el sistema de tipos dominante en los documento WSDL.
Elemento message
El elemento Message proporciona una abstracción común para el paso de mensajes entre el
cliente y el servidor. Como puede utilizar múltiples formatos de de definición de esquema en
documento WSDL es necesario de disponer de un mecanismo común de identificar los
mensajes. El elemento Message proporciona este nivel común de abstracción al que se hará
referencia en otras partes del documento WSDL.
Pude Aparecer, y normalmente aparecerán, múltiples elementos Message en un documento

WSDL, uno para cada mensaje que se comunica entre el cliente y el servidor. Cada mensaje
contiene uno o más elementos "Part" que describen las piezas del contenido del mensaje. Un
ejemplo de una parte es el cuerpo de un mensaje de SOAP o un parámetro que forma parte de
una cadena de petición, un parámetro codificado en el cuerpo del mensaje de SOAP o todo el
cuerpo de un mensaje de SOAP.
Elemento portType
El elemento porType contiene un conjunto de operaciones abstractas que representan los tipos
de correspondencia que pueden producirse entre el cliente y el servidor. Para los Servicios Web
de estilo RPC se pude pensar en un porType como una definición de internas en donde cada
método se pude definir como una operación.
Un tipo puerto se compone de un conjunto de electos operation que define una determinada
acción. Los electos operation se componen de mensajes definidos en el documento WSDL.
WSDL define cuatro tipos de operaciones denominadas tipo operaciones:
z Request-response(petición-respuesta) comunicación del tipo RPC en la que le cliente

realiza una petición y el servidor envía la correspondiente respuesta.
z One-way (un-sentido) Comunicación del estilo documento en la que el cliente envía ubn
mensaje pero no recibe una respuesta del servidor indicando el resultado del mensaje
procesado.
z Solicit-response(solicitud-respuesta) La contraria a la operación petición-respuesta. El
servidor envía una petición y el cliente le envía de vuelta una respuesta.
z Notification (Notificación) La contraria a la operación un-sentido el servidor envía una
comunicación del estilo documento al cliente.
Elemento binding
El elemento binding contiene las definiciones de la asociación de un protocolo como SOAP a un

determinado bindingType. Las definiciones binding especifican detalles de formatos del mensaje
y el protocolo. Por ejemplo, la información de asociación especifica si se puede acceder a una
instancia de un portType de forma RPC.
Las definiciones binding también indican el número de comunicaciones de re red que se

requieren para realizar una determinada acción. Por ejemplo, una llamada RPC de SOAP sobre
HTTP podría involucrar un intercambio de comunicación HTTP, pero esa misma llamada sobre
SMTP podría involucrar dos intercambios de comunicaciones de SMTP discretas.
La asociación de logra utilizando elementos de extensión. Cada protocolo tiene su propio

conjunto de elementos de extensión para especificar los detalles del protocolo y el formato de
los mensajes. Para un determinado protocolo los elementos de extensión se suelen utilizar para
decorar las acciones individuales de una operación y la propia operación con la información de
asociación del protocolo. A veces los elementos de extensión se utilizan en el propio nivel
portType.
Elemento service
Un servicio es un grupo de puertos relacionados y se definen en el elemento service. Un puerto

es un extremo concreto de un Servicio Web al que se hace referencia por una dirección única.
Los puertos que se definen en determinado servicio son independientes. Por ejemplo, la salida
de un puerto que no puede utilizarse como una entrada de otro.
Elementos de Extensibilidad
Los elementos de extensibilidad se utilizan para representar determinadas tecnologías. Por

ejemplo, se puede utilizar los elementos de extensibilidad para especificar el idioma en que se
utiliza en el esquema de los elementos types.
El esquema para un determinado conjunto de elementos de extensibilidad se debe definir

dentro de distintos espacios de nombres que WSDL. La definición de los propios elementos
puede contener un atributo wsdl:requiered que indique un valor boolean si el atributo requiered
se establece a true en una definición de elementos una asociación que haga referencia a ese
conjunto concreto de electos de extensibilidad tiene que incluir dicho elemento.
Lo más habitual es que los elementos de extensibilidad se utilicen para especificar

especificación de asociación. La especificación WSDL define conjunto de elementos de
extensibilidad para la asociación SOAP, HTTP GET, HTTP POS, MIME. Sin embargo, la
especificación sólo define las asociaciones para dos de los cuatro tipos de operaciones. Un
sentido y petición repuesta.
UDDI (Universal Description Discovery and Integration)

Hasta ahora, se ha explicado cómo crear un servicio Web en una situación real, describiendo
desde los documentos de diseño iniciales hasta las repercusiones empresariales o la
implementación final. Lógicamente, el siguiente paso consiste en definir cómo se dará a conocer
el servicio Web para que los clientes interesados puedan descubrirlo fácilmente y utilizarlo en
sus aplicaciones. En la actualidad, ya existe un mecanismo de descubrimiento que cumple estos
requisitos: UDDI (Universal Description Discovery and Integration), una iniciativa del sector
para hacer compatible el descubrimiento de servicios Web con todo tipo de tecnologías y
plataformas.
En primer lugar, analizaré las repercusiones de UDDI, desde un punto de vista tanto tecnológico
como empresarial. A continuación, explicaré la relación entre UDDI y WDSL (Lenguaje de

descripción de servicios Web. Por último, describiré el proceso de registro en UDDI y los puntos
que se deben tener en cuenta para maximizar su potencial.
UDDI Un registro global de servicios Web
UDDI es un registro público diseñado para almacenar de forma estructurada información sobre
empresas y los servicios que éstas ofrecen. A través de UDDI, se puede publicar y descubrir
información de una empresa y de sus servicios. Se puede utilizar sistemas taxonómicos
estándar para clasificar estos datos y poder encontrarlos posteriormente en función de la
categorización. Lo más importante es que UDDI contiene información sobre las interfaces
técnicas de los servicios de una empresa. A través de un conjunto de llamadas a API XML
basadas en SOAP, se puede interactuar con UDDI tanto en tiempo de diseño como de ejecución
para descubrir datos técnicos de los servicios que permitan invocarlos y utilizarlos. De este
modo, UDDI sirve como infraestructura para una colección de software basado en servicios
Web.
z ¿Por qué UDDI? ¿Por qué resulta necesario un registro de este tipo? Teniendo en cuenta
que existe una colección de software de miles (quizás millones) de servicios Web, se nos
plantean varias cuestiones difíciles:
z ¿Cómo se descubren los servicios Web?
z ¿Cómo se categoriza la información de forma coherente?
z ¿Cómo repercute esto en la localización?
z ¿Cómo afecta a las tecnologías de propietario? ¿Cómo se puede garantizar la
interoperabilidad del mecanismo de descubrimiento?
z ¿Cómo se puede interactuar en tiempo de ejecución con este mecanismo de
descubrimiento cuando mi aplicación depende de un servicio Web?
La iniciativa UDDI surgió como respuesta a estas preguntas. Varias empresas, incluidas
Microsoft, IBM, Sun, Oracle, Compaq, Hewlett Packard, Intel, SAP y unas trescientas más (para
obtener un listado completo, consulte UDDI: Community [en inglés]), unieron sus esfuerzos
para desarrollar una especificación basada en estándares abiertos y tecnologías no propietarias
que permitiera resolver los retos anteriores. El resultado, cuya versión beta se lanzó en
diciembre de 2000 y estaba en producción en mayo de 2001, fue un registro empresarial global
alojado por varios nodos de operadores en el que los usuarios podían realizar búsquedas y
publicaciones sin coste alguno.
A partir de la creación de esta infraestructura para servicios Web, los datos sobre estos
servicios se pueden encontrar de forma sistemática y confiable en una capacidad universal
totalmente independiente de proveedores. Se pueden llevar a cabo búsquedas categóricas
precisas utilizando sistemas de identificación y taxonómicos extensibles. La integración de UDDI
en tiempo de ejecución se puede incorporar a las aplicaciones. Como resultado, se fomenta el
desarrollo de un entorno de software de servicios Web.
¿Cómo funciona UDDI?
La información de UDDI se aloja en nodos de operador, empresas que se han comprometido a

ejecutar un nodo público conforme a la especificación que rige el consorcio UDDI.org. En la
actualidad existen dos nodos públicos que se ajustan a la versión 1 de la especificación UDDI:
Microsoft aloja uno e IBM el otro. Hewlett Packard se ha comprometido a alojar un nodo bajo la
versión 2 de la especificación. Los operadores del host deben replicar datos entre ellos a través
de un canal seguro, para conseguir la redundancia de la información en el registro UDDI. Se
pueden publicar los datos en un nodo y descubrirlos en otro tras la réplica. Actualmente, la
réplica se produce cada 24 horas. En el futuro, este intervalo entre réplicas se reducirá, ya que
habrá más aplicaciones que dependan de los datos de UDDI.
Resulta importante observar que no existen requisitos de propietario respecto al modo en que
el operador del host implementa su nodo. El nodo sólo se debe ajustar a la especificación UDDI.
El nodo de Microsoft (http://uddi.microsoft.com/default.aspx [en inglés]), por ejemplo, se ha
escrito por completo en C# y se ejecuta en producción en tiempo de ejecución en lenguaje

común .NET Beta 2. El código de base se beneficia claramente de la compatibilidad nativa con
SOAP y de la serialización que ofrecen las clases de sistema .NET. En el lado del servidor, el
nodo del operador Microsoft utiliza Microsoft® SQL Server 2000 como almacén de datos. Creo
que basta con mencionar que IBM utiliza tecnologías diferentes para ejecutar su nodo,
¿verdad?. No obstante, los dos nodos se comportan exactamente igual, ya que se ajustan al
mismo conjunto de llamadas a API XML basadas en SOAP. Las herramientas de los clientes
pueden interoperar con ambos nodos sin problemas. Por eso, el nodo público UDDI constituye
un claro ejemplo de que el modelo de servicios Web XML funciona en entornos heterogéneos.
El próximo paso para comprender la iniciativa UDDI consiste en ver qué datos se almacenan en
UDDI y cómo se estructuran. UDDI es relativamente ligero; se ha diseñado como registro, no
como depósito. La diferencia, aunque sutil, resulta esencial. Un registro redirige al usuario a
recursos, mientras que un depósito sólo almacena información. El registro Microsoft®
Windows® puede servir de ejemplo: contiene las configuraciones y parámetros básicos pero, en
última instancia, su función es la de dirigir la aplicación a un recurso o binario. Buscar un
componente COM basándonos en su Id. de programa nos conducirá a un Id. de clase, que a su
vez nos dirigirá a la ubicación del binario.
UDDI se comporta de forma similar: como el registro de Windows, se basa en identificadores

únicos globales (GUID) para garantizar la capacidad de búsquedas y determinar la ubicación de
recursos. En última instancia, las consultas a UDDI conducen a una interfaz (un archivo .WSDL,
.XSD, .DTD, etc.) o a una implementación (como un archivo .ASMX o .ASP) ubicadas en otro
servidor. Por tanto, UDDI puede responder a este tipo de preguntas:
z "¿Qué interfaces de servicios Web basadas en WSDL se han publicado y establecido para
un sector determinado?"
z "¿Qué empresas han escrito una implementación basada en una de estas interfaces?"
z "¿Qué servicios Web, categorizados de algún modo, se ofrecen actualmente?"
z "¿Qué servicios Web ofrece una empresa determinada?"
z "¿Con quién se debe poner en contacto el usuario para utilizar los servicios Web de una
empresa?"
z "¿Cuáles son los detalles de implementación de un servicio Web concreto?"
WSDL y UDDI
WSDL se ha convertido en una pieza clave de la pila de protocolos de los servicios Web. Por
eso, es importante saber cómo colaboran UDDI y WSDL y por qué la idea de interfaces frente
implementaciones forma parte de cada protocolo. WSDL y UDDI se diseñaron para diferenciar
claramente los metadatos abstractos y las implementaciones concretas. Para entender cómo
funcionan WSDL y UDDI resulta esencial comprender las consecuencias de esta división.
Por ejemplo, WSDL distingue claramente los mensajes de los puertos: los mensajes (la sintaxis
y semántica que necesita un servicio Web) son siempre abstractos, mientras que los puertos
(las direcciones de red en las que se invoca al servicio Web) son siempre concretos. No es
necesario que un archivo WSDL incluya información sobre el puerto. Un archivo WSDL puede
contener simplemente información abstracta de interfaz, sin facilitar datos de implementación
concretos, y ser válido. De este modo, los archivos WSDL se separan de las implementaciones.
Una de las consecuencias más interesantes de esto es que pueden existir varias
implementaciones de una única interfaz WSDL. Este diseño permite que sistemas dispares
escriban implementaciones de la misma interfaz, para garantizar así la comunicación entre
ellos. Si tres empresas diferentes implementan el mismo archivo WSDL y una parte del software
de cliente crea el código auxiliar/proxy a partir de esa interfaz, dicho software se podrá
comunicar con las tres implementaciones con el mismo código de base, cambiando simplemente
el punto de acceso.
UDDI establece una distinción similar entre la abstracción y la implementación con el concepto
de tModels. La estructura tModel, abreviatura de "Technology Model" (modelo de tecnología),
representa huellas digitales técnicas, interfaces y tipos abstractos de metadatos. El resultado de

los tModels son las plantillas de enlace, que son la implementación concreta de uno o más
tModels. Dentro de una plantilla de enlace se registra el punto de acceso de una
implementación particular de un tModel. Del mismo modo que el esquema de WSDL permite
separar la interfaz y la implementación, UDDI ofrece un mecanismo que permite publicar por
separado los tModels de las plantillas de enlace que hacen referencia a ellos. Por ejemplo, un
grupo industrial o de estándares publica la interfaz canónica para un sector particular y, a
continuación, varias empresas escriben implementaciones de esta interfaz. Obviamente, cada
una de estas implementaciones haría referencia al mismo tModel. Los archivos WSDL
constituyen un ejemplo perfecto de tModel de UDDI.
Registro en UDDI
La publicación en UDDI es un proceso relativamente sencillo. El primer paso consiste en
determinar información básica sobre cómo definir la empresa y los servicios en UDDI. El
siguiente paso, una vez determinada esta información, consiste en llevar a cabo el registro, ya
sea mediante programación o a través de una interfaz de usuario basada en el Web. Por último,
se debe probar la entrada para asegurar que se registró correctamente y que aparece tal y
como se esperaba en diferentes tipos de búsquedas y herramientas.
Primer paso: Definir la entrada de UDDI
Partiendo del modelo de datos descrito anteriormente, se debe recopilar cierta información
importante antes de establecer una entrada de UDDI.
Determine los tModels (archivos WSDL) que utilizan las implementaciones del servicio Web.
Al igual que sucede en el desarrollo de un componente COM, el servicio Web se ha desarrollado
a partir de una interfaz existente o de una interfaz de diseño propio. En el caso de un servicio
Web basado en una interfaz WSDL existente, deberá determinar si el archivo WSDL se ha
registrado en UDDI. Si es así, deberá comprobar su nombre y tModelKey, que es el identificador
GUID que generó UDDI cuando se produjo el registro.
Por el contrario, si el servicio Web se basa en un archivo WSDL que no se ha registrado en

UDDI, deberá crear un nuevo tModel para representar esta interfaz. El nombre de este tModel
debería tener un formato URI (identificador de recursos uniforme), como MyCompany-
com:SampleWebService-interface:v1, y señalar a la ubicación del archivo WSDL.
Si su servicio Web es un servicio de Microsoft® Visual Studio® .NET, podrá generar una
descripción WSDL utilizando una cadena de consulta desde el archivo .ASMX (como ). No
obstante, el archivo WSDL generado por Visual Studio .NET se relaciona estrechamente con el
punto de acceso para la invocación del servicio Web, lo cual puede no resultar adecuado cuando
la interfaz del servicio tiene varias implementaciones. Esto no supondrá ningún problema si su
intención es que el archivo WSDL sólo tenga una implementación.
Determine el nombre de la empresa y una breve descripción de la misma en varios idiomas, si

es necesario, así como los contactos principales para los servicios Web que ofrece.
UDDI es compatible con el espacio de nombre xml:lang, lo que permite a las empresas ofrecer
su descripción en varios idiomas. Asimismo, UDDI permite enumerar los contactos, incluyendo
datos como el correo electrónico, el teléfono y la dirección. Esta lista de contactos muestra los
recursos de una empresa con los que se puede poner en contacto en relación con los servicios
Web ofrecidos. Por ejemplo, si un usuario desea comenzar a utilizar el servicio Web deberá
ponerse en contacto con el responsable de relaciones comerciales correspondiente pero, ¿cómo
puede llegar a saber quién es? ¿Existe algún contacto para obtener asistencia técnica a la hora
de utilizar los servicios Web de la empresa? También se debería incluir en la lista a esta
persona.
Determine las categorías e identificaciones adecuadas para la empresa.

Podrá explorar los sistemas taxonómicos compatibles con UDDI actualmente en el nodo
Microsoft UDDI (http://uddi.microsoft.com/default.aspx [en inglés]). Estos sistemas son, por el

momento, North American Industry Classification System (NAICS), Universal Standard Products
and Services Codes (UNSPSC), ISO 3166, Standard Industry Classification (SIC) y GeoWeb
Geographic Classification. Seleccione las categorías que representan de forma más acertada a
su empresa.
Determine los servicios Web que la empresa ofrece a través de UDDI.

A continuación, deberá determinar los servicios Web que desea registrar la empresa en el nodo
público UDDI. ¿Existen varios puntos de acceso para este servicio? ¿Es preciso que los clientes
conozcan otros parámetros y otra información para utilizar el servicio Web?
Resulta importante destacar que no todo el mundo puede obtener acceso a un servicio Web
porque éste se haya registrado en UDDI. A una entrada de registro UDDI le pueden acompañar
medidas de seguridad, autorización y autenticación. No basta que el usuario sepa que existe un
servicio Web para que pueda invocarlo. Puede existir una comunicación fuera de banda entre
empresas antes de permitir el acceso a un servicio Web.
Determine las categorías adecuadas para los servicios.

Los servicios Web se pueden categorizar del mismo modo que las empresas. No obstante, una
empresa se debe categorizar a nivel empresarial, como por ejemplo NAICS: Software Publisher
(51121), y el servicio Web (de reserva hotelera, en este caso) se debería categorizar en el nivel
de servicios, como NAICS: Hotels and Motels (72111).
Segundo paso: Registrar la entrada de UDDI
Una vez finalizada la tarea de definición, el siguiente paso consiste en registrar la empresa.
Deberá obtener una cuenta con un registro UDDI. Esta operación no se puede realizar mediante
programación, ya que deberá mostrar su conformidad con una declaración de condiciones de
uso. El nodo de Microsoft utiliza Passport para la autenticación, así que deberá adquirir una
cuenta de Passport (http://www.passport.com/Consumer/default.asp) para continuar con el
registro.
En este punto se ofrecen dos opciones: puede utilizar la interfaz de usuario Web del nodo de
Microsoft o realizar el registro mediante programación dirigiendo al propio nodo las llamadas a
API de SOAP. Si no piensa modificar la entrada o ésta es relativamente simple, bastará con la
interfaz de usuario Web. No obstante, si pretende actualizar la entrada con frecuencia, o bien,
ésta es más compleja, resulta recomendable realizar el proceso de registro con secuencias de
comandos, utilizando el SDK de Microsoft UDDI. Además, la interfaz de usuario de Microsoft no
está localizada en otros idiomas, así que se deberá registrar mediante programación para
disfrutar esa característica de la API de UDDI.
Tercer paso: Buscar la entrada en UDDI
Es recomendable realizar tres comprobaciones una vez registrada la entrada en UDDI. En

primer lugar, utilizando la interfaz de usuario Web de Microsoft, busque la empresa por su
nombre y categorizaciones para verla entre los conjuntos de resultados devueltos. En segundo
lugar, abra Visual Studio .NET y asegúrese de que aparece en el cuadro de diálogo "Agregar
referencia Web". Si no aparece, se puede deber a que el tModel no se categorizó correctamente
utilizando la taxonomía uddi-org:types descrita anteriormente. Podrá agregar el servicio Web al
proyecto y generar el código proxy basado en el archivo WSDL. Por último, transcurridas 24
horas, la entrada se replicará al nodo de IBM y podrá buscarla con su IU en https://www-
3.ibm.com/services/uddi/protect/find (en inglés).
Para Terminar
UDDI y WSDL funcionan como especificaciones gratuitas que facilitar el desarrollo de una
colección de software basado en servicios Web. WSDL ofrece un modo formal de definir
servicios Web, independientemente del proveedor, que permitirá realizar llamadas a
procedimientos remotos de próxima generación, mientras que UDDI proporciona una amplia
infraestructura estandarizada que permite al usuario describir y descubrir servicios Web.

Mediante la combinación de estos dos estándares, se podrá desarrollar todo un universo de
servicios Web.
¿Son seguros los Servicios Web XML?

Teniendo en cuenta todos los aspectos de seguridad, autenticación y autorización,
confidencialidad e integridad de datos, etc., y el hecho de que la especificación SOAP ni siquiera
menciona la seguridad, es fácil llegar a la conclusión de que la respuesta es negativa. Pero no
hay que subestimar los servicios Web XML de Microsoft®. Hoy en día, se pueden tomar muchas
medidas para crear servicios Web XML seguros.
A la hora de tratar la seguridad en servicios Web XML, es necesario considerar los siguientes
puntos:
z ¿Cuál es nuestro objetivo? Limitar el acceso a servicios Web XML a usuarios autorizados,
evitar que los mensajes puedan ser visualizados por personas no autorizadas, etc.
z ¿Cómo vamos a cumplir con el objetivo deseado? Red, capa de transporte, sistema
operativo, servicio o aplicación.
z ¿Qué nivel de interoperabilidad deseamos y necesitamos en nuestra solución? Local o
global.
z ¿Cómo se puede aumentar la seguridad de los servicios Web XML actuales?
Esto se consigue respondiendo a las preguntas anteriores y, a continuación, aplicando las

mismas técnicas de seguridad que utilizaríamos para cualquier otra aplicación Web:
z Crear conexiones seguras

z Autenticar y autorizar la interacción
Como podrá comprobar seguidamente, estas técnicas ofrecen varias opciones que se pueden
combinar para obtener beneficios adicionales. Por ejemplo, un servidor de seguridad puede
funcionar con servicios Web XML para limitar el acceso a ciertas funcionalidades (métodos)
basándose en la identidad del cliente y las directivas definidas para cada cliente.
Vamos a empezar repasando y entendiendo el funcionamiento de cada una de las opciones

disponibles actualmente para crear una infraestructura segura.
Creación de una infraestructura segura una infraestructura segura es la clave para contar con
servicios Web XML seguros. Microsoft ofrece una amplia gama de tecnologías que, una vez
integradas en un plan general de seguridad, permiten a las empresas proteger eficazmente una
infraestructura informática. Para completar la implementación con éxito, la planeación debe
considerar lo siguiente:
z Tener una idea detallada de los riesgos potenciales del entorno (como virus, intrusos y
desastres naturales.
z Realizar un análisis activo de la relación entre las consecuencias y contramedidas de una
intrusión y los riesgos.
z Crear una estrategia de implementación planeada con detenimiento para integrar las
medidas de seguridad en el conjunto de una red empresarial, basándose en los dos
puntos anteriores.
Creación de conexiones seguras
Uno de los métodos más sencillos para aumentar la seguridad de los servicios Web XML
consiste en asegurarse de que la conexión entre el cliente de servicios Web XML y el servidor es
segura. Esto se puede llevar a cabo mediante varias técnicas, dependiendo de la extensión de
la red y el perfil de actividades de las interacciones. Tres de las técnicas más comunes y
accesibles son: reglas basadas en un servidor de seguridad, SSL (Secure Sockets Layer) y
redes privadas virtuales (VPN.
Si sabe con exactitud qué equipos van a tener acceso a los servicios Web XML, puede utilizar
reglas de servidor de seguridad para restringir el acceso a equipos con direcciones IP conocidas.
Esta técnica resulta particularmente útil si desea restringir el acceso a equipos en una red
privada virtual (por ejemplo, una red LAN/WAN corporativa) y no desea mantener el contenido
de los mensajes en secreto (cifrados. Los servidores de seguridad, como Microsoft Internet
Security and Acceleration (ISA) Server, pueden ofrecer reglas avanzadas basadas en directivas
que proporcionen distintas restricciones para clientes diferentes según su origen o identidad.
Esto resulta de gran utilidad cuando se espera que determinados clientes tengan acceso a
funcionalidades (métodos) diferentes de los mismos servicios Web XML.
Se puede utilizar SSL para establecer conexiones seguras en redes que no son de confianza
(como Internet. SSL cifra y descifra mensajes enviados entre el cliente y el servidor. Al cifrar
los datos, se evita que los mensajes sean leídos por terceros durante la transmisión. SSL cifra
el mensaje del cliente y, a continuación, lo envía al servidor. Una vez que el servidor lo recibe,
SSL lo descifra y comprueba que procede del remitente correcto (proceso que se denomina
autenticación. El servidor, o el servidor y el cliente, pueden tener certificados que se utilizan
como parte del proceso de autenticación y que proporcionan capacidades de autenticación
además del cifrado de la conexión. Aunque es un método muy eficaz para crear comunicaciones
seguras, SSL presenta un coste en rendimiento que debe tenerse en cuenta. Los servicios Web
XML de Microsoft admiten SSL integrado, tanto en clientes como en servidores.
Una red privada virtual es la extensión de una red privada que se conecta a través de redes
compartidas o públicas, como Internet. Las redes virtuales privadas permiten enviar datos entre
dos equipos en una conexión segura. Si bien su funcionamiento es similar a SSL, una red virtual
segura es una conexión punto a punto establecida a largo plazo. De este modo, mejora la
eficacia y permite la comunicación con servicios Web XML, pero requiere que se establezca una
conexión duradera a largo plazo para obtener un rendimiento mayor.
Seguridad en servicios web. Autenticación y autorización.

Interoperabilidad
2 Autenticación y autorización
2.1 Autenticación:
La autenticación es el proceso por el que se comprueba la identidad de alguien o algo, para ver
si es lo que dice ser. Ese "alguien" o "algo" se denomina principal. La autenticación requiere
pruebas de identidad, denominadas credenciales. Por ejemplo, una aplicación cliente puede
presentar una contraseña como sus credenciales. Si la aplicación cliente presenta las
credenciales correctas, se asume que es quien dice ser.
2.2 Autorización:
Una vez que se ha autenticado la identidad de un principal, deben tomarse decisiones sobre la
autorización. El acceso se determina comparando la información del principal con información
de control de acceso, como listas de control de acceso (ACL. Es posible que los clientes tengan
distintos grados de acceso. Por ejemplo, algunos clientes pueden tener acceso total a los
servicios Web XML, mientras que otros estarían autorizados sólo a ciertas operaciones. A
algunos clientes se les permitirá un acceso total a todos los datos, mientras que a otros sólo se
les permitirá acceso a un subconjunto de los datos y otros tendrán acceso de sólo lectura.
Un modo sencillo de implementar servicios Web XML Web consiste en aprovechar las
características de autenticación del protocolo que se utilice para intercambiar mensajes. Para la
mayoría de los servicios Web XML, esto significa aprovechar las características de autenticación
disponibles en HTTP. Microsoft Internet Información Server (IIS) e ISA Server funcionan en
conjunción con Windows 2000 Server y ofrecen soporte para varios mecanismos de
autenticación en HTTP.
z Básica: utilizada para identificación no segura o poco segura de clientes, ya que el

nombre de usuario y la contraseña se envían como texto codificado en base 64, que
puede ser fácilmente descodificado. IIS autorizará el acceso a los servicios Web XML si las
credenciales coinciden con las de una cuenta de usuario válida.
z Básica sobre SSL: igual que la autenticación básica, excepto que el canal de
comunicación está cifrado y protege de ese modo el nombre de usuario y la contraseña.
Una buena opción para entornos en Internet; sin embargo, el uso de SSL influye
negativamente en el rendimiento.
z Implícita: utiliza algoritmos hash para transmitir las credenciales del cliente de forma
segura. Sin embargo, es posible que no sea compatible con todas las herramientas de
desarrollo para generar clientes de servicios Web XML. IIS autorizará el acceso a los
servicios Web XML si las credenciales coinciden con las de una cuenta de usuario válida.
z Autenticación de Windows integrada: resulta útil sobre todo en entornos en Intranet.
Utiliza NTLM o Kerberos. El cliente debe pertenecer al mismo dominio que el servidor o a
un dominio en el que el dominio del servidor confía. IIS autorizará el acceso a los
servicios Web XML si las credenciales coinciden con las de una cuenta de usuario válida.
z Certificados de cliente a través de SSL: requiere que cada cliente obtenga un
certificado. Los certificados se asignan a las cuentas de usuario, que son utilizadas por IIS
para autorizar el acceso a los servicios Web XML. Se trata de una solución viable para
entornos en Internet, aunque el uso de certificados digitales no está muy extendido
actualmente. Es posible que no sea compatible con todas las herramientas de desarrollo
para generar clientes de servicios Web XML. Sólo está disponible en conexiones SSL, de
modo que el rendimiento puede verse afectado.
Desde la perspectiva de alguien que intenta implementar servicios Web XML, una de las
ventajas de utilizar estos mecanismos de autenticación es que no se necesita escribir nuevo
código. IIS/ISA Server completa todo el proceso de autenticación y autorización ACL antes de
llamar a los servicios Web XML. Sin embargo, al implementar el cliente será necesario realizar
algunas tareas adicionales. La aplicación cliente necesitará responder a las peticiones de
autenticación y credenciales del servidor.
Entre los métodos para la implementación de autenticación en servicios Web XML también se
incluyen servicios de terceros, como los que se encuentran en Microsoft® . NET Passport,
características de sesión de Microsoft ASP.NET o la creación de métodos de autenticación
personalizados.
3 Próximamente: Interoperabilidad
Como puede ver, las técnicas habituales para crear aplicaciones Web seguras se pueden aplicar
por separado o combinadas a la hora de proteger servicios Web XML. Estas técnicas ya se han
utilizado en el pasado y resultan bastante efectivas. Sin embargo, no ofrecen una solución
integrada dentro de la arquitectura de servicios Web XML. Conforme aumenta la complejidad
del entorno de servicios Web XML (sobrepasando los límites de la confianza, extendiéndose a
múltiples sistemas o empresas) los responsables de implementarlos tienen que recurrir a
soluciones personalizadas que, si bien resultan eficaces, no ofrecen una interoperabilidad total.
Para hacer frente a estas necesidades y mejorar la interoperabilidad entre servicios Web XML,
Microsoft y sus socios están trabajando en un conjunto de especificaciones de seguridad
basadas en el mecanismo de extensibilidad de la especificación SOAP para ofrecer funciones de
seguridad mejoradas e integradas en el núcleo mismo de los servicios Web XML.
Una de las principales especificaciones que se están desarrollando es el lenguaje de seguridad

de servicios Web XML (WS-Security) que proporciona mejoras en la mensajería SOAP,
consistentes en tres funcionalidades: transferencia de credenciales, integridad de mensajes y
confidencialidad. Estas funcionalidades no proporcionan por sí mismas una solución de
seguridad completa; WS-Security es una pieza que se puede utilizar en conjunción con la
infraestructura y otros protocolos de servicios Web XML para hacer frente a un gran número de
requisitos de seguridad de aplicaciones. La arquitectura de servicios Web XML globales de
Microsoft alberga a WS-Security y otras especificaciones relacionadas y proporciona un marco
para la evolución de la infraestructura de los servicios Web XML.
El Futuro de los Servicios Web XML

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.
Introducción al entorno de desarrollo de Microsoft .NET

1 El nuevo modelo de computación distribuida en Internet.
Nos encontramos en un momento especial en la industria de computación. Estamos en el inicio

de una nueva manera de hacer y de integrar las aplicaciones.
Algunos gurús de la industria de computación vaticinan que este cambio ser equivalente al que
produjo la introducción de la PC, la interfase visual o al surgimiento mismo de Internet.
Dispositivos móviles como celulares, TabletPC (PCs que parecen un cuaderno de notas pero
tienen la capacidad de una computadora de escritorio), hasta televisores u otros dispositivos
hogareños estarán conectados entre sí, con servidores y distintas aplicaciones. El elemento
integrador será Internet. Estamos ahora en el inicio de la tercera generación de Internet. Con
Visual Studio .NET y ASP.NET Web Matrix vamos a ser protagonistas del cambio.
El tema de fondo es romper barreras. Barreras entre distintas aplicaciones que tienen
información, barreras entre sistemas, barreras entre los sistemas y la gente que los utiliza,
barreras entre las organizaciones.
¿Cómo se llega a este nuevo modelo de computación?
La década de los 80's fue marcada por el surgimiento de la PC y de la interfase grafica. En la

década de los 90's Internet permitió conectar computadoras en una escala global. En principio
la conexión fue entre PCs y servidores por medio del explorador de Internet. A comienzos de
este siglo es clara la necesidad de permitir a las computadoras conectadas a Internet
comunicarse entre ellas. Desde entonces se va dando forma al nuevo modelo de computación
distribuida llamado servicios Web basados en XML. El objetivo es permitir comunicarse entre sí
a sistemas heterogéneos dentro y fuera de la empresa. Esta comunicación es independiente del
sistema operativo, lenguaje o modelo de programación. Para conseguir esto se desarrollaron
estándares. El consorcio de Internet http://www.w3c.org fue el encargado de crear y mantener
estos estándares.
Estos son algunos de los estándares que permiten hacer uso de los Servicios Web basados en
XML:
z XML: (Lenguaje de Marcado eXtensible) Es un formato universal para representar los

datos.
z SOAP: (Protocolo Simple de Acceso a Objetos) Es un protocolo que permite mover los
datos entre aplicaciones y sistemas. Es el mecanismo por medio del cual los servicios Web
son invocados e interactúan.
z UDDI: (Descubrimiento, Descripción e Integración Universal) Lenguaje que permite
publicar, encontrar y usar los Servicios Web basados en XML. Es la 'Página Amarilla' de
los servicios Web es decir un directorio para poder encontrarlos. Puede ser accedido con
un explorador en http://www.uddi.org o programáticamente ya que UDDI es también un
servicio Web.
z WSDL: (Lenguaje de Descripción de Servicios Web) Lenguaje por medio del cual un
servicio Web describe entre otras cosas qué hace o qué funcionalidad implementa.
z La competencia en la industria de software no pasa por imponer el protocolo sobre el cual
se va a construir la nueva generación de Internet, debido a que están ya establecidos
(aunque en continuo desarrollo).
Nadie discute tampoco la importancia del uso de los servicios Web, toda la industria de software
esta enfocada a ello. La competencia es por proveer de las mejores herramientas basadas en
estándares y las más fáciles y más productivas herramientas para construir las aplicaciones. La
plataforma .NET es la infraestructura, los servicios y productos que Microsoft ofrece.
Antes de la adopción del modelo de Servicios Web basados en XML los datos eran 'islas' que se
encontraban dentro de las aplicaciones en las empresas. Era muy difícil y costoso implementar
soluciones para acceder a la información desde afuera de la aplicación y la empresa. Las
aplicaciones pueden ahora, comunicarse entre sí y con los sistemas de sus socios, proveedores
y clientes gracias a los Servicios Web y XML.
En resumen, con el uso de los servicios Web se integra la información que puede ser accedida
desde distintos dispositivos, desde distintas plataformas de hardware o software y que puede
estar guardada en distintos formatos. El lenguaje estándar para lograr esta integración es XML.
Todos los servidores corporativos de .NET entienden este lenguaje. Siguientes versiones de
estos servidores van a incorporar muchas mejoras en este aspecto. Ejemplo de esto es la
siguiente versión de SQL Server 2000 llamada Yukon. Este producto puede guardar datos en
formato nativo XML, además permite hacer consultas al servidor no solamente en el lenguaje
típico de bases de datos sino también en cualquier lenguaje compatible con la plataforma .NET.
2 ¿Qué es la plataforma .NET?
Provee los cimientos para la nueva generación de software. Utiliza los Servicios Web como un
medio para poder interoperar a distintas tecnologías. Permite conectar distintos sistemas
operativos, dispositivos físicos, información y usuarios. Les da a los desarrolladores las
herramientas y tecnologías para hacer rápidamente soluciones de negocios que involucran
distintas aplicaciones, dispositivos físicos y organizaciones.
FIGURA IX.1: "Esquema general de la Plataforma .NET"
La idea central detrás de la plataforma .NET es la de servicio. Más concretamente software

como servicio y de cómo construir, instalar, consumir, integrar o agregar (en federaciones)
estos servicios para que puedan ser accedidos mediante Internet. Esto es posible debido a que
tenemos la infraestructura de comunicación global que es Internet cada vez más rápida y a un
costo cada vez menor y además, a la capacidad de los procesadores que continúa
incrementándose año tras año. El usuario de Internet puede con un explorador de Internet no
solamente acceder a contenido como texto, imágenes o sonido, también puede hacer uso de
servicios Web. Estos son los bloques de construcción o componentes sobre los cuales se basa el
modelo de computación distribuida en Internet. La plataforma .NET permite usar Internet y su
capacidad de distribución para que los usuarios accedan desde cualquier dispositivo, en
cualquier sistema operativo y lugar a la funcionalidad que los servicios Web proveen.
Los desarrolladores por su parte tienen la infraestructura y herramientas para crearlos y hacer
uso de ellos en programas. Es decir, se trata de aprovechar la capacidad de distribución a gran
escala de Internet para acceder a servicios de software. También se trata de aprovechar el
incremento en la capacidad de procesamiento de los nuevos dispositivos móviles llamados
"Smart Devices" (dispositivos inteligentes) para que el usuario haga uso de la funcionalidad que
proveen los servicios Web con interfases cada vez más sencillas y naturales como la voz o la
escritura.
La siguiente versión del portal MSN, MSN 8, es un ejemplo de software como servicio. Utiliza los
ladrillos de construcción que proveen el servicio Web Passport y .NET Alerts (los cuales
estudiaremos más adelante). Permite además instalar software actualizado mientras se hacen
otras cosas. La actualización de software es un servicio al que hay que subscribirse

independientemente de la plataforma desde la cual se accede.
El nuevo modelo de computación basado en Internet implica que la empresas no solamente

tengan sitios donde el contenido puede ser accedido de manera visual como hasta ahora, con
un explorador de Internet. Si quieren ser exitosas deben crear componentes que implementen
servicios relacionados con su actividad para que usuarios o sitios los integren y utilicen. Por
ejemplo, una aerolínea puede hacer componentes para la reserva de pasajes y desde una
aplicación de una empresa de turismo llamar a este componente. O un usuario desde un
dispositivo móvil (por ejemplo un celular) puede también invocar el componente de reserva de
pasajes aéreos directamente para ver la disponibilidad y hacer reservaciones. La empresa
turística puede exponer un servicio Web que incluya la llamada al servicio Web de la aerolínea.
Cuando un servicio Web llama a otros se crea lo que se llama federación de servicios Web y las
posibilidades funcionales se multiplican.
Componentes de la plataforma .NET.

La plataforma .NET no es un solo producto. Es un conjunto de productos. Desde sistemas
operativos como Windows XP, servidores de aplicaciones como SQL Server 2000, productos de
oficina como Office XP, herramientas de desarrollo como Visual Studio .NET hasta servicios Web
provistos por Microsoft como .NET Passport.
Tanto la invocación de los servicios como su ejecución pueden ser hechas en cualquier
dispositivo y sistema operativo, y accedido desde Internet. Los sitios se comunican entre sí y
acceden a servicios y contenidos sin la intervención humana. Por eso se llama a la nueva
generación de Internet "Internet inteligente".
Los componentes de la plataforma .NET son:
Smart Clients (Clientes Inteligentes): Son dispositivos muy variados. Lo que los hace 'Smart' o
inteligentes es su capacidad para hacer uso de servicios Web.
Sus características son:
z Permiten acceder a la información en el formato apropiado, en cualquier momento y

lugar.
z Hacen uso de Servicios Web.
z Optimizan de distintas maneras la forma en que la información es presentada y
organizada. Por ejemplo: Pueden convertir texto en sonido en un celular o reconocer la
escritura en un TabletPC.
z Proveen de una interfase sencilla y natural para que el usuario acceda a la información.
Pueden utilizar la identidad del usuario, su perfil y datos para adaptar la información que
es presentada.
z Pueden reconocer la presencia de otros dispositivos e intercambiar información.
z Pueden adaptarse a las características de la red donde están. Por ejemplo la velocidad de
transmisión.
z Tienen capacidad de procesamiento propio, y distribuyen el procesamiento en la red
haciendo uso de los servicios Web.
Ejemplo de estos son:
z PocketPC (PC de bolsillo)

z SmartPhone (Teléfono Inteligente)
z HandHelds
z TabletPC
z XBox (Consola de juegos de Microsoft)
PCs: Las computadoras personales.
NoteBooks: Las computadoras portátiles.
Y muchos otros dispositivos en desarrollo. Además:
Servidores: Proveen de la infraestructura para implementar el modelo de computación

distribuida en Internet. Son sistemas operativos y de aplicación.
Sistemas Operativos: Windows 2000: Server, Advance Server y Datacenter, Windows Server
2003: Standard, Enterprise, Datacenter y Web Server.
Servidores .NET Corporativos:
z Microsoft Application Center 2000: Para instalar y administrar aplicaciones Web altamente
disponibles y escalables.
z Microsoft BizTalk Server 2000 : Para construir procesos de negocios basados en XML a
través de distintas aplicaciones y organizaciones.
z Microsoft Commerce Server 2000: Para construir rápidamente soluciones de e-commerce
escalables.
z Microsoft Content Management Server 2001: Para administrar contenido para sitios Web
de e-bussines dinámicos.
z Microsoft Exchange Server 2000: Para permitir enviar mensajes y trabajar en forma
colaborativa en cualquier momento y lugar.
z Microsoft Host Integration Server 2000: Para acceder a datos y aplicaciones en
mainframes.
z Microsoft SQL Server 2000: Para almacenar, recuperar y analizar datos en formato XML.
z Microsoft SharePoint Portal Server 2001: Para encontrar, compartir y publicar información
de negocios.
z Microsoft Internet Security and Acceleration Server 2000: Para conectividad a Internet
rápida y segura.
z Microsoft Mobile Información 2001 Server: Para soportar aplicaciones en dispositivos
móviles como por ejemplo celulares.
Servicios Web basados en XML: Son los bloques de construcción de la tercera generación de
Internet. Algunas de sus características son:
z Permiten a las aplicaciones compartir datos. Son componentes. Es decir, unidades de

código discretas, cada una haciendo una tarea en particular.
z Están basados en el lenguaje universal de intercambio de datos de Internet: XML.
z Pueden ser llamados desde distintos sistemas operativos, plataformas de hardware y
lenguajes de programación.
Herramientas de desarrollo: Visual Studio .NET y el .NET Framework. Ambos permiten al

desarrollador hacer servicios Web basados en XML además de otro tipo de aplicaciones. El .NET
Framework viene incorporado directamente en la nueva línea de sistemas operativos
Windows .NET. Para los dispositivos móviles se llama .NET Compact Framework. Los
componentes de la plataforma .NET pueden interactuar de distintas maneras. Esta
comunicación es permitida por los servicios Web que integran los distintos tipos de dispositivos
y componentes. Analicemos 4 tipos de interacciones posibles:
Cliente con Cliente: Smart Clients o dispositivos pueden proveer de servicios Web y utilizarlos
para permitir que la información este disponible en todo momento y lugar.
Cliente con Servidor: Los servicios Web permiten que un servidor comparta datos con una PC
o un dispositivo móvil vía Internet.
Servidor con Servidor: Una aplicación en un servidor puede programáticamente acceder a

otra aplicación utilizando un servicio Web como interfase.
Servicio con Servicio: Un servicio Web puede invocar a otro, aumentando de esta manera la
funcionalidad disponible.
La plataforma .NET
Es claro entonces que el objetivo de la plataforma .NET es simplificar el desarrollo de
aplicaciones Web. Provee las herramientas y tecnologías para transformar a Internet en una
plataforma de computación distribuida en gran escala. Esta plataforma además soporta los
estándares sobre los cuales se basan los servicios Web.
Figura IX.2: "La Plataforma .NET"
La plataforma .NET utiliza tecnologías existentes, productos modificados para su uso dentro de
la plataforma y elementos nuevos.
Productos existentes: COM.
Microsoft tiene una tecnología para la creación, invocación y uso de componentes llamada COM
(Modelo de Objetos Componentes). Al igual que el protocolo SOAP utilizado para la invocación
de los servicios Web, COM establece las reglas acerca de cómo los objetos deben ser invocados
y cómo deben interactuar. También los componentes COM pueden implementar funcionalidad
similar a la de los servicios Web. Sin embargo tienen dos puntos en contra. Primero: No son
una tecnología estándar. Segundo: No pueden ser utilizados fuera de la barrera de seguridad
que las empresas tienen para su comunicación hacia y desde Internet (firewall). Por lo tanto no
sirven al modelo de computación distribuida en Internet.
Sin embargo, hay muchas soluciones que usan COM en el mercado. La plataforma .NET puede
por medio de clases especiales hacer uso de COM y los objetos COM también pueden hacer uso
de servicios Web. Lo que permite aprovechar la plataforma instalada para el desarrollo de
nuevos proyectos.
Productos Modificados: La familia de sistemas operativos de Windows 2000 fue modificada para
soportar a la plataforma .NET. También todos los productos de servidores de aplicaciones
fueron modificados para permitir la interoperatividad basada en XML.
Elementos Nuevos: BizTalk Server es un producto pensado para entender y manipular datos en
formato XML y para poder transformar datos en XML a otros formatos y viceversa. Permite
coordinar el flujo de información entre aplicaciones dentro de la empresa y también "orquesta"
el flujo de datos con otras empresas.
De ahí que se califique a su función como "orquestación". Algo muy importante actualmente ya
que las distintas aplicaciones deben comunicarse entre sí y muchas veces los formatos de los
datos son incompatibles. El .NET Framework es una tecnología nueva de Microsoft y por su
importancia merece que la estudiemos con detenimiento
El .NET Framework
El .NET Framework se instala como un componente aparte en Windows 2000, mientras que
Windows XP y las futuras versiones de Windows lo incorporan directamente al sistema
operativo. Como por ejemplo Windows Server 2003 o Windows .NET CE.
El .NET Compact Framework permite hacer uso de los servicios Web en dispositivos móviles.
Debido a que es un subconjunto del .NET Framework comparte el mismo modelo de
programación y herramientas de desarrollo de aplicaciones haciendo posible que los
desarrolladores transfieran sus conocimientos existentes al desarrollo de aplicaciones móviles.
Figura IX.3 "El Componente del Marco de trabajo .NET "
Los componentes del .NET Framework proveen los "ladrillos" necesarios para construir las
aplicaciones Web, los servicios Web y cualquier otra aplicación dentro de Visual Studio .NET.
Ahora que tenemos una visión general del .NET Framework, vamos a estudiar que función
cumplen las partes que lo componen.
Figura IX.4: "Runtime del Leguaje Común"
El Common Language Runtime provee lo que se llama código administrado, es decir, un entorno
que provee servicios automáticos al código que se ejecuta. Los servicios son variados:
z Cargador de Clases: Permite cargar en memoria las clases.

z Compilador MSIL a nativo: Transforma código intermedio de alto nivel independiente del
hardware que lo ejecuta a código de máquina propio del dispositivo que lo ejecuta.
z Administrador de Código: Coordina toda la operación de los distintos subsistemas del
Common Language Runtime.
z Recolector de Basura: Elimina de memoria objetos no utilizados.
z Motor de Seguridad: Administra la seguridad del código que se ejecuta.
z Motor de Depuración: Permite hacer un seguimiento de la ejecución del código aún
cuando se utilicen lenguajes distintos.
z Verificador de Tipos: Controla que las variables de la aplicación usen el área de memoria
que tienen asignado.
z Administrador de Excepciones: Maneja los errores que se producen durante la ejecución
del código.
z Soporte de multiproceso (threads): Permite ejecutar código en forma paralela.

z Empaquetador de COM: Coordina la comunicación con los componentes COM para que
puedan ser usados por el .NET Framework.
z Soporte de la Biblioteca de Clases Base: Interfase con las clases base del .NET
Framework.
Figura IX.5: "Librería de Clases .NET"
La librera de clases base son las clases sobre las cuales se construyen todas las demás clases
que utilizan los programas de Visual Studio .NET. La clase madre de todas es System. A partir
de ella por un mecanismo llamado herencia de clases, se construyen las demás clases.
Debido a que en la librería de clases base hay muchas clases, se utiliza para identificarlas un
mecanismo llamado espacio de nombres (namespace). La parte del nombre de la clase que se
encuentra a la derecha del último punto se llama tipo de la clase. Todo lo que resta se llama
espacio de nombres. Por ejemplo: En la clase llamada System.Runtime.InteropServices,
InteropServices es el tipo de la clase y System.Runtime es el espacio de nombre. El espacio de
nombre es una manera de organizar en grupos las distintas clases. Esto hace más manejable y
fácil su uso.
La librera de clases base es independiente del lenguaje. Permite el uso y la depuración de otros
lenguajes. Es extensible ya que por el mecanismo de herencia el usuario puede crear nuevas
clases que usan las clases base como "ladrillos". También el usuario puede incorporarlas en
bibliotecas para su utilización posterior. Es segura ya que es posible permitir o restringir su uso
por medio de distintos mecanismos de seguridad.
Cómo funciona el .NET Framework.
Cuando usted crea una aplicación Windows en algún lenguaje compatible con la
plataforma .NET, puede utilizar cualquiera de los servicios que la biblioteca de clases de .NET
provee. Por ejemplo: Puede usar clases para hacer ventanas que tengan distintos tipos de
controles. Cuando compila la aplicación, se crea un código intermedio llamado MSIL. Este
código es independiente de la plataforma de hardware. Una vez compilado, el ejecutor de
lenguaje común administra la ejecución de la aplicación.
Figura IX.6: "Funcionamiento del .NET Framework."
Uno de los subsistemas del Common Language Runtime se llama compilación JIT, que transforma el código intermedio
MSIL al código de máquina en el sistema donde la aplicación se va a ejecutar. Esta compilación a lenguaje de máquina
lo hace en el momento de ejecución del código. Cuando un dispositivo de cliente, por ejemplo, un celular "Smart
phone", ejecuta una aplicación hecha con Visual Studio .NET, se ejecuta en el código de máquina del sistema del
cliente. La aplicación sin embargo puede interactuar con otras aplicaciones .NET y servicios independientemente del
lenguaje en que fueron desarrollados.
Desarrollo y consumo de un Web Services con Microsoft Visual

Studio .Net
1 Introducción.
El objetivo de la actividad es presentar fundamentos teóricos generales relativos a la tecnología de webservices, y como
puede ser implementada en los escenarios más comunes con que nos encontraremos.
Como implementación, comenzaremos construyendo un webservice muy sencillo, el cual será testado a través del
browser.
Desarrollaremos aplicaciones cliente (consumidoras) del Web Service, como:
z Página ASP.Net
z Aplicación Windows .Net
z Aplicación Excel de Office XP
z Aplicación de Internet Mobile
z Aplicación Visual Basic 6.0
Requerimientos
Software
Servidor - Webservice
z Windows 2000, XP, superior

z Internet Information Service
z .Net Framework (SDK)
Desarrollo Webservice
z Visual Studio .Net

o
z Notepad.
Cliente webservice (Consumidor)
z MS SoapToolkit
z Office XP
o
z Webservice referente toolkit (para creación del Proxy)
2 Implementación
Desarrollando un webservice
1.) En Visual Studio .Net, creamos un proyecto ASP.Net Webservices, llamado "WorkShopUDP_v1"
2.) Eliminar los comentarios (comilla simple) del método HelloWorld() de la clase - service1.
3.) Cambiamos el nombre de la "Service1" por "Saludo"
Antes:
Imports System.Web.Services
<WebService(Namespace := "http://tempuri.org/")> _
Public Class Service1
Inherits System.Web.Services.WebService
#Region " Web Services Designer Generated Code "
Public Sub New()

MyBase.New()
'This call is required by the Web Services Designer.
InitializeComponent()
'Add your own initialization code after the InitializeComponent() call
End Sub
'Required by the Web Services Designer

Private components As System.ComponentModel.IContainer
'NOTE: The following procedure is required by the Web Services Designer

'It can be modified using the Web Services Designer.
'Do not modify it using the code editor.
<System.Diagnostics.DebuggerStepThrough()> Private Sub InitializeComponent()
components = New System.ComponentModel.Container()
End Sub
Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)

'CODEGEN: This procedure is required by the Web Services Designer
If disposing Then
If Not (components Is Nothing) Then
components.Dispose()
End If
End If
MyBase.Dispose(disposing)
End Sub
#End Region
' WEB SERVICE EXAMPLE

' The HelloWorld() example service returns the string Hello World.
' To build, uncomment the following lines then save and build the project.
' To test this web service, ensure that the .asmx file is the start page
' and press F5.
'
'<WebMethod()> Public Function HelloWorld() As String

'HelloWorld = "Hello World"
'End Function
End Class
Después:
Imports System.Web.Services
<WebService(Namespace:="http://tempuri.org/")> _
Public Class Saludo
Inherits System.Web.Services.WebService
#Region " Web Services Designer Generated Code "
Public Sub New()

MyBase.New()
'This call is required by the Web Services Designer.

'Add your own initialization code after the InitializeComponent() call
End Sub
'Required by the Web Services Designer

'NOTE: The following procedure is required by the Web Services Designer

'It can be modified using the Web Services Designer.
components = New System.ComponentModel.Container()
End Sub

'CODEGEN: This procedure is required by the Web Services Designer
If disposing Then
End If
End If
End Sub
#End Region
' WEB SERVICE EXAMPLE

' The HelloWorld() example service returns the string Hello World.
' To build, uncomment the following lines then save and build the project.
' To test this web service, ensure that the .asmx file is the start page
' and press F5.
' <WebMethod()> Public Function HelloWorld() As String
HelloWorld = "Hello World Marco"
End Function
End Class
4.) Cambiar el nombre del archivo "Service1.asmx" a "mensaje1.asmx" a través del solution Explorer.
Antes:
Después:
5.) Construir la solución.

Ejecutar: "Build Solution"
Menu: Build à "Build Solution", o bien, "Ctrl+Shift+B"
Verificar en IIS que en "Default Web Site" está el sitio http://localhost/WorkShopUDP_v1
3 Testing
Testing del webservice desde el browser

En el browser, abrir la dirección: http://localhost/WorkShopUDP_v1/mensaje1.asmx
Clickar sobre "HelloWorld"
Clickar "Invoke"
Consumo del webservice en aplicación .Net

1.) Crear proyecto Windows Application, llamado "testWebServiceHelloWorld"
2.) Agregamos referencia al webservice al proyecto: En el "Solution Explorer" pulsar botón derecho sobre "References"
y "Add Web Reference" En la barra de direcciones de la ventana, agregar la dirección del webservice creado.
http://localhost/WorkShopUDP_v1/mensaje1.asmx
Pulsando <ENTER>, comprobamos la existencia del webservice en la dirección ingresada.
Agregamos la referencia al proyecto: Click en "Add Reference".

Comprobar en el "Solution Explorer" la referencia agregada, y cambiar el nombre del fólder "localhost" a "wsSaludos"
Antes:
Después:
3.) Comprobamos a través del explorador de Windows la existencia de los archivos "mensaje1.disco" y "mensaje1.wsdl"
existen en el directorio "wsSaludos"
3.) Insertar un botón y un cuadro de texto al formulario
4.) En el código del formulario, importamos en espacio de nombres asociado a la referencia al webservice agregada.
5.) En el código de acción del botón, instanciamos un objeto de la clase "testWebServiceHelloWorld.wsSaludos",

llamado "objWsSaludos".
Dim objWsSaludo As New Saludo()
6.) Luego llamamos el método "HelloWorld" y asignamos su respuesta al TextBox1.
TextBox1.Text = objWsSaludo.HelloWorld()
Finalmente el código queda como:
Imports testWebServiceHelloWorld.wsSaludos
Public Class Form1

Inherits System.Windows.Forms.Form
#Region " Windows Form Designer generated code "
Public Sub New()

MyBase.New()
'This call is required by the Windows Form Designer.

'Add any initialization after the InitializeComponent() call
End Sub
'Form overrides dispose to clean up the component list.

If disposing Then
End If
End If
End Sub
'Required by the Windows Form Designer

'NOTE: The following procedure is required by the Windows Form Designer

'It can be modified using the Windows Form Designer.
Friend WithEvents Button1 As System.Windows.Forms.Button
Friend WithEvents TextBox1 As System.Windows.Forms.TextBox
Me.Button1 = New System.Windows.Forms.Button()
Me.TextBox1 = New System.Windows.Forms.TextBox()
Me.SuspendLayout()
'
'Button1
'
Me.Button1.Location = New System.Drawing.Point(184, 144)
Me.Button1.Name = "Button1"
Me.Button1.Size = New System.Drawing.Size(128, 32)
Me.Button1.TabIndex = 0
Me.Button1.Text = "Aceptar"
'
'TextBox1
'
Me.TextBox1.Location = New System.Drawing.Point(32, 24)
Me.TextBox1.Name = "TextBox1"
Me.TextBox1.Size = New System.Drawing.Size(192, 20)
Me.TextBox1.TabIndex = 1
Me.TextBox1.Text = "TextBox1"
'
'Form1
'
Me.AutoScaleBaseSize = New System.Drawing.Size(5, 13)
Me.ClientSize = New System.Drawing.Size(432, 273)
Me.Controls.AddRange(New System.Windows.Forms.Control() {Me.TextBox1, Me.Button1})
Me.Name = "Form1"
Me.Text = "Form1"
Me.ResumeLayout(False)
End Sub
#End Region
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

TextBox1.Text = objWsSaludo.HelloWorld()
End Sub
End Class
6.) Construimos la solución, y pulsamos F5 para ejecutarla.
Al pulsar el botón, se invoca el webservice y se asigna el resultado al cuadro de texto.

Consumo de un web service desde ASP.Net

Crear un proyecto ASP.Net Web Application
Agregar un botón y un cuadro de texto.
Agregar "Web Reference" al webservice http://localhost/WorkShopUDP_v1/mensaje1.asmx

Cambiar el nombre del directorio "localhost" a "wsSaludos"en el "Solution Explorer"
- En el código del webform, importar el espacio de nombres asociado al webservice.
Imports testWSAsp.wsSaludos
- En el código del botón, instanciar un objeto de la clase "Saludo", invocar la función "HelloWorld" asignando el
resultado al TextBox1.

TextBox1.Text = objWsSaludo.HelloWorld
Imports testWSAsp.wsSaludos
Public Class WebForm1

Inherits System.Web.UI.Page
Protected WithEvents TextBox1 As System.Web.UI.WebControls.TextBox
Protected WithEvents Button1 As System.Web.UI.WebControls.Button
#Region " Web Form Designer Generated Code "
'This call is required by the Web Form Designer.

End Sub
Private Sub Page_Init(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Init

'CODEGEN: This method call is required by the Web Form Designer
End Sub
#End Region
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

'Put user code to initialize the page here
End Sub
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

End Sub
End Class
Construyendo la solución (Build) y ejecutando (F5):
Pulsando el botón:
Consumo de un web service desde aplicación móvil en .net

- Instalar el "Mobile Internet Toolkit" para Visual Studio .NET
- Instalar emulador de aplicación móvil.
1.) Crear proyecto "Mobile Web Application"
2.) Agregar controles móviles TextBox y Command.

3.) Agregar "Web Reference" al webservice http://localhost/WorkShopUDP_v1/mensaje1.asmx
Cambiar el nombre del directorio "localhost" a "wsSaludos"en el "Solution Explorer".
- En el código del Mobile Web Form, importar el espacio de nombres asociado al webservice.
Imports MobileWebWSSaludo.wsSaludos
- En el código del botón, instanciar un objeto de la clase "Saludo", invocar la función "HelloWorld" asignando el
resultado al TextBox1.

Imports MobileWebWSSaludo.wsSaludos
Public Class MobileWebForm1

Inherits System.Web.UI.MobileControls.MobilePage
Protected WithEvents Command1 As System.Web.UI.MobileControls.Command
Protected WithEvents TextBox1 As System.Web.UI.MobileControls.TextBox
Protected WithEvents Form1 As System.Web.UI.MobileControls.Form
#Region " Web Form Designer Generated Code "
'This call is required by the Web Form Designer.

End Sub
Private Sub Page_Init(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Init

'CODEGEN: This method call is required by the Web Form Designer
End Sub
#End Region

'Put user code to initialize the page here
End Sub
Private Sub Command1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles

Command1.Click
End Sub
End Class
Construyendo la solución (Build).
Abrir el emulador abriendo la dirección de la página Mobiul Web Form.
Consumo de un web service desde Excel XP

Instalar "Soap Toolkit"
Instalar Office Webservices Referece Toolkit
1.) En el editor de Visual Basic
Menu: Tools à Macro à Visual Basic Editor, o bien, Alt+F11 2.) Usando el webservice referente tool, agregar referencia
al webservice Menu: Tools à Webservice Referentes
Agregar URL asociada: http://localhost/WorkShopUDP_v1/mensaje1.asmx Pulsar "Search"

Agregar la referencia, seleccionando el checkBox y pulsar "Add"
Esto ha creado el módulo de clase "clsws_Saludo" (Proxy al Webservice) Ver Explorador del proyecto.
Insertar un módulo: Menu: Insert à Module
Agregar la función publica siguiente al módulo insertado:
Public Function HelloMarco() As String Dim objWS As New clsws_Saludo HelloMarco = objWS.wsm_HelloWorld End
Function
Probar la nueva function (HelloMarco) desde la planilla Excel.
Implementar código de Seguridad anti robots en ASP.NET

Para crear un código de seguridad seguiremos los siguientes pasos:
Tenemos que agregar en el formulario que deseamos insertar el código de seguridad los siguientes controles:
z Una imagen (dónde su scr será /AntiRobots.aspx)

z Un input de tipo texto, con un id= type= frm_Codigo_Seguridad
En el código VB de la página del registro declararemos una variable llamada bAntiBots
#Region "Members"
Dim bAntiBots As Boolean = False
#End Region
En el Page_Load:
If Not IsPostBack Then

Session("AntiBots") = GenerateRandomCode()
Else
'Comprobamos el código antibots
If frm_Codigo_Seguridad.Value = Session("AntiBots").ToString() Then
bAntiBots = True
Else
bAntiBots = False
Me.Session("AntiBots") = GenerateRandomCode()
End If
End If
Tenemos que crear la función GenerateRandomCode para generar un código de seguridad al azar
#Region "GenerateRandomCode"
Private Function GenerateRandomCode() As String

Dim random As New Random
Dim s As String = ""
Dim i As Int32 = 0
Dim iChr As Int32
While (i <; 6)
iChr = random.Next(48, 90)
While iChr >; 57 And iChr <; 65
iChr = random.Next(48, 90)
End While
s = String.Concat(s, Chr(iChr).ToString())
i=i+1
End While
Return s
End Function
#End Region
Para seguir, nos faltará crear la clase encargada de crear, manipular y deformar el código de seguridad generado en
imagen
Imports System
Imports System.Drawing
Imports System.Drawing.Drawing2D
Imports System.Drawing.Imaging
Imports System.Drawing.Text
Public Class ImagenAntiBots
Dim m_text As String

Dim m_width As Int32
Dim m_height As Int32
Dim m_familyName As String
Dim m_image As Bitmap
Dim m_random As New Random
#Region "Propiedades de lectura"
Public ReadOnly Property Text() As String

Get
Return m_text
End Get
End Property
Public ReadOnly Property Width() As Int32

Get
Return m_width
End Get
End Property
Public ReadOnly Property Height() As Int32

Get
Return m_height
End Get
End Property
Public ReadOnly Property Image() As Bitmap

Get
Return m_image
End Get
End Property
#End Region
Public Sub New(ByVal s As String, ByVal width As Int32, ByVal height As Int32)
Me.m_text = s
Me.SetDimensions(width, height)
Me.GenerateImage()
End Sub
Public Sub New(ByVal s As String, ByVal width As Int32, ByVal height As Int32, ByVal familyName As String)
Me.m_text = s
Me.SetDimensions(width, height)
Me.SetFamilyName(familyName)
Me.GenerateImage()
End Sub
Private Sub SetDimensions(ByVal width As Int32, ByVal height As Int32)

If width <;= 0 Then
Throw New ArgumentOutOfRangeException("width", width, "Argument out of range, must be greater than zero.")
End If
If (height <;= 0) Then
Throw New ArgumentOutOfRangeException("height", height, "Argument out of range, must be greater than zero.")
End If
Me.m_width = width
Me.m_height = height
End Sub
Private Sub SetFamilyName(ByVal familyName As String)

Try
Dim font As Font = New Font(familyName, 12.0F)
Me.m_familyName = familyName
font.Dispose()
Catch ex As Exception
Me.m_familyName = System.Drawing.FontFamily.GenericSerif.Name
End Try
End Sub
Private Sub GenerateImage()

Dim bitmap As New Bitmap(Me.m_width, Me.m_height, PixelFormat.Format32bppArgb)
'Creamos objeto grafico

Dim g As Graphics = Graphics.FromImage(bitmap)
g.SmoothingMode = SmoothingMode.AntiAlias
Dim rect As New RectangleF(0, 0, Me.m_width, Me.m_height)
'Rellenamos el fondo
Dim hatchBrush As New HatchBrush(HatchStyle.SmallConfetti, Color.LightGray, Color.White)
g.FillRectangle(hatchBrush, rect)
'Establecemos la fuente
Dim size As SizeF
Dim fontSize As Single = rect.Height + 1
Dim font As Font
'Ajusta el tamaño de la fuente
Do
fontSize = fontSize - 1
font = New Font(Me.m_familyName, fontSize, FontStyle.Bold)
size = g.MeasureString(Me.m_text, font)
Loop While (size.Width >; rect.Width)
'Establece el formato de texto

Dim format As New StringFormat
format.Alignment = StringAlignment.Center
format.LineAlignment = StringAlignment.Center
Dim path As New GraphicsPath

path.AddString(Me.m_text, font.FontFamily, CType(font.Style, Int32), font.Size, rect, format)

Dim v As Single = 4.0F
Dim points As System.Drawing.PointF() = { _

New System.Drawing.PointF(m_random.Next(CType(rect.Width, Integer)) / v, m_random.Next(CType(rect.Height,
Integer)) / v), _
New System.Drawing.PointF(rect.Width - m_random.Next(CType(rect.Width, Integer)) / v, m_random.Next(CType
(rect.Height, Integer)) / v), _
New System.Drawing.PointF(m_random.Next(CType(rect.Width, Integer)) / v, rect.Height - m_random.Next(CType
(rect.Height, Integer)) / v), _
New System.Drawing.PointF(rect.Width - m_random.Next(CType(rect.Width, Integer)) / v, rect.Height -
m_random.Next(CType(rect.Height, Integer)) / v)}
Dim matrix As New Matrix

matrix.Translate(1, 3)
'Deformamos la imagen
path.Warp(points, rect, matrix, 0)
'Dibuja el texto
hatchBrush = New HatchBrush(HatchStyle.OutlinedDiamond, Color.Orange, Color.BlueViolet)
g.FillPath(hatchBrush, path)
'Añade efectos
Dim m As Int32 = Math.Max(CType(rect.Width, Integer), CType(rect.Height, Integer))
Dim i As Int32 = 0
While i <; CType((rect.Width * rect.Height / 30.0F), Int32)
Dim x As Int32 = m_random.Next(CType(rect.Width, Integer))
Dim y As Int32 = m_random.Next(CType(rect.Height, Integer))
Dim w As Int32 = m_random.Next(CType(m / 50, Integer))
Dim h As Int32 = m_random.Next(CType(m / 50, Integer))
g.FillEllipse(hatchBrush, x, y, w, h)
i=i+1
End While
font.Dispose()
hatchBrush.Dispose()
g.Dispose()
'Establece la imagen
Me.m_image = bitmap
End Sub
End Class
Ahora en el proyecto crearemos la página que apunta nuestra imagen (el primer control que hemos agregado en el
proyecto, y en el Page_Load pondremos este código:

'Creamos una imagen creando el texto guardado en la sesion
Dim ab As New ImagenAntiBots(Session("AntiBots").ToString(), 200, 50, "Arial")
'Cambiamos la respuesta al cliente a tipo "imagen/jpeg"

Me.Response.Clear()
Me.Response.ContentType = "image/jpeg"
'Salvamos la imagen en el Response

ab.Image.Save(Me.Response.OutputStream, ImageFormat.Jpeg)
End Sub
Y para terminar, en el formulario del registro, dónde hemos agregado los controles, en el botón del submit, utilizar esta
condición:
If bAntiBots Then
' Creamos el registro
Else
' El código de seguridad no está bien colocado
End if
Puedes descargarte todo el código fuente de pulsando aquí.

[http://www.mistrucos.net/ficheros/trucos/652/antirobots.zip]
Autores del manual:

Hay que agradecer a diversas personas la dedicación prestada para la creación de este manual. Sus nombres junto con
el número de artículos redactados por cada uno son los siguientes:
z Benjamín González C.
Ingeniero de Sistemas
(21 capítulos)
z Pol Salvat
http://www.mistrucos.net/
(1 capítulo)
Todos los derechos de reproducción y difusión [http://www.desarrolloweb.com/copyright/] reservados a Guiarte

Multimedia S.L. [http://www.guiartemultimedia.com/]
Volver [http://www.desarrolloweb.com/manuales/54]

Servicios Web

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Servicios Web

Uploaded by

Copyright:

Available Formats

Servicios Web en plataforma .

NET - Manual completo Página 1 de 52

Introdución a los servicios web

A mediado de la década de los 90 y con la aparición de Internet y su posterior masificación a

Debido a la gran masificación de Internet a niveles insospechables y al gran impacto causado

Conocer y entender el significado y alcance le los Servicios Web XML.

Dimensionar los nuevos cambios de paradigmas informáticos producto de la

Ampliar el conocimiento de todas las tecnologías asociadas a los Servicios Web.

Una visión general I

La funcionalidad de los protocolos empleados es la siguiente:

Aunque la idea de la programación modular no es nueva, el éxito de esta tecnología reside en

es muy amplio. Pero también tiene sus puntos oscuros:

Una visión general II

Actualmente ya existen en el mercado algunas herramientas específicamente diseñadas para

z Microsoft: Recientemente ha anunciado la disponibilidad de su primer web service,

Conceptos e ideas de Web Services

XML Web Services

Requisitos de un Web Service

z Interoperabilidad: Un servicio remoto debe permitir su utilización por clientes de otras

hecho, no se bebería requerir el comprar, instalar o mantener una infraestructura de

Bloques Constructivos de Servicios Web

En el siguiente grafico se muestran los bloques constructivos principales necesarios para

Figura II.1: "Bloques constructivos de Servicios Web"

z Descubrimiento: La aplicación cliente que necesita acceder a la funcionalidad que

NetBEUI y NetBIOS sobre IPX.

SOAP (Simple Object Access Protocol)

Algunas de las Ventajas de SOAP son:

z No esta asociado con ningún lenguaje: los desarrolladores involucrados en nuevos

Anatomía de un mensaje de SOAP

SOAP proporciona un mecanismo estándar de empaquetar un mensaje. Un mensaje SOAP se

Figura III.1: "Anatomía de un mensaje SOAP"

El elemento raíz del documento es el elemento Envelope. El ejemplo contiene dos

XML: el lenguaje de los Servicios Web

Vista general de XML

Conociendo este sistema y conociendo a la perfección el sistema de marcas de cada aplicación

Los lenguajes de marcas no son equivalentes a los lenguajes de programación aunque se

Su desarrollo se comenzó en 1996 y la primera versión salió a la luz el 10 de febrero de 1998.

Respecto a sus objetivos son:

z XML debe ser directamente utilizable sobre Internet.

z La concisión en las marcas XML es de mínima importancia.

Estructura del XML

XML y Los Servicios Web

z Es un estándar abierto es decir que es reconocido mundialmente ya que muchas

WSDL para la documentación de Servicios Web

El lenguaje de descripción de servicios Web (WSDL, Web Service Description Language) es un

A continuación se detalla un poco más en profundidad cada uno de estos elementos

El elemento Types contiene información de esquema referenciado en el documento WSDL. El

Pude Aparecer, y normalmente aparecerán, múltiples elementos Message en un documento

z Request-response(petición-respuesta) comunicación del tipo RPC en la que le cliente

El elemento binding contiene las definiciones de la asociación de un protocolo como SOAP a un

Las definiciones binding también indican el número de comunicaciones de re red que se

La asociación de logra utilizando elementos de extensión. Cada protocolo tiene su propio

Un servicio es un grupo de puertos relacionados y se definen en el elemento service. Un puerto

Los elementos de extensibilidad se utilizan para representar determinadas tecnologías. Por

El esquema para un determinado conjunto de elementos de extensibilidad se debe definir

Lo más habitual es que los elementos de extensibilidad se utilicen para especificar

UDDI (Universal Description Discovery and Integration)

como empresarial. A continuación, explicaré la relación entre UDDI y WDSL (Lenguaje de

UDDI Un registro global de servicios Web

¿Cómo funciona UDDI?

La información de UDDI se aloja en nodos de operador, empresas que se han comprometido a

escrito por completo en C# y se ejecuta en producción en tiempo de ejecución en lenguaje

UDDI se comporta de forma similar: como el registro de Windows, se basa en identificadores