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

Sistemas de
Información

Tecnologías de objetos distribuidos:
OMG-CORBA

Agradecimientos: Jesus Villamor Lugo, Simon Pickin de IT/UCIIIM, Juan José Gil Ríos de Terra.

[email protected]

1

Índice

¿Qué es?. Historia
¿Para qué sirve?. Objetivos
¿Cómo funciona?
¿Cómo se usa?. Ejemplos
Arquitectura OMA
Arquitectura Corba
Corba y sus competidores

[email protected]

2

CORBA
Concepto ¿Qué es?
CORBA (Common Object Request Broker Architecture).
Es una herramienta que facilita el desarrollo de

aplicaciones distribuidas en entornos heterogéneos (HW
y SW)
Distintos sistemas operativos (Unix, Windows, MacOS, OS/2)
Distintos protocolos de comunicación (TCP/IP, IPX, …)
Distintos lenguajes de programación (Java, C, C++, …)
Define la infraestructura para la arquitectura OMA

(Object Management Architecture) especificando los
entándares necesarios para la invocación de métodos
sobre objetos en entornos heterogéneos

[email protected]

3

CORBA
¿Para qué sirve?

Permitir invocación de métodos de un objeto por
objetos que residen en diferentes máquinas en
entornos heterogéneos
Los objetos pueden estar desarrollados en diferentes

Los equipos pueden tener diferente:

lenguajes.

Hardware
Sistema operativo

Los equipos pueden estar conectados entre sí usando

distintos protocolos de comunicación

Facilitar el desarrollo de aplicaciones distribuidas

[email protected]

4

CORBA
Historia. Especificaciones
OMG (Object Management Group)

consorcio creado en 1989, primer “producto”: CORBA
inicialmente 8 empresas (Sun, HP, 3Com,...)

Hoy: más de 800 socios

Proveedores de SW y equipos, operadores de telecomunicaciones,

empresas, universidades,...

http://www.omg.org/

OMA (Object Management Archictecture)

Inicial: 1990

CORBA (Common Object Request Broker Arquitecture)

CORBA 1. 1991
CORBA 2. 1995
CORBA 3. 2002

[email protected]

5

CORBA
Objetivos
Especificar un middleware para construir aplicaciones

cliente-servidor multi-nivel
distribuidos y centralizados
flexibles / extensibles

Poder con la heterogeneidad

hardware distinto
redes distintas
sistemas operativos distintos
lenguajes de programación distintos

⇒ interoperabilidad

[email protected]

6

CORBA
Otras propiedades deseadas
Transparencia de distribución

ni cliente ni servidor necesitan saber si la aplicación está distribuido

o centralizado

Transparencia de localización (caso distribuido)

el cliente no necesita saber donde ejecuta el servicio
el servicio no necesita saber donde ejecuta el cliente

Integración de software existente

amortizar inversión previa

sistemas heredados (legacy systems)

Activación de objetos

objetos remotos no tienen que estar en memoria permanentemente
se hace de manera invisible para el cliente

[email protected]

7

CORBA
Otras propiedades deseadas

Comunicación flexible

múltiples modos de comunicación

síncrona: tipo invocación de métodos / RPC
asíncrona: sin respuesta

múltiples modelos de comunicación

invocación estática
invocación dinámica

[email protected]

8

CORBA
Objetivos comerciales
CORBA 1 (1991)

llegar al mercado antes de Microsoft DCOM/COM+
competir con DCE, RPC: un éxito

CORBA 2 (1995)

interoperabilidad entre implementaciones de distintos vendedores
competir con Java RMI, COM+: un éxito

CORBA 3 (2002)

permitir desarrollo basado en componentes (CBD)
competir con EJB, .NET

¿llegó demasiado tarde?

competir con los Web Services

difícil: Web Services actualmente en auge

hasta ahora no ha tenido éxito: ¿CORBA se muere?

[email protected]

9

CORBA
Medios para alcanzar los objetivos
Orientado objetos
encapsulación
herencia
late binding & polimorfismo

Comunicación por invocación de métodos remotos
más fácil de programar que IPC, sockets, RPC, etc.
stub:

representante local del objeto remoto


encargado de la comunicación con el objeto remoto

skeleton:

encargado de la comunicación con el cliente

cliente-servidor de grano fino

interacciones son de tipo cliente-servidor
papeles: misma entidad puede actuar como cliente o servidor

[email protected]

10

CORBA
Medios para alcanzar los objetivos
Separación interfaz-implementación

la interfaz define un contrato
CORBA IDL (Interface Definition Language)
multi-lenguaje: mapeo IDL → lenguajes de programación

Referencia de objeto: identificador único de un objeto

como un puntero

puede ser nil : no apunta a ningún objeto
puede estar colgando: apunta a un objeto inalcanzable o que no existe

puede ser transient o persistent
puede convertirse entre forma interna y forma cadena
CORBA 2 IOR (Interoperable Object Reference)

para evitar conflictos entre implementaciones de diferentes vendedores

[email protected]

11

CORBA
Medios para alcanzar los objetivos
Protocolo estándar

IIOP: Internet Inter-ORB Protocol (implementación del GIOP)
Implementado encima de TCP/IP

Modos de comunicación

síncrona:

invocación de métodos remotos normal
repuesta puede ser de tipo void

asíncrona:

invocación de métodos definidos como oneway
CORBA 3: añade servicio de mensajería (patrón publisher-subscriber)

Uso de envolturas (wrappers)

permite integrar los sistemas heredados
normalmente, una sola instancia de cada clase

[email protected]

12

CORBA
Medios para alcanzar los objetivos
ORB (Object Request Broker)

núcleo de CORBA: un bus de software
oculta la heterogeneidad a las dos partes
oculta los detalles de la comunicación a las dos partes
proporciona transparencia de localización via referencias de objeto

interpreta los referencias de objeto
canaliza las invocaciones del cliente al objeto remoto correcto
canaliza las respuestas del objeto remoto al cliente

proporciona transparencia de distribución

comportamiento igual en centralizado o distribuido

se ocupa de la activación y desactivación de objetos
proporciona servicios para construir peticiones dinámicamente

[email protected]

13

CORBA
¿Cómo funciona?
El servidor

Crea objetos remotos
Hace accesibles refs a objetos remotos
Espera a que los clientes invoquen a estos

objetos remotos o a sus métodos

El cliente

Obtiene una referencia de uno o más objetos

remotos en el servidor
Invoca a sus métodos

[email protected]

14

CORBA ¿Cómo funciona?
Elementos de la arquitectura

[email protected]

15

CORBA ¿Cómo funciona?
¿Cómo se realiza la invocación?

[email protected]

16

CORBA ¿Cómo funciona?
¿Cómo se realiza la invocación?
El cliente

¿Qué necesita?

Referencia del objeto remoto IOR
Tipo del objeto
Nombre de la operación que se desea invocar

¿Cómo realiza la invocación?

Usando stub generado a partir del IDL
Usando invocación dinámica a través de DII

Tiene que gestionar las excepciones producidas por su llamada

El ORB a partir de la petición del cliente

Encuentra el código de la implementación apropiada,
Transmite los parámetros
Transfiere el control a la Implementación de la Interfaz a través de:

esqueleto IDL,
esqueleto dinámico (DII)

válidas)

Informa de excepciones en el proceso (ej referencias IOR o IDL no

[email protected]

17

CORBA ¿Cómo funciona?
¿Cómo se realiza la invocación?
Para el desarrollador es una invocación corriente
En tiempo de ejecución la invocación pasa por:

El stub del cliente
El ORB
El adaptador de objetos
Encontrar el objeto adecuado
Viajar por los skeletons del servidor
Realizar la invocación sobre el objeto
Realizar el mismo camino de vuelta

[email protected]

18

CORBA ¿Cómo funciona?
¿Cómo se recibe la petición?

[email protected]

19

CORBA ¿Cómo funciona?
¿Cómo se recibe la petición?
La implementación del objeto que proporciona el servicio

Recibe la invocación de uno de sus métodos como llamadas desde el

ORB hacia la Implementación de la Interfaz.

La llamada puede venir de un cliente :

que ha utilizado los stubs IDL,
Que ha utilizado DII

Los esqueletos de la interfaz IDL son específicos de cada interfaz y del

adaptador de objetos que exista en la implementación de CORBA.

Cuando la invocación ha sido completada, el control y los valores de

retorno son devueltos al cliente.

Puede utilizar los servicios que proporciona el adaptador de objetos e
incluso los que proporciona el ORB, mientras procesa la petición que
ha recibido del cliente

Puede elegir un Adaptador de Objetos entre un conjunto de ellos, una

decisión que estará basada en la clase de servicios que pueda requerir la
Implementación de la Interfaz

Inicialmente OMG propuso como adaptad