PDF de programación - ORBit2 como middleware para una aplicación multicapa, usando el servicio de nombres CORBA

ORBit2 como middleware para una aplicación

multicapa, usando el servicio de nombres

CORBA

Alejandro García Castro, Juan Jos é Sánchez Penas

[email protected], [email protected]

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 1/29

Objetivo

Objetivo de la charla: explicación del uso que se
está haciendo de ORBit2 en una arquitectura
cliente/servidor, sus limitaciones en la actualidad y las
soluciones que hemos implementado para
solucionarlas.

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 2/29

Estructura de la charla

1. Contextualización, el proyecto Fisterra
2. ¿Qué es CORBA?
3. Arquitectura multicapa, el proyecto Fisterra
4. ORBit2 como middleware de comunicaciones, el

servicio de nombres

5. Ejemplos de funcionamiento
6.
7. Conclusiones y trabajo futuro

Implementación de localizadores fijos en ORBit2

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 3/29

Contextualización

Necesidades para la implantación de software
libre en los escritorios de la empresa: aplicaciones
de gestión integradas con el escritorio.
Creación del proyecto Fisterra desde Igalia, año
2003.
Desarrollo del proyecto en función del interés de la
comunidad.
Elsoftware libre en la empresa, posibilidades y
problemas, un campo abierto.

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 4/29

Contextualización (II)

Arquitectura de capas (Martin Fowler, Analysis
Patterns, 1997).
Selección del entorno de desarrollo del escritorio
GNOME.
Posibilidades para integrarlo con desarrollos de
servidor:

Glib, independencia del interfaz.
Comunicaciones, integración con tecnología:
CORBA (ORBit2).
Costes de adaptación, no era el primer uso de
estas bibliotecas fuera del escritorio.
Direcciones de objetos fijas.

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 5/29

Contextualización (y III)

Principal problema encontrado en las
comunicaciones: gestión de uso de referencias a
los servicios de forma manejable.
Utilización del servicio de nombres CORBA para la
gestión de las referencias.
Durante el proyecto intentamos solucionar este
problema mediante la modificación de ORBit2.
Nuevas posibilidades en la utilización de ORBit2.

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 6/29

¿Qué es CORBA?

Estándar para la integración de componentes de
comunicaciones, creado por la OMG (1989).
Permite la comunicación de objetos en un entorno
distribuido de forma transparente: middleware
de comunicaciones.
Pensado para entornos multilenguaje.
El estándar define todas las partes de la
arquitectura, desde el protocolo hasta servicios de
apoyo básicos.

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 7/29

¿Qué es CORBA? (II)

La base de la comunicación es el ORB (Object
Request Broker), encargado de la encapsulación
de las comunicaciones.
El funcionamiento se basa en la publicación por
parte del ORB de un interfaz a los métodos de los
objetos que implementemos.
Definición de interfaces mediante la utilización de
un lenguaje especial: IDL(Interface Definition
Language)

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 8/29

¿Qué es CORBA? (III)

Compilación de estos interfaces para la
generación del código de comunicaciones.
Definición de datos y métodos utilizados, entornos
multilenguaje.
“Contenedores de objetos” : POA (Portable Object
Adapter).
Más jerga de CORBA: stubs, skeletons, servants,
POAmanager, IORs (explicación posterior), etc.
El servidor de nombres: “el DNS de CORBA”.

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 9/29

¿Qué es CORBA? (y IV)

Cliente

Servidor

servant

skel−impl

IIOP (IOR)

POA

stub

ORB

ORB

skel

POAManager

objeto cliente

delegate

ORBit2

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 10/29

Arquitectura multicapa

proyecto Fisterra.
Arquitectura de capas (Martin Fowler, 1997).
Necesidad de middleware de comunicaciones
para la transparencia en la orientación a objetos.
El contenedor de objetos como servidor,
propiedades de los objetos: comunicaciones,
gestión de la información persistencia,
transacciones, etc.
Completamente desarrollado con tecnologías
GNOME.

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 11/29

Arquitectura multicapa (II)

Cliente: es una aplicación de ventanas,
desarrollada como cualquier otra aplicación de
escritorio GNOME, que se encarga de interaccionar
con el usuario. Patrón MVC intensivo.
Servidor: está formado por componentes que
implementan las acciones necesarias para llevar a
cabo los servicios del interfaz de comunicaciones.
El contenedor de EGBs.

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 12/29

Arquitectura multicapa (y III)

cliente fisterra

servidor de base de datos

servidor fisterra

servidor LDAP

cliente fisterra

servidor nombres (CORBA)

servidor de base de datos

servidor fisterra

replicado

cliente fisterra

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 13/29

ORBit2 como middleware

Presentación acerca de ORBit2 en este sentido de
Frank Rehberger en la GUADEC 2004 (SSL).
Interés de la integración con el escritorio con un
middleware para otras soluciones.
En nuestro caso particular uso en arquitectura
multicapa.

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 14/29

ORBit2 como middleware (II)

configuración

cliente:

<URL servidor nombres>

...

cliente

fisterra

(3)

(6)

servidor

fisterra

(5)

<referencia>

servidor

sesiones

fisterra

(1)

(4)

servidor

nombres

CORBA

(7)

(8)

Objeto

sesión

base

de

datos

(2)

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 15/29

ORBit2 como middleware (III)

Para conocer las localizaciones de objetos CORBA se
utilizan los IORs (Interoperable Object References).
Se pueden convertir en cadenas de texto:

IOR:010000002b00000049444c3a6f6d672e6f7267
2f436f734e616d696e672f4e616d696e67436f6e74
6578744578743a312e300000010000000100000024
000000010000000100000001000000140000000100
000001000105000000000901010000000000

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 16/29

ORBit2 como middleware (IV)

Parte de la información que incluye el IOR en el
caso de IIOP (comunicación por TCP/IP) es:

nombre de la máquina
número de puerto
object key

La object key identifica a un objeto de forma
unívoca dentro de un ORB. Incluye información
sobre el POA en el que se ejecuta.

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 17/29

ORBit2 como middleware (V)

Las cadenas en ese formato son engorrosas, por lo
que se definen representaciones más legibles:
corbalocs:

corbaloc:iiop:1.2@localhost:4444/%00%00%00
%00%7e%c8%fc%d9%70%8a%f9%5f%88%40%10%3

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 18/29

ORBit2 como middleware (VI)

El corbaloc mantiene la object key, que incluye el
identificador del POA, por lo que sigue siendo
incomprensible.
Lo que es peor es que además es variable.
La identificación de un objeto varía cada vez que
lo levantamos.
El principal problema es que imposibilita una
configuración fija para identificar un objeto.
Aunque la mayoría de ORBs actuales incluyen una
forma de poder sustituir el corba key por una
cadena fija, ORBit2 no tiene esa posibilidad.

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 19/29

ORBit2 como middleware (VII)

Solución: Uso de un servidor de nombres.
Conversión de nombres en localizaciones
jerárquicas (directorio), en los IORs:
myorb/mysite/fisterra_service
Podemos buscar el IOR de objetos en esta
estructura.
Pero ... se pueden encontrar todos excepto el del
propio servidor de nombres que es también un
objeto, por ser el primero.

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 20/29

ORBit2 como middleware (y VIII)

La solución que implementamos para resolver este
segundo problema es añadir a ORBit2 un sistema
para poder registrar y acceder a objetos
sustituyendo el corba key por un nombre fijo.

corbaloc:iiop:1.2@localhost:4444/NameService

Parámetro de configuración para cliente y servidor.

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 21/29

Ejemplos de funcionamiento

Ejemplos de funcionamiento

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 22/29

Implementación en ORBit2

Uso del mensaje LocateReply.
Mensaje se usa como respuesta al mensaje
LocateRequest.
Se envía antes de cada conexión como mejora del
rendimiento.
El cliente pide con el localizador y se le responde
con el IOR real almacenado para ese objeto.
El protocolo es el responsable de esta nueva
petición, por lo que es totalmente transparente al
programador.

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 23/29

Implementación en ORBit2 (II)

Se incluye una nueva estructura en el ORB para
almacenar esta relación.

struct CORBA_ORB_type {

struct ORBit_RootObject_struct
...
GPtrArray

root_object;

*adaptors;

/* Esta es la tabla hash que utilizaremos */

GHashTable
GSList
GHashTable
...

*forw_binds;
*current_invocations;
*initial_refs;

ORBit2 como middleware para una aplicaci ón multicapa, usando el servicio de nombres CORBA– p. 24/29

Implementación en ORBit2 (III)

Comprobación de la tabla hash para las peticiones.

..