unidad ii arqitectura de sistemas distribuidos
TRANSCRIPT
UNIDAD II. ARQUITECTURA DE SISTEMAS DISTRIBUIDOS.
Objetivo educacional.
Aprender un modelo arquitectónico de sistemas distribuidos, modelo cliente servidor y sus
variaciones, como la arquitectura de 3 capas. Para aplicarlos en el desarrollo de un
proyecto.
Actividades de aprendizaje.
- Explicación del modelo cliente-servidor por parte del docente.
- Investigación y exposición por parte de los alumnos, de las variaciones del modelo.
- Realización del modelado sobre un proyecto.
Investigación y exposición por parte de los alumnos, de las variaciones del modelo.
Realización del modelado sobre un proyecto.
2.1 Cliente/Servidor.
En el modelo cliente-servidor hay dos tipos de componentes:
• Clientes: hacen peticiones de servicio. Normalmente, los clientes inician la comunicación
con el servidor.
• Servidores: proveen servicios. Normalmente, los servidores esperan recibir peticiones. Una
vez han recibido una petición, la resuelven y devuelven el resultado al cliente.
El paradigma cliente-servidor se basa en la asignación de dos funcionalidades diferentes a
cada uno de los componentes que se comunican. El proceso servidor proporciona una serie
de servicios y espera la llegada de peticiones por parte de los clientes. En este modelo, el
servidor tiene un papel pasivo, dedicándose a esperar las solicitudes de los clientes, que son
los que toman el papel activo.
Este modelo, que predomina en la actualidad, permite descentralizar el procesamiento y
recursos, sobre todo, de cada uno de los servicios y de la visualización de la Interfaz Gráfica
de Usuario. Esto hace que ciertos servidores estén dedicados sólo a una aplicación
determinada y por lo tanto ejecutarla en forma eficiente.
Definición:
Sistema en donde el cliente es una máquina que solicita un determinado servicio y se
denomina Servidor a la máquina que lo proporciona. Los servicios pueden ser:
Ejecución de un determinado programa.
Acceso a un determinado banco de información.
Acceso a un dispositivo de hardware.
Categorías de Servidores:
A continuación se presenta una lista de los servidores más comunes:
Servidores de archivos.- Proporciona archivos para clientes. Si los archivos no fueran tan
grandes y los usuarios que comparten esos archivos no fueran muchos, esto sería una gran
opción de almacenamiento y procesamiento de archivos. El cliente solicita los archivos y el
servidor los ubica y se los envía.
Servidores de Base de Datos.- Son los que almacenan gran cantidad de datos
estructurados, se diferencian de los de archivos pues la información que se envía está ya
resumida en la base de datos. Ejemplo: El Cliente hace una consulta, el servidor recibe esa
consulta (SQL) y extrae sólo la información pertinente y envía esa respuesta al cliente.
Servidores de Software de Grupo.- El software de grupo es aquel, que permite organizar
el trabajo de un grupo. El servidor gestiona los datos que dan soporte a estas tareas. Por
ejemplo: almacenar las listas de correo electrónico. El Cliente puede indicarle, que se ha
terminado una tarea y el servidor se lo envía al resto del grupo.
Servidores WEB.- Son los que guardan y proporcionan páginas HTML. El cliente desde un
browser o navegador hace un llamado de una página (link) y el servidor recibe el mensaje
para después enviar la página solicitada.
Servidores de correo.- Gestiona el envío y recepción de correo de un grupo de usuarios (el
servidor no necesita ser muy potente). El servidor sólo debe utilizar un protocolo de correo.
Servidor de objetos.- Permite almacenar objetos que pueden ser activados de manera
remota. Los clientes pueden ser capaces de activar los objetos que se encuentren en el
servidor.
Servidores de impresión.- Gestionan las solicitudes de impresión de los clientes. El cliente
envía la solicitud de impresión, el servidor recibe la solicitud y la ubica en la cola de
impresión, ordena a la impresora que lleve a cabo las operaciones y luego avisa a la
computadora cliente que ya acabo su respectiva impresión.
Servidores de aplicación.- En el pasado refería a un servidor que se dedicaba a una única
aplicación. Era básicamente una aplicación a la que podían acceder los clientes. En la
actualidad refiere más a un servidor Web con capacidad de procesamiento, por lo que suele
ser a la vez servidor Web con algunas funciones de lógica de negocio.
Comunicación cliente-servidor.
Muy utilizada en entornos distribuidos (más del 90% de los sistemas distribuidos utilizan la
arquitectura cliente-servidor
Protocolo típico: petición-respuesta.
NÚCLEO
cliente
petcición
respuesta
servidor
Máquina A Máquina B
NÚCLEO
RED
Arquitecturas Cliente – Servidor.
La arquitectura cliente-servidor más simple se denomina arquitectura cliente-servidor
de dos capas.
Se organiza como un servidor (o múltiples servidores idénticos) y un conjunto de
clientes.
Como se ilustra en la Figura siguiente, las arquitecturas cliente/servidor de dos capas
pueden ser de dos tipos:
1. Modelo de cliente ligero (thin-client). todo el procesamiento de las aplicaciones y la
gestión de los datos se lleva a cabo en el servidor.
El cliente simplemente es responsable de la capa de presentación del software.
2. Modelo de cliente rico (fat-client). En este modelo, el servidor solamente es responsable
de la gestión de los datos.
El software del cliente implementa la lógica de la aplicación y las interacciones con el
usuario del sistema.
Clientes Livianos y Pesados.
Contestar las preguntas que a continuación se plantean:
1. ¿Qué entiende por Arquitectura Cliente Servidor?
2. ¿Cuáles son los elementos de una Arquitectura Cliente Servidor?
3. ¿Qué características muestra el modelo Cliente Servidor?
4. ¿Cuáles son las ventajas y desventajas del modelo Cliente Servidor?
5. ¿Qué servicios ofrece el modelo Cliente Servidor?
Libro: Introducción sistemas distribuidos.pdf Pagina 41
2.2 Capas y Niveles.
Arquitecturas por capas.
Los componentes lógicos se organizan por capas. Un componente lógico de la capa Li sólo
puede invocar operaciones en la capa de bajo Li+1. En este estilo, las invocaciones van de
las capas superiores a las capas inferiores, mientras que los resultados van de las capas
inferiores hacia las capas superiores
1. Capa de presentación: es la que ve el usuario, presenta el sistema al usuario,
le comunica la información y captura la información del usuario dando un mínimo de
proceso (realiza un filtrado previo para comprobar que no hay errores de formato).
Esta capa se comunica únicamente con la capa de negocio.
2. Capa de negocio: es donde residen los programas que se ejecutan , recibiendo
las peticiones del usuario y enviando las respuestas tras el proceso. Se denomina capa de
negocio (e incluso de lógica del negocio) pues es aquí donde se establecen todas
las reglas que deben cumplirse.
Esta capa se comunica con la capa de presentación, para recibir las solicitudes y
presentar los resultados, y con la capa de datos, para solicitar al sistema
administrador de base de datos para almacenar o recuperar datos.
3. Capa de datos: es donde residen los datos. Está formada por uno o más
sistemas administradores de bases de datos que realiza todo el almacenamiento de
datos, reciben solicitudes de almacenamiento o recuperación de información desde la
capa de negocio.
Modelo Cliente –Servidor de 2 Capas.
El problema con una aproximación cliente-servidor de dos capas es que las tres capas
lógicas —-presentación procesamiento de la aplicación y gestión de los datos— deben
asociarse con dos computadoras: el cliente y el servidor.
Aquí puede haber problemas con la escalabilidad y rendimiento si se elige el modelo de
cliente ligero, o problemas con la gestión del sistema si se usa el modelo de cliente rico.
Modelo Cliente –Servidor de 3 Capas.
Para evitar estos problemas, una aproximación alternativa es usar una arquitectura
cliente-servidor de tres capas.
Aquí, la presentación, el procesamiento de la aplicación y la gestión de los datos son
procesos lógicamente separados que se ejecutan sobre procesadores diferentes.
Ejemplo:
Un sistema bancario por Internet es un ejemplo de una arquitectura cliente-servidor de
tres capas.
La base de datos de clientes del banco (usualmente ubicada sobre una computadora
mainframe) proporciona servicios de gestión de datos; un servidor web proporciona los
servicios de aplicación tales como facilidades para transferir efectivo, generar estados
de cuenta, pagar facturas, y así sucesivamente.
La propia computadora del usuario con un navegador de Internet es el cliente.
El sistema es escalable, porque es relativamente fácil añadir nuevos servidores web, a
medida que el número de clientes crece.
El uso de una arquitectura de tres capas permite optimizar la transferencia de
información entre el servidor web y el servidor de la base de datos.
Las comunicaciones entre estos sistemas pueden usar protocolos de comunicación de
bajo nivel muy rápidos.
Para recuperar información de la base de datos se utiliza un middleware eficiente que
soporte consultas a la base de datos en SQL (Structured Query Language).
Figura de Modelo de Arquitectura Cliente – Servidor de 3 Capas (Sistema Bancario en
Internet)
A veces sirve extender el modelo cliente-servidor de tres capas a una variante
multicapa en la que se añaden al sistema servidores adicionales.
Los sistemas multicapa pueden usarse cuando las aplicaciones necesitan acceder y
usar datos de diferentes bases de datos.
Entonces, un servidor de integración se ubica entre el servidor de aplicaciones y los
servidores de la base de datos.
El servidor de integración recoge los datos distribuidos y los presenta a la aplicación
como si se obtuviesen desde una única base de datos.
Las arquitecturas cliente-servidor de tres capas y las variantes multicapa, que
distribuyen el procesamiento de la aplicación entre varios servidores, son más
escalables que las arquitecturas de dos capas.
El tráfico de la red se reduce, al contrario que con las arquitecturas de dos capas de
cliente ligero.
El procesamiento de la aplicación es la parte más volátil del sistema, y puede ser
fácilmente actualizada, porque está localizada centralmente.
El procesamiento, en algunos casos, puede distribuirse entre: la lógica de la aplicación
y los servidores de gestión de datos, lo que permite una respuesta más rápida a las
peticiones de los clientes.
CAPAS Y NIVELES EN EL SOTRWARE.
Para estudiar el Modelo de Capas o de Aplicación para diseñar programas estudiaremos
algunos fundamentos teóricos y posteriormente se plantearán escenarios de una aplicación
modelada
Independientemente del número de capas que se empleen para diseñar una aplicación, son
básicamente 3 tipos de servicios que pueden proveer estas capas:
• Servicios de usuario o presentación.
• Servicios de negocio.
• Servicios de datos.
Cuando una aplicación se diseña a una capa, estos 3 tipos de servicios se encuentran
fusionados en el código de este componente. Cuando se diseña a 2 capas, en una de las
capas se ubican uno de los tipos de servicios y en la otra capa se encuentran fusionados los
otros 2 tipos de servicios.
Las combinaciones posibles para fusionar servicios son:
• Servicios de presentación y servicios de negocio.
• Servicios de negocio y servicios de datos.
La combinación exclusiva de servicios de presentación con servicios de datos en una capa
es inválida.
Las aplicaciones diseñadas a mayor número de capas son posibles, ya que aunque estos
servicios persisten, las capas pueden comenzar a estratificarse e n subcapas y es en dónde
aparecen un mayor número de capas. Por ejemplo, si partimos de un modelo a 3 capas, y el
arquitecto de software decide que la capa de negocio se estratifique en 2 subcapas, en total
tendremos una aplicación de 4 capas. A partir de la tercera capa, podemos hablar de
modelos multicapa o n -capas.
Los servicios de usuario o presentación son los que proveen la interfaz al usuario. El usuario
puede ser una persona u otro programa o componente. Cuando es una persona los servicios
de presentación son proporcionados por una Interfaz Gráfica del Usuario (GUI –Graphic
User Interface). Cuando el usuario es un programa o componente, los servicios de
presentación son proporcionados a través de una API o interfaz programática.
Aunque la capa de presentación no debe procesar información puesto que corresponde a la
capa de “negocio”; es válido que la capa de presentación tenga código de procesamiento
para validar entrada de datos en forma básica o formatear información de salida.
Los Servicios o Reglas de Negocio de una aplicación corresponden a los algoritmos
principales de ésta. El emplear el término “Negocio” no implica que forzosamente
correspondan a algoritmos de aplicaciones administrativas; sino que, como se ha denotado,
es cualquier algoritmo principal de la aplicación. Por ejemplo, en un programa que pida
números al usuario, los ordene y los imprima en pantalla; la regla de negocio correspondiente
es el algoritmo de ordenamiento.
Es la capa responsable de administrar las transacciones de negocio, la cual generalmente es
implementada a través de la tecnología de componentes basada en objetos. El empleo del
paradigma de la orientación a objetos nos hace recurrir a un conjunto de herramientas
denominadas Monitores de Transacciones (también conocidos en inglés como TP Monitors
–Transaction Processing Monitors).
La capa de negocio tiene dentro de sus facultades el solicitar el cambio o consulta de los
datos, pero no le corresponde llevar a cabo esta tarea, lo cual será el trabajo a real izar por la
capa de datos.
Por ejemplo, en una aplicación de créditos hipotecarios, en un punto de ejecución de la
misma se requerirá que para otorgar un crédito el cliente debe ser mayor de edad, contar con
un aval, contar con una propiedad valor superior o igual a $500,000.00 y ser de nacionalidad
mexicana. Para tal efecto, la aplicación deberá realizar una serie de consultas y cálculos para
autorizar el crédito. Este tipo de algoritmos corresponden a las reglas de negocio.
- La capa de datos realiza los servicios u operaciones de manipulación de bajo nivel de base
de datos.
- Los servicios u operaciones podrán ser los de inserción, borrado, modificación y consulta en
una base datos.
- Como se comentó en la sección anterior, la capa de negocio solicita estos servicios más no
los implementa o lleva a cabo. La capa de datos si los implementa.
De esta manera, aunque la capa de negocio hace solicitudes a la capa de datos respecto a
las operaciones a realizar sobre los mismos; la capa de negocio no requiere conocer dónde
se localizan los datos, como se implementa el acceso a los mismos y los pormenores de
éste.
En el modelado a 2 capas, existen 2 formas en que las capas pueden fusionarse:
1) Capa de presentación –Capa de negocio, o
2) Capa de negocio –Capa de datos.
En el modelado a 3 capas, los servicios se distribuyen para cada uno de estos tipos de
servicios: presentación, negocio y datos.
Por ejemplo, para una aplicación diseñada a 3 capas podemos tener una aplicación cuya
capa de presentación pueda ser provista de dos formas. Una de ellas a través de la interfaz
gráfica que puede ser construida con un lenguaje de programación. La otra a través de un
navegador para Internet (browser) empleando páginas Web (construidas en forma estática o
dinámica).
La capa de negocio puede ser implementada a través tecnología de componentes. Y la capa
de datos a través de componentes de acceso a manejadores de bases de datos
Existe una discusión respecto a la implementación de la capa de datos. Algunos autores o
diseñadores consideran que el manejador de base de datos y los procedimientos
almacenados conforman la capa de datos. Otros consideran que debe existir por lo menos
una capa de objetos que administren e interactúen con el manejador de bases de datos y los
procedimientos almacenados; y todos estos elementos
La aplicación del ejemplo consiste en una interfaz gráfica que solicita al usuario su nombre y
fecha de nacimiento. A través de dos botones principales, el primero “Calcular edad” y el
segundo “Guardar”. “Calcular edad” obtendrá la fecha de sistema y calculará la diferencia en
años entre ésta y la fecha de nacimiento capturada. “Guardar” almacenará la información en
una base de datos.
2.3 Modelo Vista Controlador (MVC).
Modelo-Vista-Controlador (MVC).
Este patrón fue descrito por primera vez por Trygve Reenskaug en 1979, y la
implementación original fue realizada en Smalltalk en los laboratorios Xerox.
MVC se basa en la separación de la aplicación en tres capas principales: Modelo,
Vista y Controlador.
Se usa (alguna de sus variantes) en la gran mayoría de las interfaces de usuario.
El Modelo es el objeto que representa los datos del programa. Maneja los datos y controla
todas sus transformaciones. El Modelo no tiene conocimiento específico de los Controladores
o de las Vistas, ni siquiera contiene referencias a ellos. Es el propio sistema el que tiene
encomendada la responsabilidad de mantener enlaces entre el Modelo y sus Vistas, y
notificar a las Vistas cuando cambia el Modelo.
La Vista es el objeto que maneja la presentación visual de los datos representados por el
Modelo. Genera una representación visualdel Modelo y muestra los datos al usuario.
Interactúa con el Modelo a través deuna referencia al propio Modelo.
El Controlador es el objeto que proporciona significado a las ordenes del usuario, actuando
sobre los datos representados por el Modelo. Cuando se realiza algún cambio, entra en
acción, bien sea por cambios en la información del Modelo o por alteraciones de la Vista.
Interactúa con el Modelo a través de una referencia al propio Modelo. La siguiente figura
muestra como funciona esta Arquitectura en web.
Muchas aplicaciones utilizan un mecanismo de almacenamiento persistente (como
puede ser una base de datos) para almacenar los datos. MVC no menciona
específicamente esta capa de acceso a datos porque supone que está encapsulada
por el modelo.
El objetivo primordial del MVC es la reutilización del código ya implementado.
Esta tarea se facilita mucho si a la hora de programar tenemos la precaución de
separar el código en varias partes que sean susceptibles de ser reutilizadas sin
modificaciones.
Más de una Vista de un Modelo de Datos.
MVC es utilizado con mayor frecuencia en las aplicaciones web, donde la Vista es la
página HTML, y el Controlador es el código que reúne la data dinámica y genera el
contenido de la página.
El Modelo es representado por el contenido actual, que usualmente se encuentra
almacenado en una base de datos o en archivos XML.
Fortalezas.
Se presenta la misma información de distintas formas.
Las vistas y comportamiento de una aplicación deben reflejar las manipulaciones de
los datos de forma inmediata.
Debería ser fácil cambiar la interfaz de usuario (incluso en tiempo de ejecución).
Permitir diferentes estándares de interfaz de usuario o portarla a otros entornos no
debería afectar al código de la aplicación.
Variantes del Modelo.
- Variante en la cual no existe ninguna comunicación entre el Modelo y la Vista y esta última
recibe los datos a mostrar a través del Controlador.
Variante inicial del Patrón MVC.
- Variante en la cual se desarrolla una comunicación entre el Modelo y la Vista, donde esta
última al mostrar los datos los busca directamente en el Modelo, dada una indicación del
Controlador, disminuyendo el conjunto de responsabilidades de este último.
Variante Intermedia del Patrón MVC.
Muchas interfaces gráficas de usuario, como Swing o MFC, hacen innecesario el uso de un
controlador.
Definen su propio flujo de control y manejan los eventos internamente.
Integran, así, la vista y el controlador.
A esta variante se la suele denominar Document-View
Un controlador (controlador.java, por ejemplo) puede gestionar el clic en un botón, de tal
forma que recoge datos por medio del Modelo (model.cargar_texto(..)) y los manda a la Vista
(el applet) para su actualización (vista.mostrar_texto( )):
/****************************************************************
Responde al click en botón "abrir" La respuesta al evento es hacer que se abra en la vista
el archivo correspondiente a la referencia seleccionada en el combo box
****************************************************************/
void b_abrir_actionPerformed(ActionEvent e) {
…
String texto_archivo = model.cargar_texto( indice_ref ); // Obtener texto de archivo
/*** Si la carga de archivo es ok, lo muestro. Si no, aviso de error ****/
if (texto_archivo != null) {
vista.mostrar_texto(texto_archivo); // Mostrar texto
vista.mostrar_aviso("Carga de " + path + " completada.");
}
else
vista.mostrar_aviso("Error en la carga de " + path);
}
2.4 Orientadas a Servicios (SOA). Service Oriented Architecture.
2.4.1 Introducción.
SOA.
–Service Oriented Architecture.
• Arquitectura Orientada a Servicios.
–OASIS la define como:
• “Paradigma para organizar y utilizar capacidades distribuidas que pueden estar bajo el
control de varios propietarios (dominios). Provee medios uniformes para ofrecer, descubrir,
interactuar y utilizar capacidades para producir los efectos deseados consistentes con
precondiciones y expectativas medibles”
Fundamentos.
– La lógica necesaria para resolver un problema se gestiona/construye mejor si se separa en
trozos más pequeños relacionados entre si.
• Se pueden ver como servicios:
–Este es un concepto “clásico” en el desarrollo de software.
–De hecho es un concepto que se puede ver en el desarrollo de las sociedades.
– Las sociedades.
• tienen diversas necesidades
• surgen negocios/empresas dedicadas a cubrir cada una de esas necesidades =>
especialización
– Alimentos
– Servicios
– etc.
• Los procesos globales requieren de varios de estos servicios. (Ej: comprar un piso)
– Buscas el piso en una agencia
– Sacas el dinero del banco
– Etc.
Encapsulamiento de la lógica del negocio.
– Los servicios encapsulan lógica del negocio.
– El “tamaño” y el alcance de la lógica representada por cada servicio puede variar.
¿Cómo se relacionan los servicios?
¿Cómo se comunican los servicios?
2.4.2 Evolución de SOA.
Del XML a SOA.
SOA es el producto de una evolución.
Deben su origen al nacimiento del XML. (Padre de múltiples tecnologías).
– XML.
• Sistema de marcado.
• Derivación del SGML.
• Permite integrar tanto contenido como estructura de los mismos.
– RPC
• La invocación a procesos remotos ha resultado muy útil.
• Con el surgimiento de XML se vio lo interesante que podría empaquetar las llamadas
a RPC mediante XML.
• En el año 2000 el W3C recibió una posible especificación que unificaba/reemplazaba
las comunicaciones propietarias de los RPC con XML.
– SERVICIOS WEB.
• Las empresas recibieron esta propuesta con las manos abiertas.
• Permitía una comunicación “puramente web”.
• Por eso se llamaron “Web Services”.
• Se centraron en la especificación de la interfaz pública, la parte más importante, con
el WSDL(Web Service Description Language).
– SOA.
• Las empresas vieron que los servicios web podían formar parte de una plataforma
arquitectónica distinta.
2.4.3 Web Services.
– Es un sistema software diseñado para soportar interacciones entre máquinas en una red.
– Frecuentemente son APIs web que pueden ser accedidas vía una red (Internet).
– Normalmente se refieren a clientes que se comunican vía XML mediante el estándar SOAP
Arquitectura.
– Las especificaciones de un servicio web son modulares. Incluyen:
• Protocolo de comunicación.
• Lenguaje de descripción de servicios.
• Protocolo de publicación y descubrimiento de metadatos.
– Normalmente.
• SOAP
• WSDL
• UDDI
Utilización.
– Los servicios web pueden utilizarse de varias maneras:
• Tipo RPC (XML-RPC).
• Tipo SOA.
• Tipo REST(Representational State Transfer).
o Basan su interfaz en un conjunto de operaciones estándar (GET, PUT
DELETE).
o Manejan un estado intrínseco.
2.4.4 Service Oriented Architecture.
¿Qué es?
Es una arquitectura software que define la utilización de servicios para dar soporte a
los requerimientos de software del usuario.
Los nodos de la red hacen disponibles sus recursos a otros como servicios
independientes a los que tienen acceso de unmodo estandar.
o Normalmente se utilizan servicios web (con SOAPy WSDL).
o Pero se puede implementar SOA con cualquier tecnología orientada a servicios.
Al contrario de la orientación a objetos, las SOAs están formadas por servicios.
o Poco acoplados.
o Altamente interoperables.
Para comunicarse utilizan una definición formal independiente de la plataforma y del
lenguaje (p.e. SOAP).
La definición del interfaz (WSDL) encapsula las particularidades de una implementación,
lo cuál la hace independiente del fabricante, lenguaje o tecnología.
Ventajas.
Permite disponer de componentes muy reusables.
Total independencia de la plataforma/lenguaje/etc.
No está asociado a ningún protocolo de transporte o infraestructura de objeto
distribuido.
Aprovecha estándares (XML) bien conocidos.
Permite la interoperabilidad entre casi cualquier entorno.
Inconvenientes.
El XMLes pesado y lento de parsear
Tecnología todavía “naciendo”, problemas de seguridad, etc.
Principios SOA.
Principios generales:
• Reutilización.
• Granularidad.
• Modularidad.
• Interoperabilidad.
• Conformidad a los estándares.
• Identificación y categorización de servicios.
Principios de Arquitectura:
• Encapsulación de servicios.
• Minimización de acoplamiento entre servicios.
• Contrato de servicios.
• Abstracción de servicios.
• Reutilización de servicios.
• Composición de servicios.
• Autonomía de servicios.
• Optimización de servicios.
• Descubrimiento de servicios.
SOA por partes.
– Definición de los servicios: WSDL
– Mensajes entre servicios: SOAP
– Descubrimiento: UDDI
2.4.5 WSDL (Web Services Description Language).
El mecanismo de intercambio está documentado en un WSD (WS Description). WSD es una
especificación procesable por la máquina de la interfaz del web service escrita en WSDL.
Este define el formato de los mensajes, tipo de datos, protocolos de transporte que deberían
ser usados entre el cliente y proveedor.
Es un lenguaje basado en XML para describir el comportamiento de un servicio web (su
API).
Contiene las operaciones y los tipos de datos necesarios para definir dichas
operaciones.
Todo servicio web debe proveer su wsdl para que otros puedan invocarlo.
2.4.6 SOAP (Simple Object Access Protocol).
Es el protocolo que define el intercambio de información en un entorno distribuido y
descentralizado. Es un protocolo basado en XML que consiste en 3 partes:
o Un sobre que define un framework para describir qué hay en el mensaje y cómo
procesarlo.
o Un conjunto de reglas para expresar instancias de tipo de datos definidos en nuestra
aplicación.
o Una convención para representar llamadas en remoto y respuestas.
(Service Oriented Architecture Protocol).
Protocolo para el intercambio de mensajes basados en XML(normalmente bajo HTTP)
Permite la comunicación entre servicios web.
Ejemplo Petición.
Ejemplo Respuesta.
2.4.7 UDDI (Universal Description Discovery and Integration).
Es el protocolo para la descripción, descubrimiento e integración universal. Publica la
información de los servicios Web y permite a las aplicaciones comprobar qué web services
están disponibles.
Registro independiente de la plataforma basado en XML para registrar servicios web y
permitir el descubrimiento de los mismos.
Se compone de:
• Páginas Blancas: Dirección, contacto e identificadores conocidos.
• Páginas Amarillas: Categorización industrial basada en taxonomías estándar.
• Páginas Verdes: Información técnica sobre servicios proporcionados por empresas.
¿Para qué sirve?
Se diseñó para ser interrogado por mensajes SOAP y proporcionar acceso a los
WSDL de los servicios.
Es uno de los pilares fundamentales de SOA.