APLICACIONES DISTRIBUIDAS HENRY MAURICIO ROMERO QUIROGA 160001428

APLICACIONES DISTRIBUIDAS DCOM RMI CORBA Netremoting

CORBA (Common Object Request Broker Architecture arquitectura común de intermediarios en peticiones a objetos) Es un estándar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos.

corba fue definido y está controlado por el Object Management Group (OMG) que define las APIs “Envuelve" el código escrito en otro lenguaje en un paquete que contiene información adicional sobre las capacidades del código que contiene, y sobre cómo llamar a sus métodos.

Tipos de Implementaciones de corba Ada C C++ Smalltalk Java Python Perl TCL

Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto). CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones.

EJEMPLOS http://grasia.fdi.ucm.es/jpavon/dso/corba02ejemplojava.pdf http://edocs.bea.com/tuxedo/tux80/interm/csamples.htm

RMI RMI (Java Remote Method Invocation) es un mecanismo ofrecido en Java para invocar un método remotamente.

Proveyendo pasaje por referencia de objetos. RMI puede darse el lujo de ser muy amigable para los programadores: Proveyendo pasaje por referencia de objetos. “Recolección de basura" distribuida. Pasaje de tipos arbitrarios Por medio de RMI, un programa Java puede exportar un objeto.

Contexto A pesar de que RMI es un ORB en el sentido general, no es un modelo compatible con CORBA. RMI es nativo de Java, es decir, es una extensión al núcleo del lenguaje. fue diseñada para resolver problemas escribiendo y organizando código ejecutable.

Arquitectura Primera capa Es la de aplicación y se corresponde con la implementación real de las aplicaciones cliente y servidor. Segunda capa Es la capa proxy, o capa stub-skeleton. Esta capa es la que interactúa directamente con la capa de aplicación.

Tercera capa Es la de referencia remota, y es responsable del manejo de la parte semántica de las invocaciones remotas. Cuarta Capa Es la de transporte. Es la responsable de realizar las conexiones necesarias y manejo del transporte de los datos de una máquina a otra.

Elementos Toda aplicación RMI normalmente se descompone en 2 partes: Un servidor Un cliente

DCOM Distributed Component Object Model (DCOM), Modelo de Objetos de Componentes Distribuidos, es una tecnología propietaria de Microsoft para desarrollar componentes software distribuidos sobre varios ordenadores y que se comunican entre sí.

En términos de las extensiones que añade a COM, DCOM tenía que resolver los problemas de: Aplanamiento Recolección de basura distribuida Uno de los factores clave para resolver estos problemas es el uso de DCE/RPC como el mecanismo RPC subyacente bajo DCOM.

DCOM fue uno de los mayores competidores de CORBA DCOM fue uno de los mayores competidores de CORBA. Los defensores de ambas tecnologías sostenían que algún día serían el modelo de código y servicios sobre Internet.

Versiones alternativas e implementaciones El Open Group tiene una implementación DCOM llamada COMsource, cuyo código fuente está disponible, así como la documentación completa, suficiente para su uso y suficiente también para implementar una versión interoperable de DCOM.

El equipo de Wine también está implementando DCOM El equipo de Wine también está implementando DCOM. Lo hacen para conseguir la interoperabilidad binaria, y no están interesados en la parte de distribución sobre la red de DCOM, que es proporcionada por MSRPC

NETREMOTING Microsoft® .NET Remoting proporciona el marco que permite a los objetos interactuar entre sí desde distintos dominios de aplicaciones e incluye servicios como la activación y la compatibilidad con la duración de los objetos, junto con los canales de comunicación responsables del transporte de mensajes a y desde aplicaciones remotas

Los formateadores se emplean para codificar y descodificar los mensajes antes de que éstos se envíen por el canal. Las aplicaciones pueden hacer uso de la codificación binaria en los casos en los que el rendimiento es un factor fundamental, o bien, la codificación XML, en aquellos otros en los que el aspecto esencial es la interoperabilidad con otros marcos remotos.

CANALES Los canales se utilizan para transportar mensajes a y desde objetos remotos. Cuando un cliente llama a un método en un objeto remoto, los parámetros, así como otros detalles relacionados con la llamada, se transportan a través del canal al objeto remoto.

La selección del canal está sujeta a las siguientes reglas: Al menos un canal debe estar registrado con el marco de servicios remotos para poder llamar a un objeto remoto. Los canales deben registrarse antes que los objetos. Los canales se registran por dominio de aplicación. En un único proceso pueden existir varios dominios. Cuando el proceso termina, todos los canales que éste registra se destruyen automáticamente.

No se puede registrar el mismo canal que escucha en el mismo puerto más de una vez. Los clientes se pueden comunicar con el objeto remoto utilizando cualquier canal registrado. El marco de servicios remotos garantiza que el objeto remoto se conecta al canal adecuado cuando el cliente intenta realizar la conexión.

EJEMPLOS http://es.gotdotnet.com/quickstart/howto/doc/Remoting/quickstart.aspx