introducciÓn corba

INTRODUCCIN

CORBA es una tecnologa que oculta la programacin 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 tambin brinda al programador una tecnologa orientada objetos, las funciones y los datos se agrupan en objetos, estos objetos pueden estar en diferentes mquinas, pero el programador acceder a ellos a travs de funciones normales dentro de suprograma. CORBA proporciona un entorno de desarrollo y ejecucin de aplicaciones distribuidas. La distribucin de aplicaciones introduce un nuevo conjunto de dificultades. Sin embargo, algunas veces no hay eleccin, algunas aplicaciones por su naturaleza deben estardistribuidas a travs de mltiples computadoras por algunode estos motivos:

La aplicacin utiliza datos distribuidos La computacin est distribuida Los usuarios de la aplicacin estn distribuidos1. HISTORIA DE CORBA

La arquitectura y las especificaciones descritas en el Common Object Request Broker: Arquitectura y especificaciones libro estn dirigidas a los diseadores 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 informacin que sigue es una historia de las revisiones hechas al Common Object Request Broker: Arquitectura y especificaciones (CORBA) durante los ltimos aos.

1.1 CORBA 1.0 (octubre de 1991) Incluye el modelo de objetos CORBA, Interface Definicin Lenguaje (IDL), y el conjunto bsico de interfaces de programacin de aplicaciones (API) para la gestin de solicitudes y la invocacin dinmica (DII) y el repositorio de interfaz. Incluye una asignacin nica lengua para el lenguaje C.1.2 CORBA 1.1 (febrero de 1992)

Esta fue la primera versin ampliamente publicada de la especificacin CORBA. Se cerr muchas ambigedades en la especificacin original; aadido interfaces para el adaptador de objetos de base y la gestin de memoria, aclar el Interface Repositorio, y aclar ambigedades en el modelo de objetos.

1.3 CORBA 1.2 (diciembre de 1993)

Cerrado varias ambigedades, sobre todo en la gestin de memoria y la comparacin referencia de objeto.

1.4 CORBA 2.0 (agosto de 1996)

Primera revisin importante mantener el existente modelo CORBA objeto, y ha aadido varias caractersticas importantes:

Interfaz esqueleto dinmico (espejo de invocacin dinmica)

Resolucin de referencia inicial para la portabilidad cliente

Extensiones para el Interface Repository "Out of the box" arquitectura de interoperabilidad (GIOP, IIOP, DCE CIOP)

Apoyo a la seguridad por capas y servicios de transaccin

Extensiones de tipo de datos de COBOL, el procesamiento cientfico, caracteres de ancho interfuncionamiento con OLE2/COM

Incluido en este comunicado son la especificacin del protocolo de interoperabilidad, mejoras en la interfaz del repositorio, inicializacin 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 versin de CORBA incluye la portabilidad del servidor mejoras (POA), Interfuncionamiento DCOM, y la especificacin de mapeo IDL / JAVA lenguaje.

1.7 CORBA 2.3 (junio de 1999)

Esta versin de CORBA incluye las siguientes especificaciones nuevas o revisadas:

COM / CORBA Parte A y B (orbos/97-09-07), (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 versin de CORBA incluye las siguientes especificaciones:

Mensajera especificacin (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)

Notificacin de servicio (formal/00-06-20)

1.9 CORBA 2.5 (septiembre de 2001)


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

Mensajera (cambios de redaccin)

Interceptores porttiles (ptc/01-03-04)

Realtime CORBA (ptc/00-09-02)

RTF salidas de CORBA Core, Interop, OTS, etc1.10 CORBA 2.6 (diciembre de 2001)


Seguridad Comn (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 especificacin CORBA Core, v3.0 (formal/02-06-01) incluye actualizaciones basadas en la produccin 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 especificacin independiente, permite una mayor integracin con Java y otras tecnologas de componentes, lo que hace que sea ms fcil para los programadores a utilizar CORBA, y su nmero de versin inicial de 3,0 significa su conformidad con esta versin de CORBA y IIOP. Adems de esta versin, mnima y CORBA en tiempo real CORBA (CORBA tanto aade Core en la versin 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 captulos 4 y 22.

OMG FORMALMENTE LANZADO VERSIONES DE CORBA

VersinFecha de lanzamiento:URL

3,311 2012http://www.omg.org/spec/CORBA/3.3

3,211 2011http://www.omg.org/spec/CORBA/3.2/

3.1.108 2011http://www.omg.org/spec/CORBA/3.1.1/




















2. CONCEPTO

2.1 Qu es CORBA? Qu hacer?

CORBA es el acrnimo de Arquitectura Broker Common Object Request, abierto OMG, la arquitectura independiente del proveedor y la infraestructura de las aplicaciones informticas que utilizan para trabajar juntos a travs de redes. Utilizando el protocolo estndar IIOP, un programa basado en CORBA de cualquier proveedor, en casi cualquier ordenador, sistema operativo, lenguaje de programacin, 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 programacin, y la red.

En un sentido general, CORBA "envuelve" el cdigo escrito en otro lenguaje, en un paquete que contiene informacin adicional sobre las capacidades del cdigo que contiene y sobre cmo llamar a sus mtodos. Los objetos que resultan, pueden entonces ser invocados desde otroprograma(u objeto CORBA) desde la red. En este sentido CORBA se puede considerar como un formato de documentacin legible por la mquina, similar a un archivo de cabeceras, pero con ms informacin.

CORBA utiliza un lenguaje de definicin de interfaces (IDL) para especificar las interfaces con los servicios que los objetos ofrecern. CORBA puede especificar a partir de este IDL, la interfaz a un lenguaje determinado, describiendo cmo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. Implementaciones estndar existen paraAda,C,C++,Smalltalk,Java,Python,PerlyTcl.

Al compilar una interfaz en IDL se genera cdigo para el cliente y el servidor (el implementador del objeto). El cdigo del cliente sirve para poder realizar las llamadas a mtodos remotos. Es el conocido comostub, el cual incluye unproxy(representante) del objeto remoto en el lado del cliente. El cdigo generado para el servidor consiste en unosskeletons(esqueletos) que el desarrollador tiene que rellenar para implementar los mtodos del objeto.

CORBA es ms que una especificacin multiplataforma, tambin define servicios habitualmente necesarios como seguridad y transacciones. Y as este no es un sistema operativo en s, en realidad es unmiddleware.

El Object Management Group (OMG) es responsable de la definicin de CORBA. El OMG comprende ms de 700 empresas y organizaciones, incluyendo a casi todos los principales fabricantes y desarrolladores de tecnologa de objetos distribuidos, incluyendo la plataforma, base de datos y proveedores de aplicaciones, as como de herramientas de software y desarrolladoresEl Common Object Request Broker Architecture (CORBA) [OMG: 95a] es un emergente abierta infraestructura de computacin distribuida objeto siendo normalizado por el Object Management Group (OMG). CORBA automatiza muchas de las tareas comunes de programacin de red, tales como el registro de objeto, la ubicacin y la activacin; de multiplexacin solicitud, elaboracin y control de errores, el parmetro de clasificacin y demarshalling y operacin de despacho.

La figura siguiente muestra los principales componentes de la arquitectura del modelo de referencia OMG. Las descripciones de estos componentes estn disponibles a continuacin. 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 aplicacin. Dos ejemplos de servicios de objeto que cumplen esta funcin 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 funcin de sus propiedades.

Tambin hay especificaciones objeto de servicio para la gestin del ciclo de vida, seguridad, transacciones, y notificacin de eventos, as como muchos otros [OMG: 95b].b) Instalaciones comunes. Como las interfaces de objeto de servicio, estas interfaces son tambin orientados horizontalmente, pero a diferencia de Servicios de objeto estn 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 Comn basada en OpenDoc. DDCF permite la presentacin y el intercambio de objetos basado en un modelo de documento, por ejemplo, facilitar la vinculacin de un objeto de hoja de clculo en un documento de informe.c) Interfaces de dominioEstas interfaces de llenar papeles similares a los servicios e instalaciones de objetos comunes, pero estn orientados hacia los dominios de aplicacin especficos. Por ejemplo, uno de los primeros OMG RFP emitidas para interfaces de dominio es para gestin de datos de productos (PDM) habilitadores para el dominio de la fabricacin. Otros RFP OMG pronto se publicar en los sectores de telecomunicaciones, mdica y dominios econmicos.d) Interfaces de Aplicacin. Estas son interfaces desarrolladas especficamente para una aplicacin dada. Debido a que son especficos de la aplicacin, y porque el OMG no desarrolla aplicaciones (slo las especificaciones), estas interfaces no estn normalizadas. Sin embargo, si con el tiempo parece que algunos servicios tiles en general surgen de un dominio de aplicacin concreto, pueden ser candidatos para la futura estandarizacin OMG.3. QU ES BUENO PARA CORBA?

CORBA es til en muchas situaciones. Debido a la forma sencilla que integra CORBA mquinas de tantos vendedores, con tamaos que van desde mainframes a travs de ministerios y escritorios para sierras manuales y los sistemas integrados, es el middleware de eleccin para los grandes (e incluso no tan grandes) empresas. Uno de los ms importantes, as como la ms frecuente, utiliza est en los servidores que deben manejar gran nmero de clientes, con tasas altas de golpe, con una alta fiabilidad. CORBA trabaja detrs de las escenas en las aulas de informtica de muchos de los mayores sitios web del mundo, los que es probable que usamos todos los das. Especializaciones para la escalabilidad y tolerancia a fallos apoyar estos sistemas. Pero no slo se utiliza para aplicaciones de gran tamao, las versiones especializadas de CORBA ejecutar sistemas de tiempo real, y los pequeos sistemas embebidosLas cuatro claves para la orientacin a objetos son

Encapsulacin

Polimorfismo

Herencia

Instanciacin

En CORBA, el cliente y el objeto pueden ser escritos en diferentes lenguajes de programacin!4. LA ARQUITECTURA CORBA

Est orientada a objetos. Los objetos CORBA presentan muchas caractersticas de otros sistemas orientados a objetos, incluyendo la herencia de interfaces y el polimorfismo. Lo que hace a CORBA ms 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 tcnicas y lenguajes de modelado de objetos, cabe destacar la notacin estndarUML (Unified Modeling Language), cuya ltima actualizacin es UML 1.2 a mediados de 1998. UML es una evolucin de las metodologas 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 diseos orientados a objetos, consistente en palabras, textos, grficos y smbolos.

Cabe destacar, sin embargo, que UML es slo un estndar de notacin. Esencialmente, define un cierto nmero 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, tambin considerado en la metodologa formal tradicional.

5. CORBA ORB ARCHITECTURE

La figura siguiente muestra los principales componentes de la arquitectura CORBA ORB. Las descripciones de estos componentes estn disponibles por debajo de la figura.

a) Object.Esta es una entidad de programacin CORBA que consta de una identidad, una interfaz, y una aplicacin, que se conoce como un Sirviente.b) Sirviente. Esta es una aplicacin de programacin 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 operacin en una implementacin de objeto. Acceso a los servicios de un objeto remoto debe ser transparente para el llamante. Idealmente, debera ser tan simple como llamar a un mtodo 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 implementacin de los objetos. El ORB simplifica la programacin distribuida, disociando al cliente de los detalles de las llamadas a mtodos. Esto hace que las solicitudes de cliente parecen ser llamadas locales procedimiento. Cuando un cliente invoca una operacin, el ORB es responsable de encontrar la implementacin 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 lgica que puede ser implementado de varias formas (tales como uno o ms procesos o un conjunto de bibliotecas). Para separar las aplicaciones de los detalles de implementacin, la especificacin CORBA define una interfaz abstracta para un ORB. Esta interfaz proporciona varias funciones de ayuda, tales como la conversin de referencias de objetos a cadenas y viceversa, y la creacin de listas de argumentos para las solicitudes realizadas a travs de la interfaz de invocacin dinmica se describe a continuacin.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 transformacin entre CORBA IDL definiciones y el lenguaje de programacin 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) Invocacin dinmica 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 dinmicamente a los objetos sin necesidad de IDL especficos de la interfaz talones de estar vinculado pulg A diferencia de los talones de IDL (que slo permiten al estilo RPC solicitudes), el DII tambin permite a los clientes hacer sin bloqueo diferido sincrnico (por separado enviar y las operaciones de recepcin) y llama unidireccional (send-only).h) Interfaz de Esqueleto Dinmico (DSI). Esta es analgico el lado del servidor para DII del lado del cliente. La DSI permite un ORB para entregar peticiones para una implementacin de objeto que no tiene tiempo de compilacin el conocimiento del tipo de objeto al que est aplicacin. El cliente realiza la solicitud no tiene ni idea de si la aplicacin est utilizando los esqueletos de tipo especfico IDL o est utilizando los esqueletos dinmicos.i) Adaptador Object. Esto ayuda al ORB con la entrega de solicitudes para el objeto y con la activacin del objeto. Ms importante an, un objeto adaptador implementacin de los objetos asociados con el ORB. Adaptadores de objetos pueden ser especializados para prestar apoyo a ciertos estilos de objeto de aplicacin (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 Misin del ORB

Una parte fundamental de la arquitectura CORBA es el ORB, componente software cuyo fin es facilitar la comunicacin 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 caracterstica del ORB es la transparencia, cmo facilita la comunicacin cliente/servidor. Generalmente, el ORB oculta lo siguiente: Ubicacin de los objetos. El cliente no sabe dnde se encuentra el objeto destino. Puede residir en un proceso diferente en otra mquina a travs de la red, o dentro del mismo proceso

Implementacin de los objetos. El cliente no sabe cmo esta implementado el objeto remoto, en qu lenguaje de programacin o descriptsest escrito, o el sistema operativo y el hardware, sobre el que se ejecuta.

Estado de ejecucin del objeto. Cuando el cliente lanza una peticin sobre un objeto remoto, no necesita saber si el objeto est en ese momento en ejecucin, y listo para aceptar peticiones. El ORB de forma transparente inicializa el objeto en caso de ser necesario, antes de enviarle la peticin

Mecanismos de comunicacin de los objetos. El cliente no sabe qu mecanismos de comunicacin (por ejemplo, TCP/IP, memoria compartida, llamada a mtodo local) utiliza el ORB para enviar la peticin al objeto y retorna la respuesta al cliente.Estas caractersticas del ORB permiten a los desarrolladores de aplicaciones preocuparse ms por las cuestiones propias del dominio de sus aplicaciones y desentenderse de las cuestiones de programacin a bajo nivel del sistema distribuido.La idea de un ORB es la siguiente, cuando un componente de aplicacin quiere utilizar un servicio proporcionado por otro componente, primero debe obtener una referencia para el objeto que proporciona ese servicio. Despus de obtenerla, el componente puede llamar a los mtodos en ese objeto, accediendo as a los servicios proporcionados por ste; evidentemente el programador del componente cliente debe saber en tiempo de compilacin que mtodos estn 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 aplicacin establecer conectividad entre ellos.

Cuando se crea un objeto CORBA tambin 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 estndar o propietario. Los clientes pueden obtener las referencias a objetos de muy diversas formas: En la creacin de objetos. El cliente puede crear un nuevo objeto y conseguir as una referencia al objeto.

A travs del servicio de directorio. El cliente puede invocar a un servicio de bsqueda de cualquier tipo, con el fin de obtener referencias a objetos. Estos servicios no crean nuevos objetos, sino que almacenan referencias a objetos e informacin asociada (por ejemplo, nombres y propiedades) para los objetos existentes, y los proporcionan previa solicitud.

Convirtiendo la referencia al objeto en una cadena y recuperndola. Una aplicacin 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. Ms tarde, la cadena puede ser recuperada y transformada nuevamente en una referencia a un objeto por el ORB.

6.2 Marshaling

Despus de que el componente de una aplicacin haya obtenido la referencia a un objeto, el componente puede invocar mtodos en dicho objeto. Generalmente, dichos mtodos tienen ciertos parmetros como entrada, y retornan otros parmetros como salida. El ORB es el encargado de clasificar esos parmetros; es decir, trasformar los parmetros procedentes del componente que invoca los mtodos remotos, a un formato estndar, denominado formato de red y despus al formato entendible por el componente que tiene dichos mtodos. El ORB se encarga as mismo de desclasificar los parmetros de salida retornados por el mtodo, convirtindolos de la representacin de la red al formato que entiende este componente invocador.

El proceso total de clasificacin tiene lugar sin intervencin alguna por parte del programador. Una aplicacin cliente simplemente invoca el mtodo remoto deseado, que para l tiene la apariencia de un mtodo local, y el resultado es retornado o se lanza una excepcin, de nuevo, como si se tratase de un mtodo local.6.3 Independencia de la plataformaUn resultado del proceso de clasificacin y desclasificacin es, que debido a que los parmetros se convierten en la transmisin a un formato independiente de la plataforma, la comunicacin entre componentes es independiente de la plataforma. Esto significa que, por ejemplo, un cliente ejecutndose en un sistema Macintosh puede invocar mtodos en un servidor ejecutndose en un sistema Unix. Adems de la independencia del sistema operativo utilizado, las diferencias de hardware, como puede ser el orden de los bytes ms significativos o el tamao de una palabra, son as mismo irrelevantes, ya que el ORB hace automticamente la conversin necesaria.7. El IDL

El lenguaje de definicin de interfaz o IDL (Interface Definition Language), es un lenguaje muy sencillo utilizado para definir interfaces entre componentes de aplicacin. Es importante destacar que IDL slo puede definir interfaces, no implementaciones. IDL, al especificar las interfaces entre objetos CORBA, es el instrumento que asegura la independencia del lenguaje de programacin utilizado.

Para ello, la especificacin IDL ha de asegurar que los datos son correctamente intercambiados entre dos lenguajes distintos. Por ejemplo, el tipolonges un entero con signo de 32 bits, que se puede hacer corresponder con unlongde C++ (dependiendo de la plataforma) o a unintde Java. Es responsabilidad de la especificacin 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 travs de una correspondencia. El OMG ha definido bastantes correspondencias con lenguajes de programacin populares, como: C, C++, COBOL, Java, Smalltalk y Ada. Las correspondencias para otros lenguajes tambin existen, pero o no son estndar o estn en proceso de estandarizacin. En la Tabla 1 se muestra la correspondencia entre los tipos IDL y los tipos C++.

Describiendo las interfaces IDL, un ORB genera automticamente cdigo en el lenguaje seleccionado para realizar la integracin de las aplicaciones distribuidas. Evidentemente, puesto que slo describe interfaces, todas las tareas complejas relacionadas con los lenguajes de programacin, como control de flujo, gestin de memoria, composicin funcional, no aparecen en IDL.

Evidentemente, la independencia del lenguaje de programacin es una caracterstica muy importante de la arquitectura CORBA. CORBA da a los programadores de la aplicacin la libertad para elegir el lenguaje que mejor se adapta a las necesidades de su aplicacin o bien utilizar varios lenguajes para varios componentes de la aplicacin.

Por ejemplo, el cliente de una aplicacin podra estar implementado en Java, lo que asegura que los clientes pueden ejecutarse virtualmente en cualquier mquina. Los componentes servidores de dicha aplicacin podran implementarse en C++, para conseguir una elevada eficiencia. CORBA hace posible la comunicacin entre estos componentes de diversa naturaleza.

IDLC++

ShortCORBA::Short

LongCORBA::Long

Unsigned shortCORBA::UShort

Unsigned longCORBA::ULong

FloatCORBA::Float

DoubleCORBA::Double

CharCORBA::Char

BooleanCORBA::Boolean

OctectCORBA::Octect

AnyCORBA::Any

Tabla: Correspondencia para los tipos de datos bsicos.

7.1 El registro de interfaz

Todas las aplicaciones basadas en CORBA necesitan acceder al tipo de sistema de IDL cuando se estn ejecutando. Esto es necesario porque la aplicacin necesita conocer los tipos de valores a ser pasados como argumentos de la peticin. Asimismo, la aplicacin ha de conocer los tipos de interfaces soportados por los objetos que estn utilizando.Ciertas aplicaciones requieren slo un conocimiento esttico del tipo de sistema IDL. Tpicamente, la especificacin IDL es compilada o traducida a cdigo para el lenguaje de programacin de la aplicacin siguiendo las reglas de traduccin 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 aplicacin, la aplicacin ha de volver a construirse.Pero hay ciertas aplicaciones, sin embargo, para las cuales es imposible un conocimiento esttico del tipo de sistema IDL. Para estas aplicaciones CORBA proporciona otro mtodo de definir interfaces sustituyendo a IDL, el registro de interfaz. Las interfaces pueden ser aadidas a un servicio de registro de interfaz, el cual define las operaciones para la recuperacin de la informacin del almacn en tiempo de ejecucin. Utilizando el registro de interfaz, un cliente podra ser capaz de ubicar un objeto desconocido en tiempo de compilacin, preguntar acerca de su interfaz, y despus construir una peticin a ser enviado a travs del ORB.7.2 Los tipos estructurados de IDL

8. CARACTERSTICAS

Permite invocar mtodos de objetivos remotos sin que importe el lenguaje en el que estn escritos el llamador y el llamado, ni las plataformas (sistema operativo y hardware) y redes de comunicacin intermedias. Incluye un buen nmero de servicios: nombres, trading (comercio), seguridad, transacciones, persistencia, notificaciones, etc.Esta estandarizado por el OMG (Object Management Group) El mayor consorcio de la industriade software. Solo emite especificaciones (no existe implementacin de referencia). Las especificaciones se desarrollan por consenso son pblicas y gratuitas. Existen muchos fabricantes que implementan lasespecificaciones ms importantes para las plataformas ms usuales. Tambin estandariza UML (UnifiedModeling Language).9. VENTAJASDECORBA

9.1 Heterogeneidad:Un sistema heterogneo consiste en conjuntos de elementos interconectados de hardware y software de diferente fabricante y que puede integrar aplicaciones de diferente tecnologa.9.2 Movilidad:La migracin 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 administracin o seguridad.9.3 Eficiencia Laredllevamenosmensajes.

Elservidorrealizamstrabajo

Seevitalalatencia/inestabilidaddelaredenlosprocesos.

9.4 Adaptacin al cliente Elclientepuedeextenderlafuncionalidaddelservidor

Fcilinstalacinparaelusuario

Noserequiereinstalacindeservidor.

Noseacuerdanlosprocedimientosentrelosclientesylosservidores

Instalacindinmicadelosprocedimientosdel-clienteenelservidor.

9.5 Tiempo de desempeo:

Adems, la ejecucin asncrona permite que los procesos controlen la gestin y terminacin de tarea y que el cliente pueda finalizar o continuar haciendo otras cosa ensu sistema, por otro lado se reduce el trfico en la red y la capacidad de cmputo del cliente

Figura2: Tiempos en la red utilizando corba

9.6 Robusto Reduccindeladependenciade la disponibilidaddela redy del cliente/servidor

Los procesosmigrados al sistema servidorno se ven afectados por los fallos del cliente o de la red

Los procesosseejecutanrealizandotareasespecficasen lugares diferentes

Automatizacindelastareasdistribuidas.10. DESVENTAJASDECORBA

El problema fundamental de los sistemas de integracin es el software. An no existe mucha experiencia en el diseo, implantacin y uso de software como CORBA. Precisamente, ste es un campo de investigacin actual. Las redes son indispensables para la comunicacin entre mquinas;sin embargo, pueden plantear problemas de saturacin, embotellamiento, interrupcin o prdidas de mensajes. El posible acceso a todo elsistema por parte de los usuarios plantea el inconveniente de la necesidad de un sistema de seguridad adecuado y estndar, aunque CORBA maneja la seguridad.

10.1 ComplejidadPermite la interoperabilidad de distintos lenguajes y sistemas operativos hace que sea un estndar bastante complejo, y su uso no sea tan transparente al programador como sera deseable

Hay usar un compilador que traduce una serie de tipos de datos estndares a los tipos del lenguaje en el que se vaya a programar (IDL).

Hay que ser conscientes a la hora de disear 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 programacin (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 diseo de un programa pensado para otro, hacen que la adaptacin sea fastidiosa. Cuestiones como la colocacin de libreras o las diferentes formas de implementar la gestin de la concurrencia, hacen difcil la portabilidad del cdigo y obliga al programador a reciclarse cuando quiere cambiar de ORB. Adems, donde el estndar no, concreta, las implementaciones pueden varias entre s, lo que da lugar a ,molestas incompatibilidades que complican la vida al usuario11. ASPECTOSDECORBALos aspectos a tener en cuenta esla forma de manejarlos siguientes puntos: Interfaces. Transparencia de Ubicacin. Invocacin a mtodos remotos. Activacin de los objetos.11.1 InterfacesCORBA soporta el trabajo en entornos heterogneos (permite interoperabilidad entre distintas mquinas y con objetos escritos en diferentes lenguajes) gracias a la clara separacin entre la interfaz y la implementacin. Para lograr esto necesita que los objetos definan su interfaz de forma comn, aunque la implementacin se realice en diferentes lenguajes. Para esto CORBA define un lenguaje de definicin de interfaces (IDL), a travs del cual cada objeto define su interfaz, la cual consiste del nombre del objeto, elnombreDe los servicios que brinda (junto con los parmetros 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 organizacin delos objetos. Este mecanismo se aplica solo a las interfaces, en la implementacin se debe hacer con los mecanismos del lenguaje usado (si lo provee).11.2 Transparencia de UbicacinLa idea es hacer referencia aotros objetos sin que se conozca la ubicacin real de este. Este manejo tiene varias ventajas como: facilita la programacin, permite la migracin de objetos, permite sacar, agregar o modificar objetos sin alterar el resto del sistema. En CORBA, existe un componente bsico llamado Object Request Broker(ORB), el cual se encarga de manejar la comunicacin entre el objeto cliente y el objeto servidor de manerade lograr la transparencia de Ubicacin buscada. El cliente conoce una referencia al servidor en vez de la ubicacin fsica de este. Esta referencia es un identificador unvoco en todo el sistema que se le otorga al ser creado el objeto. El cliente enva el pedido al ORB indicando la referencia al objeto servidor y el mtodo invocado, este obtiene la ubicacin fsica del servidor, y lereenva el pedido para que loresuelva.11.3 Invocacin a Mtodos Remotos (RMI)CORBA soporta dos variantes bsicas de RMI apartir de diferentes mdulos:11.3.1 La Invocacin EstticaEs similar a RPC. La interfaz de un objeto se enva junto con un pre compilador con el cual se genera un fragmento de cdigo del lado del cliente(stub) yotro dellado delservidos(skeleton). Unainvocacin esttica sigue los siguientes pasos:

1. El cliente enva el pedido a su stub correspondiente, y queda esperando el resultado en forma pasiva.

2. El stub transforma la invocacin (en ellenguaje dela implementacin del objeto cliente) a una forma comn para todos los objetos (en lenguaje IDL). Y la enva al ORB.3. El ORB determina laubicacin fsica delservidor y pasa el pedidoal objeto Adapter.

4. El objetoAdapter invoca alskeletondel servidor.

5. El Skeleton transforma la invocacin en IDL a una forma conocida por el lenguaje de implementacin del objeto servidor y realiza dicha invocacin.

6. Al terminar elservicio, elresultado esretornado alcliente. 11.3.2 Invocacin Dinmica

Es ms compleja. CORBA mantiene un depsito de interfaces, la cual almacena todas las interfaces del sistema. Usando este depsito, el cliente puede obtener detalles del objeto servidor, tales como el nombre y los parmetros de un servicio. Tambin se define una Interfaz de Invocacin Dinmica (DII) en cada objeto, el cual es una especie de stub despropsito general. Para realizar una Invocacin Dinmica el cliente utiliza el depsito de interfaces para obtener el nombre y los parmetros para la invocacin, y enva el pedido al DII, el cual acta de la misma forma que losstub de la invocacin esttica (transforma el pedido y lo enva al ORB).Este tipo de invocacin es ms flexible, pero ms complejo y lento. Usa un protocolo de dos fases no bloqueante. El cliente entrega el pedido al DII y contina con su trabajo, despus se llama a una segunda funcin para esperar explcitamente la finalizacin del servicio. Un modo especial deinvocacin 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 contina con su trabajo, sin asegurarse que el servicio haya sido realizado. De por s, la invocacin esttica es bloqueante y la dinmica es no bloqueante, pero esto puede modificarse.11.4 Activacin de ObjetosComo 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 mltiples objetos, cada uno con una referencia o identificador diferente. Los objetos son creados por procesos server, el cual es responsable del objetodurante toda su vida. CORBA mantiene un depsito 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 travs 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 despus enviar el requerimiento. Todo esto se maneja deforma 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 elproceso.11.5 Creacin de ObjetosNormalmente, los objetos son creados por servidores. CORBA provee unos objetos especiales llamados Factory, los cuales crean objetos en nombre delos clientes.

12. QUESOLUCIONACORBA

a) AplicacionesProcesos clientes y servidores que representan la lgica del negocio como objetos que pueden residir en distintas mquinas.

b) MiddlewareSoporte que permite la comunicacin entreaplicaciones.

c) Servicios de Red.Transporta la informacin entre computadores.

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

e) Sistema OperativoProvee servicios bsicos de hardware y scheduling13. SERVICIOS CORBAOtra parte importante del estndar CORBA es la definicin de un conjunto de servicios distribuidos para soportar la integracin e interoperabilidad de los objetos distribuidos. Como se muestra en el grfico de abajo, los servicios (conocidos como CORBA Services oCOS) se encuentran definidos en la parte superior del ORB. Esto es, estn definidos como objetos CORBA estndar con interfacesIDL, algunas veces llamados "Object Services. Existen varios servicios que proporciona CORBA. Los ms populares se describenbrevemente a continuacin:

14. TECNOLOGIACORBA14.1 CorbacomoPlataformadeDistribucineIntegracinCORBA ofrece la posibilidad de construir mecanismos de integracin de sistemas distribuidos por mediode dos especificaciones fundamentales:

15. Interface Definition Language (IDL)

General Inter-ORB Protocol (GIOP) El lenguaje de especificacin de interfaces (IDL) permite definir de una forma neutral los servicios que un servidor CORBA ofrece. A partir de la especificacin IDL, los compiladores generan cdigo en el lenguaje de programacin 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 cdigo 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 qumico de Repsol en Tarragona, a datos de la planta almacenados en la base de datosde proceso.

El protocolo de interoperabilidad es el que permite que los servicios sean pedidos entra plataformas heterogneas. Solo es necesario disponer del mismo protocolo en ambas plataformas para poder ofrecer la conectividad cliente-servidor necesaria. La implementacin ms comn del protocolo general GIOPes la denominada Internet Inter-ORB Protocol (IIOP). sta es una implementacin de GIOP sobre los protocolos bsicos de Internet(TCP/IP).Aunque un servidor CORBA puede ser una aplicacin muy compleja, la funcionalidad bsica se reduce a ser capaza de hablar el protocolo de interoperabilidad. Existen implementaciones de librera 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.CorbaparaSistemasdeControlLa especificacin 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 aplicacin son:16. Minimum CORBA Specification. Este es un perfil de la especificacin CORBA bsica para su uso en sistemas de bajos recursos.

Bsicamente, esta especificacin elimina las partes de la especificacin CORBA que tienen poca utilidad en sistemas que estn perfectamente especificadosen la etapadediseo. Todas las partesrelativas ala invocacin dinmica de servicios y los almacenes de informacin en caliente se eliminan (para ser ms precisos, no se requieren de implementaciones que reclamen ajustarse a la especificacin de Mnimum CORBA).17. Real-Time CORBA Specification. Esta especificacin aade caracterstica nuevas a la especificacin CORBA estndar para aumentar el control de los recursos con el fin de mejorar la predecibilidad extremo-a-extremo

. Esta especificacin reutiliza conceptos de otras especificaciones (por ejemplo el marco de calidad deservicio de la especificacin de Messaging o el concepto de tiempo de la especificacin 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 especificacin define los servicios de la infraestructura CORBA bsica que una aplicacin puede necesitar para conseguir dicha tolerancia a fallos. La especificacin 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 inters 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 Real-Time 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 gestin de aplicaciones complejas basada en objetos CORBA. La especificacin de SmartTransducers introduce mecanismos para la gestin de sensores y actuadores muy empotrados y tambin clusters de los mismos.

CONCLUSIONESCORBA proporciona una infraestructura y un modelo comn desde donde los requisitos expresados en diferentes lenguajes (las diferentes metodologas 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 tecnolgico suficientemente maduro como para construir aplicaciones robustas, eficientes y competitivas, a la vez que integrables con otros sistemas que cumplan estos estndares.

Los sistemas que son desarrollados con tecnologas antiguas pueden ser integrados con las nuevas a travs de CORBA. Esto es, construyendo interfaces para que intercambien informacin local o remota a travs de la red para resolver problemas en forma parcial incremental.

CORBA es una tecnologa adecuada para implementar sistemas distribuidos y en particular es muy adecuada para la implementacin de sistemas distribuidos de control porque simplifica el proceso de diseo, construccin, despliegue y mantenimiento cuando las aplicaciones superan un nivel mnimo de complejidad.

REFERENCIASBIBLIOGRFICAS 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 http://albertocc.tripod.com/pdf/CORBA-DCOM.pdf http://di002.edv.uniovi.es/~lourdes/publicaciones/bt99.pdf http://gredos.usal.es/jspui/handle/10366/21733 http://www.isa-spain.org/images/biblioteca_virtual/hrtc.pdf.Videos

http://www.youtube.com/watch?v=5Oc5QjtmVAo http://www.youtube.com/watch?v=2zTgX5DHN4s http://www.youtube.com/watch?v=p_g95gzg15k http://www.youtube.com/watch?v=EMmLrUDXW_o http://www.youtube.com/watch?v=1zRqxiquCo4 EMBED StaticMetafile

EMBED StaticMetafile

_1431181666.unknown

_1431181667.unknown

_1431181664.unknown

_1431181665.unknown

_1431181662.unknown

introducciÓn corba

Documents