Tesis de grado de Ingeniería en Informática. Extensión del estándar de para proveer. implementación.

Extensión del estándar

de

para proveer

servicios de estado persistente con acceso remoto: Análisis, diseño e

implementación.

I

NFORMACIÓN DE

C

ONTACTO

P

M

I

:

@

.

.

@

.

R

Muchas de las aplicaciones distribuidas tienen requerimientos de persistencia y se encuentran desarrolladas en lenguajes de programación orientados a objetos (POO) tales como Java. Una de las arquitecturas, CORBA de OMG, define un estándar de persistencia denominado

   
 
  

  

(PSS), siendo una de sus alternativas con un lenguaje PSDL. En este trabajo se analizó el estado

del arte de la persistencia, en particular en el marco de las aplicaciones CORBA desarrolladas en lenguaje Java y la especificación del servicio PSS. Para estas aplicaciones, se diseñó y construyó un servicio de estado persistente, junto con un compilador de lenguaje PSDL. Este servicio, además de la persistencia, permite compartir objetos persistentes entre servants ubicados en distintas máquinas o procesos, característica que no está prevista en la especificación PSS de CORBA. El compilador y el servicio construidos se caracterizan por ser extensibles y configurables, soportando distintas formas de lograr persistencia. Finalmente, los resultados obtenidos fueron comparados con otros servicios PSS. Palabras clave: Persistencia, OMG, CORBA, Servicio, POO, Java, PSS, PSDL, Compilador, Servant, Conector, OODB

A

A large number of distributed applications require persistence. Many of these applications are developed using object oriented programming languages (OOP) like Java. The OMG CORBA architecture defines the

   
    

  

(PSS) as a standard for persistence. One of the options

is using a language PSDL. In this work, the state of art of persistence was analyzed specifically in the context of CORBA applications developed in Java, altogether with the PSS specification itself. For these applications, a persistent state service with a PSDL language compiler was designed and built. The service includes in addition of persistence, the sharing of persistent objects with servants existing in different machines or processes, a feature which is not provided by the PSS specification. The built compiler and service are characterized for being extensible and configurable, supporting different ways for persisting objects. Finally, the work’s results were compared to other existing PSS services.

Keywords: Persistence, OMG, CORBA, Service, POO, Java, PSS, PSDL, Compiler, Servant, Connector, OODB

C

ONTENIDO

Introducción ... 9

Introducción a POO - Programación Orientada a Objetos ... 13

Introducción a CORBA... 21

Servicio de Estado Persistente CORBA - PSS ... 31

Implementación del servicio de estado persistente CORBA - PSS... 47

Comparación con otras implementaciones del servicio de estado persistente de

CORBA ... 121

Trabajos adicionales ... 131

Índice de Gráficos ... 133

I

NTRODUCCIÓN

os juegos, sistemas de bases de datos distribuidas, multimedia, aplicaciones gráficas y los sistemas distribuidos en general, almacenan información que requiere persistencia. La mayoría de los sistemas de información, requieren de algún soporte para mantener su estado en forma persistente. Persistencia en la programación orientada a objetos (POO), significa almacenar los objetos y por consiguiente el valor de sus atributos para uso futuro.

El soporte de persistencia no es trivial, ya que la representación de un objeto en memoria puede variar en tamaño y estructura de una plataforma a otra. Además, no está soportado en forma nativa por todos los lenguajes de programación (por ejemplo, C++), plataformas de desarrollo y sistemas operativos. Por consiguiente, es necesario el uso de frameworks, como por ejemplo, CORBA, para su implementación.

CORBA (Common Object Request Broker Architecture) o
   
    
            

[CR01] es la propuesta del OMG (Object Management Group) para la construcción de software interoperable, portable y reusable. OMG define una arquitectura de software detallada, que consta de interfases claramente definidas. Esta arquitectura, llamada OMA (Object Management Architecture) [OM0], está dividida en dos modelos fundamentales. El primero, llamado 

   
       (
      

), permite el desarrollo de aplicaciones distribuidas basadas en un            

u ORB (Object Request Broker). El segundo modelo, llamado        
  (   
     

), define un marco para el desarrollo de las aplicaciones junto a un conjunto de interfases estandarizadas llamadas 


       (    
 

) que utilizan la ORB.

Uno de los servicios que CORBA provee, tiene el objeto de facilitar y unificar la forma de hacer persistentes a los objetos utilizados por los servants [CRO1], por medio de una interfase común para el manejo de persistencia. Los servants son aquellos objetos que están bajo el control de la ORB. Todo servant tiene una interfase definida en lenguaje IDL (Interface Definition Language o 

                
  

y puede ser accedido en forma remota por medio de los mecanismos que la ORB provee a tal fin.

El servicio de CORBA que da soporte de persistencia de objetos se denomina: 


 !    
   (P"#$ % $&"'& S&(&" S"#) % * "

) PSS [PS0]. Este servicio no intenta ser una interfase a una base de datos orientada a objetos OODBMS (Object Oriented Database Management System), sino que provee una forma estándar de persistencia de objetos. No incluye los dos conceptos fundamentales de OODBMS como ser las transacciones y las consultas [BgVaDk]. Su fundamento, es la separación de intereses (+,- . /. 0 1 2 32 45 23 5 ,/3 +

) que está presente en la arquitectura y las especificaciones de servicios CORBA. De esta forma, si se tienen requerimientos transaccionales no serán implementados por este servicio, sino que este servicio se conectará o comunicará con el servicio de transacciones CORBA [TS01].

El modelo de trabajo que propone PSS, es similar al modelo general propuesto por CORBA. Los objetos persistidos por PSS, son denominados 2

67 ,02 + . 8 9. 5 ,3. :2 + (+02 /.; , 2 67 , 5 0+ ). Todo objeto persiste en un . 8 9. 5< 3 (+02 /. ; ,=2 9,

). Los almacenes existen en /,-2 + 1

02 / 1

2 +

. PSS provee un lenguaje para definir estos objetos y almacenes, llamado PSDL (P>?@

A @ B >C B SB D B > D> EA C ABA F C LD CG HDG > ), que es una extensión al lenguaje IDL. Los servants que utilicen PSS, pueden hacer persistentes a los objetos de dos formas: por su definición en lenguaje PSDL, o por medio de objetos comunes definidos en el lenguaje de programación que se utilice. La segunda forma de persistencia se la denomina I J

KL M L N J O P M Q N KQ O L I Q K J O N JR

En ambos casos, los objetos persistidos por los servants, son sólo conocidos por el servant que los define, y no son exportados a la ORB, lo que implica que los objetos almacenados no pueden ser accedidos en forma remota.

Para usar el lenguaje PSDL se requiere de un compilador que traduzca las definiciones PSDL en las definiciones del lenguaje de programación que se utiliza. En cambio, la persistencia transparente, permite persistir objetos directamente en el lenguaje nativo, pero a costa de perder muchas funcionalidades que solo están disponibles en las definiciones PSDL.

Si bien PSS es un estándar cuya última revisión es del año 2002, no existen muchas implementaciones del mismo, dado que no se trata de una de las especificaciones más difundidas.

El problema a resolver es: ¿Cómo hacer uso de objetos que requieran estado persistente en CORBA? Se deben analizar las soluciones existentes, viendo que alternativas son viables de construir. Las especificaciones son ambiguas en algunas definiciones, en las cuales se pierde la idea de interfase de servicio CORBA. En particular, sucede cuando se trata de soportar dos modelos de persistencia, como lo son el transparente y el de definición por PSDL, por medio de una misma interfase de servicio.

Sin embargo, la construcción de un servicio siguiendo la especificación PSS se plantea como una idea atractiva y desafiante. Es atractiva, porque permite tener una interfase o modelo estándar para solucionar este problema no trivial, lo cual es algo muy útil y valioso. Es desafiante, porque se trata de un problema complejo con muchos matices a considerar, tales como la construcción de un compilador del lenguaje PSDL, proveer persistencia transparente sin uso de un lenguaje nuevo, definir dónde y cómo almacenar el estado que define a los objetos utilizando una base de datos u otro medio, evaluar cómo se podría extender el servicio para que soporte el acceso remoto de los objetos almacenados, no contemplado en el estándar actual, etc.

O

Se realizó un estudio del estado del arte de la persistencia en objetos, focalizado principalmente en CORBA y el lenguaje de programación Java.

Se realizó un análisis de la especificación del servicio de estado persistente (PSS) CORBA, evaluando sus posibles usos, ventajas y desventajas. Se analizaron las distintas alternativas que plantea el estándar, considerando los beneficios y las desventajas de la

  
        

. Se evaluaron las

diferentes estrategias a seguir frente a ambigüedades en las definiciones. Se evaluaron las distintas herramientas que pueden utilizarse para mantener el estado persistente, y su posible uso en un servicio de persistencia.

Se diseñó y construyó un servicio de persistencia, que soporta el estándar CORBA, utilizando el lenguaje de programación Java y patrones de diseño adecuados para este fin [GA0]. Se proveyó de un mecanismo básico que permite a dos o más servants acceder en forma remota a un repositorio definido en otra máquina, pudiendo así acceder a objetos almacenados definidos por otros servants, extendiendo el servicio que propone el estándar. El servicio de persistencia que se construyó, soporta definiciones PSDL, junto con las funcionalidades que este lenguaje provee. Para ello, fue necesaria la construcción de un compilador [CooperRice00] PSDL que genera código Java que es compatible con el servicio construido. Finalmente, se realizó una comparación entre otras implementaciones del servicio de persistencia de CORBA y la construida.

E

T

1. REVISIÓN DEL MARCO TEÓRICO

Esta etapa del trabajo se focalizó en obtener un conocimiento del marco teórico necesario para la realización de este trabajo. Este marco incluye CORBA, Persistencia de Objetos Java y Servicios de CORBA.

2. ANÁLISIS

Se realizó un análisis completo de la especificación del servicio de estado persistente de CORBA. Se evaluó el aporte del servicio al desarrollo de aplicaciones CORBA, valorizando sus beneficios y desventajas. Se analizaron los requerimientos para la construcción de un servicio CORBA que cumple con este estándar y permite compartir un repositorio por más de una ORB. Se consideraron las diferentes herramientas, lenguajes de programación y

 

 

que podrían utilizarse en la construcción. Esta etapa definió los requerimientos del servicio a construir.

3. DISEÑO

En esta etapa se diseñó una solución que cumple con los requerimientos relevados durante la etapa de análisis. Esta solución incluye el diseño de un compilador de lenguaje PSDL a Java, y varios conectores para el servicio. El diseño obtenido es lo suficientemente amplio, como para permitir futuras extensiones al servicio en forma de nuevos conectores para distintos tipos de repositorios, tales como archivos o bases de datos relacionales. La solución también contempla el soporte para su funcionamiento en distintas ORBs y no sólo para una en particular. El diseño hace uso de distintos patrones de diseño adecuados para resolver los problemas que se presentaron.

4. CONSTRUCCIÓN

En esta etapa se construyeron los artefactos definidos en la etapa de diseño. La construcción se realizó en forma incremental, y se proveyeron pruebas unitarias que permiten futuras extensiones al servicio con otros conectores. Esta forma de construcción se realizó en dos iteraciones entre la etapa de diseño y construcción, focalizando la primera en el compilador y las herramientas. Entre los artefactos construidos se encuentran el compilador y el conector que permite compartir repositorios entre distintas ORBs. También se construyeron herramientas para la generación de código y junto con sus respectivas pruebas unitarias.

5. EVALUACIÓN DEL SERVICIO

Esta etapa se evaluó el servicio construido en una aplicación CORBA. También se compararon las funcionalidades y las formas de uso de otras implementaciones de este mismo servicio. El objetivo de esta etapa fue poner un marco de referencia de este trabajo en relación con otros servicios.

6. REDACCIÓN DEL INFORME Y CONCLUSIONES

Esta epata consistió en la realización de este informe final del trabajo. Se adjuntan también un CDROM con el código fuente de todas las construcciones realizadas para este trabajo, referencias en formato digital, herramientas utilizadas, y este documento en formato digital.

R

”. Third Edition June 13, 1995. Richard Mark Soley, Ph.D. (ed.) Christopher M. Stone

BM0 – “
             

”. Meyer, Bertrand. Prentice Hall. (1997) ISBN 0-13-629155-4. CR01 – “  
                             OMG”. http://www.omg.org/technology/documents/corba_spec_catalog.htm

PS0 – “Persistent State Service”, V2.0 OMG 2002. http://www.omg.org/cgi-bin/doc?formal/02-09-06 GA0 – “Design Patterns: Elements of Reusable Object-Oriented Software”, Addison-Wesley

Professional Computing Series - by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, January 15, 1995.

BgVaDk – “Java Programming with CORBA, Advanced Techniques for Building Distributed Applications”, 3rd Edition – Gerald Brose, Andreas Vogel, Keith Duddy, Wiley 2001. TS01 – “Transaction Service Specification”, OMG 2003.

http://www.omg.org/technology/documents/corbaservices_spec_catalog.htm

EisenbergMelton01 – “SQL: 1999, formerly known as SQL3”. Andrew Eisenberg, Sybase, Concord, MA 01742 [email protected]; Jim Melton Sandy UT 84093 [email protected] Ramakanth01 – “Object-Relational Database Systems - The Road Ahead”; Ramakanth S. Devarakonda; http://www.acm.org/crossroads/xrds7-3/ordbms.html

CooperRice00 – “Engineering A Compiler”, Keith Cooper - Rice University, Houston, Texas; Linda Torczon - Rice University, Houston, Texas. http://www.cs.rice.edu/~keith/

I

NTRODUCCIÓN A

POO

-

P

ROGRAMACIÓN

O

RIENTADA A

O

BJETOS

Elementos principales ... 15

Clase ... 15

Objeto ... 15

Atributo ... 15

Método ... 16

Mensaje ... 16

Características:... 16

Encapsulamiento ... 16

Herencia ... 16

Abstracción ... 16

Polimorfismo ... 17

Ciclo de Vida ... 17

Persistencia ... 17

Java ... 18

Patrones de Diseño ... 18

Referencias ... 20

a Programación Orientada a Objetos (POO) es un paradigma de programación, así como también lo son el Estructurado y el Funcional que preceden a POO. Un paradigma de programación es un estilo de programación que conlleva una cierta filosofía. Esta filosofía define una serie de premisas que son las llamadas mejores prácticas (best practices). Existen múltiples lenguajes de programación para un paradigma dado. El paradigma define las herramientas que los lenguajes de programación deben proveer para permitir el desarrollo de aplicaciones de la forma más natural posible [HJ0].

Si bien la POO tiene ya muchos años no fue recién hasta los comienzos de los 90 donde se popularizó y comenzó a ser utilizado como paradigma de desarrollo de software.

Muchas de las buenas prácticas en otros paradigmas son igualmente válidas en POO, como por ejemplo la Modularización.

La Modularización tiene como objetivo separar un sistema en módulos, simplificando su diseño, implementación y entendimiento, así como también facilitar su evolución y mantenimiento. El grado de efectividad de esta técnica depende del criterio utilizado para descomponer el sistema en módulos [PD0]. La modularización está presente en POO principalmente en las clases. Para algunos autores, las clases debieran ser los únicos módulos existentes en un sistema [BM0]. En algunos lenguajes, tales como ADA o Java, existe un concepto que también se podría asociar a los módulos, que es el de paquete. Estos paquetes se utilizan para agrupar clases, pero no son estrictamente necesarios en el mundo de POO.

La idea básica en POO es resolver un problema planteándolo como un modelo del mundo real en el que existen objetos que interactúan, a diferencia del modelo de desarrollo estructurado donde se trata de resolver el problema descomponiéndolo en un conjunto de funciones.

Existen múltiples lenguajes de programación orientados a objetos, entre los que se encuentran: Smalltalk, Object Pascal, ADA, C++, Java, Eiffel, C#, entre muchos otros.

E

Todo lenguaje que se base en POO debe proveer de algunas herramientas o construcciones básicas como son las: clases, objetos, métodos, mensajes y atributos.

C

Una clase define o modela las características de una “cosa”. Las características incluyen los atributos o propiedades junto con su comportamiento (métodos). El típico ejemplo es el de un Animal, el cual tiene propiedades tales como: edad, ubicación, forma de alimentación, etc. su comportamiento podría estar definido por: alimentarse, dormir, procrear, etc.

O

Un objeto es un individuo de una clase. Los individuos en POO se denominan instancias. En el ejemplo de los animales un objeto seria un Animal concreto, por ejemplo, un animal en el zoológico, que tiene un estado determinado, como por ejemplo, 2 años de vida.

A

Un atributo de una clase es análogo a una variable en la programación estructurada, con la diferencia del contexto donde se define. Los atributos son accesibles desde una instancia de una clase u objeto, mientras que las variables son accesibles desde el contexto en el que se definieron. En la programación más estricta todo es un objeto, o sea un entero o un string es un objeto. Los atributos son tipados. Se puede tener un atributo de tipo Animal y otro de tipo Entero, o un atributo de tipo Objeto, que podría referenciar tanto una instancia de un Animal como de un Entero. Los valores de los atributos de una instancia de un objeto determinan su estado.

MÉTODO

Los métodos de POO son análogos a las funciones de programación estructurada. La diferencia fundamental es que las funciones o procedimientos se ejecutan en un contexto global, mientras que los métodos se ejecutan en el contexto del objeto en el cual se llamó al método. Se dice que el conjunto de métodos de un objeto determinan su comportamiento.

M

Se entiende por mensaje, a la invocación a un método de un objeto. Esta invocación se realiza con los parámetros aceptados por el método. El mensaje es el equivalente a una llamada a una función en el paradigma estructurado.

C

:

La POO se basa en cuatro características: Encapsulamiento, Herencia, Abstracción y Polimorfismo.

E

El encapsulamiento es una forma de ocultar y agrupar información de forma tal de unificar el acceso a la misma. El encapsulamiento es generalmente equiparado a “ocultamiento de la información”. Según [BM0]:

“Debiera ser posible para el autor de una clase especificar los atributos que estarán disponibles para todos, ninguno o algunos de los clientes de la clase”.

Pero ocultar información, no se refiere solamente a los aspectos físicos de la misma. Por ejemplo, que una clase Lista utilice un array para almacenar sus elementos no debiera ser visible para un usuario de esta clase. Los usuarios de la clase debieran acceder a los elementos de una Lista por medio las operaciones de la misma, por ejemplo: obtenerElementoX. Esto garantiza que los clientes de las clases se comuniquen por medio de su interfase o contrato sin depender de la implementación de la misma.

H

La herencia es una característica que permite agrupar funcionalidades comunes en lugares comunes, es la forma más natural de reutilización en POO. Al igual que en el mundo real, la herencia refleja que una clase hereda de otra. En POO las clases pueden heredar de otras clases sus características y comportamiento. Por ejemplo, en la familia de los animales, algunos son de tipo carnívoro y otros de tipo herbívoro. Una forma de herencia se podría definir como que las clases Carnívoro y Herbívoro heredan de la clase Animal. Esto implica que ambas tiene las mismas características que cualquier animal como la edad, peso, etc. pero además cada una tiene sus características propias, por ejemplo, un Carnívoro se alimenta de distinta forma que un Herbívoro.

Existen dos tipos distintos de herencia: la herencia simple y la herencia múltiple. La primera, implica que una clase solo puede heredar a lo sumo de una única clase, mientras que la segunda, permite que una clase pueda heredar de más de una clase al mismo tiempo. No todos los lenguajes de programación soportan el segundo tipo de herencia, por ejemplo, C++ la soporta y Java no lo hace.

La herencia incluye un nuevo concepto llamado redefinición. Básicamente significa que una clase hija puede redefinir una característica de la clase padre, por ejemplo un atributo o un método.

A

La abstracción permite que dos objetos sean tratados de forma uniforme sin que importe cual clase sea. Por ejemplo, dos animales, uno Carnívoro y otro Herbívoro como un Perro y un Caballo, pueden

interpretar un mensaje como dormir. Para quien envía el mensaje dormir, es indistinto si es un Perro o un Caballo el que lo recibe.

P

El polimorfismo es una de las características esenciales de POO y está muy asociada a la redefinición y a la abstracción. Cuando un Animal recibe el mensaje alimentarse, que debe hacer, depende básicamente del tipo de Animal. Los Carnívoros consumirán carne y los Herbívoros vegetales. Desde el punto de vista del cliente o usuario de una clase de tipo Animal, el mensaje enviado es el mismo, pero los resultados son muy distintos.

La forma de conseguir un comportamiento similar en programación estructurada, sería mediante una condición. Por ejemplo, se tiene la función alimentar(animal, alimento): dentro del código fuente de la función se debe preguntar ‘si animal es carnívoro alimentar_carne() sino alimentar_vegetal()’. Mientras que en objetos sólo sería necesario escribir: ‘animal.alimentar(alimento)’. El polimorfismo es la propiedad que permite que un objeto, dado un mismo mensaje responda de manera distinta en función del tipo de objeto.

C

V

Para utilizar una instancia de una clase es necesario tener una referencia al objeto, o construir una instancia de la misma. Para construir una instancia de una clase, se utilizan métodos especiales de las clases llamados ‘constructores’. Todo constructor devuelve como resultado una instancia de la clase donde está definido. Cuando la instancia es creada se dice que es referenciada por la variable a la que se asignó. Una vez creada la instancia de la clase, ya está lista para ser utilizada mediante sus métodos y atributos.

Toda instancia que está creada ocupa un espacio en memoria. La forma de liberar este espacio depende principalmente del lenguaje de programación utilizado. Cuando se libera esta memoria, se dice que es el objeto se destruye.

Los primeros lenguajes de POO requerían que el usuario de los mismos se encargara de alocar y liberar la memoria utilizada por las instancias de los objetos. Por ejemplo, en C++ es necesario llamar explícitamente al operador delete para liberar la memoria que el objeto utiliza. Algunos lenguajes más modernos, liberan la memoria que utilizan los objetos de forma automática, este es el caso de Java, o C#.

P

Muchas aplicaciones desarrolladas utilizando POO requieren mantener los objetos utilizados entre distintas sesiones o ejecuciones de la aplicación. Los objetos que deben ser compartidos entre distintas sesiones se dicen que son Persistentes, mientras que los que no lo son se dice que son Transientes. Los objetos no pueden ser mantenidos en memoria entre distintas sesiones, ya que la memoria es liberada cada vez que se cierre la aplicación donde se utilizan los objetos. Es necesario almacenar los objetos en algún repositorio permanente.

Si el estado de un objeto está definido por el valor de sus atributos, se puede asumir que para recuperar un objeto de un repositorio permanente, es suficiente con almacenar los valores de sus atributos. Pero esto no es suficiente cuando estos atributos son otros objetos con sus propios atributos o cuando estos atributos referencian a otros objetos que pueden referenciar al objeto inicial que se quería presistir. Los objetos en memoria pueden constituir un grafo de dependencias complejo que puede incluir ciclos definidos por referencias cruzadas. Un mecanismo de persitencia que pueda almacenar en forma automática el objeto junto con estas dependecinas cruzadas, se dice que soporta persistence closure o persitencia cerrada [BM0].

Cuando los objetos necesitan ser compartidos entre distintas sesiones, y además ser compartidos entre distintas aplicaciones, se agrega la necesidad de la existencia de una bases de datos u objetos. Las bases de datos pueden ser de tipo relacional (RDBMS) que require un mecanismo de traducción entre el modelo de objetos y el modelo relacional, o pueden ser sistemas de bases de datos orientadas a objetos (OODBS) que soportan los objetos en forma nativa.

Algunos mecanismos de persitencia proveen soluciones para la evolución del esquema [BM0]. La evolución del esquema se aplica cuando se modifica una clase y para dicha clases ya existen instancias de objetos con la estructura original de la clase almacenadas en un repositorio. Cuando se recuperan dichas intancias puede ocurrir que ya no esté disponible la clase original y no sea posible recuperarla con la nueva clase ya que no existe algún atributo de la misma. A este problema se lo denomina object mismatch o incompatibilidad de objeto. La incompatibilidad de objetos no ocurre solamente cuando se recupera un objeto de un repositorio donde persiste, también puede ocurrir cuando se transmite un objeto por la red, y el receptor del mismo posee una versión distinta de la clase a la que pertenece el objeto transmitido.

La persistencia de los objetos no está ligada directamente a la POO, cada lenguaje puede proveer o no, herramientas que permitan la persistencia de los objetos utilizados.

J

Java es un lenguaje de programación orientado a objetos cuya sintaxis deriva de C y C++, pero que provee un modelo de objetos más simple que C++. Java fue creado por James Gosling [JavaTech01] y por la empresa SUN en el año 1995, como parte de una plataforma llamada Java Virtual Machine o Máquina Virtual Java. Desde entonces ha evolucionado hasta su versión 6. La máquina virtual permite que un programa escrito y compilado en Java pueda ejecutarse en cualquier sistema operativo y arquitectura sin ser modificado. El sistema operativo requiere tener una implementación de la máquina virtual instalada. Java se compila en código de bytes o bytecode, y no en código binario. El bytecode es la representación interna que entiende la máquina virtual, y es lo que permite la independencia de arquitectura y sistema operativo.

Una de las características principales de Java y que lo diferencian fundamentalmente de C++, es el manejo de memoria. Java provee manejo automático de memoria, lo que implica que el programador no debe encargarse de pedir y liberar la memoria necesaria para la creación y destrucción de los objetos. Esta característica se implementa por medio de automatic garbage collection o recolección automática de basura [HoskingMoss01]. Este mecanismo permite que un objeto sea eliminado cuando no existan referencias accesibles a él desde los objetos activos. La máquina virtual es la encargada de llevar el control de las referencias a los objetos y de administrar la memoria utilizada.

Existen algunas otras diferencias importantes con C++ [TateB01]. Java no permite herencia múltiple de clases, aunque si permite herencia múltiple de interfases. Las interfases son definiciones de comportamientos que pueden tener o implementar las clases, pero sin su implementación. Son análogas a las clases abstractas con todos sus métodos abstractos de C++. En Java todos los métodos son potencialmente polimórficos, mientras que en C++, un método debe ser declarado virtual para que pueda comportarse en forma polimórfica. Java no posee destructores ni operadores redefinibles por el programador. En Java las clases son definidas en paquetes y un paquete puede contener múltiples clases y sub paquetes.

P

D

El diseño de sistemas en lenguajes orientados a objetos no es una tarea simple, se deben considerar múltiples factores que permitan reutilización, bajo acoplamiento y alta cohesión de las clases que conformen el sistema.

Generalmente, el mejor diseño no se obtiene en un solo paso, sino a través de iteraciones que lo refinen. Cuando se plantea diseñar una solución a un problema, se trata de reutilizar soluciones anteriores buscando analogías a otros problemas similares. Muchos de los problemas que se plantean al realizar un diseño, fueron afrontados por otros diseños anteriores de la misma u otras personas. Las soluciones a estos problemas recurrentes siguen patrones de comunicación y estructuras de clases comunes.

Estos patrones son los llamados Design Patterns o Patrones de Diseño que permiten reutilizar diseños y arquitecturas exitosas. Un patrón de diseño fue definido por Erich Gamma [GA01] como:

“Un patrón de diseño nombra, motiva y explica en forma sistemática un diseño general que soluciona un problema recurrente en sistemas orientados a objetos. Describe el problema, da su solución, y define cuando es aplicable, determinando las consecuencias de la solución. También da ejemplos y lineamientos para su implementación. La solución es un esquema general de objetos y clases que solucionan el problema. La solución se debe adaptar e implementar para resolver el problema en el contexto particular”.

Los patrones de diseño se popularizaron a partir de la tesis doctoral de Erich Gamma [GA02], que luego fue ampliada con nuevos patrones y publicada en el libro “Design Patterns: Elements of Reusable Object-Oriented Software” [GA01] o “Patrones de Diseño: Elementos de Software Orientado a Objetos Reutilizable”.

Algunos de los patrones de diseño más difundidos son: Abstract Factory, Adapter, Composite, Decorator, Factory Method, Observer, Strategy, Template Method, etc.

R

AD0 – Armstrong, Deborah J. “The Quarks of Object-Oriented Development”. Communications of the ACM 49 (February 2006): 123-128. ISSN 0001-0782.

BM0 – Meyer, Bertrand. “Object-Oriented Software Construction”. Prentice Hall PTR, 1997, 2da Edición, ISBN 0136291554.

CO0 – “Software engineering: Report of a conference sponsored by the NATO” Science Committee. Peter Naur, Brian Randell (eds.) Garmisch, Germany, 7–11 October 1968, Brussels, Scientific Affairs Division, NATO (1969).

HJ0 – John Hunt. “Samlltalk and Object Orientation: An Introduction”. JayDee Technology Ltd, Hartham Park Corsham, Wiltshire, SN13 0RP United Kingdom.

PD0 – David Parnas, "On the Criteria to Be Used in Decomposing Systems Into Modules". Communications of the ACM in December, 1972.

VRH0 –Peter Van Roy, Seif Haridi, “Concepts Techniques and Models of Computer Programming”. The MIT Press, Cambridge, Massachusetts. London, England 2004. ISBN 0-262-22069-5

JavaTech01 – “Java Technology: The Early Years", by Jon Byous.

http://java.sun.com/features/1998/05/birthday.html

HoskingMoss01 – “Protection traps and alternatives for memory management of an object-oriented language”. Antony L. Hosking J. Eliot B. Moss. Object Systems Laboratory Department of Computer

Science University of Massachusetts Amherst, MA 01003.

ftp://ftp.cs.purdue.edu/pub/hosking/papers/sosp93.pdf

TateB01 – "Beyond Java", by Bruce A. Tate. O'Reilly, September 2005. ISBN 0-596-10094-9

GA01 – “Design Patterns: Elements of Reusable Object-Oriented Software”, Addison-Wesley Professional Computing Series - by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, January 15, 1995.

GA02 – “Object-Oriented Software Development based on ET++: Design Patterns, Class Library, Tools”. Erich Gamma PhD thesis, University of Zurich Institut für Informatik, 1991.

I

NTRODUCCIÓN A

CORBA

OMG y CORBA _______________________________________________________ 23

OMA _______________________________________________________________ 23

Object Services _____________________________________________________ 23

Common Facilities __________________________________________________ 23

Domain Interfases __________________________________________________ 24

Principios de Diseño en CORBA__________________________________________ 24

Características de CORBA ______________________________________________ 24

IDL Interface Definition Language ______________________________________ 24

Pasaje de Parámetros: _______________________________________________ 25

Mapeos de lenguajes (Language Mappings) ______________________________ 25

Invocación de Operaciones y facilidades de despacho (dispatching) ___________ 25

Object Adapters (OA) ________________________________________________ 26

Protocolo Inter-ORB _________________________________________________ 26

Un request en CORBA _________________________________________________ 27

Object References __________________________________________________ 27

Adquisición de OR ________________________________________________ 27

Proceso para la invocación de un request ________________________________ 27

Las características de la invocación _____________________________________ 27

Contenedor de Componentes CORBA ____________________________________ 28

Referencias _________________________________________________________ 29

n Sistema Distribuido es un conjunto de computadoras independientes que se presentan al usuario del sistema como un único sistema. Desde la perspectiva de hardware, las máquinas o computadoras son autónomas, pero desde el punto de vista del software, el sistema se ve por el usuario como un todo [Tanenbaum01].

La construcción de este tipo de sistemas plantea desafíos que no se presentan en los Sistemas Centralizados. Las computadoras que se interconectan son heterogéneas y pueden tener arquitecturas diversas. La comunicación conlleva latencia y fallos que deben ser contemplados. Esta problemática impone la necesidad de un modelo de abstracción que simplifique la construcción y diseño de los Sistemas Distribuidos [TariBukhers01]. La especificación CORBA de OMG provee un modelo para estos problemas.

OMG

CORBA

OMG (Object Management Group) o Grupo de Administración de Objetos, es una organización o consorcio internacional fundado en 1989 que trata de establecer los lineamientos y modelos para el desarrollo de aplicaciones reusables, portables e interoperables en ambientes distribuidos heterogéneos, bajo un modelo de objetos e interfases claramente definidas. OMG ha recibido un gran apoyo de la industria, transformándose en el consorcio de software más grande del mundo.

CORBA (Common Object Request Broker Arquitecture) o Arquitectura Común para el Agente de Pedidos de Objetos [CR0] es el núcleo del modelo de arquitectura propuesto por OMG, llamado OMA.

OMA

Esta arquitectura, llamada OMA (Object Management Architecture) [OM0], está dividida en dos modelos fundamentales. El primer modelo, llamado Modelo Central de Objetos (Core Object Model), permite el desarrollo de aplicaciones distribuidas basadas en un Agente de Pedidos a Objetos u ORB (Object Request Broker). Se trata de un modelo con definiciones abstractas que no poseen ninguna implementación y permiten interpretar el modelo de objetos e interfases. Este modelo fija las bases para CORBA. Está enfocado en el diseño e implementación de la ORB y no en la construcción de aplicaciones. CORBA es una especialización de los conceptos definidos en este modelo, llevando las definiciones abstractas a construcciones concretas.

El segundo modelo, llamado Modelo de Referencia (Reference Model), define a la ORB junto a un grupo de interfases estandarizadas, como el núcleo para la construcción de aplicaciones distribuidas. Estas interfases son: los Servicios de Objetos (Object Services) [COS0], las Utilidades Comunes (Common Facilities) [CCF0] y las Interfases de Dominio (Application Domain Interfases). El modelo de referencia es el utilizado por los desarrolladores de aplicaciones.

O

S

Los servicios de objetos (Object Services) son un conjunto de interfases de servicios y objetos que soportan operaciones básicas para la implementación y utilización de objetos. Estos servicios permiten la construcción de aplicaciones distribuidas independientes del dominio. Los servicios definen operaciones genéricas que se aplican a objetos de cualquier dominio, por ejemplo acceder a un objeto por algún identificador. Existen servicios, tales como Naming Service o Trading Service, que proveen referencias a objetos que permiten accederlos desde cualquier ubicación. Algunos de los servicios de objetos son: Naming Service [NS01], Persistence State Service [PSS01], Transaction Service [TSS01], etc.

C

F

Las utilidades comunes (Common Facilities), son también servicios u objetos, pero no esenciales para la construcción de aplicaciones, como los servicios de objetos. Su existencia permite que diferentes aplicaciones puedan beneficiarse compartiéndolos, sin tener que implementar su funcionalidad en cada aplicación. Un ejemplo de estas utilidades son los servicios para el manejo de correo electrónico.

D

I

Las interfases de dominio corresponden a grupos de interfases generalizadas para dominios de aplicación particulares, tales como: telecomunicaciones, internet, salud, etc.

P

D

CORBA

OMA define lineamientos que se deben respetar en el diseño de interfases de servicios de CORBA: • Separación de la interfase de su implementación.

• Las referencias a objetos deben ser tipadas por interfases.

• Los clientes sólo dependen de interfases, no de implementaciones. • Las interfases permiten herencia múltiple.

• Para especializar o extender funcionalidades se utilizan subtipos.

• Se asume que las implementaciones de los servicios son eficientes al cumplir su cometido, de forma tal que la eficiencia no sea un problema para los clientes.

C

CORBA

La ORB se puede interpretar como un canal de comunicación que transporta pedidos y respuestas desde y hacia objetos en cualquier ubicación, sin importar como estén implementados. La noción de transparencia es fundamental en CORBA. Un objeto puede ser invocado independientemente de su ubicación física, por medio de este canal. La transparencia también se aplica al lenguaje de programación. Se pueden realizar pedidos a objetos independientemente del lenguaje en el cual estén implementados, por medio del lenguaje de definición de interfases o IDL que es común a todas las implementaciones y usuarios.

IDL

I

D

L

Uno de los lineamientos que permite la abstracción de CORBA, es la separación de las interfases de los objetos de su implementación. Las interfases se definen en un lenguaje provisto por CORBA para este propósito, llamado IDL (Interface Definition Language o Lenguaje de Definición de Interfases). IDL no permite definir la implementaciones. El hecho de que la definición se realice en un lenguaje genérico, permite que la especificación sea independiente del lenguaje de implementación de los objetos.

IDL soporta todos los tipos básicos del lenguaje C, enumerados y relaciones entre otras interfases. La definición de interfases, también soporta herencia en el formato diamante [CR0]. Toda interfase que no declare heredar de otra en forma explícita, hereda en forma implícita de la interfase IDL Object. De esta forma, todos los objetos CORBA, tienen una interfase común.

La definición IDL, es compilada en un lenguaje específico, como puede ser C, C++. Java, Fortran, etc. El mecanismo de compilación de la definición IDL, se concreta según la especificación de CORBA, denominada language mappings (o mapeos de lenguaje). El código que genera el proceso de compilación de un segmento de código en lenguaje IDL, es sólo la cáscara para la implementación. Para generar un objeto servidor o servant, un desarrollador toma esta cáscara e implementa el cuerpo de las operaciones o funciones que se hayan definido en la interfase.

Cuando se compila un archivo que tiene definiciones IDL, para el caso de C++, por lo general se crean cuatro archivos. Un archivo contiene las interfases C++, otro contiene las operaciones de la interfase, otro contiene la implementación C++ del cliente (stubs), y el último contiene la implementación

base del servidor o esqueleto (skeleton) de la misma, ya que el cuerpo de cada función en particular es lo que se desarrolla a posteriori.

Cuando se comunican diferentes implementaciones de ORBs, no se pueden compartir los archivos generados por el compilador IDL, ya que el código que éste genera es propietario. No tiene sentido hablar de compartir código si se comunica una ORB que funciona con Java y otra con C++. Mediante el uso del IDL, se puede llamar a una operación definida en una interfase IDL, que esté implementada en un objeto programado en otro lenguaje y corriendo en otra ORB.

P

P

:

La definición de una operación requiere que se especifique el modo de pasaje de sus parámetros. Las formas permitidas son: in, out, e inout.

- in: el argumento se pasa del cliente al servidor.

- out: el argumento es devuelto al cliente, desde el servidor.

- inout: el argumento es inicializado por el cliente, modificado por el servidor, y devuelto al cliente nuevamente.

Dado que IDL, carece del concepto de punteros, tiene que existir una forma más eficiente de pasar por parámetro, estructuras más complejas que un tipo de dato simple. Cuando se compila una operación de una interfase que recibe como parámetro a otra interfase, se pasa una referencia al objeto que implemente este parámetro, lo que es análogo a un “puntero”.

M

(L

M

)

Los Lenguaje Mappings especifican como se mapean las interfases IDL a un lenguaje determinado. Para cada construcción IDL, el mapeo del lenguaje define como se traduce a ese lenguaje. Por ejemplo, en C++ las interfases IDL se mapean a clases, mientras que en Java [IDJ0], se mapean a interfases públicas.

Las referencias a objetos en C++ se mapean a una construcción que soporta el operator->, mientras que en C, se mapean a un void *.

De igual forma, los mapeos de lenguajes especifican como utilizar las facilidades que provee la ORB (ORB facilities), y como las aplicaciones servidoras implementan los servants.

Existen múltiples mapeos de lenguajes que permite que las aplicaciones distribuidas puedan ser construidas en partes y utilizando múltiples lenguajes.

La independencia del lenguaje que plantea CORBA, es la clave para interconectar sistemas heterogéneos.

I

O

(

)

Las aplicaciones CORBA funcionan recibiendo pedidos o request, o emitiendo request a objetos CORBA. Los tipos de invocación que soporta CORBA son:

- Invocación estática: se realiza mediante una llamada a los stubs generados por el compilador IDL. El servant hereda o modifica el skeleton generado por el compilador IDL.

- Invocación dinámica: este mecanismo requiere la construcción del request en tiempo de ejecución. Dado que no se tiene información en tiempo de compilación, la creación e interpretación de los requests, requiere el acceso a los servicios que permitan obtener dicha información. Este servicio puede estar implementado, por ejemplo, mediante la interrogación a un operador que brinde la información necesaria, o utilizando el Interfase Repository Service, que es un servicio que provee acceso a interfases IDL en tiempo de ejecución.

La invocación estática es comúnmente utilizada por los desarrolladores cuando se implementan aplicaciones que utilicen interfases bien definidas. Mientras que el mecanismo dinámico es utilizado, generalmente, por dispositivos que procesen información que a priori es desconocida, tales como los bridges, o gateways.

O

A

(OA)

Los OA son el nexo entre los servants y la ORB, corresponden al patrón de diseño Adapter [GA0]. Un objeto adapter adapta la interfase de un objeto a otra esperada por el emisor. De esta forma, permite a un emisor comunicarse con un receptor sin conocer realmente cual es su interfase.

Los Object Adapters cumplen con tres requerimientos básicos:

1- Crean Object References, que permiten a los clientes acceder a los objetos.

2- Aseguran que cada objeto a invocar o target, esté encarnado o representado por un servant. 3- Toman los request que llegan a la ORB en la cual se aloja el objeto target y se los transmite

al servant que es la encarnación del target.

Esto permite a la ORB separarse de los diferentes tipos de servants que puedan existir. De esta forma, la única responsabilidad relacionada con el request de la ORB es entregarlo al OA que es el que realmente se encarga de comunicarse con el servant.

En C++ [HeVi0] un servant, es una clase que probablemente herede de un skeleton generado por el mapeo del IDL al lenguaje. Para implementar las operaciones, se deben sobrescribir los métodos virtuales. En el caso de Java [BgVaDk0], se deben implementar los métodos de la interfase que defina el skeleton. El servant se registra con el OA, permitiéndole a la encarnación de las interfases que el servant represente, recibir los request de los clientes.

Hasta la versión 2.1 de CORBA existía una especificación base del OA, llamada Basic Object Adapter (BOA) solamente para C. La versión 2.2 de CORBA introdujo el Portable Object Adapter (POA), para solucionar los inconvenientes que tenia BOA. El POA, mejoró mucho la relación entre los objetos CORBA, y las encarnaciones servants. Como resultado de esto, la especificación de BOA fue eliminada de CORBA.

P

I

-ORB

Antes de CORBA 2.0, una de las principales desventajas que se le criticaban a CORBA, era la inexistencia de una especificación de protocolo para comunicar ORBs. Por ello, cada proveedor de ORB debía definir el protocolo de red que usaba para comunicar la ORB. Lo que daba como resultado el aislamiento de las distintas implementaciones de ORB, ya que cada una contaba con un protocolo propietario.

En CORBA 2.0, se introdujo una arquitectura para la interoperabilidad de distintas implementaciones de la ORB llamada General Inter-ORB Protocol (GIOP se pronuncia “gee-op”). GIOP es un protocolo abstracto que define la sintaxis para la transmisión y el conjunto de formatos de mensajes que permite a cualquier implementación de ORB comunicarse sobre una capa de transporte orientada a la conexión. Internet Inter-ORB Protocol (IIOP se pronuncia “eye-op”) especifica como GIOP se mapea sobre TCP/IP.

Para la interoperabilidad de las ORBs se requiere un formato estándar de Object References. Este formato se denomina Interoperable Object Reference (IOR), y es lo suficientemente flexible como para permite almacenar cualquier tipo de IOP. Los IOR, identifican uno o más protocolos soportados (IOPs). Para cada protocolo, el paquete IOR contiene la información propietaria del mismo. En el caso de IIOP, el

IOR contiene el nombre del host, el puerto TCP/IP, y una clave de objeto que identifica al objeto target, para la combinación host - puerto.

U

CORBA

O

R

Las Object References (OR), son análogas a los punteros a objetos de C++ o las referencias de Java.

- Cada OR identifica una única instancia de objeto.

- Pueden existir múltiples OR que referencien al mismo objeto. - La referencia puede ser null (nil reference)

- Las referencias pueden apuntar a objetos eliminados.

- Son opacas, los cliente no conocen el contenido de las mismas. (deber ser tratadas como caja negra)

- Son fuertemente tipadas.

- Soportan late-binding (soporta el polimorfismo de C++, a diferencia del de RPC).

- Pueden ser persistentes (las referencias pueden haber sido almacenados en disco para luego ser recuperadas nuevamente).

- Pueden ser interoperables (diferentes implementaciones de ORBs, pueden intercambiar OR).

ADQUISICIÓN DE OR

La única forma de acceder a un objeto CORBA es a través de las OR. Cada servidor puede publicar las ORs que contiene. La forma más natural de adquirir una OR por un cliente es la de recibirla como respuesta a una invocación a un servicio. Otra forma es la de buscarla en un servicio como Naming o Trading Service.

P

Cuando un cliente invoca una operación por medio de la OR de un objeto, la ORB hace lo siguiente:

- Ubica el objeto target.

- Activa la aplicación servidor, si es que esta no está activa. - Transmite los argumentos para la operación.

- Activa el servant para el request si es necesario. - Espera que se complete el request.

- Devuelve todos los parámetros out, o inout, y el resultado del request.

- Alternativamente devuelve una excepción, en conjunto con los datos, cuando el request falle. El mecanismo para el cliente es completamente transparente y lo ve como la invocación de cualquier otro método en un objeto no controlado por la ORB.

L

- Transparencia de la ubicación: El cliente no sabe si el objeto es local al proceso en el que corre, o si se encuentra en otro proceso de la misma máquina, o si realmente se encuentra en otro proceso de otra máquina. Los procesos servidores, no están obligados a permanecer en la misma máquina eternamente, pueden ser movidos de máquina en máquina sin que los clientes sean conscientes de ello.

- Transparencia del servidor: El cliente no necesita saber cual es el servidor que implementa el objeto.

- Independencia del lenguaje: Al cliente no le interesa saber en cual lenguaje está implementado el objeto que está invocando.

- Independencia de la implementación: El cliente no necesita saber como funciona la implementación. Incluso los objetos servidores, no necesariamente deben estar implementados en un lenguaje orientado a objetos.

- Independencia de la arquitectura: El cliente no conoce realmente el tipo de máquina en la que está corriendo el objeto.

- Independencia del sistema operativo: no se sabe realmente cual es el sistema operativo que está corriendo el servidor.

- Independencia del protocolo: El cliente no conoce el protocolo que se está utilizando para comunicarse. La ORB, es la encargada de seleccionar, en tiempo de ejecución, el protocolo que utilizará para comunicarse.

- Independencia del Transporte: El cliente desconoce el transporte o topología de la red que se utilice para la comunicación. Se pueden utilizar distintos tipos de red sin que el cliente sea consciente de ello.

C

C

CORBA

La versión 3.0 de CORBA incluye un nuevo modelo de trabajo, denominado modelo de componentes [CCM01]. Los componentes extienden el modelo de objetos de CORBA (las interfases de IDL), y promueven la composición en vez de la herencia.

El modelo de componentes de CORBA toma características del modelo de componentes de Java, llamado EJB (Enterprise Java Bean), y del modelo de componentes de Microsoft llamado COM (Component Object Model), pero a diferencia de ambos no está basado en un lenguaje particular o en un único entorno como Windows.

CCM o CORBA Component Model (Modelo de Componentes CORBA) promueve un modelo de desarrollo de aplicaciones, donde se oculta parte de la complejidad de CORBA. Los componentes de CORBA tienen acceso a los servicios estándar de CORBA, tales como el de Transacciones, Seguridad, Persistencia o Eventos.

Todo componente se instala en un contenedor de componentes. La especificación CCM introduce el concepto de componente y un conjunto compuesto por interfases, técnicas para especificar la implementación, empaquetado, y despliegue (deploy) o instalación de los componentes.

Los componentes implementan al menos una interfase, pero además permiten definir a los otros componentes que se requieren para que un componente pueda funcionar. Un componente también puede exponer atributos que permiten configurarlos en el contenedor donde sean instalados. Además, se define un modelo de conexión de componentes mediante eventos, que permite independencia de interfases de los componentes conectados. Este modelo de conexión sigue el patrón de diseño Observer [GA0].

Todas estas nuevas características son definidas mediante un nuevo lenguaje llamado CIDL (Component Implementation Definition Language), que extiende al lenguaje PSDL [PSS01] y al IDL versión 3.0 de CORBA.

R

Tanenbaum01 – “Distributed Operating Systems”, Andrew, S. Tanenbaum, Practice-Hall Inc 1996. ISBN 0-13-219908-4

TariBukhers01 – “Fundamentals of Distributed Object Systems, the CORBA Perspective”, Zahir Tari, Omran Bukhers, Willey Inc. 2001. ISBN 0-471-35198-9

CR0 – Object Management Group, “Common Object Request Broker Architecture”, version 3.0.3, OMG document number formal/04-03-01. http://www.omg.org/cgi-bin/doc?ptc/04-03-01

OM0 – Richard Mark Soley, “Object Management Architecture Guide”, June 13, 1995, Ph.D. (ed.) Christopher M. Stone

COS0 – CORBAservices: Common Object Services Specification, Updated: November 1997. ftp://ftp.omg.org/pub/docs/formal/98-07-05.pdf

CCF0 – CORBAfacilities: Common Facilities Architecture. ftp://ftp.omg.org/pub/docs/formal/97-06-08.pdf

NS01 – Object Management Group, “Naming Service Specification”, version 1.1. February 2001. OMG document number formal/01-02-65.

http://www.omg.org/cgi-bin/doc?formal/01-02-65

PSS01 – Object Management Group, “Persistent State Service”, version 2.0. September 2002. OMG document number formal/02-09-06.

http://www.omg.org/cgi-bin/doc?formal/02-09-06

TSS01 – Object Management Group, “Transaction Service Specification”, version 1.4. September 2003. OMG document number formal/03-09-02.

http://www.omg.org/cgi-bin/doc?formal/03-09-02

IDJ0 - Object Management Group, “Java™ to IDL Language Mapping Specification”, version 1.3.

September 2003. OMG document number formal/03-09-04.

http://www.omg.org/cgi-bin/doc?formal/03-09-04

GA0 – Erich Gamma, “Design Patterns: Elements of Reusable Object-Oriented Software”, Addison-Wesley Professional Computing Series, Richard Helm, Ralph Johnson, John Vlissides, January 15, 1995.

BgVaDk0 – Gerald Brose, Andreas Vogel, Keith Duddy, “Java Programming with CORBA, Advanced Techniques for Building Distributed Applications”, 3rd Edition, Wiley 2001.

HeVi0 – Michi Henning, Steve Vinoski, “Advanced CORBA Programming with C++”. Addison Wesley. February 12, 1999. ISBN: 0-201-37927-9

CCM01 – CORBA “Component Model Specification”, OMG Available Specification Version 4.0 formal/06-04-01. http://www.omg.org/cgi-bin/doc?formal/06-04-01

S

ERVICIO DE

E

STADO

P

ERSISTENTE

CORBA

-

PSS

Conceptos Fundamentales en el Servicio ... 33

Identificación ... 35

Tipos y Herencias. ... 35

Claves ... 36

Uso del Servicio de Persistencia ... 36

Acceso al Servicio de Persistencia ... 37

Transacciones ... 38

Construcciones en PSDL ... 38

Características de las construcciones básicas PSDL ... 39

AbstractStorageObject ... 39

AbstractStorageHome ... 40

StorageObject ... 40

StorageHome ... 41

Mapeo del lenguaje PSDL a un lenguaje concreto ... 41

Diferencias entre C++ y Java del servicio de persistencia ... 41

Críticas a la especificación ... 42

Notas finales sobre el servicio de estado persistente ... 43

Alternativas a PSS en Java ... 43

Referencias ... 45

n 1997 OMG creó un RFP (Request for Proposal) para la creación de un servicio CORBA. Se trató de un servicio de persistencia de objetos [PSS01]; Una RFP consiste en el llamado a entidades a participar en la creación de una nueva especificación.

El servicio de persistencia de CORBA tiene el objeto de facilitar y unificar la forma de hacer persistente el estado de los servants [CORBA01] y fue denominado: Servicio de Estado Persistente (Persistent State Service) PSS.

El hacer persistente el estado del objeto significa que su estado sobrevive o se mantiene sin importar cuantas veces el objeto sea encarnado o destruido. No debe confundirse el persistir referencias a servants, con el hacer persistente el estado de un objeto. El hacer persistente las referencias a los servants significa guardar en forma persistente una referencia a un servant y no el estado del mismo.

En el año 2000, PSS reemplazó una especificación anterior del año 1994, denominada POS Persistent Object Service [POS01], que fue muy poco aceptada y ampliamente criticada [KjPfTp]. Actualmente está definida la revisión 2 de PSS que data de Septiembre del 2002.

PSS no intenta ser una interfase a una base de datos orientada a objetos OODBMS, sino el de proveer una forma estándar de hacer persistentes a los objetos. No define los conceptos fundamentales en OODBMS como transacciones y consultas [BgVaDk]. Su fundamento es la separación de intereses (separation of concerns) que está presente en todas la arquitectura y especificaciones de servicios CORBA [CORBA01]. De esta forma, si se tienen requerimientos transaccionales, éstos no serán implementados por este servicio sino que este servicio se conectará o comunicará con el servicio de transacciones CORBA [TS01]. Una de las características que fue mas ampliamente criticada a POS fue no usar los otros servicios que CORBA provee [KjPfTp].

PSS está basado en dos lenguajes de programación: C++ y Java. Aunque su modelo tiene mas similitudes con el segundo que con el primero.

C

F

S

Según la especificación, los clientes de los servants son ajenos a este servicio y no tienen forma de saber si se está usando el mismo. El PSS es visible solo dentro de la implementación de los servants. Según muestra el Gráfico 1, el cliente de la ORB que accede al servant, no accede al PSS directamente sino que lo hace a través del Servant.

In te rfa c e P S S ( P S D L )

Dominio de ORB Dominio de PSS

Servant In te rfa c e O R B e x te rn a ( ID L ) Cliente ORB Objeto del dominio PSS

GRÁFICO 1 - INTERACCIÓN CON LA ORB

En PSS, la información persistente se presenta como objetos almacenados (Storage Objects) en almacenes (Storage Homes), que a su vez se encuentran ubicados en repositorios de datos (DataStores) tales como una base de datos o un conjunto de archivos. Este modelo está representado en el Gráfico 2.

E

Data Store o Repositorio de Datos Objeto Almacenado Almacen o Storage Home Objeto Almacenado Objeto Almacenado Almacen o Storage Home Objeto Almacenado

GRÁFICO 2 - MODELO LÓGICO

Dentro de un repositorio de datos pueden existir múltiples almacenes y a su vez dentro de los almacenes pueden existir múltiples objetos almacenados. Conceptualmente, un repositorio de datos es un conjunto de almacenes, cada almacén contiene objetos de un tipo definido dentro del repositorio. Dentro del repositorio, un almacén es un Singleton [Gamma01], es decir que existe a lo sumo una única instancia de un almacén por tipo de objeto almacenado.

Los objetos almacenados se manipulan a través de instancias de una clase definida en el lenguaje de implementación del programa o proceso que utilice el servicio. Estas instancias representan en un momento dado un objeto existente en el repositorio de datos, mediante el cual se accede al estado persistido. Las instancias de objetos que estén ligadas a un objeto en el repositorio se llaman encarnaciones, al cambiar un atributo de una de estas instancias se está cambiando el estado del objeto almacenado en el repositorio.

Los almacenes de objetos también son manipulados mediante instancias de los mismos. Estas instancias son provistas por catálogos. Para acceder a las instancias de los objetos almacenados desde del proceso o programa se requiere de una conexión con el repositorio de datos, denominada sesión. El Gráfico 3 define la relación entre el modelo lógico y el modelo real de la aplicación.

Data Store o Repositorio de Datos Almacenes o Storage Homes Objetos Almacenados Objetos Almacenados Programa o Proceso Catálogo sesión Encarnaciones Instancia de Almacen Encarnaciones Instancia de Almacen

GRÁFICO 3 - SESIÓN PARA ACCEDER AL DATASTORE

Muchos de los conceptos existentes en PSS, fueron tomados del estándar SQL3 o SQL 1999 [EisenbergMelton01]. SQL3 fue una extensión propuesta al estándar SQL en el año 1999, que agrega conceptos de los lenguajes de programación orientados a objetos. Las bases de datos que lo soportan son llamadas Object-Relational DBMS u ORDBMS [Ramakanth01]. Las tablas en SQL3 permiten tipos de datos

más ricos llamados ADT (Abstract Data Type) que soportan herencia. Los almacenes de PSS son el análogo a las tablas de SQL3, mientras que los objetos almacenados son los registros o tipos de datos de SQL3.

Todos los objetos definidos por el servicio de persistencia implementan la interfase LocalInterface [CORBA01]. Según la especificación de CORBA, todos los objetos que implementen dicha interfase tienen su ciclo de vida limitado al proceso en el que fueron engendrados. De esta forma, es imposible para un servant exportar un objeto definido en el dominio del servicio de persistencia. Esta es otra forma de encapsular el servicio de persistencia sólo dentro de la implementación de los servants.

I

Dado que existen múltiples instancias de objetos dentro de un repositorio y de un almacén, es necesaria una forma de diferenciarlos.

Cada objeto almacenado posee un número único que lo identifica dentro del almacén al que pertenece denominado short-pid (Short Process Identifier o Identificador corto de Proceso). Además posee un identificador único dentro del repositorio en el que existe, que es denominado pid (Process Identifier o Identificador de Proceso). El alcance de este pid está limitado a todas las instancias que pueden ser accedidas por el mismo catálogo.

El concepto de pid es análogo al de oid dentro de CORBA. Una forma simple de relacionar un objeto CORBA con un objeto del servicio de persistencia (un objeto persistente) es directamente por sus identificadores (oid igual al pid).

T

H

.

Los tipos estén separados en dos grandes categorías abstractos y concretos, los primeros implican definiciones que no pueden ser instanciadas, las segundas son las construcciones que serán instanciadas en el programa que utilice el servicio.

custom Herencia Diamante

«i nterface» A «i nterface» B «interface» C «i nterface» D «interface» A' «i nterface» B' «i nterface» C' «interface» D' «interface» E'

GRÁFICO 4 - HERENCIA DIAMANTE DE INTERFASES EN CORBA

Este modelo es muy similar al modelo de herencia del lenguaje de programación Java, los tipos abstractos son análogos a las interfases de Java, mientras que los concretos son análogos a las clases. Al igual que las interfases, los tipos abstractos admiten herencia múltiple, mientras que los concretos solo pueden heredar a lo sumo de un único tipo concreto. De igual forma que las clases, los tipos concretos pueden “implementar” múltiples interfases. La herencia múltiple incluye el modelo de herencia diamante.

La herencia diamante (gráfico 4) está definida en la especificación de CORBA [CORBA01], se utiliza principalmente para la definición de interfases.

AlmacenTipoA TipoA TipoB AlmacenTipoB TipoC AlmacenTipoC AlmacenConcreto TipoConreto almacena almacena almacena almacena Implementa Implementa Implementa Implementa

Hereda Hereda Hereda

Hereda

GRÁFICO 5 - TIPOS Y MODELO DE HERENCIA EN PSS

Tanto los objetos almacenados como los almacenes son tipados con tipos abstractos o concretos, según si son abstractos o concretos respectivamente.

Cada objeto almacenado tiene un tipo asociado, este tipo define el estado y las operaciones que poseen todas las instancias de este tipo. A su vez un tipo puede ser derivado de otros tipos definidos en el repositorio.

Cada almacén a su vez está definido por un tipo, el cual define los tipos de objetos que el almacén puede contener o manejar junto con las operaciones que pueda realizar. De igual forma que los tipos de objetos, los tipos de almacenes también pueden derivar de otros tipos de almacenes definidos dentro del repositorio.

Dentro de un repositorio, un almacén puede manejar tanto las instancias de sus objetos almacenados como las de sus subtipos, que se denomina familia de almacenes.

En el gráfico 5 se muestra la herencia de tipo diamante soportada por el servicio de persistencia CORBA.

C

Un almacén puede definir que una serie de atributos de los objetos que maneja, definen una clave que representa un identificador único para cualquier instancia de los objetos existentes en el almacén. Los almacenes pueden definir tantas claves como deseen. Hay una clave implícita que es el short-pid. Un concepto muy importante, es que las claves no están definidas por los objetos almacenados, sino por el almacén donde se encuentran. Esto permite que diferentes almacenes definan diferentes claves. Una implicación importante es que la unicidad de los objetos sólo es válida dentro del almacén en el que existen.

U

S

P

Para hacer uso del servicio de persistencia, se requiere que el usuario defina los tipos que usará en un programa, la especificación propone dos formas para definir los tipos de objetos.