Download DCOM

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/corba
02ejemplojava.pdf
http://edocs.bea.com/tuxedo/tux80/inter
m/csamples.htm
RMI

RMI (Java Remote Method
Invocation) es un mecanismo
ofrecido en Java para invocar un
método remotamente.
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 stubskeleton. 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:
1.
2.
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. 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. 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