Sistemas basados en Objetos distribuidos.
Anuncio
Sistemas Basados en Objetos
Distribuidos
CORBA: Un caso de Estudio
Prof. Mariela Curiel
Sept-Dic 2009
Basado en el Capítulo del mismo nombre
de Tanenbaum y Van Steen.
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 (RPC)
Invocación a un método remoto
(RMI)
Modelo de programación basado
en eventos (Ejem. Java Beans)
1
Programa Distribuido (RPC)
Computador1
main
Computador2
Comp. local
Comp. remoto
Cliente
Funciones del
Servidor
func(void ){
func()
}
proc1
proc2
proc3
proc5
proc4
Thread de ejecución
Thread bloqueado
Llamada a proc.
remota
Proceso en el Servidor
Proceso en el Cliente
Cliente
Funciones del Serv.
retorno
llamada
Remota
Llamada
y retorno lógico
Retorno
Marshaled
Req.
Marshaled
Servicios de
red
retorno
llamada
Stub del Servidor
Stub del Cliente
Req.
Marshaled
Red
kernel del cliente
Retorno
Marshaled
Servicios de
red
Kernel del servidor
Proceso en el Servidor
Proceso en el Cliente
Funciones del Serv.
Cliente
llamada
Remota
retorno
Infaz. servidor
Stub del Cliente
Comm. servidor
Comm. Cliente
Req.
Marshaled
Req.
Marshaled
Retorno
Marshaled
RPC
Servicios de
red
kernel del cliente
retorno
llamada
Infaz. cliente
Retorno
Marshaled
Servicios de
red
Kernel del servidor
2
Qué deseamos hacer con objetos
remotos?
Servidor
Cliente
Result = Obj.method1(val1)
Def Obj {
int method1(int v)
{}
string method2(string v)
{}
int
method3(int v)
{}
int
method4(int v)
{}
}
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
(estado) y un conjunto de métodos.
Los métodos se ponen a disposición mediante una
interfaz. Dada una definición de interfaz, puede
haber varios objetos que ofrezcan una forma de
implementarla.
Esta separación entre interfaces y objetos que las
implementan es crucial en los SD. Se pudieran
colocar las interfaces en una máquina, mientras
que el objeto reside en otra.
Objectos Distribuidos
Figure 10-1. Common organization of a
remote object with client-side proxy.
3
Objetos Distribuidos
El estado de un objeto distribuido
reside en una sola máquina,
solamente las interfaces están
disponibles en varias máquinas.
Estos objetos también se conocen
como objetos remotos.
Modelo de Objetos
Distribuidos
La interfaz define las firmas o
signatures de los métodos (tipos de
sus argumentos, valores devueltos y
excepciones) sin especificar su
implementación.
Modelo de Objetos
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.
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
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.
5
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.
Objetos Distribuidos
Objetos a tiempo de ejecución vs objetos a
tiempo de compilación
Objetos a tiempo de compilación: son objetos
soportados por el lenguaje de programación
(C++, Java, etc). En este caso el objeto se
define como una instancia de una clase.
Una clase es una descripción de un tipo
abstracto de datos.
Objetos Distribuidos
Objetos a tiempo de compilación: Un
objeto se define mediante su clase y
las interfaces que implementa. Las
interfaces pueden compilarse en
resguardos del lado del cliente y del
servidor, lo cual permite la invocación
remota de objetos. Desventaja:
dependencia de un lenguaje de
programación.
6
Modelo de Objetos Distribuidos
Tiempo de compilación vs tiempo de
ejecución
{
{
{
Otra forma de construir objetos es hacerlo a
tiempo de ejecución. Se puede implementar de
cualquier forma.
Puede ser una librería de funciones en C que
acceden a un archivo de datos, pero cómo hago
que parezcan métodos de un objeto???
Uso un adaptador de objetos, es como una
envoltura sobre la implementación para darle
forma de objeto. El adaptador “se comunica”
con la librería de C y abre un archivo de datos
que representa el estado actual del objeto.
Objetos Distribuidos
Este método se sigue en muchos
sistemas distribuidos basados en
Objetos (Corba). Es independiente del
lenguaje de programación en el que
están escritas las aplicaciones
distribuidas. Los objetos pueden
escribirse en varios lenguajes.
Objetos Distribuidos
Los objetos deben registrarse con el
adaptador quién posteriormente hace
que la interfaz esté disponible para
invocaciones remotas.
7
Objetos Distribuidos
Objetos Persistentes y Transistorios
Objetos Persistentes: continúan
existiendo aun cuando ya no esté
contenido en el espacio de direcciones
de cualquier proceso servidor. El
servidor puede almacenar el objeto en
memoria secundaria y después
terminar.
Objetos Distribuidos
Objetos Transistorios: un OT existe sólo
en tanto el servidor que lo está
alojando exista.
Procesos: Servidores de Objetos.
Modelo de Objetos
Distribuidos
Un servidor de objetos es un servidor
diseñado para soportar objetos distribuidos.
La diferencia más importante entre un
servidor general y un servidor de objetos, es
que un servidor de objetos no proporciona
por sí mismo un servicio específico.
Los servicios son implementados por los
objetos que existen en el servidor. Al
cambiar los objetos cambian los servicios.
8
Modelo de Objetos
Distribuidos
Cada proceso servidor 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
B
A
D
E
Objeto Remoto
Objeto Remoto
Modelo de Objetos Distribuidos
{
{
Un servidor puede tener un solo hilo de
control para atender todas las solicitudes.
Tener varios hilos de control, uno por
cada objeto que maneja. Si llega una
solicitud al método de un determinado
objeto se pasa al hilo correspondiente, si
está ocupado, se encola la solicitud. Los
objetos quedan protegidos contra acceso
concurrente, las invocaciones se
serializan a través del hilo
correspondiente.
Servidores de Objetos:
Políticas
Objetos Transitorios:
{
{
Crearlo a la primera solicitud de
invocación y destruirlo en cuanto ya
ningún cliente esté ligado a tal objeto.
Crear todos los objetos transitorios en el
momento en el que el servidor se
inicializa (nungún cliente pudiera utilizar
el objeto).
9
Servidores de Objetos:
Políticas
Colocación de los Objetos en la Memoria:
{
{
Cada objeto tiene su propio espacio de
direcciones, los objetos no comparten el código
ni los datos (útil cuando los objetos tienen que
separarse por razones de seguridad).
Permitir que los objetos compartan el código.
Una BD que contiene objetos pertenecientes a
la misma clase puede ser implementada
eficientemente si la clase se carga sólo una vez
en el servidor. Cuando llega una solicitud de
invocación, el servidor sólo necesita buscar el
estado del objeto.
Servidores de Objetos:
Políticas
Hilos:
{
{
Implementar el servidor con un solo hilo
de control.
Tener varios hilos, uno por cada objeto.
Los objetos quedan protegidos
automáticamente contra acceso
concurrente.
Servidores de Objetos: Políticas
Servidores
{
{
También es posible utilizar un hilo por
cada solicitud de invocación. En este
caso los objetos deben estar protegidos
para el acceso concurrente.
Crear hilos por demanda o tener un
conjunto fijo de hilos.
10
Adaptador de Objetos
Las políticas anteriores se conocen
como políticas de activación, para
enfatizar que la mayoría de las veces
el objeto debe ser llevado primero al
espacio de direcciones del servidor
(activado) antes de que puedan
invocarse sus métodos.
Adaptador de Objetos
Se requiere entonces un mecanismo para
agrupar objetos por política de activación.
Tal mecanismo es lo que se conoce como
adaptador de objetos.
El adaptador es un software que
implementa una política de activación
específica.
Un adaptador controla uno o más objetos
Adaptador de Objetos
Varios adaptadores de objetos pueden
residir en un servidor al mismo tiempo.
El adaptador de objeto no tiene
conocimiento de las interfaces específicas
de los objetos que controlan (si así fuera no
podrían ser genéricos).
Un adaptador de objetos extrae una
referencia a objeto de una solicitud de
invocación y posteriormente despacha la
solicitud al objeto referido.
11
Adaptador de Objetos
En lugar de pasar la solucitud
directamente al objeto la pasa al
resguardo del lado del servidor.
Sirviente: es el término usado para la
implementación del objeto
Server with three objects
Server machine
Object's stub
(skeleton)
Object adapter
Object adapter
Request
demultiplexer
Local OS
Comunicación
Vinculación de un Cliente a un Objeto.
- Los sistemas RPC tradicionales que
soportan objetos distribuidos
proporcionan referencias a objetos a
través de todo el sistema.
- Las referencias pueden pasarse como
parámetros de invocaciones remotas o
ser valores de retorno.
12
Comunicación
Vinculación de un Cliente a un Objeto.
Cuando un proceso tiene una referencia a
un objeto, primero debe vincular al objeto
referido antes de invocar a cualquiera de
sus métodos. La vinculación hace que se
coloque un proxy en el espacio de
direcciones del proceso, y así se
implementa una interfaz que contiene los
métodos que se pueden invocar. La
vinculación también se puede hacer
automáticamente.
Comunicación
Vinculación de un Cliente a un Objeto.
Vinculación Implícita: al cliente se le ofrece
un mecanismo simple que le permite
invocar directamente los métodos utilizando
sólo la referencia a objeto. C++ se
sobrecarga el operador -> y se utilizan
referencias a objetos como si fueran
apuntadores ordinarios. El cliente se vincula
automáticamente al objeto.
Comunicación
Vinculación de un Cliente a un Objeto.
Vinculación Explícita: el cliente debe
invocar una función especial para
ligarse al objeto antes de que pueda
invocar sus métodos. La vinculación
explícita regresa un apuntador a un
proxy que luego llega a estar
localmente disponible.
13
Distr_object obj_ref; // Referencia a objeto distribuido, abarca todo el sistema
obj_ref = ....; // Inicializar una referencia a un objeto distribuido
obj_ref->do_somthing(); // Vincular e invocar implícitamente un métodoEjemplo de Vinculación Implícita.
Distr_object obj_ref; // Referencia a objeto distribuido, abarca todo el sistema
Local_object* obj_ptr; // Apuntador a objetos locales.
obj_ref = ....; // Inicializar una referencia a un objeto distribuido
obj_ptr = bind(obj_ref); // Vinculación explícita.
obj_ptr->do_something() // Invocar el método en el proxy local
Ejemplo de Vinculación Explícita
Comunicación
Invocaciones a Métodos Remotos:
Estáticas Vs. Dinámicas.
-
-
try {
Invocaciones Estáticas:
Calculator c = (Calculator)
Invocar al objeto usando las
definiciones que se ofrecen en Naming.lookup( "rmi://remotehost
la interfaz. Se requiere que se /CalculatorService");
System.out.println( c.sub(4, 3) );
conozcan las interfaces de los
System.out.println( c.add(4, 5) );
objetos, cuando la aplicación
del cliente se está
desarrollando.
Si cambian las interfaces, la
aplicación tiene que
recompilarse.
Comunicación
Invocaciones a Métodos Remotos:
Estáticas Vs. Dinámicas.
- Invocaciones Dinámicas: Se puede
componer la invocación a un método a
tiempo de ejecución. La diferencia es
que la aplicación selecciona, a tiempo
de ejecución, qué método invocará de
un objeto remoto.
14
Comunicación
Invocaciones a Métodos Remotos:
Estáticas Vs. Dinámicas.
Una invocación dinámica adopta la
siguiente forma:
Invoke(object, object_method, input.parameters, out_put.parameters)
Comunicación
Invocaciones a Métodos Remotos:
Estáticas Vs. Dinámicas.
Estática:
fobject.append(int)
Dinámica:
invoke(fobject, id(append), int)
Pase de Parámetros
Sistema donde sólo existen objetos
distribuidos (presentan una interfaz remota).
En este caso se pueden utilizar
consistentemente las referencias a los
objetos comó parámetros de invocaciones
remotas. Las referencias son pasadas por
valor y por lo tanto copiadas de una
máquina a otra. Cuando un proceso recibe
una referencia a objeto, se vincula a él y lo
utiliza.
15
Pase de Parámetros
Sistemas dende existen objetos locales y remotos
Las referencias a objetos remotos y las referencias
a objetos locales a menudo se tratan de forma
distinta.
{
{
Si se invoca a un método con una referencia a
objeto como parámetro, dicha referencia se copia y
pasa como un parámetro por valor sólo cuando se
refiere a un objeto remoto.
Cuando dicha referencia se refiere a un objeto local
(un objeto situado en el mismo espacio de
direcciones del cliente) el objeto referido se copia en
su totalidad y se pasa junto con la invocación.
Machine A
Local
reference L1
Client code with
RMI to server at C
(proxy)
Machine B
Local object
O1
Remote
reference R1
New local
reference
Remote object
O2
Copy of O1
Remote
invocation with
L1 and R1 as
parameters
Copy of R1 to O2
Machine C
Server code
(method implementation)
Comunicación Síncrona y
Asíncrona
Una invocación de método asíncrona
es análoga a un RPC asíncrono: el
invocador continua después de
realizar la invocación sin esperar el
resultado. CORBA ofrece
comunicación asíncrona a través del
modelo de llamada automática.
16
Comunicación Síncrona y
Asíncrona
Un cliente proporciona un objeto que
implementa una interfaz que contiene métodos
de llamada automática. Estos métodos pueden
ser invocados por el sistema de comunicación
subyacente para pasar el resultados de una
invocación asíncrona.
Las invocaciones asíncronas no afectan no
afectan la implementación del objeto, en otras
palabras es responsabilidad del cliente el
transformar una invocación síncrona original en
una invocación asíncrona.
Comunicación Síncrona y
Asíncrona
Cómo se implementa:
{
{
{
la interfaz original, tal y como la implementa el objeto
se reemplaza por dos nuevas interfaces que deben
ser implementadas únicamente por el software del
lado del cliente.
Una interfaz contiene el/los métodos que el cliente
invoca. Ninguno de estos métodos regresa ningún
valor.
La segunda interfaz es la automática y para cada
operación de la interfaz anterior contiene un método
que será invocado por el sistema subyacente para
pasar al cliente los resultados de la invocación del
método.
Comunicación Síncrona y
Asíncrona
Ejemplo:
int add (in int i, in int j, out int k)
Método que ofrece
el objeto en el servidor
void sendcb_add(in int i, in int j) // LLamada realizada por el cliente
void replycb_add(in int ret_val, in int k) // Upcall al cliente
17
Comunicación Síncrona y
Asíncrona
Posteriormente se compilan las
intefaces generadas. Al cliente se le
ofrece un resguardo que le permite
invocar sendcb_add.
El cliente debe proporcionar una
implementación para la interfaz de
llamada automática replycb_add.
Client application
1. Call by the
application
Client
proxy
Callback
interface
4. Call by the RTS
3. Response from server
Client
RTS
2. Request to server
Comunicación Síncrona y
Asíncrona
Como alternativa de las llamadas
automáticas, CORPA ofrece un
modelo encuestador. En éste se le
ofrece al cliente un conjunto de
operaciones útiles para “interrogar” a
su sistema a tiempo de ejecución
(RTS) local sobre los resultados
entrantes de una invocación previa.
18
Comunicación Síncrona y
Asíncrona
Ejemplo:
int add (in int i, in int j, out int k)
void sendcb_add(in int i, in int j) // LLamada realizada por el cliente
void replypoll_add(out int ret_val, out int k) // También invocado por
el cliente
Comunicación Síncrona y
Asíncrona
El método replypoll_add tendrá que
ser implementado por el RTS
Client application
1. Call by the
application
4. Call by the
application
Client
proxy
Polling
interface
3. Response from server
Client
RTS
2. Request to server
Sincronización
En sistemas orientados por objetos,
los detalles de implementación se
encuentran ocultos detrás de las
interfaces.
Cuando un proceso invoca a un objeto
remoto, no sabe si dicha invocación
conducirá a la invocación de otros
objetos.
19
Sincronización
Si uno de esos objetos está protegido
contra accesos concurrentes puede ser que
tenga un conjunto de locks de los que el
proceso invocador no esté al tanto.
Por el contrario, cuando se trata de un
proceso solicitando recursos, el proceso
puede ejercer más control en tiempo de
ejecución cuando las cosas van mal, tal
como renunciar a los candados (si las
llamadas se lo permiten)
Object
Object
Lock
Process
Process
Unlock
(a)
(b)
Sincronización
En SD basados en Objetos es
importante saber dónde ocurre la
sincronización.
Una ubicación evidente para la
sincronización es en el servidor. Si llegan
varias solicitudes en serie para el mismo
objeto, el servidor puede decidir ponerlas
en serie (pudiera hacerlo a través de
hilos)
20
Sincronización
También se pudiera hacer el bloqueo del
lado del cliente utilizando soporte del
lenguaje.
Se bloquea al llamador en el cliente si está
invocando un método “sincronizado”.
Se tienen que sincronizar otros clientes en
otras máquinas que estén accediendo al
mismo método. La sincronización distribuida
puede ser bastante compleja.
Consistencia y Replicación
Existen 2 temas a resolver para
implementar la consistencia :
{
{
Se requiere una forma de evitar el acceso
concurrente de varias invocaciones al
mismo objeto. Es decir, si se está
ejecutando un método, ningún otro método
dentro del mismo objeto puede estarse
ejecutando.
Este requerimiento garantiza la serialización
de los datos internos del objeto.
Consistencia y Replicación
Existen 2 temas a resolver para
implementar la consistencia :
{
En el caso de que un objeto esté replicado,
se debe garantizar que los cambios del
estado del objeto replicado sean los
mismos. Es decir, debemos garantizar que
no ocurran dos invocaciones independientes
a un método en diferentes réplicas al mismo
tiempo.
21
Consistencia y Replicación
Existen 2 temas a resolver para
implementar la consistencia :
{
{
Se tienen que ordenar las invocaciones a
métodos de tal forma que todas las réplicas
vean las invocaciones en el mismo orden.
Este requerimiento se satisface de dos formas:
1. Utilizando el método basado en réplicas
primarias
2. Mediante multitransmisión en orden total para
las réplicas.
Casos de Estudio
Enterprise Java Beans
Un EJB es un objeto Java alojado en
un servidor especial que ofrece
diferentes formas para que los clientes
remotos lo invoquen.
El servidor puede separar la
funcionalidad orientada a la aplicación
de la funcionalidad orientada al
sistema.
22
Container
EJB
EJBEJB
Server
RMI
JDBC
JNDI
JMS
Services
Server kernel
Local OS
Network
EJB
{
División de Trabajo: La posibilidad de dividir
"Servicios"(EJB Container) de "Componentes
Principales"(EJB'S) permite una clara división
de trabajo, esto es, un diseñador de
"componentes"(EJB's) puede concentrar sus
esfuerzos en la "lógica de proceso" sin
preocuparse del diseño de servicios. Y de la
misma manera un "diseñador" de
servicios("Middleware") concentrarse en su
área.
EJB
Los servicios típicos incluyen aquellos
necesarios para la invocación de
métodos remotos (RMI), el acceso a
BD (JDBC), la asignación de nombres
(JNDI) y la mensajería (JMS).
23
EJB
Se distinguen 4 clases de EJB:
1. Beans de sesión sin estado.
2. Beans de sesión con estado
3. Beans de entidad
4. Beans dirigidos por mensajes
EJB
Beans de sesión sin estado: es un objeto
transitorio que se invoca una vez,
realiza su trabajo, tras de lo cual
desecha cualquier información
utilizada para realizar el servicio que
ofrecía al cliente.
EJB
Beans de sesión con estado: matiene el
estado relacionado con el cliente.
Por ser un bean de sesión, cuando el
cliente termina (posiblemente
después de haber invocado al objeto
varias veces) el bean se destruye.
24
EJB
Beans de Entidad: es un objeto
persistente de larga duración. Se
guarda en una BD y normalmente
forma parte de transacciones
distribuidas. Típicamente guardan
información que puede necesitarse la
próxima vez que el cliente acceda al
servidor (datos de un cliente:
domicilio, tarjeta de crédito, etc).
EJB
Beans dirigidos por mensajes: se utilizan
para programar objetos que deberán
reaccionar a los mensajes que llegan.
También son capaces de enviar
mensajes. Modelo publicaciónsuscripción.
Globe
Es un sistema en el cual la escalabilidad
desempeña un rol central. Metas: soporte a
múltiples usuarios, funcionar en una red de área
amplia.
Al igual que otros sistemas orientados por objetos,
en Globe se espera que los objetos encapsulen
estado y operaciones incluidas en el estado.
Pero..cada objeto determina cómo se distribuirá el
estado entre sus réplicas. Cuándo y donde debe
replicarse el estado. Un objeto puede además
determinar su política de seguridad.
25
Globe: Modelo de Objetos
A diferencia de la mayoría de los SD
basados en objetos, no se adopta el modelo
de objeto remoto.
Los objetos pueden estar físicamente
distribuidos, ello implica que el estado de un
objeto puede distribuirse y replicarse a
través de múltiples procesos. Modelo de
objetos compartidos-distribuidos.
Globe
Distributed shared object
Local object
Process
Network
Interface
Globe
A un objeto que está ligado a un
objeto compartido-distribuido se le
ofrece una implementación local de la
interfaz que provee dicho objeto
26
Same interface as implemented
by semantics subobject
Control
subobject
Replication
subobject
Semantics
subobject
Communication
subobject
Communication
with other local
objects
Organización de un Objeto
Local
Subobjeto Semántica: implementa la
funcionalidad provista por un objeto
compartido distribuido. Corresponde a
objetos remotos ordinarios, es similar a los
EJB.
Subobjeto comunicación: Provee una
interfaz a la red subyacente. Ofrece varios
primitivas de traspaso de comunicación.
Existen subojetos de comunicación
avanzados que implementan interfaces de
multitransmisión.
Organización de un Objeto
Local
Subobjeto replicación: implementa la
estrategia de distribución para un
objeto. Garantiza que todas las
invocaciones a un método sean
realizadas en el mismo orden en cada
réplica.
Subobjeto Control: exporta las
interfaces del subobjeto semántica.
Coordina las llamadas al sub-objeto
semántica y al sub-objeto replicación.
27
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,
Hewlett-Packard, Philips
Telecommunications N.V., Sun
Microsystems y Unisys Corporation.
¾
Actualmente hay más de 500 miembros
28
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 alto nivel de abstracción
las “facilidades” necesarias para el
desarrollo de aplicaciones
distribuidas orientadas por objetos.
Object Management Architecture
(OMA)
• Posee 4 componentes:
Common
Facilities
Application
Interfaces
Object Request Broker (ORB)
Object Services
29
Object Management Architecture (OMA)
¾
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 object request broker architecture)
Common
Facilities
Application
Interfaces
Object Request Broker (ORB)
Object Services
Object Management Architecture (OMA)
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.
Object Management Architecture (OMA)
¾
Object Services: definen un conjunto de objetos
que implementan servicios fundamentales de bajo
nivel como servicio de nombres, seguridad,
persistencia, ejecución concurrente y transacciones,
etc. Permiten a los desarrolladores construir
aplicaciones sin tener que reinventar la rueda.
Common
Facilities
Application
Interfaces
Object Request Broquer (ORB)
Object Services
30
Object Management Architecture (OMA)
¾ Common Facilities (CF): son servicios
de más alto nivel orientados a las
aplicaciones (accounting, intercambio de
información entre aplicaciones, correo
electrónico o facilidades para imprimir).
¾ Application Interfaces: interfaces
desarrolladas para aplicaciones en
particular. Estos objetos hacen uso del
resto de los componentes. OMG
probablemente no llegue a desarrollar
estándares de este tipo.
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 reciba 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.
31
Corba IDL
IDL: Interface Definition Language
La interfaz especifica un nombre y un conjunto de
métodos que podrán utilizar los clientes.
¾
¾
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
interface Forma {
struct Rectangulo {
long ancho;
long alto;
long x;
long y;
};
struct ObjetoGrafico{
string tipo;
Rectangle enmarcado;
boolean estaRelleno;
};
referencia a objeto
CORBA
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
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.
32
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};
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
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.
33
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
IMPLEMENTATION
REPOSITORY
SERVANTS
IDL
STUBS
ORB
INTERFACE
IDL
SKELETON
DSI
OBJECT ADAPTER
ORB CORE
GIOP/IIOP
Client
REQUEST
DII
IDL Stub
ORB Core
¾IDL
Stubs (resguardos o proxies):
Funciones generadas desde la interfaz IDL (mediante un
compilador de IDL) para “enlazarlas” a los clientes, en el lenguaje del
cliente. Empaqueta los argumentos y desempaqueta las respuestas.
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, get_response, etc.
El cliente especifica el objeto, la operación y los parámetros. Se
obtienen a través del repositorio de interfaz (se tiene que poseer la
referencia al objeto)
34
Enfoque CORBA
¾IDL
Skeleton (Esqueletos):
Funciones generadas desde la interfaz IDL para “enlazarlas” a
las implementaciones de objetos. Se generan mediante un compilado
de IDL. Desempaqueta argumentos y empaqueta las respuestas y
excepciones.
¾Dynamic Skeleton Interface (DSI)
Análogo al DII del lado de la implementación de objetos.
Inspecciona la petición para descubrir el objeto destino, el método
Servant
que se invoca y los argumentos.
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
Operaciones que permiten su arranque
y parada
Operaciones para convertir referencias
a objetos remotos en cadenas de texto
y viceversa.
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
35
Repositorio de Implementaciones
(Implementation Repository):
Contiene información que permite al ORB
localizar y activar implementaciones de
objetos
Un IR almacena la correspondencia de los
nombres de ciertos adaptadores de objeto
con las rutas de los archivos que contienen
las implementaciones de los objetos.
Los objetos se registran en este repositorio
cuando se instalan los servidores.
Entrada en el repositorio de implementación:
Nombre
del Adaptador de
Objetos
¾
Ruta de implemtación
del objeto
host y
número de puerto
Repositorio de Interfaces (Interface
Repository):
Su información permite que un programa
encuentre un objeto cuya interfaz no conoce en
tiempo de compilación.
Para una interfaz puede aportar los nombres de
los métodos, y para cada método los nombres y
tipos de argumentos y las excepciones.
Las aplicaciones que utilicen la invocación estática
con resguardos en el cliente y esqueletos en el
servidor no necesitan repositorio de interfaz.
No todos los ORBs proporcionan repositorio de
interfaz.
Enfoque CORBA
ADAPTADOR DE
OBJETOS
Servant
IDL Sk
ORB
Interface
DSI
Object Adapter
ORB Core
36
Funciones de un Adaptador de Objetos
Genera referencias a objetos que se
registran en CORBA. IOR (Interoperate
object reference)
Da 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.
Despacha cada RMI vía un esqueleto hacia
el sirviente apropiado (implementación del
objeto)
Activación/Desactivación de sirvientes
utilizando el repositorio de implementación
Funciones de un Adaptador de
Objetos
El ORB y el OA cooperan para permitir que
las aplicaciones cliente 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.
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.)
37
Object Adapter
Figure 10-5.
Organization of
an object server
supporting
different OAs
Estructura de un Adaptador de Objetos
¾
Adaptadores de Objetos adoptados
por el estándar CORBA:
Basic Object Adapter (BOA)
Portable Object Adapter (POA)
Referencia a un objeto remoto
Una referencia es un identificador de
objeto que puede usarse en todo el
sistema distribuido y se refiere a un
objeto único.
38
Referencia a Objetos
Un objeto CORBA puede identificarse, localizarse y direccionarse
por su referencia a objeto.
Nombre de tipo
de Interfaz IDL
Identificador
de repositorio
de interfaz
Protocolo y dirección
detallada
Nombre de
IIOP Dominio
del host
Número
de puerto
Clave del
Objeto
Nombre del Nombre o
adaptador
ID del objeto
Referencia a Objetos
Las referencias pueden pasarse
libremente entre los objetos de
diferentes máquinas (como
parámetros o valores de retorno)
La referencia a un objeto debe
contener suficiente información como
para permitir que un cliente se vincule
a un objeto.
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)
Se unifica la definición de
referencias.
39
Implementaciones de ORBs
¾
Residente en el cliente y en la
implementación de objeto
¾
Basado en un Servidor
¾
Basado en el Sistema
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
Con la interfaz dinámica: síncrona,
síncrona diferida, oneway.
Servicios de CORBA
Ciclo de vida de los objetos
Manejo de nombres
Persistencia
Notificación de eventos
Concurrencia y transacciones: lleva a
cabo un protocolo de consumación de
dos fases. Se emplean bloqueos para
controlar accesos concurrentes a los
objetos CORBA.
Seguridad
40
Manejo de Nombres
struct NameComponent {string id, string clase};
typedef sequence <NameComponent> Name;
Interface NamingContext {
void bind(int Name n, int Object obj);
enlaza el nombre y la referencia en el contexto propio.
Object resolve (in Name n);
busca el nombre en el contexto y devuelve su referencia a
objeto remoto.
void unbind () ;
. ....
}
Interfaz IDL NamingContext del Servicio de Nombres de Corba.
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.
41
