INSTITUTO TECNOLÓGICO SUPERIOR DE LERDO

ALUMNOS
Jennifer Stephania Arzola De la Rosa
Jesús López Maldonado

NUMEROS DE CONTROL:
15231834
15231833

MATERIA:
Programación en Ambiente Cliente Servidor

NOMBRE DEL PROYECTO:

“Servicios WEB XML y 3 Tecnologías”

ASESOR:
Ing. Jesús Salas Marín

30/10/2018
Tabla de contenido
Servicios Web XML ....................................................................................................................... 2
SOAP (Simple Object Access Protocol) ........................................................................................ 3
WSDL (Web Services Description Language) ............................................................................... 5
UDDI (Universal Description, Discovery, and Integration) .......................................................... 7
Conclusiones ................................................................................................................................. 8

Servicios Web XML

Los servicios Web XML son bloques de código ejecutable expuestos a través de protocolos
estándar para su uso en la Web. El bloque de código que compone un servicio Web XML
parece más a un programa de consola sin interfaz; se trata de una clase pública que define,
principalmente, métodos. Estos son llamados métodos de servicio Web XML, mismos que
podrán ser invocados por aquellos programas que consuman el servicio.
Los servicios Web XML permiten el manejo distribuido de componentes, estos permiten tomar
ventaja de la infraestructura de Internet para la distribución de funcionalidad y paquetes de
datos.

Las principales características de los servicios Web XML son:

 Están basados en protocolos estándar para la Web. Los servicios Web XML realizan las
peticiones y proporcionan las respuestas utilizando protocolos estándar de la Web,
como los son HTTP (Hyper Text Transfer Protocol), XML (Extensible Markup Language),
y SOAP (Simple Object Access Protocol), toda plataforma que maneje dichos protocolos,
podrá aprovechar la funcionalidad de los servicios Web XML.
 Comunicación de aplicación a aplicación basada en Internet. Al utilizar un servicio Web
XML no se tienen una interfaz de usuario visible; realmente se trata de un componente
que puede ser consumido de manera programática de aplicación a aplicación. Los
servicios Web XML proporcionan una interfaz estándar para la recepción de peticiones
y envío de respuesta, denominada contrato, dicho contrato pone a disposición de los
usuarios la información requerida por el componente, describe los comportamientos
del mismo, y relaciona los datos de entrada con la salida del componete.
 Independencia del lenguaje. Los servicios Web XML pueden ser consumidos desde
programas escritos en cualquier lenguaje .NET, por lo cual no es necesario aprender un
lenguaje determinado para poder tener acceso a su funcionalidad.
 Independencia de la plataforma. Independientemente de la plataforma que dispongan
los clientes de una aplicación, el contrato se encarga de hacer la petición en un formato
estándar, y de recibir la respuesta correspondiente.
 Arquitectura libre del manejo de estados (stateless architecture). Los servicios Web XML
no manejan estados de objetos; cada respuesta brindada por un servicio Web XML es
una nueva instancia de un objeto, con su estado particular. Lo que una petición realiza
no impacta lo realizado por otras peticiones.
 Comunicación síncrona y asíncrona. El requerimiento de ejecución de un método de
servicio Web XML, y el requerimiento de la respuesta, son independientes. La aplicación
que consume el servicio Web XML, y el servicio Web XML mismo, pueden operar con
mayor disponibilidad, ya que liberan recursos mientras se está en tiempo de espera.
Los principales usos que tienen los servicios Web XML son los siguientes:

 Cuando se requiere compartir funcionalidad libre de interfaz de usuario. Los servicios

Web son útiles en cuando se desea consumir la funcionalidad de un componente, sin la
intermediación de una interfaz de usuario. Ejemplos de esto es el consumo de servicios
que proporcionan información, como tipos de cambio, estado del clima, precios de
productos, disponibilidad de lugares en eventos, sin tener que responder a alguna
interfaz de usuario.
 Cuando se quiere comercializar un servicio de uso de software, y no un producto de
software. En el futuro, no se venderá software, sino la funcionalidad que el software
brinda estará disponible como servicio en la Web, si requerimos de un procesador de
palabras, nos enlazaremos a un procesador de palabras en línea, y pagaremos sólo por
el tiempo que utilizamos dicho procesador.
 Cuando el equipo cliente y servidor requieren compartir funcionalidad en Internet, pero
difieren en su plataforma operativa.

SOAP (Simple Object Access Protocol)

SOAP define un protocolo que da soporte a la interacción (datos + funcionalidad) entre
aplicaciones en entornos distribuidos y heterogéneos, es interoperable es decir neutral a
plataforma y lenguajes de programación, independiente del hardware y protocolos. Funciona
sobre la infraestructura existente en Internet. SOAP define cómo organizar información usando
XML de forma estructurada para intercambiarla entre distintos sistemas.

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 Call), 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 toma 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.

SOAP intercambia información mediante mensajes. Los mensajes se utilizan como envoltorios
que la aplicación utiliza para guardar la información que quiere enviar.

Cada mensaje contiene dos partes:

 Una cabecera (opcional). Que contiene información del mensaje, por ejemplo, la
cabecera puede contener la fecha en que el mensaje es enviado, o información de
 autenticación, cuando está presente la cabecera siempre debe estar en la parte de
arriba.
 Un cuerpo (obligatorio). Contiene los datos del mensaje.

La cabecera y el cuerpo pueden tener múltiples subpartes en forma de bloques de la cabecera y

bloques del cuerpo.

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 que es invocado, y los parámetros
que son pasados al método Web en un formato XML. Cuando el paquete SOAP llega al servidor
Web en el cual reside el servicio Web, el método Web y sus parámetros son extraídos del
paquete SOAP y el método es invocado.

Este son unos ejemplos de una solicitud SOAP:

 WSDL (Web Services Description Language)

Un WSDL es la especificación estándar de funcionamiento y datos de un servicio Web XML.

WSDL se maneja a través de un contrato, conocido también como Service Description, que es
un documento XML que contiene información relacionada al servicio Web XML y los paquetes
de datos que el servicio Web XML maneja, tanto de entrada como de salida.

De cierta forma WSDL específica los datos requeridos por el servicio, su comportamiento, y sus
datos de retorno; actúa como un contrato de intercambio de paquetes de datos entre el
consumidor de servicios Web XML y el servicio Web XML.

WSDL también contiene las referencias a las direcciones asociadas con el servicio Web XML,
mismas que dependerán del protocolo utilizado para consumir el servicio.

El documento WSDL es un documento XML; el elemento raíz es llamado definitions, y contiene

cinco nodos hijos que muestran la forma en que está definido el servicio Web XML. Dichos
elementos hijo son los siguientes:

 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 Web
service.

Para generar un WSDL, se utiliza la utilería wsdl.exe con las siguientes sintaxis:
Wsdl /l: Lenguaje /n:NombreNamespace URL_Servicio

Donde Lenguaje es el lenguaje que se desea utilizar, NombreNamespace es el nombre del

espacio de nombres a generarse en el WSDL, y URL_Servicio es el URL del servicio Web XML a
partir del cual se generará WSDL.

La ejecución de wsdl.exe sobre el servicio Web XML producirá un programa generado en el

lenguaje especificado, que deberá ser compilado como librería para su uso programático.
Dicho programa contendrá la misma funcionalidad del servicio Web XML, con todas las
especificaciones descriptivas.
Este es un ejemplo de un documento WSDL donde <message> específica el mensaje
individual XML que son transformados entre computadoras, en este caso “getWeatherRequest”
and “getWeatherResponse”, y <service> específica que el servicio está disponible vía SOAP.
 UDDI (Universal Description, Discovery, and Integration)

Uno de los puntos más importantes de un servicio es su publicidad, pensando en ello, 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 del 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: es el elemento “top-level”, describe un negocio o una entidad que ha

registrado un servicio en UDDI. Ejemplos: Departamento de Contabilidad, Servidor de
Aplicaciones Corporativo. Este elemento soporta información estándar tal como
nombre, descripción, e información de contacto, así como información de metadatos
(por ejemplo: identificadores y categorías).
 businessService: describe un Servicio Web que ha sido expuesto por una entidad de
negocio, soporta el nombrado de un Servicio Web y lo asocia con una entidad de negocio
y con la información de binding. Soporta la asignación de categorías al Servicio Web
(industria, productos, códigos geográficos, etc.).
 bindingTemplate: describe la información técnica necesaria para enlazar con un Servicio
Web en particular. Este elemento soporta el nombrado de un Servicio Web y su
asociación con una entidad de negocio e información de binding. La información de
binding se describe como un punto de acceso que posee un atributo llamado UrlType
utilizado para especificar los siete tipos de puntos de entrada: mailto, http, Https, Ftp,
Fax, Phone, Other.
 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.).
Este diagrama muestra la relación entre las tecnologías usadas para implementar un servicio

Web

Comunicación mediante
Mensajes SOAP

Documento
Registro
UDDI WSDL

Localiza un
servicio Web

Aplicación Servicio Web

Cliente

Conclusiones
En esta investigación se conoció lo que vienen siendo los servicios Web XML, lo que entendí de
esto es que son códigos extras que se agregan, el cual dice que no contiene interfaz, es más
como un programa de consola el cual sirve o más bien contiene una clase de métodos que son
usados por los programas consumidores del servicio, todo esto con el fin de agilizar el
intercambio de paquetes de datos.
El SOAP es un protocolo que ayuda a la comunicación y a intercambiar los datos XML.
WSLD es un formato de XML que se usa en los servicios web, este con ayuda del SOAP sirven
para presentar al cliente las funciones que están disponibles dentro del servidor.
Sobre UDDI se dice que está basado en SOAP, es un protocolo que ayuda a la comunicación de
los clientes y los registros UDDI, los registros ayudan a tener información sobre los servicios
web.
 Conclusiones
Luego de realizar la investigación sobre los servicios web entendí que internet trabaja en
conjunto con protocolos, con ello podemos crear aplicaciones o paginas las cuales se pueden
comunicar con protocolos como SOAP o los que vimos anterior mente, dichas aplicaciones se
son en capas y a partir de ahí el desarrollo en capas se crea el concepto de Servicio Web.

Los componentes que vi que se utilizan para crear una aplicación de web service, inicia con http
que es el servicio web dentro de ella esta la aplicación y dentro de la misma esta por ejemplo
SOAP engine, el cual se encarga del manejo de los mensajes, y ahí dentro esta otra capa que ya
es el Web Service que es el sw o componente que realiza las operaciones.

Sobre UDDI entendí que es un catálogo de negocios de internet, y este protocolo ayuda a la
comunicación de los clientes y los registros UDDI, los registros ayudan a tener información sobre
los servicios web. Referente a WSLD entendí que es un formato de XML el cual es usador para
el mismo propósito, Servicios web y en conjunto con el SOAP funciona para mostrar al cliente
las funciones que están disponibles dentro del servidor.

Bibliografía
www.itlalaguna.edu.mx/Academico/Carreras/sistemas/prograweb/Unidad5.doc
https://developer.mozilla.org/es/docs/Servicios_Web_XML
https://programacionwebisc.wordpress.com/5-1-vision-general-de-servicios-web-xml/