is iisistemas distribuidos - corba 1 ingeniería del software ii objetos distribuidos corba

IS IISistemas Distribuidos -

CORBA 1

Ingeniería del software II

Objetos DistribuidosCORBA


CORBA 2

¿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


CORBA 3

¿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


CORBA 4

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


CORBA 5

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


CORBA 6

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


CORBA 7


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


CORBA 8


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


CORBA 9

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


CORBA 10

OMA – Corba Domains

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


CORBA 11

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


CORBA 12

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


CORBA 13



CORBA 14


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


CORBA 15


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.


CORBA 16


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)


CORBA 17

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


CORBA 18

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


CORBA 19

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


CORBA 20

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


CORBA 21

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


CORBA 22

Estructura de un módulo IDLmó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];

}}


CORBA 23

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”


CORBA 24

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


CORBA 25

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.


CORBA 26

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


CORBA 27

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


CORBA 28

Jerarquía del IR


CORBA 29

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


CORBA 30

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


CORBA 31

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


CORBA 32

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

is iisistemas distribuidos - corba 1 ingeniería del software ii objetos distribuidos corba

Documents