TECNOLÓGICO NACIONAL DE MÉXICO

Instituto Tecnológico de la Costa Grande

UNIDAD 4

MATERIA

PROGRAMACIÓN WEB AVANZADA

CARRERA
INGENIERÍA EN SISTEMAS COMPUTACIONALES
PLAN ISIC-2010-2024

PRESENTA

LUIS ABRAHAM ROSAS BARAJAS

ASESOR

LIC. LEONARDO SANDOVAL QUIÑONES

ZIHUATANEJO GUERRERO, MÉXICO

DIC, 2018
Índice.

UNIDAD 4 1

MATERIA 1

PROGRAMACIÓN WEB AVANZADA 1

4.1 EL CONCEPTO Y CATÁLOGO DE SERVICIOS WEB. 3

EL CONCEPTO. 3
CATÁLOGOS DE SERVICIOS WEB. 4
SERVICIOS WEB SOAP 4
SERVICIOS WEB RESTFUL 5
ALTERNATIVAS DE ESTOS SERVICIOS. 5

4.2 TECNOLOGÍAS SUBYACENTES 6

4.2.1 SIMPLE OBJECT ACCESS PROTOCOL (SOAP) 6
4.2.2 WSDL (WEB SERVICES DESCRIPTION LANGUAGE). EL LENGUAJE DE DESCRIPCIÓN 8
4.2.3 UDDI (UNIVERSAL DESCRIPTION, DISCOVERY, AND INTEGRATION). EL REPOSITORIO DE
SERVICIOS 9

4.3 PUBLICACIÓN DE UN SERVICIO WEB 10

4.3 CONSUMO DE UN SERVICIO WEB 12

REFERENCIAS: 13
4.1 El concepto y catálogo de servicios Web.

El concepto.

Los servicios Web son componentes de aplicaciones distribuidas que están

disponibles de forma externa. Se pueden utilizar para integrar aplicaciones escritas
en diferentes lenguajes y que se ejecutan en plataformas diferentes. Los servicios
Web son independientes de lenguaje y de la plataforma gracias a que los
vendedores han admitido estándares comunes de Servicios Web.

El WC3 (World Wide Web Consortium) define un servicio Web como un sistema
software diseñado para soportar interacciones máquina a máquina a través de la
red. Dicho de otro modo, los servicios Web proporcionan una forma estándar de
interoperar entre aplicaciones software que se ejecutan en diferentes plataformas.
Por lo tanto, su principal característica es obtener una gran interoperabilidad y
extensibilidad así como proporcionar información fácilmente procesable por las
máquinas gracias al uso de XML. Los servicios Web pueden combinarse con muy
bajo acoplamiento para conseguir la realización de operaciones complejas. De esta
forma, las aplicaciones que proporcionan servicios simples pueden interactuar con
otras para "entregar" servicios sofisticados añadidos.
Catálogos de servicios web.

Figura 4.1 Pila de protocolos de los Servicios Web.

Servicios Web SOAP

Los servicios Web SOAP, o servicios Web "big", utilizan mensajes XML para
intercomunicarse que siguen el estándar SOAP (Simple Object Access Protocol),
un lenguaje XML que define la arquitectura y formato de los mensajes. Dichos
sistemas normalmente contienen una descripción legible por la máquina de la
descripción de las operaciones ofrecidas por el servicio, escrita en WSDL (Web
Services Description Language), que es un lenguaje basado en XML para definir las
interfaces sintácticamente.

El formato de mensaje SOAP y el lenguaje de definición de interfaces WSDL se ha

extendido bastante, y muchas herramientas de desarrollo, por ejemplo Netbeans,
pueden reducir la complejidad de desarrollar aplicaciones de servicios Web.

El diseño de un servicio basado en SOAP debe establecer un contrato formal para

describir la interfaz que ofrece el servicio Web. WSDL puede utilizarse para describir
los detalles del contrato, que pueden incluir mensajes, operaciones, bindings, y la
localización del servicio Web. También deben tenerse en cuenta los requerimientos
no funcionales, como por ejemplo las transacciones, necesidad de mantener el
estado (addressing), seguridad y coordinación

En este módulo vamos a hablar únicamente en los Servicios Web SOAP.

Servicios Web RESTful

Los servicios Web RESTful (Representational State Transfer Web Services) son
adecuados para escenarios de integración básicos ad-hoc. Dichos servicios Web se
suelen integrar mejor con HTTP que los servicios basado en SOAP, ya que no
requieren mensajes XML o definiciones del servicio en forma de fichero WSDL

Los servicios Web REST utilizan estándares muy conocidos como HTTP, SML, URI,
MIME, y tienen una infraestructura "ligera" que permite que los servicios se
construyan utilizando herramientas de forma mínima. Gracias a ello, el desarrollo
de servicios RESTful es barato y tiene muy pocas "barreras" para su adopción.

Alternativas de estos servicios.

 Jabber, es un protocolo asíncrono de transporte (más ligero que HTTP).

 EbXML, está pensado para integración de servicios en soluciones B2B
(Business to Business).
 XML-RPC, está basado en HTTP-POST.

- En el caso de WSDL otras opciones son:

 RDF (Resource Description Framework), definido por el W3C. Es más

potente pero también más complejo que WSDL.
 DAML (DARPA Agent Markup Language), definido por la agencia de defensa
estadounidense (DARPA). Es también más potente pero más complejo que
 WSDL.
 - En el caso de UDDI existe una propuesta alternativa realizada por

Microsoft e IBM, llamada WS-Inspection Language.

4.2 Tecnologías subyacentes

Las especificaciones que se han desarrollado para implementar los servicios Web se
presentan como una pila de tecnologías donde las especificaciones superiores hacen uso
de las inferiores, como se muestra en la figura 4.2.

Figura 4.2
4.2.1 Simple Object Access Protocol (SOAP)

Para ser capaces de comunicarse entre sí, un servicio Web y una

aplicación cliente deben concordar sobre un protocolo común. SOAP es un
protocolo estándar de comunicación para intercambiar información en
un formato estructurado en un medio ambiente distribuido. La información
intercambiada entre la aplicación cliente y el servicio Web es l amado mensaje.
Los mensajes incluyen las l amadas hechas por una aplicación cliente a un método
Web y los datos retornados por el método Web al cliente. Cuando una aplicación
cliente hace una solicitud a un método Web, un paquete SOAP es creado. Este
paquete contiene el nombre del método Web invocado y los parámetros pasados
al método Web en un formato XML. Esta información es usada para invocar el
método Web con los parámetros apropiados. Cuando el paquete
SOAP llega al servidor Web en el cual reside el servicio Web, el nombre
del método Web y sus parámetros son extraídos del paquete SOAP y el método
Web apropiado es invocado.

SOAP especifica lo siguiente:

 Un formato de mensaje para una comunicación

unidireccional, describiendo cómo se empaqueta la información en
documentos XML.

 Un conjunto de convenciones para usar mensajes SOAP para implementar

el patrón de interacción RPC (Remote Procedure Cal ), definiendo cómo los
clientes pueden invocar un Procedimiento Remoto enviando un mensaje
SOAP y cómo los servicios pueden responder enviando otro mensaje al
llamador.

 Un conjunto de reglas que una entidad que procesa

mensajes SOAP debe seguir, definiendo en particular los elementos XML
que una entidad debe leer y entender, así como las acciones que deben
tomar si no entienden el contenido, estas reglas son llamadas: Reglas
de Codificación de los Datos.

 Una descripción de cómo se debe transportar un mensaje SOAP sobre

HTTP y SMTP.

Cada mensaje contiene los siguientes elementos:

  Elemento envelope, este es el elemento raíz de un documento SOAP, este
elemento contiene los elementos header y body del mensaje SOAP, este
elemento es obligatorio.

 Elemento header, este elemento es opcional y da al servidor información

extra, como autenticación y manejo de transacciones.

 Elemento body, este elemento es obligatorio que contiene datos concretos

del mensaje SOAP, este elemento contiene información tal como nombre del
método, parámetros, y los valores en la invocación del método.

 Elemento fault, este elemento es utilizado para determinar si existe

algún error en el mensaje SOAP y no desplegar mensajes de error.

4.2.2 WSDL (Web Services Description Language). El Lenguaje de

Descripción

WSDL es un lenguaje estándar basado en XML, que define como los servicios Web
XML son descritos cuando son publicados en un registro. La información del
servicio Web XML es publicada en registros como documentos WSDL. El
documento WSDL es un archivo XML que incluye el esquema de interfaz del
servicio Web XML. WSDL reconoce los métodos que son intercambiados entre
el proveedor del servicio Web XML y el consumidor del servicio Web XML. Un
documento WSDL proporciona información a los clientes de cómo acceder a los
servicios Web XML. WSDL proporciona la información usando varios elementos.
Estos elementos de un archivo WSDL incluyen lo siguiente:

 Types. Define los tipos de datos utilizados para el intercambio de

mensajes entre el consumidor y el servicio.
  Message. Describe los mensajes que serán comunicados entre el
consumidor y el servicio.
 portType. Identifica el conjunto de operaciones que realiza el servicio, y los
mensajes involucrados en dichas operaciones.
 Binding. Específica los detalles de protocolo para el intercambio de
mensajes entre las operaciones, describiendo cómo traducir contenido
abstracto a un formato estándar.
 Service. Agrupa aquellos puertos que estén relacionados, y que
implementan un servicio Web.

4.2.3 UDDI (Universal Description, Discovery, and Integration). El Repositorio

de Servicios

Uno de los puntos más importantes de un servicio es su publicidad, pensando en

el o, se ha definido un mecanismo para darles publicidad a los servicios Web
XML que las empresas desarrollan, denominado UDDI. Cuando un proveedor de
servicios Web quiere poner un servicio Web disponible para clientes de aplicación,
el proveedor describe el servicio Web usando un documento WSDL. Entonces el
proveedor registra el servicio Web en el directorio UDDI. El directorio UDDI
contiene apuntadores a el servicio Web y el documento WSDL de el servicio Web.
De esta manera las aplicaciones Cliente pueden descubrir el servicio Web usando
el directorio UDDI.

La especificación UDDI tiene dos objetivos esenciales:

(1) ser un soporte a los desarrolladores para encontrar información sobre

servicios web y poder construir clientes.
 (2) facilitar el Enlace Dinámico de Servicios Web, permitiendo consultar
referencias y acceder a servicios de interés.

La información en un registro UDDI se almacena en archivos XML con una

estructura jerárquica, Los elementos de esta estructura son:

 businessEntity: Describe la organización que ofrece el servicio (Nombre,

dirección, etc.)
 businessService: Grupo de servicios Web relacionados ofrecido por una
BusinessEntity (empresa), pero ofrecida en diferentes direcciones,
versiones, y tecnologías. Al igual que las BusinessEntity, pueden incluir
información de clasificación.
 bindingTemplate: Información técnica para utilizar el servicio, (Dirección
del servicio, Referencias documentos (tModels) describiendo la interfaz u
otras propiedades, Como dar valor a los parámetros y valores por defecto).
 tModel: (Technology Model). Estructura de Metadatos Genérica para
representar cualquier concepto o construcción (definiciones de protocolos,
ficheros WSDL, XML schemas, Espacios de Nombres, esquemas de
categorías, etc.).

4.3 Publicación de un servicio WEB

Class. Específica la clase implementada por el servicio Web XML, esta se

compLos servicios Web XML desde el punto de vista de programación, son
muy parecidos a un programa, mientras que en su consumo son más orientados
al ambiente Web. Estos servicios están constituidos por un archivo de extensión
.asmx, y este archivo debe contener lo siguiente:
1. La directiva @WebService. Esta directiva específica los atributos de servicio
Web XML. Esta directiva es el equivalente a @Page de las páginas Web. Los
atributos que utiliza esta directiva son:ila automáticamente la primera vez que se
tiene acceso al servicio Web XML, o después de que se operan cambios en él.

 CodeBehind. Específica el archivo de código fuente que contiene la clase

utilizada por el servicio Web XML.
 Language. Específica el lenguaje .NET utilizado para codificar la clase que
implementa el servicio Web XML.

La sintaxis de cómo utilizar la directiva @WebService y sus atributos es la

siguiente:

<%@ WebService Language=”C#” CodeBehind=”NombreArchivo” Class=”NombreClase” %>

La directive @WebService se deberá colocar al principio del código del servicio

Web XML.

2. Importar el espacio de nombres System.Web.Services. El espacio de nombres

System.Web.Services es el espacio de nombres que contiene las clases que
permiten crear servicios Web XML, tales como WebService y WebMethodAttribute.
La sintaxis para importar el espacio de nombres es la siguiente.

using System.Web.Services;

Después de importar el espacio de nombres, se puede escribir el código de la

clase que constituirá el servicio Web; esta clase deberá heredar la funcionalidad
de System.Web.Services.WebService.

3. Crear una clase, ya sea dentro de la página o en modo Code Behind.

Después de establecer las directivas y haber importado los espacios de
nombres, se deberá codificar una clase, que contendrá el bloque de código que
constituye el servicio Web XML. Debe ser una clase porque al consumir un
servicio Web XML programáticamente, es necesario manejar la funcionalidad en
modo objeto y éstos no son otra cosa que instancias de una clase. La clase debe
tener suficientes permisos, de preferencia ser pública, sobre todo si el servicio
Web XML podrá ser consumido desde Internet. La sintaxis que se utiliza para
declarar una clase es la siguiente:

public class NombreClase : System.Web.Services.WebService {

WebMetodos

4. Declarar como [WebMethod()] las funciones del servicio Web XML. Las
funciones incluidas en la clase constituyen el comportamiento del servicio Web
XML, en su definición, las funciones se asemejan mucho a las funciones que
conocemos en programación. Su diferencia radica en que deben ser de acceso
público, y que deben estar habilitadas para ser acreditadas por clientes remotos
a través de la Web, agregándoles el atributo WebMethod(). La sintaxis para
declarar un WebMethod es la siguiente:

[WebMethod(Description=”Descripción del método”)]

public TipoFuncion NombreFuncion(Parametros){

return ValorRetorno

4.3 Consumo de un servicio WEB

Los servicios Web XML pueden ser consumidos de dos maneras, directamente
desde un navegador o desde una aplicación de forma programática.

Las diferencias entre estas dos formas son las siguientes:

 Directamente desde el navegador. La petición se realiza vía HTTP al

servidor, este mostrará la página de hipertexto de descripción, que lista los
métodos disponibles en el servicio Web XML. En dicha página puede
seleccionar algún método disponible, interactuar con la interfaz
proporcionando datos y recibir la respuesta del servicio Web XML. La
respuesta que se recibe está en XML

 Desde una aplicación, programáticamente. Se debe establecer una

referencia hacia el servicio Web XML, dicha referencia es un objeto que es
utilizado para comunicarse con el servicio Web utilizando SOAP. La clase
que se genera es una equivalencia de la clase original del servicio Web
XML, con la diferencia de que no contiene la lógica de la aplicación, en lugar
de eso, la clase contiene la lógica de clasificación y transporte de datos. La
clase permite a la aplicación que consume el servicio Web XML disponer
de una respuesta manejada a través de SOAP, que permite manejar
objetos más complejos que HTTP. Se deberá en el programa generar
una instancia de la clase, utilizar los métodos del servicio Web XML y recibir
los datos de la aplicación.

Referencias: