Programación Orientada por Objetos

Transcripción

1 Sistemas Basados en Objetos Distribuidos CORBA: Un caso de Estudio Prof. Mariela Curiel Sept-Dic 2009 Basado en el Capítulo del mismo nombre de Tanenbaum y Van Steen. 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 (RPC) Invocación a un método remoto (RMI) Modelo de programación basado en eventos (Ejem. Java Beans) 1

2 Programa Distribuido (RPC) Computador 1 Comp. local Cliente Comp. remoto Funciones del Servidor main Computador 2 func() func(void ){ } proc 1 proc 2 proc 3 proc 4 proc 5 Thread de ejecución Thread bloqueado Llamada a proc. remota Proceso en el Cliente Proceso en el Servidor Cliente llamada retorno Remota Stub del Cliente Llamada y retorno lógico Funciones del Serv. llamada retorno Stub del Servidor Req. Marshaled Retorno Marshaled Req. Marshaled Retorno Marshaled Servicios de red Red Servicios de red kernel del cliente Kernel del servidor Proceso en el Cliente Cliente llamada retorno Remota Infaz. cliente Stub del Cliente Comm. Cliente Req. Marshaled Retorno Marshaled Proceso en el Servidor Funciones del Serv. llamada retorno Infaz. servidor Req. Marshaled Comm. servidor Retorno Marshaled Servicios de red RPC Servicios de red kernel del cliente Kernel del servidor 2

3 Qué deseamos hacer con objetos remotos? Cliente Result = Obj.method1(val1) Servidor Def Obj { int method1(int v) {} string method2(string v) {} int method3(int v) {} int method4(int v) {} } 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 (estado) y un conjunto de métodos. Los métodos se ponen a disposición mediante una interfaz. Dada una definición de interfaz, puede haber varios objetos que ofrezcan una forma de implementarla. Esta separación entre interfaces y objetos que las implementan es crucial en los SD. Se pudieran colocar las interfaces en una máquina, mientras que el objeto reside en otra. Objectos Distribuidos Figure Common organization of a remote object with client-side proxy. 3

4 Objetos Distribuidos El estado de un objeto distribuido reside en una sola máquina, solamente las interfaces están disponibles en varias máquinas. Estos objetos también se conocen como objetos remotos. Modelo de Objetos Distribuidos La interfaz define las firmas o signatures de los métodos (tipos de sus argumentos, valores devueltos y excepciones) sin especificar su implementación. Modelo de Objetos 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. 4

5 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. A Invocación Remota Invocaciones locales Invocación Remota C B D E Interfaz Remoto Interfaz Remoto 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. 5

6 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. Objetos Distribuidos Objetos a tiempo de ejecución vs objetos a tiempo de compilación Objetos a tiempo de compilación: son objetos soportados por el lenguaje de programación (C++, Java, etc). En este caso el objeto se define como una instancia de una clase. Una clase es una descripción de un tipo abstracto de datos. Objetos Distribuidos Objetos a tiempo de compilación: Un objeto se define mediante su clase y las interfaces que implementa. Las interfaces pueden compilarse en resguardos del lado del cliente y del servidor, lo cual permite la invocación remota de objetos. Desventaja: dependencia de un lenguaje de programación. 6

7 Modelo de Objetos Distribuidos Tiempo de compilación vs tiempo de ejecución Otra forma de construir objetos es hacerlo a tiempo de ejecución. Se puede implementar de cualquier forma. Puede ser una librería de funciones en C que acceden a un archivo de datos, pero cómo hago que parezcan métodos de un objeto??? Uso un adaptador de objetos, es como una envoltura sobre la implementación para darle forma de objeto. El adaptador se comunica con la librería de C y abre un archivo de datos que representa el estado actual del objeto. Objetos Distribuidos Este método se sigue en muchos sistemas distribuidos basados en Objetos (Corba). Es independiente del lenguaje de programación en el que están escritas las aplicaciones distribuidas. Los objetos pueden escribirse en varios lenguajes. Objetos Distribuidos Los objetos deben registrarse con el adaptador quién posteriormente hace que la interfaz esté disponible para invocaciones remotas. 7

8 Objetos Distribuidos Objetos Persistentes y Transistorios Objetos Persistentes: continúan existiendo aun cuando ya no esté contenido en el espacio de direcciones de cualquier proceso servidor. El servidor puede almacenar el objeto en memoria secundaria y después terminar. Objetos Distribuidos Objetos Transistorios: un OT existe sólo en tanto el servidor que lo está alojando exista. Modelo de Objetos Distribuidos Procesos: Servidores de Objetos. Un servidor de objetos es un servidor diseñado para soportar objetos distribuidos. La diferencia más importante entre un servidor general y un servidor de objetos, es que un servidor de objetos no proporciona por sí mismo un servicio específico. Los servicios son implementados por los objetos que existen en el servidor. Al cambiar los objetos cambian los servicios. 8

9 Modelo de Objetos Distribuidos Cada proceso servidor contiene un conjunto de objetos, algunos de los cuales pueden recibir tanto invocaciones locales como remotas. Otros objetos sólo pueden recibir invocaciones locales. A Invocación Remota Invocaciones locales Invocación Remota C B D E Objeto Remoto Objeto Remoto Modelo de Objetos Distribuidos Un servidor puede tener un solo hilo de control para atender todas las solicitudes. Tener varios hilos de control, uno por cada objeto que maneja. Si llega una solicitud al método de un determinado objeto se pasa al hilo correspondiente, si está ocupado, se encola la solicitud. Los objetos quedan protegidos contra acceso concurrente, las invocaciones se serializan a través del hilo correspondiente. Servidores de Objetos: Políticas Objetos Transitorios: Crearlo a la primera solicitud de invocación y destruirlo en cuanto ya ningún cliente esté ligado a tal objeto. Crear todos los objetos transitorios en el momento en el que el servidor se inicializa (nungún cliente pudiera utilizar el objeto). 9

10 Servidores de Objetos: Políticas Colocación de los Objetos en la Memoria: Cada objeto tiene su propio espacio de direcciones, los objetos no comparten el código ni los datos (útil cuando los objetos tienen que separarse por razones de seguridad). Permitir que los objetos compartan el código. Una BD que contiene objetos pertenecientes a la misma clase puede ser implementada eficientemente si la clase se carga sólo una vez en el servidor. Cuando llega una solicitud de invocación, el servidor sólo necesita buscar el estado del objeto. Servidores de Objetos: Políticas Hilos: Implementar el servidor con un solo hilo de control. Tener varios hilos, uno por cada objeto. Los objetos quedan protegidos automáticamente contra acceso concurrente. Servidores de Objetos: Políticas Servidores También es posible utilizar un hilo por cada solicitud de invocación. En este caso los objetos deben estar protegidos para el acceso concurrente. Crear hilos por demanda o tener un conjunto fijo de hilos. 10

11 Adaptador de Objetos Las políticas anteriores se conocen como políticas de activación, para enfatizar que la mayoría de las veces el objeto debe ser llevado primero al espacio de direcciones del servidor (activado) antes de que puedan invocarse sus métodos. Adaptador de Objetos Se requiere entonces un mecanismo para agrupar objetos por política de activación. Tal mecanismo es lo que se conoce como adaptador de objetos. El adaptador es un software que implementa una política de activación específica. Un adaptador controla uno o más objetos Adaptador de Objetos Varios adaptadores de objetos pueden residir en un servidor al mismo tiempo. El adaptador de objeto no tiene conocimiento de las interfaces específicas de los objetos que controlan (si así fuera no podrían ser genéricos). Un adaptador de objetos extrae una referencia a objeto de una solicitud de invocación y posteriormente despacha la solicitud al objeto referido. 11

12 Adaptador de Objetos En lugar de pasar la solucitud directamente al objeto la pasa al resguardo del lado del servidor. Sirviente: es el término usado para la implementación del objeto Server with three objects Server machine Object's stub (skeleton) Object adapter Object adapter Local OS Request demultiplexer Comunicación Vinculación de un Cliente a un Objeto. - Los sistemas RPC tradicionales que soportan objetos distribuidos proporcionan referencias a objetos a través de todo el sistema. - Las referencias pueden pasarse como parámetros de invocaciones remotas o ser valores de retorno. 12

13 Comunicación Vinculación de un Cliente a un Objeto. - Cuando un proceso tiene una referencia a un objeto, primero debe vincular al objeto referido antes de invocar a cualquiera de sus métodos. La vinculación hace que se coloque un proxy en el espacio de direcciones del proceso, y así se implementa una interfaz que contiene los métodos que se pueden invocar. La vinculación también se puede hacer automáticamente. Comunicación Vinculación de un Cliente a un Objeto. Vinculación Implícita: al cliente se le ofrece un mecanismo simple que le permite invocar directamente los métodos utilizando sólo la referencia a objeto. C++ se sobrecarga el operador -> y se utilizan referencias a objetos como si fueran apuntadores ordinarios. El cliente se vincula automáticamente al objeto. Comunicación Vinculación de un Cliente a un Objeto. Vinculación Explícita: el cliente debe invocar una función especial para ligarse al objeto antes de que pueda invocar sus métodos. La vinculación explícita regresa un apuntador a un proxy que luego llega a estar localmente disponible. 13

14 Distr_object obj_ref; // Referencia a objeto distribuido, abarca todo el sistema obj_ref =...; // Inicializar una referencia a un objeto distribuido obj_ref->do_somthing(); // Vincular e invocar implícitamente un método- Ejemplo de Vinculación Implícita. Distr_object obj_ref; // Referencia a objeto distribuido, abarca todo el sistema Local_object* obj_ptr; // Apuntador a objetos locales. obj_ref =...; // Inicializar una referencia a un objeto distribuido obj_ptr = bind(obj_ref); // Vinculación explícita. obj_ptr->do_something() // Invocar el método en el proxy local Ejemplo de Vinculación Explícita Comunicación Invocaciones a Métodos Remotos: Estáticas Vs. Dinámicas. - Invocaciones Estáticas: Invocar al objeto usando las definiciones que se ofrecen en la interfaz. Se requiere que se conozcan las interfaces de los objetos, cuando la aplicación del cliente se está desarrollando. - Si cambian las interfaces, la aplicación tiene que recompilarse. try { Calculator c = (Calculator) Naming.lookup( "rmi://remotehost /CalculatorService"); System.out.println( c.sub(4, 3) ); System.out.println( c.add(4, 5) ); Comunicación Invocaciones a Métodos Remotos: Estáticas Vs. Dinámicas. - Invocaciones Dinámicas: Se puede componer la invocación a un método a tiempo de ejecución. La diferencia es que la aplicación selecciona, a tiempo de ejecución, qué método invocará de un objeto remoto. 14

15 Comunicación Invocaciones a Métodos Remotos: Estáticas Vs. Dinámicas. Una invocación dinámica adopta la siguiente forma: Invoke(object, object_method, input.parameters, out_put.parameters) Comunicación Invocaciones a Métodos Remotos: Estáticas Vs. Dinámicas. Estática: fobject.append(int) Dinámica: invoke(fobject, id(append), int) Pase de Parámetros Sistema donde sólo existen objetos distribuidos (presentan una interfaz remota). En este caso se pueden utilizar consistentemente las referencias a los objetos comó parámetros de invocaciones remotas. Las referencias son pasadas por valor y por lo tanto copiadas de una máquina a otra. Cuando un proceso recibe una referencia a objeto, se vincula a él y lo utiliza. 15

16 Pase de Parámetros Sistemas dende existen objetos locales y remotos Las referencias a objetos remotos y las referencias a objetos locales a menudo se tratan de forma distinta. Si se invoca a un método con una referencia a objeto como parámetro, dicha referencia se copia y pasa como un parámetro por valor sólo cuando se refiere a un objeto remoto. Cuando dicha referencia se refiere a un objeto local (un objeto situado en el mismo espacio de direcciones del cliente) el objeto referido se copia en su totalidad y se pasa junto con la invocación. Machine A Machine B Local reference L1 Local object O1 Remote reference R1 Remote object O2 Client code with RMI to server at C (proxy) New local reference Copy of O1 Remote invocation with L1 and R1 as parameters Machine C Copy of R1 to O2 Server code (method implementation) Comunicación Síncrona y Asíncrona Una invocación de método asíncrona es análoga a un RPC asíncrono: el invocador continua después de realizar la invocación sin esperar el resultado. CORBA ofrece comunicación asíncrona a través del modelo de llamada automática. 16

17 Comunicación Síncrona y Asíncrona Un cliente proporciona un objeto que implementa una interfaz que contiene métodos de llamada automática. Estos métodos pueden ser invocados por el sistema de comunicación subyacente para pasar el resultados de una invocación asíncrona. Las invocaciones asíncronas no afectan no afectan la implementación del objeto, en otras palabras es responsabilidad del cliente el transformar una invocación síncrona original en una invocación asíncrona. Comunicación Síncrona y Asíncrona Cómo se implementa: la interfaz original, tal y como la implementa el objeto se reemplaza por dos nuevas interfaces que deben ser implementadas únicamente por el software del lado del cliente. Una interfaz contiene el/los métodos que el cliente invoca. Ninguno de estos métodos regresa ningún valor. La segunda interfaz es la automática y para cada operación de la interfaz anterior contiene un método que será invocado por el sistema subyacente para pasar al cliente los resultados de la invocación del método. Comunicación Síncrona y Asíncrona Ejemplo: intadd (in inti, in intj, out intk) Método que ofrece el objeto en el servidor void sendcb_add(in int i, in int j) // LLamada realizada por el cliente void replycb_add(in int ret_val, in int k) // Upcall al cliente 17

18 Comunicación Síncrona y Asíncrona Posteriormente se compilan las intefaces generadas. Al cliente se le ofrece un resguardo que le permite invocar sendcb_add. El cliente debe proporcionar una implementación para la interfaz de llamada automática replycb_add. 1. Call by the application Client proxy Client RTS Client application Callback interface 4. Call by the RTS 3. Response from server 2. Request to server Comunicación Síncrona y Asíncrona Como alternativa de las llamadas automáticas, CORPA ofrece un modelo encuestador. En éste se le ofrece al cliente un conjunto de operaciones útiles para interrogar a su sistema a tiempo de ejecución (RTS) local sobre los resultados entrantes de una invocación previa. 18

19 Comunicación Síncrona y Asíncrona Ejemplo: intadd (in inti, in intj, out intk) void sendcb_add(in int i, in int j) // LLamada realizada por el cliente void replypoll_add(out int ret_val, out int k) // También invocado por el cliente Comunicación Síncrona y Asíncrona El método replypoll_add tendrá que ser implementado por el RTS Client application 1. Call by the application Client proxy Polling interface 4. Call by the application Client RTS 3. Response from server 2. Request to server Sincronización En sistemas orientados por objetos, los detalles de implementación se encuentran ocultos detrás de las interfaces. Cuando un proceso invoca a un objeto remoto, no sabe si dicha invocación conducirá a la invocación de otros objetos. 19

20 Sincronización Si uno de esos objetos está protegido contra accesos concurrentes puede ser que tenga un conjunto de locks de los que el proceso invocador no esté al tanto. Por el contrario, cuando se trata de un proceso solicitando recursos, el proceso puede ejercer más control en tiempo de ejecución cuando las cosas van mal, tal como renunciar a los candados (si las llamadas se lo permiten) Process Object Process Lock Object Unlock (a) (b) Sincronización En SD basados en Objetos es importante saber dónde ocurre la sincronización. Una ubicación evidente para la sincronización es en el servidor. Si llegan varias solicitudes en serie para el mismo objeto, el servidor puede decidir ponerlas en serie (pudiera hacerlo a través de hilos) 20

21 Sincronización También se pudiera hacer el bloqueo del lado del cliente utilizando soporte del lenguaje. Se bloquea al llamador en el cliente si está invocando un método sincronizado. Se tienen que sincronizar otros clientes en otras máquinas que estén accediendo al mismo método. La sincronización distribuida puede ser bastante compleja. Consistencia y Replicación Existen 2 temas a resolver para implementar la consistencia : Se requiere una forma de evitar el acceso concurrente de varias invocaciones al mismo objeto. Es decir, si se está ejecutando un método, ningún otro método dentro del mismo objeto puede estarse ejecutando. Este requerimiento garantiza la serialización de los datos internos del objeto. Consistencia y Replicación Existen 2 temas a resolver para implementar la consistencia : En el caso de que un objeto esté replicado, se debe garantizar que los cambios del estado del objeto replicado sean los mismos. Es decir, debemos garantizar que no ocurran dos invocaciones independientes a un método en diferentes réplicas al mismo tiempo. 21

22 Consistencia y Replicación Existen 2 temas a resolver para implementar la consistencia : Se tienen que ordenar las invocaciones a métodos de tal forma que todas las réplicas vean las invocaciones en el mismo orden. Este requerimiento se satisface de dos formas: 1. Utilizando el método basado en réplicas primarias 2. Mediante multitransmisión en orden total para las réplicas. Casos de Estudio Enterprise Java Beans Un EJB es un objeto Java alojado en un servidor especial que ofrece diferentes formas para que los clientes remotos lo invoquen. El servidor puede separar la funcionalidad orientada a la aplicación de la funcionalidad orientada al sistema. 22

23 Container Server EJB EJBEJB Services JMS JNDI JDBC RMI Server kernel Local OS Network EJB División de Trabajo: La posibilidad de dividir "Servicios"(EJB Container) de "Componentes Principales"(EJB'S) permite una clara división de trabajo, esto es, un diseñador de "componentes"(ejb's) puede concentrar sus esfuerzos en la "lógica de proceso" sin preocuparse del diseño de servicios. Y de la misma manera un "diseñador" de servicios("middleware") concentrarse en su área. EJB Los servicios típicos incluyen aquellos necesarios para la invocación de métodos remotos (RMI), el acceso a BD (JDBC), la asignación de nombres (JNDI) y la mensajería (JMS). 23

24 EJB Se distinguen 4 clases de EJB: 1. Beans de sesión sin estado. 2. Beans de sesión con estado 3. Beans de entidad 4. Beans dirigidos por mensajes EJB Beans de sesión sin estado: es un objeto transitorio que se invoca una vez, realiza su trabajo, tras de lo cual desecha cualquier información utilizada para realizar el servicio que ofrecía al cliente. EJB Beans de sesión con estado: matiene el estado relacionado con el cliente. Por ser un bean de sesión, cuando el cliente termina (posiblemente después de haber invocado al objeto varias veces) el bean se destruye. 24

25 EJB Beans de Entidad: es un objeto persistente de larga duración. Se guarda en una BD y normalmente forma parte de transacciones distribuidas. Típicamente guardan información que puede necesitarse la próxima vez que el cliente acceda al servidor (datos de un cliente: domicilio, tarjeta de crédito, etc). EJB Beans dirigidos por mensajes: se utilizan para programar objetos que deberán reaccionar a los mensajes que llegan. También son capaces de enviar mensajes. Modelo publicaciónsuscripción. Globe Es un sistema en el cual la escalabilidad desempeña un rol central. Metas: soporte a múltiples usuarios, funcionar en una red de área amplia. Al igual que otros sistemas orientados por objetos, en Globe se espera que los objetos encapsulen estado y operaciones incluidas en el estado. Pero..cada objeto determina cómo se distribuirá el estado entre sus réplicas. Cuándo y donde debe replicarse el estado. Un objeto puede además determinar su política de seguridad. 25

26 Globe: Modelo de Objetos A diferencia de la mayoría de los SD basados en objetos, no se adopta el modelo de objeto remoto. Los objetos pueden estar físicamente distribuidos, ello implica que el estado de un objeto puede distribuirse y replicarse a través de múltiples procesos. Modelo de objetos compartidos-distribuidos. Globe Distributed shared object Local object Network Process Interface Globe A un objeto que está ligado a un objeto compartido-distribuido se le ofrece una implementación local de la interfaz que provee dicho objeto 26

27 Same interface as implemented by semantics subobject Control subobject Replication subobject Semantics subobject Communication subobject Communication with other local objects Organización de un Objeto Local Subobjeto Semántica: implementa la funcionalidad provista por un objeto compartido distribuido. Corresponde a objetos remotos ordinarios, es similar a los EJB. Subobjeto comunicación: Provee una interfaz a la red subyacente. Ofrece varios primitivas de traspaso de comunicación. Existen subojetos de comunicación avanzados que implementan interfaces de multitransmisión. Organización de un Objeto Local Subobjeto replicación: implementa la estrategia de distribución para un objeto. Garantiza que todas las invocaciones a un método sean realizadas en el mismo orden en cada réplica. Subobjeto Control: exporta las interfaces del subobjeto semántica. Coordina las llamadas al sub-objeto semántica y al sub-objeto replicación. 27

28 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 Inicialmente estuvo conformado por 8 compañías: 3Com Corpotation, American Airlines, Canon Inc., Data General, Hewlett-Packard, Philips Telecommunications N.V., Sun Microsystems y Unisys Corporation. Actualmente hay más de 500 miembros 28

29 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 alto nivel de abstracción las facilidades necesarias para el desarrollo de aplicaciones distribuidas orientadas por objetos. Object Management Architecture (OMA) Posee 4 componentes: Application Interfaces Common Facilities Object Request Broker (ORB) Object Services 29

30 Object Management Architecture (OMA) 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 object request broker architecture) Application Interfaces Common Facilities Object Request Broker (ORB) Object Services Object Management Architecture (OMA) 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. Object Management Architecture (OMA) Object Services: definen un conjunto de objetos que implementan servicios fundamentales de bajo nivel como servicio de nombres, seguridad, persistencia, ejecución concurrente y transacciones, etc. Permiten a los desarrolladores construir aplicaciones sin tener que reinventar la rueda. Application Interfaces Common Facilities Object Request Broquer (ORB) Object Services 30

31 Object Management Architecture (OMA) Common Facilities (CF): son servicios de más alto nivel orientados a las aplicaciones (accounting, intercambio de información entre aplicaciones, correo electrónico o facilidades para imprimir). Application Interfaces: interfaces desarrolladas para aplicaciones en particular. Estos objetos hacen uso del resto de los componentes. OMG probablemente no llegue a desarrollar estándares de este tipo. 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 reciba 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. 31

32 Corba IDL IDL: Interface Definition Language La interfaz especifica un nombre y un conjunto de métodos que podrán utilizar los clientes. 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 referencia a objeto CORBA 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. 32

33 Enfoque CORBA: IDL Si no se devuelve ningún valor el tipo retornado se coloca como void. oneway void retrollamada (in int version) 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. exception ExceptionLlena{}; exception ExceptionLlena{ObjetoGrafico g}; CORBA: IDL Tipos IDL Value Object Reference Basic Values Constructed value struct Union sequence array Integer Float Point Short Long Ushort Ulong Float Double char string booleanoctal any enum 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. 33

34 La Arquitectura de CORBA CLIENT in args Operation() out args + return value OBJECT IMPLEMENTATION Request ORB La Arquitectura de CORBA INTERFACE REPOSITORY IDL COMPILER IMPLEMENTATION REPOSITORY CLIENT SERVANTS DII IDL STUBS ORB INTERFACE IDL SKELETON DSI OBJECT ADAPTER GIOP/IIOP ORB CORE Client REQUEST DII IDL Stub ORB Core IDL Stubs (resguardos o proxies): Funciones generadas desde la interfaz IDL (mediante un compilador de IDL) para enlazarlas a los clientes, en el lenguaje del cliente. Empaqueta los argumentos y desempaqueta las respuestas. 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, get_response, etc. El cliente especifica el objeto, la operación y los parámetros. Se obtienen a través del repositorio de interfaz (se tiene que poseer la referencia al objeto) 34

35 Enfoque CORBA IDL Skeleton (Esqueletos): Funciones generadas desde la interfaz IDL para enlazarlas a las implementaciones de objetos. Se generan mediante un compilado de IDL. Desempaqueta argumentos y empaqueta las respuestas y excepciones. Dynamic Skeleton Interface (DSI) Análogo al DII del lado de la implementación de objetos. Inspecciona la petición para descubrir el objeto destino, el método Servant que se invoca y los argumentos. DSI IDL Sk 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 Operaciones que permiten su arranque y parada Operaciones para convertir referencias a objetos remotos en cadenas de texto y viceversa. La Arquitectura de CORBA INTERFACE REPOSITORY IDL COMPILER IMPLEMENTATION REPOSITORY CLIENT SERVANTS DII IDL STUBS ORB INTERFACE IDL SKELETON DSI OBJECT ADAPTER GIOP/IIOP ORB CORE 35

36 Repositorio de Implementaciones (Implementation Repository): Contiene información que permite al ORB localizar y activar implementaciones de objetos Un IR almacena la correspondencia de los nombres de ciertos adaptadores de objeto con las rutas de los archivos que contienen las implementaciones de los objetos. Los objetos se registran en este repositorio cuando se instalan los servidores. Entrada en el repositorio de implementación: Nombre del Adaptador de Objetos Ruta de implemtación del objeto host y número de puerto Repositorio de Interfaces (Interface Repository): Su información permite que un programa encuentre un objeto cuya interfaz no conoce en tiempo de compilación. Para una interfaz puede aportar los nombres de los métodos, y para cada método los nombres y tipos de argumentos y las excepciones. Las aplicaciones que utilicen la invocación estática con resguardos en el cliente y esqueletos en el servidor no necesitan repositorio de interfaz. No todos los ORBs proporcionan repositorio de interfaz. Enfoque CORBA ADAPTADOR DE OBJETOS Servant ORB Interface IDL Sk DSI Object Adapter ORB Core 36

37 Funciones de un Adaptador de Objetos Genera referencias a objetos que se registran en CORBA. IOR (Interoperate object reference) Da 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. Despacha cada RMI vía un esqueleto hacia el sirviente apropiado (implementación del objeto) Activación/Desactivación de sirvientes utilizando el repositorio de implementación Funciones de un Adaptador de Objetos El ORB y el OA cooperan para permitir que las aplicaciones cliente 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. 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.) 37

38 Object Adapter Figure Organization of an object server supporting different OAs Estructura de un Adaptador de Objetos Adaptadores de Objetos adoptados por el estándar CORBA: Basic Object Adapter (BOA) Portable Object Adapter (POA) Referencia a un objeto remoto Una referencia es un identificador de objeto que puede usarse en todo el sistema distribuido y se refiere a un objeto único. 38

39 Referencia a Objetos Un objeto CORBA puede identificarse, localizarse y direccionarse por su referencia a objeto. Nombre de tipo de Interfaz IDL Identificador de repositorio de interfaz Protocolo y dirección detallada IIOP Nombre de Dominio del host Número de puerto Clave del Objeto Nombre del adaptador Nombre o ID del objeto Referencia a Objetos Las referencias pueden pasarse libremente entre los objetos de diferentes máquinas (como parámetros o valores de retorno) La referencia a un objeto debe contener suficiente información como para permitir que un cliente se vincule a un objeto. 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) Se unifica la definición de referencias. 39

40 Implementaciones de ORBs Residente en el cliente y en la implementación de objeto Basado en un Servidor Basado en el Sistema 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 Con la interfaz dinámica: síncrona, síncrona diferida, oneway. Servicios de CORBA Ciclo de vida de los objetos Manejo de nombres Persistencia Notificación de eventos Concurrencia y transacciones: lleva a cabo un protocolo de consumación de dos fases. Se emplean bloqueos para controlar accesos concurrentes a los objetos CORBA. Seguridad 40

41 Manejo de Nombres struct NameComponent {string id, string clase}; typedef sequence <NameComponent> Name; Interface NamingContext { void bind(int Name n, int Object obj); enlaza el nombre y la referencia en el contexto propio. Object resolve (in Name n); busca el nombre en el contexto y devuelve su referencia a objeto remoto. void unbind () ;.... } Interfaz IDL NamingContext del Servicio de Nombres de Corba. 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 Sistemas Distribuidos Conceptos y Diseño. Coulouris, Dollimore and Kindberg. Tercera Edición. Addison Wesley. 41