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

Transcripción

1 Tesis de grado de Ingeniería en Informática Extensión del estándar de para proveer servicios de estado persistente con acceso remoto: Análisis, diseño e implementación. Buenos Aires, Argentina. Diciembre 2007

2

3 Tesis de Grado Ingeniería en Informática INFORMACIÓN DE CONTACTO PABLO MAXIMILIANO ILARDI: O MARÍA FELDGEN: O 3

4 4

5 Abstract RESUMEN 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 ABSTRACT 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 5

6 6

7 Tesis de Grado Ingeniería en Informática CONTENIDO Introducción... 9 Introducción a POO - Programación Orientada a Objetos Introducción a CORBA Servicio de Estado Persistente CORBA - PSS Implementación del servicio de estado persistente CORBA - PSS Comparación con otras implementaciones del servicio de estado persistente de CORBA Trabajos adicionales Índice de Gráficos Glosario

8 8

9 Tesis de Grado Ingeniería en Informática INTRODUCCIÓN L 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. y (P"#$%$&"'&S&(&"S"#)%*") PSS (+,-./ ,/3+) que (+02/.;,267,50+). Todo (+02/.;,=29,). Los 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 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: [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.89.5<3 267, ,3.:2+ y las consultas [BgVaDk]. Su fundamento, es la separación de intereses 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 IJKLMLNJOPMQNKQOLIQKJONJR por CORBA. Los objetos persistidos por PSS, son denominados objeto persiste en un almacenes existen en /,-2+102/12+. PSS provee un lenguaje para definir estos objetos y almacenes, llamado PSDL (P>?@A@B>CBSBDB>D>EACABAFCLDCGHDG>), 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 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. 9

10 Tesis de Grado Ingeniería en Informática 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. OBJETIVOS 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. ETAPAS DEL TRABAJO 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. 10

11 Tesis de Grado Ingeniería en Informática 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. 11

12 Tesis de Grado Ingeniería en Informática REFERENCIAS. OM0 Third Edition June 13, Richard Mark Soley, Ph.D. (ed.) Christopher M. Stone. Meyer, BM OMG. CR01 Bertrand. Prentice Hall. (1997) ISBN PS0 Persistent State Service, V2.0 OMG 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, BgVaDk Java Programming with CORBA, Advanced Techniques for Building Distributed Applications, 3 rd Edition Gerald Brose, Andreas Vogel, Keith Duddy, Wiley TS01 Transaction Service Specification, OMG EisenbergMelton01 SQL: 1999, formerly known as SQL3. Andrew Eisenberg, Sybase, Concord, MA andrew.eisenberg@sybase.com; Jim Melton Sandy UT jim.melton@acm.org Ramakanth01 Object-Relational Database Systems - The Road Ahead ; Ramakanth S. Devarakonda; CooperRice00 Engineering A Compiler, Keith Cooper - Rice University, Houston, Texas; Linda Torczon - Rice University, Houston, Texas. 12

13 Introducción a POO Programación Orientada a Objetos INTRODUCCIÓN A POO - PROGRAMACIÓN ORIENTADA A OBJETOS Elementos principales Clase Objeto Atributo Método Mensaje Características: Encapsulamiento Herencia Abstracción Polimorfismo Ciclo de Vida Persistencia Java Patrones de Diseño Referencias

14 14

15 Introducción a POO Programación Orientada a Objetos L 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. ELEMENTOS PRINCIPALES 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. CLASE 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. OBJETO 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. ATRIBUTO 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. 15

16 Introducción a POO Programación Orientada a Objetos 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. MENSAJE 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. CARACTERÍSTICAS: La POO se basa en cuatro características: Encapsulamiento, Herencia, Abstracción y Polimorfismo. ENCAPSULAMIENTO 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. HERENCIA 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. ABSTRACCIÓN 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 16

17 Introducción a POO Programación Orientada a Objetos 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. POLIMORFISMO 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. CICLO DE VIDA 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#. PERSISTENCIA 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]. 17

18 Introducción a POO Programación Orientada a Objetos 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. JAVA 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. PATRONES DE DISEÑO 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. 18

19 Introducción a POO Programación Orientada a Objetos 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. 19

20 Introducción a POO Programación Orientada a Objetos REFERENCIAS AD0 Armstrong, Deborah J. The Quarks of Object-Oriented Development. Communications of the ACM 49 (February 2006): ISSN BM0 Meyer, Bertrand. Object-Oriented Software Construction. Prentice Hall PTR, 1997, 2da Edición, ISBN 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, VRH0 Peter Van Roy, Seif Haridi, Concepts Techniques and Models of Computer Programming. The MIT Press, Cambridge, Massachusetts. London, England ISBN JavaTech01 Java Technology: The Early Years", by Jon Byous. 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 ftp://ftp.cs.purdue.edu/pub/hosking/papers/sosp93.pdf TateB01 "Beyond Java", by Bruce A. Tate. O'Reilly, September ISBN 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, GA02 Object-Oriented Software Development based on ET++: Design Patterns, Class Library, Tools. Erich Gamma PhD thesis, University of Zurich Institut für Informatik,

21 Introducción a CORBA INTRODUCCIÓ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 21

22 22

23 Introducción a CORBA U 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 Y 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. OBJECT SERVICES 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. COMMON FACILITIES 23

24 Introducción a CORBA 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. DOMAIN INTERFASES Las interfases de dominio corresponden a grupos de interfases generalizadas para dominios de aplicación particulares, tales como: telecomunicaciones, internet, salud, etc. PRINCIPIOS DE DISEÑO EN 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. CARACTERÍSTICAS DE 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 INTERFACE DEFINITION LANGUAGE 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 24

25 Introducción a CORBA 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. PASAJE DE PARÁMETROS: 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. MAPEOS DE LENGUAJES (LANGUAGE MAPPINGS) 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. INVOCACIÓN DE OPERACIONES Y FACILIDADES DE DESPACHO (DISPATCHING) 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. 25

26 Introducción a CORBA 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. OBJECT ADAPTERS (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. PROTOCOLO INTER-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 26

27 Introducción a CORBA 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. UN REQUEST EN CORBA OBJECT REFERENCES Java. Las Object References (OR), son análogas a los punteros a objetos de C++ o las referencias de - 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. PROCESO PARA LA INVOCACIÓN DE UN REQUEST 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. LAS CARACTERÍSTICAS DE LA INVOCACIÓN - 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. 27

28 Introducción a CORBA - 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. CONTENEDOR DE COMPONENTES 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. 28