Temas: 8.1 Arquitectura CORBA8.2 CORBA RMI8.3 Referencias a objetos remotos CORBA

Integrantes:

Tapia Miranda Alejandra

Chvez Gmez Agustn

El OMG (The Object Management Group) se form en 1989 con el finde fomentar la adopcin de sistemas de objetos distribuidos con elobjetivo de obtener los beneficios de la orientacin a objetos deprogramacin para el desarrollo de software.

Dise un idioma de interfaz que es independiente de cualquier lenguajede implementacin.

Ellos introdujeron ORB cuyo papel es el de ayudar a un cliente parainvocar un mtodo en un objeto. Este implica la localizacin del objeto,activando el objeto si es necesario y luego comunicar la solicitud delcliente al objeto, lo que lo lleva a cabo y las respuestas.

Introduccin

CORBA es un diseo de middleware que permite a los programas de aplicacin secomuniquen entre s con independencia de sus lenguajes de programacin, suhardware y plataformas de software, las redes que se comunican a travs y susejecutores.

Las aplicaciones se construyen a partir de los objetos CORBA, que implementaninterfaces definidas en Lenguaje de definicin de interfaz de CORBA, IDL.

CORBA

Arquitectura Corba

Est diseado para apoyar la funcin de un intermediario de peticiones objeto quepermite a los clientes invocar mtodos de objetos remotos, donde los clientes y losservidores pueden ser implementados en una variedad de lenguajes de programacin.

Ncleo ORBEl papel del ncleo del ORB incluye toda la funcionalidad del mdulo decomunicacin adems proporciona una interfaz que incluye lo siguienteoperaciones

Las que le permitan iniciarse y detenerse;

Las operaciones de conversin entre las referencias a objetos remotos ycadenas;

las operaciones para proporcionar listas de argumentos de solicitudes utilizandola invocacin dinmica.

Adaptador de objetos

El papel de un adaptador es el camino o puente entre los objetos CORBAcon interfaces IDL y las interfaces de lenguaje de programacin de lascorrespondientes clases sirvientes(servant), esta tiene la funcin de:

Se crea referencias a objetos remotos para objetos CORBA

Distribuye cada RMI a travs de un esqueleto para el (servant) sirvienteapropiado.

Activa y desactiva sirvientes.

Da a cada objeto corba un nombre de objeto nico, que forma parte desu referencia al objeto remoto.

Cada objeto CORBA se ha registrado en el adaptador de objeto, quemantiene un control remoto de tabla de objetos que mapea los nombresde objetos CORBA a sus sirvientes.

Adaptador de objeto portable(POA)Estndar para los adaptadores de objeto

Permite a las aplicaciones y los servidores ser ejecutados en los ORB producidos por diferentes desarrolladores. Esto se logra por medio de la estandarizacin de las clases de esqueleto y de la interacciones entre el POA y los sirvientes.

El POA es compatible con objetos CORBA con dos diferentes tiempos de vida:

aquellos cuyas vidas se limitan a la del proceso en el que sus sirvientes son instanciados;(objetos transitorios)

aquellos cuya duracin puede abarcar las instancias de los sirvientes en mltiples procesos.(objetos permanentes)

El valor predeterminado es que un slo servidor puede representar todos losobjetos CORBA por su POA.

Tenga en cuenta que las implementaciones de CORBA proporcionan interfacespara la funcionalidad del POA y el ncleo del ORB mediante pseudo-objetos,dado este nombre porque no pueden ser utilizados como objetos normalesCORBA.

El pseudo-objeto POA incluye:

un mtodo para activar un POA manager

servant_to_reference, para el registro de un objeto CORBA

El pseudo-objeto ORB incluye;

el mtodo init, que deben ser llamados a inicializar el ORB,

el mtodo resolve_initial_references, que se utiliza para encontrar los servicios

Compilador IDL

Interfaces IDL pueden tener atributos as como los mtodos. Los atributos son como campos de clase pblica en Java. Los atributos pueden ser definidos como de slo lectura cuando sea apropiado.

Los atributos son privados a objetos CORBA, pero para cada atributo declarado, un par de mtodos de acceso se genera automticamente por el compilador de IDL;

1) para recuperar el valor del atributo (get).

2) el otro para fijar(set).

Para los atributos de slo lectura, slo se proporciona mtodo get.

Skeletons

Clases de Skeleton se generan en el idioma del servidor por uncompilador de IDL. La invocaciones de mtodos remotos se envan atravs del esqueleto apropiada a un sirviente particular, el esqueletocon los argumentos a los mensajes de solicitud y los resultados en losmensajes de respuesta.

Client Stubs/ proxiesEstos son en el idioma del cliente. La clase de un proxy (paralenguajes orientados a objetos), o un conjunto de procedimientos deregistro (para las lenguajes de procedimiento) se genera a partir deuna interfaz IDL por un compilador de IDL para el idioma del cliente.

Repositorio de Implementacin (Implementation repository)

Este es responsable de la activacin de los servidores registrados y para la localizacin de los servidores que se estn ejecutando actualmente.

Un repositorio de la implementacin almacena una asignacin de los nombres de los adaptadores de objeto para la ruta de los archivos que contienen implementaciones de objetos.

Cuando las implementaciones de objetos estn activados en los servidores, el hostname y el nmero del puerto son agregados:

Entrada del repositorio de implementacin:

nombre del adaptador de objeto

nombre de ruta de

implementacin del objeto

nombre de host y

nmero de puerto del servidor

Repositorio de interfaz

El papel del repositorio de interfaz es proporcionar informacin sobrelas interfaces IDL registrados a los clientes y servidores que lo requieran.

Interfaz de invocacin dinmicaLa interfaz de invocacin dinmica permite a los clientes para hacerinvocaciones dinmicas sobre objetos CORBA remotos. Se utilizacuando no es prctico emplear proxies.

El cliente puede obtener desde el repositorio de interfaz de lainformacin necesaria acerca de los mtodos disponibles para unobjeto CORBA dado.

El cliente puede utilizar esta informacin para construir una invocacincon argumentos adecuados y enviarlo al servidor.

Esqueletos dinmicos

Si un servidor utiliza esqueletos dinmicos, entonces se puede aceptar invocaciones en la interfaz de un objeto CORBA para el que no tiene esqueleto.

Cuando un esqueleto dinmico recibe una invocacin, se inspecciona elcontenido de la solicitud a descubrir su objeto de destino, el mtodo quese invoca y los argumentos. Despus, invoca el objetivo.

Legacy codeSe refiere al cdigo existente que no fue diseado con objetosdistribuidos.

Un pedazo de cdigo heredado puede ser convertido en un objetoCORBA mediante la definicin de una interfaz IDL para ella y queproporciona una implementacin de un objeto adaptador apropiado ylos esqueletos necesarios

CORBA RMI

RMI(Invocacin de un mtodo robusto)

CORBA(Common Object Request Broker

Architecture)

Mecanismo para la comunicacin de servidores en aplicaciones distribuidas

Estndar que facilita el desarrollo de aplicaciones distribuidas en entornos

heterogneos

Protocolo JRMP Protocolo IIOP

Un programa JAVA puede exportar un objeto y este estar accesible a travs de la red y el programa permanecera a la espera de peticiones en un puerto

TCP

Brinda una tecnologa orientada a objetos, las funciones y los datos se agrupan en objetos y estos pueden estar en diferentes maquinas y se

acceder a ellos a travs de funciones del programa.

RMI(Invocacin de un mtodo robusto)

CORBA(Common Object Request Broker

Architecture)

El servidor espera a que el clienteinvoque los objetos por medio de las

referencias.

Transparencia de distribucin: ni cliente ni servidor necesitan saber si la aplicacin esta distribuida o centralizada, el sistema

se encarga de eso.

Transparencia de localizacin: el cliente no necesita saber donde ejecuta el servicio y el servicio no necesita saber

donde ejecuta el cliente.

Activacin de objetos: los objetos remotos no tienen por qu estar en memoria

permanentemente, y se hace de manera invisible.

REFERENCIAS A OBJETOS REMOTOS CORBA

En CORBA cuando un cliente retiene una referencia a un objeto,puede invocar los mtodos implementados por el objeto referido.

Un proceso (cliente o servidor) puede utilizar slo una implementacindependiente del lenguaje de una referencia a un objeto.

Esta referencia adopta la forma de un apuntador dirigido a larepresentacin local del objeto.

Si una referencia quiere pasar del proceso A al proceso B no puedepasar, ya que tiene significado solo dentro del espacio de A.

Entonces A tiene que organizar el apuntador para convertirlo en unarepresentacin independiente del proceso.

El RTS proporciona la operacin para transformar la referencia y unavez transformada se traspasa a B, el cual puede desempacarla otravez.

Uno de los problemas con esto era que cada implementacin podadecidir cmo representar la referencia a un objeto.

Si el proceso A deseaba pasar una referencia a B se lograba solo siambos procesos utilizaban la misma implementacin CORBA.

A la representacin independiente del lenguaje de un objeto dereferencia se le llama referencia a objeto interoperable (IOR).

Cuando pasa una referencia a un objeto entre dos sistemas diferentesCORBA, se pasa como una IOR.

Cada IOR se identifica como un identificador de repositorio.

A este identificador se le asigna una interfaz que sirve para recuperarinformacin sobre una interfaz en tiempo de ejecucin.

Para que este identificador sea til, tanto el cliente como el servidordeben tener acceso a la misma interfaz.

Los perfiles etiquetados son la parte ms importante de cada IOR.

Cada uno de estos perfiles contiene la informacin necesaria parainvocar a un objeto.

CORBA utiliza el protocolo Inter-ORB de internet (IIOP) paraimplementar la comunicacin entre nodos.

ORB (Objetct Request Broker)es el nombre utilizado por CORBA para susistema en tiempo de ejecucin basado en objetos, que permite a losobjetos realizar llamadas a mtodos situados en mquinas remotas, atravs de una red.

IIOP es un protocolo de resguardos para internet dedicado parainvocaciones de mtodos remotos para CORBA.

IIOP sigue una arquitectura cliente servidor para la comunicacin,donde una solicitud de mensaje se transmite siempre desde un clientea un servidor.

Algunas especificaciones para IIOP:

1. Representacin de datos comn (CDR): proporciona un mtodo decodificacin de datos / decodificador estndar.

2. Referencia a Objeto Interoperable (IOR): el cliente debe tener una direccinde programa antes de enviar una solicitud a un servidor. Se basa endirecciones IP y nmeros de puerto del servidor.

3. Formatos de mensaje definidos por ORB.

Organizacin de un IOR:

1. Campo ProfileID identifica el perfil IIOP en el perfil etiquetado. Secompone de cinco campos:

1. Versin del IIOP utilizado en el perfil

2. Host: es una cadena que identifica con exactitud en que servidor (nombrede dominio o IP) esta localizado el objeto.

3. Nmero de puerto donde el servidor de objetos escucha las peticionesentrantes.

4. Clave del objeto que contiene informacin que identificara el adaptadorespecifico.

5. Componentes: contiene ms informacin para indicar como debe sermanejada la referencia o que hacer en caso de que el servidor referidono est disponible.