Ingeniería del software II

Objetos Distribuidos CORBA Ingeniería del software 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

¿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

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

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 ellosy se encarga de proporcionar transparencia en las comunicaciones

OMA – Corba Services 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

OMA – Corba Services 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

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

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).

OMA – Corba Domains Similares a las Corba Facilities, en este se trata de servicios verticales para diferentes dominios: Telecomunicaciones Finanzas Salud

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

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

Arquitectura del ORB

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

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.

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)

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

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

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

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

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

Estructura de un módulo IDL módulo <identificador> { <declaraciones de tipo>; <declaraciones de contantes>; <declaraciones de excepciones>; intefaz <identificador> [:<herencia>] { <declaraciones de tipo>; <declaraciones de contantes>; <declaraciones de excepciones>; <declaraciones de atributos>; [<op_tipo>]<identificador>(<parámetros>) [excepciones]; }}

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”

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

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.

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

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, ...)

Jerarquía del IR

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

Comunicación Inter-ORB • IIOP (Internet Inter-ORB Protocol): Especifica como los mensajes GIOP son intercambiados sobre TCP/IP • ESIOP’s (Environment-Specific Inter-ORB 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

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

Ventajas y desventajas de CORBA • 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

Ingeniería del software II