PDF de programación - Curso Corba - El estándar OMG

Curso:

CORBA

El Estándar OMG

Imparte:

Dr. Víctor Jesús Sosa Sosa

I n d i c e G e n e r a l

Visión general de CORBA
El modelo de objetos de CORBA
La arquitectura del ORB
El lenguaje de descripción de interfaces
(IDL)
La Interfaz del ORB
BOA
POA
Mapeo hacia los lenguajes de
programación

Contenido Adicional

Interoperabilidad
Invocación dinámica
Repositorio de interfaces
Plataforma comerciales
Evolución del estándar CORBA
Plataformas alternativas

I n t r o d u c c i ó n
I n t r o d u c c i ó n
I n t r o d u c c i ó n
I n t r o d u c c i ó n

+ Sistemas Informáticos restringidos a las

Grandes Corporaciones Industriales.

+ Sistematización de Pequeñas Empresas e

Interconexión entre ellas (Redes).

+ Surgen las Aplicaciones capaces de ejecutar

parte de su Código en diferentes máquinas.

+ Se crea la OMS (Grupo de 76 Empresas).

+ Nace la Norma CORBA (Common Object

Request Broker Architecture).

D e f i n i c i ó n d e l a N o r m a
D e f i n i c i ó n d e l a N o r m a
D e f i n i c i ó n d e l a N o r m a
D e f i n i c i ó n d e l a N o r m a

Esta norma cubre cinco grandes ámbitos que constituyen los sistemas
de objetos distribuidos:

Un lenguaje de descripción de interfaces, llamado Lenguaje de
Definición de Interfaces IDL (Interface Definition Language),
traducciones de este lenguaje de especificación IDL a lenguajes de
implementación (como pueden ser C++, Java, ADA, etc.) y una
infraestructura de distribución de objetos llamada Object Request
Broker (ORB) que ha dado su nombre a la propia norma: Common
Object Request Broker Architecture (CORBA).

Una descripción de servicios, conocidos con el nombre de
Servicios CORBA (Corba
el
funcionamiento básico de los objetos de que dan lugar a una
aplicación.
de
nombrado, de persistencia, de eventos, de transacciones, etc. El
número de servicios se amplía continuamente para añadir nuevas
capacidades a los sistemas desarrollados con CORBA.

especificaciones

complementan

cubren los

Services),

servicios

Estas

que

D e f i n i c i ó n d e l a N o r m a ( I I )
D e f i n i c i ó n d e l a N o r m a ( I I )
D e f i n i c i ó n d e l a N o r m a ( I I )
D e f i n i c i ó n d e l a N o r m a ( I I )

Una descripción de servicios orientados al desarrollo de
aplicaciones finales, estructurados sobre los objetos y servicios CORBA.
Con el nombre de Facilidades Comunes (Corba Facilities), estas
especificaciones cubren servicios de alto nivel, como los interfaces de
usuario, los documentos compuestos, la administración de sistemas y
redes, etc. La ambición es aquí bastante amplia ya que Corba Facilities
pretende definir funciones de objetos prefabricados para aplicaciones
habituales en la empresa: creación de documentos, administración de
sistemas informáticos, etc.

Una descripción de servicios verticales denominados Interfaces
de Dominio (Corba Domains), que proveen funcionalidad de interés
para usuarios finales en campos de aplicación particulares. Por
ejemplo,
como:
telecomunicaciones, finanzas, medicina, etc.

proyectos

sectores

existen

curso

en

en

E s t r u c t u r a d e l a N o r m a
E s t r u c t u r a d e l a N o r m a
E s t r u c t u r a d e l a N o r m a
E s t r u c t u r a d e l a N o r m a

Especificación ORB 2.x

El ORB es el software de intermediación
(middleware) que permite la interacción
transparente entre objetos
Intercepta invocaciones, localiza al
destinatario, le hace llegar invocación y
parámetros y devuelve resultados al
cliente
El cliente realiza la invocación con
transparencia de localización y acceso y
con independencia de la tecnología de
implementación del servidor

Interacción cliente–servidor

Cliente

Implementación

Stub

Skeleton

Núcleo ORB

Interacción cliente–servidor(II)

El stub convierte las invocaciones al formato de
transmisión y el skeleton convierte el mensaje en una
invocación apropiada para la implementación
Si varios objetos ofrecen la misma interfaz, es posible
sustituir uno por otro sin ningún problema de
interacción. La decisión podría ser tomada en base a:

Semántica de la implementación
Calidad del servicio

El servicio de “trading” permite buscar objetos que
cumplan con determinado criterio

Evoluciones de CORBA desde
su versión 1.2

Interoperabilidad ORB-ORB.

Entre productos de diferentes proveedores
Universal Networked Objects(IIOP, DCE-CIOP)

Inicialización de cliente y servidor

Mejora portabilidad

Nuevas traducciones de IDL

C++ y Smalltalk, JAVA

Especificación del repositorio de interfaces

Completa versión inicial para interoperabilidad

Modelo de objetos de CORBA
CORBA utiliza los mismos conceptos fundamentales
de OMA (Object Management Architecture)

Más específicos y concretos

Implementaciones de objetos

La implementación es el código que implementa la
operación definida por una interfaz IDL. Es la parte
de un objeto CORBA proporcionada por el
desarrollador de la aplicación. Mantiene un estado
interno y puede causar efectos laterales sobre otras
cosas (no necesariamente objetos)

Bases de datos

Skeleton

Implementación

Pantalla

Elemento de red

Referencias de objeto

La referencia de objeto es la identidad
que utiliza el cliente para invocar al
servidor. Una referencia corresponde
siempre a un solo objeto. Varias
referencias pueden corresponder al
mismo objeto

Una referencia puede ser obtenida como
parámetro ó resultado de una operación.
También puede ser pasada en forma de
string
Las referencias son opacas. La información
que contienen no puede ser accesada por el
usuario

Referencias de objeto (II)

Identificación única de un objeto en el
ámbito de un ORB
Formato no definido en la especificación
CORBA
CORBA 2.0 define la IOR para referencia
a objetos en entornos multi-ORB
Para portabilidad la referencia se
obtiene siempre mediante la misma
operación
IOR=ref (ORB)+internet address+port
number

IOR = Interoperable Object Reference

T i p o s

tipos

pueden

“objeto”

Los tipos “objeto” están relacionados en
una jerarquía de herencia con el tipo
“object” como raíz
Los
ser
especificados en las operaciones como
parámetros o como resultados. Pueden
ser componentes de otras estructuras
de datos
Existe un conjunto de tipos de datos
(no-objetos)
propiedades
específicas
El tipo “Any” puede contener cualquier
tipo legítimo

con

I n t e r f a c e s

Una interfaz es la descripción de las
operaciones ofrecidas por un objeto
Una interfaz puede contener también
definiciones de las estructuras de datos
que se utilizan como parámetros de sus
operaciones
Las interfaces se especifican en IDL y
están relacionadas en una jerarquía de
herencias

Semántica de las operaciones
At-Most-Once. Los mensajes se retransmiten hasta
que se obtenga una respuesta,
los mensajes
duplicados se filtran de manera que nunca se ejecuta
la operación 2 veces en el servidor. El cliente espera
por la respuesta
Best-Effort. Se declaran con la palabra clave
“oneway”, El cliente no espera hasta que la operación
termina sino que se libera justo después de hacer la
petición. No puede tener resultados ni parámetros de
salida
Deferred-Syncronous. El cliente hace la petición sin
bloquearse y mas tarde solicita los resultados. (solo
para invocación dinámica)

F i r m a s

operaciones

Las
(signatures)
contienen los siguientes campos:

tienen

expresadas

en IDL

firmas
y

Nombre de la operación (identificador)
Tipo de valor del resultado
Lista de parámetros (cero ó mas) indicando
nombre, tipo y dirección (in, out, inout)
---------------opcional ---------------
Cláusula de excepciones (raises)
Palabra reservada “oneway”
Cláusula de contexto (context)

A t r i b u t o s

Una interfaz puede contener atributos.

Se declaran como tipos nombrados
pueden incluir la condición “readonly”
Son equivalentes a un par de operaciones
• una que accesa el valor
• otra que toma un argumento del tipo

correspondiente y modifica el valor (no aplica
para atributos “readonly”)

Un atributo no necesariamente
representa una variable de estado en la
implementación

Ejecutar una escritura con un determinado
valor no garantiza que la siguiente lectura
tendra ese mismo valor

Excepciones

Una excepción se presenta como un tipo
no-objeto en IDL.

Incluye la palabra reservada “excepción”
tiene un nombre y puede incluir datos
(semejante a una
declaración de estructura de datos
CORBA define 26 excepciones estándar que
pueden ser invocadas de manera implícita
por el ORB o de manera explícita por la
implementación

Excepciones (II) -Ejemplo -

Interface Bank {

exception Reject {

string Reason;

};
exception TooMany {}; // Demasiadas cuentas!
Account newaccount (in string name)
raises (Reject, TooMany);

void deleteAccount (in Account a);

};

Arquitectura ORB

Cliente

Implementación

IR

DII

Stubs

Int. ORB

Skeleton

DSI

Impl. Rep

Adaptador de objetos

Núcleo ORB (IIOP)

Componentes en el lado cliente

Stubde cliente

Representate estático del servidor en
el cliente. También llamado proxy
Para el cliente todas las llamadas son
locales
Generado en tiempo de compilación a
partir de la interfaz IDL del servidor
Realiza el marshallingde las
invocaciones del cliente y resultados
devueltos por el servidor

Componentes en el lado cliente (II)

Interfaz de Invocación Dinámica (DII)
Permite a los clientes encontrar interfaces
de servidores en tiempo de ejecución
Proporciona mecanismos para obtener del
IR interfaces y operaciones previamente
desconocidas
El uso de la DII o un stubestático es
transparente para los servidores
Es un mecanismo más complejo que el stub
pero proporciona mayor flexibilidad.

Componentes en el lado cliente (III)

Repositorio de interfaces

Es una base de datos en tiempo de ejecución con
versiones “máquina” de las interfaces IDL
Permite obtener y modificar las descripciones
(interfaces, métodos y parámetros) de todos los
objetos registrados
Es un mecanismo de autode