Unidad III Comunicacion

8/12/2019 Unidad III Comunicacion

1/49

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


2/49

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 dosoperaciones 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


3/49

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.


4/49

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.

Transfe rencia de datos.

Cerrar la conexin.


5/49

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


6/49

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:


7/49

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


8/49

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.


9/49

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.


10/49

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.


11/49

Escenario de uso de sockets datagrama.


12/49

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 sistemasdistribuidos 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 elGrupo 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 ComponenteDistribuido, 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.


13/49

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.


14/49


15/49

Objetivos de Java RMI.

Transparencia.

Orientado a objetos.

Facilidad.

Mantenimiento.

Seguridad.

Portabilidad.

Robustez.

Versatilidad.


16/49


17/49


18/49

Registro de Objetos.

Cualquier programa que quiera instanciar un objeto de esta clase debe realizar el registrocon el servicio de nombrado de la siguiente forma:

Cuenta mi_cuenta = (Cuenta)Na ming.lookup("rmi://"+host+"/"+m i_cuenta");

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


19/49

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 lossiguientes parmetroso 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.


20/49

Desarrollo de Aplicaciones RMI.

Definicin de lainterfaz remota

javac

(.java)

1

2

3

4

10

95

6

7

8

(.java)

usaCliente

Ejectuar

Cliente

(.class)

CLIENTE SERVIDOR

(.class)

Esqueleto(.class)

Implementacin de lainterfaz remota

Esqueleto(.class)

Servidor (.class)

Arrancar RMIRegistry

Crear los objetos

Registrar los objetos

javac

rmic


21/49


22/49


23/49


24/49


25/49


26/49


27/49


28/49


29/49


30/49


31/49


32/49


33/49

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 e jecutar 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 lainteroperabilidad en entornos heterogneos.

Fundado en 1989, en la actualidad lo componen ms de 800 empresas y otros organismos.


34/49

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 entornodistribuido, 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 peroms complejos. Estn orientadas a usuarios finales (no al desarrollo de aplicaciones).


35/49

Un ejemplo de este tipo de funciones es el DDCF ( Distributed Document ComponentFacility ) formato de documentacin basado en OpenDoc.

(Tambin denominadas Facilidades Horizontales )

Interfaces de Dominio:

Proporcionan funciones complejas, al igual que las Facilidades, pero restringidas acampos de aplicacin muy concretos. Por ejemplo, telecomunicaciones, aplicacionesmdicas 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 deobjetos que OMG no define, pues est compuesto por los objetos propios de cadacaso 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 deinterconexin entre los objetos distribuidos (servicios, facilidades y objetos deaplicacin) 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:


36/49

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 Definit ion Language ).

Es el lenguaje mediante el cual se describen los mtodos que un determinado objeto delentorno proporciona al resto de elementos del mismo.

interface Cuenta {

void ingresar(in long cantidad);

void retirar(in long cantidad);

long balance();

};


37/49

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 querepresentan el cdigo de cliente y servidor respectivamente.

El cdigo cliente generado en base a la definicin IDL ( stub ) contiene las llamadas pararealizar el proceso de marshalling .

Marshalling : Traduccin de los argumentos a un formato intermedio y pedir al ORB suejecucin.


38/49


39/49

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 parael cliente los mtodos del objeto remoto, asociando a cada uno de los mtodos unaserie de funciones que realizan la comunicacin con el objeto servidor.

Skeleton:

Cdigo servidor asociado al objeto. Representa el elemento anlogo al stub delcliente. Se encarga de simular la peticin remota del cliente como una peticin local ala implementacin real del objeto.

DII (Dynamic Invocation Interface).

Alternativa al uso de stubs estticos que permite que un cliente solicite peticiones aservidores cuyas interfaces se desconocan en fase de compilacin.


40/49

DSI (Dynam ic Skeleton Interface ).

Alternativa dinmica al uso de skeletons estticos definidos en tiempo de compilacindel objeto. Es usado por servidores que durante su ejecucin pueden arrancardiferentes 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 lacomputadora cliente y servidor, de forma independiente de las arquitecturas hardwarey Software.

Debido a que tanto clientes como servidores pueden requerir de ciertasfuncionalidades del ORB, ambos son capaces de acceder a las mismas por medio deun interfaz.

Las dos principales responsabilidades del ORB son:

Localizacin de objetos: El cliente desconoce la computadora donde se encuentrael objeto remoto.

Comunicacin entre cliente y servidor: De forma independiente de protocolos decomunicacin 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 unadeterminada computadora de forma que cuando llega una peticin a un mtodo escapaz 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.


41/49

Mantiene informacin (almacenada en el Repositorio de Implementaciones) sobre losobjetos servidos, siendo el encargado de activarlos si al llegar una peticin no seencontraban 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 nicapara 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, porlo general slo hay uno. (ORB servidor).

4- El Adaptador de Objetos resuelve cul es el objeto invocado, y dentro de dicho objeto cules el mtodo solicitado (Adaptador de Objetos).

5- El skeleton del servidor realiza el proceso de de-marshalling de los argumentos e invoca ala implementacin del objeto. (Skeleton servidor).

6- La implementacin del objeto se ejecuta y los resultados y/o parmetros de salida seretornan al skeleton. (Implementacin del objeto).

7- El proceso de retorno de los resultados es anlogo.


42/49

IMPLEMENTACIN DE UN ORB.El ORB representa a nivel lgico el bus de objetos que comparten tanto clientes comoservidores. 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 mismoespacio de memoria.

LOCALIZACIN DE OBJETOS.

Los objetos de servicio de una aplicacin CORBA se encuentran identificados pormedio 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 elobjeto concreto dentro del Adaptador.

El ORB proporciona mecanismos para transformar a cadena de caracteres y de cadena decaracteres a dicha referencia:

object_to_string, string_to_object


43/49

Ejemplo:

IOR:010000000f00000049444c3a4375656e74613a312e30000002000000000000003000000001010000160000007175696e6f2e64617473692e66692e75706d2e65730041040c000000424f418a640965000009f4030100000024000000010000000100000001000000140000000100000001000100000000000901010000000000

IMPLEMENTACIN DEL SERVIDOR.

La implementacin del objeto se disea como una subclase de la clase generada por elcompilador (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.


44/49

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 funcionalidadeselementales. Estos objetos estn definidos de forma estndar (interfaces IDL concretos).

Sus especificaciones se encuentran recogidas en los documentos COSS (CommonObject 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


45/49

IIOP: Protocolo para la comunicacin entre ORBs a travs de TCP/IP. El ORB se comunica atravs 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 unarealizacin 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, quemapea 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 aun 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 agentespara facilitar las peticiones de objetos, localizar implementaciones de objetos y

gestionar los canales de comunicacin.


46/49

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?


47/49

3.2.3 COM/DCOM.

Un ejemplo de la evolucin de los sistemas de comunicaciones dentro de la misma empresaes el caso de Microsoft, donde se ha ido evolucionando desde un modelo sin soporte a ladistribucin basado en el paso de mensajes hasta un modelo de distribucin decomponentes. 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


48/49

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 unainterfaz 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 laevolucin 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.


49/49

3.3 Sncrona y Asncrona.

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

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

Unidad III Comunicacion

Documents

Transcript of Unidad III Comunicacion