Manual Completo Servicios Web

Introducin a los servicios web
Toda la informacin disponible para cualquier persona, en cualquier lugar, a travs

de cualquier dispositivo.

Esta frase acua quizs el sueo de todos los que de una u otra forma se relacionan con las
tecnologas de la informacin, partiendo desde una gran compaa tecnolgica hasta un simple
usuario de una planilla Excel. La pregunta es: Ser esto posible?

A mediado de la dcada de los 90 y con la aparicin de Internet y su posterior masificacin a
niveles jams 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 integracin entre
sistemas heterogneos, cuando hablo de sistemas heterogneos me refiero tanto al software
como al hardware. Para tal efecto muchas compaas fueron creando de forma individual la
mejor manera de lograr esta integracin. Muchas empresas comenzaron una loca carrera para
generar la mejor tecnologa integradora de sistemas, pero a medida que la competencia se
hacia cada vez ms fuerte, la integracin se hacia cada vez ms difcil.

Debido a la gran masificacin de Internet a niveles insospechables y al gran impacto causado
por las tecnologas de la informacin en las ultimas dos dcadas del siglo pasado, la manera de
hacer negocios y la comunicacin entre las personas y las empresas cambi de una manera
rotunda. Bajo este contexto se haca cada vez mayor la necesidad de integrar y compartir
informacin 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 raz. Para esto decidieron que en vez de
crear la mejor plataforma integradora, era mejor buscar un leguaje comn de intercambio de
informacin aprovechando los estndares 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 prctica la adopcin e implementacin de dicha tecnologa, tambin
conocer sus principales ventajas as como sus limitaciones desde un punto de vista de una
tecnologa que esta en continuo desarrollo.

Dimensionar los nuevos cambios de paradigmas informticos producto de la
implementacin de Servicios Web.

Esto quiere decir poder dimensionar que esta tecnologa viene a cambiar la forma en que se
comunicaban las distintas aplicaciones y la forma en que se accede a la informacin que reside
en distintas plataformas y aplicaciones desde diversos tipos de equipos y dispositivo de
comunicacin.

Ampliar el conocimiento de todas las tecnologas asociadas a los Servicios Web.
Servicios Web en
plataforma .NET
Manual por: DesarrolloWeb.com [http://www.desarrolloweb.com/]
"Tu mejor ayuda para aprender a hacer webs"
Versin on-line:
http://www.desarrolloweb.com/manuales/54
Pgina 1 de 52 Servicios Web en plataforma .NET - Manual completo

De manera general o detallada conocer las tecnologas asociadas a Servicios Web. Ya que de
alguna manera, ms 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 tecnologa.

La intencin del presente documento no es solo la de explicar el contexto de los Servicios Web,
si no tambin transmitir al lector un numero de nuevos conceptos y tecnologas que en la
actualidad estn en pleno desarrollo y en adopcin 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 informtica se refiere.

Una visin general I

Web Services y la evolucin hacia la Economa Global

Las aplicaciones web actuales ya no son suficientes. El modelo actual de negocio electrnico no
facilita la integracin de las aplicaciones de Internet con el resto de software de las empresas.
Si las compaas quieren extraer el mximo 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, va Internet. Son aplicaciones independientes de la
plataforma que pueden ser fcilmente publicadas, localizadas e invocadas mediante protocolos
web estndar, como XML, SOAP, UDDI o WSDL. El objetivo final es la creacin 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:
XML( eXtensible Markup Language): Un servicio web es una aplicacin web creada en
XML.
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.
SOAP (Simple Object Access Protocol): Permite que programas que corren en diferentes
sistemas operativos se comuniquen. La comunicacin entre las diferentes entidades se
realiza mediante mensajes que son rutados en un sobre SOAP.
UDDI (Universal Description Discovery and Integration): Este protocolo permite la
publicacin y localizacin de los servicios. Los directorios UDDI actan como una gua
telefnica de web services.
Aunque la idea de la programacin modular no es nueva, el xito de esta tecnologa reside en
que se basa en estndares conocidos en los que ya se tiene una gran confianza, como el XML.
Adems, el uso de los web services aporta ventajas significativas a las empresas. El principal
objetivo que se logra, es la interoperabilidad y la integracin. Mediante los web services, las
empresas pueden compartir servicios software con sus clientes y sus socios de negocio. Esto
ayudar a las compaas a escalar sus negocios, reduciendo el coste en desarrollo y
mantenimiento de software, y sacando los productos al mercado con mayor rapidez. La
integracin de aplicaciones har posible obtener la informacin demandada en tiempo real,
acelerando el proceso de toma de decisiones. La evolucin de Internet hacia los web services,
mejorar los resultados globales de las empresas, reduciendo sus gastos y guindolas hacia una
mejora progresiva de la calidad. La adopcin de la tecnologa de servicios web por la industria
es el primer paso hacia una economa global.

Posibles riesgos

Las expectaciones alrededor de esta tecnologa son grandes, porque el mercado de aplicacin
es muy amplio. Pero tambin tiene sus puntos oscuros:
Los web services hacen uso de las mismas tecnologas que han sido atacadas en tantas
ocasiones. Usando web services, la seguridad de una empresa puede verse
comprometida. La ausencia de tcnicas de seguridad estndar es un obstculo para la
adopcin de la tecnologa.
La calidad de un web service es un parmetro que no queda demasiado claro, pero cuya
medida es fundamental a la hora de desarrollar un servicio maduro.

Una visin general II

Seguridad

Actualmente, los web services estn 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 compaa. Los desarrollos
actuales no ayudan a la cooperacin entre las empresas ya que no hay ningn estndar
establecido sobre las tcnicas de seguridad. Debido a la tecnologa que es usada por los web
services, y en concreto al uso de SOAP, las tcnicas de seguridad convencionales que se han
venido usando en Internet, ya no son suficientes. Con SOAP, cada mensaje simple que se
intercambia realiza mltiples saltos y es rutado a travs de numerosos puntos antes de que
alcance su destino final. Es por ello que los web services necesitan tecnologas que protejan los
mensajes desde el principio hasta el final. Existen un conjunto de tcnicas que se pueden usar
para garantizar la seguridad a nivel de mensaje. Estas son:
Encriptacin XML: Evita que los datos se vean expuestos a lo largo de su recorrido.
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.
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.
SAML y la Autorizacin: SAML (Security Assertion Mark-up Language) hace posible que
los web services intercambien informacin de autentificacin y autorizacin entre ellos, de
modo que un web service confe en un usuario autentificado por otro web service.
Validacin de datos: Permite que los web services reciban datos dentro de los rangos
esperados.
Adems, tambin hay tcnicas que permiten mantener la seguridad a otros niveles. La
seguridad en UDDI permite autentificar todas las entidades que toman parte en la publicacin
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 especficamente diseadas para
medir la calidad de los web services, pero sigue siendo necesaria una estandarizacin sobre
este tema. Los resultados sobre la calidad de diferentes web services, servirn como parmetro
de comparacin y ayudarn al consumidor a decantarse por un servicio u otro. Para que un web
service se ejecute con correccin y satisfaga las expectativas creadas, a parte del precio, habr
que tener en cuenta una serie de parmetros 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 integracin. Aunque tericamente los web services proporcionan conectividad con
cualquier software de un modo transparente, cada proveedor de servicios puede adoptar
soluciones diferentes que resultan ms o menos adecuadas para el consumidor. Analizando la
escalabilidad se comprobar el grado de modularidad y flexibilidad del servicio. Por ltimo,
tambin sera interesante analizar las caractersticas que ofrece el proveedor de web services.
Actualmente no hay definidos estndares sobre este tema, pero la mayora de las empresas ya
est demandando algn 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.

Estandarizacin

Los web services estn basados en el estndar XML, que ha sido universalmente aceptado. Pero
la situacin para el resto de protocolos es bien distinta. La mayor parte de ellos se encuentran
todava en desarrollo y pueden ser objeto de cambios. Esa es la razn por la que la mayora de
las empresas estn esperando a que estos protocolos sean ms universales antes de
profundizar en esta tecnologa. Actualmente, ni SOAP, ni WSDL, ni UDDI han sido oficialmente
reconocidos por ningn organismo de estandarizacin. SOAP es el nico que en este momento
est en consideracin por el World Wide Web Consortium y se encuentra cercano a la
estandarizacin. SOAP y WSDL estn siendo ampliamente usados, pero de momento UDDI no
ha tenido el mismo xito. El principal motivo es que las tcnicas de seguridad son todava muy
inmaduras y las compaas prefieren hacer uso de registros privados para dar soporte a
intercambios privados de web services. En febrero de este ao, algunas de las empresas ms
importantes en el desarrollo de Negocio Electrnico como IBM, Intel, Microsoft o Oracle, han
creado el WS-I: organizacin para la Interoperabilidad de los Web Services. El objetivo de dicha
organizacin es la promocin de la estandarizacin de los web services de modo que se fomente
la cooperacin e interoperabilidad entre las compaas y mercados.

Algunos ejemplos

Las principales compaas del mundo han empezado a desarrollar soluciones mediante la
tecnologa de los web services. Algunos ejemplos son:
Microsoft: Recientemente ha anunciado la disponibilidad de su primer web service,
llamado MapPoint .Net. Mediante este servicio, el usuario podr conocer su localizacin
exacta y otros datos adicionales relacionados con su posicin actual, como informacin de
trfico, rutas posibles o puntos comerciales cercanos.
IBM: Ha implementado una solucin basada en los web services llamada e-Business on
Demand. Esta solucin permite la construccin de Extranets que ayuden a las empresas a
ver los catlogos de productos, realizar y localizar pedidos o chequear el estado del
inventario en tiempo real.
Lneas Areas Escandinavas: Estas lneas areas han desarrollado un servicio web que
permite a los usuarios comprar billetes y chequear el estado de los vuelos, mediante el
uso del telfono mvil.
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, va Internet. Son aplicaciones
independientes de la plataforma que pueden ser fcilmente publicadas, localizadas e invocadas
mediante protocolos web estndar, como XML, SOAP, UDDI o WSDL. El objetivo final es la
creacin 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 revolucin informtica de la nueva generacin de aplicaciones que
trabajan colaborativamente en las cuales el software esta distribuido en diferentes servidores."

"Los servicios XML Web son los bloques de construccin de la computacin distribuida en el
Internet. Usted puede crear soluciones al usar los mltiples servicios de XML Web desde varias
fuentes que trabajan en conjunto-independientemente de dnde residan o cmo fueron
implementadas."

XML Web Services

Antes de continuar y con el propsito de dejar al lector con una idea lo ms clara posible acerca
de el concepto de Web Services (Servicio Web), quiero citar una definicin que rescate al asistir
a una charla tcnica de XML Web Service en Microsoft en octubre del 2003 cuyo expositor fue el
seor 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 travs de protocolos estndares 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 travs
de un mensaje formateado en XML desde una aplicacin, realiza una tarea y devuelve un
mensaje de respuesta tambin formateado en XML.
Microsoft y otras empresas lideres estn promocionando SOAP como estndar 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 direccin del receptor del mensaje , un conjunto de opciones de
entrega (tal como la informacin de encriptacin), y un cuerpo o body con la informacin o data
del mensaje.
Microsoft y otros proveedores lderes promocionan los Web Services como un modelo de
programacin para la comunicacin entre aplicaciones. Estas compaas piensan que la
conexin de aplicaciones a travs 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 aplicacin corporativa existente, las organizaciones podrn permitir
que sistemas externos puedan invocar las funciones de la aplicacin a travs de Internet (o una
intranet corporativa) sin tener que modificar la aplicacin misma. Por ejemplo, varias
compaas estn hoy en da creando Web Services que actan como front end para aplicaciones
de entrada de rdenes que estn residentes internamente en un mainframe. Estas compaas
permiten a los sistemas de compras de sus clientes enviar rdenes de compra a travs de la
Internet. Poner una capa de web services sobre las aplicaciones existentes es una solucin muy
interesante para integrar las aplicaciones desarrolladas por los diferentes departamentos y as
reducir los costos de integracin."

Ahora que ya tenemos una breve nocin de lo que es un Web Services nos introduciremos en
aspectos un poco ms tcnicos.

Requisitos de un Web Service

Interoperabilidad: Un servicio remoto debe permitir su utilizacin por clientes de otras
plataformas.
Amigabilidad con Internet: La solucin debe poder funcionar para soportar clientes que
accedan a los servicios remotos desde internet.
Interfaces fuertemente tipadas: No debera haber ambigedad acerca del tipo de dato
enviado y recibido desde un servicio remoto. Ms an, los tipos de datos definidos en el
servicio remoto deben poderse corresponder razonablemente bien con los tipos de datos
de la mayora de los lenguaje de programacin procedimentales.
Posibilidad de aprovechar los estndares de Internet existentes: La
implementacin del servicio remoto debera aprovechar estndares de Internet existentes
tanto como sea posible y evitar reinventar soluciones a problema que ya se han resuelto.
Una solucin construida sobre un estndar de Internet ampliamente adoptado puede
aprovechar conjuntos de herramientas y productos existentes creados para dicha
tecnologa.
Soporte para cualquier lenguaje: La solucin no debera ligarse a un lenguaje de
programacin particular Java RMI, por ejemplo, esta ligada completamente a lenguaje
Java. Sera muy difcil invocar funcionalidad de un objeto Java remoto desde Visual Basic
o PERL. Un cliente debera ser capaz de implementar un nuevo servicio Web existente
independientemente del lenguaje de programacin en el que se halla escrito el cliente
Soporte para cualquier infraestructura de componente distribuida: La solucin no
debe estar fuertemente ligada a una infraestructura de componentes en particular. De
hecho, no se bebera requerir el comprar, instalar o mantener una infraestructura de
objetos distribuidos, solo construir un nuevo servicio remoto utilizar un servicio existente.
Los protocolos subyacentes deberan proporcionar un nivel base de comunicacin 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

Descripcin
WSDL, Esquema XML, Docs

Formato de Mensaje
SOAP

Codificacin
XML

Transporte
HTTP,SMTP y otros
Figura II.1: "Bloques constructivos de Servicios Web"
Descubrimiento: La aplicacin cliente que necesita acceder a la funcionalidad que
expone un Servicio Web necesita una forma de resolver la ubicacin 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 mtodos ad hoc. En DCOM, el servicio de descubrimiento lo proporciona el
Administrador de control de servicios (SCM, Services Control Manager).
Descripcin: Una vez que se ha resuelto el extremo de un servicio Web dado, el cliente
necesita suficiente informacin para interactuar adecuadamente con el mismo. La
descripcin de un servicio Web implica meta datos estructurados sobre la interfaz que
intenta utilizar la aplicacin cliente as como documentacin 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 programacin de aplicacin (API) propietaria.
Formato del mensaje: Para el intercambio de datos, el cliente y el servidor tienen que
estar de acuerdo en un mecanismo comn de codificacin y formato de mensaje.
El uso de un mecanismo estndar de codificar los datos asegura que los datos que
codifica el cliente los interpretar correctamente el servidor. En DCOM los mensajes que
se envan entre un cliente y un servidor tienen un formato definido por el protocolo DCOM
Object RPC (ORPC).
Codificacin: Los datos que se trasmiten entre el cliente y el servidor necesitan
codificarse en un cuerpo de mensaje. Dcom utiliza un esquema de codificacin binaria
para serializar los datos de los parmetros que se intercambian entre el cliente y el
servidor.
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 algn
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 documentacin acerca de este primer protocolo de comunicacin bajo
http mediante XML. Con este protocolo se pedan realizar RPC o remote procedure calls, es
decir, podamos bien en cliente o servidor realizar peticiones mediante http a un servidor web.
Los mensajes deban tener un formato determinado empleando XML para encapsular los
parmetros de la peticin. 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 inters por
XML-RPC se desarrollo SOAP."

En el ncleo de los servicios Web se encuentra el protocolo simple de acceso a datos SOAP, que
proporciona un mecanismo estndar de empaquetar mensajes. SOAP ha recibido gran atencin
debido a que facilita una comunicacin del estilo RPC entre un cliente y un servidor remoto.
Pero existen multitud de protocolos creados para facilitar la comunicacin entre aplicaciones,
incluyendo RPC de Sum, DCE de Microsoft, RMI de Java y ORPC de CORBA. Por qu se presta
tanta atencin a SOAP?

Una de las razones principales es que SOAP ha recibido un increble apoyo por parte de la
industria. SOAP es el primer protocolo de su tipo que ha sido aceptado prcticamente por todas
las grandes compaas de software del mundo. Compaas que en raras ocasiones cooperan
entre s estn ofreciendo su apoyo a este protocolo. Algunas de las mayores Compaas que
soportan SOAP son Microsoft, IBM, SUN, Microsystems, SAP y Ariba.

Algunas de las Ventajas de SOAP son:
No esta asociado con ningn lenguaje: los desarrolladores involucrados en nuevos
proyectos pueden elegir desarrollar con el ultimo y mejor lenguaje de programacin que
exista pero los desarrolladores responsables de mantener antiguas aflicciones heredadas
podran no poder hacer esta eleccin sobre el lenguaje de programacin que utilizan.
SOAP no especifica una API, por lo que la implementacin de la API se deja al lenguaje de
programacin, como en Java, y la plataforma como Microsoft .Net.
No se encuentra fuertemente asociado a ningn protocolo de transporte: La
especificacin de SOAP no describe como se deberan asociar los mensajes de SOAP con
HTTP. Un mensaje de SOAP no es ms que un documento XML, por lo que puede
transportarse utilizando cualquier protocolo capaz de transmitir texto.
No est atado a ninguna infraestructura de objeto distribuido La mayora de los
sistemas de objetos distribuidos se pueden extender, y ya lo estn alguno de ellos para
que admitan SOAP.
Aprovecha los estndares existentes en la industria: Los principales contribuyentes
a la especificacin SOAP evitaron, intencionadamente, reinventar las cosas. Optaron por
extender los estndares existentes para que coincidieran con sus necesidades. Por
ejemplo, SOAP aprovecha XML para la codificacin de los mensajes, en lugar de utilizar su
propio sistema de tipo que ya estn definidas en la especificacin 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.
Permite la interoperabilidad entre mltiples entornos: SOAP se desarrollo sobre los
estndares existentes de la industria, por lo que las aplicaciones que se ejecuten en
plataformas con dicho estndares pueden comunicarse mediante mensaje SOAP con
aplicaciones que se ejecuten en otras plataformas. Por ejemplo, una aplicacin de
escritorio que se ejecute en una PC puede comunicarse con una aplicacin del back-end
ejecutndose en un mainframe capaz de enviar y recibir XML sobre HTTP.
Anatoma de un mensaje de SOAP

SOAP proporciona un mecanismo estndar de empaquetar un mensaje. Un mensaje SOAP se
compone de un sobre que contiene el cuerpo del mensaje y cualquier informacin de cabecera
que se utiliza para describir le mensaje. A continuacin tiene un ejemplo:

Figura III.1: "Anatoma de un mensaje SOAP"

El elemento raz del documento es el elemento Envelope. El ejemplo contiene dos
subelementos, Body y Header. Un ejemplo de SOAP valido tambin puede contener otros
elementos hijo en el sobre.
El sobre puede contener un elemento Header opcional que contiene informacin 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.
Adems de definir un sobre de SOAP, la especificacin de SOAP define una forma de codificar
los datos contenidos en un mensaje. La codificacin de SOAP proporciona un mecanismo
estndar para zerialisar tipos de datos no definidos en la parte 1 de la especificacin del
esquema de XML.
La especificacin de SOAP tambin proporciona un patrn de mensaje estndar para facilitar el
comportamiento de tipo RPC. Se emparejan dos mensajes de SOAP para facilitar la asociacin
de un mensaje de peticin con un mensaje de respuesta.
La llamada a un mtodo y sus parmetros se serializan en el cuerpo del mensaje de peticin en
forma de una estructura.
El elemento raz tiene el mismo nombre que el mtodo objetivo, con cada uno de los
parmetros codificado como un subelemento.
El mensaje de respuesta puede contener los resultados de la llamada al mtodo o una
estructura de fallo bien definida. Los resultados de la llamada a un mtodo se serializan en el
cuerpo de la peticin como una estructura. Por convenio, el elemento raz tiene el mismo
nombre que el mtodo original al que se aade result. Los parmetros de retorno se serializan
como elementos hijo, con el parmetro 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 raz tiene el mismo nombre que el mtodo original al que se aade
result. Los parmetros de retorno se serializan como elementos hijo, con el parmetro 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 intencin explicar detalladamente la sintaxis de este lenguaje si
no ms bien no evocaremos a aspectos ms generales como sus orgenes, sus caractersticas
principales y porque es el lenguaje escogido para desarrolla servicios Web.

Vista general de XML

El cdigo html permite insertar mens, tablas, imgenes 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 informacin comparativa en diferentes tiendas por
ejemplo, pero nada ms. Con XML el usuario podr ordenar los datos o actualizarlos en tiempo
real o realizar un pedido.

La informacin que manejan las empresas es uno de sus principales activos. Pero lo normal es
que esa informacin est fragmentada, en diferentes departamentos, ordenadores conectados o
no, etc. El reto ahora est en interrelacionar toda esa informacin para rendir todo su potencial
y ponerlo a trabajar para aumentar los beneficios o reducir los costes. Para realizar esto se
necesita un estndar de almacenamiento estructurado que es lo que nos ofrece XML.

Una gran cantidad de gente ha odo hablar ltimamente de XML y mucha gente que es una
especie de HTML pero ms avanzado. Pero todo el mundo lo que debera 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 ms o menos claro es que XML es un lenguaje de Marcas, pero qu es
exactamente un lenguaje de marcas.

Lenguajes de Marcas

En los aos 60, IBM intent resolver sus problemas asociados al tratamiento de documentos en
diferentes plataformas a travs de GML (Generalized markup Language.

El principal problema era que cada aplicacin utilizaba sus propias marcas para describir los
diferentes elementos. Las marcas son cdigos que indican a un programa cmo 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 dems caractersticas de cualquier texto.
Ejemplos pueden tenerlos en mente los usuarios de WordPerfect.

Conociendo este sistema y conociendo a la perfeccin el sistema de marcas de cada aplicacin
sera posible pasar informacin 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, cdigo ASCII. Y la norma se denomin GML
(General Modeling Language.

Ms 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 ms conocidos son el HTML y el RTF.

Los lenguajes de marcas no son equivalentes a los lenguajes de programacin aunque se
definan igualmente como "lenguajes". Son sistemas complejos de descripcin de informacin,
normalmente documentos, que si se ajustan a SGML, se pueden controlar desde cualquier
editor ASCII. Las marcas ms utilizadas suelen describirse por textos descriptivos encerrados
entre signos de "menor" (<) y "mayor" (>), siendo lo ms usual que existan una marca de
principio y otra de final.

Se puede decir que existen tres utilizaciones bsicas de los lenguajes de marcas: los que sirven
principalmente para describir su contenido, los que sirven ms 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
tpicos del segundo tipo, y aunque no lo parezca, el HTML es la muestra ms conocida del tercer
modelo.

Qu es XML?

XML, es el estndar de Extensible Markup Language. XML no es ms que un conjunto de reglas
para definir etiquetas semnticas 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, slo un poco de HTML. En
teora HTML es un subconjunto de XML especializado en presentacin de documentos para la
Web, mientras que XML es un subconjunto de SGML especializado en la gestin de informacin
para la Web. En la prctica XML contiene a HTML aunque no en su totalidad. La definicin de
HTML contenido totalmente dentro de XML y por lo tanto que cumple a rajatabla la
especificacin SGML es XHTML (Extensible, Hypertext Markup Language.

Desde su creacin, 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 versin sali a la luz el 10 de febrero de 1998.
La primera definicin que apareci fue: Sistema para definir validar y compartir formatos de
documentos en la web.

Durante el ao 1998 XML tuvo un crecimiento exponencial, y con ello me refiero a sus
apariciones en medios de comunicacin, menciones en pginas web, soporte software, etc.

Respecto a sus objetivos son:
XML debe ser directamente utilizable sobre Internet.
XML debe soportar una amplia variedad de aplicaciones.
XML debe ser compatible con SGML.
Debe ser fcil la escritura de programas que procesen documentos XML.
El nmero de caractersticas opcionales en XML debe ser absolutamente mnimo,
idealmente cero.
Los documentos XML deben ser legibles por humanos y razonablemente claros.
El diseo de XML debe ser preparado rpidamente.
El diseo de XML debe ser formal y conciso.
Los documentos XML deben ser fcilmente creables.
La concisin en las marcas XML es de mnima importancia.
Esta especificacin, junto con los estndares asociados (Unicode e ISO/IEC 10646 para
caracteres, Internet RFC 1766 para identificacin de lenguajes, ISO 639 para cdigos de
nombres de lenguajes, e ISO 3166 para cdigos de nombres de pases), proporciona toda
la informacin necesaria para entender la Versin 1.0 de XML y construir programas de
computador que los procesen.
Principales caractersticas
Es una arquitectura ms 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.
Mayor consistencia, homogeneidad y amplitud de los identificadores descriptivos del
documento con XML (los RDF Resource Description FrameWork), en comparacin a los
atributos de la etiqueta del HTML.
Integracin de los datos de las fuentes ms dispares. Se podr hacer el intercambio de
documentos entre las aplicaciones tanto en el propio PC como en una red local o extensa.
Datos compuestos de mltiples aplicaciones. La extensibilidad y flexibilidad de este
lenguaje nos permitir agrupar una variedad amplia de aplicaciones, desde pginas web
hasta bases de datos.
Gestin y manipulacin de los datos desde el propio cliente web.
Los motores de bsqueda devolvern respuestas ms adecuadas y precisas, ya que la
codificacin del contenido web en XML consigue que la estructura de la informacin
resulte ms accesible.
Se desarrollarn de manera extensible las bsquedas personalizables y subjetivas para
robots y agentes inteligentes. Tambin conllevar que los clientes web puedan ser ms
autnomos para desarrollar tareas que actualmente se ejecutan en el servidor.
Se permitir un comportamiento ms estable y actualizable de las aplicaciones web,
incluyendo enlaces bidireccionales y almacenados de forma externa (El famoso epgrafe
"404 file not found" desaparecer).
El concepto de "hipertexto" se desarrollar ampliamente (permitir denominacin
independiente de la ubicacin, enlaces bidireccionales, enlaces que pueden especificarse y
gestionarse desde fuera del documento, hiperenlaces mltiples, enlaces agrupados,
atributos para los enlaces, etc. Creado a travs del Lenguaje de enlaces extensible (XLL).
Exportabilidad a otros formatos de publicacin (papel, web, cd-rom, etc.). El documento
maestro de la edicin electrnica podra ser un documento XML que se integrara en el
formato deseado de manera directa.
Estructura del XML

El metalenguaje XML consta de cuatro especificaciones (el propio XML sienta las bases
sintcticas y el alcance de su implementacin):

DTD (Document Type Definition) Definicin del tipo de documento. Es, en general, un
archivo/s que encierra una definicin formal de un tipo de documento y , a la vez,
especifica la estructura lgica de cada documento. Define tanto los elementos de una
pgina como sus atributos. El DTD del XML es opcional. En tareas sencillas no es
necesario construir una DTD, entonces se tratara de un documento "bien formado"(well-
formed) y si lleva DTD ser un documento "validado" (valid).
XSL (eXtensible Stylesheet Language) Define o implementa el lenguaje de estilo de
los documentos escritos para XML. Desde el verano de 1997 varias empresas informticas
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 mltiple columnas, texto girado, orden de visualizacin de
los datos de una tabla, mltiples tipos de letra con amplia variedad en los tamaos. Este
estndar est basado en el lenguaje de semntica y especificacin de estilo de documento
(DSSSL, Document Style Semantics and Specification Language, ISO/IEC 10179) y, por
otro lado, se considera ms 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 integracin en XML con el protocolo CSS2 (Cascading Style Sheets,
level 2) ofreciendo nuevas formas de composicin y una ms rpida visualizacin) y, por
otra parte, XSL pueda ser utilizado donde se requiera ms potencia de diseo como
documentos XML que encierran datos estructurados (tablas, organigramas, etc.)(2)".
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 estructuracin hipermedia/basado en el tiempo, ISO 10744) y
sigue algunas especificaciones del TEI (Text Encoding Initiative o Iniciativa de codificacin
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 ms all de los enlaces simples que slo soporta el HTML. Se podr
implementar con enlaces extendidos. Jon Bosak establece los siguientes mecanismos
hipertextuales que soportar esta especificacin:
Denominacin independiente de la ubicacin.
Enlaces que pueden ser tambin bidirecccionales.
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 automticamente. No
habr ms errores del tipo "404 Not Found").
Hiperenlaces mltiples (anillos, mltiples ventanas, etc.).
Enlaces agrupados (mltiples orgenes).
Transclusin (el documento destino al que apunta el enlace aparece como parte
integrante del documento orgen del enlace).
Se pueden aplicar atributos a los enlaces (tipos de enlaces).
XUA (XML User Agent): Estandarizacin de navegadores XML. Todava est en
proceso de creacin 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 ms sobre XML no queda responde porque XML es
utilizado en los servicios Web? Si recapitulamos todo los captulos anteriores seguro ya
tendremos alguna pista para esta pregunta, pero para hacerlo ms prctico diremos que se
utiliza XML porque:
Es un estndar abierto es decir que es reconocido mundialmente ya que muchas
compaas tecnolgicas integran en sus software compatibilidad con dicho lenguaje. Esto
quiere decir que la gran mayora de software de escritorio de sistema operativo,
aplicaciones mviles permiten la compatibilidad con XML esto lo hace muy potente a la
hora de permite la comunicacin entre distintas plataformas de software y hardware (y si
bien recordamos este es el sentido final de los Servicios Web).
Simplicidad de sintaxis esto quiere decir que es muy fcil de escribir cdigo en XML y la
representacin 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 bsicas y ya esta en
condiciones de escribir cdigo XML el cual ser soportado o entendido por cualquier
aplicacin que pueda leer documentos XML. El hecho de que XML sea tan fcil de codificar
y de entender lo hace el lenguaje ideal para utilizarlo en los servicios Web.
Independencia del protocolo de Transporte, el hecho de que XML es un lenguaje de
Marcado de Texto, no necesita de ningn 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 caracterstica como lo son los mas
conocidos en HTTP y SMTP por nombrar algunos. Volviendo la tema de los servicios Web
una de las caracterstica de estos es la independencia del protocolo de trasporte.


WSDL para la documentacin 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 mtodos sumar y restar.
Ambos mtodos 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 cmo interacciona un cliente con el servicio Web se define un
esquema para los mensajes que se intercambiarn entre el cliente y el servidor. El esquema
contiene una definicin de un tipo de complejo para los mensaje de peticin y repuesta para los
mtodos sumar y restar. Recuerde que el objetivo ltimo es que los desarrolladores no tengan
que investigar en las definiciones del esquema intentando descifrar cmo 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.

Adems de la informacin que proporciona el esquema, Qu ms necesita conocer el cliente
para invocar los mtodos 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 asociacin formal entre los mensajes de peticin Sumar y Restar
y sus mensajes de respuesta asociados eliminaran cualquier posible ambigedad.

Una descripcin formal de los patrones de mensaje resulta an ms importante en el caso de
Servicio Web ms complejos. Algunos servicios podran aceptar una peticin pero no enviar la
respuesta correspondiente devuelta al cliente. Otros podran solamente enviar mensajes al
cliente.
Adems, el esquema no contiene informacin sobre cmo acceder al Servicio Web. Como SOAP
es independiente del protocolo, se intercambiarn los mensajes entre el cliente y el servidor de
numerosas formas. Cmo se sabe si hay que enviar un mensaje mediante HTTP, SMTP o
cualquier otro protocolo de transporte? Ms an, cmo se sabe la direccin la que hay que
enviar el mensaje?

El lenguaje de descripcin 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 informacin necesaria al cliente para interaccionar con el servicio Web. WSDL es
extensible y se pude utilizar para describir, prcticamente, 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 estn estandarizados
en la comunidad del Web, cada da aumenta la posibilidad e importancia de describir las
comunicaciones de forma estructurada. WSDL afronta esta necesidad definiendo una gramtica
XML que describe los servicios de red como colecciones de puntos finales de comunicacin
capaces de intercambiar mensajes. Las definiciones de servicio de WSDL proporcionan
documentacin para sistemas distribuidos y sirven como frmula para automatizar los detalles
que toman parte en la comunicacin entre aplicaciones.

Los documentos WSDL definen los servicios como colecciones de puntos finales de red o
puertos. En WSDL, la definicin abstracta de puntos finales y de mensajes se separa de la
instalacin concreta de red o de los enlaces del formato de datos. Esto permite la reutilizacin
de definiciones abstractas: mensajes, que son descripciones abstractas de los datos que se
estn 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 asociacin de una
direccin de red y un enlace reutilizable; una coleccin de puertos define un servicio. Por esta
razn, un documento WSDL utiliza los siguientes elementos en la definicin de servicios de red:
Types: contenedor de definiciones del tipo de datos que utiliza algn sistema de tipos (por
ejemplo XSD).
Message: definicin abstracta y escrita de los datos que se estn comunicando.
Operation: descripcin abstracta de una accin admitida por el servicio.
Port Type: conjunto abstracto de operaciones admitidas por uno o ms puntos finales.
Binding: especificacin del protocolo y del formato de datos para un tipo de puerto
determinado.
Port: punto final nico que se define como la combinacin de un enlace y una direccin de
red.
Service: coleccin de puntos finales relacionados.
A continuacin se detalla un poco ms en profundidad cada uno de estos elementos

Elemento types

El elemento Types contiene informacin 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 extensin. Si desea, utilizar otro sistema de
tipo pude aparecer un elemento de extensibilidad bajo el elemento Types. El nombre de este
elemento debera identificar el sistema de tipos utilizados. En este captulo 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 abstraccin comn para el paso de mensajes entre el
cliente y el servidor. Como puede utilizar mltiples formatos de de definicin de esquema en
documento WSDL es necesario de disponer de un mecanismo comn de identificar los
mensajes. El elemento Message proporciona este nivel comn de abstraccin al que se har
referencia en otras partes del documento WSDL.

Pude Aparecer, y normalmente aparecern, mltiples elementos Message en un documento
WSDL, uno para cada mensaje que se comunica entre el cliente y el servidor. Cada mensaje
contiene uno o ms 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 parmetro que forma parte de
una cadena de peticin, un parmetro 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 definicin de internas en donde cada
mtodo se pude definir como una operacin.

Un tipo puerto se compone de un conjunto de electos operation que define una determinada
accin. Los electos operation se componen de mensajes definidos en el documento WSDL.
WSDL define cuatro tipos de operaciones denominadas tipo operaciones:
Request-response(peticin-respuesta) comunicacin del tipo RPC en la que le cliente
realiza una peticin y el servidor enva la correspondiente respuesta.
One-way (un-sentido) Comunicacin del estilo documento en la que el cliente enva ubn
mensaje pero no recibe una respuesta del servidor indicando el resultado del mensaje
procesado.
Solicit-response(solicitud-respuesta) La contraria a la operacin peticin-respuesta. El
servidor enva una peticin y el cliente le enva de vuelta una respuesta.
Notification (Notificacin) La contraria a la operacin un-sentido el servidor enva una
comunicacin del estilo documento al cliente.
Elemento binding

El elemento binding contiene las definiciones de la asociacin de un protocolo como SOAP a un
determinado bindingType. Las definiciones binding especifican detalles de formatos del mensaje
y el protocolo. Por ejemplo, la informacin de asociacin especifica si se puede acceder a una
instancia de un portType de forma RPC.

Las definiciones binding tambin indican el nmero de comunicaciones de re red que se
requieren para realizar una determinada accin. Por ejemplo, una llamada RPC de SOAP sobre
HTTP podra involucrar un intercambio de comunicacin HTTP, pero esa misma llamada sobre
SMTP podra involucrar dos intercambios de comunicaciones de SMTP discretas.

La asociacin de logra utilizando elementos de extensin. Cada protocolo tiene su propio
conjunto de elementos de extensin para especificar los detalles del protocolo y el formato de
los mensajes. Para un determinado protocolo los elementos de extensin se suelen utilizar para
decorar las acciones individuales de una operacin y la propia operacin con la informacin de
asociacin del protocolo. A veces los elementos de extensin 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 direccin 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 tecnologas. 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 definicin 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 definicin de elementos una asociacin que haga referencia a ese
conjunto concreto de electos de extensibilidad tiene que incluir dicho elemento.

Lo ms habitual es que los elementos de extensibilidad se utilicen para especificar
especificacin de asociacin. La especificacin WSDL define conjunto de elementos de
extensibilidad para la asociacin SOAP, HTTP GET, HTTP POS, MIME. Sin embargo, la
especificacin slo define las asociaciones para dos de los cuatro tipos de operaciones. Un
sentido y peticin repuesta.

UDDI (Universal Description Discovery and Integration)

Hasta ahora, se ha explicado cmo crear un servicio Web en una situacin real, describiendo
desde los documentos de diseo iniciales hasta las repercusiones empresariales o la
implementacin final. Lgicamente, el siguiente paso consiste en definir cmo se dar a conocer
el servicio Web para que los clientes interesados puedan descubrirlo fcilmente 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 tecnologas y
plataformas.

En primer lugar, analizar las repercusiones de UDDI, desde un punto de vista tanto tecnolgico
como empresarial. A continuacin, explicar la relacin entre UDDI y WDSL (Lenguaje de
descripcin 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 pblico diseado para almacenar de forma estructurada informacin sobre
empresas y los servicios que stas ofrecen. A travs de UDDI, se puede publicar y descubrir
informacin de una empresa y de sus servicios. Se puede utilizar sistemas taxonmicos
estndar para clasificar estos datos y poder encontrarlos posteriormente en funcin de la
categorizacin. Lo ms importante es que UDDI contiene informacin sobre las interfaces
tcnicas de los servicios de una empresa. A travs de un conjunto de llamadas a API XML
basadas en SOAP, se puede interactuar con UDDI tanto en tiempo de diseo como de ejecucin
para descubrir datos tcnicos de los servicios que permitan invocarlos y utilizarlos. De este
modo, UDDI sirve como infraestructura para una coleccin de software basado en servicios
Web.
Por qu UDDI? Por qu resulta necesario un registro de este tipo? Teniendo en cuenta
que existe una coleccin de software de miles (quizs millones) de servicios Web, se nos
plantean varias cuestiones difciles:
Cmo se descubren los servicios Web?
Cmo se categoriza la informacin de forma coherente?
Cmo repercute esto en la localizacin?
Cmo afecta a las tecnologas de propietario? Cmo se puede garantizar la
interoperabilidad del mecanismo de descubrimiento?
Cmo se puede interactuar en tiempo de ejecucin con este mecanismo de
descubrimiento cuando mi aplicacin 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 ms (para
obtener un listado completo, consulte UDDI: Community [en ingls]), unieron sus esfuerzos
para desarrollar una especificacin basada en estndares abiertos y tecnologas no propietarias
que permitiera resolver los retos anteriores. El resultado, cuya versin beta se lanz en
diciembre de 2000 y estaba en produccin en mayo de 2001, fue un registro empresarial global
alojado por varios nodos de operadores en el que los usuarios podan realizar bsquedas y
publicaciones sin coste alguno.

A partir de la creacin de esta infraestructura para servicios Web, los datos sobre estos
servicios se pueden encontrar de forma sistemtica y confiable en una capacidad universal
totalmente independiente de proveedores. Se pueden llevar a cabo bsquedas categricas
precisas utilizando sistemas de identificacin y taxonmicos extensibles. La integracin de UDDI
en tiempo de ejecucin se puede incorporar a las aplicaciones. Como resultado, se fomenta el
desarrollo de un entorno de software de servicios Web.

Cmo funciona UDDI?

La informacin de UDDI se aloja en nodos de operador, empresas que se han comprometido a
ejecutar un nodo pblico conforme a la especificacin que rige el consorcio UDDI.org. En la
actualidad existen dos nodos pblicos que se ajustan a la versin 1 de la especificacin UDDI:
Microsoft aloja uno e IBM el otro. Hewlett Packard se ha comprometido a alojar un nodo bajo la
versin 2 de la especificacin. Los operadores del host deben replicar datos entre ellos a travs
de un canal seguro, para conseguir la redundancia de la informacin en el registro UDDI. Se
pueden publicar los datos en un nodo y descubrirlos en otro tras la rplica. Actualmente, la
rplica se produce cada 24 horas. En el futuro, este intervalo entre rplicas se reducir, ya que
habr ms 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 slo se debe ajustar a la especificacin UDDI.
El nodo de Microsoft (http://uddi.microsoft.com/default.aspx [en ingls]), por ejemplo, se ha
escrito por completo en C# y se ejecuta en produccin en tiempo de ejecucin en lenguaje
comn .NET Beta 2. El cdigo de base se beneficia claramente de la compatibilidad nativa con
SOAP y de la serializacin que ofrecen las clases de sistema .NET. En el lado del servidor, el
nodo del operador Microsoft utiliza Microsoft SQL Server 2000 como almacn de datos. Creo
que basta con mencionar que IBM utiliza tecnologas 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 pblico UDDI constituye
un claro ejemplo de que el modelo de servicios Web XML funciona en entornos heterogneos.

El prximo paso para comprender la iniciativa UDDI consiste en ver qu datos se almacenan en
UDDI y cmo se estructuran. UDDI es relativamente ligero; se ha diseado como registro, no
como depsito. La diferencia, aunque sutil, resulta esencial. Un registro redirige al usuario a
recursos, mientras que un depsito slo almacena informacin. El registro Microsoft
Windows puede servir de ejemplo: contiene las configuraciones y parmetros bsicos pero, en
ltima instancia, su funcin es la de dirigir la aplicacin a un recurso o binario. Buscar un
componente COM basndonos en su Id. de programa nos conducir a un Id. de clase, que a su
vez nos dirigir a la ubicacin 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 bsquedas y determinar la ubicacin de
recursos. En ltima instancia, las consultas a UDDI conducen a una interfaz (un archivo .WSDL,
.XSD, .DTD, etc.) o a una implementacin (como un archivo .ASMX o .ASP) ubicadas en otro
servidor. Por tanto, UDDI puede responder a este tipo de preguntas:
"Qu interfaces de servicios Web basadas en WSDL se han publicado y establecido para
un sector determinado?"
"Qu empresas han escrito una implementacin basada en una de estas interfaces?"
"Qu servicios Web, categorizados de algn modo, se ofrecen actualmente?"
"Qu servicios Web ofrece una empresa determinada?"
"Con quin se debe poner en contacto el usuario para utilizar los servicios Web de una
empresa?"
"Cules son los detalles de implementacin 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 cmo colaboran UDDI y WSDL y por qu la idea de interfaces frente
implementaciones forma parte de cada protocolo. WSDL y UDDI se disearon para diferenciar
claramente los metadatos abstractos y las implementaciones concretas. Para entender cmo
funcionan WSDL y UDDI resulta esencial comprender las consecuencias de esta divisin.

Por ejemplo, WSDL distingue claramente los mensajes de los puertos: los mensajes (la sintaxis
y semntica 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 informacin sobre el puerto. Un archivo WSDL puede
contener simplemente informacin abstracta de interfaz, sin facilitar datos de implementacin
concretos, y ser vlido. De este modo, los archivos WSDL se separan de las implementaciones.

Una de las consecuencias ms interesantes de esto es que pueden existir varias
implementaciones de una nica interfaz WSDL. Este diseo permite que sistemas dispares
escriban implementaciones de la misma interfaz, para garantizar as la comunicacin entre
ellos. Si tres empresas diferentes implementan el mismo archivo WSDL y una parte del software
de cliente crea el cdigo auxiliar/proxy a partir de esa interfaz, dicho software se podr
comunicar con las tres implementaciones con el mismo cdigo de base, cambiando simplemente
el punto de acceso.

UDDI establece una distincin similar entre la abstraccin y la implementacin con el concepto
de tModels. La estructura tModel, abreviatura de "Technology Model" (modelo de tecnologa),
representa huellas digitales tcnicas, interfaces y tipos abstractos de metadatos. El resultado de
los tModels son las plantillas de enlace, que son la implementacin concreta de uno o ms
tModels. Dentro de una plantilla de enlace se registra el punto de acceso de una
implementacin particular de un tModel. Del mismo modo que el esquema de WSDL permite
separar la interfaz y la implementacin, 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 estndares publica la interfaz cannica para un sector particular y, a
continuacin, varias empresas escriben implementaciones de esta interfaz. Obviamente, cada
una de estas implementaciones hara referencia al mismo tModel. Los archivos WSDL
constituyen un ejemplo perfecto de tModel de UDDI.

Registro en UDDI

La publicacin en UDDI es un proceso relativamente sencillo. El primer paso consiste en
determinar informacin bsica sobre cmo definir la empresa y los servicios en UDDI. El
siguiente paso, una vez determinada esta informacin, consiste en llevar a cabo el registro, ya
sea mediante programacin o a travs 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 bsquedas y herramientas.

Primer paso: Definir la entrada de UDDI

Partiendo del modelo de datos descrito anteriormente, se debe recopilar cierta informacin
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 diseo 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
debera tener un formato URI (identificador de recursos uniforme), como MyCompany-
com:SampleWebService-interface:v1, y sealar a la ubicacin del archivo WSDL.

Si su servicio Web es un servicio de Microsoft Visual Studio .NET, podr generar una
descripcin 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 invocacin del servicio Web, lo cual puede no resultar adecuado cuando
la interfaz del servicio tiene varias implementaciones. Esto no supondr ningn problema si su
intencin es que el archivo WSDL slo tenga una implementacin.

Determine el nombre de la empresa y una breve descripcin 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 descripcin en varios idiomas. Asimismo, UDDI permite enumerar los contactos, incluyendo
datos como el correo electrnico, el telfono y la direccin. Esta lista de contactos muestra los
recursos de una empresa con los que se puede poner en contacto en relacin 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, cmo
puede llegar a saber quin es? Existe algn contacto para obtener asistencia tcnica a la hora
de utilizar los servicios Web de la empresa? Tambin se debera incluir en la lista a esta
persona.

Determine las categoras e identificaciones adecuadas para la empresa.
Podr explorar los sistemas taxonmicos compatibles con UDDI actualmente en el nodo
Microsoft UDDI (http://uddi.microsoft.com/default.aspx [en ingls]). 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 categoras que representan de forma ms acertada a
su empresa.

Determine los servicios Web que la empresa ofrece a travs de UDDI.
A continuacin, deber determinar los servicios Web que desea registrar la empresa en el nodo
pblico UDDI. Existen varios puntos de acceso para este servicio? Es preciso que los clientes
conozcan otros parmetros y otra informacin 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 acompaar
medidas de seguridad, autorizacin y autenticacin. No basta que el usuario sepa que existe un
servicio Web para que pueda invocarlo. Puede existir una comunicacin fuera de banda entre
empresas antes de permitir el acceso a un servicio Web.

Determine las categoras 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 debera 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 definicin, el siguiente paso consiste en registrar la empresa.
Deber obtener una cuenta con un registro UDDI. Esta operacin no se puede realizar mediante
programacin, ya que deber mostrar su conformidad con una declaracin de condiciones de
uso. El nodo de Microsoft utiliza Passport para la autenticacin, 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 programacin 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 ms compleja, resulta recomendable realizar el proceso de registro con secuencias de
comandos, utilizando el SDK de Microsoft UDDI. Adems, la interfaz de usuario de Microsoft no
est localizada en otros idiomas, as que se deber registrar mediante programacin para
disfrutar esa caracterstica 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 asegrese de que aparece en el cuadro de dilogo "Agregar
referencia Web". Si no aparece, se puede deber a que el tModel no se categoriz correctamente
utilizando la taxonoma uddi-org:types descrita anteriormente. Podr agregar el servicio Web al
proyecto y generar el cdigo 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 ingls).

Para Terminar

UDDI y WSDL funcionan como especificaciones gratuitas que facilitar el desarrollo de una
coleccin 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 prxima generacin, mientras que UDDI proporciona una amplia
infraestructura estandarizada que permite al usuario describir y descubrir servicios Web.
Mediante la combinacin de estos dos estndares, se podr desarrollar todo un universo de
servicios Web.

Son seguros los Servicios Web XML?

Teniendo en cuenta todos los aspectos de seguridad, autenticacin y autorizacin,
confidencialidad e integridad de datos, etc., y el hecho de que la especificacin SOAP ni siquiera
menciona la seguridad, es fcil llegar a la conclusin de que la respuesta es negativa. Pero no
hay que subestimar los servicios Web XML de Microsoft. Hoy en da, 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:
Cul 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.
Cmo vamos a cumplir con el objetivo deseado? Red, capa de transporte, sistema
operativo, servicio o aplicacin.
Qu nivel de interoperabilidad deseamos y necesitamos en nuestra solucin? Local o
global.
Cmo se puede aumentar la seguridad de los servicios Web XML actuales?
Esto se consigue respondiendo a las preguntas anteriores y, a continuacin, aplicando las
mismas tcnicas de seguridad que utilizaramos para cualquier otra aplicacin Web:
Crear conexiones seguras
Autenticar y autorizar la interaccin
Como podr comprobar seguidamente, estas tcnicas 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 (mtodos)
basndose 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.

Creacin de una infraestructura segura una infraestructura segura es la clave para contar con
servicios Web XML seguros. Microsoft ofrece una amplia gama de tecnologas que, una vez
integradas en un plan general de seguridad, permiten a las empresas proteger eficazmente una
infraestructura informtica. Para completar la implementacin con xito, la planeacin debe
considerar lo siguiente:
Tener una idea detallada de los riesgos potenciales del entorno (como virus, intrusos y
desastres naturales.
Realizar un anlisis activo de la relacin entre las consecuencias y contramedidas de una
intrusin y los riesgos.
Crear una estrategia de implementacin planeada con detenimiento para integrar las
medidas de seguridad en el conjunto de una red empresarial, basndose en los dos
puntos anteriores.
Creacin de conexiones seguras

Uno de los mtodos ms sencillos para aumentar la seguridad de los servicios Web XML
consiste en asegurarse de que la conexin entre el cliente de servicios Web XML y el servidor es
segura. Esto se puede llevar a cabo mediante varias tcnicas, dependiendo de la extensin de
la red y el perfil de actividades de las interacciones. Tres de las tcnicas ms 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 tcnica 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 segn su origen o identidad.
Esto resulta de gran utilidad cuando se espera que determinados clientes tengan acceso a
funcionalidades (mtodos) 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 ledos por terceros durante la transmisin. SSL cifra
el mensaje del cliente y, a continuacin, lo enva al servidor. Una vez que el servidor lo recibe,
SSL lo descifra y comprueba que procede del remitente correcto (proceso que se denomina
autenticacin. El servidor, o el servidor y el cliente, pueden tener certificados que se utilizan
como parte del proceso de autenticacin y que proporcionan capacidades de autenticacin
adems del cifrado de la conexin. Aunque es un mtodo 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 extensin de una red privada que se conecta a travs de redes
compartidas o pblicas, como Internet. Las redes virtuales privadas permiten enviar datos entre
dos equipos en una conexin segura. Si bien su funcionamiento es similar a SSL, una red virtual
segura es una conexin punto a punto establecida a largo plazo. De este modo, mejora la
eficacia y permite la comunicacin con servicios Web XML, pero requiere que se establezca una
conexin duradera a largo plazo para obtener un rendimiento mayor.

Seguridad en servicios web. Autenticacin y autorizacin.
Interoperabilidad

2 Autenticacin y autorizacin

2.1 Autenticacin:

La autenticacin 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 autenticacin requiere
pruebas de identidad, denominadas credenciales. Por ejemplo, una aplicacin cliente puede
presentar una contrasea como sus credenciales. Si la aplicacin cliente presenta las
credenciales correctas, se asume que es quien dice ser.

2.2 Autorizacin:

Una vez que se ha autenticado la identidad de un principal, deben tomarse decisiones sobre la
autorizacin. El acceso se determina comparando la informacin del principal con informacin
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 estaran autorizados slo a ciertas operaciones. A
algunos clientes se les permitir un acceso total a todos los datos, mientras que a otros slo se
les permitir acceso a un subconjunto de los datos y otros tendrn acceso de slo lectura.

Un modo sencillo de implementar servicios Web XML Web consiste en aprovechar las
caractersticas de autenticacin del protocolo que se utilice para intercambiar mensajes. Para la
mayora de los servicios Web XML, esto significa aprovechar las caractersticas de autenticacin
disponibles en HTTP. Microsoft Internet Informacin Server (IIS) e ISA Server funcionan en
conjuncin con Windows 2000 Server y ofrecen soporte para varios mecanismos de
autenticacin en HTTP.
Bsica: utilizada para identificacin no segura o poco segura de clientes, ya que el
nombre de usuario y la contrasea se envan como texto codificado en base 64, que
puede ser fcilmente descodificado. IIS autorizar el acceso a los servicios Web XML si las
credenciales coinciden con las de una cuenta de usuario vlida.
Bsica sobre SSL: igual que la autenticacin bsica, excepto que el canal de
comunicacin est cifrado y protege de ese modo el nombre de usuario y la contrasea.
Una buena opcin para entornos en Internet; sin embargo, el uso de SSL influye
negativamente en el rendimiento.
Implcita: 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 vlida.
Autenticacin 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 confa. IIS autorizar el acceso a los
servicios Web XML si las credenciales coinciden con las de una cuenta de usuario vlida.
Certificados de cliente a travs 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 solucin 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. Slo 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 autenticacin es que no se necesita escribir nuevo
cdigo. IIS/ISA Server completa todo el proceso de autenticacin y autorizacin ACL antes de
llamar a los servicios Web XML. Sin embargo, al implementar el cliente ser necesario realizar
algunas tareas adicionales. La aplicacin cliente necesitar responder a las peticiones de
autenticacin y credenciales del servidor.

Entre los mtodos para la implementacin de autenticacin en servicios Web XML tambin se
incluyen servicios de terceros, como los que se encuentran en Microsoft . NET Passport,
caractersticas de sesin de Microsoft ASP.NET o la creacin de mtodos de autenticacin
personalizados.

3 Prximamente: Interoperabilidad

Como puede ver, las tcnicas habituales para crear aplicaciones Web seguras se pueden aplicar
por separado o combinadas a la hora de proteger servicios Web XML. Estas tcnicas ya se han
utilizado en el pasado y resultan bastante efectivas. Sin embargo, no ofrecen una solucin
integrada dentro de la arquitectura de servicios Web XML. Conforme aumenta la complejidad
del entorno de servicios Web XML (sobrepasando los lmites de la confianza, extendindose a
mltiples 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 estn trabajando en un conjunto de especificaciones de seguridad
basadas en el mecanismo de extensibilidad de la especificacin SOAP para ofrecer funciones de
seguridad mejoradas e integradas en el ncleo mismo de los servicios Web XML.

Una de las principales especificaciones que se estn desarrollando es el lenguaje de seguridad
de servicios Web XML (WS-Security) que proporciona mejoras en la mensajera SOAP,
consistentes en tres funcionalidades: transferencia de credenciales, integridad de mensajes y
confidencialidad. Estas funcionalidades no proporcionan por s mismas una solucin de
seguridad completa; WS-Security es una pieza que se puede utilizar en conjuncin con la
infraestructura y otros protocolos de servicios Web XML para hacer frente a un gran nmero 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 evolucin 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 aos,
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 clsica, se est desarrollando e implantando tecnologas de
servicios Web en paralelo, progresando a travs de un ciclo de realimentacin positivo. Aunque
los servicios Web han progresado mucho en los ltimos tres aos, el trabajo sobre la plataforma
contina. Si vamos a desarrollar sistemas basados en servicios Web, es importante comprender
dnde 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
ms cosas (por ejemplo, enviar mensajes SOAP sobre SMTP. Sin embargo, la mensajera
basada en HTTP es la nica opcin de comunicacin ms generalmente soportada. La mayora
de las herramientas de Servicios Web mapea mensajes SOAP a invocaciones de mtodos en
objetos. Algunas proporcionan adems un acceso directo al cuerpo de los mensajes SOAP,
exponindolos como XML. Servicios de alto nivel como la seguridad se implementan
generalmente de modo ad hoc, tpicamente en el nivel de los protocolos de transporte.

La mayora 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 reunindose peridicamente para garantizar que
sus kits de herramientas trabajan conjuntamente.

Muchos de los trabajos de la comunidad SOAPBuilders han sido necesarios en relacin 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 debera aportar mejoras
sustanciales. El grupo XML Protocol Working Group est trabajando en la especificacin SOAP
1.2 mientras que el grupo Web Services Description Working Group est creando la
especificacin WSDL 1.2. Mientras tanto, IETF y OASIS estn tambin 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
ncleo de los servicios Web, existe otra organizacin independiente que est prestando ms
atencin a la interoperabilidad. La organizacin Web Services Interoperability Organization
(WS-I) tiene como objetivo definir mejores prcticas para garantizar la interoperabilidad de los
servicios Web. El grupo WS-I Basic Profile Working Group est actualmente desarrollando un
conjunto de recomendaciones sobre cmo utilizar los protocolos bsicos 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 aparecern mejoras
en tres reas fundamentales. En primer lugar, se aadirn servicios de ms alto nivel. Todo el
mundo est de acuerdo en que debe existir un modo estndar de asegurar servicios Web,
rutear mensajes, garantizar una entrega fiable de mensajes, definir semntica transaccional,
etc. Estas caractersticas de propsito general se expanden ms all de los dominios del
problema y no hay ninguna razn por la que cada desarrollador de servicios Web deba
implementarlas individualmente. Microsoft, IBM y otros estn realizando mucho trabajo en
estas reas. La iniciativa Global XML Web Service Architecture (GXA) define un conjunto de
especificaciones sobre cmo implementar estos servicios de infraestructura en trminos de
mensajes SOAP (por ejemplo, de un modo neutral respecto del protocolo de transporte.

En segundo lugar, seguirn estandarizndose especificaciones. El ciclo de vida de las
especificaciones de servicios Web tpicamente progresa desde una propuesta hasta un estndar
de facto y desde ste hasta un estndar real. Con SOAP 1.2 y WSDL 1.2 las peculiaridades
finales estn siendo elaboradas de las especificaciones SOAP y WSDL y algunas de las
especificaciones de servicios de mayor nivel, como WS-Security, ya estn en el periodo "de
facto" en el proceso de estandarizacin. Las empresas siguen proponiendo nuevas
especificaciones como aadidos a la plataforma de servicios Web y la industria en su conjunto
necesitar acordar cules adoptar. Esas especificaciones necesitarn a continuacin ser
estandarizadas.

En tercer lugar, los kits de herramientas y marcos de trabajo seguirn mejorando. Adems de
servicios de ms alto nivel como la seguridad y los objetos adjuntos, se aadir soporte para
protocolos de transporte alternativos como SMTP o TCP. De modo ms importante, los modelos
de programacin migrarn desde los servicios de tipo RPC hacia servicios centrados en
documentos, para promover un acoplamiento dbil. Todos estos cambios ocurrirn en paralelo,
mientras los desarrolladores continan desarrollando e implantando sistemas basados en
servicios Web.

3 Avances de futuro

Llegados a este punto, estaremos preguntndonos cmo podemos utilizar los servicios Web
cuando la plataforma todava est evolucionando. Las herramientas y marcos de trabajo de los
servicios Web actuales proporcionan suficiente funcionalidad bsica para desarrollar
interesantes aplicaciones distribuidas que envan mensajes SOAP sobre HTTP. Algunos servicios
de mayor nivel como WS-Security estn empezando a cuajar con el soporte de diversas
herramientas nuevas como el kit Web Services Development Kit. Otros servicios estn todava
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 dems caractersticas.

Si queremos desarrollar servicios Web utilizando herramientas de Microsoft, tenemos varias
opciones. Si todava estamos utilizando Visual Studio 6.0 o algn otro entorno de desarrollo que
no soporta el desarrollo de cdigo gestionado, podemos crear y consumir servicios Web
utilizando el kit de herramientas SOAP Toolkit. Si estamos utilizando .NET, podemos
focalizarnos en los mtodos Web de ASP.NET (a esto hace referencia la mayor parte de la
documentacin de .NET sobre los servicios Web). En cualquier caso, podemos aprender tanto
como queramos sobre cmo funcionan los protocolos de mensajera y metadatos de los
servicios Web. Cuanto ms comprendamos la fontanera, ms fcil ser desarrollar nuestros
propios servicios y utilizar servicios desarrollados por los dems.

Tambin podemos experimentar con las nuevas especificaciones. La versin preliminar del kit
Microsoft WSDK Technology Preview proporciona un soporte preliminar para las especificaciones
WS-Security, WS-Routing y DIME. Podemos tambin 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 opcin no es para todo el mundo, pero si tenemos tiempo y
recursos, obtendremos pronto una avanzada funcionalidad. Adems, contribuiremos al
desarrollo de la plataforma. El entendimiento colectivo de SOAP Y WSDL se mejor
sustancialmente gracias al intento de implementacin de sistemas basados en ambos
estndares por parte de mltiples usuarios. Cuanto ms estrechamente trabajen los usuarios
con las nuevas especificaciones, mejor resultar la plataforma de servicios Web global.


Introduccin al entorno de desarrollo de Microsoft .NET

1 El nuevo modelo de computacin distribuida en Internet.

Nos encontramos en un momento especial en la industria de computacin. Estamos en el inicio
de una nueva manera de hacer y de integrar las aplicaciones.

Algunos gurs de la industria de computacin vaticinan que este cambio ser equivalente al que
produjo la introduccin de la PC, la interfase visual o al surgimiento mismo de Internet.
Dispositivos mviles como celulares, TabletPC (PCs que parecen un cuaderno de notas pero
tienen la capacidad de una computadora de escritorio), hasta televisores u otros dispositivos
hogareos estarn conectados entre s, con servidores y distintas aplicaciones. El elemento
integrador ser Internet. Estamos ahora en el inicio de la tercera generacin 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
informacin, barreras entre sistemas, barreras entre los sistemas y la gente que los utiliza,
barreras entre las organizaciones.

Cmo se llega a este nuevo modelo de computacin?

La dcada de los 80's fue marcada por el surgimiento de la PC y de la interfase grafica. En la
dcada de los 90's Internet permiti conectar computadoras en una escala global. En principio
la conexin 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 computacin
distribuida llamado servicios Web basados en XML. El objetivo es permitir comunicarse entre s
a sistemas heterogneos dentro y fuera de la empresa. Esta comunicacin es independiente del
sistema operativo, lenguaje o modelo de programacin. Para conseguir esto se desarrollaron
estndares. El consorcio de Internet http://www.w3c.org fue el encargado de crear y mantener
estos estndares.

Estos son algunos de los estndares que permiten hacer uso de los Servicios Web basados en
XML:

XML: (Lenguaje de Marcado eXtensible) Es un formato universal para representar los
datos.
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 interactan.
UDDI: (Descubrimiento, Descripcin e Integracin Universal) Lenguaje que permite
publicar, encontrar y usar los Servicios Web basados en XML. Es la 'Pgina Amarilla' de
los servicios Web es decir un directorio para poder encontrarlos. Puede ser accedido con
un explorador en http://www.uddi.org o programticamente ya que UDDI es tambin un
servicio Web.
WSDL: (Lenguaje de Descripcin de Servicios Web) Lenguaje por medio del cual un
servicio Web describe entre otras cosas qu hace o qu funcionalidad implementa.
La competencia en la industria de software no pasa por imponer el protocolo sobre el cual
se va a construir la nueva generacin de Internet, debido a que estn 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
estndares y las ms fciles y ms productivas herramientas para construir las aplicaciones. La
plataforma .NET es la infraestructura, los servicios y productos que Microsoft ofrece.

Antes de la adopcin del modelo de Servicios Web basados en XML los datos eran 'islas' que se
encontraban dentro de las aplicaciones en las empresas. Era muy difcil y costoso implementar
soluciones para acceder a la informacin desde afuera de la aplicacin 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 informacin que puede ser accedida
desde distintos dispositivos, desde distintas plataformas de hardware o software y que puede
estar guardada en distintos formatos. El lenguaje estndar para lograr esta integracin 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 versin de SQL Server 2000 llamada Yukon. Este producto puede guardar datos en
formato nativo XML, adems permite hacer consultas al servidor no solamente en el lenguaje
tpico de bases de datos sino tambin en cualquier lenguaje compatible con la plataforma .NET.

2 Qu es la plataforma .NET?

Provee los cimientos para la nueva generacin de software. Utiliza los Servicios Web como un
medio para poder interoperar a distintas tecnologas. Permite conectar distintos sistemas
operativos, dispositivos fsicos, informacin y usuarios. Les da a los desarrolladores las
herramientas y tecnologas para hacer rpidamente soluciones de negocios que involucran
distintas aplicaciones, dispositivos fsicos y organizaciones.

FIGURA IX.1: "Esquema general de la Plataforma .NET"

La idea central detrs de la plataforma .NET es la de servicio. Ms concretamente software
como servicio y de cmo 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 comunicacin global que es Internet cada vez ms rpida y a un
costo cada vez menor y adems, a la capacidad de los procesadores que contina
incrementndose ao tras ao. El usuario de Internet puede con un explorador de Internet no
solamente acceder a contenido como texto, imgenes o sonido, tambin puede hacer uso de
servicios Web. Estos son los bloques de construccin o componentes sobre los cuales se basa el
modelo de computacin distribuida en Internet. La plataforma .NET permite usar Internet y su
capacidad de distribucin 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 distribucin a gran
escala de Internet para acceder a servicios de software. Tambin se trata de aprovechar el
incremento en la capacidad de procesamiento de los nuevos dispositivos mviles llamados
"Smart Devices" (dispositivos inteligentes) para que el usuario haga uso de la funcionalidad que
proveen los servicios Web con interfases cada vez ms sencillas y naturales como la voz o la
escritura.

La siguiente versin del portal MSN, MSN 8, es un ejemplo de software como servicio. Utiliza los
ladrillos de construccin que proveen el servicio Web Passport y .NET Alerts (los cuales
estudiaremos ms adelante). Permite adems instalar software actualizado mientras se hacen
otras cosas. La actualizacin de software es un servicio al que hay que subscribirse
independientemente de la plataforma desde la cual se accede.

El nuevo modelo de computacin 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 aerolnea puede hacer componentes para la reserva de pasajes y desde una
aplicacin de una empresa de turismo llamar a este componente. O un usuario desde un
dispositivo mvil (por ejemplo un celular) puede tambin invocar el componente de reserva de
pasajes areos directamente para ver la disponibilidad y hacer reservaciones. La empresa
turstica puede exponer un servicio Web que incluya la llamada al servicio Web de la aerolnea.
Cuando un servicio Web llama a otros se crea lo que se llama federacin 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 invocacin de los servicios como su ejecucin 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 intervencin humana. Por eso se llama a la nueva
generacin 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 caractersticas son:

Permiten acceder a la informacin en el formato apropiado, en cualquier momento y
lugar.
Hacen uso de Servicios Web.
Optimizan de distintas maneras la forma en que la informacin es presentada y
organizada. Por ejemplo: Pueden convertir texto en sonido en un celular o reconocer la
escritura en un TabletPC.
Proveen de una interfase sencilla y natural para que el usuario acceda a la informacin.
Pueden utilizar la identidad del usuario, su perfil y datos para adaptar la informacin que
es presentada.
Pueden reconocer la presencia de otros dispositivos e intercambiar informacin.
Pueden adaptarse a las caractersticas de la red donde estn. Por ejemplo la velocidad de
transmisin.
Tienen capacidad de procesamiento propio, y distribuyen el procesamiento en la red
haciendo uso de los servicios Web.
Ejemplo de estos son:

PocketPC (PC de bolsillo)
SmartPhone (Telfono Inteligente)
HandHelds
TabletPC
XBox (Consola de juegos de Microsoft)
PCs: Las computadoras personales.

NoteBooks: Las computadoras porttiles.

Y muchos otros dispositivos en desarrollo. Adems:

Servidores: Proveen de la infraestructura para implementar el modelo de computacin
distribuida en Internet. Son sistemas operativos y de aplicacin.

Sistemas Operativos: Windows 2000: Server, Advance Server y Datacenter, Windows Server
2003: Standard, Enterprise, Datacenter y Web Server.

Servidores .NET Corporativos:

Microsoft Application Center 2000: Para instalar y administrar aplicaciones Web altamente
disponibles y escalables.
Microsoft BizTalk Server 2000 : Para construir procesos de negocios basados en XML a
travs de distintas aplicaciones y organizaciones.
Microsoft Commerce Server 2000: Para construir rpidamente soluciones de e-commerce
escalables.
Microsoft Content Management Server 2001: Para administrar contenido para sitios Web
de e-bussines dinmicos.
Microsoft Exchange Server 2000: Para permitir enviar mensajes y trabajar en forma
colaborativa en cualquier momento y lugar.
Microsoft Host Integration Server 2000: Para acceder a datos y aplicaciones en
mainframes.
Microsoft SQL Server 2000: Para almacenar, recuperar y analizar datos en formato XML.
Microsoft SharePoint Portal Server 2001: Para encontrar, compartir y publicar informacin
de negocios.
Microsoft Internet Security and Acceleration Server 2000: Para conectividad a Internet
rpida y segura.
Microsoft Mobile Informacin 2001 Server: Para soportar aplicaciones en dispositivos
mviles como por ejemplo celulares.
Servicios Web basados en XML: Son los bloques de construccin de la tercera generacin de
Internet. Algunas de sus caractersticas son:

Permiten a las aplicaciones compartir datos. Son componentes. Es decir, unidades de
cdigo discretas, cada una haciendo una tarea en particular.
Estn basados en el lenguaje universal de intercambio de datos de Internet: XML.
Pueden ser llamados desde distintos sistemas operativos, plataformas de hardware y
lenguajes de programacin.
Herramientas de desarrollo: Visual Studio .NET y el .NET Framework. Ambos permiten al
desarrollador hacer servicios Web basados en XML adems de otro tipo de aplicaciones. El .NET
Framework viene incorporado directamente en la nueva lnea de sistemas operativos
Windows .NET. Para los dispositivos mviles se llama .NET Compact Framework. Los
componentes de la plataforma .NET pueden interactuar de distintas maneras. Esta
comunicacin 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 informacin 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 mvil va Internet.

Servidor con Servidor: Una aplicacin en un servidor puede programticamente acceder a
otra aplicacin 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 tecnologas para transformar a Internet en una
plataforma de computacin distribuida en gran escala. Esta plataforma adems soporta los
estndares sobre los cuales se basan los servicios Web.

Figura IX.2: "La Plataforma .NET"

La plataforma .NET utiliza tecnologas existentes, productos modificados para su uso dentro de
la plataforma y elementos nuevos.
Productos existentes: COM.

Microsoft tiene una tecnologa para la creacin, invocacin y uso de componentes llamada COM
(Modelo de Objetos Componentes). Al igual que el protocolo SOAP utilizado para la invocacin
de los servicios Web, COM establece las reglas acerca de cmo los objetos deben ser invocados
y cmo deben interactuar. Tambin los componentes COM pueden implementar funcionalidad
similar a la de los servicios Web. Sin embargo tienen dos puntos en contra. Primero: No son
una tecnologa estndar. Segundo: No pueden ser utilizados fuera de la barrera de seguridad
que las empresas tienen para su comunicacin hacia y desde Internet (firewall). Por lo tanto no
sirven al modelo de computacin 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 tambin 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. Tambin 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 informacin entre aplicaciones dentro de la empresa y tambin "orquesta"
el flujo de datos con otras empresas.

De ah que se califique a su funcin como "orquestacin". 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 tecnologa 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 mviles.
Debido a que es un subconjunto del .NET Framework comparte el mismo modelo de
programacin y herramientas de desarrollo de aplicaciones haciendo posible que los
desarrolladores transfieran sus conocimientos existentes al desarrollo de aplicaciones mviles.

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 aplicacin dentro de Visual Studio .NET.
Ahora que tenemos una visin general del .NET Framework, vamos a estudiar que funcin
cumplen las partes que lo componen.

Figura IX.4: "Runtime del Leguaje Comn"

El Common Language Runtime provee lo que se llama cdigo administrado, es decir, un entorno
que provee servicios automticos al cdigo que se ejecuta. Los servicios son variados:

Cargador de Clases: Permite cargar en memoria las clases.
Compilador MSIL a nativo: Transforma cdigo intermedio de alto nivel independiente del
hardware que lo ejecuta a cdigo de mquina propio del dispositivo que lo ejecuta.
Administrador de Cdigo: Coordina toda la operacin de los distintos subsistemas del
Common Language Runtime.
Recolector de Basura: Elimina de memoria objetos no utilizados.
Motor de Seguridad: Administra la seguridad del cdigo que se ejecuta.
Motor de Depuracin: Permite hacer un seguimiento de la ejecucin del cdigo an
cuando se utilicen lenguajes distintos.
Verificador de Tipos: Controla que las variables de la aplicacin usen el rea de memoria
que tienen asignado.
Administrador de Excepciones: Maneja los errores que se producen durante la ejecucin
del cdigo.
Soporte de multiproceso (threads): Permite ejecutar cdigo en forma paralela.
Empaquetador de COM: Coordina la comunicacin con los componentes COM para que
puedan ser usados por el .NET Framework.
Soporte de la Biblioteca de Clases Base: Interfase con las clases base del .NET
Framework.

Figura IX.5: "Librera de Clases .NET"

La librera de clases base son las clases sobre las cuales se construyen todas las dems 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 dems clases.

Debido a que en la librera 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 ms manejable y
fcil su uso.

La librera de clases base es independiente del lenguaje. Permite el uso y la depuracin 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". Tambin el usuario puede incorporarlas en
bibliotecas para su utilizacin posterior. Es segura ya que es posible permitir o restringir su uso
por medio de distintos mecanismos de seguridad.

Cmo funciona el .NET Framework.

Cuando usted crea una aplicacin Windows en algn 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 aplicacin, se crea un cdigo intermedio llamado MSIL. Este
cdigo es independiente de la plataforma de hardware. Una vez compilado, el ejecutor de
lenguaje comn administra la ejecucin de la aplicacin.

Figura IX.6: "Funcionamiento del .NET Framework."

Uno de los subsistemas del Common Language Runtime se llama compilacin JIT, que transforma el cdigo intermedio
MSIL al cdigo de mquina en el sistema donde la aplicacin se va a ejecutar. Esta compilacin a lenguaje de mquina
lo hace en el momento de ejecucin del cdigo. Cuando un dispositivo de cliente, por ejemplo, un celular "Smart
phone", ejecuta una aplicacin hecha con Visual Studio .NET, se ejecuta en el cdigo de mquina del sistema del
cliente. La aplicacin 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 Introduccin.

El objetivo de la actividad es presentar fundamentos tericos generales relativos a la tecnologa de webservices, y como
puede ser implementada en los escenarios ms comunes con que nos encontraremos.

Como implementacin, comenzaremos construyendo un webservice muy sencillo, el cual ser testado a travs del
browser.

Desarrollaremos aplicaciones cliente (consumidoras) del Web Service, como:

Pgina ASP.Net
Aplicacin Windows .Net
Aplicacin Excel de Office XP
Aplicacin de Internet Mobile
Aplicacin Visual Basic 6.0

Requerimientos

Software

Servidor - Webservice

Windows 2000, XP, superior
Internet Information Service
.Net Framework (SDK)

Desarrollo Webservice

Visual Studio .Net
o
Notepad.

Cliente webservice (Consumidor)

MS SoapToolkit
Office XP
o
Webservice referente toolkit (para creacin del Proxy)

2 Implementacin

Desarrollando un webservice

1.) En Visual Studio .Net, creamos un proyecto ASP.Net Webservices, llamado "WorkShopUDP_v1"


2.) Eliminar los comentarios (comilla simple) del mtodo 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

Despus:

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 travs del solution Explorer.

Antes:


Despus:

5.) Construir la solucin.
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 direccin: http://localhost/WorkShopUDP_v1/mensaje1.asmx

Clickar sobre "HelloWorld"

Clickar "Invoke"

Consumo del webservice en aplicacin .Net

1.) Crear proyecto Windows Application, llamado "testWebServiceHelloWorld"


2.) Agregamos referencia al webservice al proyecto: En el "Solution Explorer" pulsar botn derecho sobre "References"
y "Add Web Reference" En la barra de direcciones de la ventana, agregar la direccin del webservice creado.
http://localhost/WorkShopUDP_v1/mensaje1.asmx

Pulsando <ENTER>, comprobamos la existencia del webservice en la direccin ingresada.

Agregamos la referencia al proyecto: Click en "Add Reference".


Comprobar en el "Solution Explorer" la referencia agregada, y cambiar el nombre del flder "localhost" a "wsSaludos"

Antes:

Despus:

3.) Comprobamos a travs del explorador de Windows la existencia de los archivos "mensaje1.disco" y "mensaje1.wsdl"
existen en el directorio "wsSaludos"


3.) Insertar un botn y un cuadro de texto al formulario

4.) En el cdigo del formulario, importamos en espacio de nombres asociado a la referencia al webservice agregada.

5.) En el cdigo de accin del botn, instanciamos un objeto de la clase "testWebServiceHelloWorld.wsSaludos",
llamado "objWsSaludos".

Dim objWsSaludo As New Saludo()

6.) Luego llamamos el mtodo "HelloWorld" y asignamos su respuesta al TextBox1.

TextBox1.Text = objWsSaludo.HelloWorld()

Finalmente el cdigo 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 solucin, y pulsamos F5 para ejecutarla.

Al pulsar el botn, 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 botn 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 cdigo del webform, importar el espacio de nombres asociado al webservice.

Imports testWSAsp.wsSaludos

- En el cdigo del botn, instanciar un objeto de la clase "Saludo", invocar la funcin "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 solucin (Build) y ejecutando (F5):

Pulsando el botn:

Consumo de un web service desde aplicacin mvil en .net

- Instalar el "Mobile Internet Toolkit" para Visual Studio .NET
- Instalar emulador de aplicacin mvil.

1.) Crear proyecto "Mobile Web Application"

2.) Agregar controles mviles 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 cdigo del Mobile Web Form, importar el espacio de nombres asociado al webservice.

Imports MobileWebWSSaludo.wsSaludos

- En el cdigo del botn, instanciar un objeto de la clase "Saludo", invocar la funcin "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 solucin (Build).

Abrir el emulador abriendo la direccin de la pgina 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 mdulo de clase "clsws_Saludo" (Proxy al Webservice) Ver Explorador del proyecto.


Insertar un mdulo: Menu: Insert Module

Agregar la funcin publica siguiente al mdulo 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 cdigo de Seguridad anti robots en ASP.NET

Para crear un cdigo de seguridad seguiremos los siguientes pasos:

Tenemos que agregar en el formulario que deseamos insertar el cdigo de seguridad los siguientes controles:
Una imagen (dnde su scr ser /AntiRobots.aspx)
Un input de tipo texto, con un id= type= frm_Codigo_Seguridad

En el cdigo VB de la pgina 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 cdigo 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 funcin GenerateRandomCode para generar un cdigo 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 cdigo 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 tamao 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)
'Aade 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 pgina que apunta nuestra imagen (el primer control que hemos agregado en el
proyecto, y en el Page_Load pondremos este cdigo:

'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, dnde hemos agregado los controles, en el botn del submit, utilizar esta
condicin:

If bAntiBots Then
' Creamos el registro
Else
' El cdigo de seguridad no est bien colocado
End if

Puedes descargarte todo el cdigo fuente de pulsando aqu.
[http://www.mistrucos.net/ficheros/trucos/652/antirobots.zip]


Autores del manual:

Hay que agradecer a diversas personas la dedicacin prestada para la creacin de este manual. Sus nombres junto con
el nmero de artculos redactados por cada uno son los siguientes:
Benjamn Gonzlez C.
Ingeniero de Sistemas
(21 captulos)

Pol Salvat
http://www.mistrucos.net/
(1 captulo)

Todos los derechos de reproduccin y difusin [http://www.desarrolloweb.com/copyright/] reservados a Guiarte
Multimedia S.L. [http://www.guiartemultimedia.com/]

Volver [http://www.desarrolloweb.com/manuales/54]

Manual Completo Servicios Web

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual Completo Servicios Web

Cargado por

Copyright:

Formatos disponibles

Introducin a los servicios web

Toda la informacin disponible para cualquier persona, en cualquier lugar, a travs

También podría gustarte