material de apoyo 3.3 3.3 corba · 1991. hoy en día, el último estándar aprobado de corba está...

Material de Apoyo 3.3

3.3 CORBA

3.3.1 Introducción

El Object Management Group (OMG) es un consorcio integrado por varias

industrias importantes, que ha desarrollado CORBA (Common Request Broker Architecture). CORBA ofrece servicios de interoperabilidad e interconexión de

objetos. Los servicios de interoperabilidad e interconexión son normalmente conocidos como servicios middleware.

Servicios Middleware

Para resolver los problemas inherentes a sistemas heterogéneos y distribuidos,

que dificultan la implementación de verdaderas aplicaciones empresariales, los proveedores de software están ofreciendo interfaces de programación y

protocolos estándares. Estos servicios se denominan usualmente servicios middleware, porque se encuentran en una capa intermedia, por encima del

sistema operativo y del software de red y por debajo de las aplicaciones de los usuarios finales.

Un servicio middleware es un servicio de propósito general que se ubica entre

plataformas y aplicaciones. Por plataformas se entiende el conjunto de servicios

de bajo nivel ofrecidos por la arquitectura de un procesador y el conjunto de API´s de un sistema operativo. Como ejemplos de plataformas se pueden citar: Intel x86 y Win-32, Sun SPARCStation y Solaris, IBM RS/6000 y AIX, entre otros.

Un servicio middleware está definido por las API´s y el conjunto de protocolos

que ofrece. Pueden existir varias implementaciones que satisfagan las especificaciones de protocolos e interfaces. Los componentes middleware se

distinguen de aplicaciones finales y de servicios de plataformas específicas por

cuatro importantes propiedades:

Son independientes de las aplicaciones y de las industrias para las que

éstas se desarrollan.

Se pueden ejecutar en múltiples plataformas.

Se encuentran distribuidos.

Soportan interfaces y protocolos estándar.

CORBA es el estándar propuesto por el OMG. EL OMG fue fundado en 1989 y

es el más grande consorcio de industrias de la actualidad, con más de 700

compañías. Opera como una organización no comercial sin fines de lucro, cuyo Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

130

Introducción a los Sistemas Distribuidos

objetivo es lograr establecer todos los estándares necesarios para lograr interoperabilidad en todos los niveles de un mercado de objetos.

Originalmente los esfuerzos de la OMG se centraron en resolver un problema

fundamental: cómo lograr que sistemas distribuidos orientados a objetos implementados en diferentes lenguajes y ejecutándose en diferentes plataformas interactúen entre ellos. Más allá de los problemas planteados por la computación distribuida, problemas más simples como la falta de comunicación entre dos

sistemas generados por compiladores de C++ distintos que corren en la misma plataforma frenaron los esfuerzos de integración no bien comenzados. Para

opacar aún más el escenario, distintos lenguajes de programación ofrecen modelos de objetos distintos. Los primeros años de la OMG estuvieron dedicados a resolver los principales problemas de cableado. Como resultado se obtuvo la primera versión del Common Object Request Broker, publicado en

1991. Hoy en día, el último estándar aprobado de CORBA está por la versión

2.3, y la versión 3.0 está a punto de ser lanzada.

Desde sus principios, el objetivo de CORBA fue permitir la interconexión abierta

de distintos lenguajes, implementaciones y plataformas. De esta forma, CORBA cumple con las cuatro propiedades enumeradas como deseables de los servicios middleware. Para lograr estos objetivos, la OMG decidió no establecer estándares binarios (como es el caso de COM); todo está estandarizado para

permitir implementaciones diferentes y permitir que aquellos proveedores que desarrollan CORBA pueden ofrecer valor agregado. La contrapartida es la

imposibilidad de interactuar de manera eficiente a nivel binario. Todo producto que sea compatible con CORBA debe utilizar los costosos protocolos de alto nivel.

CORBA está constituido esencialmente de tres partes: un conjunto de interfaces

de invocación, el ORB (object request broker) y un conjunto de adaptadores de objetos (objects adapters). CORBA va más allá de simples servicios middleware, provee una infraestructura para construir aplicaciones orientadas a

objetos. Las interfaces definen los servicios que prestan los objetos, el ORB se encarga de la localización e invocación de los métodos sobre los objetos y el object adapter es quien liga la implementación del objeto con el ORB.

Para que las interfaces de invocación y los adaptadores de objetos funcionen

correctamente, se deben cumplir dos requisitos importantes. En primer lugar, las

interfaces de los objetos deben describirse en un lenguaje común. En segundo lugar, todos los lenguajes en los que se quieran implementar los objetos deben proveer un mapeo entre los elementos propios del lenguaje de programación y el lenguaje común. La primera condición permite generalizar los mecanismos de pasaje de parámetros (marshaling y unmarshaling). La segunda permite

relacionar llamadas de o a un lenguaje en particular con el lenguaje de

especificación común. Este lenguaje común fue una parte esencial de CORBA Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

131


desde sus orígenes y es conocido como el OMG IDL: Interfaz Definition Language. Existen mapeos del OMG IDL a C, C++, Java y Smalltalk.

El desarrollo basado en componentes

El desarrollo basado en componentes que se puedan comprar y poner en

marcha sin mayores dificultades (Plug & Play) es una meta a alcanzar que

facilitaría la reutilidad de software. En esta sección se hace una breve introducción al desarrollo basado en componentes y el rol que le compete a

CORBA en este ámbito.

Un componente ha sido definido en la European Conference on Object

Oriented Programming (ECOOP) de 1996 como una “una unidad de

composición con interfaces contractuales especificadas y dependencias de

contexto explícitas.” Un componente de software puede ser desarrollado independientemente y utilizado por terceras partes para integrarlo mediante

composición a sus sistemas.” Los componentes son para crear software utilizando composición, por eso es esencial que sean independientes y que se presenten en formato binario, permitiendo así distintos vendedores e integración robusta.

Para que un componente pueda ser integrado por terceras partes en sus

sistemas, éste deber ser suficientemente auto contenido y debe proveer una

especificación de lo que requiere y provee. En otras palabras, los componentes deben encapsular su implementación e interactuar con otros componentes a través de interfaces bien definidas.

Un componente no es un objeto. A diferencia de los objetos, los componentes no

tienen estado. Esto quiere decir que un componente no puede distinguirse de una copia de sí mismo. Un componente puede tomar la forma de un archivo ejecutable o una biblioteca dinámica que usualmente cobra vida a través de

objetos, pero no es este un requisito indispensable. De hecho, los primeros componentes conocidos (aunque en su momento no se los haya definido así)

fueron las bibliotecas de procedimientos. Sin embargo, los objetos, con sus características de encapsulamiento y polimorfismo, facilitan la construcción e integración de componentes.

Y al hablar de objetos vale la pena distinguir aquí los objetos de las clases. Una

clase es una definición de propiedades y funcionalidades ha ser provistas por los objetos. A partir de una clase es posible la instancia objetos. Los componentes pueden contener una o más clases y serán los clientes de los componentes quienes soliciten la creación de las instancias de estas clases.

Pero tomando el lugar del programador que debe integrar el componente a su

aplicación, surgen algunas incógnitas que debería resolver. El fabricante del Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

132


componente solamente ha entregado un archivo ejecutable que se debe iniciar en la máquina en la que se ejecuta la aplicación y la interfaz definida en un lenguaje de definición de interfaces (IDL, Interface Definition Language)

estándar. El programador desea ahora:

Mapear la interfaz: ¿Cómo hace el programador para mapear las clases

que el componente provee al lenguaje en que realizará su implementación final? Seguramente el lenguaje de programación elegido provee mecanismos para definir clases, pero es necesario que la

definición que se haga de la clase en ese lenguaje corresponda a la definición que dio el fabricante del componente.

Crear objetos: ¿Cómo hace el programador para crear una instancia del

objeto Venta? Es necesario que exista un mecanismo para indicar al componente que cree una instancia del objeto Venta. Una vez creada la

instancia ¿Cómo se logra acceder a sus propiedades o métodos?

Transparencia: El componente sería de poca utilidad si su utilización no

fuera transparente. Si para cada llamada al componente el programador tiene que utilizar un servicio del sistema operativo de llamada entre procesos (IPC), o peor aún si el componente es remoto, un servicio de

llamada remota a procedimientos (RPC), está claro que dejaría el componente de lado pues es más trabajo utilizarlo que hacer un programa desde cero.

Estas son sólo algunas de las cuestiones que el programador tendrá que

resolver para poder utilizar el componente. En el caso de que el programador llegara a comprar otro componente, es seguro que desea que los mecanismos de utilización sean uniformes para no tener que resolverlas nuevamente. Los servicios middleware que provee CORBA buscan resuelven estos problemas.

3.3.2 Generalidades de CORBA

CORBA es un Middeware o marco de trabajo estándar y abierto de objetos

distribuidos que permite a los componentes en la red ínter operar en un ambiente común sin importar el lenguaje de desarrollo, sistema operacional, tipo

de red, etc. En esta arquitectura, los métodos de un objeto remoto pueden ser invocados “transparentemente” en un ambiente distribuido y heterogéneo a través de un ORB (Object Request Broker). Además del objetivo básico de

ejecutar simplemente métodos en objetos remotos, CORBA adiciona un conjunto de servicios que amplían las potencialidades de éstos objetos y conforman una

infraestructura sólida para el desarrollo de aplicaciones críticas de negocio.

CORBA es la respuesta del “Grupo de Gestión de Objetos” (Object

Management Group – OMG) a la necesidad de interoperabilidad ante la gran proliferación de productos hardware y software. CORBA permite a una Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

133


aplicación comunicarse con otra sin importar el tipo de red, protocolo, sistema operacional o lenguaje de desarrollo.

CORBA automatiza muchas tareas comunes y “pesadas” de programación de

redes tales como registro, localización y activación de objetos; manejo de errores y excepciones; codificación y decodificación de parámetros, y protocolo de transmisión.

En un ambiente CORBA, cada Implementación de Objeto, define bien su Interfaz

a través una especificación normalizada conocida como IDL (Interface Definition Language) a través de la cual en forma Estática (en el momento de compilación) o en forma Dinámica (en el momento de ejecución) un Cliente que

requiera el servicio de una Implementación de Objeto, puede ser ejecutada. Las invocaciones a métodos remotos son enviadas por los clientes llamando objetos locales llamados “Stubs” (generados por un compilador de IDL - Estático), el

cual intercepta dichas invocaciones y continúa el proceso de llevar y retornar automáticamente dicha invocación. La Implementación del objeto, no tiene que

conocer el mecanismo por el cual un Cliente le ha invocado un servicio.

Cuando el Cliente y una Implementación de Objeto están distribuidos por una

red, usan el protocolo GIOP/IIOP suministrado por la arquitectura para lograr la comunicación.

La forma en cómo una Implementación de Objeto (desarrollada por un

programador de aplicaciones) se conecta a un ORB, es a través de un Adaptador de Objetos. Este adaptador recibe las peticiones por la red e invoca los servicios a la implementación correspondiente.

Actualmente CORBA ya ha resuelto los problemas fundamentales de

interoperabilidad y comunicación entre objetos y se han definido y especificado un conjunto de servicios comunes requeridos para la construcción de las aplicaciones, pero donde hay gran actividad es en la especificación de objetos

comunes por dominio de aplicación o conocidas en CORBA como Interfaces de Dominio. Allí se trabajan en áreas como Telecomunicaciones, Medicina,

Finanzas, Manufactura, etc.

CORBA esta fundamentado en dos modelos: un modelo de objetos, el cual

agrega todas las características de Orientación por Objetos como Tipos de

Datos, Abstracción, Polimorfismo y Herencia y un modelo de referencia o arquitectura conocida como OMA (Object Management Architecture).

3.3.3 Object Management Group (OMG)

La OMG fue fundada en abril de 1989 por 11 compañías, en octubre de 1989, la

OMG comenzó operaciones independientes como una entidad sin ánimo de lucro. A través de sus comités, la OMG desarrolla especificaciones Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

134


independientes de cualquier proveedor para la industria del software. Actualmente el consorcio tiene más de 800 miembros. La OMG se esta moviendo a establecer a CORBA como el “Middleware que esta en todas

partes” a través de sus especificaciones CORBA/IIOP, Servicios de Objetos,

Facilidades de Internet y Especificaciones de Dominio, entre otras.

La misión de la OMG es crear un mercado de software basados en

componentes introduciendo las tecnologías de objetos. Establecer guías y

especificaciones para proveer un marco común para el desarrollo de aplicaciones. Conforme a estas especificaciones, será posible desarrollar en

ambientes heterogéneos a través de la gran variedad de productos hardware y software existente.

La OMG define la administración de objetos como el desarrollo de software que

modela el mundo real a través de la representación de “objetos”. Estos objetos son la encapsulación de los atributos, relaciones y métodos de software identificables como componentes de un programa. La administración de objetos

facilita el desarrollo rápido de aplicaciones, facilidad de mantenimiento, escalabilidad y reutilidad del software.

La OMG esta estructurado en tres grandes cuerpos: el Comité de Plataforma

Tecnológica (Platform Technology Committee - PTC), el Comité de Dominio

Tecnológico (Domain Technology Committee - DTC) y la Junta de Arquitectura (Architecture Board). Dentro de los Comités Técnicos y Junta de Arquitectura,

trabajan las Fuerzas de Trabajo, Grupos de Interés Especial y Grupos de Trabajo quienes llevan a cabo los procesos de adopción tecnológica de la OMG.

3.3.4 Object Management Architecture - OMA

Una de las metas principales de la arquitectura OMA, es introducir las

tecnologías orientadas a objetos como soporte a la nueva generación de aplicaciones y sistemas distribuidos, por ello, un esquema de administración de

objetos representa los siguientes beneficios:

Interfaces de usuario orientadas a objetos.

Funcionalidades comunes en diferentes aplicaciones, tal como almacenamiento y recuperación de objetos, correo de objetos, impresión, creación y borrado de objetos.

Compartir información, desde el punto de vista de acceso múltiple a través de aplicaciones. La transición a un esquema orientado por objetos no quiere decir que las aplicaciones existentes son obsoletas. Las aplicaciones existentes pueden ser incorporadas en un ambiente orientado por objetos.

El Modelo de Objetos Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

135


Provee una representación organizada de los conceptos y terminología de objetos. El modelo de la OMG es abstracto en el sentido que directamente no realiza una tecnología particular, el modelo descrito aquí es un modelo de

objetos concreto.

Un sistema de objetos es una colección de objetos que aíslan las peticiones de

servicios (clientes) de la provisión de los servicios por el encapsulamiento de las interfaces.

El modelo de objetos es un ejemplo del modelo clásico de objetos, donde un

cliente envía un mensaje a un objeto. Conceptualmente, el objeto interpreta el mensaje para decidir que servicio ejecutar. En este modelo, la selección de métodos es ejecutada por el objeto o por el ORB.

Semántica de Objetos

Un sistema de objetos provee servicios a clientes. Un cliente de un servicio es

cualquier entidad capaz de requerir servicios.

Conceptos relevantes a un cliente:

Objeto: un objeto es una entidad identificable y encapsulada que provee uno o

más servicios que pueden ser requeridos por un cliente.

Requerimientos: los clientes solicitan un servicio enviando un requerimiento. Un

requerimiento es un evento. La información asociada a este evento consiste en una operación, objeto destino, cero o más parámetros y contextos opcionales del

requerimiento.

Creación y Destrucción de Objetos

Aunque los objetos pueden ser creados o destruidos, desde el punto de vista del

cliente no existen mecanismos especiales para la creación o destrucción.

Tipos

Un tipo es una entidad identificable con un predicado asociado definido sobre

valores. Un valor satisface un tipo si el predicado es verdadero para este valor.

Un valor que satisface un tipo es llamado un miembro del tipo.

Un tipo de objeto es un tipo cuyos miembros son objetos. En otras palabras, un

tipo objeto es satisfecho solo por objetos.

Tipos básicos: Enteros de 16 y 32 bits con y sin signo, números IEEE de

punto flotante de 32 y 64 bits, caracteres ISO Latin-1 (8859.1), booleano,

Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

136


opaco de 8 bits, enumerados, string de longitud variable y tipo any el

cual representa cualquier posible tipo básico o construido.

Tipos complejos: estructuras, uniones, secuencias, arreglos, interfaces,

etc.

Interfaces

Una Interfaz es una descripción de un conjunto de posibles operaciones que un

cliente puede requerir de un objeto. Un objeto satisface una Interfaz si este puede ser especificado como el objeto destino en cada requerimiento potencial descrito por la Interfaz.

Un tipo de Interfaz es un tipo que es satisfecho por cualquier objeto que

satisface una Interfaz particular.

Las Interfaces en OMG son especificadas en IDL (Interface Definition

Language). La herencia de Interfaces provee los mecanismos para permitir a un objeto soportar múltiples Interfaces. La Interfaz principal es simplemente la Interfaz más especifica que el objeto soporta y consiste en todas la operaciones en la transitive closure del grafo de herencia de Interfaz.

Operaciones

Una Operación es una entidad identificable que denota un servicio que puede

ser requerido. Una operación es identificada por un identificador de operación y tiene una firma que describe los valores legítimos de los parámetros requeridos

y resultados retornados.

Las excepciones son una indicación que un requerimiento de operación no ha

ejecutado exitosamente.

Un contexto de requerimiento provee información adicional y especifica de la

operación que puede afectar el rendimiento de un requerimiento.

Semántica de ejecución

Dos estilos de semántica de ejecución son definidos para el modelo de objeto:

Al menos una vez: si un requerimiento de operación retorna

exitosamente, este fue ejecutado exactamente una sola vez, si este retorna una indicación de excepción, este fue ejecutado al menos una

vez.


137


Mejor esfuerzo: una operación de mejor esfuerzo es una operación de requerimiento único, este no puede retornar cualquier resultado y el solicitante nunca se sincroniza con la terminación.

Atributos

Una Interfaz puede tener atributos. Un atributo puede ser sólo lectura o lectura-

escritura.

Implementación de objetos

El modelo de implementación consiste en dos partes: el modelo de ejecución y

el modelo de construcción. El modelo de ejecución describe como los servicios

son ejecutados y el modelo de construcción describe como los servicios son definidos.

Modelo de ejecución: el servicio requerido es ejecutado en un sistema

computacional por ejecución de un código que opera sobre los mismos datos. El código que es ejecutado para realizar un servicio es llamado

método. Un método es una descripción inmutable de una computación que puede ser interpretada por el motor de ejecución. Un método tiene

unos atributos inmutables llamados "formato de método" que define el conjunto de máquinas de ejecución que pueden interpretar el método. Un motor de ejecución es una máquina abstracta (no un programa) que puede interpretar métodos en ciertos formatos, causando que las

computaciones descritas sean realizadas. Un motor de ejecución define un contexto dinámico para la ejecución de un método. La ejecución de un método es llamada "activación de método".

Modelo de construcción: una implementación de objeto o implementación

es una definición que provee la información necesaria para crear un

objeto y permitir al objeto participar en proveer un apropiado conjunto de servicios. Una implementación típicamente incluye, entre otras cosas, la

definición de los métodos que operar sobre el estado de un objeto. también incluye información acerca de los tipos intended del objeto.

Elementos de OMA

Object Request Broker – ORB: representa el medio o bus de objetos a

través del cual se comunican todos los objetos participantes en el

sistema. El ORB es el corazón de comunicaciones del estándar. Este es referido comercialmente como CORBA. Este provee una infraestructura que permite a objetos comunicarse, independiente de la plataforma especifica y técnicas usadas para implementar el objeto direccionado. El


138


ORB garantiza portabilidad e interoperabilidad de objetos sobre una red de sistemas heterogéneos.

Objetos de Servicio – CORBAServices, son un conjunto de objetos

genéricos, que son usados por muchos programas distribuidos, como soporte a tareas muy comunes. Actualmente se tienen definidos los siguientes objetos de servicio: Nombres, Ciclo de Vida, Persistencia,

Seguridad, Consulta, Propiedades, Transacciones, Eventos, Tiempo y Negociador entre otros.

Objetos de Dominio – CORBADomain, es un conjunto de objetos que

son comunes y estándares dentro de un dominio o mercado de aplicación, se cuentan con dominios como: Telecomunicaciones, Finanzas, Comercio Electrónico, Medicina, Transportes, Transportes, etc.

Facilidades Comunes – CORBAFacilities, conjunto de objetos

orientados hacia las aplicaciones de usuario final como Administración de Datos, Aplicaciones, Interfaces de Usuario, etc.

Objetos de Aplicación: son desarrollados por el programador.

La figura muestra los elementos de OMA. 3.3.5 Object Request Broker - ORB

El Object Request Broker (ORB) es el middleware que establece las

relaciones cliente/servidor entre objetos. Usando un ORB, un cliente puede

transparentemente invocar un método sobre un objeto remoto. El ORB intercepta la llamada y es responsable de encontrar el objeto que implementa el

requerimiento, pasar los parámetros, invocar el método y retornar el resultado.

El cliente no tiene que preocuparse de donde esta implementado el objeto, su

lenguaje de desarrollo, sistema operacional o tipo de red. De esta forma el ORB Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

139


provee la interoperabilidad entre aplicaciones sobre diferentes máquinas en un ambiente heterogéneo distribuido.

En el esquema actual de aplicaciones cliente/servidor, los desarrolladores usan

su propio diseño o un “estándar” para definir el protocolo a ser usado entre los dispositivos. La definición de ese protocolo depende del lenguaje de implementación, transporte de red y otros factores. Un ORB simplifica este proceso, por ejemplo el protocolo es definido a través de una especificación de

las Interfaces conocida como IDL. Una vez se tiene claro las Interfaces, el lenguaje de implementación o sistemas operacionales y de red, ya no es

relevante.

La especificación IDL de OMG provee una forma estándar de definir las

Interfaces a los objetos CORBA. La definición IDL es una especie de contrato

entre el desarrollador de un objeto y el cliente. IDL es independiente del lenguajes de programación y se mapea a los lenguajes más típicos para desarrollar, actualmente se encuentra generación de código a C, C++,

SmallTalk, Java, Ada, COBOL, etc.

Más importante aún, una solución basada en ORB, permite integrar aplicaciones

existentes, simplemente describiendo sus Interfaces en IDL y escribiendo los "wrappers" que traslada entre el bus estandarizado y las Interfaces existentes.

Lo que permite en el ORB la interoperabilidad e independencia de muchos

factores, es la definición de los objetos en un lenguaje de especificación totalmente independiente del lenguaje de implementación, este lenguaje se conoce como Interface Definition Language (IDL)

Elementos de un ORB

Implementación del Objeto: realizado por el programador. Implementa las

operaciones especificadas en la definición IDL. La implementación puede ser

escrita en una variedad de lenguajes como C, C++, Java, SmallTalk, Ada, etc.

Cliente: entidad que invoca una operación en una Implementación de Objeto

remoto. De igual forma puede ser desarrollado en varios lenguajes y es realizado por un programador de aplicaciones.

Núcleo ORB: provee mecanismos para transportar de manera

transparentemente requerimientos de Clientes hacia Implementaciones de Objeto remotos. Es responsable de interceptar todas las llamadas del cliente, localizar el objeto, codificar y enviar el requerimiento y esperar la respuesta, la cual es retornada al Cliente. Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

140


Interfaz ORB: ofrece varias funciones de ayuda, tales como conversión de referencia de objetos a texto y viceversa, creación de lista de argumentos para invocación DII, entre otras.

Stubs y Skeleton IDL: Los stubs y skeleton sirven como “pegante” entre el

cliente y servidor respectivamente y el ORB. Son estáticos y generados en

tiempo de compilación por un compilador IDL el cual transforma las Interfaces IDL hacia el lenguaje de desarrollo, esto reduce las posibilidades de errores al generar automáticamente los stubs y skeleton.

Interfaz de Invocación Dinámica (DII): esta Interfaz permite a un cliente construir

dinámicamente un requerimiento sin tener un stub, lo cual significa que los

requerimientos son construidos en tiempo de ejecución. Otra ventaja de este esquema es permitir llamadas sincrónicas de no bloqueo (deferred) y llamadas asincrónicas de una sola vía (oneway)

Interfaz Skeleton Dinámica (DSI): cumple las mismas funciones de DII pero en

el lado del servidor. Permite que el ORB realice llamadas a una Implementación de Objeto del cual no se tiene conocimiento de la Interfaz.

Adaptador de Objetos: este módulo asiste al ORB con la entrega de

requerimientos a los objetos y con la activación de objetos de acuerdo a varias

políticas. Un adaptador de objetos asocia una implementación de objetos con el ORB. Actualmente se tienen definidos dos tipos de adaptadores: BOA (Basic

Object Adaptor) y POA (Portable Object Adaptor). La figura muestra los elementos de un ORB. Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

141


Un ORB no tiene que ser implementado como un componente único. Las Interfaces que ofrecen los ORB están organizadas en 3 categorías:

Operaciones para todas las implementaciones de ORB

Operaciones especificas a tipos particulares de Objetos Operaciones especificas a estilos particulares de implementación de objetos.

El núcleo del ORB es el componente que provee la representación básica de

objetos y la comunicación de requerimientos.

Un cliente tiene acceso al objeto a través de una “Referencia al Objeto”, el

cliente solo conoce la Interfaz que este objeto tiene con el entorno.

Los clientes generalmente “ven” los objetos y el ORB bajo la perspectiva de un

lenguaje mapeado, trayendo el ORB a niveles del programador.

Una variedad de Implementaciones de Objetos se pueden soportar en CORBA,

incluyendo servidores separados, librerías, un programa por método, una aplicación encapsulada, una base de datos orientada a objetos, etc.

Referencias de Objeto

Es la información necesaria para especificar un objeto dentro de un ORB. Tanto

los clientes como las implementaciones del objeto tienen una noción “opaca” de

la referencia de objeto de acuerdo al lenguaje de mapeo y así aislar la representación real de estos.

Dos ORB pueden diferir en la elección de la representación de las Referencias

de Objeto.

Lenguaje de especificación de Interfaces

IDL es la forma de especificar las Interfaces de un objeto en el ambiente

CORBA. De estas defunciones en IDL, es posible mapearlos a una variedad de

lenguajes de programación o sistemas de objetos.

Este lenguaje de mapeo también define la interacción entre la invocación de los

objetos y los hilos de control en el cliente o implementación.

El lenguaje de mapeo provee llamadas sincrónicas, es decir, no retorna hasta

que se termine de ejecutar el método en la implementación del objeto.

Adaptador de objeto

Es la forma principal para acceder los servicios de una implementación de objeto

provistos por el ORB. Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

142


Los servicios provistos por el ORB a través de un Adaptador de Objetos incluye: generación e interpretación de referencia de objetos, invocación de métodos,

seguridad de interacciones, activación/desactivación de objetos e implementaciones, mapeo de referencias de objeto a implementaciones y registro de implementaciones.

Un adaptador de objetos exporta una interfaz pública a la implementación del

objeto y una privada al skeleton.

Es responsable de las siguientes funciones:

Generación e interpretación de referencias de objetos

Invocación de métodos

Seguridad de interacciones

Activación/desactivación de objetos e implementaciones

Mapeo de referencias de objeto a las correspondientes implementaciones de objeto

Registro de implementaciones

Ejemplos de Adaptadores de Objetos:

Basic Object Adapter: define una especificación que puede ser usada por

muchos objetos ORB con implementaciones convencionales. Para este adaptador, las implementaciones son generalmente programas separados. Esto

permite activar un programa por: método, objeto y compartido para todas las instancias del tipo de objeto. Si la implementación no esta activa, el BOA

comienza una. Library Object Adapter: es utilizado por los objetos que tienen implementaciones de librerías. Este accede el almacenamiento persistente en

archivos y no soporta activación o autenticación, ya que los objetos se asume que están en los clientes. Object-Oriented Database Adapter: usa una conexión a una OODB para

proveer acceso a los objetos almacenados. Los objetos pueden ser registrados implícitamente.

Interfaz ORB

Son las Interfaces que directamente llegan al ORB y que son las mismas para

todas las implementaciones de ORBs y que no depende de la Interfaz de un

objeto o adaptador. Ya que muchas de las funcionalidades del ORB son provistas a través del adaptador de objetos, stubs, skeleton o invocación

dinámica; quedan pocas operaciones comunes a través de todos los objetos.

Repositorio de Interfaces Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

143


Es un servicio que provee objetos persistentes que representan la información IDL en forma disponible en tiempo de ejecución. También el IR es un lugar

común para almacenar información adicional asociada con Interfaces al ORB. (ej: debug, librerías de stubs/skeleton, etc.).

Repositorio de implementación

Contiene información que permite al ORB localizar y activar implementaciones

de objetos, aunque esta información es muy dependiente de la implementación del ORB o del ambiente operativo.

Ejemplos de implementaciones de ORB

Cliente e Implementación residen en el ORB: Si hay un mecanismo adecuado de

comunicaciones, un ORB puede ser implementado en rutinas residentes en el cliente e implementaciones. Los stubs en el cliente pueden utilizar un esquema de IPC o directamente acceder la localización de un servicio. El código enlazado

con las implementaciones es responsable de configurar las bases de datos apropiadas para uso de los clientes ORB basado en Servidor: administración centralizada. Todos los clientes e

implementaciones pueden comunicarse con uno o más servidores cuya función es enrutar los requerimientos de clientes a implementaciones. Se utilizan IPC

para comunicación hacia el ORB.

ORB basado en sistema: para mejorar la seguridad, robustez y rendimiento, el

ORB puede ser provisto como un servicio del Sistema Operacional, pueden existir optimizaciones como evitar el marshalling cuando ambos están en la

misma máquina.

ORB basado en librería: para objetos que son de “peso liviano” y cuyas

implementaciones pueden ser compartidas, la implementación del ORB podría ser en una librería. En este caso, los stubs pueden ser los métodos reales. Esto

asume, que es posible para un cliente tener acceso a los datos para los objetos y que la implementación confía en que el cliente no dañara los datos.

3.3.6 CORBA Services

OMA esta construida sobre un fundamento y arquitectura CORBA que desarrolla

la visión de la OMG de componentes de software plug-and-play.

Los CORBA Services especifican servicios básicos casi todos los objetos

necesitan. Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

144


Para cada componente de OMA, la OMG provee una especificación formal descrita en OMG IDL (como invocar cada operación dentro de un objeto) y su semántica en lenguaje inglés (que hace cada operación y las reglas de

comportamiento). Un proveedor no tiene que suministrar obligatoriamente ningún servicio adicional al ORB, pero si este lo ofrece, deberá esta de acuerdo a la especificación que para este servicio tiene la OMG.

Los CORBA Services proveen servicios a nivel de aplicación fundamentales

para las aplicaciones orientadas por objetos y componentes en entornos

distribuidos. La OMG ha definido alrededor de 15 servicios de objetos. Los

cuales son:

Nombres Trader

Notificación

Eventos

Transacciones

Seguridad

Ciclo de vida

Propiedades

Persistencia

Consulta

Relaciones

Concurrencia

Externalización

Licenciamiento

Tiempo

Colección

De éstos 15 se destacan los siguientes servicios clave:

Acceso a referencias de objetos a través de la red, soportada por el

servicio de Nombres y de Trader.

Notificación de eventos importantes o cambios de estado en un objeto,

soportado por el servicio de Eventos y de Notificación. Soporte para semántica transaccional (two-phase commit y rollback)

soportado por el servicio de Transacciones.

Soporte para seguridad, soportada por el servicio de Seguridad.

Nombres: permite a componentes descubrir otros componentes en un ambiente

distribuido, básicamente es un servicio de localización que asocia identificadores a manejadores que proveen una forma de contactar el componente deseado en

un sistema distribuidos. Este asocia nombres - organizados jerárquicamente - a objetos.

Ciclo de vida: básicamente es un servicio de configuración, define servicios y

convenciones para crear, borrar, copiar y mover componentes en un sistema

distribuido.

Eventos: implementa un modelo de comunicación desacoplado, basado en el

paradigma publicación/suscripción. En este modelo, uno o más publicadores pueden enviar mensajes relacionados con un tópico específico, mientras que un grupo de suscriptores reciben los mensajes asincrónicamente. Con estos Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

145


mecanismos, los publicadores pueden generar evento sin tener que conocer la identificación de sus consumidores y viceversa. Hay dos acercamientos, modelo Push y modelo Pull, en el modelo Push los publicadores toman la iniciativa de iniciar la comunicación, en el modelo Pull, los suscriptores requieren eventos de

los publicadores.

Transacciones: gestiona interacciones entre objetos distribuidos estableciendo

puntos de Commit y delimitación de transacciones. Este servicio soporta varios

modelos y permite interoperabilidad entre diferentes arquitecturas de red y

modelos de programación.

Seguridad: controla la identificación de los elementos del sistema distribuido

(usuarios, objetos, componentes, etc) que permite verificar que un cliente esta autorizado a acceder los servicios de una implementación remota.

Adicionalmente permite la comunicación segura sobre enlaces de comunicación inseguros, ofreciendo confidencialidad e integridad de la información transmitida.

Tiempo: suministra información del tiempo y permite la definición de llamadas

periódicas.

Licenciamiento: controla la utilización de objetos específicos, inhibiendo uso

inadecuado de derechos y propiedad intelectual.

Propiedades: provee la habilidad de dinámicamente asociar propiedades a los

objetos los cuales pueden ser consultados o modificados por otros elementos.

Relaciones: permite la definición del papel ejecutado por objetos CORBA en una

relación.

Consulta : permite a los usuarios y objetos invocar operaciones de consulta sobre

colecciones de objetos.

Persistencia: provee mecanismos para retener y mantener el estado de objetos

persistentes.

Concurrencia: permite la coordinación de múltiples accesos a recursos

compartidos a través de la provisión de varios modelos de locks y permite resolución flexible de conflictos.

Externalización: define convenciones y protocolos para representar el estado de

información relacionado a un objeto en la forma de una secuencia de datos, permitiendo a esta información ser almacenada o transferida a otras localizaciones.

3.3.7 CORBA Facilities Horizontales Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

146


Las facilidades CORBA tanto horizontales como verticales, son diseñadas para completar la arquitectura entre los Servicios básicos de CORBA y las aplicaciones específicas de industria. Con una arquitectura completa, las

compañías compartirán datos a nivel de aplicación y funcionalidades para la integración de diferentes sistemas de información. Las facilidades representan un punto medio entre una aplicación particular y los servicios y ORB.

La OMG ha definido como Facilidades Horizontales las siguientes:

Interfaz de usuario

Administración de información

Administración de sistemas

Administración de tareas

Hoy en día estas especificaciones han sido adheridas a ORBOS (ORB y

Servicios) y ya no están como un grupo aparte.

Específicamente a nivel de facilidades verticales la OMG ha definido las

siguientes:

Especificación para la administración de sistemas XCMF.

Facilidad para colar de impresión.

3.3.8 CORBA Facilities Verticales o de Dominio

La potencialidad que representa el lenguaje IDL para la especificación de un

objeto u componente ha permitido trabajar en la normalización de intereses

comunes para un sector de mercado particular y que una vez se llegue a un acuerdo en cuanto a estas especificaciones, sería estándar dentro de este

mercado.

Para esto se ha creado el Domain Technology Committee (DTC) y esta a su

vez esta organizada en una serie de Domain Task Forces (DTF) los cuales escriben documentos de requerimientos (RFI y RFP) para nuevas

especificaciones y evalúan y recomiendan especificaciones candidatas. Basados en las recomendaciones de los DTF, el DTC conduce un proceso formal de

votación para asegurar que cumple todos los requerimientos del sector y no solo de quien haya propuesto. Posteriormente estas recomendaciones requieren ser enviadas a la Junta de Directores de la OMG para hacerla una especificación

oficial. Actualmente hay 8 DTF:

Objetos de negocio

Finanzas y seguros

Comercio Electrónico

Manufactura

Salud o Medicina


147


Telecomunicaciones

Transportes

Investigación de ciencias de la vida

También bajo la OMG pero que no tienen DTF se encuentran dos Grupos de

Interés Especial:

Utilities (principalmente energía eléctrica)

Estadística

Seis especificaciones ya han sido adoptadas oficialmente como estándares de

dominio vertical, ellos son:

Facilidad Currency del DTF de Finanzas.

Un conjunto de Habilitadores para la administración de datos de

productos, del DTF de manufactura. Servicio de Identificación de Personas (PIDS) de CORBAMed

Servicio de Consulta Lexicon de CORBAMed

Control y Administración de flujos de Audio/Vídeo, del DTF de telecomunicaciones.

Servicio de Notificación, del DTF de Telecomunicaciones.

3.3.9 Nuevas especificaciones de CORBA

Después que fue completada y normalizada la versión 2.0 en 1996, la OMG

continuo trabajando en la incorporación de aspectos importantes que deben ser tenidos en cuenta en un sistema distribuido y ha ampliado su modelo de objetos para incorporar aspectos como: múltiples Interfaces por objeto, paso de objetos

por valor, modelo de componentes, soporte para tiempo real y tolerancia a fallos entre otros. CORBA 3.0 se refiere a una serie de nuevas especificaciones que

unidas dan una nueva dimensión a CORBA. Estas nuevas especificaciones están divididas en tres categorías:

Integración con Internet.

Control de Calidad de Servicio

Arquitectura de componentes CORBA

Por otro lado, han aumentado las especificaciones de mercados verticales, o lo

que en CORBA se conoce como Dominios Verticales y mediante la utilización de IDL, existen muchos mercados estandarizando en CORBA (Finanzas, Seguros, Comercio Electrónico, Medicina, Manufactura, Telecomunicaciones, Transportes, Investigación y Objetos de Negocio).

A continuación se describen las características más importantes de los últimos

adelantos en CORBA 3.0: Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

148


Integración con Internet

Esta integración esta siendo desarrollada por la especificación “firewall”. La

especificación CORBA 3 define firewalls a nivel de transporte, de aplicación y

conexiones bidireccionales GIOP útiles para callbacks y notificación de eventos.

Los firewalls de transporte trabajan a nivel de TCP, para lo que la IANA ha

reservado los puertos bien conocidos 683 para IIOP y 684 para IIOP sobre SSL.

También hay una especificación de CORBA sobre SOCKS.

En CORBA es frecuente que un objeto invoque un método (callback) o notifique

de algún suceso a su cliente, por esto el objeto puede comportarse como cliente,

por esto generalmente se requiere abrir una nueva conexión TCP en sentido inverso el cual puede ser detenido por un firewall. Bajo esta especificación, a

una conexión IIOP se le permite llevar invocaciones en el sentido inverso bajo

ciertas condiciones que no comprometan la seguridad de la conexión.

UML y MOF: Soporte para análisis y diseño

El modelado es una pieza clave en el desarrollo de software robusto, antes que

existiera UML de OMG, no había mecanismos estándares para intercambiar modelos de una herramienta a otra.

UML es un lenguaje visual para el modelado e intercambio de modelos bien

definidos para el desarrollo de software. Aunque a un nivel básico UML suple muchas de las necesidades de los usuarios, esta puede ser especializada para incorporar aspectos que no contemplaban otras herramientas. Esta diseñado

para soportar herramientas y colaboración utilizando marcos de trabajo, patrones y componentes.

UML define una notación gráfica para cada uno de los siguientes diagramas: de

casos, de uso, de clases, de comportamiento, de implementación incluyendo

diagramas de componentes y de desarrollo.

Modelo de componentes de CORBA (CORBABeans)

CORBAComponents extiende el modelo de objeto de la OMG para incluir un

número de características importantes en un sistema distribuido. La noción de

componente puede no corresponder al modelo uno a uno ni de un objeto CORBA, esta centrado más en la relación de un Componente con un conjunto de Interfaces.

Los componentes tienen identificadores de instancias, así como propiedades

que son externamente accedidas y que soporta mecanismos de notificación (servicio de eventos) y validación cuando alguna propiedad cambia. Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

149


Los componentes de CORBA serán trasladados a los lenguajes ya soportados, y a otros modelos de componentes como los Java Beans. Igualmente se esta trabajando en una especificación para un lenguaje de scripting que facilite el

nivel de usuario la utilización de componentes.

Control de la Calidad del Servicio

Mensajes Asincrónicos y Control de Calidad del Servicio.

La nueva especificación de Mensajería define un número de modos de

invocaciones asincrónicas e independientes del tiempo para CORBA el cua l permite tanto invocaciones estáticas como dinámicas en cada modo. Las invocaciones asincrónicas pueden ser realizadas de dos formas: censando (polling) o callback.

Las políticas permite tener control de la Calidad del Servicio de las invocaciones,

los clientes y objetos pueden establecer control de ordenación (por tiempo, prioridad, deadline), configurar prioridades, deadlines y tiempos de vida,

configurar tiempos de inicio y finalización para invocaciones sensibles al tiempo

y controlar las políticas de enrutamiento y número de saltos.

Tiempo Real, Tolerancia a Fallos y CORBA Mínimo.

Aunque ya hay muchos desarrollos de productos de tiempo real en CORBA y

que hay un grupo de trabajo en el área en la OMG, la incorporación de aspectos de tiempo real en un ORB es opcional, es decir no es obligatorio que cumpla

requisitos de tiempo real para un proveedor de ORBs. Pero si un proveedor ofrece esta característica en sus productos, deberá cumplir las especificaciones

definidas para tal caso. La primera especificación cubrirá aspectos como Planificadores de prioridad fija, control de los recursos del ORB para predictibilidad extremo a extremo y comunicaciones flexibles.

El nuevo Adaptador de Objetos Portable (POA), que permite a una

implementación acoplarse a un ORB es lo suficientemente robusto y flexible para soportar redundancia y tolerancia a fallos en ambientes CORBA, pero aún es necesario trabajar directamente en este campo por parte de la OMG. Así se ha presentado una propuesta para tolerancia a fallos en modo de redundancia

activa y pasiva.

Aunque CORBA 2.0 especifica muchos requisitos para garantizar la

interoperabilidad entre proveedores de ORBs, hay ciertos casos en los cuales una implementación “liviana” de un ORB sería altamente recomendable, por

ejemplo en implementaciones en chips o en sistemas embebidos. Para esto se ha definido una RFP para CORBA mínimo que determine los requerimientos Modelo Paracurricular – Desarrollador de Software – 2004 – V.1.0.

150


mínimos que sí deben ser cumplidos para una especificación de “CORBA Mínimo”.

material de apoyo 3.3 3.3 corba · 1991. hoy en día, el último estándar aprobado de corba está...

Documents