Taller de Web Services: Introducción a la creación, distribución

Transcripción

Taller de Web Services: Introducción a
la creación, distribución, registro,
consumo y presentación de resultado.
Mayo de 2007
Resumen
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
XML
XSD
SOAP
HTTP
WSDL
UDDI
Escenario de operación de los Web Services.
4
5
5
6
7
9
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.
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.
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>
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"
Declaración del
xmlns=" http://www.inegi.gob.mx/Indicadores.xsd "
elemento
xmlns:mstns=" http://www.inegi.gob.mx/Indicadores.xsd "
Indicadores
xmlns:xs="http://www.w3.org/2001/XMLSchema"
complexType1
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>
Declaración
<xs:complexType name="complexType1">
del tipo
<xs:sequence>
complejo
<xs:element name="Clave_de_serie " type="xs:string" minOccurs="0" />
complexType
<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" />
<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>
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
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.
Fig. 6 Procesamiento de los mensajes de SOAP.
WSDL
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.
7
Estructura general del XML del WSDL.
Descripción de los elementos del WSDL
<definitions>
Comienzo del documento, este tag agrupa a todos los
demás.
<types>
Se definen los tipos de datos utilizados en el Web
Service.
</types>
Fin de la definición de tipos.
<message>
Se definen los métodos y parámetros para realizar la
operación. Cada message puede consistir en una o
más partes (parámetros).
</message>
Fin de la definición de los parámetros.
<portType>
Esta sección es la más importante, ya que se definen
las operaciones que pueden ser realizadas, y los
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.
<binding>
Se definen el formato del mensaje y detalles del
protocolo para cada portType.
</binding>
Fin de la definición del formato del mensaje y detalles
del protocolo para cada PortType.
</definitions>
Fin del documento WSDL
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
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
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.
11
5. Lo siguiente es el crear el método o métodos
servicio.
que expondrán la funcionalidad del
[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
ds = new DataSet();
try
{
//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;");
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;
}
}
}
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
Necesario
No necesario
.sln, .vbproj, .csproj, vsdisco
9
.resx
9
.vb, .cs
9
.xsd
9
Folders de referencia y archivos Web
9
Carpeta bin y dll’s
9
.asmx
9
Web.config
9
Global.asax
9
.xml
9
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.
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)
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
tModel: Descriptions of
specifications for services.
0…n
Service: Descriptive information
about a particular family of
technical offerings
0…n
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.
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:
•
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.
tModel
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.
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.
18
Adicionar referencia web
En el Soluction Explorer sobre el proyecto Web WsClient precione clic derecho y seleccione
Add Web References.
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”.
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.
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.
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)
23
24
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/
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
27

Taller de Web Services: Introducción a la creación, distribución

Transcripción

Documentos relacionados

Language Access Rights: Montana Legal Services Association

We can assist you!