4. Tendencias en el Desarrollo de Sistemas Distribuidos

4. Tendencias en el
Desarrollo
de Sistemas Distribuidos
Tendencias en el desarrollo
CORBA
CORBA yyDCOM:
DCOM: Modelo
Modelode
de
Objetos
ObjetosDistribuidos
Distribuidos
Java
JavaBeans:
Beans: Modelo
Modelode
de
Componentes
ComponentesDistribuidos
Distribuidos
Grids:
Grids:Un
Unmundo
mundoinfinito
infinito
de
derecursos
recursos
Peer-to-Peer
Peer-to-Peer computing:
computing:Cómputo
Cómputointensivo
intensivo
descentralizado
descentralizado
Objetos Distribuidos
CORBA: Un caso de Estudio
Profs. Yudith Cardinale-Mariela Curiel
Sep – Dic 2002
1
Programación Orientada por
Objetos
Código Monolítico (Spaguetti)
Distintos Archivos, Librerías
„ Objetos
„
„
„
Ventajas: código más modular, reusabilidad,
mantenibilidad, división del trabajo.
Modelos de Programación para
Aplicaciones Distribuidas
„ Llamadas
a procedimientos remoto
„ Invocación a un método remoto (RMI)
„ Modelo de programación basado en
eventos (Java Beans)
Programa Distribuido
Computador1
main
Computador2
Comp. local
Comp. remoto
Cliente
Funciones del
Servidor
func()
func(void ){
}
proc1
proc2
proc4
proc3
proc5
Thread de ejecución
Thread bloqueado
Llamada a proc.
remota
2
Interfaces
Interfaces en los sistemas distribuidos
„ Interfaces de servicio
„ Interfaces remotas
Los lenguajes de definición de interfaces
(IDL) están diseñados para permitir que
los objetos implementados en lenguajes
diferentes se invoquen unos a otros. Ejem:
CORBA IDL, Sun XDR.
Modelo de Objetos
„
„
„
„
Un programa OO consta de un conjunto de
objetos que interactúan entre ellos.
Cada objeto se compone de un conjunto de
datos y un conjunto de métodos.
Un objeto se comunica con otro objeto
invocando sus métodos, generalmente
pasándole argumentos y recibiendo resultados
Se puede acceder a los objetos mediante
referencias a objetos.
Modelo de Objetos
„
„
„
La interfaz define las firmas o signatures de los
métodos (nombre, tipos de sus argumentos,
valores devueltos y excepciones) sin especificar
su implementación.
Se manejan excepciones
Se hace necesario proporcionar mecanismos de
liberación del espacio ocupado por aquellos
objetos que ya no lo necesitan (compactación
automática de la memoria)
3
Modelo de Objetos Distribuidos
En el modelo C/S, los objetos son
administrados por servidores y sus
clientes invocan sus métodos utilizando
una invocación de métodos remota (RMI)
„ Cuando el cliente invoca un método de un
objeto remoto, se envía un mensaje al
servidor que lo administra.
„
Modelo de Objetos Distribuidos
„
Cada proceso contiene un conjunto de
objetos, algunos de los cuales pueden
recibir tanto invocaciones locales como
remotas. Otros objetos sólo pueden
recibir invocaciones locales.
Invocación
Remota
Invocaciones
locales
Invocación
Remota
C
A
B
D
E
Objeto Remoto
Objeto Remoto
Modelo de Objetos Distribuidos
„
La invocación se lleva a cabo ejecutando
el método del objeto en el servidor y el
resultado se devuelve al cliente en otro
mensaje.
4
Modelo de Objetos Distribuidos
Existen dos conceptos fundamentales:
„ Referencia de objeto remoto:
… Otros
objetos pueden invocar los métodos de
un objeto remoto si tienen acceso a su
referencia de objeto remoto.
… Las referencias a objetos remotos se pueden
pasar como argumentos y resultado de las
invocaciones de métodos remotos.
Modelo de Objetos Distribuidos
„
Interfaz remota:
… Cada
objeto tiene una interfaz remota que
especifica cuáles de sus métodos pueden
invocarse remotamente.
… El sistema CORBA proporciona un IDL que
permite definir interfaces remotas. Las clases de
los objetos remotos y los programas de los
clientes pueden implementarse en cualquier
lenguaje. Los clientes CORBA no tienen que estar
en el mismo lenguaje que el objeto remoto.
Invocación
Remota
Invocaciones
locales
Invocación
Remota
C
A
B
Interfaz Remoto
D
E
Interfaz Remoto
Modelo de Objetos Distribuidos
„
Una invocación a un método remoto debe
ser capaz de lanzar excepciones. CORBA
IDL proporciona una notación para las
excepciones.
5
Corba: un estándar para
construir objetos
distribuidos.
Object Management Group
(OMG)
¾
Es un consorcio internacional que promueve
el desarrollo de software orientado por
objetos
¾
El objetivo del OMG es proveer un marco de
arquitectura común para permitir la
interacción de objetos en plataformas
heterogéneas y distribuidas.
Object Management Group
(OMG)
¾
Fue fundado en 1989.
¾
Inicialmente estuvo conformado por 8
compañías: 3Com Corpotation, American
Airlines, Canon Inc., Data General, HewlettPackard, Philips Telecommunications N.V.,
Sun Microsystems y Unisys Corporation.
¾
Actualmente hay más de 500 miembros
6
Object Management Group (OMG)
¾ El
OMG no realiza trabajos de
desarrollo e implementación, más
bien se basa en la tecnología
existente ofrecida por sus miembros.
¾ Propone especificaciones para el
desarrollo de computación
distribuida basada en objetos: OMA
(Object Management Architecture).
Object Management Architecture
(OMA)
¾ OMA
es una arquitectura de
referencia sobre la cual se pueden
construir aplicaciones.
¾ Define, a un nivel alto de abstracción
las “facilidades” necesarias para el
desarrollo de aplicaciones
distribuidas orientadas por objetos.
Object Management Architecture
(OMA)
„
Ofrece dos modelos fundamentales, en los
cuales se basan CORBA y otras interfaces
standard:
… Core
Object Model: conjunto abstracto de conceptos
que permiten comprender los objetos y sus
interfaces. Los conceptos no pueden redefinirse o
reemplazarse, sólo extenderse si es necesario para
hacerlos más concretos. Relevante para los que
implementan ORB´s
… Modelo de Referencia: marco arquitectónico para
el desarrollo de aplicaciones.
7
Core Object Model
Sus principales metas son:
interoperabilidad y portabilidad
Portabilidad: conocimiento de las interfaces
de los objetos y la capacidad de crear
aplicaciones cuyos componentes no
confían en la existencia o localización de
una implementación de objeto particular.
„
Core Object Model
Interoperabilidad: capacidad de invocar
operaciones en los objetos sin importar
dónde se ubican, sobre qué plataforma se
ejecutan o en qué lenguaje de
programación se implementaron. Esto se
logra mediante el Object Request Broker.
Core Object Model
„
Conceptos
… Objetos
… Operaciones,
Firmas, parámetros, valores de
retorno
… Tipos que no son objetos
… Interfaces
… Reemplazabilidad
… Herencia
8
Core Object Model
„
„
Objetos: modelos de entidades o conceptos. Un
objeto puede modelar un documento, una fecha,
un empleado, un compilador.
Operaciones, Firmas, parámetros, valores de
retorno:
… Operación:
es un comportamiento que ofrece el
objeto, el cuál se conoce “afuera” a través de la firma.
Los nombres de las operaciones son únicos dentro
de un objeto particular. Una referencia a un objeto
puede devolverse como el resultado de una
operación. Las Operaciones pueden causar cambios
en el estado del objeto. Si un objeto no puede
procesar un requerimiento retorna una excepción.
Core Object Model
„
„
„
Tipos que no son objetos: se llaman tipos de
datos
Interfaz: es una colección de firmas. Es el
conjunto de operaciones que ofrece el objeto.
Capacidad de Reemplazo: un objeto que ofrece
una interfaz puede usarse en el lugar de otro
objeto con una interfaz similar.
Core Object Model
„
Herencia: Si una interfaz A hereda de una
interfaz B, A ofrece todas las operaciones
de B y puede ofrecer operaciones
adicionales.
9
El Modelo de Referencia
„
Es un marco arquitectónico que
estandariza las interfaces para la
infraestructura y los servicios que una
aplicación puede usar.
El Modelo de Referencia
Objeto CORBA
Wrapper para una aplicación Legacy
Common
Facilities
Application
Objects
Object Request Broquer (ORB)
Object Services
Domain Objects
El Modelo de Referencia
¾
ORB (intermediario de petición de
objetos) Permite o facilita la
comunicación entre objetos. La
tecnología adoptada para los ORBs es
lo que se conoce como CORBA.
Common
Facilities
Application
Interfaces
Object Request Broquer (ORB)
Object Services
10
El Modelo de Referencia
Corba (Common Object Request Broker
Architecture) es un diseño de middleware
que permite que los programas de aplicación
se comuniquen unos con otros con
independencia del lenguaje de programación,
sus plataformas de hw y sw, las redes sobre
las que se comunican y sus
implementadores.
ORB
„
Provee:
… Una
extensión del Core, que incluye la
sintáxis y semántica de un IDL (Interface
Definition Language)
… Un entorno para interoperabilidad, que
incluye dos definiciones de protocolo
… Un conjunto de Mappings desde el IDL a un
subconjunto de lenguajes: C, C++, COBOL,
Smalltalk, Ada95, Java, Lisp y Python.
Object Services
¾
Object Services: definen un conjunto de objetos que implementan
servicios fundamentales de bajo nivel que los desarrolladores de
aplicaciones pudieran necesitar para administrar sus objetos y
datos. Los servicios incluyen: servicio de nombres, seguridad,
persistencia, ejecución concurrente y transacciones, etc. Permiten a
los desarrolladores construir aplicaciones sin tener que reinventar la
rueda.
Application
Objects
Common
Facilities
Object Request Broquer (ORB)
Object Services
Domain Objects
11
Modelo de Referencia
Common Facilities (CF): son servicios
genéricos de más alto nivel orientados a
las aplicaciones (Intercambio de Datos,
facilidades para imprimir, almacenamiento
de información, etc.).
¾ Domain Interfaces: interfaces
desarrolladas para aplicaciones en
particular (telecomunicaciones, Internet,
Salud) . Estos objetos hacen uso del resto
de los componentes.
¾
CORBA
Fue creada en 1991 (Corba 1.1). propone
una implementación específica del ORB
(IDL)
¾ En 1994 surge CORBA 2.0 (1994), que
definió estándares para permitir la
comunicación entre implementaciones
realizadas por desarrolladores diferentes.
Este estándar se denomina GIOP
(General Inter-ORB Protocol).
¾ CORBA 3.0 (1997) incrementa
interoperabilidad y funcionalidad (POA)
¾
Modelo de Objetos CORBA
„
„
„
„
Los clientes no son necesariamente objetos;
un cliente podrá ser cualquier programa que
envía mensajes de petición a objetos
remotos y recibe respuestas.
El término objeto CORBA se refiere a objetos
remotos.
Un objeto CORBA implementa una interfaz
IDL, tiene asociado una referencia de objeto
remoto y es capaz de responder a las
invocaciones de los métodos en su interfaz
IDL.
Se puede implementar un objeto CORBA en
un lenguaje que no sea OO.
12
Modelo de Objetos CORBA
„
Qué ofrece:
… Interfaces
independientes de las implementaciones
a objetos implementados en diversos
lenguajes de programación.
… Acceso a los objetos sin importar su localización
(transparencia)
… Generación de código automática para manejar
invocaciones remotas.
… Acceso a los servicios y facilidades de CORBA:
… Acceso
Corba IDL
IDL: Interface Definition Language
La interfaz especifica un nombre y un conjunto de
métodos que podrán utilizar los clientes.
¾ Es
un lenguaje declarativo
¾ Define tipos de objetos especificando
sus interfaces estáticas
¾ Sintaxis derivada de C++ con
palabras adicionales
Enfoque CORBA: IDL
// Ejemplo de especificación de
IDL: forma.idl y
ListaForma.idl
struct Rectangulo {
long ancho;
long alto;
long x;
long y;
};
struct ObjetoGrafico{
string tipo;
Rectangle enmarcado;
boolean estaRelleno;
};
interface Forma {
long dameVersion();
ObjetoGrafico DameTodoEstado();
};
Typedef sequence <Forma, 100> Todo
Interface ListaForma {
exception ExceptionLlena{};
Forma nuevaForma(in ObjetoGrafico g)
raises (ExceptionLlena)
Todo TodasFormas();
long dameVersion();
};
Lista de Ref. a objetos
CORBA
13
Enfoque CORBA: IDL
„
Los parámetros se etiquetan como in, out,
inout.
… in:
se pasa del cliente al objeto CORBA
invocado.
… out: lo devuelve el objeto CORBA
… inout: el valor de este parámetro puede
pasarse en ambas direcciones.
Enfoque CORBA: IDL
„
Si no se devuelve ningún valor el tipo
retornado se coloca como void.
„
Oneway indica que el cliente que invoca el
método no se bloqueará mientras el destino
lleva a cabo el método.
Cuando se lanza una excepción que
contiene variables, el servidor puede utilizar
las variables para devolver información al
cliente sobre la excepción.
oneway void retrollamada (in int version)
„
exception ExceptionLlena{};
exception ExceptionLlena{ObjetoGrafico g};
Semántica de las operaciones
„
La invocación remota en CORBA
define, por defecto, la semántica como
máximo una vez. Si una operación
retorna exitosamente, se garantiza que
se ejecutó exactamente 1 vez. Si
retorna una excepción fue ejecutada a
lo sumo 1 vez.
14
Enfoque CORBA: IDL
Value
Tipos IDL
Constructed value
Object Reference
array
struct sequence
Basic Values
Integer
Union
Float Point
Short Long UshortUlong Float
Double
char
string
octal
boolean
any
enum
La Arquitectura
de CORBA
in args
Operation()
CLIENT
OBJECT
IMPLEMENTATION
out args + return value
Request
ORB
La Arquitectura de CORBA
INTERFACE
REPOSITORY
IDL COMPILER
CLIENT
DII
IDL
STUBS
IMPLEMENTATION
REPOSITORY
SERVANTS
ORB
INTERFACE
IDL
SKELETON
DSI
OBJECT ADAPTER
GIOP/IIOP
ORB CORE
15
La Arquitectura de CORBA
Client
REQUEST
DII
¾IDL
IDL Stub
Stubs (resguardos o proxies): ORB Core
ƒFunciones generadas desde la interfaz IDL para “enlazarlas”
a los clientes
ƒProvee una interfaz de invocación estática
¾Dynamic Invocation Interface (DII)
ƒPermite especificar y construir requerimientos a tiempo de ejecución
ƒOperaciones: create_request, invoke, send, get_response
ƒ El cliente especifica el objeto, la operación y los parámetros. Se
obtienen a través del repositorio de interfaz.
Enfoque CORBA
¾IDL
Skeleton (Esqueletos):
ƒFunciones generadas desde la interfaz IDL para “enlazarlas” a
las implementaciones de objetos
Desempaqueta los argumentos y empaqueta las excepciones.
¾Dynamic Skeleton Interface (DSI)
ƒAnálogo al DII del lado de la implementación de objetos .
ƒEl Cliente especifica el objeto, la operación y los parámetros. Éstos
Se obtienen a partir del repositorio de Interfaces.
Servant
IDL Sk
DSI
ORB
Interface Object Adapter
ORB Core
Arquitectura de CORBA
¾
ORB Interface:
ƒ
Provee funciones para acceder directamente al
ORB core desde los clientes y desde las
implementaciones de objetos
List_initial_services()
Resolve_initial_references()
Estas funciones se utilizan para obtener una referencia al
POA.
ƒ
ƒ
ƒ
Operaciones que permiten su arranque y parada.
ƒ
ƒ
(orb_init()) se provee para obtener una referencia a un
pseudo-objeto ORB.
Operaciones para la transformación entre
referencias a objetos remotos y cadenas de texto.
16
Arquitectura de CORBA
¾ Repositorio
de Interfaces (Interface
Repository):
ƒ
Su información permite que un programa
encuentre un objeto cuya interfaz no conoce
en tiempo de compilación
¾ Repositorio
de Implementaciones
(Implementation Repository):
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Contiene información que permite al ORB
core localizar y activar implementaciones de
objetos
Funciones
de un
Adaptador
de Objetos
Genera referencias a objetos que se
registran en CORBA. IOR
(Interoperate object reference)
Otorga a cada objeto CORBA un
único nombre que forma parte de su
referencia a objeto remoto.
Medio de comunicación entre
implementaciones de objetos y el
ORB core.
Despacha cada RMI vía un
Servant
esqueleto hacia el sirviente
apropiado.
IDL Sk DSI
Activación/Desactivación de objetos ORB
Interface
Object Adapter
Incarnation/etherealization de
Sirvientes
ORB Core
Funciones de un Adaptador de
Objetos
„
El ORB y el OA cooperan para permitir
que las aplicaciones clientes invoquen
métodos de objetos CORBA y aseguran
que cada objeto CORBA se asocie a un
sirviente. El ORB y el OA cooperan para,
de forma transparente, localizar e invocar
a los sirvientes adecuados, una vez que
se tiene la información en las referencias.
17
Funciones de un Adaptador de
Objetos
„
¾
Diferentes OAs pueden soportar
diferentes estilos de implementación de
sirvientes. Por ejemplo, el Orbix Object
Database Adapter Framework, permite
implementar objetos usando una base de
datos OO. Otro ejemplo es el Real Time
Object Adapter (objetos a tiempo real.)
Estructura de un Adaptador de
Objetos
Algunas limitaciones (BOA)
¾ No
especifica cómo deben ser los
esqueletos o cómo deben asociarse los
sirvientes a los esqueletos.
¾ No especifica cómo se deben registrar los
sirvientes en el OA.
Al no estar estos puntos explícitos se pierde
portabilidad porque cada persona que
implementa un ORB lo hace de forma
distinta.
¾ No se establece nada respecto a servidores
multithreading.
Estructura de un Adaptador de
Objetos
POA: facilita la portabilidad de los servidores
CORBA.
¾
¾
¾
Identificador de objetos
Objetos persistentes y transitorios
Activación asociada al objeto, no al servidor.
¾ Explícitamente
se soportan servidores
multithreaded.
¾ Existen otras diferencias (Schmidt and
Vinosky)
18
Estructura de un Adaptador de
Objetos
¾
Tiene tres interfaces diferentes:
ƒ
Una interfaz privada para el esqueleto (envío de
respuestas)
ƒ
Una interfaz privada para el núcleo (llamadas al
objeto)
ƒ
Una interfaz pública para las implementaciones
de objetos (registro)
Estructura de un Adaptador de
Objetos
Sirviente: una implementación de objeto que
provee una semántica a tiempo de ejecución
para uno o más objetos CORBA.
¾ Object ID: identificador de objeto, único con
respecto a un POA.
¾ Mapa de Objetos Activos: asociación entre
identificadores de objetos y sirvientes.
Permite direccionar los requerimientos al
objeto adecuado.
¾
Estructura de un Adaptador de
Objetos
Incarnate: proveer un sirviente (running
servant) para servir los requerimientos
particulares a un objeto.
Etherealize: destruir la asociación entre el
sirviente y el objeto.
Default Servant: un objeto que atenderá los
requerimientos para objetos cuyos
identificadores no están en la tabla.
19
POA
„
„
„
Puede haber más de un POA activo en un
servidor particular.
Siempre existe un rootPOA a partir del cual se
crean todos los otros.
Cada POA tiene asociados un conjunto de
políticas que se pueden modificar una vez que
el POA se crea. Todos los objetos que maneja
un POA están sujetos a las mismas políticas.
POA: políticas
„
„
„
Unicidad del ID: determina si se puede asociar
más de un objeto al mismo sirviente.
Asignación del ID: determina quién asigna el
identificador del objeto: el programador o el
POA.
Tiempo de vida: determina si los objetos son
transitorios o persistentes, i.e. si los objetos
están disponibles al cliente una vez que se
destruye el POA.
POA: políticas
„
„
Retención de Sirvientes: Determina si el POA mantiene
asociaciones Sirviente-Objeto en un mapa (Active
Object Map), o confía en un sirviente por defecto o
posee servant locators para encontrar los sirvientes
adecuados en cada requerimiento.
Procesamiento de requerimientos: determina si el POA
utiliza el mapa, el sirviente por defecto, los locators o
combinaciones de estos mecanismos : para localizar el
sirviente una vez que viene un requerimiento. Existen
dos objetos adicionales:
…
…
Servant Activator: Un objeto que el POA usa para encarnar los
sirvientes.
Servan Locator: se usa para obtener un sirviente e invocar una
operación.
20
POA: políticas
Politica de threads: si la implementación
es multi-threading o no.
„ Activación de Sirvientes implícita: si se
puede activar a un sirviente de forma
implícita cuando se crea una referencia a
un objeto.
„
Referencia a Objetos
Un objeto CORBA puede identificarse, localizarse y direccionarse
por su referencia a objeto.
Nombre de tipo
de Interfaz IDL
Protocolo y dirección
detallada
Nombre de
Identificador
en el repositorio IIOP Dominio
del host
de interfaz
Número
de puerto
Clave del
Objeto
Nombre del Nombre o
adaptador ID del objeto
Inter-Operabilidad
¾ Es
necesario que inter-operen los
ORB´s de diversos fabricantes.
¾ Las barreras no son sólo de
implementación sino relacionadas
con la seguridad.
¾ Dominios: son un conjunto de
objetos, los cuales, por alguna
razón de implementación o
administrativa están separados de
otros objetos.
21
Inter-Operabilidad
¾ El
protocolo General Inter-ORB
(GIOP) satisface las necesidades
de comunicación entre ORB´s y
trabaja sobre cualquier protocolo
de transporte.
¾ La implementación del GIOP que
funciona sobre TCP/IP se
denomina Internet Inter-ORB
Protocol (IIOP)
Semánticas de Ejecución y
Modelos de interacción
¾ Semánticas:
¾ At-most-once
¾ Best
effort (oneway): no se espera
ningún resultado
¾ Modelos
de interacción:
¾ Con
la interfaz estática: Operaciones
síncronas, oneway
¾ Con la interfaz dinámica: síncrona,
síncrona diferida, oneway.
Implementaciones de ORBs
¾
Rutinas residentes en el cliente y en la
implementación de objeto.
¾
Basado en un Servidor: los clientes se
comunican con uno o mas procesos
servidores que enrutan los
requerimientos hacia las
implementaciones de objetos.
¾
Basado en el Sistema: el ORB es un
servicio del sistema operativo.
22
CORBA
„
„
„
„
Ejemplo del uso de comunicación de objetos
usando CORBA, con la implementación
JAVAORB.
Principales componenetes de la arquitectura:
Cliente, ORBs, Adaptador de Objetos, Servant,
Servidor de Nombres.
Los objetos que se comunican están
programados en JAVA.
Archivo
Bibliografía
„
„
„
CORBA: A Platform for Distributed Object
Computing. Zhonghua Yang and Keith Duddy.
Objet Interconnections. Object adapters:
Concepts and Terminology. Douglas Schmidt
and Steve Vinosky. SIGS C++ Report magazine
1997.
Sistemas Distribuidos Conceptos y Diseño.
Coulouris, Dollimore and Kindberg. Tercera
Edición. Addison Wesley.
Bibliografía
„
Java Programming with CORBA.
Advanced Techniques for Building
Distributed Applications. G. Brose, A.
Vogel, K. Duddy.
23