Taller de Web Services: Introducción a la creación, distribución, registro, consumo y presentación de resultado. Resumen Mayo de 2007 Este documento tiene la finalidad de proporcionar de una manera breve los conocimientos y habilidades básicas necesarias para el desarrollo de soluciones basadas en Web Services como implementación de la arquitectura orientada a servicios (SOA), incluyendo los conceptos elementales y los procesos de generación, distribución, registro, consumo y presentación de resultados con apoyo de Microsoft Visual Studio.NET 2003.
El Data Warehouse es un ingrediente fundamental para la toma de decisiones y para la construcción de un modelo de Inteligencia de Negocios. lmplementar un DWH, a grandes rasgos consiste en las siguientes actividades y procesos: analizar los requerimientos de información de las áreas usuarias; documentar las reglas de negocio y las fuentes de datos; diseñar las bases de datos que almacenarán la información requerida por los usuarios; diseñar y construir los procesos de extracción-transformación-carga (ETL por sus siglas en inglés) necesarios para recuperar los datos fuente, convertirlos en información y cargarlas dentro del DWH; implementar las herramientas de análisis, explotación y reporteo de información almacenada en el DWH. Una de las funciones de un DWH es concentrar datos dispersos y generar información integrada sobre temas particulares, las organizaciones en general pueden esperar todos o varios de los siguientes beneficios: mejorar la oportunidad con la que se genera y entrega información para la toma de decisiones; elevar la calidad de la información utilizada y reducir el nivel de incertidumbre respecto a la confiabilidad de la misma, entre otras.
Introducción 1 Breve historia de la evolución de la Web. 1 El porqué de los Web Services. 2 La arquitectura de los web services. 3 Definición de XML Web Services 4 XML 5 XSD 5 SOAP 6 HTTP WSDL 7 UDDI 9 Escenario de operación de los Web Services. 9 Creación de un Web Services 10 Distribución de un Web Services 14 De manera manual. 14 Utilizando un Instalador de archivos de Windows. 15 Registro en UDDI 16 Consumo de un Web Service 18 Creación de un proyecto Web 18 Adicionar referencia web 19 Descubrimiento del Web Services con UDDI. 20 Aspectos de Seguridad 24 Otras plataformas para Web Services. 26 Referencias 27
Introducción Breve historia de la evolución de la Web. Antes de dar una explicación del porqué de los web services es necesario dar una revisión a la historia comenzando por el suceso histórico del surgimiento de Internet. Al principios su uso fue privilegiado durante muchos años al mundo académico, posteriormente se da el surgimiento del Word Wide Web que trae consigo una característica muy innovadora que vino a facilitar el acceso a la información, desde cualquier lugar usado los protocolos de Internet (TCP/IP) desde browsers implementados en diferentes plataformas que permitieron el acceso a información (human-to-application) de diferentes sitio. En una etapa posterior se incluyen la surgen las aplicaciones en Web que integran base de datos para la generación de contenidos dinámicos. En 1999, Microsoft publico el protocolo XML-based, llamado SOAP, que puede ser usado para el escenario A2A (application-toapplication) que reúne un conjunto de sugerencias de diferentes protocolos (HTTP, XML, WSDL,UDDI), cerca del 2000 establece relaciones con IBM para dar soporte al estándar, donde eventualmente SOAP no tuvo buena aceptación en la industria, pero posteriormente gana popularidad rápidamente. Fue claro que era necesario contar con una descripción y fácil localización del servicio para implantar su uso. El termino Web Services fue concebido meses después, cuando IBM y Microsoft, publicaron juntos el Web Services Description Language (WSDL). Fig.1 Evolución de la Web. Introducción a la creación, distribución, registro y consumo de Web Services 1
El porqué de los Web Services. Para entender la importancia de XML Web Services es necesario conocer el problema que tratan de solucionar, especialmente en la evolución de las aplicaciones distribuidas y sus limitaciones de la arquitectura de este tipo de aplicaciones. Anteriormente se realizaron intentos de crear soluciones con el modelo de componentes distribuidos de Microsoft (DCOM, Distributed Componet Object Model), una infraestructura de objetos distribuidos que permite a una aplicación invocar componentes de Modelo de objetos componentes (COM, Componet Object Model) instalados en otro servidor, para se portados a otras plataformas que no sean de Windows. Pero DCOM nunca a tenida aceptación en dichas plataformas. En el caso de CORBA - ORB y Java RMI están limitados a aplicaciones y componentes instalados en el mismo centro de datos corporativo. Las dos razones para ello son que de manera predeterminada estas tecnologías utilizan protocolos propietarios y dichos protocolos y dichos protocolos son inherentemente orientados a conexiones. Otro gran problema es que se hacía uso de RPC (Remote Procedure Call) para realizar la comunicación entre diferentes nodos. Esto, además de presentar ciertos problemas de seguridad, tiene la desventaja de que su implementación en un ambiente como es Internet, es casi imposible (muchos firewalls bloquean este tipo de mensajes, lo que hace prácticamente imposible a dos computadoras conectadas por Internet comunicarse). Fig.2 Problemática de integración con otras tecnologías. Introducción a la creación, distribución, registro y consumo de Web Services 2
Los problemas con problemas existentes con el modelo de objetos para aplicaciones distribuidas forzaron a los desarrolladores a buscar nuevas alternativas. Con la rápida adopción de los estándares de la Web permitió la evolución de los Web Services. Como solución a la problemática Fig.2, los XML Web Services son los elementos fundamentales en la evolución hacia la computación distribuida a través de Internet. Surgieron ante una necesidad de estandarizar la comunicación entre distintas plataformas (PC, Mainframe, Mac, etc.) y lenguajes de programación (PHP, C#, Java, etc.), tal como se puede observar en la Fig.3. Fig.3 Problemática de integración con otras tecnologías. La arquitectura de los web services. Los web services son la una implementación de la arquitectura orientada a servicios (SOA), que propone una implantación dinámica, de bajo acoplamiento y de aplicaciones distribuidas. SOA consiste en tres roles principales: un proveedor de servicios, un consumidor y un intermediario. Fig.4 Representación de la implementación de SOA en los Web Services. Introducción a la creación, distribución, registro y consumo de Web Services 3
Definición de XML Web Services Un servicio Web es una aplicación software identificada mediante una URL, cuyo interfaz (y uso) es capaz de ser definido (WSDL), descrito y descubierto (UDDI) mediante artefactos XML, y soportar interacciones directas con otras aplicaciones software usando mensajes basados en XML (SOAP) y protocolos basados en Internet (HTTP). Existen varias definiciones para un XML Web Services pero la idea general es: Los servicios XML Web Services ofrecen funciones muy útiles a usuarios del medio Web ya que emplean un protocolo Web estándar que, en casi todos los casos, es SOAP. Los servicios XML Web Services permiten describir sus interfaces con suficiente detalle para que el usuario diseñe una aplicación cliente que permita comunicarse con ellas. Esta descripción se proporciona normalmente en un documento XML denominado WSDL (lenguaje de descripción de servicios Web). Los servicios XML Web Services se registran para que los futuros usuarios los encuentren fácilmente. Este registro se realiza a través de UDDI (descripción, descubrimiento e integración universales). Además son unidades autónomas de funciones de negocios, conectados a través de la red de forma distribuida, contratada a través de una interfase accesible por una URI, de bajo acoplamiento, independientes de cualquier plataforma, herramientas de desarrollo, metodología, u ubicación geográfica. De acuerdo a la arquitectura mostrada en la Fig. 4 los elementos que componen a los web services son: XML XML (extensible Markup Lenguage - Lenguaje extensible de marcas) es un un lenguaje abierto, derivado de SGML, optimizado para su uso en la WWW, y que va a permitirnos describir el sentido o la semántica de los datos. El XML, a diferencia del HTML, separa el contenido de la presentación. XML es un Meta-Lenguaje, que permite la definición de lenguajes concretos de representación de documentos, es usado en la implementación de Web Services para comunicar al consumidor y al proveedor (para construcción de los mensajes de SOA), también se utiliza para describir la interfase de los Web Services (WSDL). Ejemplo de un XML: <?xml version="1.0" encoding="utf-8"?> <SerieEstadistica> <Clave_de_serie>5157</Clave_de_serie> <Año>2000</Año> <Periodo>12</Periodo> <Dato>8581</Dato> <Numero_Decimales>0</Numero_Decimales> <Unidad_de_Medida>Miles de pesos a precios corrientes</unidad_de_medida> <Frecuencia>Mensual</Frecuencia> </SerieEstadistica> Introducción a la creación, distribución, registro y consumo de Web Services 4
Las recomendaciones para la construcción de XML bien formado son las siguientes: Tiene que haber un elemento raíz, XML se ordena en forma de árbol. Todos los elementos necesitan e estar cerrados. Las etiquetas de apertura y cerrado deben de ser o minúsculas o mayúsculas, <PERIODO>12</Periodo> Los elementos deben de anidarse correctamente. Un atributo no puede ser repetido en un elemento. XSD XML Schema Definition XSD describe la estructura de un documento XML, son importantes porque definen también el tipo de dato de los elementos y atributos devueltos en el XML. <?xml version="1.0" encoding="utf-8"?> <xs:schema id="indicadores" targetnamespace="http://www.inegi.gob.mx/indicadores.xsd" elementformdefault="qualified" attributeformdefault="qualified" xmlns=" http://www.inegi.gob.mx/indicadores.xsd " xmlns:mstns=" http://www.inegi.gob.mx/indicadores.xsd " xmlns:xs="http://www.w3.org/2001/xmlschema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata"> <xs:element name= Indicadores" msdata:isdataset="true"> <xs:complextype> <xs:choice maxoccurs="unbounded"> <xs:element name="indicadores" type="complextype1"></xs:element> </xs:choice> </xs:complextype> </xs:element> <xs:complextype name="complextype1"> <xs:sequence> <xs:element name="clave_de_serie " type="xs:string" minoccurs="0" /> <xs:element name="año" type="xs:string" /> <xs:element name="periodo" type="xs:string" /> <xs:element name="dato" type="xs:double" minoccurs="0" /> <xs:element name="numero_decimales" type="xs:int" minoccurs="0" /> Declaración del elemento Indicadores complextype1 Declaración del tipo complejo complextype <xs:element name=" Miles de pesos a precios corrientes " type="xs:string minoccurs="0" /> <xs:element name="frecuencia" type="xs:int" minoccurs="0" /> </xs:sequence> </xs:complextype> </xs:schema> Introducción a la creación, distribución, registro y consumo de Web Services 5
SOAP SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar creado por Microsoft, IBM y otros, está actualmente bajo W3C que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. SOAP es uno de los protocolos utilizados en los servicios Web para el envío de mensajes a través de Internet mediante el protocolo HTTP. Fig. 5 Estructura general de SOAP. Ejemplo de un mensaje SOAP Petición del cliente <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:body> <obtienehistorialindicadorsdmx xmlns="http://inegi.gob.mx/indicadores"> <noindicador>string</noindicador> </obtienehistorialindicadorsdmx> </soap:body> </soap:envelope> Método que se invoca y parámetro a enviar Ejemplo de un mensaje SOAP Respuesta al cliente <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi="http://www.w3.org/2001/xmlschema- instance" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:body> <obtienehistorialindicadorsdmxresponse xmlns="http://inegi.gob.mx/indicadores"> obtienehistorialindicadorsdmxresult>string </obtienehistorialindicadorsdmxresult> </obtienehistorialindicadorsdmxresponse> </soap:body> </soap:envelope> Mensaje de respuesta al cliente Introducción a la creación, distribución, registro y consumo de Web Services 6
HTTP SOAP actualmente usa el método POST del HTTP para el envío de datos. La ubicuidad de HTTP y la sencillez de SOAP los convierte en una base perfecta para implementar XML Web Services que pueden llamarse desde prácticamente cualquier entorno. POST /Indicadores/Indicadores.asmx HTTP/1.1 Content-Type: text/xml; charset=utf-8... SOAPAction: "http://inegi.gob.mx/indicadores-bie/obtienehistorialindicadorsdmx" Content-Length: length <?xml version= 1.0?> <soap:envelope...>... </soap:envelope> Otras características importantes están en Content-Type que deberá de ser text/xml; y la propiedad SOAPAction deberá contener la concatenación del de un namespace, y el nombre del método. Una cuestión de seguridad podría ser que el administrador de la red pueda usar herramientas para filtrar las peticiones a través de HTTP y si es inadecuada rechazarla. WSDL Fig. 6 Procesamiento de los mensajes de SOAP. WSDL (Web Services Description Language), un formato XML que se utiliza para describir servicios Web. WSDL describe la interfaz pública a los servicios Web. Está basado en XML y describe la forma de comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su catálogo. Las operaciones y mensajes que soporta se describen en abstracto y se ligan después al protocolo concreto de red y al formato del mensaje. Introducción a la creación, distribución, registro y consumo de Web Services 7
Estructura general del XML del WSDL. Descripción de los elementos del WSDL Comienzo del documento, este tag agrupa a todos los <definitions> demás. Se definen los tipos de datos utilizados en el Web <types> Service. </types> Fin de la definición de tipos. Se definen los métodos y parámetros para realizar la <message> operación. Cada message puede consistir en una o más partes (parámetros). </message> Fin de la definición de los parámetros. Esta sección es la más importante, ya que se definen las operaciones que pueden ser realizadas, y los <porttype> mensajes que involucran (por ejemplo el mensaje de petición y el de respuesta). </porttype> Fin de la definición de las operaciones y mensajes. Se definen el formato del mensaje y detalles del <binding> protocolo para cada porttype. Fin de la definición del formato del mensaje y detalles </binding> del protocolo para cada PortType. </definitions> Fin del documento WSDL Introducción a la creación, distribución, registro y consumo de Web Services 8
UDDI UDDI son las siglas del catálogo de negocios de Internet denominado Universal Description, Discovery, and Integration. El registro en el catálogo se hace en XML. UDDI es una iniciativa industrial abierta (sufragada por la OASIS) entroncada en el contexto de los servicios Web. UDDI es uno de los estándares básicos de los servicios Web cuyo objetivo es ser accedido por los mensajes SOAP y dar paso a documentos WSDL, en los que se describen los requisitos del protocolo y los formatos del mensaje solicitado para interactuar con los servicios Web del catálogo de registros. Una entrada en un listín UDDI es un archivo XML que describe un negocio y los servicios que ofrece. Cada entrada tiene tres partes: Las "páginas blancas" describen los datos de la empresa, como nombre, dirección, información de contacto, etc. Las "páginas amarillas" incluyen las categorías industriales basadas en taxonomías estándares, como la NAICS (North American Industry Classification System) y la SIC (Standard Industrial Classification). Las "páginas verdes" describen la interfaz del servicio con información suficiente para que alguien escriba una aplicación para usar un servicio Web. Los servicios se definen por un documento UDDI denominado Type Model o tmodel. En muchos casos, tmodel contiene un archivo WSDL que describe una interfaz SOAP a un servicio XML Web; tmodel es suficientemente flexible para describir prácticamente cualquier tipo de servicio. Escenario de operación de los Web Services. El escenario de operación de los servicios web se representa de acuerdo a la Fig.8 Fig. 8 Proceso de operación de los Web Services Introducción a la creación, distribución, registro y consumo de Web Services 9
Creación de un Web Services Para la creación de un nuevo Web Services en Visual Studio.NET 2003 se siguen los siguientes pasos: 1. Abra Visual Studio.NET 2003, vaya al menú principal y secciones File (Archivo), New (Nuevo), Project (Proyecto) o bien solo precione Ctrl+Shift+N (a). a 2. En la pantalla de nuevo proyecto (New Project), seleccione Visual C# Projects (a), ASP.NET Web Service (b) y en la caja de texto de localización (Location) proporcione el nombre del proyecto donde esta contenido el Web Seviches(c). a b c Introducción a la creación, distribución, registro y consumo de Web Services 10
3. Para programar el código que dará la funcionalidad a nuestro Web Services presione en la pantalla central click here to switch the code view o bien de un clic derecho sobre Services1.asmx 4. Para programar el código que dará la funcionalidad a nuestro Web Services presione en la pantalla central click here to switch the code view o bien de un clic derecho sobre Services1.asmx, como recomendación cambie el nombre del servicio por un nombre representativo, para este caso Servicio1.asmx cambia por IndicadorEconomico.asmx, también es necesario cambiar el nombre de la clase y constructor. Introducción a la creación, distribución, registro y consumo de Web Services 11
5. Lo siguiente es el crear el método o métodos que expondrán la funcionalidad del servicio. [WebMethod (Description="Devuelve datos de la exportaciones de petroleo")] public DataSet ExportacionPetroleo() { //Lógica de negocios //Objeto para recibir la colección de datos //a consultar. DataSet resultado = new DataSet(); //Instancia la clase que extrae //la información de la base de datos IndicadoresEconomicos.dataAccess regresa = new IndicadoresEconomicos.dataAccess(); //Asigna los resultados al DataSet resultado =(regresa.regresads()); } //Devuelve los resultados. //la conversión del dataset a XML queda a cargo de SOAP. return resultado; El atributo WebMethod es necesario para poder exponer la funcionalidad en el WSDL. Para este caso se separo la consulta a datos en otra clase llamada dataaccess. La cual contiene: using System; using System.Data; using System.Data.SqlClient; // Para poder usar el DataSet //Para hacer consultas a SQL Server namespace IndicadoresEconomicos { /// <summary> /// Summary description for dataaccess. /// </summary> public class dataaccess { public dataaccess() { } public DataSet regresads() { SqlConnection connection = null; DataSet try { ds = new DataSet(); //Invoca al método GetConnection para generar la conexión //a la base de datos envía el provider como parámetro connection = GetConnection("user id=internet;pwd=password;data source=servidor;persist security info=true;initial catalog=basededatos;"); Introducción a la creación, distribución, registro y consumo de Web Services 12
//Genera el adaptador de SQL para asignar resultados al //dataset SqlDataAdapter sqldaindicadores = new SqlDataAdapter(); //Sentencia de SQL a ejecutar string = "SELECT * FROM SERIES WHERE ClaveSerie = 23542 sqldaindicadores.selectcommand = new SqlCommand(query,connection); //Llena el dataset con los resultados. sqldaindicadores.fill(ds); } catch(exception ex) { ex.message.tostring(); } finally { if(connection!= null) { connection.close(); connection.dispose(); } } //Regresa el dataset de resultado. return ds; } //Crea la conexión a la base de datos. private SqlConnection GetConnection(string connectionstring) } } { } SqlConnection connection = new SqlConnection(connectionString); connection.open(); return connection; Introducción a la creación, distribución, registro y consumo de Web Services 13
Distribución de un Web Services Estos pueden ser distribuidos de dos formas: De manera manual puede ser de dos formas: Utilizando la opción del menú en Project- copiar proyecto, esta opción crea un directorio virtual en el IIS de manera automática, los pasos para utilizar esta opción son: o En el menú Project dar clic en Copy Project. o Seleccione la carpeta del proyecto de destino. o Seleccione el método de acceso web. o Seleccione los archivos a copiar. o De clic en OK. La otra es por medio de un ftp o dispositivo físico copiando los archivos necesarios y depositándolos en el servidor de aplicaciones, de esta forma el IIS debe ser configurado; esto es, crear el directorio virtual para el Web Service. Los Archivos necesarios para distribuir los Web Services son: Archivos Web Services.sln,.vbproj,.csproj, vsdisco.resx.vb,.cs.xsd Folders de referencia y archivos Web Carpeta bin y dll s.asmx Web.config Global.asax.xml Necesario No necesario Ventajas de la distribución manual copiando archivos: Fácil de distribuir: los archivos y otros recursos pueden simplemente copiarse al servidor web Fácil de actualizar: Usted puedes actualizar los archivos en el servidor web simplemente copiando los archivos actualizados a este servidor. Introducción a la creación, distribución, registro y consumo de Web Services 14
La distribuir manualmente es recomendada si: Si el Web Service es probado antes de distribuirlo. Si el Web service es relativamente simple. Utilizando un Instalador de archivos de Windows. Cuando distribuimos Web services, especialmente Web service mas complejos, usted puede utilizar la opción de Visual Studio.NET llamada Web Setup Project. Este crea un instalador de archivos (.msi) para el Web services. Aunque usted puede distribuir su Web service con los archivos necesarios a la localización requerida, utilizando el instalador la distribución es más fácil y este no es igual a ningún otro instalador. Hay muchas cuestiones del instalador que son asociadas con un web services complejo Los servicios web incluyen varios rasgos como: Componentes compartidos como el global assemblies. Componentes Legacy Component Object Model (COM). IIS, incluyendo ajustes de seguridad. Aplicaciones como colas de mensajes, eventos logs y contadores de performance Los pasos para distribuir una aplicación web usando el Web Setup Project son: Agregar una nueva solución y agregar un nuevo proyecto Configurar el Web Setup Project: incluir las especificaciones para el web service como el nombre del directorio virtual y los archivos necesarios para su distribución. Compilar el Web Setup proyect: para crea el Instalador del proyecto vaya a la opción del menú Build y de un clic en Build nombre del proyecto(ejemplo: BuildWebServicesPro1) Introducción a la creación, distribución, registro y consumo de Web Services 15
Registro en UDDI UDDI permite buscar negocios de los que desee obtener servicios Web. Si conoce con quién quiere realizar negocios pero desconoce los servicios que ofrece, permite examinar una recopilación de los servicios XML Web Services ofrecidos en un servidor determinado para buscar los que satisfagan sus necesidades. Para poder registrar un servicio es UDDI es necesario conocer los concepto que se proveen en la Fig. 7. Provider: Information about the entity who offers a service 0 n Service: Descriptive information about a particular family of technical offerings 0 n tmodel: Descriptions of specifications for services. Bindings contains references to tmodels. These references declare the interface specifications for a service. 0 n Binding: Technical information about a service entry point Fig. 7 Relaciones de las entidades de UDDI. Providers Los entidad Provider es la de mas alto nivel y como tal representa la entidad padre. Un provider puede ser un negocio, una organización, o un grupo conceptual que ofrece servicios. Por ejemplo, un negocio, una unidad de negocio, un departamento de una organización, una persona, computadora o aplicación. Para definir los providers dentro UDDI es necesarios considerar lo siguiente: Los providers son un tipo de entidad que puede asociarse a con los contactos. Cada provider debe ligar por lo menos una persona responsable. Los providers pueden crear relaciones con otros providers. Por ejemplo, un equipo puede tener un hijo a un departamento como hijo. Los providers lógicamente contiene servicios. Si una definición de un provider no contiene servicios, es probable que no se haya definido apropiadamente. Los providers deben de elegir el como se construirá el nombre para que sea entendido por todas las organizaciones. El nombre deberá de ser intuitivo. Provider names can be established in multiple languages. Services Cuando un provider ha sido definido, el siguiente paso es definir los servicios asociados al provider. Introducción a la creación, distribución, registro y consumo de Web Services 16
Un servicio en UDDI es la entidad que describe y provee acceso a la función compartida con otros usuarios. Los servicios pueden desarrollar cualquier función a través de la red, ordenado por una simple llamada a un complejo proceso de negocios. Los cuando se definen servicios los siguientes puntos deben ser considerados: Los servicios son una entidad lógica. Considere un servicio como una colección de bindings (ligas). Los servicios lógicamente contienen bindings (ligas). Si un servicio no contiene bindings, probablemente no este definido correctamente. La no es necesario que la información técnica se proporcione en el nivel de servicios. Sin embargo, un servicio puede ser complementado con metadatos que lo describan. Los servicios deben de elegir el como se construirá el nombre para que sea entendido por todas las organizaciones. El nombre deberá de ser intuitivo. Los servicios se puede establecer en multiples lenguajes. Los servicios no contiene contactos. Toda la información de los contactos para los servicios es derivada lógicamente del provider padre. Si un servicio tiene diferente contacto para este provider, considere la creación de un nuevo provider para el servicio. Bindings A diferencia de los servicios, los bindings no son lógicos, si no físicos, en ellos esta contenido el punto de acceso a los Web service u otra información que sirva como interfaces para implementar el punto de acceso. Los puntos a considerar cuando se define los bindings son: tmodel El punto de acceso es la información más importante en binding. En el caso de que un Web service binding, contenga como punto de acceso un URL con esto el Web service podrá ser invocado por el cliente. En un caso distinto, el punto de acceso también puede ser un número de teléfono o una dirección de e-mail. Auscencia de los nombres de categoria en los bindings. Como resultados de esto, no podran ser descubierto por la realción con la categoría. La entidad tmodel representa los archivos WSDL, que define cada una de las interfaces que pueden ser usados por uno o más servicios, también puede apunta a XML Schema Data types (XSD), XML, y otros documentos localizados en la red. Introducción a la creación, distribución, registro y consumo de Web Services 17
Consumo de un Web Service Los pasos para poder consumir un Web Service son los siguientes: Creación de un proyecto Web 1. En Visual Studio. NET presione File, New, Project o Ctrl+Shift+N 2. En la ventana de New Project, en el apartado de Project Types selecione Visual C# Project, en el apartado de Templete seleccione ASP.NET Web Application y asigne un nombre de proyecto en la caja de texto de Location. Introducción a la creación, distribución, registro y consumo de Web Services 18
Adicionar referencia web En el Soluction Explorer sobre el proyecto Web WsClient precione clic derecho y seleccione Add Web References. Introducción a la creación, distribución, registro y consumo de Web Services 19
Descubrimiento del Web Services con UDDI. 1. Para realizar el descubrimiento desde un servidor de UDDI, es necesario conocer el URL de dicho servidor. 2. Una vez identificado el servicio de UDDI, entonces podemos realizar búsquedas por servicio o bien nombre del proveedor, para este caso se buscan todos los servicios que comiencen con la letra a. Introducción a la creación, distribución, registro y consumo de Web Services 20
3. El resultado para nuestra búsqueda fue el servicio de AutenticacionLDAP, para visualizar los métodos que contiene este servicio es necesario dar clic en la definición de la interfase 4. Una vez invocada la URL del Web Services podremos ver los nombres de los métodos y sus descripciones, esta presentación es construida con el WSDL. Cambiamos el nombre de la referencia, la agregamos al proyecto pulse el botón de Add Reference. Introducción a la creación, distribución, registro y consumo de Web Services 21
5. Una ves que la referencia Web sea agredado al proyecto con el nombre de Autentica solo es necesario invocar la funcionalidad a través de código. //Crear la instancia al web services autenticación a través de la referencia agregada TallerWebServices.Autentica.LDAP aut = new TallerWebServices.Autentica.LDAP(); //Llamar al método autenticar del web services. string ds = aut.obtenercurp(txtlogin.text.tostring(),txtpassword.text.tostring()); Posteriormente si el resultado es satisfactorio se procede o no se realiza las actividades pertinentes. Introducción a la creación, distribución, registro y consumo de Web Services 22
Aspectos de Seguridad Los tres problemas de seguridad de los Web Services Seguridad comunicación de confianza. Con quien vamos a compartir nuestros servicios. Mecanismos seguros. Llamas maliciosas a nuestros servicios. Dilema de la exposición. A través de que puesto estarán expuestos los servicios (80 http, 443 SSL) Métodos de seguridad. Autenticación en el Servidor Web Configurar Web.Config. Usando el HEADER de SOAP Atributo [SoapMethod(sHeader)] Extensiones de SOAP Secure Socket Layer (SSL) Introducción a la creación, distribución, registro y consumo de Web Services 23
Introducción a la creación, distribución, registro y consumo de Web Services 24
Introducción a la creación, distribución, registro y consumo de Web Services 25
Otras plataformas para Web Services. Servidores de aplicaciones para servicios Web: Axis el servidor Jakarta_Tomcat (de Apache) http://ws.apache.org/axis/ http://tomcat.apache.org/ ColdFusion de Macromedia http://www.adobe.com/devnet/coldfusion/webservices.html Java Web Services Development Pack (JWSDP) de Sun Microsystems (basado en Jakarta Tomcat) http://java.sun.com/webservices/jwsdp/ JOnAS (parte de ObjectWeb una iniciativa de código abierto) http://jonas.objectweb.org/ Microsoft.NET http://msdn.microsoft.com/webservices/ Novell extend (basado en la plataforma J2EE) http://www.novell.com/offices/emea/spain/news/pr03029.html WebLogic http://edocs.bea.com/wls/docs81/webserv/ WebSphere http://www-128.ibm.com/developerworks/websphere/zones/webservices/ Zope es un servidor de aplicaciones Web orientado a objetos desarrollado en el lenguaje de programación Python http://www.zope.org/resources/zsp/ Introducción a la creación, distribución, registro y consumo de Web Services 26
Referencias. W3C World Wide Web Consortium http://www.w3.org/2002/ws/ Web Services interoperability (promueve la interoperabilidad entre plataformas, sistemas operativos y lenguajes de programación) http://www.ws-i.org/ OASIS UDDI Sección descubrimiento dinámico e invocación de Web Services http://www.uddi.org/ OASIS Consorcio global que maneja los desarrollos, converge y adopta estándares de e-business sin intenciones de lucro. http://www.oasis-open.org/home/index.php Microsoft UDDI Services http://www.microsoft.com/windowsserver2003/technologies/idm/uddi/default.mspx Introducción a la creación, distribución, registro y consumo de Web Services 27