4. Tendencias en el Desarrollo de Sistemas Distribuidos Tendencias en el desarrollo CORBA CORBA yyDCOM: DCOM: Modelo Modelode de Objetos ObjetosDistribuidos Distribuidos Java JavaBeans: Beans: Modelo Modelode de Componentes ComponentesDistribuidos Distribuidos Grids: Grids:Un Unmundo mundoinfinito infinito de derecursos recursos Peer-to-Peer Peer-to-Peer computing: computing:Cómputo Cómputointensivo intensivo descentralizado descentralizado Objetos Distribuidos CORBA: Un caso de Estudio Profs. Yudith Cardinale-Mariela Curiel Sep – Dic 2002 1 Programación Orientada por Objetos Código Monolítico (Spaguetti) Distintos Archivos, Librerías Objetos Ventajas: código más modular, reusabilidad, mantenibilidad, división del trabajo. Modelos de Programación para Aplicaciones Distribuidas Llamadas a procedimientos remoto Invocación a un método remoto (RMI) Modelo de programación basado en eventos (Java Beans) Programa Distribuido Computador1 main Computador2 Comp. local Comp. remoto Cliente Funciones del Servidor func() func(void ){ } proc1 proc2 proc4 proc3 proc5 Thread de ejecución Thread bloqueado Llamada a proc. remota 2 Interfaces Interfaces en los sistemas distribuidos Interfaces de servicio Interfaces remotas Los lenguajes de definición de interfaces (IDL) están diseñados para permitir que los objetos implementados en lenguajes diferentes se invoquen unos a otros. Ejem: CORBA IDL, Sun XDR. Modelo de Objetos Un programa OO consta de un conjunto de objetos que interactúan entre ellos. Cada objeto se compone de un conjunto de datos y un conjunto de métodos. Un objeto se comunica con otro objeto invocando sus métodos, generalmente pasándole argumentos y recibiendo resultados Se puede acceder a los objetos mediante referencias a objetos. Modelo de Objetos La interfaz define las firmas o signatures de los métodos (nombre, tipos de sus argumentos, valores devueltos y excepciones) sin especificar su implementación. Se manejan excepciones Se hace necesario proporcionar mecanismos de liberación del espacio ocupado por aquellos objetos que ya no lo necesitan (compactación automática de la memoria) 3 Modelo de Objetos Distribuidos En el modelo C/S, los objetos son administrados por servidores y sus clientes invocan sus métodos utilizando una invocación de métodos remota (RMI) Cuando el cliente invoca un método de un objeto remoto, se envía un mensaje al servidor que lo administra. Modelo de Objetos Distribuidos Cada proceso contiene un conjunto de objetos, algunos de los cuales pueden recibir tanto invocaciones locales como remotas. Otros objetos sólo pueden recibir invocaciones locales. Invocación Remota Invocaciones locales Invocación Remota C A B D E Objeto Remoto Objeto Remoto Modelo de Objetos Distribuidos La invocación se lleva a cabo ejecutando el método del objeto en el servidor y el resultado se devuelve al cliente en otro mensaje. 4 Modelo de Objetos Distribuidos Existen dos conceptos fundamentales: Referencia de objeto remoto: Otros objetos pueden invocar los métodos de un objeto remoto si tienen acceso a su referencia de objeto remoto. Las referencias a objetos remotos se pueden pasar como argumentos y resultado de las invocaciones de métodos remotos. Modelo de Objetos Distribuidos Interfaz remota: Cada objeto tiene una interfaz remota que especifica cuáles de sus métodos pueden invocarse remotamente. El sistema CORBA proporciona un IDL que permite definir interfaces remotas. Las clases de los objetos remotos y los programas de los clientes pueden implementarse en cualquier lenguaje. Los clientes CORBA no tienen que estar en el mismo lenguaje que el objeto remoto. Invocación Remota Invocaciones locales Invocación Remota C A B Interfaz Remoto D E Interfaz Remoto Modelo de Objetos Distribuidos Una invocación a un método remoto debe ser capaz de lanzar excepciones. CORBA IDL proporciona una notación para las excepciones. 5 Corba: un estándar para construir objetos distribuidos. Object Management Group (OMG) ¾ Es un consorcio internacional que promueve el desarrollo de software orientado por objetos ¾ El objetivo del OMG es proveer un marco de arquitectura común para permitir la interacción de objetos en plataformas heterogéneas y distribuidas. Object Management Group (OMG) ¾ Fue fundado en 1989. ¾ Inicialmente estuvo conformado por 8 compañías: 3Com Corpotation, American Airlines, Canon Inc., Data General, HewlettPackard, Philips Telecommunications N.V., Sun Microsystems y Unisys Corporation. ¾ Actualmente hay más de 500 miembros 6 Object Management Group (OMG) ¾ El OMG no realiza trabajos de desarrollo e implementación, más bien se basa en la tecnología existente ofrecida por sus miembros. ¾ Propone especificaciones para el desarrollo de computación distribuida basada en objetos: OMA (Object Management Architecture). Object Management Architecture (OMA) ¾ OMA es una arquitectura de referencia sobre la cual se pueden construir aplicaciones. ¾ Define, a un nivel alto de abstracción las “facilidades” necesarias para el desarrollo de aplicaciones distribuidas orientadas por objetos. Object Management Architecture (OMA) Ofrece dos modelos fundamentales, en los cuales se basan CORBA y otras interfaces standard: Core Object Model: conjunto abstracto de conceptos que permiten comprender los objetos y sus interfaces. Los conceptos no pueden redefinirse o reemplazarse, sólo extenderse si es necesario para hacerlos más concretos. Relevante para los que implementan ORB´s Modelo de Referencia: marco arquitectónico para el desarrollo de aplicaciones. 7 Core Object Model Sus principales metas son: interoperabilidad y portabilidad Portabilidad: conocimiento de las interfaces de los objetos y la capacidad de crear aplicaciones cuyos componentes no confían en la existencia o localización de una implementación de objeto particular. Core Object Model Interoperabilidad: capacidad de invocar operaciones en los objetos sin importar dónde se ubican, sobre qué plataforma se ejecutan o en qué lenguaje de programación se implementaron. Esto se logra mediante el Object Request Broker. Core Object Model Conceptos Objetos Operaciones, Firmas, parámetros, valores de retorno Tipos que no son objetos Interfaces Reemplazabilidad Herencia 8 Core Object Model Objetos: modelos de entidades o conceptos. Un objeto puede modelar un documento, una fecha, un empleado, un compilador. Operaciones, Firmas, parámetros, valores de retorno: Operación: es un comportamiento que ofrece el objeto, el cuál se conoce “afuera” a través de la firma. Los nombres de las operaciones son únicos dentro de un objeto particular. Una referencia a un objeto puede devolverse como el resultado de una operación. Las Operaciones pueden causar cambios en el estado del objeto. Si un objeto no puede procesar un requerimiento retorna una excepción. Core Object Model Tipos que no son objetos: se llaman tipos de datos Interfaz: es una colección de firmas. Es el conjunto de operaciones que ofrece el objeto. Capacidad de Reemplazo: un objeto que ofrece una interfaz puede usarse en el lugar de otro objeto con una interfaz similar. Core Object Model Herencia: Si una interfaz A hereda de una interfaz B, A ofrece todas las operaciones de B y puede ofrecer operaciones adicionales. 9 El Modelo de Referencia Es un marco arquitectónico que estandariza las interfaces para la infraestructura y los servicios que una aplicación puede usar. El Modelo de Referencia Objeto CORBA Wrapper para una aplicación Legacy Common Facilities Application Objects Object Request Broquer (ORB) Object Services Domain Objects El Modelo de Referencia ¾ ORB (intermediario de petición de objetos) Permite o facilita la comunicación entre objetos. La tecnología adoptada para los ORBs es lo que se conoce como CORBA. Common Facilities Application Interfaces Object Request Broquer (ORB) Object Services 10 El Modelo de Referencia Corba (Common Object Request Broker Architecture) es un diseño de middleware que permite que los programas de aplicación se comuniquen unos con otros con independencia del lenguaje de programación, sus plataformas de hw y sw, las redes sobre las que se comunican y sus implementadores. ORB Provee: Una extensión del Core, que incluye la sintáxis y semántica de un IDL (Interface Definition Language) Un entorno para interoperabilidad, que incluye dos definiciones de protocolo Un conjunto de Mappings desde el IDL a un subconjunto de lenguajes: C, C++, COBOL, Smalltalk, Ada95, Java, Lisp y Python. Object Services ¾ Object Services: definen un conjunto de objetos que implementan servicios fundamentales de bajo nivel que los desarrolladores de aplicaciones pudieran necesitar para administrar sus objetos y datos. Los servicios incluyen: servicio de nombres, seguridad, persistencia, ejecución concurrente y transacciones, etc. Permiten a los desarrolladores construir aplicaciones sin tener que reinventar la rueda. Application Objects Common Facilities Object Request Broquer (ORB) Object Services Domain Objects 11 Modelo de Referencia Common Facilities (CF): son servicios genéricos de más alto nivel orientados a las aplicaciones (Intercambio de Datos, facilidades para imprimir, almacenamiento de información, etc.). ¾ Domain Interfaces: interfaces desarrolladas para aplicaciones en particular (telecomunicaciones, Internet, Salud) . Estos objetos hacen uso del resto de los componentes. ¾ CORBA Fue creada en 1991 (Corba 1.1). propone una implementación específica del ORB (IDL) ¾ En 1994 surge CORBA 2.0 (1994), que definió estándares para permitir la comunicación entre implementaciones realizadas por desarrolladores diferentes. Este estándar se denomina GIOP (General Inter-ORB Protocol). ¾ CORBA 3.0 (1997) incrementa interoperabilidad y funcionalidad (POA) ¾ Modelo de Objetos CORBA Los clientes no son necesariamente objetos; un cliente podrá ser cualquier programa que envía mensajes de petición a objetos remotos y recibe respuestas. El término objeto CORBA se refiere a objetos remotos. Un objeto CORBA implementa una interfaz IDL, tiene asociado una referencia de objeto remoto y es capaz de responder a las invocaciones de los métodos en su interfaz IDL. Se puede implementar un objeto CORBA en un lenguaje que no sea OO. 12 Modelo de Objetos CORBA Qué ofrece: Interfaces independientes de las implementaciones a objetos implementados en diversos lenguajes de programación. Acceso a los objetos sin importar su localización (transparencia) Generación de código automática para manejar invocaciones remotas. Acceso a los servicios y facilidades de CORBA: Acceso Corba IDL IDL: Interface Definition Language La interfaz especifica un nombre y un conjunto de métodos que podrán utilizar los clientes. ¾ Es un lenguaje declarativo ¾ Define tipos de objetos especificando sus interfaces estáticas ¾ Sintaxis derivada de C++ con palabras adicionales Enfoque CORBA: IDL // Ejemplo de especificación de IDL: forma.idl y ListaForma.idl struct Rectangulo { long ancho; long alto; long x; long y; }; struct ObjetoGrafico{ string tipo; Rectangle enmarcado; boolean estaRelleno; }; interface Forma { long dameVersion(); ObjetoGrafico DameTodoEstado(); }; Typedef sequence <Forma, 100> Todo Interface ListaForma { exception ExceptionLlena{}; Forma nuevaForma(in ObjetoGrafico g) raises (ExceptionLlena) Todo TodasFormas(); long dameVersion(); }; Lista de Ref. a objetos CORBA 13 Enfoque CORBA: IDL Los parámetros se etiquetan como in, out, inout. in: se pasa del cliente al objeto CORBA invocado. out: lo devuelve el objeto CORBA inout: el valor de este parámetro puede pasarse en ambas direcciones. Enfoque CORBA: IDL Si no se devuelve ningún valor el tipo retornado se coloca como void. Oneway indica que el cliente que invoca el método no se bloqueará mientras el destino lleva a cabo el método. Cuando se lanza una excepción que contiene variables, el servidor puede utilizar las variables para devolver información al cliente sobre la excepción. oneway void retrollamada (in int version) exception ExceptionLlena{}; exception ExceptionLlena{ObjetoGrafico g}; Semántica de las operaciones La invocación remota en CORBA define, por defecto, la semántica como máximo una vez. Si una operación retorna exitosamente, se garantiza que se ejecutó exactamente 1 vez. Si retorna una excepción fue ejecutada a lo sumo 1 vez. 14 Enfoque CORBA: IDL Value Tipos IDL Constructed value Object Reference array struct sequence Basic Values Integer Union Float Point Short Long UshortUlong Float Double char string octal boolean any enum La Arquitectura de CORBA in args Operation() CLIENT OBJECT IMPLEMENTATION out args + return value Request ORB La Arquitectura de CORBA INTERFACE REPOSITORY IDL COMPILER CLIENT DII IDL STUBS IMPLEMENTATION REPOSITORY SERVANTS ORB INTERFACE IDL SKELETON DSI OBJECT ADAPTER GIOP/IIOP ORB CORE 15 La Arquitectura de CORBA Client REQUEST DII ¾IDL IDL Stub Stubs (resguardos o proxies): ORB Core Funciones generadas desde la interfaz IDL para “enlazarlas” a los clientes Provee una interfaz de invocación estática ¾Dynamic Invocation Interface (DII) Permite especificar y construir requerimientos a tiempo de ejecución Operaciones: create_request, invoke, send, get_response El cliente especifica el objeto, la operación y los parámetros. Se obtienen a través del repositorio de interfaz. Enfoque CORBA ¾IDL Skeleton (Esqueletos): Funciones generadas desde la interfaz IDL para “enlazarlas” a las implementaciones de objetos Desempaqueta los argumentos y empaqueta las excepciones. ¾Dynamic Skeleton Interface (DSI) Análogo al DII del lado de la implementación de objetos . El Cliente especifica el objeto, la operación y los parámetros. Éstos Se obtienen a partir del repositorio de Interfaces. Servant IDL Sk DSI ORB Interface Object Adapter ORB Core Arquitectura de CORBA ¾ ORB Interface: Provee funciones para acceder directamente al ORB core desde los clientes y desde las implementaciones de objetos List_initial_services() Resolve_initial_references() Estas funciones se utilizan para obtener una referencia al POA. Operaciones que permiten su arranque y parada. (orb_init()) se provee para obtener una referencia a un pseudo-objeto ORB. Operaciones para la transformación entre referencias a objetos remotos y cadenas de texto. 16 Arquitectura de CORBA ¾ Repositorio de Interfaces (Interface Repository): Su información permite que un programa encuentre un objeto cuya interfaz no conoce en tiempo de compilación ¾ Repositorio de Implementaciones (Implementation Repository): Contiene información que permite al ORB core localizar y activar implementaciones de objetos Funciones de un Adaptador de Objetos Genera referencias a objetos que se registran en CORBA. IOR (Interoperate object reference) Otorga a cada objeto CORBA un único nombre que forma parte de su referencia a objeto remoto. Medio de comunicación entre implementaciones de objetos y el ORB core. Despacha cada RMI vía un Servant esqueleto hacia el sirviente apropiado. IDL Sk DSI Activación/Desactivación de objetos ORB Interface Object Adapter Incarnation/etherealization de Sirvientes ORB Core Funciones de un Adaptador de Objetos El ORB y el OA cooperan para permitir que las aplicaciones clientes invoquen métodos de objetos CORBA y aseguran que cada objeto CORBA se asocie a un sirviente. El ORB y el OA cooperan para, de forma transparente, localizar e invocar a los sirvientes adecuados, una vez que se tiene la información en las referencias. 17 Funciones de un Adaptador de Objetos ¾ Diferentes OAs pueden soportar diferentes estilos de implementación de sirvientes. Por ejemplo, el Orbix Object Database Adapter Framework, permite implementar objetos usando una base de datos OO. Otro ejemplo es el Real Time Object Adapter (objetos a tiempo real.) Estructura de un Adaptador de Objetos Algunas limitaciones (BOA) ¾ No especifica cómo deben ser los esqueletos o cómo deben asociarse los sirvientes a los esqueletos. ¾ No especifica cómo se deben registrar los sirvientes en el OA. Al no estar estos puntos explícitos se pierde portabilidad porque cada persona que implementa un ORB lo hace de forma distinta. ¾ No se establece nada respecto a servidores multithreading. Estructura de un Adaptador de Objetos POA: facilita la portabilidad de los servidores CORBA. ¾ ¾ ¾ Identificador de objetos Objetos persistentes y transitorios Activación asociada al objeto, no al servidor. ¾ Explícitamente se soportan servidores multithreaded. ¾ Existen otras diferencias (Schmidt and Vinosky) 18 Estructura de un Adaptador de Objetos ¾ Tiene tres interfaces diferentes: Una interfaz privada para el esqueleto (envío de respuestas) Una interfaz privada para el núcleo (llamadas al objeto) Una interfaz pública para las implementaciones de objetos (registro) Estructura de un Adaptador de Objetos Sirviente: una implementación de objeto que provee una semántica a tiempo de ejecución para uno o más objetos CORBA. ¾ Object ID: identificador de objeto, único con respecto a un POA. ¾ Mapa de Objetos Activos: asociación entre identificadores de objetos y sirvientes. Permite direccionar los requerimientos al objeto adecuado. ¾ Estructura de un Adaptador de Objetos Incarnate: proveer un sirviente (running servant) para servir los requerimientos particulares a un objeto. Etherealize: destruir la asociación entre el sirviente y el objeto. Default Servant: un objeto que atenderá los requerimientos para objetos cuyos identificadores no están en la tabla. 19 POA Puede haber más de un POA activo en un servidor particular. Siempre existe un rootPOA a partir del cual se crean todos los otros. Cada POA tiene asociados un conjunto de políticas que se pueden modificar una vez que el POA se crea. Todos los objetos que maneja un POA están sujetos a las mismas políticas. POA: políticas Unicidad del ID: determina si se puede asociar más de un objeto al mismo sirviente. Asignación del ID: determina quién asigna el identificador del objeto: el programador o el POA. Tiempo de vida: determina si los objetos son transitorios o persistentes, i.e. si los objetos están disponibles al cliente una vez que se destruye el POA. POA: políticas Retención de Sirvientes: Determina si el POA mantiene asociaciones Sirviente-Objeto en un mapa (Active Object Map), o confía en un sirviente por defecto o posee servant locators para encontrar los sirvientes adecuados en cada requerimiento. Procesamiento de requerimientos: determina si el POA utiliza el mapa, el sirviente por defecto, los locators o combinaciones de estos mecanismos : para localizar el sirviente una vez que viene un requerimiento. Existen dos objetos adicionales: Servant Activator: Un objeto que el POA usa para encarnar los sirvientes. Servan Locator: se usa para obtener un sirviente e invocar una operación. 20 POA: políticas Politica de threads: si la implementación es multi-threading o no. Activación de Sirvientes implícita: si se puede activar a un sirviente de forma implícita cuando se crea una referencia a un objeto. Referencia a Objetos Un objeto CORBA puede identificarse, localizarse y direccionarse por su referencia a objeto. Nombre de tipo de Interfaz IDL Protocolo y dirección detallada Nombre de Identificador en el repositorio IIOP Dominio del host de interfaz Número de puerto Clave del Objeto Nombre del Nombre o adaptador ID del objeto Inter-Operabilidad ¾ Es necesario que inter-operen los ORB´s de diversos fabricantes. ¾ Las barreras no son sólo de implementación sino relacionadas con la seguridad. ¾ Dominios: son un conjunto de objetos, los cuales, por alguna razón de implementación o administrativa están separados de otros objetos. 21 Inter-Operabilidad ¾ El protocolo General Inter-ORB (GIOP) satisface las necesidades de comunicación entre ORB´s y trabaja sobre cualquier protocolo de transporte. ¾ La implementación del GIOP que funciona sobre TCP/IP se denomina Internet Inter-ORB Protocol (IIOP) Semánticas de Ejecución y Modelos de interacción ¾ Semánticas: ¾ At-most-once ¾ Best effort (oneway): no se espera ningún resultado ¾ Modelos de interacción: ¾ Con la interfaz estática: Operaciones síncronas, oneway ¾ Con la interfaz dinámica: síncrona, síncrona diferida, oneway. Implementaciones de ORBs ¾ Rutinas residentes en el cliente y en la implementación de objeto. ¾ Basado en un Servidor: los clientes se comunican con uno o mas procesos servidores que enrutan los requerimientos hacia las implementaciones de objetos. ¾ Basado en el Sistema: el ORB es un servicio del sistema operativo. 22 CORBA Ejemplo del uso de comunicación de objetos usando CORBA, con la implementación JAVAORB. Principales componenetes de la arquitectura: Cliente, ORBs, Adaptador de Objetos, Servant, Servidor de Nombres. Los objetos que se comunican están programados en JAVA. Archivo Bibliografía CORBA: A Platform for Distributed Object Computing. Zhonghua Yang and Keith Duddy. Objet Interconnections. Object adapters: Concepts and Terminology. Douglas Schmidt and Steve Vinosky. SIGS C++ Report magazine 1997. Sistemas Distribuidos Conceptos y Diseño. Coulouris, Dollimore and Kindberg. Tercera Edición. Addison Wesley. Bibliografía Java Programming with CORBA. Advanced Techniques for Building Distributed Applications. G. Brose, A. Vogel, K. Duddy. 23