Unidad II Arqitectura de Sistemas Distribuidos

Texto completo

(1)

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)

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.

(3)

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.

(4)

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

(5)

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.

(6)

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?

(7)

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.

(8)

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.

(9)

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)

(10)

 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.

(11)

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.

(12)

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.

(13)

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

(14)

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.

(15)

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

(16)

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

(17)

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.

(18)
(19)
(20)
(21)

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.

(22)

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

(23)

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.

(24)

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.

(25)

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.

(26)

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); }

(27)

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.

(28)

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?

(29)

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.

(30)

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).

(31)

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).

(32)

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.

(33)

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.

(34)

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)

(35)

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.

(36)

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

Figure

Actualización...

Referencias

Actualización...