Beruflich Dokumente
Kultur Dokumente
Servicios Web en
plataforma .NET
Manual por: DesarrolloWeb.com [http://www.desarrolloweb.com/] Versión on-line:
"Tu mejor ayuda para aprender a hacer webs" http://www.desarrolloweb.com/manuales/54
Esta frase acuña quizás el sueño de todos los que de una u otra forma se relacionan con las
tecnologías de la información, partiendo desde una gran compañía tecnológica hasta un simple
usuario de una planilla Excel. La pregunta es: ¿Será esto posible?
Las empresas se percataron que era imposible crear una plataforma integrado de forma
individual, así que decidieron atacar el problema de raíz. Para esto decidieron que en vez de
crear la mejor plataforma integradora, era mejor buscar un leguaje común de intercambio de
información aprovechando los estándares existentes en el mercado.
Bajo este contexto nacen los Servicios Web basados en XML, los cuales son el objeto de estudio
del presente manual.
OBJETIVOS
Esto implica entender el contexto global en el cual se desarrollaron los Servicios Web para así
conseguir de manera práctica la adopción e implementación de dicha tecnología, también
conocer sus principales ventajas así como sus limitaciones desde un punto de vista de una
tecnología que esta en continuo desarrollo.
Esto quiere decir poder dimensionar que esta tecnología viene a cambiar la forma en que se
comunicaban las distintas aplicaciones y la forma en que se accede a la información que reside
en distintas plataformas y aplicaciones desde diversos tipos de equipos y dispositivo de
comunicación.
De manera general o detallada conocer las tecnologías asociadas a Servicios Web. Ya que de
alguna manera, más temprano que tarde, nos encontraremos inmersos en ellas.
Dejar un documento escrito que sirva de base para los futuros estudiantes que se
interesen en descubrir nuevas tecnología.
La intención del presente documento no es solo la de explicar el contexto de los Servicios Web,
si no también transmitir al lector un numero de nuevos conceptos y tecnologías que en la
actualidad están en pleno desarrollo y en adopción por diversas empresas. Todo lo anterior
pretende incentivar al lector a que investigue y descubra nuevas herramientas con las cuales
logre estar un grado por encima del resto en lo que a informática se refiere.
Las aplicaciones web actuales ya no son suficientes. El modelo actual de negocio electrónico no
facilita la integración de las aplicaciones de Internet con el resto de software de las empresas.
Si las compañías quieren extraer el máximo beneficio de Internet, los sitios web deben
evolucionar. Este es el contexto en el que surgen los web services. Los web services son
componentes software que permiten a los usuarios usar aplicaciones de negocio que comparten
datos con otros programas modulares, vía Internet. Son aplicaciones independientes de la
plataforma que pueden ser fácilmente publicadas, localizadas e invocadas mediante protocolos
web estándar, como XML, SOAP, UDDI o WSDL. El objetivo final es la creación de un directorio
online de web services, que pueda ser localizado de un modo sencillo y que tenga una alta
fiabilidad.
z XML( eXtensible Markup Language): Un servicio web es una aplicación web creada en
XML.
z WSDL (Web Services Definition Service): Este protocolo se encarga de describir el web
service cuando es publicado. Es el lenguaje XML que los proveedores emplean para
describir sus web services.
z SOAP (Simple Object Access Protocol): Permite que programas que corren en diferentes
sistemas operativos se comuniquen. La comunicación entre las diferentes entidades se
realiza mediante mensajes que son rutados en un sobre SOAP.
z UDDI (Universal Description Discovery and Integration): Este protocolo permite la
publicación y localización de los servicios. Los directorios UDDI actúan como una guía
telefónica de web services.
Posibles riesgos
Las expectaciones alrededor de esta tecnología son grandes, porque el mercado de aplicación
Servicios Web en plataforma .NET - Manual completo Página 3 de 52
z Los web services hacen uso de las mismas tecnologías que han sido atacadas en tantas
ocasiones. Usando web services, la seguridad de una empresa puede verse
comprometida. La ausencia de técnicas de seguridad estándar es un obstáculo para la
adopción de la tecnología.
z La calidad de un web service es un parámetro que no queda demasiado claro, pero cuya
medida es fundamental a la hora de desarrollar un servicio maduro.
Actualmente, los web services están siendo ampliamente aceptados por las empresas para el
desarrollo de software de uso interno. De este modo, los servicios pueden implementar toda su
funcionalidad y permanecer seguros tras el Cortafuegos de la compañía. Los desarrollos
actuales no ayudan a la cooperación entre las empresas ya que no hay ningún estándar
establecido sobre las técnicas de seguridad. Debido a la tecnología que es usada por los web
services, y en concreto al uso de SOAP, las técnicas de seguridad convencionales que se han
venido usando en Internet, ya no son suficientes. Con SOAP, cada mensaje simple que se
intercambia realiza múltiples saltos y es rutado a través de numerosos puntos antes de que
alcance su destino final. Es por ello que los web services necesitan tecnologías que protejan los
mensajes desde el principio hasta el final. Existen un conjunto de técnicas que se pueden usar
para garantizar la seguridad a nivel de mensaje. Estas son:
z Encriptación XML: Evita que los datos se vean expuestos a lo largo de su recorrido.
z Firma Digital XML: Asocia los datos del mensaje al usuario que emite la firma, de modo
que este usuario es el único que puede modificar dichos datos.
z XKMS y los Certificados: XKMS (XML Key Management Specification) define web services
que se pueden usar para chequear la confianza de un certificado de usuario.
z SAML y la Autorización: SAML (Security Assertion Mark-up Language) hace posible que
los web services intercambien información de autentificación y autorización entre ellos, de
modo que un web service confíe en un usuario autentificado por otro web service.
z Validación de datos: Permite que los web services reciban datos dentro de los rangos
esperados.
Además, también hay técnicas que permiten mantener la seguridad a otros niveles. La
seguridad en UDDI permite autentificar todas las entidades que toman parte en la publicación
de un web service: proveedor, agente y consumidor del servicio. De este modo, nadie podrá
registrar servicios en el papel de un proveedor o hacer uso de ellos sin contar con los permisos
adecuados.
Calidad
también sería interesante analizar las características que ofrece el proveedor de web services.
Actualmente no hay definidos estándares sobre este tema, pero la mayoría de las empresas ya
está demandando algún tipo de acuerdo o contrato con los proveedores, de modo que se pueda
garantizar la calidad y la fiabilidad de los servicios por los que se paga.
Estandarización
Los web services están basados en el estándar XML, que ha sido universalmente aceptado. Pero
la situación para el resto de protocolos es bien distinta. La mayor parte de ellos se encuentran
todavía en desarrollo y pueden ser objeto de cambios. Esa es la razón por la que la mayoría de
las empresas están esperando a que estos protocolos sean más universales antes de
profundizar en esta tecnología. Actualmente, ni SOAP, ni WSDL, ni UDDI han sido oficialmente
reconocidos por ningún organismo de estandarización. SOAP es el único que en este momento
está en consideración por el World Wide Web Consortium y se encuentra cercano a la
estandarización. SOAP y WSDL están siendo ampliamente usados, pero de momento UDDI no
ha tenido el mismo éxito. El principal motivo es que las técnicas de seguridad son todavía muy
inmaduras y las compañías prefieren hacer uso de registros privados para dar soporte a
intercambios privados de web services. En febrero de este año, algunas de las empresas más
importantes en el desarrollo de Negocio Electrónico como IBM, Intel, Microsoft o Oracle, han
creado el WS-I: organización para la Interoperabilidad de los Web Services. El objetivo de dicha
organización es la promoción de la estandarización de los web services de modo que se fomente
la cooperación e interoperabilidad entre las compañías y mercados.
Algunos ejemplos
Las principales compañías del mundo han empezado a desarrollar soluciones mediante la
tecnología de los web services. Algunos ejemplos son:
"Los web services son componentes software que permiten a los usuarios usar aplicaciones de
negocio que comparten datos con otros programas modulares, vía Internet. Son aplicaciones
independientes de la plataforma que pueden ser fácilmente publicadas, localizadas e invocadas
mediante protocolos web estándar, como XML, SOAP, UDDI o WSDL. El objetivo final es la
creación de un directorio de online de web services, que pueda ser localizado de un modo
sencillo y que tenga una alta fiabilidad."
"Los servicios web son la revolución informática de la nueva generación de aplicaciones que
trabajan colaborativamente en las cuales el software esta distribuido en diferentes servidores."
"Los servicios XML Web son los bloques de construcción de la computación distribuida en el
Internet. Usted puede crear soluciones al usar los múltiples servicios de XML Web desde varias
fuentes que trabajan en conjunto-independientemente de dónde residan o cómo fueron
implementadas."
Antes de continuar y con el propósito de dejar al lector con una idea lo más clara posible acerca
de el concepto de Web Services (Servicio Web), quiero citar una definición que rescate al asistir
a una charla técnica de XML Web Service en Microsoft en octubre del 2003 cuyo expositor fue el
señor Marcos Escovar.
"Un Web Service es un componente de software que se comunica con otras aplicaciones
codificando los mensaje en XML y enviando estos mensaje a través de protocolos estándares de
Internet tales como el Hypertext Transfer Protocol (HTTP). Intuitivamente un Web Service es
similar a un sitio web que no cuenta con un interfaz de usuario y que da servicio a las
aplicaciones en vez de a las personas. Un Web Service, en vez de obtener solicitudes desde el
navegador y retornar paginas web como respuesta, lo que hace es recibir solicitudes a través
de un mensaje formateado en XML desde una aplicación, realiza una tarea y devuelve un
mensaje de respuesta también formateado en XML.
Microsoft y otras empresas lideres están promocionando SOAP como estándar de los mensajes
para los Web Services. Un mensaje SOAP se parece mucho a una carta : es un sobre que
contiene una cabecera con la dirección del receptor del mensaje , un conjunto de opciones de
entrega (tal como la información de encriptación), y un cuerpo o body con la información o data
del mensaje.
Microsoft y otros proveedores líderes promocionan los Web Services como un modelo de
programación para la comunicación entre aplicaciones. Estas compañías piensan que la
conexión de aplicaciones a través de la Internet mejorará la capacidad de las empresas para
trabajar conjuntamente con sus socios de negocio, proveedores y clientes. Creando una capa de
Web Services sobre una aplicación corporativa existente, las organizaciones podrán permitir
que sistemas externos puedan invocar las funciones de la aplicación a través de Internet (o una
intranet corporativa) sin tener que modificar la aplicación misma. Por ejemplo, varias
compañías están hoy en día creando Web Services que actúan como front end para aplicaciones
de entrada de órdenes que están residentes internamente en un mainframe. Estas compañías
permiten a los sistemas de compras de sus clientes enviar órdenes de compra a través de la
Internet. Poner una capa de web services sobre las aplicaciones existentes es una solución muy
interesante para integrar las aplicaciones desarrolladas por los diferentes departamentos y así
reducir los costos de integración."
Ahora que ya tenemos una breve noción de lo que es un Web Services nos introduciremos en
aspectos un poco más técnicos.
Descubrimiento
UDDI,DISCO
Descripción
WSDL, Esquema XML, Docs
Formato de Mensaje
SOAP
Codificación
XML
Transporte
HTTP,SMTP y otros
Son las siglas de Simple Object Access Protocol. Este protocolo deriva de un protocolo creado
por David Winer, XML-RPC en 1998. En su sitio web, Userland, http://www.userland.com/ se puede
encontrar multitud de documentación acerca de este primer protocolo de comunicación bajo
http mediante XML. Con este protocolo se pedían realizar RPC o remote procedure calls, es
decir, podíamos bien en cliente o servidor realizar peticiones mediante http a un servidor web.
Los mensajes debían tener un formato determinado empleando XML para encapsular los
parámetros de la petición. Con el paso del tiempo el proyecto iniciado por David Winer interesó
a Importantes multinacionales entre las que se encuentran IBM y Microsoft y de este interés por
XML-RPC se desarrollo SOAP."
En el núcleo de los servicios Web se encuentra el protocolo simple de acceso a datos SOAP, que
proporciona un mecanismo estándar de empaquetar mensajes. SOAP ha recibido gran atención
debido a que facilita una comunicación del estilo RPC entre un cliente y un servidor remoto.
Pero existen multitud de protocolos creados para facilitar la comunicación entre aplicaciones,
incluyendo RPC de Sum, DCE de Microsoft, RMI de Java y ORPC de CORBA. ¿Por qué se presta
tanta atención a SOAP?
Una de las razones principales es que SOAP ha recibido un increíble apoyo por parte de la
industria. SOAP es el primer protocolo de su tipo que ha sido aceptado prácticamente por todas
las grandes compañías de software del mundo. Compañías que en raras ocasiones cooperan
entre sí están ofreciendo su apoyo a este protocolo. Algunas de las mayores Compañías que
soportan SOAP son Microsoft, IBM, SUN, Microsystems, SAP y Ariba.
escritorio que se ejecute en una PC puede comunicarse con una aplicación del back-end
ejecutándose en un mainframe capaz de enviar y recibir XML sobre HTTP.
Un mensaje debe estar dentro de sobre de SOAP bien construido. Un sobre se compone de un
único elemento envelope el sobre puede contener un elemento Header y puede contener un
elemento body. Si existe, la cabecera debe ser el elemento hijo inmediato del sobre, con el
cuerpo siguiendo inmediatamente a la cabecera.
El cuerpo contiene la carga de datos del mensaje y la cabecera contiene los datos adicionales
que no pertenecen necesariamente al cuerpo del mensaje.
Además de definir un sobre de SOAP, la especificación de SOAP define una forma de codificar
los datos contenidos en un mensaje. La codificación de SOAP proporciona un mecanismo
estándar para zerialisar tipos de datos no definidos en la parte 1 de la especificación del
esquema de XML.
La especificación de SOAP también proporciona un patrón de mensaje estándar para facilitar el
comportamiento de tipo RPC. Se emparejan dos mensajes de SOAP para facilitar la asociación
de un mensaje de petición con un mensaje de respuesta.
La llamada a un método y sus parámetros se serializan en el cuerpo del mensaje de petición en
forma de una estructura.
El elemento raíz tiene el mismo nombre que el método objetivo, con cada uno de los
parámetros codificado como un subelemento.
El mensaje de respuesta puede contener los resultados de la llamada al método o una
estructura de fallo bien definida. Los resultados de la llamada a un método se serializan en el
cuerpo de la petición como una estructura. Por convenio, el elemento raíz tiene el mismo
Servicios Web en plataforma .NET - Manual completo Página 9 de 52
nombre que el método original al que se añade result. Los parámetros de retorno se serializan
como elementos hijo, con el parámetro de retorno en primer lugar. Si se encuentra un error el
cuerpo del mensaje de respuesta contendrá una estructura de fallo bien definida.
Por convenio, el elemento raíz tiene el mismo nombre que el método original al que se añade
result. Los parámetros de retorno se serializan como elementos hijo, con el parámetro de
retorno en primer lugar. Si se encuentra un error el cuerpo del mensaje de respuesta contendrá
una estructura de fallo bien definida.
El código html permite insertar menús, tablas, imágenes o bases de datos en los documentos,
pero no permite al usuario que maneje esos elementos como mejor le convenga con la
poderosa ayuda del ordenador. Esa es la principal novedad que XML aporta.
Con HTML se pueden hacer accesos a información comparativa en diferentes tiendas por
ejemplo, pero nada más. Con XML el usuario podrá ordenar los datos o actualizarlos en tiempo
real o realizar un pedido.
La información que manejan las empresas es uno de sus principales activos. Pero lo normal es
que esa información esté fragmentada, en diferentes departamentos, ordenadores conectados o
no, etc. El reto ahora está en interrelacionar toda esa información para rendir todo su potencial
y ponerlo a trabajar para aumentar los beneficios o reducir los costes. Para realizar esto se
necesita un estándar de almacenamiento estructurado que es lo que nos ofrece XML.
Una gran cantidad de gente ha oído hablar últimamente de XML y mucha gente que es una
especie de HTML pero más avanzado. Pero todo el mundo lo que debería preguntarse es qué es
exactamente XML y qué aplicaciones tiene actualmente. De estas dos cuestiones el mayor error
que se suele cometer es considerar a XML un HTML extendido.
Lo que sí tenemos más o menos claro es que XML es un lenguaje de Marcas, pero qué es
exactamente un lenguaje de marcas.
Lenguajes de Marcas
En los años 60, IBM intentó resolver sus problemas asociados al tratamiento de documentos en
diferentes plataformas a través de GML (Generalized markup Language.
El principal problema era que cada aplicación utilizaba sus propias marcas para describir los
diferentes elementos. Las marcas son códigos que indican a un programa cómo debe tratar su
contenido y así, si se desea que un texto aparezca con un formato determinado, dicho texto
debe ir delimitado por la correspondiente marca que indique como debe ser mostrado en
pantalla o impreso. Y lo mismo ocurre con todas las demás características de cualquier texto.
Ejemplos pueden tenerlos en mente los usuarios de WordPerfect.
Más tarde GML pasó a manos de ISO y se convirtió en SGML ( ISO 8879), Standart Generalized
Servicios Web en plataforma .NET - Manual completo Página 10 de 52
Markup Language. Esta norma es la que se aplica desde entonces a todos los lenguajes de
marcas, cuyos ejemplos más conocidos son el HTML y el RTF.
Se puede decir que existen tres utilizaciones básicas de los lenguajes de marcas: los que sirven
principalmente para describir su contenido, los que sirven más que nada para definir su formato
y los que realizan las dos funciones indistintamente. Las aplicaciones de bases de datos son
buenas referencias del primer sistema, los programas de tratamiento de textos son ejemplos
típicos del segundo tipo, y aunque no lo parezca, el HTML es la muestra más conocida del tercer
modelo.
¿Qué es XML?
XML, es el estándar de Extensible Markup Language. XML no es más que un conjunto de reglas
para definir etiquetas semánticas que nos organizan un documento en diferentes partes. XML es
un metalenguaje que define la sintaxis utilizada para definir otros lenguajes de etiquetas
estructurados.
En primer lugar para entenderlo bien hay que olvidarse un poco, sólo un poco de HTML. En
teoría HTML es un subconjunto de XML especializado en presentación de documentos para la
Web, mientras que XML es un subconjunto de SGML especializado en la gestión de información
para la Web. En la práctica XML contiene a HTML aunque no en su totalidad. La definición de
HTML contenido totalmente dentro de XML y por lo tanto que cumple a rajatabla la
especificación SGML es XHTML (Extensible, Hypertext Markup Language.
Desde su creación, XML ha despertado encontradas pasiones, y como para cualquier tema en
Internet, hay gente que desde el principio se deja iluminar por sus expectativas, mientras otras
muchas lo han ignorado.
Historia de XML
XML fue creado al amparo del Word Wide Web Consortium (W3C) organismo que vela por el
desarrollo de WWW partiendo de las amplias especificaciones de SGML.
Durante el año 1998 XML tuvo un crecimiento exponencial, y con ello me refiero a sus
apariciones en medios de comunicación, menciones en páginas web, soporte software, etc.
Principales características
z Es una arquitectura más abierta y extensible. No se necesita versiones para que puedan
funcionar en futuros navegadores. Los identificadores pueden crearse de manera simple y
ser adaptados en el acto en internet/intranet por medio de un validador de documentos
(parser.
z Mayor consistencia, homogeneidad y amplitud de los identificadores descriptivos del
documento con XML (los RDF Resource Description FrameWork), en comparación a los
atributos de la etiqueta del HTML.
z Integración de los datos de las fuentes más dispares. Se podrá hacer el intercambio de
documentos entre las aplicaciones tanto en el propio PC como en una red local o extensa.
z Datos compuestos de múltiples aplicaciones. La extensibilidad y flexibilidad de este
lenguaje nos permitirá agrupar una variedad amplia de aplicaciones, desde páginas web
hasta bases de datos.
z Gestión y manipulación de los datos desde el propio cliente web.
z Los motores de búsqueda devolverán respuestas más adecuadas y precisas, ya que la
codificación del contenido web en XML consigue que la estructura de la información
resulte más accesible.
z Se desarrollarán de manera extensible las búsquedas personalizables y subjetivas para
robots y agentes inteligentes. También conllevará que los clientes web puedan ser más
autónomos para desarrollar tareas que actualmente se ejecutan en el servidor.
z Se permitirá un comportamiento más estable y actualizable de las aplicaciones web,
incluyendo enlaces bidireccionales y almacenados de forma externa (El famoso epígrafe
"404 file not found" desaparecerá).
z El concepto de "hipertexto" se desarrollará ampliamente (permitirá denominación
independiente de la ubicación, enlaces bidireccionales, enlaces que pueden especificarse y
gestionarse desde fuera del documento, hiperenlaces múltiples, enlaces agrupados,
atributos para los enlaces, etc. Creado a través del Lenguaje de enlaces extensible (XLL).
z Exportabilidad a otros formatos de publicación (papel, web, cd-rom, etc.). El documento
maestro de la edición electrónica podría ser un documento XML que se integraría en el
formato deseado de manera directa.
El metalenguaje XML consta de cuatro especificaciones (el propio XML sienta las bases
sintácticas y el alcance de su implementación):
z DTD (Document Type Definition) Definición del tipo de documento. Es, en general, un
archivo/s que encierra una definición formal de un tipo de documento y , a la vez,
especifica la estructura lógica de cada documento. Define tanto los elementos de una
página como sus atributos. El DTD del XML es opcional. En tareas sencillas no es
necesario construir una DTD, entonces se trataría de un documento "bien formado"(well-
formed) y si lleva DTD será un documento "validado" (valid).
z XSL (eXtensible Stylesheet Language) Define o implementa el lenguaje de estilo de
los documentos escritos para XML. Desde el verano de 1997 varias empresas informáticas
como Arbortext, Microsoft e Inso vienen trabajando en una propuesta de XSL (antes
llamado "xml-style") que presentaron a W3C. Permite modificar el aspecto de un
documento. Se puede lograr múltiple columnas, texto girado, orden de visualización de
los datos de una tabla, múltiples tipos de letra con amplia variedad en los tamaños. Este
estándar está basado en el lenguaje de semántica y especificación de estilo de documento
(DSSSL, Document Style Semantics and Specification Language, ISO/IEC 10179) y, por
otro lado, se considera más potente que las hojas de estilo en cascada (CSS, Cascading
Servicios Web en plataforma .NET - Manual completo Página 12 de 52
Style Sheets), usado en un principio con el lenguaje DHTML. "Se espera que el CSS sea
usado para visualizar simples estructuras de documentos XML (actualmente se ha
conseguido mayor integración en XML con el protocolo CSS2 (Cascading Style Sheets,
level 2) ofreciendo nuevas formas de composición y una más rápida visualización) y, por
otra parte, XSL pueda ser utilizado donde se requiera más potencia de diseño como
documentos XML que encierran datos estructurados (tablas, organigramas, etc.)(2)".
z XLL (eXtensible Linking Language) Define el modo de enlace entre diferentes enlaces.
Se considera que es un subconjunto de HyTime (Hipermedia/Timed-based structuring
Language o Lenguaje de estructuración hipermedia/basado en el tiempo, ISO 10744) y
sigue algunas especificaciones del TEI (Text Encoding Initiative o Iniciativa de codificación
de texto). Desde marzo de 1998 el W3C trabajo en los enlaces y direccionamientos del
XML. Provisionalmente se le renombró como Xlink y a partir de junio se le denomina XLL.
Este lenguaje de enlaces extensible tiene dos importantes componentes: Xlink y el
Xpointer. Va más allá de los enlaces simples que sólo soporta el HTML. Se podrá
implementar con enlaces extendidos. Jon Bosak establece los siguientes mecanismos
hipertextuales que soportará esta especificación:
z Denominación independiente de la ubicación.
z Enlaces que pueden ser también bidirecccionales.
z Enlaces que pueden especificarse y gestionarse desde fuera del documento a los
que se apliquen (Esto permitirá crear en un entorno intranet/extranet un banco de
datos de enlaces en los que se puede gestionar y actualizar automáticamente. No
habrá más errores del tipo "404 Not Found").
z Hiperenlaces múltiples (anillos, múltiples ventanas, etc.).
z Enlaces agrupados (múltiples orígenes).
z Transclusión (el documento destino al que apunta el enlace aparece como parte
integrante del documento orígen del enlace).
z Se pueden aplicar atributos a los enlaces (tipos de enlaces).
z XUA (XML User Agent): Estandarización de navegadores XML. Todavía está en
proceso de creación de borradores de trabajo. Se aplicará a los navegadores para
que compartan todas las especificaciones XML.
Finalmente ahora que ya conocemos algo más sobre XML no queda responde ¿porque XML es
utilizado en los servicios Web? Si recapitulamos todo los capítulos anteriores seguro ya
tendremos alguna pista para esta pregunta, pero para hacerlo más práctico diremos que se
utiliza XML porque:
Además de la información que proporciona el esquema, ¿Qué más necesita conocer el cliente
para invocar los métodos que expone el Servicio Web Calculadora? Como el cuerpo de un
mensaje de SOAP puede contener cualquier cosa que no invalide el XML los mensajes de SOAP
se pueden combinar para disponer de una amplia variedad de patrones de intercambio de
mensajes. Los patrones de intercambio de mensajes para el Servicio Web Calculadora son
bastante inmediatos pero una asociación formal entre los mensajes de petición Sumar y Restar
y sus mensajes de respuesta asociados eliminarían cualquier posible ambigüedad.
Una descripción formal de los patrones de mensaje resulta aún más importante en el caso de
Servicio Web más complejos. Algunos servicios podrían aceptar una petición pero no enviar la
respuesta correspondiente devuelta al cliente. Otros podrían solamente enviar mensajes al
cliente.
Además, el esquema no contiene información sobre cómo acceder al Servicio Web. Como SOAP
es independiente del protocolo, se intercambiarán los mensajes entre el cliente y el servidor de
numerosas formas. ¿Cómo se sabe si hay que enviar un mensaje mediante HTTP, SMTP o
cualquier otro protocolo de transporte? Más aún, ¿cómo se sabe la dirección la que hay que
enviar el mensaje?
Dado que los protocolos de comunicaciones y los formatos de mensajes están estandarizados
en la comunidad del Web, cada día aumenta la posibilidad e importancia de describir las
comunicaciones de forma estructurada. WSDL afronta esta necesidad definiendo una gramática
XML que describe los servicios de red como colecciones de puntos finales de comunicación
capaces de intercambiar mensajes. Las definiciones de servicio de WSDL proporcionan
documentación para sistemas distribuidos y sirven como fórmula para automatizar los detalles
que toman parte en la comunicación entre aplicaciones.
Los documentos WSDL definen los servicios como colecciones de puntos finales de red o
puertos. En WSDL, la definición abstracta de puntos finales y de mensajes se separa de la
instalación concreta de red o de los enlaces del formato de datos. Esto permite la reutilización
de definiciones abstractas: mensajes, que son descripciones abstractas de los datos que se
están intercambiando y tipos de puertos, que son colecciones abstractas de operaciones. Las
especificaciones concretas del protocolo y del formato de datos para un tipo de puerto
determinado constituyen un enlace reutilizable. Un puerto se define por la asociación de una
dirección de red y un enlace reutilizable; una colección de puertos define un servicio. Por esta
razón, un documento WSDL utiliza los siguientes elementos en la definición de servicios de red:
z Types: contenedor de definiciones del tipo de datos que utiliza algún sistema de tipos (por
Servicios Web en plataforma .NET - Manual completo Página 14 de 52
ejemplo XSD).
z Message: definición abstracta y escrita de los datos que se están comunicando.
z Operation: descripción abstracta de una acción admitida por el servicio.
z Port Type: conjunto abstracto de operaciones admitidas por uno o más puntos finales.
z Binding: especificación del protocolo y del formato de datos para un tipo de puerto
determinado.
z Port: punto final único que se define como la combinación de un enlace y una dirección de
red.
z Service: colección de puntos finales relacionados.
Elemento types
Elemento message
El elemento Message proporciona una abstracción común para el paso de mensajes entre el
cliente y el servidor. Como puede utilizar múltiples formatos de de definición de esquema en
documento WSDL es necesario de disponer de un mecanismo común de identificar los
mensajes. El elemento Message proporciona este nivel común de abstracción al que se hará
referencia en otras partes del documento WSDL.
Elemento portType
El elemento porType contiene un conjunto de operaciones abstractas que representan los tipos
de correspondencia que pueden producirse entre el cliente y el servidor. Para los Servicios Web
de estilo RPC se pude pensar en un porType como una definición de internas en donde cada
método se pude definir como una operación.
Un tipo puerto se compone de un conjunto de electos operation que define una determinada
acción. Los electos operation se componen de mensajes definidos en el documento WSDL.
WSDL define cuatro tipos de operaciones denominadas tipo operaciones:
Elemento binding
Elemento service
Elementos de Extensibilidad
En primer lugar, analizaré las repercusiones de UDDI, desde un punto de vista tanto tecnológico
Servicios Web en plataforma .NET - Manual completo Página 16 de 52
UDDI es un registro público diseñado para almacenar de forma estructurada información sobre
empresas y los servicios que éstas ofrecen. A través de UDDI, se puede publicar y descubrir
información de una empresa y de sus servicios. Se puede utilizar sistemas taxonómicos
estándar para clasificar estos datos y poder encontrarlos posteriormente en función de la
categorización. Lo más importante es que UDDI contiene información sobre las interfaces
técnicas de los servicios de una empresa. A través de un conjunto de llamadas a API XML
basadas en SOAP, se puede interactuar con UDDI tanto en tiempo de diseño como de ejecución
para descubrir datos técnicos de los servicios que permitan invocarlos y utilizarlos. De este
modo, UDDI sirve como infraestructura para una colección de software basado en servicios
Web.
z ¿Por qué UDDI? ¿Por qué resulta necesario un registro de este tipo? Teniendo en cuenta
que existe una colección de software de miles (quizás millones) de servicios Web, se nos
plantean varias cuestiones difíciles:
z ¿Cómo se descubren los servicios Web?
z ¿Cómo se categoriza la información de forma coherente?
z ¿Cómo repercute esto en la localización?
z ¿Cómo afecta a las tecnologías de propietario? ¿Cómo se puede garantizar la
interoperabilidad del mecanismo de descubrimiento?
z ¿Cómo se puede interactuar en tiempo de ejecución con este mecanismo de
descubrimiento cuando mi aplicación depende de un servicio Web?
La iniciativa UDDI surgió como respuesta a estas preguntas. Varias empresas, incluidas
Microsoft, IBM, Sun, Oracle, Compaq, Hewlett Packard, Intel, SAP y unas trescientas más (para
obtener un listado completo, consulte UDDI: Community [en inglés]), unieron sus esfuerzos
para desarrollar una especificación basada en estándares abiertos y tecnologías no propietarias
que permitiera resolver los retos anteriores. El resultado, cuya versión beta se lanzó en
diciembre de 2000 y estaba en producción en mayo de 2001, fue un registro empresarial global
alojado por varios nodos de operadores en el que los usuarios podían realizar búsquedas y
publicaciones sin coste alguno.
A partir de la creación de esta infraestructura para servicios Web, los datos sobre estos
servicios se pueden encontrar de forma sistemática y confiable en una capacidad universal
totalmente independiente de proveedores. Se pueden llevar a cabo búsquedas categóricas
precisas utilizando sistemas de identificación y taxonómicos extensibles. La integración de UDDI
en tiempo de ejecución se puede incorporar a las aplicaciones. Como resultado, se fomenta el
desarrollo de un entorno de software de servicios Web.
Resulta importante observar que no existen requisitos de propietario respecto al modo en que
el operador del host implementa su nodo. El nodo sólo se debe ajustar a la especificación UDDI.
El nodo de Microsoft (http://uddi.microsoft.com/default.aspx [en inglés]), por ejemplo, se ha
Servicios Web en plataforma .NET - Manual completo Página 17 de 52
El próximo paso para comprender la iniciativa UDDI consiste en ver qué datos se almacenan en
UDDI y cómo se estructuran. UDDI es relativamente ligero; se ha diseñado como registro, no
como depósito. La diferencia, aunque sutil, resulta esencial. Un registro redirige al usuario a
recursos, mientras que un depósito sólo almacena información. El registro Microsoft®
Windows® puede servir de ejemplo: contiene las configuraciones y parámetros básicos pero, en
última instancia, su función es la de dirigir la aplicación a un recurso o binario. Buscar un
componente COM basándonos en su Id. de programa nos conducirá a un Id. de clase, que a su
vez nos dirigirá a la ubicación del binario.
z "¿Qué interfaces de servicios Web basadas en WSDL se han publicado y establecido para
un sector determinado?"
z "¿Qué empresas han escrito una implementación basada en una de estas interfaces?"
z "¿Qué servicios Web, categorizados de algún modo, se ofrecen actualmente?"
z "¿Qué servicios Web ofrece una empresa determinada?"
z "¿Con quién se debe poner en contacto el usuario para utilizar los servicios Web de una
empresa?"
z "¿Cuáles son los detalles de implementación de un servicio Web concreto?"
WSDL y UDDI
WSDL se ha convertido en una pieza clave de la pila de protocolos de los servicios Web. Por
eso, es importante saber cómo colaboran UDDI y WSDL y por qué la idea de interfaces frente
implementaciones forma parte de cada protocolo. WSDL y UDDI se diseñaron para diferenciar
claramente los metadatos abstractos y las implementaciones concretas. Para entender cómo
funcionan WSDL y UDDI resulta esencial comprender las consecuencias de esta división.
Por ejemplo, WSDL distingue claramente los mensajes de los puertos: los mensajes (la sintaxis
y semántica que necesita un servicio Web) son siempre abstractos, mientras que los puertos
(las direcciones de red en las que se invoca al servicio Web) son siempre concretos. No es
necesario que un archivo WSDL incluya información sobre el puerto. Un archivo WSDL puede
contener simplemente información abstracta de interfaz, sin facilitar datos de implementación
concretos, y ser válido. De este modo, los archivos WSDL se separan de las implementaciones.
Una de las consecuencias más interesantes de esto es que pueden existir varias
implementaciones de una única interfaz WSDL. Este diseño permite que sistemas dispares
escriban implementaciones de la misma interfaz, para garantizar así la comunicación entre
ellos. Si tres empresas diferentes implementan el mismo archivo WSDL y una parte del software
de cliente crea el código auxiliar/proxy a partir de esa interfaz, dicho software se podrá
comunicar con las tres implementaciones con el mismo código de base, cambiando simplemente
el punto de acceso.
UDDI establece una distinción similar entre la abstracción y la implementación con el concepto
de tModels. La estructura tModel, abreviatura de "Technology Model" (modelo de tecnología),
Servicios Web en plataforma .NET - Manual completo Página 18 de 52
Registro en UDDI
La publicación en UDDI es un proceso relativamente sencillo. El primer paso consiste en
determinar información básica sobre cómo definir la empresa y los servicios en UDDI. El
siguiente paso, una vez determinada esta información, consiste en llevar a cabo el registro, ya
sea mediante programación o a través de una interfaz de usuario basada en el Web. Por último,
se debe probar la entrada para asegurar que se registró correctamente y que aparece tal y
como se esperaba en diferentes tipos de búsquedas y herramientas.
Partiendo del modelo de datos descrito anteriormente, se debe recopilar cierta información
importante antes de establecer una entrada de UDDI.
Determine los tModels (archivos WSDL) que utilizan las implementaciones del servicio Web.
Al igual que sucede en el desarrollo de un componente COM, el servicio Web se ha desarrollado
a partir de una interfaz existente o de una interfaz de diseño propio. En el caso de un servicio
Web basado en una interfaz WSDL existente, deberá determinar si el archivo WSDL se ha
registrado en UDDI. Si es así, deberá comprobar su nombre y tModelKey, que es el identificador
GUID que generó UDDI cuando se produjo el registro.
Si su servicio Web es un servicio de Microsoft® Visual Studio® .NET, podrá generar una
descripción WSDL utilizando una cadena de consulta desde el archivo .ASMX (como ). No
obstante, el archivo WSDL generado por Visual Studio .NET se relaciona estrechamente con el
punto de acceso para la invocación del servicio Web, lo cual puede no resultar adecuado cuando
la interfaz del servicio tiene varias implementaciones. Esto no supondrá ningún problema si su
intención es que el archivo WSDL sólo tenga una implementación.
Resulta importante destacar que no todo el mundo puede obtener acceso a un servicio Web
porque éste se haya registrado en UDDI. A una entrada de registro UDDI le pueden acompañar
medidas de seguridad, autorización y autenticación. No basta que el usuario sepa que existe un
servicio Web para que pueda invocarlo. Puede existir una comunicación fuera de banda entre
empresas antes de permitir el acceso a un servicio Web.
Una vez finalizada la tarea de definición, el siguiente paso consiste en registrar la empresa.
Deberá obtener una cuenta con un registro UDDI. Esta operación no se puede realizar mediante
programación, ya que deberá mostrar su conformidad con una declaración de condiciones de
uso. El nodo de Microsoft utiliza Passport para la autenticación, así que deberá adquirir una
cuenta de Passport (http://www.passport.com/Consumer/default.asp) para continuar con el
registro.
En este punto se ofrecen dos opciones: puede utilizar la interfaz de usuario Web del nodo de
Microsoft o realizar el registro mediante programación dirigiendo al propio nodo las llamadas a
API de SOAP. Si no piensa modificar la entrada o ésta es relativamente simple, bastará con la
interfaz de usuario Web. No obstante, si pretende actualizar la entrada con frecuencia, o bien,
ésta es más compleja, resulta recomendable realizar el proceso de registro con secuencias de
comandos, utilizando el SDK de Microsoft UDDI. Además, la interfaz de usuario de Microsoft no
está localizada en otros idiomas, así que se deberá registrar mediante programación para
disfrutar esa característica de la API de UDDI.
Para Terminar
UDDI y WSDL funcionan como especificaciones gratuitas que facilitar el desarrollo de una
colección de software basado en servicios Web. WSDL ofrece un modo formal de definir
servicios Web, independientemente del proveedor, que permitirá realizar llamadas a
procedimientos remotos de próxima generación, mientras que UDDI proporciona una amplia
Servicios Web en plataforma .NET - Manual completo Página 20 de 52
A la hora de tratar la seguridad en servicios Web XML, es necesario considerar los siguientes
puntos:
z ¿Cuál es nuestro objetivo? Limitar el acceso a servicios Web XML a usuarios autorizados,
evitar que los mensajes puedan ser visualizados por personas no autorizadas, etc.
z ¿Cómo vamos a cumplir con el objetivo deseado? Red, capa de transporte, sistema
operativo, servicio o aplicación.
z ¿Qué nivel de interoperabilidad deseamos y necesitamos en nuestra solución? Local o
global.
z ¿Cómo se puede aumentar la seguridad de los servicios Web XML actuales?
Como podrá comprobar seguidamente, estas técnicas ofrecen varias opciones que se pueden
combinar para obtener beneficios adicionales. Por ejemplo, un servidor de seguridad puede
funcionar con servicios Web XML para limitar el acceso a ciertas funcionalidades (métodos)
basándose en la identidad del cliente y las directivas definidas para cada cliente.
Creación de una infraestructura segura una infraestructura segura es la clave para contar con
servicios Web XML seguros. Microsoft ofrece una amplia gama de tecnologías que, una vez
integradas en un plan general de seguridad, permiten a las empresas proteger eficazmente una
infraestructura informática. Para completar la implementación con éxito, la planeación debe
considerar lo siguiente:
z Tener una idea detallada de los riesgos potenciales del entorno (como virus, intrusos y
desastres naturales.
z Realizar un análisis activo de la relación entre las consecuencias y contramedidas de una
intrusión y los riesgos.
z Crear una estrategia de implementación planeada con detenimiento para integrar las
medidas de seguridad en el conjunto de una red empresarial, basándose en los dos
puntos anteriores.
Uno de los métodos más sencillos para aumentar la seguridad de los servicios Web XML
consiste en asegurarse de que la conexión entre el cliente de servicios Web XML y el servidor es
segura. Esto se puede llevar a cabo mediante varias técnicas, dependiendo de la extensión de
la red y el perfil de actividades de las interacciones. Tres de las técnicas más comunes y
Servicios Web en plataforma .NET - Manual completo Página 21 de 52
accesibles son: reglas basadas en un servidor de seguridad, SSL (Secure Sockets Layer) y
redes privadas virtuales (VPN.
Si sabe con exactitud qué equipos van a tener acceso a los servicios Web XML, puede utilizar
reglas de servidor de seguridad para restringir el acceso a equipos con direcciones IP conocidas.
Esta técnica resulta particularmente útil si desea restringir el acceso a equipos en una red
privada virtual (por ejemplo, una red LAN/WAN corporativa) y no desea mantener el contenido
de los mensajes en secreto (cifrados. Los servidores de seguridad, como Microsoft Internet
Security and Acceleration (ISA) Server, pueden ofrecer reglas avanzadas basadas en directivas
que proporcionen distintas restricciones para clientes diferentes según su origen o identidad.
Esto resulta de gran utilidad cuando se espera que determinados clientes tengan acceso a
funcionalidades (métodos) diferentes de los mismos servicios Web XML.
Se puede utilizar SSL para establecer conexiones seguras en redes que no son de confianza
(como Internet. SSL cifra y descifra mensajes enviados entre el cliente y el servidor. Al cifrar
los datos, se evita que los mensajes sean leídos por terceros durante la transmisión. SSL cifra
el mensaje del cliente y, a continuación, lo envía al servidor. Una vez que el servidor lo recibe,
SSL lo descifra y comprueba que procede del remitente correcto (proceso que se denomina
autenticación. El servidor, o el servidor y el cliente, pueden tener certificados que se utilizan
como parte del proceso de autenticación y que proporcionan capacidades de autenticación
además del cifrado de la conexión. Aunque es un método muy eficaz para crear comunicaciones
seguras, SSL presenta un coste en rendimiento que debe tenerse en cuenta. Los servicios Web
XML de Microsoft admiten SSL integrado, tanto en clientes como en servidores.
Una red privada virtual es la extensión de una red privada que se conecta a través de redes
compartidas o públicas, como Internet. Las redes virtuales privadas permiten enviar datos entre
dos equipos en una conexión segura. Si bien su funcionamiento es similar a SSL, una red virtual
segura es una conexión punto a punto establecida a largo plazo. De este modo, mejora la
eficacia y permite la comunicación con servicios Web XML, pero requiere que se establezca una
conexión duradera a largo plazo para obtener un rendimiento mayor.
2.1 Autenticación:
La autenticación es el proceso por el que se comprueba la identidad de alguien o algo, para ver
si es lo que dice ser. Ese "alguien" o "algo" se denomina principal. La autenticación requiere
pruebas de identidad, denominadas credenciales. Por ejemplo, una aplicación cliente puede
presentar una contraseña como sus credenciales. Si la aplicación cliente presenta las
credenciales correctas, se asume que es quien dice ser.
2.2 Autorización:
Una vez que se ha autenticado la identidad de un principal, deben tomarse decisiones sobre la
autorización. El acceso se determina comparando la información del principal con información
de control de acceso, como listas de control de acceso (ACL. Es posible que los clientes tengan
distintos grados de acceso. Por ejemplo, algunos clientes pueden tener acceso total a los
servicios Web XML, mientras que otros estarían autorizados sólo a ciertas operaciones. A
algunos clientes se les permitirá un acceso total a todos los datos, mientras que a otros sólo se
les permitirá acceso a un subconjunto de los datos y otros tendrán acceso de sólo lectura.
Un modo sencillo de implementar servicios Web XML Web consiste en aprovechar las
características de autenticación del protocolo que se utilice para intercambiar mensajes. Para la
mayoría de los servicios Web XML, esto significa aprovechar las características de autenticación
disponibles en HTTP. Microsoft Internet Información Server (IIS) e ISA Server funcionan en
Servicios Web en plataforma .NET - Manual completo Página 22 de 52
conjunción con Windows 2000 Server y ofrecen soporte para varios mecanismos de
autenticación en HTTP.
Desde la perspectiva de alguien que intenta implementar servicios Web XML, una de las
ventajas de utilizar estos mecanismos de autenticación es que no se necesita escribir nuevo
código. IIS/ISA Server completa todo el proceso de autenticación y autorización ACL antes de
llamar a los servicios Web XML. Sin embargo, al implementar el cliente será necesario realizar
algunas tareas adicionales. La aplicación cliente necesitará responder a las peticiones de
autenticación y credenciales del servidor.
Entre los métodos para la implementación de autenticación en servicios Web XML también se
incluyen servicios de terceros, como los que se encuentran en Microsoft® . NET Passport,
características de sesión de Microsoft ASP.NET o la creación de métodos de autenticación
personalizados.
3 Próximamente: Interoperabilidad
Como puede ver, las técnicas habituales para crear aplicaciones Web seguras se pueden aplicar
por separado o combinadas a la hora de proteger servicios Web XML. Estas técnicas ya se han
utilizado en el pasado y resultan bastante efectivas. Sin embargo, no ofrecen una solución
integrada dentro de la arquitectura de servicios Web XML. Conforme aumenta la complejidad
del entorno de servicios Web XML (sobrepasando los límites de la confianza, extendiéndose a
múltiples sistemas o empresas) los responsables de implementarlos tienen que recurrir a
soluciones personalizadas que, si bien resultan eficaces, no ofrecen una interoperabilidad total.
Para hacer frente a estas necesidades y mejorar la interoperabilidad entre servicios Web XML,
Microsoft y sus socios están trabajando en un conjunto de especificaciones de seguridad
basadas en el mecanismo de extensibilidad de la especificación SOAP para ofrecer funciones de
seguridad mejoradas e integradas en el núcleo mismo de los servicios Web XML.
infraestructura y otros protocolos de servicios Web XML para hacer frente a un gran número de
requisitos de seguridad de aplicaciones. La arquitectura de servicios Web XML globales de
Microsoft alberga a WS-Security y otras especificaciones relacionadas y proporciona un marco
para la evolución de la infraestructura de los servicios Web XML.
Muchos de los trabajos de la comunidad SOAPBuilders han sido necesarios en relación con
varios aspectos de las especificaciones SOAP 1.1 y WSDL 1.1. El W3C dispone de grupos de
trabajo focalizados en refinar ambas especificaciones, lo que debería aportar mejoras
sustanciales. El grupo XML Protocol Working Group está trabajando en la especificación SOAP
1.2 mientras que el grupo Web Services Description Working Group está creando la
especificación WSDL 1.2. Mientras tanto, IETF y OASIS están también trabajando en
estandarizar especificaciones de servicios Web, incluyendo DIME y WS-Security.
Mientras que el trabajo en el W3C se centra en las nuevas versiones de las especificaciones del
núcleo de los servicios Web, existe otra organización independiente que está prestando más
atención a la interoperabilidad. La organización Web Services Interoperability Organization
(WS-I) tiene como objetivo definir mejores prácticas para garantizar la interoperabilidad de los
servicios Web. El grupo WS-I Basic Profile Working Group está actualmente desarrollando un
conjunto de recomendaciones sobre cómo utilizar los protocolos básicos de los servicios Web
como SOAP 1.1 y WSDL 1.1 para maximizar la interoperabilidad.
problema y no hay ninguna razón por la que cada desarrollador de servicios Web deba
implementarlas individualmente. Microsoft, IBM y otros están realizando mucho trabajo en
estas áreas. La iniciativa Global XML Web Service Architecture (GXA) define un conjunto de
especificaciones sobre cómo implementar estos servicios de infraestructura en términos de
mensajes SOAP (por ejemplo, de un modo neutral respecto del protocolo de transporte.
En tercer lugar, los kits de herramientas y marcos de trabajo seguirán mejorando. Además de
servicios de más alto nivel como la seguridad y los objetos adjuntos, se añadirá soporte para
protocolos de transporte alternativos como SMTP o TCP. De modo más importante, los modelos
de programación migrarán desde los servicios de tipo RPC hacia servicios centrados en
documentos, para promover un acoplamiento débil. Todos estos cambios ocurrirán en paralelo,
mientras los desarrolladores continúan desarrollando e implantando sistemas basados en
servicios Web.
3 Avances de futuro
Llegados a este punto, estaremos preguntándonos cómo podemos utilizar los servicios Web
cuando la plataforma todavía está evolucionando. Las herramientas y marcos de trabajo de los
servicios Web actuales proporcionan suficiente funcionalidad básica para desarrollar
interesantes aplicaciones distribuidas que envían mensajes SOAP sobre HTTP. Algunos servicios
de mayor nivel como WS-Security están empezando a cuajar con el soporte de diversas
herramientas nuevas como el kit Web Services Development Kit. Otros servicios están todavía
en fase de desarrollo preliminar a medida que las especificaciones se van revisando y las
primeras implementaciones exponen áreas en las que las especificaciones necesitan
solidificarse. Mientras tanto, podemos apoyarnos en mecanismos HTTP tradicionales para
implementar seguridad y demás características.
También podemos experimentar con las nuevas especificaciones. La versión preliminar del kit
Microsoft WSDK Technology Preview proporciona un soporte preliminar para las especificaciones
WS-Security, WS-Routing y DIME. Podemos también implementar especificaciones por nosotros
mismos, tanto utilizando extensiones sobre uno de los marcos de trabajo o kits de herramientas
(por ejemplo, SoapExtensions en ASP.NET), como crear nuestra propia pila SOAP utilizando
XML plano y las APIs HTTP. Esta opción no es para todo el mundo, pero si tenemos tiempo y
recursos, obtendremos pronto una avanzada funcionalidad. Además, contribuiremos al
desarrollo de la plataforma. El entendimiento colectivo de SOAP Y WSDL se mejoró
sustancialmente gracias al intento de implementación de sistemas basados en ambos
estándares por parte de múltiples usuarios. Cuanto más estrechamente trabajen los usuarios
con las nuevas especificaciones, mejor resultará la plataforma de servicios Web global.
Servicios Web en plataforma .NET - Manual completo Página 25 de 52
Algunos gurús de la industria de computación vaticinan que este cambio ser equivalente al que
produjo la introducción de la PC, la interfase visual o al surgimiento mismo de Internet.
Dispositivos móviles como celulares, TabletPC (PCs que parecen un cuaderno de notas pero
tienen la capacidad de una computadora de escritorio), hasta televisores u otros dispositivos
hogareños estarán conectados entre sí, con servidores y distintas aplicaciones. El elemento
integrador será Internet. Estamos ahora en el inicio de la tercera generación de Internet. Con
Visual Studio .NET y ASP.NET Web Matrix vamos a ser protagonistas del cambio.
El tema de fondo es romper barreras. Barreras entre distintas aplicaciones que tienen
información, barreras entre sistemas, barreras entre los sistemas y la gente que los utiliza,
barreras entre las organizaciones.
Estos son algunos de los estándares que permiten hacer uso de los Servicios Web basados en
XML:
Nadie discute tampoco la importancia del uso de los servicios Web, toda la industria de software
esta enfocada a ello. La competencia es por proveer de las mejores herramientas basadas en
estándares y las más fáciles y más productivas herramientas para construir las aplicaciones. La
plataforma .NET es la infraestructura, los servicios y productos que Microsoft ofrece.
Servicios Web en plataforma .NET - Manual completo Página 26 de 52
Antes de la adopción del modelo de Servicios Web basados en XML los datos eran 'islas' que se
encontraban dentro de las aplicaciones en las empresas. Era muy difícil y costoso implementar
soluciones para acceder a la información desde afuera de la aplicación y la empresa. Las
aplicaciones pueden ahora, comunicarse entre sí y con los sistemas de sus socios, proveedores
y clientes gracias a los Servicios Web y XML.
En resumen, con el uso de los servicios Web se integra la información que puede ser accedida
desde distintos dispositivos, desde distintas plataformas de hardware o software y que puede
estar guardada en distintos formatos. El lenguaje estándar para lograr esta integración es XML.
Todos los servidores corporativos de .NET entienden este lenguaje. Siguientes versiones de
estos servidores van a incorporar muchas mejoras en este aspecto. Ejemplo de esto es la
siguiente versión de SQL Server 2000 llamada Yukon. Este producto puede guardar datos en
formato nativo XML, además permite hacer consultas al servidor no solamente en el lenguaje
típico de bases de datos sino también en cualquier lenguaje compatible con la plataforma .NET.
Provee los cimientos para la nueva generación de software. Utiliza los Servicios Web como un
medio para poder interoperar a distintas tecnologías. Permite conectar distintos sistemas
operativos, dispositivos físicos, información y usuarios. Les da a los desarrolladores las
herramientas y tecnologías para hacer rápidamente soluciones de negocios que involucran
distintas aplicaciones, dispositivos físicos y organizaciones.
Los desarrolladores por su parte tienen la infraestructura y herramientas para crearlos y hacer
uso de ellos en programas. Es decir, se trata de aprovechar la capacidad de distribución a gran
escala de Internet para acceder a servicios de software. También se trata de aprovechar el
incremento en la capacidad de procesamiento de los nuevos dispositivos móviles llamados
"Smart Devices" (dispositivos inteligentes) para que el usuario haga uso de la funcionalidad que
proveen los servicios Web con interfases cada vez más sencillas y naturales como la voz o la
escritura.
La siguiente versión del portal MSN, MSN 8, es un ejemplo de software como servicio. Utiliza los
ladrillos de construcción que proveen el servicio Web Passport y .NET Alerts (los cuales
estudiaremos más adelante). Permite además instalar software actualizado mientras se hacen
Servicios Web en plataforma .NET - Manual completo Página 27 de 52
Tanto la invocación de los servicios como su ejecución pueden ser hechas en cualquier
dispositivo y sistema operativo, y accedido desde Internet. Los sitios se comunican entre sí y
acceden a servicios y contenidos sin la intervención humana. Por eso se llama a la nueva
generación de Internet "Internet inteligente".
Smart Clients (Clientes Inteligentes): Son dispositivos muy variados. Lo que los hace 'Smart' o
inteligentes es su capacidad para hacer uso de servicios Web.
Sistemas Operativos: Windows 2000: Server, Advance Server y Datacenter, Windows Server
2003: Standard, Enterprise, Datacenter y Web Server.
z Microsoft Application Center 2000: Para instalar y administrar aplicaciones Web altamente
disponibles y escalables.
z Microsoft BizTalk Server 2000 : Para construir procesos de negocios basados en XML a
través de distintas aplicaciones y organizaciones.
z Microsoft Commerce Server 2000: Para construir rápidamente soluciones de e-commerce
escalables.
z Microsoft Content Management Server 2001: Para administrar contenido para sitios Web
de e-bussines dinámicos.
z Microsoft Exchange Server 2000: Para permitir enviar mensajes y trabajar en forma
colaborativa en cualquier momento y lugar.
z Microsoft Host Integration Server 2000: Para acceder a datos y aplicaciones en
mainframes.
z Microsoft SQL Server 2000: Para almacenar, recuperar y analizar datos en formato XML.
z Microsoft SharePoint Portal Server 2001: Para encontrar, compartir y publicar información
de negocios.
z Microsoft Internet Security and Acceleration Server 2000: Para conectividad a Internet
rápida y segura.
z Microsoft Mobile Información 2001 Server: Para soportar aplicaciones en dispositivos
móviles como por ejemplo celulares.
Servicios Web basados en XML: Son los bloques de construcción de la tercera generación de
Internet. Algunas de sus características son:
Cliente con Cliente: Smart Clients o dispositivos pueden proveer de servicios Web y utilizarlos
para permitir que la información este disponible en todo momento y lugar.
Cliente con Servidor: Los servicios Web permiten que un servidor comparta datos con una PC
o un dispositivo móvil vía Internet.
Servicio con Servicio: Un servicio Web puede invocar a otro, aumentando de esta manera la
funcionalidad disponible.
La plataforma .NET
Es claro entonces que el objetivo de la plataforma .NET es simplificar el desarrollo de
aplicaciones Web. Provee las herramientas y tecnologías para transformar a Internet en una
plataforma de computación distribuida en gran escala. Esta plataforma además soporta los
estándares sobre los cuales se basan los servicios Web.
La plataforma .NET utiliza tecnologías existentes, productos modificados para su uso dentro de
la plataforma y elementos nuevos.
Productos existentes: COM.
Microsoft tiene una tecnología para la creación, invocación y uso de componentes llamada COM
(Modelo de Objetos Componentes). Al igual que el protocolo SOAP utilizado para la invocación
de los servicios Web, COM establece las reglas acerca de cómo los objetos deben ser invocados
y cómo deben interactuar. También los componentes COM pueden implementar funcionalidad
similar a la de los servicios Web. Sin embargo tienen dos puntos en contra. Primero: No son
una tecnología estándar. Segundo: No pueden ser utilizados fuera de la barrera de seguridad
que las empresas tienen para su comunicación hacia y desde Internet (firewall). Por lo tanto no
sirven al modelo de computación distribuida en Internet.
Sin embargo, hay muchas soluciones que usan COM en el mercado. La plataforma .NET puede
por medio de clases especiales hacer uso de COM y los objetos COM también pueden hacer uso
de servicios Web. Lo que permite aprovechar la plataforma instalada para el desarrollo de
nuevos proyectos.
Productos Modificados: La familia de sistemas operativos de Windows 2000 fue modificada para
soportar a la plataforma .NET. También todos los productos de servidores de aplicaciones
fueron modificados para permitir la interoperatividad basada en XML.
Elementos Nuevos: BizTalk Server es un producto pensado para entender y manipular datos en
formato XML y para poder transformar datos en XML a otros formatos y viceversa. Permite
coordinar el flujo de información entre aplicaciones dentro de la empresa y también "orquesta"
el flujo de datos con otras empresas.
De ahí que se califique a su función como "orquestación". Algo muy importante actualmente ya
que las distintas aplicaciones deben comunicarse entre sí y muchas veces los formatos de los
datos son incompatibles. El .NET Framework es una tecnología nueva de Microsoft y por su
importancia merece que la estudiemos con detenimiento
El .NET Framework
Servicios Web en plataforma .NET - Manual completo Página 30 de 52
El .NET Framework se instala como un componente aparte en Windows 2000, mientras que
Windows XP y las futuras versiones de Windows lo incorporan directamente al sistema
operativo. Como por ejemplo Windows Server 2003 o Windows .NET CE.
El .NET Compact Framework permite hacer uso de los servicios Web en dispositivos móviles.
Debido a que es un subconjunto del .NET Framework comparte el mismo modelo de
programación y herramientas de desarrollo de aplicaciones haciendo posible que los
desarrolladores transfieran sus conocimientos existentes al desarrollo de aplicaciones móviles.
Los componentes del .NET Framework proveen los "ladrillos" necesarios para construir las
aplicaciones Web, los servicios Web y cualquier otra aplicación dentro de Visual Studio .NET.
Ahora que tenemos una visión general del .NET Framework, vamos a estudiar que función
cumplen las partes que lo componen.
El Common Language Runtime provee lo que se llama código administrado, es decir, un entorno
que provee servicios automáticos al código que se ejecuta. Los servicios son variados:
La librera de clases base son las clases sobre las cuales se construyen todas las demás clases
que utilizan los programas de Visual Studio .NET. La clase madre de todas es System. A partir
de ella por un mecanismo llamado herencia de clases, se construyen las demás clases.
Debido a que en la librería de clases base hay muchas clases, se utiliza para identificarlas un
mecanismo llamado espacio de nombres (namespace). La parte del nombre de la clase que se
encuentra a la derecha del último punto se llama tipo de la clase. Todo lo que resta se llama
espacio de nombres. Por ejemplo: En la clase llamada System.Runtime.InteropServices,
InteropServices es el tipo de la clase y System.Runtime es el espacio de nombre. El espacio de
nombre es una manera de organizar en grupos las distintas clases. Esto hace más manejable y
fácil su uso.
La librera de clases base es independiente del lenguaje. Permite el uso y la depuración de otros
lenguajes. Es extensible ya que por el mecanismo de herencia el usuario puede crear nuevas
clases que usan las clases base como "ladrillos". También el usuario puede incorporarlas en
bibliotecas para su utilización posterior. Es segura ya que es posible permitir o restringir su uso
por medio de distintos mecanismos de seguridad.
Cuando usted crea una aplicación Windows en algún lenguaje compatible con la
plataforma .NET, puede utilizar cualquiera de los servicios que la biblioteca de clases de .NET
provee. Por ejemplo: Puede usar clases para hacer ventanas que tengan distintos tipos de
controles. Cuando compila la aplicación, se crea un código intermedio llamado MSIL. Este
código es independiente de la plataforma de hardware. Una vez compilado, el ejecutor de
lenguaje común administra la ejecución de la aplicación.
Uno de los subsistemas del Common Language Runtime se llama compilación JIT, que transforma el código intermedio
MSIL al código de máquina en el sistema donde la aplicación se va a ejecutar. Esta compilación a lenguaje de máquina
Servicios Web en plataforma .NET - Manual completo Página 32 de 52
lo hace en el momento de ejecución del código. Cuando un dispositivo de cliente, por ejemplo, un celular "Smart
phone", ejecuta una aplicación hecha con Visual Studio .NET, se ejecuta en el código de máquina del sistema del
cliente. La aplicación sin embargo puede interactuar con otras aplicaciones .NET y servicios independientemente del
lenguaje en que fueron desarrollados.
El objetivo de la actividad es presentar fundamentos teóricos generales relativos a la tecnología de webservices, y como
puede ser implementada en los escenarios más comunes con que nos encontraremos.
Como implementación, comenzaremos construyendo un webservice muy sencillo, el cual será testado a través del
browser.
z Página ASP.Net
z Aplicación Windows .Net
z Aplicación Excel de Office XP
z Aplicación de Internet Mobile
z Aplicación Visual Basic 6.0
Requerimientos
Software
Servidor - Webservice
Desarrollo Webservice
z MS SoapToolkit
z Office XP
o
z Webservice referente toolkit (para creación del Proxy)
2 Implementación
Desarrollando un webservice
1.) En Visual Studio .Net, creamos un proyecto ASP.Net Webservices, llamado "WorkShopUDP_v1"
Servicios Web en plataforma .NET - Manual completo Página 33 de 52
2.) Eliminar los comentarios (comilla simple) del método HelloWorld() de la clase - service1.
3.) Cambiamos el nombre de la "Service1" por "Saludo"
Antes:
Imports System.Web.Services
<WebService(Namespace := "http://tempuri.org/")> _
Public Class Service1
Inherits System.Web.Services.WebService
End Sub
#End Region
End Class
Después:
Imports System.Web.Services
<WebService(Namespace:="http://tempuri.org/")> _
Public Class Saludo
Inherits System.Web.Services.WebService
End Sub
#End Region
End Class
4.) Cambiar el nombre del archivo "Service1.asmx" a "mensaje1.asmx" a través del solution Explorer.
Antes:
Servicios Web en plataforma .NET - Manual completo Página 35 de 52
Después:
3 Testing
Clickar "Invoke"
2.) Agregamos referencia al webservice al proyecto: En el "Solution Explorer" pulsar botón derecho sobre "References"
y "Add Web Reference" En la barra de direcciones de la ventana, agregar la dirección del webservice creado.
http://localhost/WorkShopUDP_v1/mensaje1.asmx
Comprobar en el "Solution Explorer" la referencia agregada, y cambiar el nombre del fólder "localhost" a "wsSaludos"
Antes:
Después:
3.) Comprobamos a través del explorador de Windows la existencia de los archivos "mensaje1.disco" y "mensaje1.wsdl"
existen en el directorio "wsSaludos"
Servicios Web en plataforma .NET - Manual completo Página 39 de 52
4.) En el código del formulario, importamos en espacio de nombres asociado a la referencia al webservice agregada.
TextBox1.Text = objWsSaludo.HelloWorld()
Imports testWebServiceHelloWorld.wsSaludos
End Sub
End Sub
#End Region
Imports testWSAsp.wsSaludos
- En el código del botón, instanciar un objeto de la clase "Saludo", invocar la función "HelloWorld" asignando el
resultado al TextBox1.
Imports testWSAsp.wsSaludos
End Sub
#End Region
End Sub
End Class
Pulsando el botón:
- En el código del Mobile Web Form, importar el espacio de nombres asociado al webservice.
Imports MobileWebWSSaludo.wsSaludos
- En el código del botón, instanciar un objeto de la clase "Saludo", invocar la función "HelloWorld" asignando el
resultado al TextBox1.
Imports MobileWebWSSaludo.wsSaludos
End Sub
#End Region
Menu: Tools à Macro à Visual Basic Editor, o bien, Alt+F11 2.) Usando el webservice referente tool, agregar referencia
al webservice Menu: Tools à Webservice Referentes
Esto ha creado el módulo de clase "clsws_Saludo" (Proxy al Webservice) Ver Explorador del proyecto.
Servicios Web en plataforma .NET - Manual completo Página 47 de 52
Public Function HelloMarco() As String Dim objWS As New clsws_Saludo HelloMarco = objWS.wsm_HelloWorld End
Function
Servicios Web en plataforma .NET - Manual completo Página 48 de 52
Tenemos que agregar en el formulario que deseamos insertar el código de seguridad los siguientes controles:
#Region "Members"
Dim bAntiBots As Boolean = False
#End Region
En el Page_Load:
Servicios Web en plataforma .NET - Manual completo Página 49 de 52
Tenemos que crear la función GenerateRandomCode para generar un código de seguridad al azar
#Region "GenerateRandomCode"
While (i <; 6)
iChr = random.Next(48, 90)
While iChr >; 57 And iChr <; 65
iChr = random.Next(48, 90)
End While
s = String.Concat(s, Chr(iChr).ToString())
i=i+1
End While
Return s
End Function
#End Region
Para seguir, nos faltará crear la clase encargada de crear, manipular y deformar el código de seguridad generado en
imagen
Imports System
Imports System.Drawing
Imports System.Drawing.Drawing2D
Imports System.Drawing.Imaging
Imports System.Drawing.Text
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
Me.m_width = width
Me.m_height = height
End Sub
Catch ex As Exception
Me.m_familyName = System.Drawing.FontFamily.GenericSerif.Name
End Try
End Sub
'Rellenamos el fondo
Dim hatchBrush As New HatchBrush(HatchStyle.SmallConfetti, Color.LightGray, Color.White)
g.FillRectangle(hatchBrush, rect)
'Establecemos la fuente
Dim size As SizeF
Dim fontSize As Single = rect.Height + 1
Dim font As Font
'Ajusta el tamaño de la fuente
Do
fontSize = fontSize - 1
font = New Font(Me.m_familyName, fontSize, FontStyle.Bold)
size = g.MeasureString(Me.m_text, font)
Loop While (size.Width >; rect.Width)
'Deformamos la imagen
path.Warp(points, rect, matrix, 0)
'Dibuja el texto
hatchBrush = New HatchBrush(HatchStyle.OutlinedDiamond, Color.Orange, Color.BlueViolet)
g.FillPath(hatchBrush, path)
'Añade efectos
Dim m As Int32 = Math.Max(CType(rect.Width, Integer), CType(rect.Height, Integer))
Dim i As Int32 = 0
While i <; CType((rect.Width * rect.Height / 30.0F), Int32)
Dim x As Int32 = m_random.Next(CType(rect.Width, Integer))
Dim y As Int32 = m_random.Next(CType(rect.Height, Integer))
Dim w As Int32 = m_random.Next(CType(m / 50, Integer))
Dim h As Int32 = m_random.Next(CType(m / 50, Integer))
g.FillEllipse(hatchBrush, x, y, w, h)
i=i+1
End While
font.Dispose()
hatchBrush.Dispose()
g.Dispose()
'Establece la imagen
Me.m_image = bitmap
End Sub
End Class
Ahora en el proyecto crearemos la página que apunta nuestra imagen (el primer control que hemos agregado en el
proyecto, y en el Page_Load pondremos este código:
Y para terminar, en el formulario del registro, dónde hemos agregado los controles, en el botón del submit, utilizar esta
condición:
If bAntiBots Then
' Creamos el registro
Else
' El código de seguridad no está bien colocado
End if
z Benjamín González C.
Ingeniero de Sistemas
(21 capítulos)
z Pol Salvat
http://www.mistrucos.net/
(1 capítulo)
Volver [http://www.desarrolloweb.com/manuales/54]