UNIDAD III. COMUNICACIN.

Objetivo educacional.
Utilizar la comunicacin que se presenta en los sistemas distribuidos; as como las
principales tecnologas aplicadas en este rubro.

Actividades de aprendizaje.
- Investigacin sobre las principales tecnologas que permiten la comunicacin en sistemas
Distribuidos.
- Realizacin de ejercicios sobre comunicacin con las tecnologas investigadas
- Aplicacin del rubro de comunicacin en el proyecto.



Middleware.
Capa de software intermedio entre el cliente y el servidor. Es la capa de software que nos
permiten gestionar los mecanismos de comunicaciones. Ejemplo si se hace la peticin de
una pgina web desde un browser en el cliente, el middleware determina la ubicacin y enva
una peticin para dicha pgina. El servidor Web, interpreta la peticin y enva la pgina al
software intermedio, quien la dirige al navegador de la mquina cliente que la solicit.









3.1 Paso de Mensajes.
Es el paradigma ms sencillo de comunicacin a nivel de procesos. Consiste en que dos
procesos se comuniquen con mensajes bsicos entre ellos. Un proceso enva una solicitud a
otro que, al recibirla, puede generar una respuesta. Para este tipo de comunicacin, slo son
necesarias dos operaciones de gestin de la comunicacin: conexin y desconexin, y dos
operaciones de transferencia de la informacin: enviar y recibir. La programacin basada en
sockets est basada en este paradigma.

Paradigma de paso de mensajes.

Un proceso enva un mensaje de solicitud.
El mensaje llega al receptor, el cual procesa la solicitud y devuelve un mensaje en
respuesta.
Esta respuesta puede originar posteriores solicitudes por parte del emisor.


Las operaciones bsicas para soportar el paradigma de paso de mensajes son enviar
y recibir
o Protocolos ms comunes: IP y UDP.
Para las comunicaciones orientadas a conexin tambin se necesitan las operaciones
conectar y desconectarse necesitan las operaciones conectar y desconectar
o Protocolo ms comn: TCP.
Operaciones de Entrada/Salida que encapsulan el detalle de la comunicacin a nivel
del sistema operativo
o Ejemplo: el API de sockets

Un socket es un extremo o un punto terminal de un canal de comunicacin entre dos
procesos. Obviamente, para formar un canal de comunicacin se requieren dos sockets, a
los cuales se les conoce como socket local y socket remoto. La comunicacin a travs de
una conexin de sockets es bidireccional.














SOCKETS.
Aparecieron en 1981 en UNIX BSD 4.2
Intento de incluir TCP/IP en UNIX.
Diseo independiente del protocolo de comunicacin.
Un socket es punto final de comunicacin (direccin IP y puerto).


Abstraccin que:
Ofrece interfaz de acceso a los servicios de red en el nivel de transporte.
Representa un extremo de una comunicacin bidireccional con una direccin asociada.

Actualmente:
Disponibles en casi todos los sistemas UNIX.
En prcticamente todos los sistemas operativos:
WinSock: API de sockets de Windows.
En Java como clase nativa.

Conceptos bsicos sobre sockets.

Dominios de comunicacin.
Tipos de sockets.
Direcciones de sockets.
Creacin de un socket.
Asignacin de direcciones.
Solicitud de conexin.
Preparar para aceptar conexiones.
Aceptar una conexin.
Transferencia de datos.
Cerrar la conexin.
Dominios de comunicacin.
Un dominio representa una familia de protocolos.
Un socket est asociado a un dominio desde su creacin.
Slo se pueden comunicar sockets del mismo dominio.
Los servicios de sockets son independientes del dominio.

Algunos ejemplos:
PF_UNIX(o PF_LOCAL): comunicacin dentro de una mquina.
PF_INET: comunicacin usando protocolos TCP/IP.

Tipos de sockets.
Stream (SOCK_STREAM):
Orientado a conexin.
Fiable, se asegura el orden de entrega de mensajes.
No mantiene separacin entre mensajes.
Si PF_INETse corresponde con el protocolo TCP.

Datagram (SOCK_DGRAM):
Sin conexin.
No fiable, no se asegura el orden en la entrega.
Mantiene la separacin entre mensajes.
Si PF_INETse corresponde con el protocolo UDP.

Raw (SOCK_RAW):
Permite el acceso a los protocolos internos como IP.

Direcciones de sockets.
Cada socket debe tener asignada una direccin nica.
Dependientes del dominio.

Las direcciones se usan para:
Asignar una direccin local a un socket (bind).
Especificar una direccin remota (connecto sendto).

Se utiliza la estructura genrica de direccin:
struct sockaddr mi_dir;

Cada dominio usa una estructura especfica.
Uso de cast en las llamadas.
Direcciones en PF_INET(struct sockaddr_in).
Direcciones en PF_UNIX(struct sockaddr_un).

Direcciones de sockets en PF_INET.
Una direccin destino viene determinada por:
Direccin del host: 32 bits.
Puerto de servicio: 16 bits.

Estructura struct sockaddr_in:
Debe iniciarse a 0 (bzero).
sin_family: dominio (AF_INET).
sin_port: puerto.
sin_addr: direccin del host.

Una transmisin est caracterizada por cinco parmetros nicos:
Direccin host y puerto origen.
Direccin host y puerto destino.
Protocolo de transporte (UDP o TCP).


Obtencin de la direccin del host.
Usuarios manejan direcciones en forma de texto:
decimal-punto: 138.100.8.100
dominio-punto: laurel.datsi.fi.upm.es
Conversin a binario desde decimal-punto:
int inet_aton(char *str,struct in_addr *dir)
o str: contiene la cadena a convertir.
o dir: resultado de la conversin en formato de red.
Conversin a binario desde dominio-punto:
struct hostent *gethostbyname(char *str)
o str: cadena a convertir.
o Devuelve la estructura que describe al host.

Creacin de un socket.
La funcin socket crea uno nuevo:

int socket(int dom,int tipo,int proto)
Devuelve un descriptor de fichero (igual que un open de fichero).
Dominio (dom): PF_XXX
Tipo de socket (tipo): SOCK_XXX
Protocolo (proto): Dependiente del dominio y del tipo:
o 0 elige el ms adecuado.
o Especificados en /etc/protocols.
El socket creado no tiene direccin asignada.

Asignacin de direcciones.
La asignacin de una direccin a un socket ya creado:
int bind(int s,struct sockaddr* dir,int tam)
Socket (s): Ya debe estar creado.
Direccin a asignar (dir): Estructura dependiendo del dominio.
Tamao de la direccin (tam): sizeof().
Si no se asigna direccin (tpico en clientes) se le asigna automticamente (puerto efmero)
en la primera utilizacin
(connect o sendto).


Asignacin de direcciones (PF_INET).
Direcciones en dominio PF_INET
Puertos en rango 0..65535.
Reservados: 0..1023.
Si se le indica el 0, el sistema elige uno.
Host: una direccin IP de la mquina local.
o INADDR_ANY: elige cualquiera de la mquina.
Si el puerto solicitado est ya asignado la funcin bind devuelve un valor negativo.
El espacio de puertos para streams (TCP) y datagramas (UDP) es independiente.

Solicitud de conexin.
Realizada en el cliente por medio de la funcin:

int connect(int s,struct sockaddr* d,int tam)
Socket creado (s).
Direccin del servidor (d).
Tamao de la direccin (tam).
Si el cliente no ha asignado direccin al socket, se le asigna una automticamente.
Normalmente se usa con streams.

Preparar para aceptar conexiones.

Realizada en el servidor stream despus de haber creado (socket) y reservado direccin
(bind) para el socket:

int listen(int sd, int baklog)
Socket (sd): Descriptor de uso del socket.
Tamao del buffer (backlog): Nmero mximo de peticiones pendientes de aceptar
que se encolarn (algunos manuales recomiendan 5)
Hace que el socket quede preparado para aceptar conexiones.

Aceptar una conexin.
Realizada en el servidor stream despus de haber preparado la conexin (listen):

int accept(int s,struct sockaddr *d,int *tam)
Socket (sd): Descriptor de uso del socket.
Direccin del cliente (d): Direccin del socket del cliente devuelta.
Tamao de la direccin (tam): Parmetor valor-resultado
o Antes de la llamada: tamao de dir
o Despus de la llamada: tamao de la direccin del cliente que se devuelve.

La semntica de la funcin accept es la siguiente:
Cuando se produce la conexin, el servidor obtiene:
La direccin del socket del cliente.
Un nuevo descriptor (socket) que queda conectado al socket del cliente.
Despus de la conexin quedan activos dos sockets en el servidor:
El original para aceptar nuevas conexiones.
El nuevo para enviar/recibir datos por la conexin establecida.
Idealmente se pueden plantear servidores multithread para servicio concurrente.


Transferencia de datos con streams.
Envo:
Puede usarse la llamada write sobre el descriptor de socket.
int send(int s,char *mem,int tam,int flags)
Devuelve el n de bytes enviados.
Recepcin:
Puede usarse la llamada read sobre el descriptor de socket.
int recv(int s,char *mem,int tam,int flags)
Devuelve el n de bytes recibidos.

Los flags implican aspectos avanzado como enviar o recibir datos urgentes (out-of-band).

Cerrar la conexin:
Para cerrar ambos tipos de sockets: close().
Si el socket es de tipo stream cierra la conexin en ambos sentidos.
Para cerrar un nico extremo: shutdown().


Escenario de uso de sockets streams.







Escenario de uso de sockets datagrama.

















3.2 Objetos distribuidos.

Tecnologas orientadas a los objetos distribuidos:
Las tres tecnologas importantes y ms usadas en este mbito son:

1.- RMI.- Remote Invocation Method.- Fue el primer framework para crear sistemas
distribuidos de Java. El sistema de Invocacin Remota de Mtodos (RMI) de Java permite, a
un objeto que se est ejecutando en una Mquina Virtual Java (VM), llamar a mtodos de
otro objeto que est en otra VM diferente. Esta tecnologa est asociada al lenguaje de
programacin Java, es decir, que permite la comunicacin entre objetos creados en este
lenguaje.

2. CORBA. - Common Object Request Broker Architecture.- Tecnologa introducida por el
Grupo de Administracin de Objetos OMG, creada para establecer una plataforma para la
gestin de objetos remotos independiente del lenguaje de programacin.

3. DCOM. - Distributed Component Object Model. - El Modelo de Objeto Componente
Distribuido, est incluido en los sistemas operativos de Microsoft. Es un juego de conceptos
e interfaces de programa, en el cual los objetos de programa del cliente, pueden solicitar
servicios de objetos de programa servidores en otras computadoras dentro de una red. Esta
tecnologa est asociada a la plataforma de productos Microsoft.












3.2.1 RMI (Remote Method Invocate).
Remote Method Invocation (RMI) de Java es un modelo de objetos distribuidos para
desarrollar aplicaciones complejas y robustas.

Java RMI es una extensin al modelo de objetos de Java para soportar objetos distribuidos.

Serializacin.
Consiste en convertir un objeto en un stream de bytes para ser trasmitido por una red.
En Java los tipos primitivos son serializables por defecto.

Si se trata de un objeto.
1. La clase debe implementar la interfaz Serializable.
2. Se debe generar un serialVersionUID.
3. Los atributos del objeto que se desea serializar deben ser de tipo primitivo o de tipo
Serializable.
4. Asegurarse que la superclase del objeto a serializar es una clase serializada.
5. Redefinir los mtodos equals() y hashcode().

Arquitectura de Java RMI.









Objetivos de Java RMI.

Transparencia.
Orientado a objetos.
Facilidad.
Mantenimiento.
Seguridad.
Portabilidad.
Robustez.
Versatilidad.









Registro de Objetos.
Cualquier programa que quiera instanciar un objeto de esta clase debe realizar el registro
con el servicio de nombrado de la siguiente forma:

Cuenta mi_cuenta = (Cuenta)Naming.lookup("rmi://"+host+"/"+mi_cuenta");

Antes de arrancar el cliente y el servidor, se debe arrancar el programa rmiregistry en el
servidor para el servicio de nombres.




Caractersticas.

Concurrencia.
Para cada cliente que trate de acceder a un objeto remoto, el servidor crear un nuevo hilo
que se encargar de darle servicio.


Nombrado de objetos.
o Utiliza la notacin URL. Por Ejemplo: rmi://localhost:8080/miObjeto.
o Adicionalmente se cuenta con el servidor de nombres rmiRegistry.

Paso de parmetros.
o La Serializacin se encarga de informar al compilador y al entorno de ejecucin de
Java que deber pasar por valor copias de los objetos de este tipo desde la JVM local
a la JVM remota.

En una invocacin a un mtodo de un objeto remoto puede contar con los
siguientes parmetros
o Primitivos.
o Serializados.
o Objetos remotos.

Recolector de basura.
o En los sistemas distribuidos, las referencias a los objetos son ms complejas y de mayor
tamao que en un entorno local.
o Una referencia a un objeto remoto indica la localizacin del objeto, datos sobre el tipo del
objeto e informacin de seguridad.





Desarrollo de Aplicaciones RMI.


Definicin de la
interfaz remota
javac
(.java)
1
2
3
4
10
9
5
6
7
8
(.java)
usa
Cliente
Ejectuar
Cliente
(.class)
CLIENTE
SERVIDOR
(.class)
Esqueleto
(.class)
Implementacin de la
interfaz remota
Esqueleto
(.class)
Servidor
(.class)
Arrancar RMIRegistry
Crear los objetos
Registrar los objetos
javac
rmic
























































3.2.2 CORBA (Common Object Resource Broker Architecture) [OMG, 1991]).
CORBA es un middeware o marco de trabajo estndar y abierto de objetos distribuidos que
permite a los componentes en la red nter operar en un ambiente comn sin importar el
lenguaje de desarrollo, sistema operacional, tipo de red, etc.

En esta arquitectura, los mtodos de un objeto remoto pueden ser invocados de forma
transparente en un ambiente distribuido y heterogneo a travs de un ORB (Object Request
Broker).

Adems del objetivo bsico de ejecutar simplemente mtodos en objetos remotos, CORBA
adiciona un conjunto de servicios que amplan las potencialidades de stos objetos y
conforman una infraestructura slida para el desarrollo de aplicaciones crticas de negocio.

CORBA permite el desarrollo de software para entornos distribuidos heterogneos separando
la especificacin de las aplicaciones de su implementacin.


OMG.
(Object Management Group)
Conjunto de organizaciones que cooperan en la definicin de estndares para la
interoperabilidad en entornos heterogneos.
Fundado en 1989, en la actualidad lo componen ms de 800 empresas y otros organismos.
OMA.
(Object Management Architecture)
Arquitectura de referencia sobre la cual se pueden definir aplicaciones distribuidas sobre un
entorno heterogneo. CORBA es la tecnologa asociada a esta arquitectura genrica.
Formalmente est dividida en una serie de modelos:
Modelo de Objetos
Modelo de Interaccin
...
Una aplicacin definida sobre OMA est compuesta por una serie de objetos distribuidos que
cooperan entre s. Estos objetos se clasifican en los siguientes grupos:




Servicios:
Proporcionan funciones elementales necesarias para cualquier tipo de entorno
distribuido, independientemente del entorno de aplicacin.
Los tipos de funciones proporcionados son cuestiones tales como la resolucin de
nombres, la notificacin asncrona de eventos o la creacin y migracin de objetos.
Concede un valor aadido sobre otras tecnologas (por ejemplo RMI).
Estn pensados para grandes sistemas.

Facilidades Comunes:
Proporcionan funciones, al igual que los servicios vlidos para varios dominios pero
ms complejos. Estn orientadas a usuarios finales (no al desarrollo de aplicaciones).
Un ejemplo de este tipo de funciones es el DDCF (Distributed Document Component
Facility) formato de documentacin basado en OpenDoc.
(Tambin denominadas Facilidades Horizontales)

Interfaces de Dominio:
Proporcionan funciones complejas, al igual que las Facilidades, pero restringidas a
campos de aplicacin muy concretos. Por ejemplo, telecomunicaciones, aplicaciones
mdicas o financieras, etc.
Muchos grupos de inters (SIGs) trabajan sobre estas especificaciones.
(Tambin denominadas Facilidades Verticales)

Aplicaciones:
El resto de funciones requeridas por una aplicacin en concreto. Es el nico grupo de
objetos que OMG no define, pues est compuesto por los objetos propios de cada
caso concreto.
Estos son los objetos que un sistema concreto tiene que desarrollar. El resto
(servicios, facilidades) pueden venir dentro del entorno de desarrollo.

ORB:
(Object Request Broker)
Es el elemento central de la arquitectura. Proporciona las funcionalidades de
interconexin entre los objetos distribuidos (servicios, facilidades y objetos de
aplicacin) que forman una aplicacin.
Representa un bus de comunicacin entre objetos.

Para posibilitar la comunicacin entre dos objetos cualesquiera de una aplicacin se realiza
por medio del ORB. El escenario de aplicacin elemental es:



El ORB funciona como una capa middleware.
El ORB redirige las peticiones al objeto apropiado que proporciona el servicio solicitado.


El ORB acta como mediador de objetos heterogneos

IDL de CORBA.
(Interface Definition Language).
Es el lenguaje mediante el cual se describen los mtodos que un determinado objeto del
entorno proporciona al resto de elementos del mismo.

interface Cuenta
{
void ingresar(in long cantidad);
void retirar(in long cantidad);
long balance();
};

Language Mappings:
Traducen la definicin IDL a un lenguaje de programacin como:
C++,
Ada,
COBOL,
SmallTalk,
Java,
...

Este proceso genera dos fragmentos de cdigo denominados Stub y Skeleton que
representan el cdigo de cliente y servidor respectivamente.

El cdigo cliente generado en base a la definicin IDL (stub) contiene las llamadas para
realizar el proceso de marshalling.
Marshalling: Traduccin de los argumentos a un formato intermedio y pedir al ORB su
ejecucin.


El cdigo servidor generado en base a la definicin IDL (skeleton) contiene las llamadas para
realizar el proceso inverso (de-marshalling).
De-marshalling: Recuperar del ORB los parmetros con los que se invoc el mtodo,
construir la llamada y realizar la peticin.



Implementacin del Objeto:
La implementacin del objeto es invocada por los mtodos definidos en el Skeleton.
Por lo general se trata de una clase derivada del mismo.

class Cuenta_Impl: public Cuenta_Skel
{
void ingresar(CORBA::Long &cantidad)
{
dinero += cantidad;
}
};

COMPONENTES DE UN ORB.

La arquitectura completa de comunicaciones de CORBA es la siguiente:



Stub:
Cdigo cliente asociado al objeto remoto con el que se desea interactuar. Simula para
el cliente los mtodos del objeto remoto, asociando a cada uno de los mtodos una
serie de funciones que realizan la comunicacin con el objeto servidor.
Skeleton:
Cdigo servidor asociado al objeto. Representa el elemento anlogo al stub del
cliente. Se encarga de simular la peticin remota del cliente como una peticin local a
la implementacin real del objeto.

DII (Dynamic Invocation Interface).
Alternativa al uso de stubs estticos que permite que un cliente solicite peticiones a
servidores cuyas interfaces se desconocan en fase de compilacin.
DSI (Dynamic Skeleton Interface).
Alternativa dinmica al uso de skeletons estticos definidos en tiempo de compilacin
del objeto. Es usado por servidores que durante su ejecucin pueden arrancar
diferentes objetos que pueden ser desconocidos cuando se compil el servidor.

ORB/Interface ORB:
Elemento encargado de (entre otras) las tareas asociadas a la interconexin entre la
computadora cliente y servidor, de forma independiente de las arquitecturas hardware
y Software.
Debido a que tanto clientes como servidores pueden requerir de ciertas
funcionalidades del ORB, ambos son capaces de acceder a las mismas por medio de
un interfaz.

Las dos principales responsabilidades del ORB son:
Localizacin de objetos: El cliente desconoce la computadora donde se encuentra
el objeto remoto.
Comunicacin entre cliente y servidor: De forma independiente de protocolos de
comunicacin o caractersticas de implementacin (lenguaje, sistema operativo, ...)

Adaptador de Objetos:
En este elemento se registran todos los objetos que sirven en un determinado nodo.
Es el encargado de mantener todas las referencias de los objetos que sirven en una
determinada computadora de forma que cuando llega una peticin a un mtodo es
capaz de redirigirla al cdigo del skeleton adecuado.

Existen dos tipos de Adaptadores de Objetos especificados por OMG:
BOA: (Basic Object Adapter).
POA: (Portable Object Adapter).

Las principales tareas del Adaptador de Objetos son:
Multiplexar a dos niveles (objeto y mtodo) las llamadas.
Mantiene informacin (almacenada en el Repositorio de Implementaciones) sobre los
objetos servidos, siendo el encargado de activarlos si al llegar una peticin no se
encontraban en ejecucin.
Permite diferente modos de activacin de los objetos:
Persistente: El estado del objeto se almacena entre varias ejecuciones.
Compartido: Todos los clientes comparten la instancia de objeto.
No-compartido: Cada cliente accede a una instancia diferente del objeto.
Por-mtodo: Cada mtodo solicitado es servido por una instancia de objeto
diferente.
Genera las referencias de los objetos dentro del entorno. Esta referencia es nica
para todos los objetos.


COMUNICACIN VA CORBA.
Pasos de una comunicacin:
1- El cliente invoca el mtodo asociado en el stub que realiza el proceso de marshalling.
(Stub cliente)
2- El stub solicita del ORB la transmisin de la peticin hacia el objeto servidor. (ORB cliente)
3- El ORB del servidor toma la peticin y la transmite el Adaptador de Objetos asociado, por
lo general slo hay uno. (ORB servidor).
4- El Adaptador de Objetos resuelve cul es el objeto invocado, y dentro de dicho objeto cul
es el mtodo solicitado (Adaptador de Objetos).
5- El skeleton del servidor realiza el proceso de de-marshalling de los argumentos e invoca a
la implementacin del objeto. (Skeleton servidor).
6- La implementacin del objeto se ejecuta y los resultados y/o parmetros de salida se
retornan al skeleton. (Implementacin del objeto).
7- El proceso de retorno de los resultados es anlogo.




IMPLEMENTACIN DE UN ORB.
El ORB representa a nivel lgico el bus de objetos que comparten tanto clientes como
servidores. A nivel prctico puede estar implementado como:
Residente cliente/servidor: Cdigo que tanto clientes como objetos tiene que enlazar.
Demonio del sistema: Un servicio del sistema encargado de centralizar las peticiones.
Interno al sistema: Integrado dentro del SO.
Librera: Usado cuando tanto clientes como servidores residen dentro del mismo
espacio de memoria.

LOCALIZACIN DE OBJETOS.
Los objetos de servicio de una aplicacin CORBA se encuentran identificados por
medio de una referencia nica (Identificador de Objeto).
Esta referencia es generada al activar un objeto en el Adaptador de Objetos.
Por medio de esta referencia el ORB es capaz de localizar la computadora y el
Adaptador de Objetos donde se encuentra, y ste ltimo es capaz de identificar el
objeto concreto dentro del Adaptador.

El ORB proporciona mecanismos para transformar a cadena de caracteres y de cadena de
caracteres a dicha referencia:
object_to_string, string_to_object
Ejemplo:
IOR:010000000f00000049444c3a4375656e74613a312e30000002000000000000003000000
001010000160000007175696e6f2e64617473692e66692e75706d2e65730041040c00000042
4f418a640965000009f40301000000240000000100000001000000010000001400000001000
00001000100000000000901010000000000

IMPLEMENTACIN DEL SERVIDOR.
La implementacin del objeto se disea como una subclase de la clase generada por el
compilador (el skeleton) de IDL en base a la definicin.
Si el lenguaje usado para la implementacin no soporta objetos el mecanismo es diferente.


Tareas Tpicas de un Servidor.
El servidor debe realizar las siguientes tareas:

Inicializar el ORB (obtiene el interfaz con el ORB).
CORBA::ORB_init
Obtener la referencia del Adaptador de objetos.
orb->BOA_init
Crear un un objeto (de la clase Cuenta_impl).
new Cuenta_impl()
Activar el objeto.
boa->impl_is_ready(...)
Iniciar el bucle de servicio.
orb->run()

Tareas Tpicas de un Cliente.

El cliente debe realizar las siguientes tareas:
Inicializar el ORB (obtiene el interfaz con el ORB).
CORBA::ORB_init
Obtener la referencia del Adaptador de objetos.
orb->BOA_init
Obtener la referencia al objeto (desde un string).
orb->string_to_object(...)
Cambiar la clase del objeto obtenido (down-casting).
Cuenta::_narrow(obj)
Realizar las llamadas al objeto.
cc->...

Servicios CORBA.
Conjunto de objetos o grupos de objetos, que proporcionan una serie de funcionalidades
elementales. Estos objetos estn definidos de forma estndar (interfaces IDL concretos).
Sus especificaciones se encuentran recogidas en los documentos COSS (Common
Object Services Specifications).
Los servicios definidos son:







Servicio de Nombres
Servicio de Eventos
Servicio de Ciclo de Vida
Servicio de Objetos Persistentes
Servicio de Transacciones
Servicio de Control de Concurrencia
Servicio de Relacin
Servicio de Externalizacin

Servicio de Consulta
Servicio de Licencias
Servicio de Propiedad
Servicio de Tiempo
Servicio de Seguridad
Servicio de Negociacin
Servicio de Coleccin de Objetos

IIOP: Protocolo para la comunicacin entre ORBs a travs de TCP/IP. El ORB se comunica a
travs de IIOP sin intervencin del desarrollador.

GIOP: En computacin distribuida, GIOP (Protocolo Entre ORBs General, General Inter-ORB
Protocol) es el protocolo abstracto por el cual los ORBs se comunican.

IIOP (Internet Inter-Orb Protocol) es la implementacin de GIOP para TCP/IP. Es una
realizacin concreta de las definiciones abstractas de GIOP.

El Object Management Group define tres partes en GIOP:

La Representacin Comn de Datos (CDR) - es una sintaxis de transferencia, que
mapea los tipos de datos de IDL en una representacin de bajo nivel para su
transferencia "por el hilo" entre ORBs.

La Referencia de Objetos Interoperable (IOR) -define el formato de una referencia a
un objeto remoto. Una IOR consiste en varios perfiles etiquetados, y sus componentes
pueden llevar diversa informacin segn se necesite. La IOR tpica habitualmente
contiene la versin del protocolo, la direccin del servidor y una secuencia de octetos
que identifica al objeto remoto (clave del objeto).

Los formatos de mensaje definidos - los mensajes se intercambian entre agentes
para facilitar las peticiones de objetos, localizar implementaciones de objetos y
gestionar los canales de comunicacin.







Cuestionario.
Qu problema la OMG est probando para resolver con CORBA?
Por qu la orientacin a objetos ayuda a resolver el problema de heterogeneidad?
Qu patrones de invocacin de objetos soporta CORBA?
Cul es la diferencia entre estilos de invocacin sncrono y asincrnicos?
Qu es IDL y su utilidad?
Qu son los stubs y cmo se usan?
Qu son los skeletons y cmo se usan?
Cul es la diferencia entre la invocacin esttica y dinmica y cmo se soportan tanto en
lado del cliente como del servidor?
Qu es un almacn de la interfaz?
Qu es un adaptador del objeto?
Cmo trabaja el registro del objeto y referencia del objeto?
Cul es la diferencia entre el adaptador del objeto y el skeleton?
Qu realiza un Adaptador del Objeto Porttil (POA)?
Qu es la activacin / desactivacin?
Qu es un objeto persistente?
Qu es un objeto transente?
Cul es la diferencia entre la llamada por referencia y llamada por valor?
Cmo la interoperabilidad del inter -orb se soporta?
Cul es la diferencia entre GIOP e IIOP?
Qu transparencias proporciona CORBA?





3.2.3 COM/DCOM.
Un ejemplo de la evolucin de los sistemas de comunicaciones dentro de la misma empresa
es el caso de Microsoft, donde se ha ido evolucionando desde un modelo sin soporte a la
distribucin basado en el paso de mensajes hasta un modelo de distribucin de
componentes. En la figura, se puede ver cmo cada modelo ha ido progresando, en paralelo
con los intentos de estandarizacin en los que Microsoft participaba.



El sistema inicial de comunicaciones del que parten los sistemas operativos de Microsoft es
el DDE (Dynamic Data Exchange) consistente en el paso de mensajes entre aplicaciones en
forma de mensajes, lo que implica el mantenimiento de un servidor DDE. Algunas
aplicaciones continan emplendolo, aunque normalmente ya no se emplea ya que
cualquiera de las tecnologas posteriores proporciona mejores prestaciones. Para el soporte
de sistemas distribuidos hay una versin llamada NetDDE que no es ms que el uso de
comandos DDE sobre las tecnologas posteriores.

El siguiente paso en la comunicacin de procesos es la tecnologa OLE (Object Linking and
Embedding), los cambios que incluye con respecto a DDE son el uso de la tecnologa de
objetos, la posibilidad de mantener dinmicamente los enlaces entre aplicaciones y el uso del
concepto de incrustar objetos dentro de otra aplicacin con la posibilidad de intercambiar
informacin con el origen de forma dinmica. En 1996 la versin 2 de OLE pasa a llamarse
ActiveX orientndola tecnologa al mbito concreto de la Web.
La evolucin de OLE, aunque paralela a ActiveX, pas a llamarse COM (Component Object
Model) en la que se ofrece una interfaz independiente del lenguaje de programacin para la
comunicacin de diferentes objetos. La independencia del modelo se logra por medio de una
interfaz comn y de un conjunto de criterios comunes a la hora de programar componentes
COM. La extensin de COM a un sistema distribuido, de forma oficial, aunque oficiosamente
ya exista con ActiveX, se llam DCOM (Distributed Component Object Model). DCOM aade
caractersticas de DCE al modelo COM en cuanto a la serializacin de informacin y
recoleccin de basura en el sistema distribuido. Cabe destacar que DCOM no es en s mismo
una tecnologa de Microsoft, sino un modelo que tambin han desarrollado otras compaas,
por ejemplo Open Group tiene una implementacin llamada COMsource; Microsoft cumple
con el Sistemas de comunicaciones modelo sin cambiarle el nombre, lo que hace que
formalmente sea recomendable llamarlo Microsoft DCOM.

Actualmente Microsoft tiene como modelo de sistema distribuido el .NET. Esto ha aadido
algo de confusin ya que tambin denomina por ese nombre el Framework para el
funcionamiento de la mayor parte de las aplicaciones desarrolladas para Windows XP y
posteriores. El impulso que se le da al lenguaje C# ha hecho que tambin se llame .NET a
dicho lenguaje. En cuanto a modelos de comunicacin distribuida, .NET no es ms que la
evolucin de DCOM y ActiveX uniendo a todo el sistema y aadiendo los servicios Web al
modelo. Adems emplea XML como norma en el formato de los mensajes, lo que supone un
gran avance hacia los sistemas abiertos con semntica autocontenida. Formalmente no se
puede considerar .NET como un modelo de comunicaciones ya que es algo mucho ms
extenso.







3.3 Sncrona y Asncrona.
Sncrona
Quien enva permanece bloqueado esperando a que llegue una respuesta del receptor antes
de realizar cualquier otro ejercicio.

Este tipo de transmisin se caracteriza porque antes de la transmisin depropia de datos, se
envan seales para la identificacin de lo que va a venir por la lnea, es mucho mas eficiente
que la Asncrona pero su uso se limita a lneas especiales para la comunicacin de
ordenadores, porque en lneas telefnicas deficientes pueden aparecer problemas.

Asncrona
Quien enva contina con su ejecucin inmediatamente despus de enviar el mensaje al
receptor.

Esta se desarroll para solucionar el problema de la sincrona y laincomodidad de los
equipos.En este caso la temporizacin empieza al comienzo de un carcter ytermina al final,
se aaden dos elementos de seal a cada carcter para indicar al dispositivo receptor el
comienzo de este y su terminacin.


3.4 Consideraciones de Seguridad.


3.5 Opciones tecnolgicas (WCF, ASMX, etc.)