Tema 4: Desarrollo de soluciones de SSDD

Sistemas Distribuidos Marcos López Sanz [Curso 2011-2012]

Sistemas distribuidos – Curso 2011-2012 www.kybele.es

Índice

Middleware para SSDD

RMI (genérico)

CORBA 2

Java RMI

Enterprise JavaBeans

Middleware para sistemas Peer-to-Peer

Ejercicios

Soluciones de SSDD

Middleware Objetivo:

Ofrecer una abstracción de programación de alto nivel para el desarrollo de SSDD y, mediante capas, ocultar la heterogeneidad de la infraestructura subyacente para mejorar la interoperabilidad y la portabilidad

Alternativas Middleware de objetos distribuidos

• Modelo de programación OO • Comunicación por RMI (mayormente) • Beneficios: encapsulación, abstracción de datos, soluciones flexibles y dinámicas • Ej.: Java RMI, CORBA

Middleware de componentes distribuidos • Retos: evitar dependencias implícitas (referencias en/a interfaces), complejidad

de programación, falta de separación de aspectos distribuidos (seguridad, gestión de errores, concurrencia…), falta de estrategias de despliegue

• Ej.: EJB, DCOM, Fractal

Otras alternativas: • Sistemas Peer-to-Peer • Servicios Web

Objetos y Componentes Distribuidos

RMI (Remote Method Invocation) Extensión de las RPC (p.ej. Sockets) para un entorno orientado a

objetos Reto: que un objeto local sea capaz de invocar un método de un

objeto potencialmente remoto

Similitudes RPC vs. RMI: Programación con interfaces Construidos sobre protocolos Request-Reply Nivel de transparencia equivalente: misma sintaxis para invocación local

y remota

Diferencias RPC vs. RMI Con RMI se pueden usar técnicas (patrones y metodologías) orientadas a

objetos para su programación Semántica de parámetros más “rica” posibilidad de usar OIDs como parámetros

• Beneficio en el paso por referencia invocación a través del OID remoto en vez de enviar el objeto completo

RMI. Cuestiones de diseño Modelo de objetos Conceptos: objeto/clase/métodos/atributos

Propiedades: encapsulación/abstracción/modularidad

Referencias de objetos: nombre.método (parámetros)

Interfaces: definición de las signaturas de los métodos

Acción: resultado de la invocación de un método (cambio de estado, instanciación de un nuevo objeto, etc.)

Excepciones: manejo de errores (throw/catch)

‘Recolector de basura’: eliminación de objetos que ya no se utilizan

Estado: valores de las variables instanciadas

RMI. Cuestiones de diseño

Objetos distribuidos

Arquitectura tradicional: cliente/servidor

Servidor: maneja los objetos ‘invocables’

Comunicación (típica) basada en el paso de mensajes de invocación y respuesta

• Alternativas: replicación o migración de objetos

Importante en RMI: encapsulación del estado remoto • Acceso a los atributos sólo por los métodos concurrencia

• Ocultación de los tipos de datos internos utilizados

RMI. Cuestiones de diseño Modelo de objetos distribuidos Premisa: cada proceso contiene una colección de objetos que

pueden recibir invocaciones locales o remotas

Conceptos básicos: • Objeto remoto: aquél que puede recibir invocaciones remotas

(aquellos que se ejecutan en procesos diferentes)

• Referencias a objetos remotos: forma de conocer el objeto remoto al que se puede invocar OID remoto

• Interfaz remota: describe los métodos que pueden invocarse de forma remota

» La clase de un método remoto implementa los métodos publicados en su interfaz

» Lenguaje del interfaz: IDL (en CORBA), Java RMI

» Lenguaje de la implementación del IDL: Java, Python, C++, etc.

RMI. Implementación

Extraído de Coulouris et al. Distributed Systems: Concepts and Design. 2012

RMI. Implementación Módulo de comunicación

Implementan el protocolo de petición-respuesta (p.ej. sobre HTTP o directamente sobre TCP o UDP)

Parámetros (tipo Java): messageType, requestId, operationId

Modulo de referencia remota Transforma las referencias a objetos remotos en referencias locales y viceversa

(marshalling/unmarshalling) Uso de una tabla interna para almacenamiento de correspondencias

‘Servant’: clase en el servidor remoto que ejecuta la petición remota (instanciación remota)

Software RMI (middleware): Proxy (cliente): ofrece transparencia de acceso (invocación remota como local).

Un proxy por cada objeto remoto invocado. Intermediario Dispacher (servidor): recibe las peticiones del módulo de comunicación y las

traslada al ‘skeleton’ Skeleton: clase que implementa los métodos de la interfaz remota. Se encarga

de hacer de intermediario entre la representación ‘pública’ y el objeto real del servidor (‘servant’)

RMI. Implementación

Generación de proxies, dispatchers y skeletons

Compilador de interfaces (Orbix en CORBA) • Genera el código C++ o Java a partir de un interfaz

• Interfaces: IDL o interfaz Java

Elementos adicionales

Binder: mantiene una tabla de nombres textuales-referencias a objetos remotos:

• CORBA: CORBA Naming System

• Java RMI: RMIregistry

CORBA Estándar del OMG (1989) Motivación Que los programas (distribuidos) se pudieran programar en

cualquier lenguaje

Premisas: Metáfora: ORB (Object Request Broker) ayudar a un cliente

a invocar un método en un objeto siguiendo las premisas del estilo RMI Fases: localizar el objeto remoto, activar el objeto remoto,

comunicar la petición del objeto cliente al objeto remoto y devolver su respuesta

Versiones CORBA 2: orientado a objetos CORBA 3 (CCM): basado en componentes

CORBA 2

Elementos

Un lenguaje de definición de interfaz: IDL

Una arquitectura

Una representación de datos externa (mensajes): CDR

Una forma estándar de identificar referencias de objetos remotos

Un conjunto de servicios genéricos útiles para aplicaciones distribuidas

CORBA 2. CORBA RMI Modelo de objetos de CORBA

CORBA Object = objeto remoto que: • Implementa una interfaz IDL, • Tiene una referencia de objeto remoto • Es capaz de responder a las invocaciones referidas a las operaciones definidas en su interfaz • Está programado en un lenguaje que no necesariamente es OO

El concepto de clase no está implementado en IDL, sólo tipos de datos

CORBA IDL

Un interfaz IDL especifica un nombre y un conjunto de métodos Ofrece facilidades para especificar módulos, tipos, atributos, signaturas de

métodos e interfaces La gramática es un subconjunto de ANSI C++

Otras características de CORBA

Existen problemas a la hora de hacer los mappings IDLlenguaje de implementación

Existe la posibilidad de definir RMI con CORBA de forma asíncrona (llamadas no bloqueantes)

CORBA 2. Ejemplo pizarra compartida

Interfaz IDL

CORBA 2. Arquitectura

CORBA 2. Arquitectura ORB Core

Incluye toda la funcionalidad de comunicación Ofrece una interfaz adicional con varias operaciones:

• Parar e iniciar el ORB • Convertir referencias de objetos remotos y strings • Listas de argumentos para invocaciones dinámicas

Adaptador de objetos Sirve de puente entre los objetos CORBA con interfaces IDL y los

interfaces de programación de las clases ‘servant’ que realmente ejecutan el código remoto invocado

Tareas: • Crear referencias remotas a objetos CORBA • Repartir cada petición RMI hecha a un skeleton al ‘servant’ adecuado • Activar y desactivar ‘servants’

POA (Portable Object Adapter): permite interconectar aplicaciones y ‘servants’ sobre ORBs de diferentes proveedores

CORBA 2. Arquitectura Skeletons

Se generan en el lenguaje del servidor mediante un compilador IDL a partir de un interfaz IDL

Deserializa (unmarshall) las peticiones RMI y serializa (marshall) las excepciones y respuestas

Stubs cliente (proxy) Se generan en el lenguaje del cliente mediante un compilador IDL a

partir de un interfaz IDL También serializan/deserializan

• Proxy: para clientes programados en lenguajes OO • Stub: para clientes programados en otros lenguajes procedurales

Repositorio de implementación Activa y localiza (mapea) servidores registrados correspondientes a los

adaptadores conocidos por el ORB

Repositorio de interfaces Ofrece información acerca de las interfaces IDL registradas en el ORB

CORBA 2. Servicios

Servicio de nombrado (básico en todo ORB)

Servicio de localización por atributo

Servicio de eventos

Servicio de notificación

Servicio de seguridad

Servicio de transacción

Servicio de control de concurrencia

Interfaces Java (a partir de IDL)

Clase del servidor en Java (‘servant’)

Clase principal del servidor (crea ORB, adaptador y servant)

Clase principal del cliente

Java RMI Extiende el modelo de objetos de Java para

entornos distribuidos

Transparencia relativa Excepciones propias: RemoteExceptions

Implementación del objeto remoto: debe implementar la interfaz Remote del paquete java.rmi

Ventaja: lenguaje único las interfaces se programan en Java (no en un lenguaje común IDL como en CORBA)

Si un programa cliente no tiene la clase remota que invoca, ésta se descarga automáticamente

Java RMI. Ejemplo: pizarra compartida

Definición de la interfaz remota

Definición del programa del lado del servidor

Java RMI. RMIRegistry Binder para Java RMI

Una instancia de esta clase debe correr en cada servidor que ofrezca clases RMI

Clase principal: Naming

Argumentos: strings de URL //nombreMaquina:puerto/nombreObjeto

Operaciones: bind/rebind (registrar nombre de objeto remoto),

unbind (desregistrar),

lookup (obtener referencia remota de objeto),

list (lista de nombres registrados)

Definición de la clase servant que implementa la interfaz publicada

Definición de la clase cliente

Middleware basado en componentes Problemas del MW de objetos distribuidos

Dependencias implícitas • Una estrategia distribuida no debería indicar sólo las interfaces sino

también los objetos que utilizará durante la invocación (naming, concurrencia, seguridad, transacciones, etc.)

Interacción con el middleware • Una estrategia distribuida debería separar la programación de la aplicación

de la programación de la interacción con el MW

Falta de separación de los aspectos de distribución • Una estrategia distribuida debería permitir que un programador se

abstuviera de tener que conocer aspectos relacionados con NFR del MW

Falta de soporte para el despliegue • Una estrategia distribuida debería ocultar las complejidades de instalación

de una solución distribuida (hacerlo igual que si fuera local)

Consecuencias: Desarrollo de middleware basado en componentes Estilos de middleware: “servidor de aplicaciones”

Middleware basado en componentes Fundamentos de los componentes

Componente: “Unidad de composición con únicamente una serie de interfaces contractuales y dependencias explícitas del contexto”

Arquitectura de componentes: componentes, interfaces y conexiones entre interfaces a través de puertos

Un componente se define en función de un “contrato” • Interfaces provistas: lo que el componente ofrece como servicios a otros

componentes • Interfaces requeridas: las dependencias que el componente establece en

términos de otros componentes que deben existir (y conectarse a él) para que funcione correctamente

Estilos de interfaces • Aquellos que soportan RMI (tipo CORBA y Java RMI) • Aquellos que soportan eventos distribuidos

Concepto de composición • Objetivo: usar componentes preexistentes y “ensamblarlos” fácilmente

(composición frente a herencia) • COTS: Commercial Off-The-Shelf

Middleware basado en componentes Fundamentos de los componentes

Programación de sistemas (complejos) basados en componentes = desarrollo de componentes + composición

Concepto de “container” • Elemento que almacena uno o varios componentes que implementan la

aplicación o lógica de negocio • Elementos (similar a una arquitectura 3 capas):

» Front-end ofrecido a un cliente (p.ej. Web) » Contenedor de componentes » Servicios de sistema que gestionan los datos asociados en

almacenamiento persistente • Tarea: ofrecer un entorno de almacenamiento (hosting) del lado del

servidor administrable para componentes y permitir una separación de aspectos de acuerdo a los criterios de diseño deseados

• Intercepta comunicaciones destinadas a los componentes y las redirige a los componentes internos (previa comprobación de cuestiones de NFR)

• El MW que soporta esta tarea se suele llamar “servidor de aplicaciones”

Middleware basado en componentes

Fundamentos de los componentes

Ejemplos de servidores de aplicaciones: • IBM: WebSphere Application Server

• Sun: Enterprise JavaBeans

• SpringSource (VMWare): Spring Framework

• JBoss Community: JBoss

• OMG: CORBA Component Model (CCM/CORBA 3)

• OW2 Consortium: JOnAS

• Sun: GlassFish

Middleware basado en componentes Tareas del MW para CBSD: Despliegue de configuraciones de componentes

Liberación de SW empaquetado como arquitecturas CB

Creación de descriptores de despliegue (Apache Ant). Información:

• Suficiente para asegurar que los componentes están bien conectados (protocolos usados y soportados por el MW)

• Configuración del MW (p.ej. de los POA en CORBA)

• Configuración para los servicios del MW

Tecnologías Enterprise JavaBeans (1999)

CORBA Component Model (CCM) (2001)

Enterprise JavaBeans (EJB)

Especificación de una arquitectura de componentes gestionada en el lado del servidor

Perteneciente a la plataforma Java: Java EE

Definido como “modelo de componentes de servidor”

Componente = ‘Bean’: intentan capturar la lógica de negocio

Ofrecen soporte para separar el almacenamiento persistente

Enterprise JavaBeans (EJB) Objetivo: mantener una separación de los aspectos (roles) de

gestión del sistema distribuido

Roles: Bean provider: desarrolla la lógica de aplicación del componente Application assembler: agrupa beans en configuraciones de aplicación Deployer: asegura que una configuración de aplicación está bien

desplegada en un entorno operativo Service provider: especializado en servicios propios del SD como gestión

de transaccionalidad o seguridad Persistence provider: especializado en la gestión del almacenamiento

persistente de datos Container provider: (sobre los 2 anteriores) responsable de configurar

los containers correctamente y ofrecer soporte de NFR System administrator: monitorización en tiempo de ejecución

Consecuencia la arquitectura EJB es muy pesada y compleja

EJB 3.0 (2006) Modelo de componentes EJB

Definición de ‘bean’ o ‘JavaBean’: componente que ofrece uno o más interfaces de negocio a potenciales clientes + ‘bean class’ que implementa dichos interfaces

Las interfaces pueden ser remotas (requiere Java RMI o JMS) o locales

Estilos de bean: • Beans de sesión

» Implementa una funcionalidad de negocio » Pueden tener estado (conversación) o no tenerlo

• Beans dirigidos por mensajes » Comunicación indirecta (colas de mensajes) » JMS » Sistemas de eventos

• Beans de entidad » Se usan para acceder a BD » Gestiona la integridad de los datos persistentes

EJB 3.0 (2006) Programación de EJB POJO (Plain Old Java Objects)

• Implementación en Java sin referencia a pertenecer a un bean

‘Annotations’ • Directivas relacionadas con la participación de una clase POJO a un

bean • Forma de asociar metadatos (comportamiento o interpretación)

» Ej. @Stateful public class eShop implements Orders {…}

Contenedores en EJB Contexto de ejecución entre el bean y el servidor Deben ser configurados para ofrecer determinadas políticas de

transaccionalidad, seguridad, persistencia y ciclo de vida Configuración basada en anotaciones

EJB 3.0 (2006) Contenedores en EJB. Interceptación El contenedor EJB intercepta las invocaciones que se hacen a

los componentes internos del contenedor • Interceptación de llamada

» Utilizado para realizar acciones cuando se recibe una invocación o sucede un evento

» Forma de indicar la interceptación: @Interceptors sobre un bean o sobre un método @AroundInvoke indicando un método especial en una clase

• Interceptación de eventos

» @PostConstruct

» @PreDestroy

» @PostActivate

» @PreActivate

EJB 3.0 (2006)

Elementos EJB

Bean: clase que define la lógica de negocio y a la que se accede a través de la interfaz remota

Interfaz remota: indica los métodos que se pueden utilizar del bean

Container: clase que encapsula los beans e implementa la interfaz local

Interfaz local: conjunto de métodos para la creación, acceso y destrucción de las instancias de los beans

EJB 3.0 (2006). Arquitectura

claseCliente Usa la interfaz remota para acceder al Bean

Servidor EJB

Contenedor EJB

interfazLocal • Hereda de EJBHome • Implementa objetoBean create () crea objetos EntityBean

interfazRemota • Hereda de EJBObject • Interfaz visible del Bean

claseBean •Implementa EntityBean • Implementa los métodos de la interfazRemota • Lógica de negocio

objetoClaseBean • Instancia del Bean

define

implementa

EJB 3.0 (2006). claseCliente import java.util.*;

import javax.naming.Context;

import javax.naming.InitialContext;

import javax.rmi.PortableRemoteObject;

public class AccountClient { public static void main(String[] args) {

// Creación de un contexto

Context initial = new InitialContext();

Object objref = initial.lookup("MyAccount");

// Interfaz Home

AccountHome home = (AccountHome)PortableRemoteObject.narrow

(objref, AccountHome.class);

// Creación de Beans:referenciados por su interfaz remoto o "vista del bean"

(Account) Account duke = home.create("123", "Duke", "Earl", 0.00);

// Acceso al Bean por medio del interfaz remoto

duke.credit(88.50); duke.debit(20.25);

double balance = duke.getBalance();

System.out.println("balance = " + String.valueOf(balance));

duke.remove(); ....

EJB 3.0 (2006). interfazRemota (vista del Bean)

import javax.ejb.EJBObject;

import java.rmi.RemoteException;

public interface Account extends EJBObject {

public void debit(double amount)

throws InsufficientBalanceException, RemoteException;

public void credit(double amount)

throws RemoteException;

public double getBalance()

throws RemoteException;

EJB 3.0 (2006). interfazLocal (creación y localización del Bean)

import java.util.Collection;

import java.rmi.RemoteException;

import javax.ejb.*;

public interface AccountHome extends EJBHome {

public Account create(String id, String firstName,

String lastName)

throws RemoteException, CreateException;

public Account findByPrimaryKey(String id)

throws FinderException, RemoteException;

public Collection findByLastName(String lastName)

public Collection findInRange(double low, double high)

EJB 3.0 (2006).

import java.sql.*;

import javax.sql.*;

import java.util.*;

import javax.ejb.*;

import javax.naming.*;

public class AccountEJB implements EntityBean {

public String ejbCreate(String id, String firstName,

String lastName, double balance)

throws CreateException {

insertRow(id, firstName, lastName, balance);

} catch (Exception ex) {

throw new EJBException(ex.getMessage());

this.id = id;

this.firstName = firstName;

this.lastName = lastName;

this.balance = balance;

return id;

http://www.proactiva-calidad.com/java/ejb/ejb_ejemplo.html

Sistemas Peer-to-Peer

Objetivo Permitir la compartición de datos y recursos a gran escala eliminando

cualquier requisito que dependa de los servidores intermedios y de la infraestructura subyacente

Careacterísticas (Coulouris et al.) Su diseño asegura que cada usuario contribuye a los recursos del sistema Independientemente del recurso compartido, todo nodo del sistema tiene

la misma responsabilidad y capacidades Su operatividad correcta no depende de la existencia de ninguna entidad

administrativa centralizada Pueden ser diseñados para ofrecer cierto grado de anonimidad a los

proveedores y usuarios de registros La eficiencia del sistema (así como sus capacidades) dependen del

algoritmo implementado para el posicionamiento de los datos en múltiples nodos

Definición 1 (2004)

Un sistema peer-to-peer es un sistema auto-organizado formado por entidades (peers) iguales y autónomas cuyo objetivo es la utilización compartida de recursos distribuidos en un entorno interconectado evitando la utilización de servicios centralizados

Definición 2

Un sistema que tiene descentralizado tanto la organización (self-organization) como la utilización de recursos

Utilización de recursos descentralizada Independientemente de la topología de la red, la

comunicación peer-to-peer debe basarse en los principios de comunicación entre extremos (end-to-end)

El conjunto de recursos compartidos se puede referir a almacenamiento, conectividad, presencia humana, etc.

Los peers se conectan a través de una red, normalmente distribuida globalmente (no LAN)

La identificación de los peers suele realizarse mediante identificadores no estructurados derivados de la descripción del contenido compartido

Auto-organización descentralizada Los peers interactúan directamente entre sí

Los peers acceden a los recursos compartidos sin

necesidad de utilizar un recurso centralizado. Cuando éste existe por motivos de eficiencia, se habla de peer-to-peer híbrido

Flexibilidad: cada peer puede actuar como cliente o como servidor

Los peers de un SSDD P2P son miembros equivalentes con una funcionalidad simétrica

Generaciones de peer-to-peer

Primera generación

Aproximación no estructurada

Búsquedas basadas en consultas a servidores centralizados que conocían la localización de los datos

Después de la localización: intercambio entre peers

Aproximación híbrida

Ejemplos: Napster (2001)

Primera generación: Napster

Segunda generación

Aproximación no estructurada

Búsquedas por inundación (a todos los peers)

Un cliente al menos conoce la IP de otro cliente

Ejemplos: Audogalaxy, Freenet, Gnutella, Kazaa, bitTorrent

Explicación del algoritmo de GNUtella: http://www.slais.ubc.ca/courses/libr500/05-06-wt1/www/R_Martin/Gnu_Arch.htm

Segunda generación: GNutella

Tercera generación Aproximación estructurada

Creación de capas middleware para la gestión independiente de recursos distribuidos

Basado en la existencia de “super-peers” que realizan el enrutamiento intermedio (overlay)

Utilización de técnicas basadas en tablas hash distribuidas (DHT) complejidad de la búsqueda O(log N)

Cada peer tiene asignado un fragmento del espacio de búsqueda

Ejemplos: Pastry, Tapestry, CAN, Chord, Kademlia (Kad/eMule)

Tercera generación: eMule

Protocolo eMule:

http://www.cs.huji.ac.il/labs/danss/p2p/resources/emule.pdf

Generaciones de peer-to-peer. Resumen

Cap. 5. LNCS 3485

Ejercicios

¿Cuál es la diferencia entre RPC y RMI?

¿Cuál es la diferencia entre RMI con CORBA (v2) y Java RMI?

¿Cuál es la diferencia entre un middleware para sistemas distribuidos Peer-to-Peer basado en una estrategia estructurada y aquellos basados en una estrategia no estructurada?

Tema 4: Desarrollo de soluciones de SSDD - Inicio | …SSDD... · Un lenguaje de definición de...

Transcript of Tema 4: Desarrollo de soluciones de SSDD - Inicio | …SSDD... · Un lenguaje de definición de...

Tema 4: Desarrollo de soluciones de SSDD - Inicio | …SSDD... · Un lenguaje de definición de...

Documents

Transcript of Tema 4: Desarrollo de soluciones de SSDD - Inicio | …SSDD... · Un lenguaje de definición de...

Anàlisis mediambiental: Aplicació de la Corba de Kuznets a ...

Una Nueva Arquitectura para la Integración de CORBA y OODB

Material i procediments endovasculars bàsics · • 0.014”: astato xs (asahi), winn 200t (abbott). • Configurar punta a 45º (inclús doble corba). • Longitud de la corba depèn

Versión RT-CORBA del servidor Pioneer 2AT-8.

CORBA - unice.frbaude/AppRep/corbasimpleGris.pdf · 2013. 5. 6. · CORBA Common Object Request Broker Architecture : CORBA Plate-forme client/serveur orientée objets Un standard

T4 Middle Ware RMI CORBA Parte1

Legajo nombrado

CORBA Component Model - unibo.itlia.deis.unibo.it/Courses/sd1415-info/lucidi/08-CCM(2x).pdf · CORBA Component Model (CCM) Giusto per rammentare che EJB3.x non è unico modello a

Fault Tolerant CORBA Tutorial - omg.org · Fault Tolerant CORBA Tutorial © Eternal Systems, Inc, & Vertel Corp. 2001 Outline 1.

Common Object Request Broker Architecture CORBA Computación de objetos distribuidos y CORBA CORBA es una solución para la distribución de objetos OMG.

Invocación Dinámica en CORBA

Apuntes Ssdd 0.3.7

Arquitectura ssdd

ARQUITECTURA CORBA

SSDD HHUUEESSCCAA R R.. VVAALLLLAADDOOLLIIDD · 2020. 10. 16. · Desde 1995 Nº 3/398 Año XX Huesca, a 18 de octubre de 2020 La Revista Deportiva de HUESCA por Excelencia SSDD HHUUEESSCCAA

Introducción a las arquitecturas de componentes y a …ocw.uc3m.es/ingenieria-telematica/software-de-comunicaciones/tran... · – CORBA 3 y el modelo de componentes de CORBA (CCM)

TRABAJO DE CORBA

Portal de Irregularidades SSDD - lan. · PDF file• Cómo Interpretar un PNR Resiber. Irregularidades SSDD 15 Revenue Integrity 19 de junio de 2012 POLÍTICA DE RESERVA LAN

Taller Arduino SSDD

Cuartelv SSDD Gas Caso ISP