INTRODUCCIÓN CORBA

INTRODUCCIÓN CORBA es una tecnología que oculta la programación a bajo nivel de aplicaciones distribuidas, de tal forma que el programador no se tiene que ocupar de tratar con sockets, flujos de datos, paquetes, sesiones etc. CORBA oculta todos estos detalles de bajo nivel. No obstante CORBA también brinda al programador una tecnología orientada objetos, las funciones y los datos se agrupan en objetos, estos objetos pueden estar en diferentes máquinas, pero el programador accederá a ellos a través de funcio funciones nes normal normales es den dentro tro de su progra programa. ma. CORBA CORBA propo proporci rciona ona un entor entorno no de desarr desarrol ollo lo y ejecución de aplicaciones distribuidas. La distribución de aplicaciones introduce un nuevo conjunto de dificultades. Sin embargo, algunas veces no hay elección, algunas aplicaciones por su naturaleza deben estar distribuidas a través de múltiples computadoras por alguno de estos motivos:



La aplicación utiliza datos distribuidos



La computación está distribuida



Los usuarios de la aplicación están distribuidos

1. HIST HISTOR ORIA IA DE CO CORB RBA A La arquitectura y las especificaciones descritas en el Common Object Request Broker: Arquitectura y especificaciones libro están dirigidas a los diseñadores y desarrolladores de software que quieran crear aplicaciones que cumplen con las normas de OMG para el intermediario de solicitud de objetos (ORB). El beneficio de cumplimiento es, en general, para ser capaz de producir aplicaciones interoperables que se basan en objetos distribuidos, interoperativos. La información que sigue es una historia de las revisiones hechas al Common Object Request Broker: Arquitectura y especificaciones (CORBA) durante los últimos años.

1.1 CORBA 1.0 (octubre de 1991) Incluye Incluye el modelo de objetos objetos CORBA, Interface Interface Definición Definición Lenguaje Lenguaje (IDL), (IDL), y el conjunto básico de interfaces de programación de aplicaciones (API) para la gestión de solicitudes y la invocación dinámica (DII) y el repositorio de interfaz. Incluye una asignación única lengua para el lenguaje C.

1.2 CORBA 1.1 (febrero de 1992) Esta fue la primera versión ampliamente publicada de la especificación CORBA. Se cerró muchas ambigüedades en la especificación original; añadido interfaces para el adaptador de objetos de base y la gestión de memoria, aclaró el Interface Repositorio, y aclaró ambigüedades en el modelo de objetos.

1.3 CORBA 1.2 (diciembre de 1993) Cerrado varias ambigüedades, sobre todo en la gestión de memoria y la comparación referencia de objeto.

1.4 CORBA 2.0 (agosto de 1996) Primera revisión importante mantener el existente modelo CORBA objeto, y ha añadido varias características importantes: 

Interfaz esqueleto dinámico (espejo (espejo de invocación dinámica) dinámica)



Resolución de referencia inicial para la portabilidad cliente

1. HIST HISTOR ORIA IA DE CO CORB RBA A La arquitectura y las especificaciones descritas en el Common Object Request Broker: Arquitectura y especificaciones libro están dirigidas a los diseñadores y desarrolladores de software que quieran crear aplicaciones que cumplen con las normas de OMG para el intermediario de solicitud de objetos (ORB). El beneficio de cumplimiento es, en general, para ser capaz de producir aplicaciones interoperables que se basan en objetos distribuidos, interoperativos. La información que sigue es una historia de las revisiones hechas al Common Object Request Broker: Arquitectura y especificaciones (CORBA) durante los últimos años.

1.1 CORBA 1.0 (octubre de 1991) Incluye Incluye el modelo de objetos objetos CORBA, Interface Interface Definición Definición Lenguaje Lenguaje (IDL), (IDL), y el conjunto básico de interfaces de programación de aplicaciones (API) para la gestión de solicitudes y la invocación dinámica (DII) y el repositorio de interfaz. Incluye una asignación única lengua para el lenguaje C.

1.2 CORBA 1.1 (febrero de 1992) Esta fue la primera versión ampliamente publicada de la especificación CORBA. Se cerró muchas ambigüedades en la especificación original; añadido interfaces para el adaptador de objetos de base y la gestión de memoria, aclaró el Interface Repositorio, y aclaró ambigüedades en el modelo de objetos.

1.3 CORBA 1.2 (diciembre de 1993) Cerrado varias ambigüedades, sobre todo en la gestión de memoria y la comparación referencia de objeto.

1.4 CORBA 2.0 (agosto de 1996) Primera revisión importante mantener el existente modelo CORBA objeto, y ha añadido varias características importantes: 

Interfaz esqueleto dinámico (espejo (espejo de invocación dinámica) dinámica)



Resolución de referencia inicial para la portabilidad cliente



Exte Extens nsio ione ness para para el Inte Interf rfac acee Repo Reposi sito tory ry "Out "Out of the the box" box" arqu arquit itec ectu tura ra de

interoperabilidad interoperabilidad (GIOP, IIOP, DCE CIOP) 

Apoyo a la seguridad seguridad por capas y servicios de de transacción



Extensiones de tipo de datos de COBOL, el procesamiento científico, caracteres de

ancho interfuncionamiento con OLE2/COM 

Incluido en este comunicado son la especificación del protocolo de interoperabilidad,

mejoras en la interfaz del repositorio, inicialización y dos asignaciones lenguaje IDL (C + + y Smalltalk).

1.5 CORBA 2.1 (agosto de 1997) Otras funciones de seguridad adicionales (seguro IIOP y IIOP sobre SSL), agregó dos asignaciones de lenguaje (COBOL y Ada), incluyó revisiones de interoperabilidad y las extensiones de tipo IDL.

1.6 CORBA 2.2 (febrero de 1998) Esta Esta vers versió iónn de CORB CORBA A incl incluy uyee la port portab abil ilid idad ad del del serv servid idor or mejo mejora rass (POA (POA), ), Interfuncionamiento DCOM, y la especificación de mapeo IDL / JAVA lenguaje.

1.7 CORBA 2.3 (junio de 1999) Esta versión de CORBA incluye las siguientes especificaciones nuevas o revisadas: 

COM / CORBA Parte A y B (orbos/97-09-0 ( orbos/97-09-07), 7), (orbos/97-09-06, 97-09-19)



Portabilidad IDL / Java



Java a IDL Mapping Idioma



IDL a lenguaje Java Mapping



Core y reportes RTF (ptc/98-09-04), (ptc/98-07-05), (ptc/99-03-01, 99-03-02)

1.8 CORBA 2.4 (octubre de 2000)

Esta versión de CORBA incluye las siguientes especificaciones: 

Mensajería especificación (orbos/98-05-05)



Core y 2,4 RTF (ptc/99-12-06), (ptc/99-12-07), (ptc/99-12-08)



Naming FTF informe (ptc/99-12-02, 99-12-03, 99-12-04)



Notificación de servicio (formal/00-06-20)

1.9 CORBA 2.5 (septiembre de 2001) Esta versión de CORBA incluye las siguientes especificaciones: 

Tolerante a Fallos (ptc/00-04-04)



Mensajería (cambios de redacción)



Interceptores portátiles (ptc/01-03-04)



Realtime CORBA (ptc/00-09-02)



RTF salidas de CORBA Core, Interop, OTS, etc

1.10 CORBA 2.6 (diciembre de 2001) Esta versión de CORBA incluye las siguientes especificaciones: 

Seguridad Común (orbos/2000-08-04, ptc/01-03-02, ptc/01-06-09)



Core RTF 12/2000 y la interoperabilidad RTF 12/2000 (ptc/01-06-10, ptc/01-06-08,

ptc/01-06-01)

1.11 CORBA 3.0 (julio de 2002) La especificación CORBA Core, v3.0 (formal/02-06-01) incluye actualizaciones basadas en la producción de la RTF Core (ptc/02-01-13, ptc/02-01-14, ptc/02-01-15 ), el RTF Interop (ptc/02-01-14 ptc/02-01-15, ptc/02-01-18), y la plantilla de referencia a objeto

(ptc/01-08-31, ptc/01-10- 23, ptc/01-01-04). El Modelo de Componentes CORBA, v3.0 (formal/02-06-65), publicado al mismo tiempo como una especificación independiente, permite una mayor integración con Java y otras tecnologías de componentes, lo que hace que sea más fácil para los programadores a utilizar CORBA, y su número de versión inicial de 3,0 significa su conformidad con esta versión de CORBA y IIOP. Además de esta versión, mínima y CORBA en tiempo real CORBA (CORBA tanto añade Core en la versión 2.4) se convierten en documentos separados.

1.12 CORBA 3.0.2 (diciembre de 2002)



Formal /02-12-02 - editorial menor a actualizar los capítulos 4 y 22.

OMG FORMALMENTE LANZADO VERSIONES DE CORBA ® Versión 3,3

Fecha de lanzamiento: 11 2012

URL http://www.omg.org/spec/CORBA/3.3

3,2 3.1.1

11 2011 08 2011

http://www.omg.org/spec/CORBA/3.2/

3,1 3.0.3

01 2008 03 2004


3.0.2

12 2002

http://www.omg.org/spec/CORBA/3.0.2/

3.0.1 3,0

11 2002


06 2002


2.6.1

05 2002


2,6

12 2001


2,5

09 2001


2.4.2

02 2001


2.4.1

11 2000


2,4

10 2000




2.3.1

10 1999


2,3

06 1999


2,2

02 1998


2,1

09 1997


2,0

02 1997


1,2

12 1993


1,1

12 1991


1,0

08 1991


2. CONCEPTO 2.1 ¿Qué es CORBA? ¿Qué hacer? CORBA es el acrónimo de Arquitectura Broker Common Object Request, abierto OMG, la arquitectura independiente del proveedor y la infraestructura de las aplicaciones informáticas que utilizan para trabajar juntos a través de redes. Utilizando el protocolo estándar IIOP, un programa basado en CORBA de cualquier proveedor, en casi cualquier ordenador, sistema operativo, lenguaje de programación, y la red, puede interoperar con un programa basado en CORBA del mismo o de otro proveedor, en casi cualquier otro equipo, sistema operativo, lenguaje de programación, y la red. En un sentido general, CORBA "envuelve" el código escrito en otro lenguaje, en un paquete que contiene información adicional sobre las capacidades del código que contiene y sobre cómo llamar a sus métodos. Los objetos que resultan, pueden entonces ser invocados desde otro programa (u objeto CORBA) desde la red. En este sentido CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras, pero con más información. CORBA utiliza un lenguaje de definición de interfaces ( IDL) para especificar las interfaces con los servicios que los objetos ofrecerán. CORBA puede especificar a partir de este IDL, la interfaz a un lenguaje determinado, describiendo cómo los tipos de dato

CORBA deben ser utilizados en las implementaciones del cliente y del servidor. Implementaciones

estándar

existen

para Ada, C,C+

+, Smalltalk, Java, Python, Perl y Tcl. Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto). El código del cliente sirve para poder realizar las llamadas a métodos remotos. Es el conocido como stub, el cual incluye un proxy (representante) del objeto remoto en el lado del cliente. El código generado para el servidor consiste en unos skeletons (esqueletos) que el desarrollador tiene que rellenar para implementar los métodos del objeto. CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones. Y así este no es un sistema operativo en sí, en realidad es un middleware. El Object Management Group (OMG) es responsable de la definición de CORBA. El OMG comprende más de 700 empresas y organizaciones, incluyendo a casi todos los principales fabricantes y desarrolladores de tecnología de objetos distribuidos, incluyendo la plataforma, base de datos y proveedores de aplicaciones, así como de herramientas de software y desarrolladores El Common Object Request Broker Architecture (CORBA) [OMG: 95a] es un emergente abierta infraestructura de computación distribuida objeto siendo normalizado por el Object Management Group (OMG). CORBA automatiza muchas de las tareas comunes de programación de red, tales como el registro de objeto, la ubicación y la activación; de multiplexación solicitud, elaboración y control de errores, el parámetro de clasificación y demarshalling y operación de despacho. La figura siguiente muestra los principales componentes de la arquitectura del modelo de referencia OMG. Las descripciones de estos componentes están disponibles a continuación. Algunas partes de estas descripciones se basan en material de [Vinoski].

2.2 Arquitectura Del Modelo De Referencia OMG.

a) Servicios de objeto. Estos son independientes del dominio de interfaces que se utilizan en muchos programas de objetos distribuidos. Por ejemplo, un servicio que proporciona para el descubrimiento de otros servicios disponibles casi siempre es necesario independientemente del dominio de aplicación. Dos ejemplos de servicios de objeto que cumplen esta función son: 

El servicio de nombres. Que permite a los clientes encontrar objetos basados en nombres;



El Servicio de Trading. Que permite a los clientes encontrar objetos en función de sus propiedades. También hay especificaciones objeto de servicio para la gestión del ciclo de vida, seguridad, transacciones, y notificación de eventos, así como muchos otros [OMG: 95b].

b) Instalaciones comunes. Como las interfaces de objeto de servicio, estas interfaces son también orientados horizontalmente, pero a diferencia de Servicios de objeto están orientados hacia las aplicaciones de usuario final. Un ejemplo de este tipo de instalaciones es el Fondo

para el Documento de componentes distribuido (DDCF), un documento compuesto Fondo Común basada en OpenDoc. DDCF permite la presentación y el intercambio de objetos basado en un modelo de documento, por ejemplo, facilitar la vinculación de un objeto de hoja de cálculo en un documento de informe.

c) Interfaces de dominio Estas interfaces de llenar papeles similares a los servicios e instalaciones de objetos comunes, pero están orientados hacia los dominios de aplicación específicos. Por ejemplo, uno de los primeros OMG RFP emitidas para interfaces de dominio es para gestión de datos de productos (PDM) habilitadores para el dominio de la fabricación. Otros RFP OMG pronto se publicará en los sectores de telecomunicaciones, médica y dominios económicos.

d) Interfaces de Aplicación. Estas son interfaces desarrolladas específicamente para una aplicación dada. Debido a que son específicos de la aplicación, y porque el OMG no desarrolla aplicaciones (sólo las especificaciones), estas interfaces no están normalizadas. Sin embargo, si con el tiempo parece que algunos servicios útiles en general surgen de un dominio de aplicación concreto, pueden ser candidatos para la futura estandarización OMG.

3. ¿QUÉ ES BUENO PARA CORBA? CORBA es útil en muchas situaciones. Debido a la forma sencilla que integra CORBA máquinas de tantos vendedores, con tamaños que van desde mainframes a través de ministerios y escritorios para sierras manuales y los sistemas integrados, es el middleware de elección para los grandes (e incluso no tan grandes) empresas. Uno de los más

importantes, así como la más frecuente, utiliza está en los servidores que deben manejar gran número de clientes, con tasas altas de golpe, con una alta fiabilidad. CORBA trabaja detrás de las escenas en las aulas de informática de muchos de los mayores sitios web del mundo, los que es probable que usamos todos los días. Especializaciones para la escalabilidad y tolerancia a fallos apoyar estos sistemas. Pero no sólo se utiliza para aplicaciones de gran tamaño, las versiones especializadas de CORBA ejecutar sistemas de tiempo real, y los pequeños sistemas embebidos Las cuatro claves para la orientación a objetos son 

Encapsulación



Polimorfismo



Herencia



Instanciación

En CORBA, el cliente y el objeto pueden ser escritos en diferentes lenguajes de programación!

4. LA ARQUITECTURA CORBA Está orientada a objetos. Los objetos CORBA presentan muchas características de otros sistemas orientados a objetos, incluyendo la herencia de interfaces y el polimorfismo. Lo que hace a CORBA más interesante es que proporciona estas capacidades, incluso cuando es utilizado en lenguajes no orientados a objeto como C o COBOL, aunque CORBA trabaja particularmente bien con los lenguajes orientados a objeto como C++ y Java. Dentro de las nuevas técnicas y lenguajes de modelado de objetos, cabe destacar la notación estándar UML (Unified Modeling Language), cuya última actualización es UML 1.2 a mediados de 1998. UML es una evolución de las metodologías orientadas a objeto anteriores, como Booch, OMT, y OOSE, tratando de unificar lo mejor de cada una de ellas. UML ha dado lugar un potente lenguaje visual, para expresar diseños orientados a objetos, consistente en palabras, textos, gráficos y símbolos.

Cabe destacar, sin embargo, que UML es sólo un estándar de notación. Esencialmente, define un cierto número de diagramas que se pueden dibujar para describir un sistema y el significado de dichos diagramas. UML no describe el proceso a seguir al desarrollar el software, también considerado en la metodología formal tradicional.

5. CORBA ORB ARCHITECTURE La figura siguiente muestra los principales componentes de la arquitectura CORBA ORB. Las descripciones de estos componentes están disponibles por debajo de la figura.

a) Object. Esta es una entidad de programación CORBA que consta de una identidad, una interfaz, y una aplicación, que se conoce como un Sirviente.

b) Sirviente.

Esta es una aplicación de programación entidad lenguaje que define las operaciones que soportan una interfaz CORBA IDL. Funcionarios se puede escribir en una variedad de idiomas, incluyendo C, C + +, Java, Smalltalk, y Ada.

c) Cliente. Es la entidad del programa que invoca una operación en una implementación de objeto. Acceso a los servicios de un objeto remoto debe ser transparente para el llamante. Idealmente, debería ser tan simple como llamar a un método en un objeto, es decir, obj-> op (args). Los componentes restantes de la Figura 2 ayudar a mantener este nivel de transparencia.

d) Object Request Broker (ORB). El ORB proporciona un mecanismo para comunicar de manera transparente las solicitudes de cliente para apuntar implementación de los objetos. El ORB simplifica la programación distribuida, disociando al cliente de los detalles de las llamadas a métodos. Esto hace que las solicitudes de cliente parecen ser llamadas locales procedimiento. Cuando un cliente invoca una operación, el ORB es responsable de encontrar la implementación del objeto, de forma transparente que activar en caso necesario, la entrega de la solicitud al objeto, y devolver cualquier respuesta a la persona que llama.

e) ORB Interface. Un ORB es una entidad lógica que puede ser implementado de varias formas (tales como uno o más procesos o un conjunto de bibliotecas). Para separar las aplicaciones de los detalles de implementación, la especificación CORBA define una interfaz abstracta para un ORB. Esta interfaz proporciona varias funciones de ayuda, tales como la conversión de referencias de objetos a cadenas y viceversa, y la creación de listas de argumentos para las solicitudes realizadas a través de la interfaz de invocación dinámica se describe a continuación.

f) CORBA IDL talones y esqueletos. Talones de CORBA IDL y esqueletos servir como el pegamento '' entre las aplicaciones cliente y servidor, respectivamente, y el ORB. La transformación entre CORBA IDL definiciones y el lenguaje de programación objetivo es automatizado por un compilador CORBA IDL. El uso de un compilador reduce el potencial de las incoherencias entre los talones de cliente y esqueletos de servidor y aumenta las oportunidades para optimizaciones del compilador automatizados.

g) Invocación dinámica Interface (DII). Esta interfaz permite a un cliente acceder directamente a los mecanismos de solicitud correspondientes presentada por un ORB. Las aplicaciones utilizan la DII para emitir peticiones dinámicamente a los objetos sin necesidad de IDL específicos de la interfaz talones de estar vinculado pulg A diferencia de los talones de IDL (que sólo permiten al estilo RPC solicitudes), el DII también permite a los clientes hacer sin bloqueo diferido sincrónico (por separado enviar y las operaciones de recepción) y llama unidireccional (send-only).

h) Interfaz de Esqueleto Dinámico (DSI). Esta es analógico el lado del servidor para DII del lado del cliente. La DSI permite un ORB para entregar peticiones para una implementación de objeto que no tiene tiempo de compilación el conocimiento del tipo de objeto al que está aplicación. El cliente realiza la solicitud no tiene ni idea de si la aplicación está utilizando los esqueletos de tipo específico IDL o está utilizando los esqueletos dinámicos.

i) Adaptador Object. Esto ayuda al ORB con la entrega de solicitudes para el objeto y con la activación del objeto. Más importante aún, un objeto adaptador implementación de los objetos

asociados con el ORB. Adaptadores de objetos pueden ser especializados para prestar apoyo a ciertos estilos de objeto de aplicación (como adaptadores de objetos OODB para adaptadores de persistencia de objetos y la biblioteca de la falta de objetos remotos).

6. El ORB 6.1 Misión del ORB Una parte fundamental de la arquitectura CORBA es el ORB, componente software cuyo fin es facilitar la comunicación entre objetos. El ORB se encarga de enviar las peticiones a los objetos y retornar las respuestas a los clientes que invocan las peticiones. La principal característica del ORB es la transparencia, cómo facilita la comunicación cliente/servidor. Generalmente, el ORB oculta lo siguiente: 

Ubicación de los objetos. El cliente no sabe dónde se encuentra el objeto destino.

Puede residir en un proceso diferente en otra máquina a través de la red, o dentro del mismo proceso 

Implementación de los objetos. El cliente no sabe cómo esta implementado el

objeto remoto, en qué lenguaje de programación o descripts está escrito, o el sistema operativo y el hardware, sobre el que se ejecuta. 

Estado de ejecución del objeto. Cuando el cliente lanza una petición sobre un

objeto remoto, no necesita saber si el objeto está en ese momento en ejecución, y listo para aceptar peticiones. El ORB de forma transparente inicializa el objeto en caso de ser necesario, antes de enviarle la petición



Mecanismos de comunicación de los objetos. El cliente no sabe qué mecanismos

de comunicación (por ejemplo, TCP/IP, memoria compartida, llamada a método local) utiliza el ORB para enviar la petición al objeto y retorna la respuesta al cliente. Estas características del ORB permiten a los desarrolladores de aplicaciones preocuparse más por las cuestiones propias del dominio de sus aplicaciones y desentenderse de las cuestiones de programación a bajo nivel del sistema distribuido. La idea de un ORB es la siguiente, cuando un componente de aplicación quiere utilizar un servicio proporcionado por otro componente, primero debe obtener una referencia para el objeto que proporciona ese servicio. Después de obtenerla, el componente puede llamar a los métodos en ese objeto, accediendo así a los servicios proporcionados por éste; evidentemente el programador del componente cliente debe saber en tiempo de compilación que métodos están disponibles por un objeto servidor particular. La principal responsabilidad de ORB es resolver las peticiones por las referencias a objetos, posibilitando a los componentes de aplicación establecer conectividad entre ellos. Cuando se crea un objeto CORBA también se crea una referencia para él. Cuando es utilizada por un cliente, la referencia siempre -durante toda la vida del objeto-, se refiere a dicho objeto para la que fue creada. En otras palabras, la referencia a un objeto siempre hace referencia a un único objeto. Las referencias a objetos son inmutables y opacas, de esta forma un cliente no puede manipular una referencia y modificarla. Las referencias a objetos pueden tener un formato estándar o propietario. Los clientes pueden obtener las referencias a objetos de muy diversas formas: 

En la creación de objetos. El cliente puede crear un nuevo objeto y conseguir así

una referencia al objeto. 

A través del servicio de directorio. El cliente puede invocar a un servicio de

búsqueda de cualquier tipo, con el fin de obtener referencias a objetos. Estos servicios no crean nuevos objetos, sino que almacenan referencias a objetos e información asociada (por ejemplo, nombres y propiedades) para los objetos existentes, y los proporcionan previa solicitud. 

Convirtiendo la referencia al objeto en una cadena y recuperándola. Una

aplicación puede solicitar al ORB que convierta una referencia a un objeto en una

cadena, y esta cadena almacenarla en un fichero o base de datos. Más tarde, la cadena puede ser recuperada y transformada nuevamente en una referencia a un objeto por el ORB.

6.2 Marshaling Después de que el componente de una aplicación haya obtenido la referencia a un objeto, el componente puede invocar métodos en dicho objeto. Generalmente, dichos métodos tienen ciertos parámetros como entrada, y retornan otros parámetros como salida. El ORB es el encargado de clasificar esos parámetros; es decir, trasformar los parámetros procedentes del componente que invoca los métodos remotos, a un formato estándar, denominado formato de red y después al formato entendible por el componente que tiene dichos métodos. El ORB se encarga así mismo de desclasificar los parámetros de salida retornados por el método, convirtiéndolos de la representación de la red al formato que entiende este componente invocador. El proceso total de clasificación tiene lugar sin intervención alguna por parte del programador. Una aplicación cliente simplemente invoca el método remoto deseado, que para él tiene la apariencia de un método local, y el resultado es retornado o se lanza una excepción, de nuevo, como si se tratase de un método local.

6.3 Independencia de la plataforma Un resultado del proceso de clasificación y desclasificación es, que debido a que los parámetros se convierten en la transmisión a un formato independiente de la plataforma, la comunicación entre componentes es independiente de la plataforma. Esto significa que, por ejemplo, un cliente ejecutándose en un sistema Macintosh puede invocar métodos en un servidor ejecutándose en un sistema Unix. Además de la independencia del sistema operativo utilizado, las diferencias de hardware, como puede ser el orden de los bytes más significativos o el tamaño de una palabra, son así mismo irrelevantes, ya que el ORB hace automáticamente la conversión necesaria.

7. El IDL El lenguaje de definición de interfaz o IDL (Interface Definition Language), es un lenguaje muy sencillo utilizado para definir interfaces entre componentes de aplicación. Es

importante destacar que IDL sólo puede definir interfaces, no implementaciones. IDL, al especificar las interfaces entre objetos CORBA, es el instrumento que asegura la independencia del lenguaje de programación utilizado. Para ello, la especificación IDL ha de asegurar que los datos son correctamente intercambiados entre dos lenguajes distintos. Por ejemplo, el tipolong es un entero con signo de 32 bits, que se puede hacer corresponder con un long de C++ (dependiendo de la plataforma) o a un int de Java. Es responsabilidad de la especificación IDL (y de los compiladores IDL que la implementan), definir dichos tipos de datos de una forma independiente del lenguaje. IDL consigue la independencia del lenguaje a través de una correspondencia. El OMG ha definido bastantes correspondencias con lenguajes de programación populares, como: C, C+ +, COBOL, Java, Smalltalk y Ada. Las correspondencias para otros lenguajes también existen, pero o no son estándar o están en proceso de estandarización. En la Tabla 1 se muestra la correspondencia entre los tipos IDL y los tipos C++. Describiendo las interfaces IDL, un ORB genera automáticamente código en el lenguaje seleccionado para realizar la integración de las aplicaciones distribuidas. Evidentemente, puesto que sólo describe interfaces, todas las tareas complejas relacionadas con los lenguajes de programación, como control de flujo, gestión de memoria, composición funcional, no aparecen en IDL. Evidentemente, la independencia del lenguaje de programación es una característica muy importante de la arquitectura CORBA. CORBA da a los programadores de la aplicación la libertad para elegir el lenguaje que mejor se adapta a las necesidades de su aplicación o bien utilizar varios lenguajes para varios componentes de la aplicación. Por ejemplo, el cliente de una aplicación podría estar implementado en Java, lo que asegura que los clientes pueden ejecutarse virtualmente en cualquier máquina. Los componentes servidores de dicha aplicación podrían implementarse en C++, para conseguir una elevada eficiencia. CORBA hace posible la comunicación entre estos componentes de diversa naturaleza.

IDL

C++

Short

CORBA::Short

Long

CORBA::Long

Unsigned short CORBA::UShort Unsigned long

CORBA::ULong

Float

CORBA::Float

Double

CORBA::Double

Char

CORBA::Char

Boolean

CORBA::Boolean

Octect

CORBA::Octect

Any

CORBA::Any

Tabla: Correspondencia para los tipos de datos básicos.

7.1 El registro de interfaz Todas las aplicaciones basadas en CORBA necesitan acceder al tipo de sistema de IDL cuando se están ejecutando. Esto es necesario porque la aplicación necesita conocer los tipos de valores a ser pasados como argumentos de la petición. Asimismo, la aplicación ha de conocer los tipos de interfaces soportados por los objetos que están utilizando. Ciertas aplicaciones requieren sólo un conocimiento estático del tipo de sistema IDL. Típicamente, la especificación IDL es compilada o traducida a código para el lenguaje de programación de la aplicación siguiendo las reglas de traducción como es definido por su correspondencia con el lenguaje. De esta forma, si el tipo del sistema IDL cambia de tal modo que pasa a ser incompatible con el tipo de sistema construido en la aplicación, la aplicación ha de volver a construirse. Pero hay ciertas aplicaciones, sin embargo, para las cuales es imposible un conocimiento estático del tipo de sistema IDL. Para estas aplicaciones CORBA proporciona otro método de definir interfaces sustituyendo a IDL, el registro de interfaz. Las interfaces pueden ser añadidas a un servicio de registro de interfaz, el cual define las operaciones para la recuperación de la información del almacén en tiempo de ejecución. Utilizando el registro de interfaz, un cliente podría ser capaz de ubicar un

objeto desconocido en tiempo de compilación, preguntar acerca de su interfaz, y después construir una petición a ser enviado a través del ORB.

7.2

Los tipos estructurados de IDL

8. CARACTERÍSTICAS



Permite invocar métodos de objetivos remotos sin que importe el lenguaje en el que

estén escritos el llamador y el llamado, ni las plataformas (sistema operativo y hardware) y redes de comunicación intermedias. 

Incluye un buen número de servicios: nombres, trading (comercio), seguridad,

transacciones, persistencia, notificaciones, etc. Esta estandarizado por el OMG (Object Management Group) 

El mayor consorcio de la industria de software.



Solo emite especificaciones (no existe implementación de referencia).



Las especificaciones se desarrollan por consenso son públicas y gratuitas.



Existen muchos fabricantes que implementan las especificaciones más importantes

para las plataformas más usuales. 

También estandariza UML (Unified Modeling Language).

9. VENTAJAS DE CORBA

9.1 Heterogeneidad: Un sistema heterogéneo consiste en conjuntos de elementos interconectados de hardware y software de diferente fabricante y que puede integrar aplicaciones de diferente tecnología.

9.2 Movilidad: La migración de procesos en sistemas distribuidos tradicionales es muy útil para mejorar el reparto de carga de los diferentes computadores. Tiene como fin garantizan el rendimiento global y ciertas restricciones de administración o seguridad.

9.3 Eficiencia 

La red lleva menos mensajes.



El servidor realiza más trabajo



Se evita la latencia/inestabilidad de la red en los procesos.

9.4 Adaptación al cliente  

El cliente puede extender la funcionalidad del servidor Fácil instalación para el usuario



No se requiere instalación de servidor.



No se acuerdan los procedimientos entre los clientes y los servidores



Instalación dinámica de los procedimientos del- cliente en el servidor.

9.5 Tiempo de desempeño: Además, la ejecución asíncrona permite que los procesos controlen la gestión y terminación de tarea y que el cliente pueda finalizar o continuar haciendo otras cosa en su sistema, por otro lado se reduce el tráfico en la red y la capacidad de cómputo del cliente

Figura2: Tiempos en la red utilizando corba 9.6 Robusto 

Reducción de la dependencia de la disponibilidad de la red y del cliente/servidor



Los procesos migrados al sistema servidor no se ven afectados por los fallos del

cliente o de la red 

Los procesos se ejecutan realizando tareas específicas en lugares diferentes



Automatización de las tareas distribuidas.



10. DESVENTAJAS DE CORBA El problema fundamental de los sistemas de integración es el software. Aún no existe mucha experiencia en el diseño, implantación y uso de software como CORBA. Precisamente, éste es un campo de investigación actual. Las redes son indispensables para la comunicación entre máquinas; sin embargo, pueden plantear problemas de saturación, embotellamiento, interrupción o pérdidas de mensajes. El posible acceso a todo el sistema por parte de los usuarios plantea el inconveniente de la necesidad de un sistema de seguridad adecuado y estándar, aunque CORBA maneja la seguridad.

10.1 Complejidad Permite la interoperabilidad de distintos lenguajes y sistemas operativos hace que sea un estándar bastante complejo, y su uso no sea tan transparente al programador como sería deseable Hay usar un compilador que traduce una serie de tipos de datos estándares a los tipos del lenguaje en el que se vaya a programar (IDL). Hay que ser conscientes a la hora de diseñar que objetos van a ser remotos y cuales no ( los remotos sufren restricciones en cuanto a sus capacidades con respecto a un objeto normal) Es necesario emplear tipos de datos que no son los que proporciona de manera habitual el lenguaje de programación (muchas veces hay que emplear tipos de datos adaptados de IDL)

10.2 Incompatibilidad entre implementaciones.-

Muchas empresas ofrecen implementaciones COBRA, si bien el grado de cumplimiento es diverso. Las divergencias entre ORBs radican en detalles que aunque no hacen imposible aplicar en uno el mismo diseño de un programa pensado para otro, hacen que la adaptación sea fastidiosa. Cuestiones como la colocación de librerías o las diferentes formas de implementar la gestión de la concurrencia, hacen difícil la portabilidad del código y obliga al programador a reciclarse cuando quiere cambiar de ORB. Además, donde el estándar no, concreta, las implementaciones pueden varias entre sí, lo que da lugar a ,molestas incompatibilidades que complican la vida al usuario

11. ASPECTOS DE CORBA Los aspectos a tener en cuenta es la forma de manejar los siguientes puntos: 

Interfaces.



Transparencia de Ubicación.



Invocación a métodos remotos.



Activación de los objetos.

11.1 Interfaces CORBA soporta el trabajo en entornos heterogéneos (permite interoperabilidad entre distintas máquinas y con objetos escritos en diferentes lenguajes) gracias a la clara separación entre la interfaz y la implementación. Para lograr esto necesita que los objetos definan su interfaz de forma común, aunque la implementación se realice en diferentes lenguajes. Para esto CORBA define un lenguaje de definición de interfaces (IDL), a través del cual cada objeto define su interfaz, la cual consiste del nombre del objeto, el nombre De los servicios que brinda (junto con los parámetros que necesita) y posibles atributos y excepciones a los cuales se puede acceder. Cualquier programa nuevo o existente puede convertirse a un objeto CORBA definiendo su interfaz en este lenguaje (IDL).Este lenguaje (IDL) soporta un mecanismo de herencia para la

organización delos objetos. Este mecanismo se aplica solo a las interfaces, en la implementación se debe hacer con los mecanismos del lenguaje usado (si lo provee).

11.2 Transparencia de Ubicación La idea es hacer referencia a otros objetos sin que se conozca la ubicación real de este. Este manejo tiene varias ventajas como: facilita la programación, permite la migración de objetos, permite sacar, agregar o modificar objetos sin alterar el resto del sistema. En CORBA, existe un componente básico llamado Object Request Broker(ORB), el cual se encarga de manejar la comunicación entre el objeto cliente y el objeto servidor de manera de lograr la transparencia de Ubicación buscada. El cliente conoce una referencia al servidor en vez de la ubicación física de este. Esta referencia es un identificador unívoco en todo el sistema que se le otorga al ser creado el objeto. El cliente envía el pedido al ORB indicando la referencia al objeto servidor y el método invocado, este obtiene la ubicación física del servidor, y le reenvía el pedido para que lo resuelva.

11.3 Invocación a Métodos Remotos (RMI) CORBA soporta dos variantes básicas de RMI a partir de diferentes módulos:

11.3.1 La Invocación Estática Es similar a RPC. La interfaz de un objeto se envía junto con un pre compilador con el cual se genera un fragmento de código del lado del cliente (stub) y otro del lado del servidos (skeleton). Una invocación estática sigue los siguientes pasos: 1. El cliente envía el pedido a su stub correspondiente, y queda esperando el resultado en forma pasiva.

2. El stub transforma la invocación (en el lenguaje de la implementación del objeto cliente) a una forma común para todos los objetos (en lenguaje IDL). Y la envía al ORB. 3. El ORB determina la ubicación física del servidor y pasa el pedido al objeto Adapter. 4. El objeto Adapter invoca al skeleton del servidor. 5. El Skeleton transforma la invocación en IDL a una forma conocida por el lenguaje de implementación del objeto servidor y realiza dicha invocación. 6. Al terminar el servicio, el resultado es retornado al cliente.

11.3.2 Invocación Dinámica Es más compleja. CORBA mantiene un depósito de interfaces, la cual almacena todas las interfaces del sistema. Usando este depósito, el cliente puede obtener detalles del objeto servidor, tales como el nombre y los parámetros de un servicio. También se define una Interfaz de Invocación Dinámica (DII) en cada objeto, el cual es una especie de stub despropósito general. Para realizar una Invocación Dinámica el cliente utiliza el depósito de interfaces para obtener el nombre y los parámetros para la invocación, y envía el pedido al DII, el cual actúa de la misma forma que losstub de la invocación estática (transforma el pedido y lo envía al ORB).Este tipo de invocación es más flexible, pero más complejo y lento. Usa un protocolo de dos fases no bloqueante. El cliente entrega el pedido al DII y continúa con su trabajo, después se llama a una segunda función para esperar explícitamente la finalización del servicio. Un modo especial de invocación soportado por CORBA el llamado Oneway. En este caso el cliente no necesita ninguna respuesta al servicio pedido, por lo cual realiza el pedido y continúa con su trabajo, sin asegurarse que el servicio haya sido realizado. De por sí, la invocación estática es bloqueante y la dinámica es no bloqueante, pero esto puede modificarse.

11.4 Activación de Objetos Como no todos los procesos necesitan correr continuamente, los procesos son activados y desactivados por necesidad, y esto es manejado por el objetoAdapter.

Una misma interfaz puede ser implementada por múltiples objetos, cada uno con una referencia o identificador diferente. Los objetos son creados por procesos server, el cual es responsable del objeto durante toda su vida. CORBA mantiene un depósito de implementaciones (de objetos) en donde cada objeto es ubicado al crearse indicando, entre otras cosas, el proceso server que lo creo. Cuando un cliente quiere acceder a un objeto a través de RMI, el objeto adapter chequea si el proceso responsable del objeto al que se Quiere acceder está activado, y en caso contrario lo activa, para después enviar el requerimiento. Todo esto se maneja de forma transparente al programador. Cada vez que se desactiva un proceso, el estado de todos sus objetos (objetos de los cuales es responsable) se pierde. Para mantener el estado, este debe ser guardado en memoria persistente al desactivar el server, de la cual es recuperado al volver a activar el proceso.

11.5 Creación de Objetos Normalmente, los objetos son creados por servidores. CORBA provee unos objetos especiales llamados Factory, los cuales crean objetos en nombre de los clientes.

12. QUE SOLU

CIONA CORBA

a) Aplicaciones Procesos clientes y servidores que representan la lógica del negocio como objetos que pueden residir en distintas máquinas.

b) Middleware Soporte que permite la comunicación entre aplicaciones.

c) Servicios de Red. Transporta la información entre computadores.

d) Servicios Locales. Ejemplo, bases de datos y administradores de transacciones.

e) Sistema Operativo Provee servicios básicos de hardware y scheduling

13. SERVICIOS CORBA Otra parte importante del estándar CORBA es la definición de un conjunto de servicios distribuidos para soportar la integración e interoperabilidad de los objetos distribuidos. Como se muestra en el gráfico de abajo, los servicios (conocidos como CORBA Services oCOS) se encuentran definidos en la parte superior del ORB. Esto es, están definidos como objetos CORBA estándar con interfaces

IDL, algunas veces llamados "Object Services. Existen varios servicios que proporciona CORBA. Los más populares se describen brevemente a continuación:

14. TECNOLOGIA CORBA

14.1 Corba como Plataforma de Distribución e Integración CORBA ofrece la posibilidad de construir mecanismos de integración de sistemas distribuidos por medio de dos especificaciones fundamentales:

15. Interface Definition Language (IDL)

General Inter-ORB Protocol (GIOP) El lenguaje de especificación de interfaces (IDL) permite definir de una forma neutral los servicios que un servidor CORBA ofrece. A partir de la especificación IDL, los compiladores generan código en el lenguaje de programación elegido por los desarrolladores. Esto nos ha permitido, por ejemplo, el especificar la interface de una base de datos de proceso de AspenTech mediante IDL y generar código en C y C++ para interaccionar condicha base de datos cuando el fabricante solo proporciona un API local en C. De esta forma hemos podido acceder desde cualquier punto de la red del complejo químico de Repsol en Tarragona, a datos de la planta almacenados en la base de datos de proceso. El protocolo de interoperabilidad es el que permite que los servicios sean pedidos entra plataformas heterogéneas. Solo es necesario disponer del mismo protocolo en ambas plataformas para poder ofrecer la conectividad cliente-servidor necesaria. La implementación más común del protocolo general GIOPes la denominada Internet Inter-ORB Protocol (IIOP). Ésta es una implementación de GIOP sobre los protocolos básicos de Internet (TCP/IP).Aunque un

servidor CORBA puede ser una aplicación muy compleja, la funcionalidad básica se reduce a ser capaza de hablar el protocolo de interoperabilidad . Existen implementaciones de librería de IIOP que requieren menos de 20KB de memoria, lo que permite distribuir objetos CORBA incluso en plataformas con recursos escasos (por ejemplo sensores inteligentes).

4.2. Corba para Sistemas de Control La especificación de CORBA de tiempo real surge de los esfuerzos de la OMGpor adaptar sus especificaciones para su uso en sistemas distribuidos de tiempo real. Algunas de las especificaciones de relevancia para este ámbito de aplicación son:

16. Minimum CORBA Specification . Este es un perfil de la especificación CORBA básica para su uso en sistemas de bajos recursos. Básicamente, esta especificación elimina las partes de la especificación CORBA que tienen poca utilidad en sistemas que están perfectamente especificados en la etapa de diseño. Todas las partes relativas a la invocación dinámica de servicios y los almacenes de información en caliente se eliminan (para ser más precisos, no se requieren de implementaciones que reclamen ajustarse a la especificación de Mínimum CORBA).

17. Real-Time CORBA Specification

. Esta especificación añade característica nuevas a la especificación CORBA estándar para aumentar el control de los recursos con el fin de mejorar la predecibilidad extremo-a-extremo . Esta especificación reutiliza conceptos de otras especificaciones (por ejemplo el marco de calidad deservicio de la especificación de Messaging o el concepto de tiempo de la especificación Enhanced Time.

18. Fault-Tolerant CORBA Specification . En el ámbito de los sistemas de tiempo real hay muchas aplicaciones que precisan de elevados niveles de tolerancia a fallos. Esta especificación define los servicios de la infraestructura CORBA básica que una aplicación puede necesitar para conseguir dicha tolerancia a fallos. La especificación soporta diversas estrategias de tolerancia a fallos como reintentos de peticiones, redirecciones a servidores alternativas o redundancia tanto pasiva como activa de los objetos servidores.

19. Especificaciones de dominio : hay muchas especificaciones en dominios concretos que son de interés para los ingenieros de control. DAIS/HDAIS (Historical Data Access for Industrial Systems) permite implementar sistemas que ofrecen los mecanismos que OPC ofrece.DDS (Data Distribution Service for RealTime Systems) permite optimizar el flujo masivo de datos entre sistemas de captura de datos y clientes distribuidos. CCM (CORBA Component Model) y LightweighCCM permiten simplificar el despliegue y la gestión de aplicaciones complejas basada en objetos CORBA. La especificación de SmartTransducers introduce mecanismos para la gestión de sensores y actuadores muy empotrados y también clusters de los mismos.

CONCLUSIONES CORBA proporciona una infraestructura y un modelo común desde donde los requisitos expresados en diferentes lenguajes (las diferentes metodologías de desarrollo), pueden ser integrados para formar un sistema globalmente consistente.

CORBA ofrece un conjunto de mecanismos muy útiles a la hora de desarrollar aplicaciones distribuidas, junto con un soporte tecnológico suficientemente maduro como para construir aplicaciones robustas, eficientes y competitivas, a la vez que integrables con otros sistemas que cumplan estos estándares. Los sistemas que son desarrollados con tecnologías antiguas pueden ser integrados con las nuevas a través de CORBA. Esto es, construyendo interfaces para que intercambien información local o remota a través de la red para resolver problemas en forma parcial incremental. CORBA es una tecnología adecuada para implementar sistemas distribuidos y en particular es muy adecuada para la implementación de sistemas distribuidos de control porque simplifica el proceso de diseño, construcción, despliegue y mantenimiento cuando las aplicaciones superan un nivel mínimo de complejidad.

REFERENCIAS BIBLIOGRÁFICAS 

http://es.wikipedia.org/wiki/CORBA



http://www.calcifer.org/documentos/librognome/corba.html



http://www.elai.upm.es/spain/Investiga/GCII/areas/administracion/CORBA.htm



http://www.osmosislatina.com/java/rmi.htm

INTRODUCCIÓN CORBA

Recommend Documents