PDF de programación - Tecnologías de Objetos Distribuidos Servicios CORBA

Sistemas de Información

Tecnologías de Objetos Distribuidos
Servicios CORBA

Agradecimientos: esta presentación se basa parcialmente en una presentación de Juan Pavón Mestras de la UCM y en
una de Jesus Villamor Lugo de IT/UCIIIM, la última basada a su vez en una presentación de Juan José Gil Ríos de Terra

1

Objetivos de OMA

Interfaces estándar que permiten extensibilidad del software

Transición tecnológica gradual

Productividad mejorada debido a la inter-operabilidad del

softwareen redes heterogéneas

Interfaces de usuario intuitivas

Uniformidad y consistencia sobre diferentes e

independientes aplicaciones (gracias a los
estándares)

OMA ofrece a usuarios y desarrolladores, la filosofía
de inter-operabilidad de sistemas software distribuidos,
a través de la mayor cantidad de hardware, sistemas
operativos y lenguajes de programación

2

Un breve repaso de OMA

NonNon--standardized
standardized

appapp--specific
specific
interfaces
interfaces

Application objects
objects
Application

Application
Application

domain--specific
specific
domain

interfaces
interfaces

Common facility
facility
Common

interfaces
interfaces

Vertical Facilities
Facilities
Vertical

Horizontal Facilities
Facilities
Horizontal

Object Request
Object

Request Broker
Broker

Object Services
Services
Object

General service
General

service interfaces
interfaces

3

COSS I

Cuatro servicios iniciales:

Object
Object
Services
Services

•

•

•

•

Nombrado (Naming): correspondencia entre nombres convenientes
de objetos y referencias a objetos reales.
Ciclo de Vida (ObjectLifeCycle): creación, borrado, copiado y
traslado de objetos.
Eventos (Event): registro para la notificación requerida y esperada
de la ocurrencia de eventos. Extensión: Notificación (Notification).
Estado persistente (PersistentState) , antes Objeto Persistente
(PersistentObject): existencia a largo plazo de objetos, gestión del
almacenamiento de objetos.

publicadas por OMG/Wiley como COSS Volumen I en 1994

4

COSS II

Cuatro servicios más:

Object
Object
Services
Services

•

•

•

•

Relación (Relationship): gestión de representación y consistencia
de relaciones entre objetos.
Externalización (Externalization): capacidad para almacenar la
representación de objetos en medios removibles y permitir más
adelante la re-internalización.
Transacciones (Transaction): combina el paradigma de
transacciones y el de objetos para tratar los problemas del
procesamiento de transacciones comercial.
Control de Concurrencia (ConcurrencyControl ): gestión de la
ejecución concurrente en un entorno distribuido.

publicadas como CORBAServices en 1995.

5

COSS III y COSS IV

Object
Object
Services
Services

•

•

•

•
•

•

•

Consulta (Query): permite a usuarios y objetos invocar consultas en
colecciones de otros objetos (1995).
Propiedades (Property): define operaciones para crear y manipular
conjuntos de propiedades (parejas nombre-valor) asociadas a objetos
(1995)
Licencia (Licencing): mecanismos para que los productores controlen
el uso de su propiedad intelectual (1995).
Seguridad (Security): identificación, autenticación, etc. (1996).
Tiempo (Time): hora y temporizadores (1996) Extensión: Visión
Realzada del Tiempo (EnhancedViewofTime).
Negociación (Trading): localización de objetos (paginas amarillas)
suministrando información del servicio requerido (1996).
…

6

Servicios CORBA
Servicios bien conocidos

El ORB está configurado para dar las referencias de los
servicios básicos, los servicios CORBA “bien conocidos”:
Servicio de Nombres (“NameService”)
Servicio de Trader (“TradingService”)
Repositorio de Interfaces (“InterfaceRepository”)

Para obtener la referencia a uno de estos servicios (por

ejemplo el Servicio de Nombres):
org.omg.CORBA.Object objeto =
NamingContext ns = NamingContextHelper.narrow(objeto);

orb.resolve_initial_references(“NameService”);

7

Servicio de Nombrado

Concepto básico

Cada objeto tiene un único ID (o referencia)
Opcionalmente se pueden asociar uno o más nombres a

una referencia

Siempre se puede definir un nombre relativo a su

contexto

Servicio de Páginas Blancas

Encapsula el nombre en directorios tales como DCE

CDS, ISO X.500 o SUN NIS+

La idea es no reinventar la rueda
La jerarquía de nombres no necesita un root universal
8

COSNaming
Uso del servicio
El Servicio de Nombres guarda pares

<nombre, referencia a objeto>
Los nombres están organizados en una jerarquía

El Servicio de Nombres es usado por cliente y servidor:

El servidor asocia (bind) en el Servicio de Nombres una referencia a

El cliente puede pedirle al Servicio de Nombres que a partir de un

objeto con un nombre
nombre le dé (resolve) una referencia a un objeto CORBA

Servicio de Nombres

Servidor

bind(A, ref)

A

jerarquía de

nombres

resolve(A)

cliente

ref

proxyA

9

COSNaming
Jerarquía de nombres

Los nombres están organizados jerárquicamente

Ejemplos de jerarquías: sistema de ficheros, direcciones y dominios en

Internet, etc.

Un nodo en la jerarquía puede ser:

Un contexto de nombres

o define un espacio de nombres

Un nombre (necesariamente nodo hoja)

o puede tener asociado una

referencia a un objeto

Hyatt

Un objeto puede tener asociados

varios nombres

La organización de la jerarquía

de nombres es flexible

Directorio Global
Recursos

Hawaii

Méjico

Grecia

Directorio ClubMed

ClubMed

Ixtapa

Playa Blanca

Cancún

o para adaptar otros servicios de directorio fácilmente (por ejemplo, DCS CDS,

ISO X.500, Sun NIS+, Internet LDAP)

10

COSNaming
Nombres
Cada Name está formado por varios NameComponent
Cada NameComponent es un par: <identificador, clase>

typedef string Istring;
typedef string Istring;
typedef sequence<NameComponent> Name;
typedef sequence<NameComponent> Name;
struct NameComponent {
struct NameComponent {
id;
id;
kind;
kind;

Istring
Istring
Istring
Istring

};
};

id es el nombre que identifica el objeto NameComponent
kind cualifica id (no es obligatorio darle un valor)
Ejemplos:

(“C:”,”volumen”)(“usuario”,”dir”)(“juan”,”dir”)(“ejemplo.idl”,”archivo idl”)
(“Compañía”,””)(“Sucursal”,””)(“Madrid”,”Ciudad”)(“Director”,”cargo”)

11

COSNaming
Interfaz NamingContext

interface NamingContext {

out BindingIterator bi);

NamingContext new_context();
void destroy() raises (NotEmpty);
Object resolve (in Name n) raises (NotFound, CannotProceed, InvalidName);
void list (in unsigned long how_many, out BindingList b,
void unbind(in Name n)
void bind(in Name n, in Object obj)
void rebind(in Name n, in Object obj)
void bind_context(in Name n, in NamingContext nc)
void rebind_context(in Name n, in NamingContext nc)
void bind_new_context(in Name n)

raises (NotFound, CannotProceed, InvalidName);
raises (NotFound, CannotProceed, InvalidName, AlreadyBound);
raises (NotFound, CannotProceed, InvalidName);
raises (NotFound, CannotProceed, InvalidName, AlreadyBound);
raises (NotFound, CannotProceed, InvalidName);
raises (NotFound, CannotProceed, InvalidName, AlreadyBound);

};

12

COSNaming
Interfaz BindingIterator
La operación list() devuelve una lista de bindings:

enum BindingType { nobject, ncontext };
struct Binding {

Name binding_name;
BindingType binding_type;

};
typedef sequence<Binding> BindingList;
void list (in unsigned long how_many, out BindingList bl, out

BindingIterator bi);

La interfaz BindingIterator permite recorrer la lista de bindings:

interface BindingIterator {

boolean next_one(out Binding b);
boolean next_n(in unsigned long how_many, out BindingList bl);
void destroy();

};

13

Creación de un nombre
y asociación a un objeto

Normalmente es el servidor quien crea un nombre y le

asocia a una referencia a objeto
1) Obtiene el NamingContext raíz llamando a
2) Crea los NamingContext necesarios (si no existen) usando

resolve_initial_references(“NameService”)
bind_new_context()
bind()

3) Crea las asociaciones a las referencias a objetos usando

14

COSNaming
Excepciones
En NamingContext define las siguientes excepciones:
Algún componente del nombre especificado
no está en la jerarquía de nombres
El nombre especificado no es válido

NotFound
InvalidName
AlreadyBound El objeto ya está asociado con el nombre dado
NotEmpty
El NamingContext tiene al menos un binding

Por lo tanto el código anterior debería estar en un bloque

try...catch para tratarlas

15

Obtener el objeto
asociado a un nombre

El cliente busca un nombre y obtiene el objeto asociado

1) Obtiene el NamingContext raíz llamando a
resolve_initial_references(“NameService”)
2) Crea un Name, que puede ser compuesto por uno o más
NameComponent
3) Obtiene la referencia a un objeto invocando resolve() sobre
4) Hace narrow() de la referencia a objeto conseguida

el NamingContext raíz

16

Usando una jerarquía de nombres
Lado servidor: registrar el nombre

orb.resolve_initial_references("NameService");
orb.resolve_initial_references("NameService");

// Consigue la referencia al servicio de Nombres
// Consigue la referencia al servicio de Nombres
org.omg.CORBA.Object nsObj =
org.omg.CORBA.Object nsObj =
NamingContext ns = NamingContextHelper.narrow(nsObj);
NamingContext ns = NamingContextHelper.narrow(nsObj);
// Primer contexto: “Divisiones”
// Primer contexto: “Divisiones”
NameComponent[] divisiones = {new NameComponent(“Divisiones","");};
NameComponent[] divisiones = {new NameComponent(“Divisiones","");};
NamingContext divisionesNC = ns.bind_new_context(divisiones);
NamingContext divisionesNC = ns.bind_new_context(divisiones);
// Segundo contexto: “Ventas”
// Segund