trabajo de corba

Universidad San Pedro Sede -Barranca

Escuela: Ingeniera Informtica y de Sistemas. Curso: Sistemas Distribuidos Ciclo: VIII

APLICACIONES CORBA

INTEGRANTES: . CHAVEZ MARZANO MARIA ALEJANDRA . SANDRA DEL CARMEN ORTIZ SOTELO . AMALIA ZELAYA MELGAREJO . JARA JUAREZ JHELLING

1



INDICE INTRODUCCIN CORBA (COMMON OBJECT REQUEST BROKER) OMG OMA CORBA REVISIN DE CORBA EL ORB MISIN DEL ORB MARSHALING INDEPENDENCIA DE LA PLATAFORMA EL IDL EL REGISTRO DE INTERFAZ EL MODELO DE OBJETO CORBA INTRODUCCIN REFERENCIAS A OBJETOS LOS ADAPTADORES DE OBJETO EL MODELO DE COMUNICACIONES CORBA PROTOCOLOS ENTRE ORBS CORBA Y EL MODELO DE TRABAJO EN RED CLIENTES Y SERVIDORES CORBA EJEMPLO DE PROGRAMACIN EN CORBA INTERFAZ IDL ALTERNATIVAS A CORBA A. VENTAJAS 05 06 07 08 09 09 11 11 13 13 14 15 16 16 17 17 18 18 19 20 21 21 23 242



B. INCONVENIENTES LIMITACIONES E INCONVENIENTES CORBA CARACTERSTICAS IDIOMA DE LA INDEPENDENCIA SISTEMA OPERATIVO DE LA INDEPENDENCIA LA LIBERTAD DE TECNOLOGAS LOS DATOS FUERTES TYPING ALTA CAPACIDAD DE TUNE LIBERTAD DE INFORMACIN DE TRANSFERENCIA DE DATOS COMPRESIN LOS PROBLEMAS Y LAS CRTICAS INCOMPATIBILIDADES DE EJECUCIN VIVO EN LA TRANSPARENCIA DISEO Y PROCESO DE LAS DEFICIENCIAS CORTAFUEGOS ALTERNATIVAS CORBA APLICACIONES DISTRIBUIDAS LOS DATOS SE DISTRIBUYEN LA COMPUTACIN ES DISTRIBUIDA USUARIOS SE DISTRIBUYEN REALIDADES FUNDAMENTALES DE LOS SISTEMAS DISTRIBUIDOS SISTEMAS DISTRIBUIDOS DE OBJETOS

25 26 27 27 27 27 28 28 29 29 29 30 30 30 31 32 33 34 34 34 35 37

3



ARQUITECTURA CORBA EL ORB CORBA COMO UN ESTNDAR PARA OBJETOS DISTRIBUIDOS CORBA SERVICIOS PRODUCTOS CORBA LA SOLICITUD DE ARCHIVO ALGUNOS OBJETOS DE LA APLICACIN DE ARCHIVO LOS OBJETOS CORBA SE DESCRIBEN MEDIANTE INTERFACES IDL ADAPTADORES DE OBJETOS CORBA DESDE JAVA FICHERO IDL CLIENTE IMPLEMENTACIN DEL SERVANT EL SERVIDOR EJECUCIN REVISIN BIBLIOGRAFIA

37 38 38 39 41 42 44 44 47 48 48 49 51 53 56 56 57

4



INTRODUCCIN

Una caracterstica importante de las grandes redes de ordenadores actuales, como Internet, es su heterogeneidad. La heterogeneidad y la estandarizacin nos permiten, idealmente, utilizar la mejor combinacin de hardware y software, aumentando el rendimiento de las aplicaciones sin afectar a su interoperabilidad, consiguiendo un sistema coherente, eficiente y altamente operativo. Pero la prctica demuestra que cumplir los requerimientos de seguridad, eficiencia, flexibilidad y extensibilidad, en sistemas distribuidos heterogneos es, desafortunadamente, raramente fcil.

Estas exigencias motivaron el uso de CORBA (Common Object Request Broker Architecture). CORBA es un estndar abierto del OMG (Object Management Group) para la programacin de aplicaciones distribuidas. CORBA mejora la flexibilidad y portabilidad de las aplicaciones y permite al programador desentenderse de las tareas ms complejas que conllevan los entornos distribuidos heterogneos, con muy diversas mquinas, sistemas operativos y protocolos de comunicaciones. CORBA constituye, por ser la arquitectura distribuida de ms xito actualmente, el soporte fundamental para la consecucin de la universalidad de las aplicaciones, y es un entorno cada vez ms demandado por las empresas dedicadas a las telecomunicaciones avanzadas.

5



CORBA (COMMON OBJECT REQUEST BROKER)

Es una tecnologa para crear sistemas distribuidos, creada por un consorcio de fabricantes, agrupados bajo el OMG.

El estndar CORBA define qu ha de incluir una implementacin estndar, pero no cmo se han de hacer. Esta tarea se deja de la mano de los diferentes fabricantes. Esta es una de las principales caractersticas de CORBA: permite una total libertad a los implementadores siempre que estos respeten unos mnimos orientados a la interoperabilidad entre implementaciones.

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 otro programa (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 para Ada, C, C++, Smalltalk, Java, Python, Perl y Tcl.

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 como stub, el cual incluye un proxy (representante) del objeto remoto en el lado del cliente. El cdigo generado para el servidor consiste en unos skeletons (esqueletos) que el desarrollador tiene que rellenar para implementar los mtodos del objeto.

6



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 si, en realidad es un middleware.

OMG

El OMG es un consorcio internacional sin nimo de lucro establecido en 1989. Su objetivo es, ayudar a reducir la complejidad, disminuir los costes y acelerar la introduccin de nuevas aplicaciones software, promoviendo la teora y la prctica de la tecnologa de objetos en los sistemas distribuidos.

Originalmente estaba formada por 13 compaas, pero los miembros del OMG han crecido progresivamente y en la actualidad es el consorcio de software ms grande del mundo, compuesto por ms de 760 vendedores, programadores y usuarios. De hecho todas las grandes compaas de software interesadas en el desarrollo orientado a objetos distribuidos son miembros del OMG.

El OMG alcanza sus objetivos promoviendo la adopcin de especificaciones de interfaz y de protocolo, que permiten la interoperabilidad y portabilidad de las aplicaciones orientadas a objetos distribuidos. En este consorcio no se producen guas de cmo implementar o producir software, slo especificaciones.

Los miembros del OMG contribuyen tecnolgicamente y con ideas en respuesta a RFI (Request For Information) y RFP (Request For Proposals), emitidas por el OMG. El OMG no establece estndares en la industria, se form para promover mediante el consenso de sus participantes, la adopcin de estndares de facto por parte de los vendedores. El estndar a ser adoptado, debe existir como una implementacin; es decir, slo se aprueba un estndar si alguien lo ha implementado y se comprueba su correcto funcionamiento.

7



OMA

OMA (Object Management Architecture) o arquitectura de gestin de objetos es el centro de toda la actividad emprendida en el OMG. Se trata de una visin a alto nivel de un entorno distribuido completo y se compone de un modelo de objeto y un modelo de referencia.

En el modelo de objeto de OMA, un objeto es una entidad encapsulada con una identidad inmutable y distinguible, cuyos servicios pueden ser accedidos a travs de interfaces bien definidas.

Figura 1: Modelo de referencia de OMA.

En la Figura 1 se muestran los componentes del modelo de referencia de OMA, encargado de caracterizar las interacciones entre objetos. El componente fundamental es el denominado ORB (Object Request Broker). El ORB es, principalmente, el responsable de facilitar la comunicacin entre clientes y objetos. Puede verse como el microkernel de un sistema distribuido. Utilizando el componente ORB hay cuatro categoras de interfaces de objetos, descritas a continuacin:8



Servicios comunes a todos objetos. Son interfaces independientes del dominio, que son utilizados por varios programas de objetos distribuidos. Ejemplos de estos servicios son: el servicio de nombres, que permite a los clientes encontrar objetos en funcin de sus nombres; el servicio de intercambio, que permite a los clientes encontrar objetos a partir de sus propiedades; el de control de la concurrencia; el de transacciones; etc.

Facilidades comunes. Estn orientadas a las aplicaciones del usuario final (por ejemplo, facilidades para la gestin de la informacin, administracin del sistema, gestin de tareas, etc.).

Interfaces del dominio. Son semejantes a los servicios de objetos y facilidades comunes, pero estn orientadas a dominios de aplicacin especficos (por ejemplo, telemedicina, aplicaciones financieras, etc.).

Interfaces de aplicacin. Estn orientadas a una aplicacin especfica y por lo tanto no estn estandarizadas por el OMG.

CORBA

REVISIN DE CORBA

La especificacin CORBA detalla las interfaces y caractersticas del componente ORB de la OMA. La ltima actualizacin hasta el momento es CORBA 2.2. En la Figura 2, se muestra la arquitectura CORBA y como se relacionan sus distintos componentes.

9



Figura 2: Arquitectura de CORBA.

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 estndar UML (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 y10



el significado de dichos diagramas. UML no describe el proceso a seguir al desarrollar el software, tambin considerado en la metodologa formal tradicional.

EL ORB

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 de scripts est 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.11



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.

12



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.

INDEPENDENCIA DE LA PLATAFORMA

Un 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.

13



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 tipo long es un entero con signo de 32 bits, que se puede hacer corresponder con un long de C++ (dependiendo de la plataforma) o a un int de Java. Es responsabilidad de la 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, el14



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.

IDL Short Long

C++ CORBA::Short CORBA::Long

Unsigned short CORBA::UShort Unsigned long CORBA::ULong Float Double Char Boolean Octect Any CORBA::Float CORBA::Double CORBA::Char CORBA::Boolean CORBA::Octect CORBA::Any

Tabla 1: Correspondencia para los tipos de datos bsicos.

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 su15



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.

EL MODELO DE OBJETO CORBA

INTRODUCCIN

Toda arquitectura orientada a objeto caracteriza un modelo de objeto, que describe cmo se representan los objetos en el sistema. No obstante, puesto que CORBA es una arquitectura distribuida, su modelo de objeto difiere de los modelos de objetos tradicionales como C++ o Java. Distribucin de los objetos.

Para un cliente CORBA, una llamada a procedimiento remoto se ve exactamente igual a la llamada a un mtodo local. As, la naturaleza distribuida de los objetos CORBA es transparente a los usuarios de dichos objetos; los clientes no son conscientes de que estn realmente tratando con objetos distribuidos en una red.

Debido a que la distribucin de objetos supone una mayor probabilidad de fallo (cada de un servidor, cada de un segmento o enlace de la red), CORBA debe ofrecer mecanismos

16



para manejar dichas posibles situaciones. Para ello, proporciona un conjunto de excepciones, que pueden ser lanzadas por cualquier mtodo remoto.

REFERENCIAS A OBJETOS

En una aplicacin distribuida, hay dos mtodos posibles para que el componente de una aplicacin obtenga el acceso a un objeto en otro proceso.

Un mtodo es conocido como paso por referencia. Mediante este mecanismo cuando un proceso invoca un mtodo sobre un objeto en un proceso remoto, el mtodo es ejecutado por dicho proceso remoto pues el objeto existe en la memoria y espacio de procesos de dicho proceso. El pasar un objeto por referencia significa que un proceso admite la visibilidad de uno de sus objetos (a travs de las referencias a esos objetos) en otro proceso mientras conserva la propiedad de ese objeto.

El segundo mtodo para pasar un objeto entre componentes de una aplicacin se conoce como paso por valor. Mediante este mecanismo, el actual estado del objeto (as como los valores de sus atributos) es pasado al componente que lo solicita. Cuando los mtodos de un objeto son invocados por un proceso remoto, son ejecutados por dicho proceso en vez de por aquel en el que reside el objeto original. Es ms, puesto que el objeto es pasado por valor, el estado del objeto original no cambia; slo la copia es modificada.

LOS ADAPTADORES DE OBJETO

El estndar CORBA describe un cierto nmero de adaptadores de objeto, cuya principal tarea es la de hacer de interfaz entre la implementacin de un objeto y su ORB, puesto que se trata de mantener el ORB tan sencillo como sea posible. El ORB, en efecto, slo ha de proporcionar una infraestructura de comunicacin y activacin para aplicaciones de objetos distribuidos.

17



Los adaptadores de objeto son, en otras palabras, un objeto interpuesto que usa la delegacin para permitir realizar invocaciones sobre un objeto, incluso aunque el innovador no conozca la verdadera interfaz del objeto. Entre las responsabilidades de los adaptadores de objeto, cabe destacar las siguientes:

La demultiplexacin de solicitudes al servidor adecuado, es decir, la localizacin del servidor.

El envo de la operacin solicitada al servidor. La activacin y desactivacin de objetos. La generacin de referencias a objetos.

Actualmente CORBA slo proporciona un adaptador de objeto, conocido por adaptador de objeto bsico. El adaptador de objeto bsico suministra objetos CORBA con un conjunto comn de mtodos para acceder a las funciones del ORB y trata de ser un adaptador de objeto multipropsito que pueda soportar varios estilos e

implementaciones de servidores, resultando ser muy bsica en ciertas reas. Esto ha supuesto baja eficiencia y baja portabilidad, pues cada vendedor ORB ha optado por cubrir dichas reas con implementaciones propias. No obstante el OMG se ha percatado de este problema y est trabajando activamente en l.

EL MODELO DE COMUNICACIONES CORBA

PROTOCOLOS ENTRE ORBS

La especificacin CORBA es independiente de los protocolos de transporte; el estndar CORBA especifica el conocido como GIOP(General Inter-ORB Protocol). GIOP especifica, a alto nivel, un estndar para la comunicacin entre varios componentes CORBA ORBs.

GIOP, es slo un protocolo general; el estndar CORBA tambin determina protocolos adicionales, que especializan GIOP para utilizar un protocolo de transporte en particular. Por ejemplo, los protocolos basados en GIOP existen para TCP/IP y DCE. Adicionalmente,18



los vendedores pueden definir y utilizar protocolos propietarios para la comunicacin entre componentes CORBA.

El protocolo basado en GIOP ms importante es el destinado a redes TCP/IP, conocido como IIOP (Internet Inter-ORB Protocol). Los vendedores tienen que implementar el protocolo IIOP para ser considerados conformes a CORBA, aunque pueden ofrecer adems sus protocolos propietarios. Este requerimiento ayuda a asegurar la interoperabilidad entre los productos CORBA de diferentes vendedores pues cada producto conforme a CORBA 2.2 debe ser capaz de hablar el mismo lenguaje. Algunos vendedores han adoptado IIOP como protocolo nativo de sus productos en vez de utilizar un protocolo propietario; sin embargo, se permite que un ORB soporte cualquier nmero de protocolos, siembre y cuando IIOP se soporte, es decir, al comunicarse entre s, los ORBs pueden negociar que protocolo utilizar. Adicionalmente algunos fabricantes estn incorporando IIOP en productos como servidores de bases de datos o herramientas de desarrollo de aplicaciones o navegadores Web.

CORBA Y EL MODELO DE TRABAJO EN RED

Esencialmente, las aplicaciones CORBA se realizan sobre los protocolos derivados de GIOP como IIOP. Estos protocolos van sobre TCP/IP, DCE o cualquier otro protocolo de transporte que utilice la red. Las aplicaciones CORBA no estn limitadas a utilizar nicamente uno de estos protocolos; la arquitectura de una aplicacin puede ser diseada para utilizar un puente que interconecte, por ejemplo, componentes de una aplicacin basados en DCE con otros basados en IIOP. Es decir, mquinas que suplantan los protocolos de la red de transporte. CORBA es una arquitectura que crea otra capa (la capa del protocolo entre ORBs) que utiliza la capa de transporte subyacente. Esto es tambin un punto determinante de la interoperabilidad entre aplicaciones CORBA, CORBA no dicta la utilizacin de una capa de transporte en particular.

19



CLIENTES Y SERVIDORES CORBA

Tradicionalmente, en una aplicacin cliente/servidor, el servidor es el componente o componentes que proporciona servicios a otros componentes de la aplicacin. El cliente es el componente que hace uso de los servicios suministrados por un servidor o servidores.

La arquitectura de una aplicacin CORBA no es diferente; generalmente, ciertos componentes de una aplicacin proporcionan servicios que son utilizados por otros componentes de otra aplicacin. El papel del cliente y servidor puede intercambiarse temporalmente, ya que un objeto CORBA puede participar en mltiples interacciones simultneamente.

En una aplicacin CORBA, cualquier componente que proporciona la implementacin para un objeto es considerado un servidor. El hecho de ser un servidor CORBA significa que, el componente (el servidor), ejecuta mtodos para un objeto particular, en nombre de otros componentes (los clientes). Stubs y skeletons.

Despus de que el programador cree las definiciones de interfaz del componente utilizando IDL, dicho desarrollador procesa los ficheros IDL resultantes con un compilador IDL. El compilador crea los conocidos por client stubs y server skeletons. Los client stubs y server skeletons sirven como una clase de pegamento que conecta las especificaciones de interfaz IDL independientes del lenguaje con un cdigo de implementacin especfico del lenguaje.

Los client stubs para una interfaz en particular se suministran para su inclusin con los clientes que utilizan dichas interfaces. El client stub para una interfaz en particular, proporciona una falsa implementacin para cada uno de los mtodos de dicha interfaz. En vez de ejecutar la funcionalidad del servidor, los mtodos del client stub simplemente se comunican con el ORB para clasificar y desclasificar los parmetros.20



Por otro lado, se tienen los server skeletons, proporcionando el esqueleto sobre el que se construir el servidor. Para cada mtodo en la interfaz, el compilador IDL genera un mtodo vaco en el server skeleton. El desarrollador despus proporciona una implementacin para cada uno de esos mtodos.

Los stubs y skeletons han sido generalizados a un DII (Dynamic Invocation Interface) y DSI (Dynamic Skeleton Interface), respectivamente. Ambas son interfaces proporcionadas directamente por ORB, y son independientes de las interfaces IDL de los objetos que estn siendo invocados. Utilizando DII una aplicacin cliente puede invocar peticiones, en cualquier objeto, sin tener conocimiento en tiempo de compilacin de las interfaces del objeto. De forma semejante, DSI permite a los servidores ser codificados, sin tener skeletons para los objetos que estn siendo invocados, siendo compilados estticamente en el programa.

EJEMPLO DE PROGRAMACIN EN CORBA

En este apartado mostramos un sencillo ejemplo del desarrollo de una aplicacin en CORBA, en concreto en Orbix 2.2 de IONA Technologies PLC sobre el sistema operativo Unix Solaris 5.5.1 de Sun Microsystems. Se trata de un contador, cuyo valor podr ser reseteado, incrementado, decrementado y consultado por los clientes ejecutndose en la misma u otras mquinas. Para informacin sobre IONA, puede acudir a su Sitio Web, en http://www.iona.com/.

INTERFAZ IDL

El cdigo de la interfaz IDL de un contador, que sera comn a la implementacin de CORBA de cualquier vendedor, es el siguiente:

// Interfaz IDL a un contador.21



interface Contador { // Devuelve el valor actual del contador long daValor (); // Pone el contador al valor especificado oneway void ponValor (in long valor); // Incrementa el valor del contador en la cantidad especificada y devuelve el valor resultante long incrementarValor (in short cantidad); // Decrementa el valor del contador en la cantidad especificada y devuelve el valor resultante long decrementarValor (in short cantidad); };

Por defecto todos los mtodos son bloqueantes, es decir, cuando un objeto llama a un mtodo en un objeto remoto, el objeto que invoca el mtodo espera (se bloquea), hasta que el mtodo se ejecute y retorne. Cuando el objeto remoto termina de procesar la invocacin del mtodo, devuelve el valor resultante, con lo cual podr continuar con el resto de sus operaciones. Para indicar que la operacin sea no bloqueante, se debe especificar la clasula oneway antes de la definicin de ste.

Como puede observar, los parmetros en un mtodo pueden ser declarados como in indica que se trata de un parmetro de entrada-, out -indica que es un parmetro de salida-, o inout -indica que el parmetro se utiliza como entrada y salida del mtodo-. Esta interfaz ser compilada utilizando el compilador IDL, generando tres ficheros:

Un fichero de cabecera que deber ser incluido en la implementacin del contador y en sus clientes.

Un fichero fuente a ser compilado e incluido en la implementacin del contador. Un fichero fuente a ser compilado e incluido en los clientes del contador.

22



ALTERNATIVAS A CORBA

La eficiencia de las aplicaciones CORBA es, por lo general, menor que la de implementaciones a bajo nivel utilizando sockets en C/C++, ya que los ORBs incurren en una significante carga debido a la cantidad de datos copiados, la clasificacin y desclasificacin de argumentos, y la sobrecarga de demultiplexacin de conexiones. No obstante, esta solucin es compleja, no portable y sujeta a muchos errores.

A primera vista, el entorno distribuido construido a partir de la arquitectura CORBA presenta grandes semejanzas con el de DCE (Distributed Computing Environment) del OSF (Open Software Foundation), que se basa en llamadas a procedimiento remoto o RPCs (Remote Procedure Call). Pero aunque la base lgica de ambas arquitecturas es la misma, hay diferencias significativas entre ambas.

Las RPCs, como su propio nombre indica, son inherentes a procedimientos, es decir, llaman a aplicaciones y sistemas operativos para que realicen tareas especficas, una al tiempo. CORBA, por el contrario, es inherentemente orientada a objeto, lo que significa que las aplicaciones por completo, as como las combinaciones de aplicaciones y datos, pueden invocar y encapsularse unas a otras. En vez de escribir una llamada procedimiento especifica para enlazar con las aplicaciones, el programador puede encapsular una aplicacin o una aplicacin y un rango dado de datos en otra aplicacin mayor. Actualmente las RPC son ligeramente ms eficientes que CORBA en aplicaciones sencillas.

CORBA actualmente presenta ms aspectos en comn con otro entorno para la integracin de aplicaciones, la especificacin OLE (Object Linking and Embedding) de Microsoft. CORBA y OLE utilizan principios de programacin orientada a objetos, incluyendo herencia, encapsulacin, y extensibilidad. El problema estaba en que OLE 2.0 no posibilitaba la integracin de aplicaciones en plataformas distintas a PCs, lo cual fue resuelto por la especificacin COM (Common Object Model), publicada por Microsoft y Digital conjuntamente, que estipula como la funcionalidad OLE puede extenderse para ser23



implementada en otras plataformas en las que se est utilizando CORBA. Adems, el OMG ha formulado un RFP para establecer la interoperabilidad entre CORBA y COM.

Otro ORB muy conocido es Java RMI (Remote Method Inovocation) de Sun Microsystems. Se trata de la solucin ms recomendable para escribir aplicaciones distribuidas en Java, por ser un ORB nativo a l, pero con la desventaja de no poder ser utilizado con objetos o aplicaciones codificadas en otros lenguajes.

A. VENTAJAS

1) DISPONIBILIDAD Y VERSATILIDAD

Muchas arquitecturas y sistemas operativos cuentan con una implementacin de CORBA, lo que hace suponer que se puede usar CORBA en virtualmente cualquier proyecto de sistemas distribuidos.

2) EFICIENCIA

La libertad de desarrollo ha favorecido la existencia de una plyade de implementaciones del estndar que se adaptan a multitud de posibles necesidades de los usuarios, generando una competencia que favorece aquellas implementaciones de mayor calidad y con ms caractersticas.

3) ADAPTACIN A LENGUAJES DE PROGRAMACIN

Adems, es posible emplear los servicios de CORBA desde cualquier lenguaje de programacin, desde C++, C Java, hasta COBOL Ada.

24



B. INCONVENIENTES

1) COMPLEJIDAD

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

1.

Hay que 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).

2.

Hay que ser conscientes a la hora de disear qu objetos van a ser remotos y cules no (los remotos sufren restricciones en cuanto a sus capacidades con respecto a un objeto normal).

3.

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).

2) INCOMPATIBILIDAD ENTRE IMPLEMENTACIONES

Muchas empresas ofrecen implementaciones CORBA, 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 obligan al programador a reciclarse cuando quiere cambiar de ORB. Adems, donde el estndar no concreta, las implementaciones pueden variar entre s, lo que da lugar a molestas incompatibilidades que complican la vida al usuario.

25



LIMITACIONES E INCONVENIENTES CORBA.

1.

El sistema no es transparente al programador. Las diferencias para el programador que quiera usar un determinado objeto con respecto a las de emplear uno local, se reducen a la inicializacin del mismo. En vez de inicializarlo normalmente, hay que pedir al ORB(via IOR o usando un nombre ms inteligible), una referencia al objeto remoto y luego convertirlo al tipo de objeto a manejar.

2.

Los objetos remotos se pueden usar por referencia, pero no por valor. As, cuando se haga uso de los mtodos de un objeto remoto (al que se accede por referencia), solo se le pueden pasar como parmetros (y el mtodo solo podrdevolver como resultado) tipos de datos contemplados en el IDL. Afortunadamente, este problema queda resuelto con CORBA 3, que s soporta el paso de parmetros por valor.

3.

Mltiples implementaciones de CORBA dan lugar a mltiples incompatibilidades. El estndar CORBA define a alto nivel qu funciones debe proporcionar un ORB y cmo han de interoperar estos entre s, lo que garantiza cierto grado de compatibilidad, pero el cmo se ofrezca esa funcionalidad al programador es algo que est al libre albedro del fabricante del ORB. Es ms, parte de la funcionalidad del estndar CORBA no es de obligado cumplimiento por parte de las compaias fabricantes para poder anunciarse como CORBA-compliant. En estas condiciones es muy dificil pensar que un programa que haya sido programado pensando en un ORB concreto, pueda funcionar bien con una simple recompilacin.

4.

El estndar CORBA est poco preparado para usarse en entornos embebidos (electrnica de consumo, asistentes digitales) o que requieran soporte de tiempo real. Para el primer caso, se dise en CORBA 3 un subconjunto llamdo Minumum CORBA que, al ser ms ligero, encaja mejor en los sistemas embebidos, donde el control del consumo de recursos es vital. Para solucionar el segundo problema, CORBA 3 introducirReal -Time CORBA, que introducir modelos de prioridad para conseguir un comportamiento predecible de los programas que lo usen.

26



CARACTERSTICAS

CORBA soporta varias caractersticas que se afirma que no hay otra tecnologa que las trae en un solo paquete. Estos beneficios incluyen el lenguaje y el sistema operativo de la independencia, la libertad de tecnologas vinculadas a las implementaciones, fuerte tipificacin de los datos, alto nivel de ajustabilidad, y la libertad de los detalles de las transferencias de datos distribuidas.

IDIOMA DE LA INDEPENDENCIA

CORBA en un principio fue diseado para ingenieros libre de las obsesiones y las limitaciones de la consideracin de sus diseos basados en un lenguaje de software en particular. En la actualidad hay muchos idiomas soportados por varios proveedores de CORBA, el ms popular es Java y C + +. Tambin hay C-solamente, SmallTalk, Perl, Ada, Ruby, Python y las implementaciones, slo para mencionar algunos.

SISTEMA OPERATIVO DE LA INDEPENDENCIA

Diseo de CORBA est destinado a ser independiente del sistema operativo. CORBA est disponible en Java (independiente del sistema operativo), as como de forma nativa para Linux / Unix, Windows, Sun, Mac y otros.

LA LIBERTAD DE TECNOLOGAS

Uno de los principales beneficios implcitos es que CORBA proporciona un campo de juego neutral para los ingenieros para ser capaz de normalizar las interfaces entre los diversos sistemas nuevos y antiguos. Cuando la integracin de C, C + +, Object Pascal, Java, Fortran, Python, y cualquier otro idioma o el sistema operativo en un solo modelo coherente diseo de sistemas, CORBA proporciona los medios para nivelar el terreno y permitir que distintos equipos de desarrollo de sistemas y pruebas unitarias que posteriormente podrn se unieron en un sistema en su conjunto. Esto no excluye la27



necesidad de que las decisiones bsicas de ingeniera de sistemas, tales como hilos, tiempo, duracin de los objetos, etc Estas cuestiones son parte de cualquier sistema, independientemente de la tecnologa. CORBA permite que los elementos del sistema que se normalizaron en un modelo de sistema cohesivo nico.

Por ejemplo, el diseo de una arquitectura de varios niveles es simple usando Java Servlets en el servidor web y diversos servidores CORBA que contienen la lgica de negocio y envolver los accesos de base de datos. Esto permite que las implementaciones de la lgica de negocio al cambio, mientras que los cambios en la interfaz que se deben manejar como en cualquier otra tecnologa. Por ejemplo, una base de datos contenido en un servidor puede tener su cambio de esquema de base de datos en aras de mejorar el uso del disco o el rendimiento (o incluso a escala total cambio de proveedor de base de datos), sin afectar a las interfaces externas. Al mismo tiempo, C + + cdigo de la herencia puede hablar con C / Fortran legado de cdigo y base de datos de cdigo Java, y puede proporcionar datos a una interfaz web.

LOS DATOS FUERTES TYPING

CORBA proporciona tipos de datos flexibles, por ejemplo un "CUALQUIERA" tipo de datos. CORBA tambin aplica datatyping bien acoplados, lo que reduce los errores humanos. En una situacin en pares nombre-valor se pasan alrededor, es concebible que un servidor ofrece una serie donde se esperaba una cadena.CORBA Interface Definition Language proporciona el mecanismo para garantizar que el usuario cumple con el cdigo del mtodo de los nombres, el rendimiento, los tipos de parmetros, y las excepciones.

ALTA CAPACIDAD DE TUNE

Hay muchas implementaciones disponibles (por ejemplo omniORB (de cdigo abierto de C + + y Python aplicacin)) que tienen muchas opciones para el ajuste de las funciones de administracin de subprocesos y la conexin. No todas las implementaciones ofrecen las mismas caractersticas. Esto es hasta el implementador.28



LIBERTAD DE INFORMACIN DE TRANSFERENCIA DE DATOS

Al manejar bajo nivel de conexin y roscado, CORBA proporciona un alto nivel de detalle en las condiciones de error. Esto se define en el conjunto excepcin CORBA define estndar y el conjunto especfico de la implementacin excepcin extendida. "A travs de las excepciones, la aplicacin puede determinar si una llamada fallida por razones tales como "pequeo problema, as que intntelo de nuevo", "El servidor est muerto" o "La referencia no tiene sentido." La regla general es: no recibir una excepcin significa que la llamada al mtodo completado con xito. Esta es una caracterstica de diseo muy potente.

COMPRESIN

CORBA calcula las referencias de sus datos en un formato binario y compatible con la compresin. IONA, recurso al que ya Telefnica ha trabajado en una extensin del estndar CORBA que ofrece la compresin.

LOS PROBLEMAS Y LAS CRTICAS

Mientras que CORBA se comprometi a entregar tanto en el cdigo de forma en que se escribi y construy el software, que ha sido objeto de muchas crticas.

Algunos de los fracasos se debieron a las puestas en prctica y el proceso por el cual se cre CORBA como un estndar, y otras reflejan problemas en la poltica y los negocios de la aplicacin de un estndar de software. Estos problemas llevaron a una disminucin significativa en el uso de CORBA y la adopcin de nuevos proyectos y reas.

29



INCOMPATIBILIDADES DE EJECUCIN

Las especificaciones iniciales de CORBA define nicamente el IDL, no el formato en el alambre. Esto significa que la compatibilidad de cdigo fuente era el mejor que estaba disponible desde hace varios aos. Con CORBA 2 y ms tarde este problema ha sido resuelto.

VIVO EN LA TRANSPARENCIA

CORBA idea de transparencia de ubicacin ha sido criticado, es decir, que los objetos que residen en el mismo espacio de direcciones y accesible con una simple llamada a la funcin se tratan igual que los objetos que residen en otras partes (los diferentes procesos en la misma mquina o mquinas diferentes). Esta nocin es errnea si se requiere que todos los accesos locales a ser tan complicado como el escenario ms complejo a distancia. Sin embargo, CORBA no pone una restriccin a la complejidad de las llamadas. Muchas implementaciones de prever recursivas rosca / conexin semntica. Es decir, A, B Obj Obj llamadas, que a su vez llama a Obj la espalda, antes de regresar.

DISEO Y PROCESO DE LAS DEFICIENCIAS

La creacin del estndar CORBA tambin se cita a menudo para su proceso de diseo por comit. No hubo un proceso de arbitraje entre las propuestas conflictivas o para decidir sobre la jerarqua de los problemas para hacer frente. As, la norma fue creada mediante la adopcin de una unin de las funciones de todas las propuestas sin tener en cuenta su coherencia. Esto hizo que el pliego de condiciones muy complejo, muy costoso de implementar por completo y muchas veces ambigua.

Un comit de diseo compuesto en gran parte de los vendedores de la aplicacin estndar, crea un desincentivo para que una norma general. Esto se debi a las normas y la interoperabilidad de aumento de la competencia y facilit el movimiento de clientes entre las implementaciones alternativas. Esto llev a la lucha poltica tanto dentro de la30



comisin, y lanzamientos frecuentes de las revisiones del estndar CORBA que eran imposibles de utilizar sin extensiones propietarias.

A travs de su historia, CORBA se ha visto afectada por las deficiencias en su implementacin.A menudo ha habido pocas implementaciones juego todos los elementos crticos de la especificacin, y las implementaciones existentes eran incompletos o inadecuados. Como no haba requisitos para proporcionar una implementacin de referencia, los miembros son libres de proponer las caractersticas que nunca fueron sometidas a pruebas de utilidad o aplicabilidad. Las implementaciones fueron obstaculizados an ms por la tendencia general de la norma sea ms explcito, y la prctica comn de poner en peligro la adopcin de la suma de todas las propuestas presentadas, que a menudo se crean las API que eran incoherentes y difciles de usar, incluso si las propuestas individuales eran perfectamente razonable.

Implementaciones de CORBA de trabajo han sido muy difciles de adquirir en el pasado, pero ahora son mucho ms fciles de encontrar. Algunas implementaciones mal diseados se han encontrado para ser complejo, lento, incompatibles e incompleta. Las versiones comerciales pueden ser muy costosas. Esto cambi considerablemente a medida comercial, aficionado, y financiado por el gobierno de alta calidad implementaciones libres lleg a estar disponible.

CORTAFUEGOS

CORBA (ms precisamente, IIOP ) utiliza primas TCP / IP para conexiones para transmitir datos. Sin embargo, si el cliente est detrs de un firewall muy restrictivo o proxy transparente entorno de servidor que slo permite HTTP conexiones con el exterior a travs de puerto 80, la comunicacin puede ser imposible, a menos que el servidor proxy en cuestin permite al HTTP CONNECT mtodo o SOCKS conexiones tambin. En un momento, era difcil, incluso para obligar a las implementaciones para utilizar un puerto estndar nico - que tienden a elegir al azar en lugar de mltiples puertos. Debido a estas dificultades, algunos usuarios han hecho un uso cada vez mayor de servicios web en lugar31



de CORBA. stos comunican a travs de XML / SOAP de a travs del puerto 80, que normalmente se deja abierto o filtrado a travs de un proxy HTTP dentro de la organizacin, para la navegacin web a travs de HTTP. Recientes implementaciones CORBA, sin embargo, el apoyo de SSL y puede ser fcilmente configurado para trabajar en un nico puerto. La mayora de los orbes de fuente abierta, tales como TAO y JacORB tambin apoyan GIOP bidireccional, lo que da CORBA la ventaja de ser capaz de utilizar la comunicacin de devolucin de llamada en lugar del enfoque caracterstico de votacin de las implementaciones de servicios Web. Adems, los cortafuegos ms amigables con CORBA ya estn disponibles comercialmente.

ALTERNATIVAS CORBA

La eficiencia de las aplicaciones CORBA es, por lo general, menor que la de implementaciones a bajo nivel utilizando sockets en C/C++, ya que los ORBs incurren en una significante carga debido a la cantidad de datos copiados, la clasificacin y desclasificacin de argumentos, y la sobrecarga de demultiplexacin de conexiones. No obstante, esta solucin es compleja, no portable y sujeta a muchos errores.

A primera vista, el entorno distribuido construido a partir de la arquitectura CORBA presenta grandes semejanzas con el de DCE (Distributed Computing Environment) del OSF (Open Software Foundation), que se basa en llamadas a procedimiento remoto o RPCs (Remote Procedure Call). Pero aunque la base lgica de ambas arquitecturas es la misma, hay diferencias significativas entre ambas.

Las RPCs, como su propio nombre indica, son inherentes a procedimientos, es decir, llaman a aplicaciones y sistemas operativos para que realicen tareas especficas, una al tiempo. CORBA, por el contrario, es inherentemente orientada a objeto, lo que significa que las aplicaciones por completo, as como las combinaciones de aplicaciones y datos, pueden invocar y encapsularse unas a otras. En vez de escribir una llamada procedimiento especifica para enlazar con las aplicaciones, el programador puede encapsular una aplicacin o una aplicacin y un rango dado de datos en otra aplicacin32



mayor. Actualmente las RPC son ligeramente ms eficientes que CORBA en aplicaciones sencillas.

CORBA actualmente presenta ms aspectos en comn con otro entorno para la integracin de aplicaciones, la especificacin OLE (Object Linking and Embedding) de Microsoft. CORBA y OLE utilizan principios de programacin orientada a objetos, incluyendo herencia, encapsulacin, y extensibilidad. El problema estaba en que OLE 2.0 no posibilitaba la integracin de aplicaciones en plataformas distintas a PCs, lo cual fue resuelto por la especificacin COM (Common Object Model), publicada por Microsoft y Digital conjuntamente, que estipula como la funcionalidad OLE puede extenderse para ser implementada en otras plataformas en las que se est utilizando CORBA. Adems, el OMG ha formulado un RFP para establecer la interoperabilidad entre CORBA y COM.

Otro ORB muy conocido es Java RMI (Remote Method Inovocation) de Sun Microsystems. Se trata de la solucin ms recomendable para escribir aplicaciones distribuidas en Java, por ser un ORB nativo a l, pero con la desventaja de no poder ser utilizado con objetos o aplicaciones codificadas en otros lenguajes.

APLICACIONES DISTRIBUIDAS

Productos CORBA proporcionan un marco para el desarrollo y ejecucin de aplicaciones distribuidas. Pero por qu iba a necesitar para desarrollar una aplicacin distribuida, en primer lugar? La distribucin presenta un nuevo conjunto de problemas difciles. Sin embargo, a veces no hay otra opcin, algunas aplicaciones por su propia naturaleza se distribuyen entre varios equipos a causa de uno o ms de las siguientes razones:

Los datos utilizados por la aplicacin se distribuyen El clculo se distribuye Los usuarios de la aplicacin se distribuyen

33



LOS DATOS SE DISTRIBUYEN

Algunas aplicaciones que se ejecutan en varios equipos porque los datos que la aplicacin debe tener acceso existen en varios equipos por razones administrativas y de propiedad. El propietario puede permitir que los datos que se accede de forma remota, pero no se almacenan de forma local. O tal vez los datos no pueden ser localizados, y debe existir en mltiples sistemas heterogneos por razones histricas.

LA COMPUTACIN ES DISTRIBUIDA

Algunas aplicaciones se ejecutan en varios equipos con el fin de aprovechar las mltiples procesadores de computacin en paralelo para resolver algn problema. Otras aplicaciones pueden ejecutarse en varios equipos con el fin de aprovechar algunas caractersticas nicas de un sistema en particular. Las aplicaciones distribuidas pueden tomar ventaja de la escalabilidad y la heterogeneidad del sistema distribuido.

USUARIOS SE DISTRIBUYEN

Algunas aplicaciones se ejecutan en varios equipos ya que los usuarios de la aplicacin se comunican e interactan entre s a travs de la aplicacin. Cada usuario ejecuta una pieza de la aplicacin distribuida en su ordenador, y los objetos compartidos, tpicamente ejecutar en uno o ms servidores. Una arquitectura tpica para este tipo de aplicacin se ilustra a continuacin.

34



Antes de disear una aplicacin distribuida, es esencial entender algunas de las realidades fundamentales del sistema de distribucin en la que se ejecutar.

REALIDADES FUNDAMENTALES DE LOS SISTEMAS DISTRIBUIDOS

Los desarrolladores de aplicaciones deben abordar una serie de cuestiones que se pueden tomar por sentado en un programa local, donde toda la lgica se ejecuta en el proceso mismo del sistema operativo. La siguiente tabla resume algunas de las diferencias bsicas entre los objetos que son co-ubicados en el mismo proceso, y los objetos que interactan a travs de los lmites del proceso o de la mquina.

CO-LOCALIZADOS Comunicacin Fallas Rpido Los objetos no juntos

DISTRIBUIDO Lento Los objetos no separados pueden particionar

El acceso concurrente Asegurar

Slo con varios subprocesos S S No

La comunicacin entre objetos en el mismo proceso en variaos rdenes de magnitud son ms rpidas que la comunicacin entre objetos en diferentes mquinas. La implicacin de35



esto es que se debe evitar el diseo de aplicaciones distribuidas en el cual dos o ms objetos distribuidos tienen interacciones muy ajustadas. Si tienen interacciones estrechas, deben ser co-localizados.

El diseador de los objetos no necesitan estar preocupados con el comportamiento de la aplicacin, si uno de los objetos est disponible y el otro no lo esta. Pero si dos objetos estn distribuidos en los lmites del proceso, los objetos pueden fallar de forma independiente. En este caso, el diseador de los objetos debe ocuparse de cada uno de los comportamientos del objeto en el caso de que el otro objeto haya fallado. De manera similar, en un sistema distribuido de la red puede particionarse los objetos para que se ejecuten de forma independiente suponiendo que el otro ha fallado.

El modo por defecto para la mayora de los programas locales es operar con un solo hilo de control. La programacin de un solo subproceso es fcil. Los objetos se acceden en un orden secuencial bien definido de acuerdo a los algoritmos del programa, y no necesita preocuparse por el acceso simultneo.

Si decide introducir mltiples hilos de control dentro de un programa local, debe tener en cuenta los ordenamientos posibles de acceso a los objetos y utilizar los mecanismos de sincronizacin para controlar el acceso concurrente a los objetos compartidos. Pero al menos usted tiene una opcin de la introduccin de mltiples hilos de control. En una aplicacin distribuida, hay temas necesariamente mltiples de control. Cada objeto distribuido est funcionando en un hilo diferente de control. Un objeto distribuido puede tener mltiples clientes simultneos. El desarrollador del objeto y el desarrollador de los clientes, debe tener en cuenta este acceso concurrente a los objetos y utilizar los mecanismos de sincronizacin necesarios.

Cuando dos objetos se ubican conjuntamente en el mismo proceso, no es necesario preocuparse por la seguridad. Cuando los objetos se encuentran en mquinas diferentes, es necesario utilizar los mecanismos de seguridad para autenticar la identidad del otro objeto.36



SISTEMAS DISTRIBUIDOS DE OBJETOS

Se distribuyen sistemas en los que todas las entidades se modelan como objetos. Sistemas de objetos distribuidos son un paradigma popular para aplicaciones orientadas a objetos distribuidos. Dado que la aplicacin se modela como un conjunto de objetos cooperantes, se asigna mucha naturalidad a los servicios del sistema de distribucin.

Los lmites del proceso son realmente importantes y tendrn impacto en su diseo.

ARQUITECTURA CORBA

CORBA define una arquitectura de objetos distribuidos. El paradigma bsico de CORBA es el de una solicitud de servicios de un objeto distribuido. Todo lo dems definido por el OMG es en trminos de este paradigma bsico.

Los servicios que proporciona un objeto estn dados por su interfaz. Las interfaces se definen en el idioma de la interfaz OMG Definicin (IDL). Objetos distribuidos son identificados por las referencias a objetos, los cuales son escritos por interfaces IDL.

La siguiente figura muestra grficamente una solicitud. Un cliente tiene una referencia de objeto a un objeto distribuido. La referencia al objeto se escribe por una interfaz. En la siguiente figura la referencia al objeto se escribe por el Rabbit de la interfaz. El Object Request Broker, o ORB, entrega la solicitud con el objeto y devuelve los resultados al cliente. En la figura, un jump devuelve un objeto de referencia escrito por el

AnotherObject interfaz.

37



EL ORB

El ORB es el servicio distribuido que implementa la peticin al objeto remoto. Localiza el objeto remoto en la red, se comunica la solicitud al objeto, espera los resultados cuando estn disponibles y comunica los resultados de vuelta al cliente.

El ORB implementa transparencia de ubicacin. Exactamente el mecanismo de solicitud es utilizada por el cliente y el objeto CORBA independientemente del lugar donde se encuentra el objeto. Puede ser que sea en el mismo proceso con el cliente, al final del pasillo o al otro lado del planeta. El cliente no puede ver la diferencia.

El ORB implementa independencia del lenguaje de programacin para la solicitud. El cliente enva la solicitud sta puede ser escrita en un lenguaje de programacin diferente de la implementacin del objeto CORBA. El ORB hace la traduccin necesaria entre los lenguajes de programacin. Los enlaces de lenguaje se definen para todos los lenguajes de programacin populares.

CORBA COMO UN ESTNDAR PARA OBJETOS DISTRIBUIDOS

Uno de los objetivos de la especificacin CORBA es que los clientes e implementaciones de objetos son porttiles. La especificacin CORBA define una interfaz de programacin de aplicaciones (API) para los clientes de un objeto distribuido, as como un API para la ejecucin de un objeto CORBA. Esto significa que el cdigo escrito para el producto de un proveedor de CORBA podra, con un mnimo de esfuerzo, ser reescrito para trabajar con38



el producto de un proveedor diferente. Sin embargo, la realidad de los productos de CORBA en el mercado hoy en da es que los clientes CORBA son portables, pero las implementaciones de objetos necesitan algunas correcciones al puerto de un producto CORBA a otro.

En particular, CORBA 2.0 define un protocolo de red, llamado IIOP (Internet Inter-ORB Protocol), que permite a los clientes que utilizan un producto CORBA de cualquier vendedor comunicarse con los objetos que utilizan un producto CORBA de cualquier otro fabricante. IIOP funciona a travs de Internet, o ms precisamente, a travs de cualquier implementacin de TCP / IP.

La interoperabilidad es ms importante en un sistema distribuido que la portabilidad. IIOP es usado en otros sistemas que ni siquiera intentan proporcionar la API de CORBA. En particular, IIOP se usa como protocolo de transporte para una versin de Java RMI (llamada "RMI sobre IIOP"). Dado que EJB se define en trminos de la RMI, tambin puede usar IIOP. Todos los IIOP en uso y los programas escritos para la API pueden interoperar entre s con los programas escritos para la API de CORBA.

CORBA SERVICIOS

Otra parte importante del estndar CORBA es la definicin de un conjunto de servicios distribuidos para apoyar la integracin y la interoperabilidad de objetos distribuidos. Como se representa en el grfico siguiente, los servicios, conocidos como Servicios CORBA o COS, se definen en la parte superior del ORB. Es decir, se definen como objetos estndar CORBA con interfaces IDL, a veces denominados como "Servicios de los objetos".

39



A continuacin se muestra una breve descripcin de cada uno:

Servicio Objeto del ciclo de vida

Descripcin Define cmo se crean los objetos CORBA, eliminar, mover y copiar

Nombrar

Define cmo los objetos CORBA pueden tener nombres simblicos amigables

Eventos Relaciones

Desacopla la comunicacin entre objetos distribuidos Proporciona arbitrarias mecanografiadas relaciones entre los objetos CORBA

Externalizacin

Coordina la transformacin de los objetos CORBA y los medios de comunicacin externos

Transacciones Control de concurrencia

Coordina el acceso a los objetos CORBA atmica Proporciona un servicio de bloqueo para objetos CORBA con el fin de garantizar el acceso serializable

Propiedad

Apoya la asociacin de pares nombre-valor con objetos CORBA

Comerciante

Compatible con el hallazgo de objetos CORBA basados en las40



propiedades que describen el servicio ofrecido por el objeto Query Pregunta Compatible con las consultas sobre los objetos

PRODUCTOS CORBA

CORBA no es una especificacin, sino que es una gua para la aplicacin de los productos. Muchos proveedores ofrecen productos CORBA para varios lenguajes de programacin. Los productos CORBA que soportan el lenguaje de programacin Java son:

ORB El ORB de Java 2

Descripcin El ORB de Java 2 viene con Java SDK de Sun 2. Estn faltando varias caractersticas.

VisiBroker para Java

Un popular ORB de Java de Inprise Corporation. VisiBroker tambin est incorporado en otros productos. Por ejemplo, es el astro que est incrustado en el navegador Netscape Communicator.

OrbixWeb WebSphere

Un popular ORB de Java de Tecnologas de Iona. Un servidor de aplicaciones populares con un ORB de IBM.

Netscape Communicator

Netscape tiene una versin de VisiBroker incrustado en ellas. Los applets pueden emitir sobre la solicitud de los objetos CORBA sin descargar clases ORB en el navegador. Ellos ya estn all.

Varias

ORBs

libres

o Implementaciones CORBA para varios idiomas estn disponibles para su descarga en la web de fuentes diversas.

shareware

41



LA SOLICITUD DE ARCHIVO

La solicitud de cotizacin de acciones es una aplicacin distribuida que muestra el lenguaje de programacin Java y CORBA.

La aplicacin de valores permite a varios usuarios ver la actividad de las poblaciones. El usuario se presenta con una lista de las existencias disponibles identificadas por los smbolos de sus acciones. El usuario puede seleccionar una accin y luego presione el botn "Ver".

Seleccin de la "vista" los resultados de botones en un informe sobre las acciones, lo que indica el nombre de la empresa, el smbolo de cotizacin, el precio actual, la ltima vez que se ha actualizado, el volumen de operaciones, y un grfico que muestra el precio de la accin sobre algunos intervalos. Este informe se actualiza automticamente los datos de archivo se disponga de nueva.

42



El informe de stock tambin permite al usuario configurar una alarma pulsando el botn "ALARM". La alarma se puede configurar para activarse cuando el precio de la accin cae por debajo de un determinado precio o cuando se supera un determinado precio.

Cuando el precio de la accin satisface la condicin de la alarma, se activa y el usuario es notificado.

43



Ms tarde, la aplicacin podra ampliarse para permitir a los usuarios comprar y vender acciones.

ALGUNOS OBJETOS DE LA APLICACIN DE ARCHIVO

De la descripcin anterior, usted puede identificar fcilmente a los siguientes objetos distribuidos en la aplicacin.

Valores

Un objeto distribuido que representa una accin en particular.

StockPresentation

Un objeto distribuido en la interfaz grfica de usuario que presenta los datos de saldos al usuario por una accin en particular.

Alarma

Un objeto distribuido que representa la alarma establecida por el usuario.

AlarmPresentation

Un objeto distribuido en la interfaz grfica de usuario que presenta la alarma de apagarse para el usuario.

El objeto de archivo se utiliza ahora para ilustrar el modelo de objetos distribuidos CORBA.

LOS OBJETOS CORBA SE DESCRIBEN MEDIANTE INTERFACES IDL

La OMG IDL Interface Definition Language es compatible con la especificacin de las interfaces de los objetos. Una interfaz de objeto indica las operaciones que el objeto admite, pero no cmo se implementan. Es decir, en IDL no hay manera de declarar el estado del objeto y los algoritmos. La implementacin de un objeto CORBA se presenta en un lenguaje de programacin estndar, tales como el lenguaje de programacin Java o

44



C + +. Una interfaz especifica el contrato entre el cdigo que utiliza el objeto y el cdigo de la aplicacin del objeto. Los clientes slo dependen de la interfaz.

Interfaces IDL del lenguaje de programacin neutral. IDL define enlaces de lenguaje de muchos lenguajes de programacin diferentes. Esto permite que un implementador objeto debe elegir el lenguaje de programacin adecuado para el objeto. Del mismo modo, permite que el desarrollador del cliente deba elegir el lenguaje de programacin adecuado y posiblemente diferentes para el cliente. En la actualidad, la OMG ha

estandarizado enlaces de lenguaje para el C, C + +, Java, Ada, COBOL, Smalltalk, Objective C, y los lenguajes de programacin Lisp.

As mediante el uso de OMG IDL, puede ser descrita sin relacin a cualquier lenguaje de programacin:

Modularizados interfaces de objetos Las operaciones y los atributos que un objeto admite Las excepciones planteadas por la operacin Tipos de datos de un valor de retorno operacin, sus parmetros y atributos de un objeto

Los tipos IDL datos son:

Tipos de datos bsicos ( long , short , string , float ...) Construidos los tipos de datos ( struct , union , enum , sequence ) Referencias con tipo de objetos La any tipo, un valor de tipo dinmico

Una vez ms, IDL no dice nada acerca de la implementacin de objetos. Aqu est la interfaz IDL para los objetos de ejemplo de acciones: module StockObjects {

45



struct Quote { string symbol; long at_time; double price; long volume; };

exception Unknown{};

interface Stock {

// Returns the current stock quote. / / Quote get_quote() raises(Unknown);

// Sets the current stock quote. / / void set_quote(in Quote stock_quote);

// Provides the stock description, / / // eg company name. / / readonly attribute string description; };

interface StockFactory {

Stock create_stock( in string symbol, in string description ); };

46



};

Ntese que el ejemplo anterior define un mdulo IDL denominado StockObjects , que contiene el:

Estructura de datos Quote Excepcin Unknown Interfaz Stock Interfaz StockFactory

El mdulo define un mbito de aplicacin de estos nombres. Dentro del mdulo, una estructura de datos Quote y una excepcin Unknown se definen y utilizan a continuacin en el Stock de interfaz. El Stock de interfaz se utiliza en la definicin de la StockFactory interfaz. Tambin tenga en cuenta que los parmetros de las operaciones estn

etiquetados con las palabras clave in , out , o inout . El in palabra clave indica que los datos se pasan del cliente al objeto. El out por palabra clave indica que los datos se devuelven desde el objeto hasta el cliente, y inout indica que los datos se pasan desde el cliente al objeto y luego se devuelve al cliente.

Declaraciones IDL se compilan con un compilador de IDL y se convierten en sus representaciones asociadas en los idiomas de destino de programacin de acuerdo a la unin de lengua estndar.

ADAPTADORES DE OBJETOS

La especificacin CORBA define el concepto de un adaptador de objeto. Un adaptador de objeto es un marco de aplicacin de los objetos CORBA. Proporciona una API que las implementaciones de objetos usan para diversos servicios de bajo nivel. De acuerdo con la especificacin CORBA, un adaptador de objeto es responsable de las siguientes funciones:

47



Generacin e interpretacin de las referencias a objetos Mtodo de invocacin Seguridad de las interacciones Objeto y aplicacin de la activacin y desactivacin Asignacin de referencias a objetos para las implementaciones de objetos correspondientes

El registro de las implementaciones

La arquitectura soporta la definicin de muchos tipos de adaptadores de objeto. La especificacin incluye la definicin del adaptador de objeto bsico (BOA). El BOA ha sido aplicado en diversos productos CORBA. Lamentablemente, desde la especificacin de la Junta de Auditores no estaba completo, las implementaciones de BOA se diferencian en algunos aspectos importantes. Esto ha puesto en peligro la portabilidad del servidor.

Para solucionar esta deficiencia, un adaptador de objeto completamente nuevo se aadi, al adaptador de objeto porttil (POA). Por desgracia, el POA todava no es posible en muchos productos.

CORBA DESDE JAVA

Para comprender el funcionamiento de CORBA desde Java, aqu un ejemplo sencillo de una aplicacin que define un IDL, un cliente y un servidor.

FICHERO IDL

El fichero IDL, Calculadora.idl es el siguiente: module prueba { interface Calculadora {48



double add (in double x, in double y); double substract (in double x, in double y); double multiply (in double x, in double y); double divide (in double x, in double y); void storeMemory (in double x); double readMemory (); }; };

Las funciones son las normales de una calculadora, como se puede ver.

Para generar los stubs y skeletons, hay que ejecutar el compilador de IDL. Lo ejecutamos con la opcin ((-fall)), para que genere tanto los stubs como los skeletons:

$ idlj -fall Calculadora.idl

Esto genera los ficheros de stub y skeleton dentro del subdirectorio ((prueba)):

$ ls prueba -C1 CalculadoraHelper.java CalculadoraHolder.java Calculadora.java CalculadoraOperations.java CalculadoraPOA.java _CalculadoraStub.java

CLIENTE

A continuacin se muestra el cliente (Cliente.java): Es un programa que es capaz de utilizar el objeto Calculadora:

49



package prueba ; import prueba .*; import org . omg . CORBA .*; import java .io .*; public class Cliente { public static void main ( String args []) { try {

// Iniciar el ORB org . omg . CORBA . ORB orb = org . omg . CORBA .ORB . init (args , null ); // Leer el IOR del fichero

File IORFile = new File (" IOR "); FileReader reader = new FileReader ( IORFile ); BufferedReader buf = new BufferedReader ( reader ); String IOR = buf . readLine ();

// Convertir el IOR en un objeto org . omg . CORBA . Object o = orb . string_to_object ( IOR ); Calculadora calc = CalculadoraHelper . narrow (o);

// Usar la calculadora System .out . println ( calc .add (2.0 ,3.0) ); } catch ( Exception e) { e. printStackTrace (); } } } El cliente realiza las siguientes labores:50



Lnea3: Incluye el paquete con el stub para el tipo de objeto Calculadora. Lnea15: Se inicia el ORB. Normalmente, el ORB se implementa como una funcin de librera. Esta llamada realiza todas las funciones de inicializacin para el ORB.

Lnea24: Se utiliza la operacin del ORB string to object para convertir el IOR dado en la Lneade comando como primer parametro en una referencia a un objeto CORBA. Todos los objetos CORBA heredan de la interfaz CORBA::Object (org.omg.CORBA.Object). Lnea25: El mtodo narrow de la clase CalculadoraHelper (generado

automaticamente) se utiliza para especializar la referencia obtenida a un objeto del tipo especfico. En este caso Calculadora. La funcin devolvera en calc la referencia especializada a un objeto de tipo Calculadora, o ((null)) si la conversin no se puede realizar

Lnea28: Se realiza la llamada propiamente dicha. La abstraccin proporcionada por CORBA permite hacer una llamada al objeto remoto como si fuera un objeto local. El resultado se imprime por la pantalla.

IMPLEMENTACIN DEL SERVANT

Para implementar un objeto CORBA, esto es, para ofrecer sus servicios al mundo, se tienen que implementar dos cosas:

El servant que contiene la implementacin de los mtodos del interfaz que se ofrece al exterior,

y un servidor, que quedar esperando conexiones en un puerto IP.

El servant es simplemente un objeto del lenguaje de programacin (en este caso Java) que implementa la funcionalidad de los mtodos del objeto CORBA. Este servant es llamado por el skeleton cuando un cliente llama a un mtodo del objeto CORBA implementado por ese servant. El cdigo del servant es el que se muestra a continuacin. Se ha implementado las funciones de la calculadora en el fichero CalculadoraImpl.java:51



package prueba ;

class CalculadoraImpl extends CalculadoraPOA { private double memory_ ;

public CalculadoraImpl () { memory_ = 0; } public double add ( double x, double y) { return x + y; }

public double substract ( double x, double y) { return x - y; } public double multiply ( double x, double y) { return x * y; }

public double divide ( double x, double y) { double result = 0;

try { result = x / y;52



} catch ( Exception e) { }

return result ; } public void storeMemory ( double x) { memory_ = x; }

public double readMemory () { return memory_ ; } }

De destacar en este fichero es:

El servant se implementa en una clase CalculadoraImpl. Todas las clases servant heredan de la clase ((POA)).

El interfaz de ese objeto, salvo algunos mtodos adicionales que se explican en la teora de la asignatura, sigue el definido en el IDL.

EL SERVIDOR

En cualquier aplicacin CORBA debe existir un servidor que quede esperando las peticiones sobre los objetos CORBA implementados por l (servants). El servidor es un programa Java normal que dejara activado un servant para el objeto CORBA.

53



package prueba ; import org . omg . CORBA .*; import org . omg . PortableServer .*;

public class Servidor { public static void main ( String [] args ) { try {

// Iniciar el ORB org . omg . CORBA . ORB orb = org . omg . CORBA .ORB . init (args , null ); // Objeto auxiliar org . omg . CORBA . Object o;

// Encontrar el POA raz POA rootPOA ; o = orb . resolve_initial_references (" RootPOA "); rootPOA = POAHelper . narrow (o); // Activar el POA rootPOA . the_POAManager (). activate ();

// Crear el objeto implmentacin

prueba . CalculadoraImpl calcImpl = new prueba . CalculadoraImpl (); // Registrarlo en el POA o = rootPOA . servant_to_reference ( calcImpl );

prueba . Calculadora calc = prueba . CalculadoraHelper . narrow (o);54



// Producir la direccin del objeto String ior = orb . object_to_string ( calc ); System .out . println ( ior ); // Esperar llamadas orb . run (); } catch ( Exception e) { e. printStackTrace (); } } }

El servidor contiene casi toda la carga de la dificultad de la programacin con CORBA.

Las tareas que implementa el servidor son las siguientes:

Lnea13: El ORB se inicia como en el cliente. Lneas 1924: Se obtiene el POA raz. El objeto servidor se tiene que registrar en un adaptador de objetos (OA). En CORBA, el POA es el adaptador de objetos, que se puede configurar como una jerarqua. En este caso, registraremos el objeto en el POA raz (RootPOA). Para la mayora de los usos, este adaptador de objetos es suficiente. Se obtiene el POA Manager. Este manager controla a un conjunto de adaptadores de objetos, permitindoles funcionar, o bien encolar las peticiones rechazarlas. Finalmente, se activa el POAManager. Lnea29: Se crea un objeto servant CalculadoraImpl. Lnea32: Se utiliza el mtodo servant to reference del POA para obtener una referencia CORBA a partir de un servant. Lnea35: La referencia se convierte a una referencia de un interfaz Calculadora. Este paso no es necesario, se muestra por completitud. Lnea38: La referencia se convierte en una cadena de caracteres con la funcin del ORB object to string.55



Lneas 4352: La referencia en formato cadena de caracteres se imprime por pantalla. Lnea42: El ORB se pone a funcionar (esperar peticiones). con la funcin run del ORB. El servidor queda as esperando las peticiones de los clientes.

EJECUCIN

Una tpica ejecucin del programa podra ser la siguiente:

$ java prueba.Servidor | tee IOR IOR:000... $ cat IOR IOR:000... $ java prueba.Cliente

REVISIN

$Id: corba-java.tex 1591 2006-12-12 09:58:08Z dsevilla $

56



BIBLIOGRAFIA

http://www.sage-technologies.net/corba/Orbarch.htm http://www.microsoft.com/Com/ Pgina oficial de Microsoft http://msdn.microsoft.com/library/en-us/dndcom/html/msdn_dcomarch.asp Arquitectura DCOM http://msdn.microsoft.com/library/en-us/dndcom/html/msdn_dcomtec.asp Resumen Tcnico de DCOM http://www.cvc.uab.es/shared/teach/a20383/practiques/ Introduccin al modelo COM http://www.gsi.dit.upm.es/~jcg/is/curso97-98/grupos/y3/html_doc/indice2.htm OLE/COM/DCOM http://www.dis.eafit.edu.co/areas/telematica/online/corba/intro/ Objetos distribuidos CORBA/RMI/DCOM http://www.gsyc.inf.uc3m.es/~jjmunoz/lro/9798/copia/%257Eatrigo/datos/indice.ht ml Programacin COM/DCOM http://club.idecnet.com/~chavesj/dcom/ DCOM for children http://www.codeguru.com/activex/index.shtml Cdigo fuente ActiveX/COM/DCOM http://www.cs.concordia.ca/~teaching/comp690j/dcomTutorial/comTutorial.html Tutorial DCOM/COM http://www.codeproject.com/com Cdigo fuente COM/DCOM http://journal.iftech.com/articles/dcom_1/ Excelente Tutorial de COM/DCOM http://www.cs.wustl.edu/~schmidt/submit/Paper.html DCOM y CORBA (comparacin) http://shrike.depaul.edu/~tliu/ds520/link.htm Links ActiveX y DCOM http://www.dalmatian.com/com_dcom.htm DCOM

57

trabajo de corba

Documents