CORBA

CURSO

:

INGENIERA DE SOFTWARE II

DOCENTE

:

ING. JUIPA CAMPO NOEL

INTEGRANTES

:

BERMDEZ YANAY VLADIMIR ROSALES SILVA ORFILA

SEMESTRE

:

2010 - II

TINGO MARIA PER 2010

DEDICATORIA

A Dios, por darnos la vida y la oportunidad de poder desarrollarnos como profesionales.

A nuestras familias por su apoyo incondicional en los momentos buenos y malos en el transcurrir de nuestros estudios.

A nuestros amigos que siempre estn a nuestro en los buenos y malos momentos.

TABLA DE CONTENIDODEDICATORIA ............................................................................................................... 2 TABLA DE CONTENIDO .............................................................................................. 3 TABLA DE ILUSTRACIONES ..................................................................................... 4 I. II. INTRODUCCION ................................................................................................... 5 ANTECEDENTES .................................................................................................. 6 2.1. Servicios Middleware ...................................................................................... 7 2.2. CORBA y el desarrollo basado en componentes ...................................... 9 III. CORBA ............................................................................................................... 12 3.1. Caractersticas ............................................................................................... 14 3.2. Aspectos de Corba ....................................................................................... 14 3.2.1. Interfaces................................................................................................. 14 3.2.2. Transparencia de Ubicacin ................................................................ 15 3.2.3. Invocacin a Mtodos Remotos (RMI) ............................................... 15 3.2.4. Activacin de Objetos ........................................................................... 16 3.2.5. Creacin de Objetos .............................................................................. 17 3.3. Ventajas de Corba ....................................................................................... 17 3.4. Desventajas de Corba .................................................................................. 18 3.5. Que Soluciona Corba ................................................................................... 18 3.6. Arquitectura de Corba .................................................................................. 18 3.6.1. ORB (Object request brker) ............................................................... 19 3.6.2. IDL (Interface Definition Language) .................................................... 24 3.6.3. El adaptador de objetos (OA) .............................................................. 25 3.6.4. STUB ....................................................................................................... 26 3.6.5. Esqueleto ................................................................................................ 29 3.7. Corba en Control de Procesos .................................................................... 29 IV. TECNOLOGIA CORBA.................................................................................... 31 4.1. Corba como Plataforma de Distribucin e Integracin ........................... 31 4.2. Corba para Sistemas de Control ................................................................ 31 V. VI. CONCLUSIONES ................................................................................................ 33 REFERENCIAS BIBLIOGRFICAS .............................................................. 34

TABLA DE ILUSTRACIONESFigura 1: CORBA ........................................................................................................... 12 Figura 2: Esquema Modular de CORBA ........................................................................ 13 Figura 3: ORB ................................................................................................................ 19 Figura 4: Un pedido siendo enviado a travs del ORB .................................................. 21 Figura 5: La estructura del ORB .................................................................................... 22 Figura 6: Cliente realizando un request de forma dinmica o a travs de un Stub IDL . 23 Figura 7: Object Implementation recibiendo un request ................................................ 23 Figura 8: IDL .................................................................................................................. 24 Figura 9: Ubicacin del Stub .......................................................................................... 26 Figura 10: Estructura del Cliente. ................................................................................... 27 Figura 11: Estructura del Object Adapter ....................................................................... 29

I.

INTRODUCCION

Los escritorios modernos estn compuestos por multitud de pequeos programas que deben comunicarse los unos con los otros para que el usuario tenga la sensacin de estar trabajando en un entorno coherente, un entorno en el que todo encaja y trabaja de forma coordinada. Tmese como ejemplo el Panel, el Panel, este es un contenedor en el cual se pueden colocar diferentes "applets", estos "applets" son programas autnomos que deben comunicarse con el Panel para que el usuario tenga la sensacin de que el Panel y los "applets" estn perfectamente integrados. Otros ejemplos mucho ms complejos son tambin posibles, por ejemplo, el caso en el cual un programa toma datos de un sensor y los introduce de forma automtica en Gnumeric (la hoja de clculo de GNOME Office) sin necesidad de que el usuario intervenga. Para poder conseguir esta integracin y la posibilidad de controlar las aplicaciones de esta forma es necesario un sistema o plataforma que permita a los diferentes programas comunicarse entre ellos. La solucin que la comunidad GNOME ha adoptado para este importante problema fue CORBA donde 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 su programa. En el siguiente trabajo se explicara (CORBA) sus caractersticas, sus ventajas, sus limitaciones, entre otros.

II.

ANTECEDENTES

En las primeras pocas de la computacin las computadoras operaban independientemente una de otra sin tener comunicacin entre ellas. Las aplicaciones de software eran comnmente desarrolladas para un propsito especfico. Compartir los datos entre sistemas era mnimo y se hacas de una manera muy fcil, se transportaban los medios de almacenamiento (tarjetas, cintas, discos, etc.) de un lado a otro. El prximo paso fue conectar las computadoras a travs de una red usando protocolos propietarios, luego los protocolos fueron estandarizados. Luego llego la era de los sistemas abiertos y la integracin de sistemas por los cuales un cliente poda elegir varios componentes de hardware de diferentes vendedores e integrarlos para crear una configuracin necesaria con costos razonables. As sigui el paso de los aos. Nuevas tcnicas de desarrollo de software se fueron sucediendo una tras otra, desde la programacin estructurada y modular hasta la programacin orientada a objetos, siempre buscando reducir costos y aumentar la capacidad de reso. Si bien la programacin orientada a objetos foment el reso y permiti reducir costos, no se ha logrado an el objetivo ltimo: comprar componentes de varios proveedores e integrarlos para formar aplicaciones que a su vez se integren para formar sistemas completos. Para lograr la integracin total de componentes realizados por terceras partes es necesario llegar a un acuerdo comn en el que se establezcan los mecanismos necesarios para que esa integracin se haga efectiva. Ser necesario especificar de manera independiente al lenguaje de programacin en el que se desarroll el componente cules son sus puntos de acceso (funciones), luego ser necesario establecer los mecanismos de comunicacin entre componentes, que podran estar ejecutndose en una mquina remota. En este sentido, y buscando satisfacer esa necesidad de mecanismos estndar e interfaces abiertas, son tres los esfuerzos que ms han sobresalido. Por un lado, Microsoft ha introducido en el mercado sus tecnologas COM, DCOM y COM+. Otro participante es Sun Microsystems, que ha presentado Java Beans. El tercero es el Object Management Group, un consorcio integrado por varias industrias importantes, que ha desarrollado CORBA (Common Request Broker Architecture), motivo de estudio de este trabajo. CORBA ofrece servicios de interoperabilidad e interconexin de objetos. Los servicios de interoperabilidad e interconexin son normalmente conocidos como servicios middleware.

2.1.

Servicios Middleware

Para resolver los problemas inherentes a sistemas heterogneos y distribuidos, que dificultan la implementacin de verdaderas aplicaciones empresariales, los proveedores de software estn ofreciendo interfaces de programacin y protocolos estndares. 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 propsito 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 APIs de un sistema operativo. Como ejemplos de plataformas se pueden citar: Intel x86 y Win-32, SunSPARCStation y Solaris, IBM RS/6000 y AIX, entre otros. Un servicio middleware est definido por las APIs 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 especficas por cuatro importantes propiedades: Son independientes de las aplicaciones y de las industrias para las que stas se desarrollan. Se pueden ejecutar en mltiples plataformas. Se encuentran distribuidos. Soportan interfaces y protocolos estndar.

Debido al importante rol que juegan una interfaz estndar en la portabilidad de aplicaciones y un protocolo estndar en la interoperabilidad entre aplicaciones, varios esfuerzos se han realizado para establecer un estndar que pueda ser reconocido por los mayores participantes en la industria del software. Algunos de ellos han alcanzado instituciones como ANSI e ISO; otros han sido propuestos por consorcios de industrias como ser la Open Software Foundation y el Object Management Group y otros han sido impulsados por industrias con una gran cuota de mercado. Este ltimo es el caso de Microsoft con su Windows Open Services Architecture. CORBA es el estndar propuesto por el OMG. EL OMG fue fundado en 1989 y es el ms grande consorcio de industrias de la actualidad, con ms de 700 compaas que son miembros del grupo. Opera como una organizacin no comercial sin fines de lucro, cuyo objetivo es lograr establecer todos los

estndares 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: cmo lograr que sistemas distribuidos orientados a objetos implementados en diferentes lenguajes y ejecutndose en diferentes plataformas interacten entre ellos. Ms all de los problemas planteados por la computacin distribuida, problemas ms simples como la falta de comunicacin entre dos sistemas generados por compiladores de C++ distintos que corren en la misma plataforma frenaron los esfuerzos de integracin no bien comenzados. Para opacar an ms el escenario, distintos lenguajes de programacin ofrecen modelos de objetos distintos. Los primeros aos de la OMG estuvieron dedicados a resolver los principales problemas de cableado. Como resultado se obtuvo la primera versin del Common Object Request Broker, publicado en 1991. Hoy en da, el ltimo estndar aprobado de CORBA est por la versin 2.3, y la versin 3.0 est a punto de ser lanzada. Desde sus principios, el objetivo de CORBA fue permitir la interconexin 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 estndares 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 invocacin, el ORB (object request broker) y un conjunto de adaptadores de objetos (objects adapters). CORBA va ms all de simples servicios middleware, provee una infraestructura (framework) para construir aplicaciones orientadas a objetos. Las interfaces definen los servicios que prestan los objetos, el ORB se encarga de la localizacin e invocacin de los mtodos sobre los objetos y el object adapter es quien liga la implementacin del objeto con el ORB. Para que las interfaces de invocacin 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 comn. 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 programacin y el lenguaje comn. La primera condicin permite generalizar los mecanismos de pasaje de parmetros (marshaling y unmarshaling). La

segunda permite relacionar llamadas de un lenguaje en particular con el lenguaje de especificacin comn. Este lenguaje comn fue una parte esencial de CORBA desde sus orgenes y es conocido como el OMG IDL: Interface Definition Language. Existen mapeos del OMG IDL a C, C++, Java y Smalltalk,

2.2.

CORBA y el desarrollo basado en componentes

Como se mencion anteriormente, el desarrollo basado en componentes que se puedan comprar y poner en marcha sin mayores dificultades (Plug & Play) es una meta a alcanzar que facilitara el reso de software. En esta seccin se hace una pequea introduccin al desarrollo basado en componentes y el rol que le compete a CORBA en este mbito. Muy frecuentemente el trmino componente se utiliza sin precisar su significado, dando por sentado que todos lo conocen. Pero no siempre es as, y al utilizar el trmino componente puede suceder que no siempre se est hablando de lo mismo. Es deseable entonces comenzar con una definicin de componente. Un componente ha sido definido en la European Conference on Object Oriented Programming (ECOOP) de 1996 como una una unidad de composicin con interfaces contractuales especificadas y dependencias de contexto explcitas. Un componente de software puede ser desarrollado independientemente y utilizado por terceras partes para integrarlo mediante composicin a sus sistemas. Los componentes son para crear software utilizando composicin, por eso es esencial que sean independientes y que se presenten en formato binario, permitiendo as distintos vendedores e integracin robusta. Para que un componente pueda ser integrado por terceras partes en sus sistemas, ste deber ser suficientemente autocontenido y debe proveer una especificacin de lo que requiere y provee. En otras palabras, los componentes deben encapsular su implementacin e interactuar con otros componentes a travs 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 dinmica que usualmente cobra vida a travs 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 caractersticas de encapsulacin y polimorfismo, facilitan la construccin e integracin de componentes.

Y al hablar de objetos vale la pena distinguir aqu los objetos de las clases. Una clase es una definicin de propiedades y funcionalidades a ser provistas por los objetos. A partir de una clase es posible instanciar objetos. Los componentes pueden contener una o ms clases y sern los clientes de los componentes quienes soliciten la creacin de las instancias de estas clases. Como escenario de ejemplo para mostrar cmo sera la construccin de software basado en componentes, se podra pensar en una librera. Una librera necesita un sistema que le permita llevar el stock de sus libros, contabilizar sus ventas y gestionar los pedidos a sus proveedores. Quien estuviera a cargo de este proyecto de desarrollo podra adquirir un componente de facturacin que provee las siguientes clases (entre otras):

Producto ID Nombre Precio Cantidad En Stock

Venta Nro. Venta Productos Subtotal IVA Total

El fabricante del componente de Facturacin no sabe de antemano en que ambientes se va a utilizar su componente. Por lo tanto, decide no ofrecer una implementacin de la clase producto. Slo provee su interfaz para que quin utilice el componente sea quien finalmente la implemente de acuerdo a sus necesidades. S en cambio ofrece la implementacin completa de la clase venta. La especificacin de la clase venta podra indicar que: Nro. de Venta es un nmero entero que se asigna automticamente al crearse una nueva instancia de un objeto Venta. Productos es un conjunto de productos (existir en otro lado la definicin de conjunto con sus operaciones de insercin y eliminacin). Al agregar un producto a la venta se debe especificar su cantidad. Esta cantidad ser deducida de la cantidad en stock de ese producto. Etc.

El programador del sistema para la librera decide crear una clase Libro que implementa la interfaz de producto (un objeto Libro se comportar como si fuera un objeto producto cuando sea necesario), y as podr crear ventas de libros.

Si bien este es un ejemplo simple, es un escenario al que se deseara poder llegar con el desarrollo basado en componentes. Hasta aqu todo suena muy lindo. Pero tomando el lugar del programador que debe integrar el componente a su aplicacin, surgen algunas incgnitas que debera poder resolver. El fabricante del componente solamente ha entregado un archivo ejecutable que se debe iniciar en la mquina en la que se ejecuta la aplicacin y la interfaz definida en un lenguaje de definicin de interfaces (IDL) estndar. El programador desea ahora: Mapear la interfaz: Cmo hace el programador para mapear las clases que el componente provee al lenguaje en que realizar su implementacin final? Seguramente el lenguaje de programacin elegido provee mecanismos para definir clases, pero es necesario que la definicin que se haga de la clase en ese lenguaje corresponda a la definicin que dio el fabricante del componente. Crear objetos: Cmo 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 Cmo se logra acceder a sus propiedades o mtodos? Transparencia: El componente sera de poca utilidad si su utilizacin no fuera transparente. Si para cada llamada al componente el programador debiera utilizar un servicio del sistema operativo de llamada entre procesos (IPC), o peor aun si el componente es remoto, un servicio de llamada remota a procedimientos (RPC), est claro que dejara el componente de lado pues es ms trabajo utilizarlo que hacer un programa desde cero.

Estas son slo algunas de las cuestiones que el programador debera poder 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 utilizacin sean uniformes para no tener que resolverlas nuevamente. Los servicios middleware que provee CORBA buscan resuelven estos problemas.

III.

CORBA

CORBA es una arquitectura de objetos distribuidos que permite a los objetos interactuar a travs de redes de comunicaciones utilizando plataformas heterogneas y lenguajes diferentes. Es decir, se pueden crear objetos en lenguajes tan diferentes como Java y C++, en plataformas distintas como GNU/Linux, Windows 95 o MacOS y dichos objetos pueden interactuar entre ellos sin ningn tipo de problema.

Figura 1: CORBA

CORBA ha cobrado una gran importancia despus de la publicacin de CORBA 2.0 en 1994 cuando defini como interactuar entre diferentes implementaciones de la arquitectura a travs del protocolo IIOP. Con IIOP una implementacin de CORBA como JacORB, totalmente en Java, no tiene ningn problema en interactuar con los objetos de una implementacin comercial como la de Visigenic. De esta forma se crea un escenario de juego totalmente abierto en el que el principal factor para el xito es la calidad de la implementacin, es decir, que el factor preponderante es la calidad tcnica de los productos. CORBA define un modelo de objetos basado en la definicin de las interfaces de los objetos mediante el lenguaje IDL. CORBA ha logrado parte de su xito a la clara separacin entre la interfaz de los objetos y la implementacin de los mismos. Las interfaces se definen utilizando el lenguaje IDL, cuya principal caracterstica es su alto nivel de abstraccin, lo que le separa de cualquier entorno de desarrollo especfico. Para la implementacin de los objetos se puede utilizar cualquier lenguaje de programacin que proporcione enlaces con el lenguaje IDL. Para que un lenguaje de programacin se pueda utilizar desde CORBA, debe tener definida la forma de enlazarse con IDL. De esta forma, y a partir de una especificacin de las interfaces en IDL, se generan unos cabos (proxies) en el lenguaje elegido que permiten el acceso a la implementacin de los objetos desde la arquitectura CORBA.

Es de destacar que todas las aplicaciones software heredadas pueden ser incluidas en la arquitectura CORBA, siempre y cuando se puedan definir unas interfaces en IDL para acceder a ellas, y el lenguaje de programacin en el que estn desarrolladas tenga compiladores, que permitan generar cabos a partir de las especificaciones IDL de los interfaces. Es fundamental este soporte que da para el cdigo heredado, ya que la industria software no puede desechar todas las aplicaciones que en la actualidad existen. Con el impulso que ha significado Internet para los sistemas distribuidos, CORBA ha pasado a ocupar un papel muy relevante dentro de la industria software y hay grandes intereses en su implantacin en Internet. CORBA ha llegado a ser incluido dentro de los clientes de Netscape y se pretende que llegue a sustituir al protocolo HTTP (con IIOP) supliendo la carencia de HTTP de no mantener el estado de la comunicacin.

Figura 2: Esquema Modular de CORBA

Para construir componentes que utilicen el entorno CORBA se deben seguir los siguientes pasos: 1. Definir la interfaz remota. Se define, en primer lugar, la interfaz del objeto remoto en IDL. Dicha interfaz permitir generar, de manera automtica, el cdigo fuente del stub y el skeleton as como todo el cdigo necesario para comunicarse con el ORB. Si slo se implementa el cliente porque el servidor ya existe, se tendra que proporcionar el fichero IDL correspondiente a la interfaz que expone el servidor. 2. Compilar la interfaz remota. El compilador genera todo el cdigo fuente mencionado en el paso anterior. 3. Implementar el servidor. A partir de los esqueletos que genera el compilador IDL es sencillo implementar el servidor. Adems de los mtodos que implementan la interfaz remota, el cdigo del servidor crea un mecanismo para arrancar el ORB y esperar por la invocacin de un cliente. 4. Implementar el cliente. De una manera similar al servidor, el cliente hace uso de los stubs generados en el paso 2. El cliente se basa en

el stub para arrancar su ORB, encontrar el servidor utilizando el servicio de nombrado, obtener una referencia al objeto remoto e invocar sus mtodos. 5. Arrancar los programas. Una vez est todo implementado, se arranca el servicio de nombrado, el servidor y finalmente, el cliente.

3.1.

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) o El mayor consorcio de la industria de software. o Solo emite especificaciones (no existe implementacin de referencia). o Las especificaciones se desarrollan por consenso son pblicas y gratuitas. o Existen muchos fabricantes que implementan las especificaciones ms importantes para las plataformas ms usuales. o Tambin estandariza UML (Unified Modeling Language).

3.2.

Aspectos de Corba

Los aspectos a tener en cuenta es la forma de manejar los siguientes puntos:

Interfaces. Transparencia de Ubicacin. Invocacin a mtodos remotos. Activacin de los objetos. Creacin de objetos.

3.2.1. Interfaces CORBA 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, el nombre

de 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 de los objetos. Este mecanismo se aplica solo a las interfaces, en la implementacin se debe hacer con los mecanismos del lenguaje usado (si lo provee). 3.2.2. Transparencia de Ubicacin La idea es hacer referencia a otros 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 manera de 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 le reenva el pedido para que lo resuelva. 3.2.3. Invocacin a Mtodos Remotos (RMI) CORBA soporta dos variantes bsicas de RMI a partir de diferentes mdulos:

Invocacin Esttica. Invocacin Dinmica.

La Invocacin Esttica es similar a RPC. La interfaz de un objeto se enva junto con un precompilador con el cual se genera un fragmento de cdigo del lado del cliente (stub) y otro del lado del servidos (skeleton). Una invocacin 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 el lenguaje de la implementacin del objeto cliente) a una forma comn para todos los objetos (en lenguaje IDL). Y la enva al ORB.

3. El ORB determina la ubicacin fsica del servidor y pasa el pedido al objeto Adapter. 4. El objeto Adapter invoca al skeleton del 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 el servicio, el resultado es retornado al cliente. La 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 de propsito 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 los stub 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 de invocacin 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. 3.2.4. Activacin de Objetos Como no todos los procesos necesitan correr continuamente, los procesos son activados y desactivados por necesidad, y esto es manejado por el objeto Adapter. 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 objeto durante 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 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. 3.2.5. Creacin 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.

3.3.

Ventajas de CorbaHeterogeneidad: Un sistema heterogneo consiste en conjuntos de elementos interconectados de hardware y software de diferente fabricante y que puede integrar aplicaciones de diferente tecnologa. 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. Eficiencia - La red lleva menos mensajes. - El servidor realiza ms trabajo. - Se evita la latencia/inestabilidad de la red en los procesos. Adaptacin al cliente - El cliente puede extender la funcionalidad del servidor. - Fcil instalacin para el usuario. - No se requiere instalacin de servidor. - No se acuerdan los procedimientos entre los - clientes y los servidores. - Instalacin dinmica de los procedimientos del - cliente en el servidor. 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 en su sistema, por otro lado se reduce el trfico en la red y la capacidad de cmputo del cliente.

Robusto - Reduccin 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 especficas en lugares diferentes. - Automatizacin de las tareas distribuidas.

3.4.

Desventajas de Corba

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 el sistema por parte de los usuarios plantea el inconveniente de la necesidad de un sistema de seguridad adecuado y estndar, aunque CORBA maneja la seguridad.

3.5.

Que Soluciona Corba- Aplicaciones. Procesos clientes y servidores que representan la lgica del negocio como objetos que pueden residir en distintas mquinas. - Middleware. Soporte que comunicacin entre aplicaciones. permite la

Aplicaciones

Middleware

Servicios de Red

Servicios Locales

- Servicios de Red. Transporta la informacin entre computadores. - Servicios Locales. Ejemplo, bases de datos y administradores de transacciones.

Sistema Operativo

- Sistema Operativo. Provee servicios bsicos de hardware y scheduling.

3.6.

Arquitectura de Corba

Para que el cliente pueda realizar una invocacin sobre un objeto, se debe tener una referencia del objeto (IOR) y conocer el tipo de objeto y la operacin

que desea invocar. El cliente puede iniciar la peticin a travs de una conexin IDL o bien construyendo la invocacin de forma dinmica utilizando el DII. El ORB se encarga de encontrar el cdigo de la implementacin apropiada, transmitir los parmetros y transferir el control a la Implementacin de la Interfaz a travs del esqueleto IDL, o a travs del esqueleto dinmico (DII) como se explica ms adelante. Las invocaciones pueden producir excepciones de diversa ndole. Por ejemplo la referencia al objeto puede ya no ser vlida, o la interfaz IDL del objeto ha podido cambiar. El ORB se encargar de informarnos de todas estas posibles excepciones y nuestro cdigo deber estar preparado para gestionar estas excepciones. A continuacin se describe cada una de las caractersticas fundamentales de la Arquitectura CORBA: 3.6.1. ORB (Object request brker) Componente que permite que clientes y objetos puedan comunicarse en un ambiente distribuido y que contempla cada una de las interfaces que el ORB manipula.

Figura 3: ORB

El bus de objetos es el intermediario entre clientes y servidores que transmite las peticiones cliente-servidor y las respuestas servidor-cliente. Se necesita un ORB en cada mquina. El ORB soporta cuatro tipos de interfaces de objetos:

-

Object Services: Son interfaces para servicios generales. Son usadas en cualquier programa basado en objetos distribuidos. Common Facilities: Son interfaces orientadas al usuario final y que se programan por la aplicacin especfica. Domain Interfaces: Son interfaces de dominio especfico para las aplicaciones. Application Interfaces: Este tipo de interfaz acepta interfaces que no sean estandarizadas y se utilizan en aplicaciones especficas.

Existe una gran variedad de implementaciones de ORB, de las cuales las ms importantes son: ORB residente en el Cliente e Implementacin: El ORB puede ser implementado en rutinas residentes en el cliente y en la implementacin del objeto. El stub en el cliente usa un mecanismo IPC (Interprocess call) o directamente accede al servicio para establecer la comunicacin con la Implementacin. ORB Server: Para centralizar el management del ORB, todos los clientes e implementaciones de objetos pueden comunicarse con uno o ms servers cuyo trabajo de los mismos es rutear los Request desde los clientes hacia las implementaciones de los objetos. El ORB podra ser un programa que utiliza IPC para las comunicaciones. ORB basado en Sistemas operativos: Para reforzar la seguridad, robustez y performance el ORB podra ser provisto como un servicio bsico del sistema operativo. ORB basado en Libreras: Para objetos que su Implementacin puede ser compartida, la Implementacin podra residir en una librera. Esto hace que sea posible para el cliente obtener acceso de los datos del objeto y que la Implementacin confe que el cliente no dae los mismos.

-

-

-

Proceso del ORB: Un cliente accede a los servicios de un objeto servidor a travs de una referencia, que identifica a la instancia del objeto (local o remota) unvocamente. El cliente slo conoce del objeto servidor su interfaz (funciones y parmetros). El puente entre el cliente y el objeto servidor es el ORB. Como se puede observar en la Figura 4 el cliente client est realizando un pedido Request a una Implementacin de un objeto. El cliente es una entidad que desea llevar a cabo una operacin sobre un objeto y el Object Implementation es el cdigo y los datos que implementa a dicho objeto.

Figura 4: Un pedido siendo enviado a travs del ORB

El pedido Request no pasa directamente desde el cliente Client a la Implementacin del Objeto Object Implementation, estos son siempre manejados por el ORB. El ORB es el responsable de todos los mecanismos requeridos para encontrar al Object Implementation, preparar al mismo para recibir el pedido y comunicar los datos que son requeridos. La interfaz que el cliente ve es completamente independiente de la ubicacin del objeto, del lenguaje de programacin que fue utilizado y cualquier otro aspecto que est relacionado con la interfaz del objeto (ej. plataforma en la cual corre la Implementacin del objeto). La Figura 5 muestra la estructura de un ORB donde los cuadros que estn pintados de gris y negro son las interfaces, las flechas indican cuando el ORB es invocado por las interfaces o cuando realiza llamadas a travs de las mismas. En CORBA la interfaz de los Objetos est definida en un lenguaje denominado OMG IDL (Interface Definition Language). La definicin de la interfaz especifica las operaciones que el objeto est preparado para realizar, los parmetros de entrada y de salida y cualquier excepcin que podra ser generada a lo largo de la utilizacin del mismo. Esta interfaz constituye un contrato con los clientes de los objetos quienes usan el mismo lenguaje para definir y realizar invocaciones a las implementaciones de los objetos. Este diseo provee gran flexibilidad y muchas ventajas como la encapsulacin y tambin permite a los clientes acceder a las implementaciones de los objetos independientemente, por ejemplo, del lenguaje de programacin en que estos fueron desarrollados.

Figura 5: La estructura del ORB

Para realizar un Request el Cliente puede usar dos formas de comunicarse con el ORB: a travs de un stub OMG IDL o a travs de Dynamic Invocation Interfaz (DII). El cliente tambin puede interactuar directamente con el ORB para algunas funciones. El stub representa el mapeo entre el lenguaje de Implementacin del cliente y el ORB. Esto hace que los clientes puedan ser escritos en cualquier lenguaje tal que el ORB reconozca este mapeo. Luego el ORB transfiere el pedido Request al Object Implementation a travs del Object Adapter y la forma de realizar esta comunicacin puede estar dada de dos maneras diferentes (igual que del lado del cliente) una de ellas es por intermedio de Statics IDL Skeleton (son equivalentes a los Stub del cliente) que debe haber uno por cada objeto que se encuentre en unido al ORB y la otra forma es mediante Dynamic Skeleton Interfaz (DSI, que es el equivalente al Dynamic Invocation Interfaz del lado del cliente) de esta forma el ORB usa esta interfaz como proxy para los objetos remotos que no se encuentran conectados a l. El Object Adapter necesita tener acceso a la informacin que contiene la ubicacin del objeto y el entorno de operacin. La base de datos que contiene dicha informacin es llamada Implementation Repository y es un componente standard de la Arquitectura CORBA. Tambin posee informacin pertinente a la Implementacin de servers tales como debugging, versin e informacin administrativa. El cliente lleva a cabo su pedido Request teniendo acceso a la referencia del objeto Object Reference y tambin sabiendo que tipo de operacin va a ser llevada a cabo. El cliente inicializa el request realizando una llamada a las

rutinas del Stub IDL que son especificas para el objeto o sino construyendo el request dinmicamente va el Dynamic Invocation Interfaz.

Figura 6: Cliente realizando un request de forma dinmica o a travs de un Stub IDL

Una vez que el ORB Core recibe el Request, localiza la Implementacin apropiada, transmite los parmetros y transfiere el control al Object Implementation a travs de un IDL Skeleton o un Dynamic Skeleton. Una vez llevado a cabo el Request el Object Implementation puede obtener servicios del ORB a travs del Object Adapter. Por ltimo cuando el request est completo el control y los valores de salida son retornados al cliente.

Figura 7: Object Implementation recibiendo un request

3.6.2. IDL (Interface Definition Language) Para poder especificar los servicios que ofrecen los objetos que fomar parte de un sistema abierto y distribuido, se necesita contar con algn lenguaje preciso, bien definido, e independiente de cualquier posible representacin de los datos o estructuras que l define, as como la futura implementacin de los objetos que especifica. La norma ISO/IEC/ 14750 (ITUT X.920) define dicho lenguaje, al que se conoce como lenguaje de definicin de interfaces de ODP o ODP IDL por su acrnimo en ingls. IDL es el medio por el cual una implementacin de un objeto en particular dice a sus potenciales clientes que operaciones estn disponibles y como ellas podran ser invocadas. Desde la definicin del IDL es posible mapear objetos CORBA dentro de lenguajes de programacin particulares o sistemas de objetos. Su principal objetivo es describir la asignatura de los objetos que especifica, en trminos de las estructuras de datos que se manejan y el perfil de las operaciones que definen sus servicios. De esta forma se consigue la ocultacin necesaria para el desarrollo de aplicaciones abiertas. Tipos bsicos : long, short, ushort, ulong, float, double char, boolean, enum, string, octect, any Tipos compuestos: struct, union, array Tipos derivados: sequence Tipos de objeto: interface, referencia a objetos

Figura 8: IDL

Un tipo es una entidad con predicados asociados y definidos con valores en un objeto. Un valor satisface un tipo si el predicado es verdadero para la variable. Los tipos son usados para restringir los posibles valores, parmetros, o para identificar un posible resultado. La Interfaz IDL se compone del repositorio de interfaces y la interoperabilidad de la Interfaz de invocacin dinmica: El repositorio de interfaces (IR); es un servicio que ofrece objetos persistentes que representan la informacin IDL de las interfaces disponibles en CORBA, de una forma accesible en tiempo de ejecucin

(runtime). Esta informacin puede ser utilizada por el ORB para realizar peticiones. Y adems, el programador de aplicaciones puede utilizar esta informacin para acceder a objetos cuya interfaz no se conoce en tiempo de compilacin, o para determinar que operaciones son vlidas en un objeto. La interfaz de invocacin dinmica; El DII (Dynamic Invocation Interface) es una interfaz que nos permite la construccin dinmica de invocaciones para un determinado objeto. Ello garantiza que el cliente pueda especificar el objeto, la invocacin y los parmetros que se pasan al servidor. La invocacin es idntica a la que llega a travs de la interfaz esttica pero que ya dentro del cliente, logra una flexibilidad fundamental en arquitecturas complejas y dinmicas. Una invocacin dinmica se compone, de una referencia al objeto, una operacin y una lista de parmetros. Todos estos datos se obtienen del Repositorio de Interfaces (IR).

3.6.3. El adaptador de objetos (OA) El adaptador de objetos (OA) es el mdulo que permite a las implementaciones de los objetos acceder a servicios ofrecidos por el ORB, ste genera las referencias a los objetos. El adaptador de objetos exporta una interfaz pblica para su uso por la implementacin del objeto y una interfaz privada para ser usada por el esqueleto del objeto que depende de la implementacin del adaptador de objetos Las funciones que realiza este adaptador son: Generacin e interpretacin de las referencias a objetos. Invocacin de mtodos. Seguridad en las interacciones. Activacin y desactivacin de objetos e implementaciones. Traduccin de referencias a objetos con sus correspondientes implementaciones. Registro de las implementaciones. Debido a que las implementaciones de los objetos dependen del adaptador de objetos, se deben definir la menor cantidad de adaptadores de objetos.

3.6.4. STUB Es el intermediario entre el cliente y el ORB. El Stub recoge del cliente llamadas a mtodos y las transmite al ORB. Se requiere una clase de stub por cada clase remota. Adems, es un componente que acta como servidor, puede estar ejecutndose en cualquier mquina conectada a la red que recibe peticiones por parte de clientes que pueden ser locales o remotos. Indistintamente de ello, el cliente siempre tendr la ilusin de que la llamada se ejecuta localmente. En otras palabras el stub logra que el programador no se ocupe de las instrucciones de programacin remotas ya que son objetos que residen en el cliente y que representan objetos remotos instalados en un servidor. En l se identifica: Host, puerto e identificador del objeto.

Figura 9: Ubicacin del Stub

3.6.4.1.

Estructura del Cliente

En CORBA un objeto puede ser cliente y servidor a la vez. El rol de un cliente es simplemente pedir servicios a las implementaciones de los objetos invocando operaciones especficas. El cliente accede a las implementaciones de los objetos a travs de sus interfaces IDL, especificando la instancia del objeto destino por medio de su referencia al objeto (Object Reference).

Figura 10: Estructura del Cliente.

La interfaz entre el cliente y el Stub es definida dependiendo del lenguaje de programacin elegido para la Implementacin del cliente. Tambin se puede utilizar la interfaz de invocacin dinmica (DII) que le da al cliente la posibilidad que en cualquier momento invoque cualquier operacin en cualquier objeto que pueda ser alcanzado por la Red. Para poder hacer esto ltimo se realizan cuatro pasos: 1. Identificar el objeto que se desea invocar: Para esto los clientes consultarn un servicio de repositorio de objetos, en donde obtendr la localizacin del objeto que proporciona el servicio que se est buscando 2. Conseguir la interfaz del objeto: El repositorio de interfaces almacena nicamente la informacin relacionada con la sintaxis, de manera tal que los objetos deben usar la operacin get_interface para una referencia al objeto que retorna el componente superior de la interfaz, siendo posible obtener las operaciones de la interfaz, sus parmetros y sus tipos 3. Construir la invocacin: Se emplea el mtodo create_request pasndole una lista de argumentos. 4. Hacer la invocacin y esperar los resultados: se emplea el mtodo add_args que le da valor a cada uno de los argumentos de la solicitud. 3.6.4.2. Estructura del servidor

El servidor es el programa que contiene la implementacin del objeto. Para permitir que la implementacin de un objeto sea portable entre distintos ORBs, CORBA define un mediador entre el mundo de los objetos CORBA y el mundo de los lenguajes de programacin: el Object Adpater.

El Object Adapter es responsable de: Llevar un registro de las implementaciones Generara e interpretara las referencias a los objetos Realizar un mapeo de las referencias a los objetos a sus implementaciones correspondientes Activar y desactivar las implementaciones de los objetos Invocar mtodos por medio de un Skeleton o del DSI Coordinar la seguridad de la interaccin junto con el Security Object Service

Para llevar a cabo estas tareas se cuenta con los siguientes Object Adapters: Basic Object Adapter: Puede manejar ya sea un programa por mtodo, por objeto, o un programa compartido por varias instancias de un tipo de objeto. Proporciona una pequea capacidad almacenamiento por cada objeto, que puede ser empleada para hacer referencia al lugar en donde este almacena la informacin de manera persistente.

Para las configuraciones en las que los objetos residen en procesos distintos al ORB, el Basic Object Adapter proporciona: Generacin e interpretacin de las referencias a los objetos Activacin y desactivacin de las implementaciones de los objetos Activacin y desactivacin de los objetos individuales Invocacin de mtodos por medio de Skeletons Para el Basic Object Adapter un servidor es una unidad de ejecucin y el objeto es la implementacin de un mtodo o interfaz. El mismo soporta las siguientes politicas de activacin de objetos: Servidor compartido: Un servidor maneja varios objetos Servidor persistente: Se parece al anterior pero servidor que no es activado por el Basic Object Adapter, ni se desactiva (permanece activo todo el tiempo). Este servidor se registra ante el Basic Object Adapter mediante un procedimiento de Instalacin Servidor no compartido: Solamente un objeto de una implementacin puede estar activa en este servidor. Servidor por mtodo: Un objeto tiene sus mtodos divididos entre varios servidores. En este caso el Basic Object Adapter arranca un servidor por cada mtodo invocado, siendo desactivado cada vez que termina la invocacin.

-

-

Library Object Adapter: Est especializado en objetos que son accedidos por un solo proceso. Estos objetos usualmente no requieren de activacin o de autenticacin. Object Oriented Database Adapter: Debido a que las bases de datos orientadas a objetos proporcionan mtodos y el almacenamiento persistente, los objetos pueden ser registrados implcitamente y el Object Adapter no necesitara guardar sus estados.

Figura 11: Estructura del Object Adapter

3.6.5. Esqueleto Es el intermediario entre ORB y los objetos del servidor. Recibe llamadas del ORB y ejecuta los mtodos correspondientes en el servidor sobre el objeto que corresponda. Cuando el cliente establece un objeto local (con servicio remoto), la peticin se realiza por intermedio del protocolo de comunicaciones IIOP a travs del ORB. El servidor recibe la peticin, busca el objeto definido (compara el esqueleto del mtodo en el mdulo esqueleto) lo ejecuta y retorna la respuesta al cliente.

3.7.

Corba en Control de Procesos

En el mundo del control de procesos CORBA se ha empleado de forma experimental en muchos proyectos de investigacin y algunos fabricantes de sistemas de control distribuido los han venido empleado en subsistemas (principalmente en sistemas de fabricacin). En el mbito del control de procesos continuos, la principal barrera existente a la introduccin de CORBA es la reducida tasa de actualizacin tecnolgica de estas industrias y al hecho de que los fabricantes de sistemas de automatizacin tratan de mantener mercados cautivos mediante el uso de tecnologas propietarias. Afortunadamente, esto est cambiando y, cada da ms, los responsables de las plantas industriales plantean el sometimiento a

estndares internacionales como uno de los requisitos bsicos de los sistemas de nueva construccin.

IV.4.1.

TECNOLOGIA CORBA

Corba como Plataforma de Distribucin e Integracin

CORBA ofrece la posibilidad de construir mecanismos de integracin de sistemas distribuidos por medio de dos especificaciones fundamentales: 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 con dicha 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 datos de 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 clienteservidor necesaria. La implementacin ms comn del protocolo general GIOP es 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.

Corba para Sistemas de Control

La especificacin de CORBA de tiempo real surge de las esfuerzos de la OMG por adaptar sus especificaciones para su uso en sistemas distribuidos de tiempo real. Algunas de las especificaciones de relevancia para este mbito de aplicacin son: 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 especificados en la etapa de diseo. Todas las partes relativas a la invocacin dinmica de servicios y los almacenes de informacin en caliente se eliminan (para ser mas precisos, no se requieren de implementaciones que reclamen ajustarse a la especificacin de Minimum CORBA). 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 de servicio de la especificacin de Messaging o el concepto de tiempo de la especificacin Enhanced Time. 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 un 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. 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 Lightweigh CCM permiten simplificar el despliegue y la gestin de aplicaciones complejas basada en objetos CORBA. La especificacin de Smart Transducers introduce mecanismos para la gestin de sensores y actuadores muy empotrados y tambin clusters de los mismos.2

V.-

CONCLUSIONES

CORBA 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 e 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.

-

-

-

VI.

REFERENCIAS BIBLIOGRFICAS

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