UNIDAD II. ARQUITECTURA DE SISTEMAS DISTRIBUIDOS.

Objetivo educacional.
Aprender un modelo arquitectnico 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.
- Explicacin del modelo cliente-servidor por parte del docente.
- Investigacin y exposicin por parte de los alumnos, de las variaciones del modelo.
- Realizacin del modelado sobre un proyecto.

Investigacin y exposicin por parte de los alumnos, de las variaciones del modelo.
Realizacin 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 comunicacin
con el servidor.

Servidores: proveen servicios. Normalmente, los servidores esperan recibir peticiones. Una
vez han recibido una peticin, la resuelven y devuelven el resultado al cliente.

El paradigma cliente-servidor se basa en la asignacin 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, dedicndose 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 visualizacin de la Interfaz Grfica
de Usuario. Esto hace que ciertos servidores estn dedicados slo a una aplicacin
determinada y por lo tanto ejecutarla en forma eficiente.

Definicin:
Sistema en donde el cliente es una mquina que solicita un determinado servicio y se
denomina Servidor a la mquina que lo proporciona. Los servicios pueden ser:
Ejecucin de un determinado programa.
Acceso a un determinado banco de informacin.
Acceso a un dispositivo de hardware.






Categoras de Servidores:
A continuacin se presenta una lista de los servidores ms 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 sera una gran
opcin de almacenamiento y procesamiento de archivos. El cliente solicita los archivos y el
servidor los ubica y se los enva.

Servidores de Base de Datos.- Son los que almacenan gran cantidad de datos
estructurados, se diferencian de los de archivos pues la informacin que se enva est ya
resumida en la base de datos. Ejemplo: El Cliente hace una consulta, el servidor recibe esa
consulta (SQL) y extrae slo la informacin pertinente y enva 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 electrnico. El Cliente puede indicarle, que se ha
terminado una tarea y el servidor se lo enva al resto del grupo.

Servidores WEB.- Son los que guardan y proporcionan pginas HTML. El cliente desde un
browser o navegador hace un llamado de una pgina (link) y el servidor recibe el mensaje
para despus enviar la pgina solicitada.

Servidores de correo.- Gestiona el envo y recepcin de correo de un grupo de usuarios (el
servidor no necesita ser muy potente). El servidor slo 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 impresin.- Gestionan las solicitudes de impresin de los clientes. El cliente
enva la solicitud de impresin, el servidor recibe la solicitud y la ubica en la cola de
impresin, ordena a la impresora que lleve a cabo las operaciones y luego avisa a la
computadora cliente que ya acabo su respectiva impresin.

Servidores de aplicacin.- En el pasado refera a un servidor que se dedicaba a una nica
aplicacin. Era bsicamente una aplicacin a la que podan acceder los clientes. En la
actualidad refiere ms a un servidor Web con capacidad de procesamiento, por lo que suele
ser a la vez servidor Web con algunas funciones de lgica de negocio.



Comunicacin cliente-servidor.

Muy utilizada en entornos distribuidos (ms del 90% de los sistemas distribuidos utilizan la
arquitectura cliente-servidor


Protocolo tpico: peticin-respuesta.





NCLEO
cliente
petcicin
respuesta
servidor
Mquina A Mquina B
NCLEO
RED
Arquitecturas Cliente Servidor.

La arquitectura cliente-servidor ms simple se denomina arquitectura cliente-servidor
de dos capas.
Se organiza como un servidor (o mltiples servidores idnticos) 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
gestin de los datos se lleva a cabo en el servidor.

El cliente simplemente es responsable de la capa de presentacin del software.

2. Modelo de cliente rico (fat-client). En este modelo, el servidor solamente es responsable
de la gestin de los datos.

El software del cliente implementa la lgica de la aplicacin y las interacciones con el
usuario del sistema.

Clientes Livianos y Pesados.

Contestar las preguntas que a continuacin se plantean:
1. Qu entiende por Arquitectura Cliente Servidor?
2. Cules son los elementos de una Arquitectura Cliente Servidor?
3. Qu caractersticas muestra el modelo Cliente Servidor?
4. Cules son las ventajas y desventajas del modelo Cliente Servidor?
5. Qu servicios ofrece el modelo Cliente Servidor?
Libro: Introduccin sistemas distribuidos.pdf Pagina 41




















2.2 Capas y Niveles.

Arquitecturas por capas.

Los componentes lgicos se organizan por capas. Un componente lgico de la capa L
i
slo
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 presentacin: es la que ve el usuario, presenta el sistema al usuario,
le comunica la informacin y captura la informacin del usuario dando un mnimo 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 lgica del negocio) pues es aqu donde se establecen todas
las reglas que deben cumplirse.
Esta capa se comunica con la capa de presentacin, 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 ms
sistemas administradores de bases de datos que realiza todo el almacenamiento de
datos, reciben solicitudes de almacenamiento o recuperacin de informacin desde la
capa de negocio.


Modelo Cliente Servidor de 2 Capas.
El problema con una aproximacin cliente-servidor de dos capas es que las tres capas
lgicas -presentacin procesamiento de la aplicacin y gestin 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 gestin del sistema si se usa el modelo de cliente rico.


Modelo Cliente Servidor de 3 Capas.

Para evitar estos problemas, una aproximacin alternativa es usar una arquitectura
cliente-servidor de tres capas.

Aqu, la presentacin, el procesamiento de la aplicacin y la gestin de los datos son
procesos lgicamente 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 gestin de datos; un servidor web proporciona los
servicios de aplicacin 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 fcil aadir nuevos servidores web, a
medida que el nmero de clientes crece.
El uso de una arquitectura de tres capas permite optimizar la transferencia de
informacin entre el servidor web y el servidor de la base de datos.
Las comunicaciones entre estos sistemas pueden usar protocolos de comunicacin de
bajo nivel muy rpidos.
Para recuperar informacin 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 aaden 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 integracin se ubica entre el servidor de aplicaciones y los
servidores de la base de datos.
El servidor de integracin recoge los datos distribuidos y los presenta a la aplicacin
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 aplicacin entre varios servidores, son ms
escalables que las arquitecturas de dos capas.
El trfico de la red se reduce, al contrario que con las arquitecturas de dos capas de
cliente ligero.
El procesamiento de la aplicacin es la parte ms voltil del sistema, y puede ser
fcilmente actualizada, porque est localizada centralmente.
El procesamiento, en algunos casos, puede distribuirse entre: la lgica de la aplicacin
y los servidores de gestin de datos, lo que permite una respuesta ms rpida a las
peticiones de los clientes.













CAPAS Y NIVELES EN EL SOTRWARE.

Para estudiar el Modelo de Capas o de Aplicacin para disear programas estudiaremos
algunos fundamentos tericos y posteriormente se plantearn escenarios de una aplicacin
modelada

Independientemente del nmero de capas que se empleen para disear una aplicacin, son
bsicamente 3 tipos de servicios que pueden proveer estas capas:

Servicios de usuario o presentacin.
Servicios de negocio.
Servicios de datos.

Cuando una aplicacin se disea a una capa, estos 3 tipos de servicios se encuentran
fusionados en el cdigo de este componente. Cuando se disea 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 presentacin y servicios de negocio.
Servicios de negocio y servicios de datos.

La combinacin exclusiva de servicios de presentacin con servicios de datos en una capa
es invlida.

Las aplicaciones diseadas a mayor nmero de capas son posibles, ya que aunque estos
servicios persisten, las capas pueden comenzar a estratificarse e n subcapas y es en dnde
aparecen un mayor nmero 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 aplicacin de 4 capas. A partir de la tercera capa, podemos hablar de
modelos multicapa o n -capas.


Los servicios de usuario o presentacin 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 presentacin son proporcionados por una Interfaz Grfica del Usuario (GUI Graphic
User Interface). Cuando el usuario es un programa o componente, los servicios de
presentacin son proporcionados a travs de una API o interfaz programtica.

Aunque la capa de presentacin no debe procesar informacin puesto que corresponde a la
capa de negocio; es vlido que la capa de presentacin tenga cdigo de procesamiento
para validar entrada de datos en forma bsica o formatear informacin de salida.



Los Servicios o Reglas de Negocio de una aplicacin corresponden a los algoritmos
principales de sta. El emplear el trmino Negocio no implica que forzosamente
correspondan a algoritmos de aplicaciones administrativas; sino que, como se ha denotado,
es cualquier algoritmo principal de la aplicacin. Por ejemplo, en un programa que pida
nmeros 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 travs de la tecnologa de componentes basada en objetos. El empleo del
paradigma de la orientacin a objetos nos hace recurrir a un conjunto de herramientas
denominadas Monitores de Transacciones (tambin conocidos en ingls 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 aplicacin de crditos hipotecarios, en un punto de ejecucin de la
misma se requerir que para otorgar un crdito 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 aplicacin deber realizar una serie de consultas y clculos para
autorizar el crdito. Este tipo de algoritmos corresponden a las reglas de negocio.


- La capa de datos realiza los servicios u operaciones de manipulacin de bajo nivel de base
de datos.
- Los servicios u operaciones podrn ser los de insercin, borrado, modificacin y consulta en
una base datos.
- Como se coment en la seccin anterior, la capa de negocio solicita estos servicios ms 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 dnde
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 presentacin 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: presentacin, negocio y datos.

Por ejemplo, para una aplicacin diseada a 3 capas podemos tener una aplicacin cuya
capa de presentacin pueda ser provista de dos formas. Una de ellas a travs de la interfaz
grfica que puede ser construida con un lenguaje de programacin. La otra a travs de un
navegador para Internet (browser) empleando pginas Web (construidas en forma esttica o
dinmica).

La capa de negocio puede ser implementada a travs tecnologa de componentes. Y la capa
de datos a travs de componentes de acceso a manejadores de bases de datos

Existe una discusin respecto a la implementacin de la capa de datos. Algunos autores o
diseadores 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 interacten con el manejador de bases de datos y los
procedimientos almacenados; y todos estos elementos





La aplicacin del ejemplo consiste en una interfaz grfica que solicita al usuario su nombre y
fecha de nacimiento. A travs de dos botones principales, el primero Calcular edad y el
segundo Guardar. Calcular edad obtendr la fecha de sistema y calcular la diferencia en
aos entre sta y la fecha de nacimiento capturada. Guardar almacenar la informacin en
una base de datos.
































2.3 Modelo Vista Controlador (MVC).

Modelo-Vista-Controlador (MVC).
Este patrn fue descrito por primera vez por Trygve Reenskaug en 1979, y la
implementacin original fue realizada en Smalltalk en los laboratorios Xerox.
MVC se basa en la separacin de la aplicacin en tres capas principales: Modelo,
Vista y Controlador.
Se usa (alguna de sus variantes) en la gran mayora 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 especfico 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 presentacin visual de los datos representados por el
Modelo. Genera una representacin visualdel Modelo y muestra los datos al usuario.
Interacta con el Modelo a travs 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 algn cambio, entra en
accin, bien sea por cambios en la informacin del Modelo o por alteraciones de la Vista.
Interacta con el Modelo a travs 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
especficamente esta capa de acceso a datos porque supone que est encapsulada
por el modelo.

El objetivo primordial del MVC es la reutilizacin del cdigo ya implementado.

Esta tarea se facilita mucho si a la hora de programar tenemos la precaucin de
separar el cdigo en varias partes que sean susceptibles de ser reutilizadas sin
modificaciones.






Ms de una Vista de un Modelo de Datos.



MVC es utilizado con mayor frecuencia en las aplicaciones web, donde la Vista es la
pgina HTML, y el Controlador es el cdigo que rene la data dinmica y genera el
contenido de la pgina.
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 informacin de distintas formas.
Las vistas y comportamiento de una aplicacin deben reflejar las manipulaciones de
los datos de forma inmediata.
Debera ser fcil cambiar la interfaz de usuario (incluso en tiempo de ejecucin).
Permitir diferentes estndares de interfaz de usuario o portarla a otros entornos no
debera afectar al cdigo de la aplicacin.




Variantes del Modelo.

- Variante en la cual no existe ninguna comunicacin entre el Modelo y la Vista y esta ltima
recibe los datos a mostrar a travs del Controlador.


Variante inicial del Patrn MVC.

- Variante en la cual se desarrolla una comunicacin entre el Modelo y la Vista, donde esta
ltima al mostrar los datos los busca directamente en el Modelo, dada una indicacin del
Controlador, disminuyendo el conjunto de responsabilidades de este ltimo.


Variante Intermedia del Patrn MVC.

Muchas interfaces grficas 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 botn, de tal
forma que recoge datos por medio del Modelo (model.cargar_texto(..)) y los manda a la Vista
(el applet) para su actualizacin (vista.mostrar_texto( )):
/****************************************************************
Responde al click en botn "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 Introduccin.
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 lgica necesaria para resolver un problema se gestiona/construye mejor si se separa en
trozos ms pequeos relacionados entre si.

Se pueden ver como servicios:
Este es un concepto clsico 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 =>
especializacin
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 lgica del negocio.

Los servicios encapsulan lgica del negocio.
El tamao y el alcance de la lgica representada por cada servicio puede variar.


Cmo se relacionan los servicios?



Cmo se comunican los servicios?

2.4.2 Evolucin de SOA.
Del XML a SOA.
SOA es el producto de una evolucin.
Deben su origen al nacimiento del XML. (Padre de mltiples tecnologas).

XML.
Sistema de marcado.
Derivacin del SGML.
Permite integrar tanto contenido como estructura de los mismos.

RPC
La invocacin a procesos remotos ha resultado muy til.
Con el surgimiento de XML se vio lo interesante que podra empaquetar las llamadas
a RPC mediante XML.
En el ao 2000 el W3C recibi una posible especificacin que unificaba/reemplazaba
las comunicaciones propietarias de los RPC con XML.

SERVICIOS WEB.
Las empresas recibieron esta propuesta con las manos abiertas.
Permita una comunicacin puramente web.
Por eso se llamaron Web Services.
Se centraron en la especificacin de la interfaz pblica, la parte ms importante, con
el WSDL(Web Service Description Language).

SOA.
Las empresas vieron que los servicios web podan formar parte de una plataforma
arquitectnica distinta.




2.4.3 Web Services.
Es un sistema software diseado para soportar interacciones entre mquinas en una red.
Frecuentemente son APIs web que pueden ser accedidas va una red (Internet).
Normalmente se refieren a clientes que se comunican va XML mediante el estndar SOAP

Arquitectura.
Las especificaciones de un servicio web son modulares. Incluyen:
Protocolo de comunicacin.
Lenguaje de descripcin de servicios.
Protocolo de publicacin y descubrimiento de metadatos.
Normalmente.
SOAP
WSDL
UDDI


Utilizacin.
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 estndar (GET, PUT
DELETE).
o Manejan un estado intrnseco.


2.4.4 Service Oriented Architecture.
Qu es?
Es una arquitectura software que define la utilizacin 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 tecnologa orientada a servicios.


Al contrario de la orientacin a objetos, las SOAs estn formadas por servicios.
o Poco acoplados.
o Altamente interoperables.

Para comunicarse utilizan una definicin formal independiente de la plataforma y del
lenguaje (p.e. SOAP).

La definicin del interfaz (WSDL) encapsula las particularidades de una implementacin,
lo cul la hace independiente del fabricante, lenguaje o tecnologa.

Ventajas.
Permite disponer de componentes muy reusables.
Total independencia de la plataforma/lenguaje/etc.
No est asociado a ningn protocolo de transporte o infraestructura de objeto
distribuido.
Aprovecha estndares (XML) bien conocidos.
Permite la interoperabilidad entre casi cualquier entorno.



Inconvenientes.
El XMLes pesado y lento de parsear
Tecnologa todava naciendo, problemas de seguridad, etc.

Principios SOA.
Principios generales:

Reutilizacin.
Granularidad.
Modularidad.
Interoperabilidad.
Conformidad a los estndares.
Identificacin y categorizacin de servicios.


Principios de Arquitectura:

Encapsulacin de servicios.
Minimizacin de acoplamiento entre servicios.
Contrato de servicios.
Abstraccin de servicios.
Reutilizacin de servicios.
Composicin de servicios.
Autonoma de servicios.
Optimizacin de servicios.
Descubrimiento de servicios.






SOA por partes.
Definicin 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
especificacin procesable por la mquina de la interfaz del web service escrita en WSDL.
Este define el formato de los mensajes, tipo de datos, protocolos de transporte que deberan
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 informacin 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 cmo
procesarlo.
o Un conjunto de reglas para expresar instancias de tipo de datos definidos en nuestra
aplicacin.
o Una convencin 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 comunicacin entre servicios web.


Ejemplo Peticin.

Ejemplo Respuesta.



2.4.7 UDDI (Universal Description Discovery and Integration).

Es el protocolo para la descripcin, descubrimiento e integracin universal. Publica la
informacin de los servicios Web y permite a las aplicaciones comprobar qu web services
estn disponibles.


Registro independiente de la plataforma basado en XML para registrar servicios web y
permitir el descubrimiento de los mismos.
Se compone de:
Pginas Blancas: Direccin, contacto e identificadores conocidos.
Pginas Amarillas: Categorizacin industrial basada en taxonomas estndar.
Pginas Verdes: Informacin tcnica 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.