Ingeniería del software II

Objetos Distribuidos CORBA

IS II Sistemas Distribuidos - CORBA 1

IS II

¿Qué es CORBA?

  CORBA ( Common Object Request Broker Arquitecture) es un estándar para objetos distribuidos que ha sido desarrollado por el OMG ( Object Management Group)  http://www.omg.org/  http://www.corba.org/ El OMG es un consorcio formado actualmente por más de 800 empresas. Uno de sus objetivos es estandarizar la interoperabilidad de sistemas distribuidos Sistemas Distribuidos - CORBA 2

IS II

¿Qué es CORBA?

  El estándar CORBA define cosas como:  Un modelo de objetos   Como interaccionan los objetos Una arquitectura del sistema que soporta la interacción de objetos   Un lenguaje para definir los servicios que ofrecen los objetos Una serie de servicios básicos para aplicaciones distribuidas Existen diversas implementaciones del estándar CORBA como:  Orbix   Inprise VisiBroker JavaIDL Sistemas Distribuidos - CORBA 3

OMA (Object Management Arquitecture)  El OMG describió antes del lanzamiento de la primera versión de CORBA un modelo de gestión de objetos denominado OMA IS II Sistemas Distribuidos - CORBA 4

IS II OMA - ORB   El componente central de la especificación CORBA es el ORB. El ORB permite a objetos comunicarse con otros a través de sistemas heterogéneos ORB es la columna vertebral de CORBA, todas las comunicaciones entre objetos son mantenidas por el ORB, que conoce donde se encuentra situado cada uno de ellos y se encarga de proporcionar transparencia en las comunicaciones Sistemas Distribuidos - CORBA 5

OMA – Corba Services IS II    CORBA ofrece una colección de servicios para gestionar objetos, aumentar sus posibilidades y complementar sus características y comportamiento Cada servicio tiene su propia interface de IDL que le permite integrarse dentro del sistema CORBA Estos servicios proporcionan un gran abanico de posibilidades para mejorar los objetos y sus posibilidades. CORBA ha estandarizado varios de estos servicios Sistemas Distribuidos - CORBA 6

OMA – Corba Services IS II  Algunos servicios de CORBA:  Lyfe cicle service: Un objeto requiere operaciones tales como crear, copiar, mover y borrar datos de si mismo. Este servicio incluye todo este bucle de operaciones    Naming Service: Mediante este servicio los objetos pueden localizarse unos a otros por el nombre Persistent Service: Almacena componentes en determinadas formas dependiendo Event Service: Proporciona un mecanismo a través del cual los objetos puedes suscribirse y emitir eventos Sistemas Distribuidos - CORBA 7

IS II OMA – Corba Services  Más servicios...

 Trader Service           Transactions Service Concurrency Service Externalization Service Security Service Time Service Properties Service Query Service Licensing Service Relationship Service Collection Service Sistemas Distribuidos - CORBA 8

IS II OMA – Corba Facilities   Estas facilidades son componentes especificados mediante interfaces IDL que proporcionan servicios horizontales de alto nivel para ser utilizados directamente por las aplicaciones Dentro de estas facilidades se incluyen componentes para facilitar:  La construcción de interfaces de usuario   Servicios de información para la gestión Aplicaciones del sistema ( por ejemplo, e-mail).

Sistemas Distribuidos - CORBA 9

IS II OMA – Corba Domains 

Similares a las Corba Facilities, en este se trata de servicios verticales para diferentes dominios:

   Telecomunicaciones Finanzas Salud Sistemas Distribuidos - CORBA 10

IS II OMA – Objetos de aplicación 

Este tipo de interfaces son componentes específicos creados por el usuario siguiendo el formato IDL, son por tanto servicios específicos de cada aplicación y no están estandarizados por el OMG

Sistemas Distribuidos - CORBA 11

Arquitectura del ORB    Cuando recibe una petición de un servicio por parte de un cliente debe tratar con ella y encontrar el correspondiente objeto pedido en el correspondiente servidor, pasar los parámetros, invocar sus métodos y devolver el resultado si es necesario Se encarga también de guardar y almacenar la información necesaria en un IR ( interface repository) Los ORB's se pueden comunicar entre si a pesar de pertenecer a fabricantes distintos, a través del protocolo IIOP (Internet Inter ORB Protocol). De este modo desde un ORB se puede acceder a un objeto situado en otro ORB diferente IS II Sistemas Distribuidos - CORBA 12

Arquitectura del ORB IS II Sistemas Distribuidos - CORBA 13

Arquitectura del ORB   Stub: Proporciona interfaces estáticas para los servicios a objetos. Se encuentran en el cliente y servidor y son generados normalmente por el precompilador de la interface IDL IID (Interfaz Invocación Dinamica): Permite a los clientes realizar invocaciones en tiempo real. Un conjunto de métodos estándar son definidos para crear las operaciones envueltas en una petición. Existen métodos para localizar los objetos, obtener la interfaz del servidor, generar los parámetros, realizar las conexiones remotas y recibir los resultados IS II Sistemas Distribuidos - CORBA 14

Arquitectura del ORB   DSI (Dynamic Skeleton Interface): Es la parte analoga en el servidor al IID. Se encarga de responder a las invocacines dinamicas sobre objetos, las creadas sin un conocimiento del IDL en tiempo de compilación Skeleton IDL: Proporciona los skeletons necesarios para las llamadas estaticas a objetos. Estos skeletons son generados por el precompilador de IDL.

IS II Sistemas Distribuidos - CORBA 15

Arquitectura del ORB 

Object Adapter

 Genera referencias a objetos ( identificadores únicos) y las asigna a los objetos creados     Soporta las llamadas entrantes de los clientes y las envía a los stubs Autentifica las peticiones entrantes, de manera que para cada objeto, será fácilmente identificable el cliente Los objetos están siempre presentes para el sistema CORBA, pero no activos, por lo que no pueden ser llamados directamente. Antes de cualquier petición, el adaptador de objetos activa el elemento en cuestión Se encarga de mantener el IR (Interface Repositoy) IS II Sistemas Distribuidos - CORBA 16

Mecanismo de invocación estatico   Crear el servidor  Crear la interfaz IDL del servidor   Generar el skeleton para recibir peticiones estaticas Incluir el IDL en el Interface Repository Crear el cliente  Obtener la interfaz IDL del IR   Generar el stub del cliente Realizar las llamadas correspondientes a través del stub IS II Sistemas Distribuidos - CORBA 17

Mecanismo de invocación estatico 

Pasos de una invocación estatica:

El cliente llama al método correspondiente del stub         El stub empaqueta (marshalling) los parametros y los envia a través del ORB El ORB localiza el objeto servidor (servant) y avisa al Object Adapter El Object adapter activa el objeto y invoca al método a través del skeleton correspondiente El skeleton desempaqueta(unmarshalling) los parametros y invoca al método correspondiente en el objeto que implemente la interfaz.

El objeto ejecuta el método que implementa la interfaz y devuleve el resultado al skeleton El skeleton empaqueta la respuesta y la envia al cliente a través de ORB El stub del cliente desempaqueta los datos de la respuesta y se los entrega al objeto que invoco el método IS II Sistemas Distribuidos - CORBA 18

Mecanismo de invocación dinamico   Cuando los clientes están invocando dinámicamente objetos en el servidor, es necesario usar APIs de petición dinámica. La información necesaria se obtiene de la IR. Este método de petición proporciona un alto nivel de flexibilidad, permitiendo nuevos tipos de objeto ser añadidos al sistema en tiempo real Pasos para realizar la invocación en el cliente:  Obtener la descripción del método del IR (en tiempo de ejecución)    Crear una lista de argumentos Crear la petición Invocar al método  RPC sincrona: el cliente queda bloqueado hasta recibir la respuesta   RPC asincrona: el cliente puede seguir haciendo otras cosas mientras espera la petición Comunicación mediate Datagrama: se envia un mensaje pero no se espera a la respuesta. No se asegura que el mensaje llegue a su destino IS II Sistemas Distribuidos - CORBA 19

Mecanismo de invocación dinamico  Métodos para realizar las llamadas dinamicas:           lookup_name(): para localizar el objeto en el IR describe(): Obtiene la definición en IDL Create_list(): crea una lista de argumentos add_arg(): debe ser invocada cada vez que un argumento haya de ser añadido a la lista create_request(): un objeto será creado a partir de esta llamada Invoke(): llamada RPC sincrona send_oneway(): llamada datagrama, sin respuesta send_deferred(): llamada RPC asincrona get_response(): espera respuesta de forma bloqueante poll_response(): chequea si ha llegado la respuesta IS II Sistemas Distribuidos - CORBA 20

IS II

IDL

   IDL es un producto de la OMG, creado para escribir los interfaces de objetos Por medio de su interfaz, un componente se describe, como lo hacen todos los otros componentes en el sistema. Así el entendimiento entre todos los componentes integrados es posible El enlace entre el interfaz y su componente está hecho con enlaces de lenguaje estandarizados  C y C++  Smalltalk  Java Sistemas Distribuidos - CORBA 21

IS II

Estructura de un módulo IDL

módulo { ; ; ; { intefaz [:] ; ; ; ; []() [excepciones]; }}

Sistemas Distribuidos - CORBA 22

IS II

Elementos en IDL

  Modulo: El principal propósito de un módulo es introducir un nivel extra de jerarquía, agrupando una colección de interfaces. Es identificado por la palabra clave module Interfaces: Define una colección de métodos (operaciones de la OMG). Es el equivalente de la definición de clases en C++, pero sin implementación. Un interfaz puede ser heredado desde interfaces “padre” Sistemas Distribuidos - CORBA 23

IS II

Elementos en IDL

 Operaciones: En su estructura, una operación incluye su nombre o identificador, el tipo de su valor de retorno (op_tipo) y sus parámetros, los cuales deberían indicar sus tipos. Además, cada parámetro tiene un modo. Hay tres diferentes modos: “in” (el valor es pasado desde el cliente al servidor), “out” (el contrario, el valor es pasado desde el servidor al cliente) y “inout” (el valor puede ser pasado en ambas direcciones) Opcionalmente, una operación puede indicar las excepciones que disparará si no se completa la operación correctamente Sistemas Distribuidos - CORBA 24

IS II

Elementos en IDL

 Tipos de datos:Son los valores de parámetros, atributos, excepciones y valores de retorno aceptados por CORBA. CORBA especifica dos tipos de valores: básicos y compuestos  Los tipos básicos son: short, long, unsigned long, unsigned short, float, double, char, boolean y octet  los tipos compuestos son: enum, string, struct, array, union, sequence y any.

Sistemas Distribuidos - CORBA 25

IS II

Repositorio de Interfaces (IR)

   El depósito del interfaz es una “base de datos” estructurada, donde todos los interfaces IDL son almacenados Esta información en el depósito del interfaz es escrita directamente precompilando interfaces IDL o usando las funciones de escritura del depósito de interfaz de CORBA El IR es gestionado por el Object Adapter Sistemas Distribuidos - CORBA 26

IS II

Repositorio de Interfaces (IR)

 El ORB usa las definiciones de objeto en el depósito para:   Detección de tipo: el ORB puede probar, si el interfaz del objeto llamado corresponde con el interfaz, el cual representa el stub cliente del objecto Ayuda con operaciones Inter-ORB: el mismo depósito ID es usado para describir objetos que van a través de ORBs. Los interfaces de todos estos objetos deben estar repetidamente definidos in todos los depósitos ORB  Proporcionar información: A clientes y herramientas (llamadas dinámicas, debuggers, navegadores de clases, ...) Sistemas Distribuidos - CORBA 27

Jerarquía del IR

IS II Sistemas Distribuidos - CORBA 28

IS II

Comunicación Inter-ORB

  Se definen protocolos de comunicación que permiten la comunicación entre distintos ORB’s.

GIOP (General Inter-ORB Protocol): Es el protocolo base, que permite la interacción entre dos ORBs. Se define el CDR (Common Data Representation), se encarga de convertir tipos de dato IDL en cadenas de bytes. El CDR también controla la ordenación de bytes y el alineamiento de memoria Sistemas Distribuidos - CORBA 29

IS II

Comunicación Inter-ORB

 

IIOP

(Internet Inter-ORB intercambiados sobre TCP/IP Protocol): Especifica como los mensajes GIOP son

ESIOP’s

(Environment-Specific Protocols): Permiten definir un protocolo basado en GIOP sobre un tipo propietario de protocolo de red. Un ejemplo es el DCE/ESIOP, protocolo definido sobre el Distribuited Computed Environment de la Open Software Foundation Inter-ORB Sistemas Distribuidos - CORBA 30

IS II

Ventajas y desventajas de CORBA



Ventajas

    Soporte de múltiples sistemas operativos Soporte de múltiples lenguajes Gran cantidad de servicios : mensajería, eventos, transacciones, persistencia... Etc Controlada por un organismo confiable, la OMG Sistemas Distribuidos - CORBA 31

Ventajas y desventajas de CORBA

IS II  Desventajas  Complejidad: CORBA es una plataforma de desarrollo muy compleja, a pesar de que existen capas de abstracción que facilitan el desarrollo de aplicaciones   Burocracia: La evolución de las especificaciones de CORBA está sujeta a demasiados pasos de burocracia, lo que origina en que para ver novedades en la plataforma sea necesario esperar grandes cantidades de tiempo Pocas soluciones libres: Como consecuencia de su complejidad y de la lentitud de su evolución se deriva que existen pocas soluciones libres Sistemas Distribuidos - CORBA 32