Está en la página 1de 29

Tecnolgico Nacional de

Mxico
Campus Pachuca
El Hombre Alimenta el Ingenio
en Contacto con la Ciencia.

Sistemas Distribuidos 1
Materia

Lic. Gutirrez Madrigal Jos Luis


Docente

Comunicacin
Unidad 3

ALUMNO NO. CONTROL


Bautista Hernndez Pablo 12200594

Ingeniera en Sistemas Computacionales


Enero - Julio 2017
3 COMUNICACIN
La comunicacin entre procesos en sistemas con un nico procesador se
lleva a cabo mediante el uso de memoria compartida entre los procesos.
En los sistemas distribuidos, al no haber conexin fsica entre las
distintas memorias de los equipos, la comunicacin se realiza mediante
la transferencia de mensajes.

Comunicacin Cliente-Servidor

Sockets
Es un mecanismo de comunicacin, Permite a los sistemas
cliente/servidor ser desarrollados Localmente en una sola mquina A
travs de redes. Funciones tales como impresin, utileras de red, tales
como login y ftp, usualmente usan sockets para comunicarse.

Socket designa un concepto abstracto por el cual dos programas


(posiblemente situados en computadoras distintas) pueden
intercambiarse cualquier flujo de datos, generalmente de manera fiable
y ordenada.

Un socket queda definido por una direccin IP, un protocolo y un nmero


de puerto.

Explicacin detallada
Para que dos programas puedan comunicarse entre s es necesario que
se cumplan ciertos requisitos:

Que un programa sea capaz de localizar al otro.


Que ambos programas sean capaces de intercambiarse cualquier
secuencia de octetos, es decir, datos relevantes a su finalidad.

Para ello son necesarios los tres recursos que originan el concepto de
socket:

Un protocolo de comunicaciones, que permite el intercambio de


octetos.
Una direccin del Protocolo de Red (Direccin IP, si se utiliza el
Protocolo TCP/IP), que identifica una computadora.
Un nmero de puerto, que identifica a un programa dentro de una
computadora.

Los sockets permiten implementar una arquitectura cliente-servidor. La


comunicacin ha de ser iniciada por uno de los programas que se
denomina programa cliente. El segundo programa espera a que otro
inicie la comunicacin, por este motivo se denomina programa servidor.

Un socket es un fichero existente en la mquina cliente y en la mquina


servidora, que sirve en ltima instancia para que el programa servidor y
el cliente lean y escriban la informacin. Esta informacin ser la
transmitida por las diferentes capas de red.

Comunicacin RPC
Otro paso en el diseo de un sistema operativo distribuido plantea las
llamadas a procedimientos remotos o RPCs. Los RPC amplan la llamada
local a procedimientos, y los generalizan a una llamada a un
procedimiento localizado en cualquier lugar de todo el sistema
distribuido. En un sistema distribuido no se debera distinguir entre
llamadas locales y RPCs, lo que favorece en gran medida la
transparencia del sistema.

Una de las dificultades ms evidentes a las que se enfrenta el RPC es el


formato de los parmetros de los procedimientos. Un ejemplo es la
posibilidad de que, en un sistema distribuido formado por diferentes
tipos de ordenadores, un ordenador con formato little endian llamara a
un procedimiento de otro ordenador con formato big endian, etc. Este
problema se podra solucionar si tenemos en cuenta que ambos
programas conocen el tipo de datos de los parmetros, o estableciendo
un estndar en el formato de los parmetros, de forma que sea usado de
forma nica.

Por ltimo, queda por solucionar la tolerancia a fallos. Una llamada a un


procedimiento remoto puede fallar por motivos que antes no existan,
como la prdida de mensajes o el fallo del cliente o del servidor durante
la ejecucin del procedimiento.
La limitacin del RPC ms clara en los sistemas distribuidos es que no
permite enviar una solicitud y recibir respuesta de varias fuentes a la
vez, sino que la comunicacin se realiza nicamente entre dos procesos.
Por motivos de tolerancia a fallos, bloqueos, u otros, sera interesante
poder tratar la comunicacin en grupo.

Comunicacin en grupo
La comunicacin en grupo tiene que permitir la definicin de grupos, as
como caractersticas propias de los grupos, como la distincin entre
grupos abiertos o que permiten el acceso y cerrados que lo limitan, o
como la distincin del tipo de jerarqua dentro del grupo. Igualmente, los
grupos han de tener operaciones relacionadas con su manejo, como la
creacin o modificacin.

Tolerancia a fallos

Que el sistema de archivos sea tolerante a fallos implica que el sistema


debe guardar varias copias del mismo archivo en distintos ordenadores
para garantizar la disponibilidad en caso de fallo del servidor original.
Adems, se ha de aplicar un algoritmo que nos permita mantener todas
las copias actualizadas de forma consistente, o un mtodo alternativo
que slo nos permita acceder al archivo actualizado, como invalidar el
resto de copias cuando en cualquiera de ellas se vaya a realizar una
operacin de escritura. El uso de memorias cache para agilizar el acceso
a los archivos tambin es recomendable, pero este caso requiere
analizar con especial atencin la consistencia del sistema.

3.1 Paso de mensajes

La aproximacin ms bsica a la comunicacin entre procesos es el paso


de mensajes. En este paradigma, los datos que representan mensajes se
intercambian entre dos procesos, un emisor y un receptor.

El paso de mensajes es el paradigma fundamental para aplicaciones


distribuidas. Un proceso enva un mensaje que representa una peticin.
El mensaje se entrega a un receptor, que procesa la peticin y enva un
mensaje como respuesta. En secuencia, la rplica puede disparar
posteriores peticiones, que lleven a sucesivas respuestas, y as en
adelante.

Las operaciones bsicas necesarias para dar soporte al paradigma de


paso de mensajes son enviar y recibir. Para comunicaciones orientadas a
conexin, tambin se necesitan las operaciones conectar y desconectar.
(Los detalles sobre las operaciones, tales como argumentos o valores de
retorno, se darn junto a las respectivas herramientas y funcionalidades
en los captulos posteriores.) Por medio del grado de abstraccin
proporcionado por este modelo, los procesos interconectados realizan la
entrada y la salida hacia el otro proceso, de una forma similar a la
utilizada en la entrada/salida (E/S) de ficheros. Como en el caso de la E/S
de ficheros, las operaciones sirven para encapsular el detalle de la
comunicacin a nivel del sistema operativo, de forma que el
programador puede hacer uso de operaciones para enviar y recibir
mensajes sin preocuparse por el detalle subyacente.

La interfaz de programacin de aplicaciones de sockets (que se


estudiar en el Captulo 4) se basa en este paradigma. Usando un
socket, una construccin lgica, dos procesos pueden intercambiarse
datos de la siguiente forma: Un emisor escribe o inserta un mensaje en
el socket; en el otro extremo, un receptor lee o extrae un mensaje del
socket.

La implementacin de nuestro sistema de subastas usando paso de


mensajes y el paradigma cliente-servidor se describir en la prxima
seccin.

Los procesos de un S.O. pueden comunicarse entre s al compartir


espacios de memoria, ya sean variables compartidas o buffers, o a
travs de las herramientas provistas por las rutinas de comunicacin de
interprocesos.
Para comunicar procesos en un ambiente distribuido, adems del uso de
un sistema de nombres de recursos, se necesita un esquema de
comunicacin lgico que d sentido a estas transacciones. El sistema
operativo provee mnimamente dos primitivas, enviar y recibir,
normalmente llamadas send y receive, pero tendr que implementar un
enlace de comunicacin entre los procesos. Este enlace puede ser
unidireccional o multidireccional segn permita la comunicacin en solo
uno o en varios sentidos, y dependiendo de la forma en que se dispara
la comunicacin.

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

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

Comunicacin Persistente.
El receptor no tiene que estar operativo al mismo tiempo que se realiza
la comunicacin, el mensaje se almacena tanto tiempo como sea
necesario para poder ser entregado.

Comunicacin Transitoria.
El mensaje se descarta si el receptor no est operativo al tiempo que se
realiza la comunicacin. Por lo tanto, no ser entregado.

Comunicacin Directa.
Las primitivas enviar y recibir usan directamente el nombre del proceso
con el que se comunican. Por ejemplo:
enviar (mensaje, A) enva un mensaje al proceso A. Obsrvese que la
primitiva slo debe especificar cul va a ser el proceso Destino, ya que
el proceso fuente viene direccionado en la comunicacin.

Las operaciones bsicas Send y Receive se definen de la siguiente


manera: Send (P, mensaje); enva un mensaje al proceso P. Receive (Q,
mensaje); espera la recepcin de un mensaje por parte del proceso Q.

Comunicacin Indirecta.
Es aquella donde la comunicacin est basada en un gateway,
enrutador, puente o switch, ya que el emisor y el receptor estn a
distancia.

Comunicacin Simtrica.
Todos los procesos pueden enviar o recibir. Tambin establece una
llamada bidireccional para el caso de dos procesos.

Comunicacin Asimtrica.
Un proceso puede enviar, los dems procesos solo reciben. Tambin
llamada unidireccional o no interactiva. Es el esquema tpico de algunos
servidores de Internet.

Comunicacin con uso de buffers automtico.


El transmisor se bloquea hasta que el receptor recibe el mensaje
completo, pero ste tiene capacidad para recibirlo, aunque no est listo
para procesarlo.

La comunicacin y sincronizacin en S.O.D. es ms compleja y se


establece en canales lentos y menos confiables que los buses internos
de una computadora, lo que incorpora problemas como la prdida de
mensajes, la llegada de datagramas desordenados, la heterogeneidad
de los nodos y su diferente rendimiento, etc.

La forma natural de comunicar y sincronizar procesos en los sistemas


distribuidos es mediante paso de mensajes; los procesos intercambian
mensajes mediante las primitivas que adems establecen una extensin
de los semforos en la que se transmite ms informacin en un contexto
sincronizado.

Una de las ventajas de emplear mecanismos de comunicacin y


sincronizacin basados en paso de mensaje es la portabilidad de las
soluciones programadas para diferentes arquitecturas de computadoras,
incluidos los sistemas con memoria compartida, otra ventaja es que no
existe el problema del acceso en exclusin mutua a datos compartidos,
ya que no hay contienda por el acceso al recurso, sino una fila en
espera.

Un sistema operativo o lenguaje de programacin podra ofrecer


herramientas, algunas basadas en memoria compartida y otras basadas
en la comunicacin mediante paso de mensajes, por lo que podramos
llegar a tener un mismo proceso o hilo que empleara las dos
posibilidades. Los siguientes son aspectos relevantes en el diseo de los
sistemas de paso de mensajes:

Identificacin en el proceso de comunicacin.


Sincronizacin.
Caractersticas del canal (capacidad, flujo de datos, etc).

3.2 Objetos distribuidos

Habitualmente, los sistemas distribuidos se han venido construyendo


utilizando conceptos utilizados en los sistemas operativos tradicionales.
El concepto de proceso y los mecanismos de comunicacin entre
procesos son los ms destacables.

En los ltimos tiempos, el auge de las tecnologas orientadas a objetos


ha llevado a los diseadores a plantearse la forma en que pueden
aplicarlas para la construccin de sistemas distribuidos. La aplicacin de
dichas tecnologas no se ha detenido en la construccin en s del
sistema distribuido, sino en la forma que ste proporciona sus servicios y
en la manera en que se construyen las aplicaciones de usuario.

El problema que surge inmediatamente es cmo construir el sistema


distribuido para que cubra dichas expectativas. La construccin se
deber realizar basndose en uno de los dos modelos siguientes: el
modelo de procesos (o cliente/servidor) o el modelo de objetos.

Modelo basado en objetos


El modelo basado en objetos afronta la construccin del sistema
identificando las abstracciones clave del dominio del problema. Dichas
entidades son vistas como agentes autnomos que colaboran para llevar
a cabo un comportamiento de nivel superior.

El modelo basado en objetos pone nfasis en la identificacin y


caracterizacin de los componentes del sistema, que sern modelados
con objetos. Informalmente, se puede definir un objeto como una
coleccin formada por una serie de datos y un conjunto de operaciones
definidas sobre ellos, de tal manera que se garantiza la ocultacin de los
detalles internos.

Para alterar el estado de un objeto, se tendr que invocar la operacin


apropiada, de tal forma que el conjunto de las operaciones definidas
para un objeto definir colectivamente su comportamiento. El
mecanismo de encapsulacin de los objetos se encarga de que esto sea
as.

Tambin se pueden utilizar los mecanismos de herencia y polimorfismo


como herramientas adicionales de estructuracin para el diseo y
construccin de sistemas distribuidos. La aplicacin de conceptos de
orientacin a objetos tal cual para la construccin de sistemas
distribuidos es denominada en [BG96] aproximacin aplicativa. Un
ejemplo clsico del uso de estos mecanismos es el sistema operativo
Choices [CIR+93].

El modelo basado en objetos no difiere del tradicional paradigma de OO


en el que cada entidad es un objeto con una interfaz de mensajes que
proporcionan sus operaciones. En el modelo basado en objetos para los
sistemas distribuidos, cada recurso compartido se representa como un
objeto. Los objetos son identificados de forma unvoca y se pueden
mover por la red sin cambiar su identidad. Cuando un proceso requiere
el acceso a un recurso, enva un mensaje al objeto correspondiente. Este
mensaje es despachado al mtodo adecuado que resuelve la peticin y
enva un mensaje de respuesta al proceso adecuado.
El modelo basado en objetos es simple y flexible. Ofrece una visin
uniforme de todos los recursos. Como en los modelos descritos
anteriormente, los objetos pueden actuar como clientes y servidores. Sin
embargo, en el modelo cliente/servidor, el esquema de nombrado de los
recursos dependa del gestor mientras que aqu todos los recursos se
referencian de manera uniforme.

3.2.1 RMI
RMI (Remote Method Invocation) [Sun98] fue diseado para permitir la
invocacin de mtodos remotos de objetos entre distintas mquinas Java
(ubicadas en el mismo o en distintos computadores) de manera
transparente. Integra directamente un modelo de objetos distribuidos en
el lenguaje Java a travs de un conjunto de clases e interfaces.

Un objeto RMI es un objeto cuyos mtodos pueden ser invocados desde


otra mquina Java, incluso a travs de una red. Cada objeto remoto
implementa una o ms interfaces remotas que especifican qu
operaciones pueden ser invocadas por los clientes. Cualquier otra
operacin pblica que tenga el objeto pero que no aparezca en la
interfaz remota no podr ser utilizada por los clientes remotos. Los
clientes invocan dichos mtodos exactamente igual que si fueran
mtodos locales, quedando ocultos los detalles de la comunicacin. Se
utilizan los denominados sustitutos (stub) y esqueletos (skeleton), que
actan de intermediarios entre los objetos local y remoto. Los sustitutos
y los esqueletos son generados de manera automtica por el compilador
rmic.

Desde el punto de vista del programador, los objetos remotos se


manipulan de la misma manera que los locales, a travs de referencias.
Realmente, una referencia a un objeto remoto apunta a una referencia a
un sustituto local que lo representa, y que es el encargado de transmitir
los parmetros de la invocacin al computador remoto y recibir de l el
valor de retorno. La manipulacin de objetos remotos tiene que tener en
cuenta:

Cmo obtener una referencia a un objeto remoto.

Gestin de excepciones especficas de la invocacin de mtodos


remotos.
Por su parte, un esqueleto es el encargado de recoger los parmetros
que recibe del sustituto a travs de la red, invocar de manera local al
objeto remoto y devolver el resultado de nuevo a travs de la red al
sustituto del objeto que realiz la invocacin.

A diferencia de una invocacin local, una invocacin RMI pasa los objetos
locales que forman parte de la lista de parmetros por copia (por valor),
dado que una referencia a un objeto local slo sera til en una mquina
virtual nica. RMI utiliza el servicio de serializacin de objetos para
aplanar el estado de un objeto local y colocarlo en el mensaje a enviar a
la mquina virtual remota. Si el objeto es no-serializable, no se puede
usar como parmetro. Tambin son pasados por valor los parmetros de
tipos primitivos. Por otro lado, RMI pasa los objetos remotos (objetos que
implementan una interfaz remota) por referencia.

RMI proporciona interfaces y clases para buscar objetos remotos,


cargarlos y ejecutarlos de manera segura. Adicionalmente, proporciona
un servicio de nombrado un tanto primitivo (servicio de nombrado no
persistente y espacio de nombres plano) que permite localizar objetos
remotos y obtener referencias a ellos, de manera que se puedan invocar
sus mtodos.

La utilizacin de objetos remotos lleva consigo la aparicin de nuevas


situaciones de error, de tal forma que el programador deber manejar el
conjunto de nuevas excepciones que pueden ocurrir durante una
invocacin remota.

RMI incluye una caracterstica de recoleccin de basura distribuida, que


recolecta aquellos objetos servidores que no son referenciados por
ningn cliente de la red.

3.2.2 CORBA

CORBA (Common Object Request Broker Architecture) [OMG99] es una


especificacin definida por el OMG (Object Management Group) para la
creacin y uso de objetos remotos, cuyo objetivo en proporcionar
interoperabilidad entre aplicaciones en un entorno distribuido y
heterogneo. OMG es el mayor consorcio mundial de compaas de
software (alrededor de 800) entre las que destaca la ausencia de
Microsoft, que tiene su propia plataforma de objetos distribuidos: DCOM
(Distributed Component Object Model, Modelo de Objetos Componentes
Distribuido).
Es conocido como un tipo de middleware, ya que no realiza las
funciones de bajo nivel necesarias para ser considerado un sistema
operativo. A pesar de que debe funcionar sobre sistemas operativos
tradicionales, realiza muchas de las operaciones que tradicionalmente
se han considerado del dominio de los sistemas operativos para
entornos distribuidos.

Los objetos CORBA se diferencian de los objetos de los lenguajes


habituales de programacin en que:

pueden estar localizados en cualquier lugar de la red,

pueden ejecutarse en cualquier plataforma (hardware + sistema


operativo), y

pueden estar escritos en cualquier lenguaje.

Un cliente puede utilizar un objeto CORBA sin saber dnde est ni en


qu lenguaje ha sido implementado; lo nico que tiene que conocer es la
interfaz que publica dicho objeto.

El corazn de CORBA es su ORB (Object Request Broker). El ORB es el


responsable de:

Buscar la implementacin del objeto servidor.

Prepararlo para recibir la peticin.

Poner en contacto el cliente con el servidor.

Transportar los datos (parmetros y valores de retorno) entre uno


y otro, transformndolos adecuadamente.

En definitiva, es el responsable de que ni cliente ni servidor necesiten


conocer ni la localizacin ni el lenguaje de implementacin del otro.

Los objetos CORBA se tienen que definir con el lenguaje de definicin de


interfaces IDL (Interface Definition Language) que, como su propio
nombre indica, se limita a definir la interfaz del objeto y no su
implementacin. La definicin del objeto incluye la definicin de sus
atributos, sus mtodos (denominados operaciones) y las excepciones
que eleva. La implementacin del objeto se tiene que realizar con algn
lenguaje de programacin que tenga enlaces con IDL (en la actualidad
existen enlaces con lenguajes como C, C++, Java, Smalltalk, Ada, etc.).
IDL proporciona herencia mltiple de interfaces, de manera que las
interfaces derivadas heredan las operaciones y los tipos definidos en las
interfaces base. Todas las interfaces derivan de una interfaz raz,
denominada Object, la cual proporciona servicios que son comunes a
todos los objetos CORBA, como duplicacin y liberacin de referencias a
objetos, etc.

La compilacin de una definicin de objetos en IDL genera, entre otras


cosas, un sustituto (stub) y un esqueleto (skeleton), para el cliente y
servidor, respectivamente. El sustituto crea una peticin de servicio al
ORB a instancias del cliente y representa al objeto servidor. El esqueleto,
por su parte, entrega las peticiones a la implementacin del objeto
CORBA.

Es posible utilizar para la definicin de los objetos una serie de tipos


basicos y construidos que no tienen la categora de objetos y que son
similares a otros tipos encontrados en la mayora de los lenguajes de
programacin: char, boolean, array, struct, etc.

Las interfaces de objetos se almacenan en un repositorio de interfaces


(IR, Interface Repository), que proporciona un almacenamiento
persistente de las declaraciones de interfaces realizadas en IDL. Los
servicios proporcionados por un IR permiten la navegacin por la
jerarqua de herencia de un objeto y proporcionan la descripcin de
todas las operaciones soportadas por un objeto.

La funcin principal del IR es proporcionar la informacin de tipos


necesaria para realizar peticiones utilizando la Interfaz de Invocacin
Dinmica, aunque puede tener otros propsitos, como servir de
almacenamiento de componentes reutilizables para los desarrolladores
de aplicaciones.

La compilacin de las declaraciones IDL en algn lenguaje de


programacin permite a los clientes invocar operaciones en objetos
conocidos, pero algunas aplicaciones necesitan poder realizar llamadas
a objetos sin tener conocimiento de sus interfaces en tiempo de
compilacin. En esencia, la Interfaz de Invocacin Dinmica (DII,
Dynamic Invocation Interface) es un stub genrico de clientes capaz de
enviar cualquier peticin a cualquier objeto, interpretando en tiempo de
ejecucin los parmetros de la peticin y los identificadores de la
operacin.

CORBA permite que la implementacin de los objetos sea todo lo variada


que se quiera. En unos casos, varias interfaces IDL pueden estar
implementadas por un solo programa, y, en otros casos, una interfaz IDL
puede estar implementada por una serie de programas, uno para cada
operacin.

Un Adaptador de Objetos (OA, Object Adapter) proporciona los medios


por los que varios tipos de implementaciones de objetos utilizan los
servicios del ORB, como por ejemplo:

generacin de referencias de objetos.

invocacin de mtodos de objetos.

seguridad.

activacin y desactivacin de objetos e implementaciones.

Dependiendo del ORB subyacente, un OA puede elegir entre


proporcionar estos servicios delegando en el ORB o realizando el trabajo
l mismo. En cualquier caso, las implementaciones de los objetos no van
a estar al tanto de la diferencia, ya que nicamente usan la interfaz
proporcionada por el OA.

Para que un cliente pueda realizar una peticin a un objeto servidor,


deber utilizar una referencia al objeto. Una referencia siempre refiere el
mismo objeto para la que fue creada, durante tanto tiempo como exista
el objeto. Las referencias son tanto inmutables como opacas, de manera
que un cliente no puede entrar en una referencia y modificarla. Slo el
ORB sabe que es lo que hay dentro de la referencia.

Cuando se pasan objetos como parmetros en invocaciones a mtodos,


lo que realmente se pasan son referencias a dichos objetos. El paso de
objetos como parmetro es, por tanto, por referencia.

En la ltima revisin importante de CORBA (revisin 2.3, de Junio de


1999) se introdujo la propuesta de objetos-por-valor (objects-by-value),
que extienden el modelo de objetos de CORBA tradicional para permitir
el paso de objetos por valor dentro de los parmetros de los mtodos.
Para conseguirlo se introduce un nuevo tipo IDL denominado el tipo valor
(value).

Cuando un ORB encuentra un objeto de tipo valor dentro de un


parmetro, automticamente pasa una copia del estado del objeto al
receptor. En contraste, el ORB pasar por referencia cualquier objeto
declarado va una interfaz IDL.
Un tipo valor se puede entender a medio camino entre una interfaz IDL y
una estructura (del estilo de las del lenguaje C). La sintaxis del valor
permite especificar algunos detalles de implementacin (por ejemplo, su
estado), que no forman parte de una interfaz IDL. Adems, se pueden
especificar mtodos locales para operar con dicho estado. A diferencia
de las interfaces, los mtodos de los tipos valor no pueden ser invocados
remotamente.

Los CORBAservices son un conjunto de servicios que aumentan y


complementan los servicios proporcionados por el ORB. Todos ellos son
accesibles a travs de un conjunto de interfaces especificadas en IDL. Se
relacionan, a continuacin, los servicios incluidos en el estndar:

Life Cycle Service: define las operaciones para crear, copiar, mover y
eliminar objetos.

Persistence Service: proporciona una interfaz para almacenar


objetos de manera persistente en una amplia variedad de servidores de
almacenamiento: bases de datos orientadas a objetos (ODBMSs), bases
de datos relacionales (RDBMSs) y ficheros tradicionales.

Naming Service: permite a los objetos localizar otros objetos, incluso


utilizando servicios de directorio como X.500, NIS+, NDS, LDAP, etc.

Event Service: permite a los objetos registrar dinmicamente su


inters por eventos especficos. Este servicio define el objeto
denominado event channel, que recolecta y distribuye eventos entre los
objetos, que no necesitarn conocerse entre s.

Concurrency Control Service: proporciona un gestor de cerraduras


(lock, en ingls).

Transaction Service: proporciona una coordinacin de dos fases


(two-phase commit) utilizando transacciones planas o anidadas.

Relationship Service: proporciona una forma de crear asociaciones


dinmicas entre objetos que no se conocen entre s.

Externalization Service: proporciona una manera estndar de


introducir/enviar al exterior datos de un objeto utilizando un mecanismo
de tipo flujo de bytes (stream).

Query Service: proporciona operaciones de consulta sobre objetos.


Es un superconjunto de SQL.
Licensing Service: proporciona operaciones para medir la utilizacin
de objetos para asegurar una compensacin justa por su uso. Permite
controlar el coste por sesin, por nodo, por creacin de instancia, etc.

Properties Service: proporciona operaciones que permiten asociar


valores con nombre (propiedades) a cualquier objeto.

Time Service: proporciona interfaces para sincronizar relojes en un


entorno de objetos distribuidos. Tambin proporciona operaciones para
definir y gestionar eventos dependientes del tiempo.

Security Service: proporciona seguridad en el entorno de objetos


distribuidos, soportando autenticacin, listas de control de acceso,
confidencialidad, etc.

Trader Service: proporciona pginas amarillas para los objetos.


Permite a los objetos publicitar sus servicios y pujar por la realizacin de
trabajos.

Collection Service: proporciona interfaces para crear y manipular las


collecciones ms comunes.

3.2.3 COM

COM (Component Object Model) [Mic95] es la tecnologa de definicin y


manipulacin de componentes de Microsoft que proporciona un modelo
de programacin y un estndar binario para los mismos. DCOM [Mic98]
(de Distributed COM) es la tecnologa que extiende COM para permitir a
los objetos componentes residir en mquinas remotas y est disponible
desde la aparicin de Windows NT 4.0. A partir de ahora se utilizarn los
trminos COM y DCOM indistintamente.

Un objeto COM se define en trminos de las interfaces individuales que


soporta (una o ms) y que estn definidas en la clase (objeto clase) a la
que pertenece. Cada interfaz est identificada por un identificador nico
(IID, Interface Identifier), que es un caso particular de identificador
global y nico (GUID, Global Unique Identifier). Los GUID son valores de
128 bits que se garantizan nicos estadsticamente en el espacio y en el
tiempo.

Las interfaces son el nico medio de interactuar con un objeto COM. Un


cliente que desea utilizar los servicios de un objeto habr de obtener
primero un puntero a una de sus interfaces.
Los objetos clase implementan una o ms interfaces y se identifican por
un identificador de clase (CLSID, Class Identifier). Los CLSID son tambin
un caso particular de GUID. Con el fin de que un cliente pueda crear un
objeto COM, es necesario describir su clase utilizando el lenguaje de
definicin de interfaces (IDL, Interface Definition Language). La
compilacin de dicha descripcin genera un representante (proxy) para
los clientes y un sustituto (stub) para el servidor.

COM no proporciona la herencia como instrumento para lograr la


reutilizacin. En su lugar proporciona los mecanismos de contencin y
agregacin. El polimorfismo es conseguido cuando diferentes clases
soportan la misma interfaz, permitiendo a una aplicacin utilizar el
mismo cdigo para comunicarse con cualquiera de ellas.

El objetivo principal de COM es proporcionar un medio por el que los


clientes pueden hacer uso de los objetos servidores, sin tener en cuenta
que pueden haber sido desarrollados por diferentes compaas
utilizando diferentes lenguajes de programacin. Con el fin de lograr
este nivel de interoperabilidad, COM define un estndar binario, que
especifica cmo se dispone un objeto en memoria principal en tiempo de
ejecucin. Cualquier lenguaje que pueda reproducir dicha disposicin en
memoria podr crear objetos COM.

Adems del objetivo de la interoperabilidad, COM tiene otros objetivos:

Proporcionar una solucin para los problemas de versiones y


evolucin.

Proporcionar una visin del sistema de los objetos.

Proporcionar un modelo de programacin singular.

Proporcionar soporte para capacidades de distribucin.

En el modelo de programacin COM, los clientes COM se conectan a uno


o ms objetos COM. Cada objeto COM expone sus servicios a travs de
una o ms interfaces, que no son ms que agrupaciones de funciones
relacionadas semnticamente.

La implementacin compilada de cada objeto COM est contenida en un


mdulo binario (exe o dll) denominado servidor COM. Un nico servidor
COM es capaz de contener la implementacin compilada de varios
objetos COM.
Un servidor COM puede estar enlazado al proceso cliente (in-process
server), puede ejecutarse en un proceso distinto del cliente pero en la
misma mquina (local server) o bien, puede ejecutarse en un proceso
separado en una mquina distinta, incluso en un sistema operativo
distinto (remote server). Para la comunicacin con objetos situados en
espacios de direcciones distintos del espacio de direcciones del cliente,
se utilizan intermediarios en la forma de representantes y sustitutos.

El modelo de programacin COM define que un servidor COM debe


exponer objetos COM, un objeto COM debe exponer sus servicios y un
cliente COM debe usar los servicios de objetos COM.

Para comunicarse con un objeto que no es local, COM emplea un


mecanismo de comunicacin entre procesos que es transparente a la
aplicacin, incluso en lo relativo a la localizacin del objeto.

Todos los objetos COM tienen que implementar una interfaz particular,
denominada IUnknown. Esta interfaz es el corazn de COM y es utilizada
para negociacin de interfaces en tiempo de ejecucin (preguntar al
objeto qu interfaces soporta y obtener punteros a las mismas), gestin
del ciclo de vida del objeto y agregacin.

Cada objeto mantiene una cuenta de referencia que es incrementada


cada vez que un cliente solicita un puntero para una interfaz o pasa una
referencia al mismo. Cuando la interfaz deja de ser utilizada por el
cliente, la cuenta de referencia se decrementa. Las operaciones de
incremento y decremento son realizadas de manera explcita por el
cliente invocando funciones pertenecientes a la interfaz.

3.3 Sncrona y asncrona

Sncrona

La transmisin sncrona es una tcnica que consiste en el enviar una


trama de datos (conjunto de caracteres) que configura un bloque de
informacin comenzando con un conjunto de bits de sincronismo (SYN) y
terminando con otro conjunto de bits de final de bloque (ETB). En este
caso, los bits de sincronismo tienen la funcin de sincronizar los relojes
existentes tanto en el emisor como en el receptor, de tal forma que
estos controlan la duracin de cada bit y carcter.
Dicha transmisin se realiza con un ritmo que se genera
centralizadamente en la red y es el mismo para el emisor como para el
receptor. La informacin se transmite entre dos grupos, denominados
delimitadores (8 bits).
Caractersticas
Los bloques a ser transmitidos tienen un tamao que oscila entre 128 y
1,024 bytes. La seal de sincronismo en el extremo fuente, puede ser
generada por el equipo terminal de datos o por el mdem. Cuando se
transmiten bloques de 1,024 bytes y se usan no ms de 10 bytes de
cabecera y terminacin, el rendimiento de transmisin supera el 99 por
100.

Ventajas

Posee un alto rendimiento en la transmisin

Son aptos para transmisiones de altas velocidades (iguales o


mayores a 1,200 baudios de velocidad de modulacin)

El flujo de datos es ms regular.

Tambin llamada Transmisin Sincrnica. A todo el conjunto de bits y de


datos se le denomina TRAMA.
Desventaja

Los equipamientos son de tecnologa ms completa y de costos


ms altos
Asncrona

La transmisin asncrona tiene lugar cuando el proceso de sincronizacin


entre emisor y receptor se realiza en cada palabra de cdigo
transmitido. Esta sincronizacin se lleva a cabo a travs de unos bits
especiales que definen el entorno de cada cdigo.

Tambin se dice que se establece una relacin asncrona cuando no hay


ninguna relacin temporal entre la estacin que transmite y la que
recibe. Es decir, el ritmo de presentacin de la informacin al destino no
tiene por qu coincidir con el ritmo de presentacin de la informacin
por la fuente. En estas situaciones tampoco se necesita garantizar un
ancho de banda determinado, suministrando solamente el que est en
ese momento disponible. Es un tipo de relacin tpica para la
transmisin de datos.

En este tipo de red el receptor no sabe con precisin cuando recibir un


mensaje. Cada carcter a ser transmitido es delimitado por un bit de
informacin denominado de cabecera o de arranque, y uno o dos bits
denominados de terminacin o de parada.

El bit de arranque tiene dos funciones de sincronizacin de reloj del


transmisor y del receptor.

El bit o bits de parada, se usan para separar un carcter del siguiente.


Despus de la transmisin de los bits de informacin se suele agregar un
bit de paridad (par o impar). Dicho Bit sirve para comprobar que los
datos se transfieran sin interrupcin. El receptor revisa la paridad de
cada unidad de entrada de datos.

Partiendo desde la lnea de transmisin en reposo, cuando tiene el nivel


lgico 1, el emisor informa al receptor de que va a llegar un carcter,
para ello antepone un bit de arranque (Start) con el valor lgico 0. Una
vez que el bit Start llega al receptor este disparar un reloj interno y se
quedar esperando por los sucesivos bits que contendr la informacin
del carcter transmitido por el emisor.

Una vez que el receptor recibe todos los bits de informacin se aadir
al menos un bit de parada (Stop) de nivel lgico 1, que repondrn en su
estado inicial a la lnea de datos, dejndola as preparada para la
siguiente transmisin del siguiente carcter. Es usada en velocidades de
modulacin de hasta 1,200 baudios. El rendimiento se basa en el uso de
un bit de arranque y dos de parada, en una seal que use cdigo de 7
bits ms uno de paridad (8 bits sobre 11 transmitidos) es del 72 por 100.

Ventajas y desventajas del modo asncrono:

En caso de errores se pierde siempre una cantidad pequea de


caracteres, pues stos se sincronizan y se transmiten de uno en
uno.
Bajo rendimiento de transmisin, dada la proporcin de bits tiles
y de bits de sincronismo, que hay que transmitir por cada carcter.
Es un procedimiento que permite el uso de equipamiento ms
econmico y de tecnologa menos sofisticada.
Se adecua ms fcilmente en aplicaciones, donde el flujo
transmitido es ms irregular.
Son especialmente aptos, cuando no se necesitan lograr altas
velocidades.
3.4 Consideraciones de seguridad

Debido a ellas surge la necesidad de proteger la integridad y la


privacidad de la
informacin, y otros recursos que pertenecen a individuos y
organizaciones, se
conjuga ambos mundos: el fsico y el digital. Nace, como es lgico, de la
necesidad de compartir recursos. En el mundo fsico, las organizaciones
adoptan polticas de seguridad para poder compartir recursos dentro de
unos
lmites especificados. Las polticas de seguridad se hacen cumplir con la
ayuda
de los mecanismos de seguridad.
En el mundo electrnico, la distincin entre polticas de seguridad y los
mecanismos tambin es importante: sin ella, sera difcil determinar si
un
sistema particular es seguro. Las polticas de seguridad son
independientes de
la tecnologa empleada, as como el instalar una cerradura en una
puerta no
garantiza la seguridad del edificio a menos que haya una poltica de uso
(por
ejemplo. que la puerta est cerrada cuando no est vigilada). Los
mecanismos de seguridad que describir no garantizan, por s mismos,
la seguridad de un
sistema.

Evolucin de las Necesidades de Seguridad

A continuacin describiremos los mecanismos que permiten hacer


cumplir las
polticas de seguridad en los sistemas distribuidos.

La distincin entre polticas de seguridad y mecanismos de seguridad es


de
utilidad cuando se disean sistemas seguros, pero no es fcil estar
seguro de
que cierto conjunto de mecanismos de seguridad implementan
completamente
las polticas de seguridad deseadas. Este es un modelo de seguridad
diseado
para ayudar en el anlisis de las amenazas de seguridad potenciales en
un
sistema distribuido.

Resumiendo el modelo de seguridad como sigue:


Los procesos encapsulan recursos y acceden a comunicarse con los
clientes a travs de sus interfaces. Los usuarios u otros procesos
pueden estar autorizados para operar sobre los recursos y estos deben
estar protegidos contra accesos no autorizados.
Los procesos interactan en la red, que es compartida. Los enemigos o
atacantes pueden acceder a la red y podrn copiar, leer o introducir
mensajes arbitrarios, dirigidos hacia cualquier destino y simular que
provienen de cualquier otro.

Este modelo de seguridad identifica las caractersticas de los sistemas


de
seguridad expuestos a ataques.

La Emergencia de la Criptografa en el Dominio Pblico

La criptografa proporciona la base para la mayora de los sistemas de


seguridad de los computadores. La criptografa tiene una larga y
fascinante
historia. La necesidad de comunicaciones militares seguras y la
correspondiente necesidad del enemigo de interceptarlas y
desencriptarlas ha
fomentado la inversin de mucho esfuerzo intelectual, por parte de los
mejores
cerebros matemticos de cada poca.
Pero slo en tiempos recientes la criptografa emerge de la trastienda en
la que
fue puesta por la clase dirigente de polticos y militares que solan
controlar su
desarrollo y su aplicacin. Hoy en da es un tema de investigacin
abierta y con
una comunidad de investigadores amplia y muy activa.
La reciente apertura es, en su mayor medida, resultado del importante
crecimiento del inters en las aplicaciones no militares de la criptografa
y los
requisitos de seguridad de los sistemas de computadores distribuidos.
Esto
desemboc en la existencia, por primera vez, de una comunidad
autosuficiente
de criptgrafos aparte del entorno militar.
Irnicamente, esta apertura al pblico de la criptografa ha trado
consigo un
mayor avance de las tcnicas criptogrficas, su resistencia a los ataques
criptoanalticos y la comodidad con la que se despliegan las medidas
criptogrficas. La criptografa de clave pblica es fruto de esta apertura.
Un
ejemplo ms, el algoritmo de encriptacin estndar DES fue inicialmente
un
secreto militar. Su eventual publicacin y los esfuerzos exitosos para
romperlo
han trado consigo el desarrollo de algoritmos de encriptacin de clave
secreta
mucho ms resistentes.
Otro producto secundario til ha sido el desarrollo de una terminologa y
aproximacin comn. Un ejemplo de esto ltimo es la adopcin de un
conjunto
de nombres familiares para los protagonistas (principales) involucrados
en las
transacciones que hay que asegurar. El uso de nombres familiares para
los
principales y los atacantes ayuda a aclarar y acercar al mundo las
descripciones de los protocolos de seguridad y los potenciales ataques
sobre
ellos, lo que supone un paso importante hacia la identificacin de sus
debilidades.

Alice Primer participante.


Bob Segundo participante.
Carol Otro participante en los protocolos a tres o cuatro bandas.
Dave Participante en protocolos a cuatro bandas.
Eve Fisgn.
Mallory Atacante malevolente.
Sara Un servidor.

3.5 Opciones tecnolgicas (ASMX, WCF, RMI,


etc.)

Un desarrollador puede incluir en sus sitios soluciones sentencias, es decir,


instrucciones que consuman Web Services de terceros o propios como por ejemplo
aquellos que proporcionan los datos meteorolgicos para una localidad determinada,
las cotizaciones de determinadas monedas, la cartelera de pelculas, el calendario o
agenda de un especialista mdico, etc.
Pensando un poco ms en forma comercial, Qu pasara si por ejemplo estuvieras
trabajando en tu procesador de texto en un idioma para el cual no tienes un corrector
ortogrfico ni sintctico instalado (quizs no exista para instalar), pero deseas realizar
la revisin del documento a toda costa? Bien, perfectamente podra haber una opcin
en el men de este procesador que de alguna forma localice un Web Service en
Internet que brinde esta funcionalidad, y lo ms interesante an para quien lo haya
desarrollado es que puede solicitar al usuario que se subscriba para su uso. Como ves,
todos ganan en esta transaccin.
El ejemplo anterior muestra una realidad a la que no podemos estar ajenos. Es un
replanteo de la estrategia utilizada por los desarrolladores quienes ahora, al realizar
una aplicacin, no deben pensar nicamente en el lugar fsico donde la misma va a
ejecutarse sino en que esa aplicacin deber estar interconectada con otras
computadoras, corriendo otras aplicaciones quizs en otras plataformas y lenguajes,
pero usando protocolos y estndares universales. El intercambio se intensificar
muchsimo ms y quizs existan por ejemplo proveedores de dominios de datos
como ser los pases, de forma tal que la aplicacin que yo realice en lugar de crear
toda la lgica para manejar las tablas y el cargado de los datos para el concepto PAIS,
se limite a consumir un Web Service que me tome esta informacin de algn lugar en
Internet. Imagino una reutilizacin an mayor de funcionalidades y una colaboracin e
intercambio de lgica a nivel mundial. Quizs sea muy ambicioso en este planteo.
Pasando al terreno ms tcnico y prctico de este artculo, existen algunas
consideraciones y conceptos que es necesario mencionar para comenzar a entender el
tema:
Un Web Service puede ser registrado para poder dejarlo a disposicin de otros
usuarios y para que los mismos puedan localizarlo. Un mecanismo para registrar
estos servicios es por medio de UDDI, sigla que corresponde a Universal
Description , Discovery and Integration, un repositorio de Web Services.
Para registrar un servicio tendrs que tener en cuenta que debes suministrar la
informacin de tu empresa, en qu categoras ubicaras tu servicio y la interfaz
a utilizar para consumir este servicio.
El mecanismo utilizado por un Web Service para especificar de qu forma hay
que proporcionarle los datos, de manera tal que cualquiera pueda interaccionar
con el mismo, es por medio de lenguaje XML. Esta informacin se almacena en
un archivo llamado WSDL (Web Services Description Language), el cual
contiene un documento XML junto con la descripcin de ciertos mensajes SOAP
y cmo deben intercambiarse, as como tambin dnde est el recurso del
servicio y con qu protocolo debe dialogar quien lo consume.
El protocolo de comunicacin utilizado es el SOAP generalmente, el cual es
relativamente sencillo de utilizar.
Los Web Services utilizan protocolos comnmente conocidos y difundidos tales
como el formato XML, TCP/IP como protocolo de transporte y HTTP como
protocolo de transferencia de hipertexto.

Qu es SOAP?
SOAP es un protocolo que define el formato XML para los mensajes de intercambio en
el uso de un Web Service. Para aquellos programadores que solan utilizar llamadas del
tipo RPC, SOAP tambin las soporta. Adicionalmente, es posible mediante SOAP definir
un mensaje HTTP y este punto es de especial inters puesto que el protocolo
imprescindible para Internet es HTTP.

Un servicio Web o WebService es un servicio ofrecido por una aplicacion que expone su
logica a clientes de cualquier plataforma mediante una interfaz accesible a traves de la red
utilizando tecnologias (protocolos) estandar de Internet.
Por ejemplo, una aplicacion como Access esta formada por un conjunto de componentes
que ofrecen una serie de servicios, como el acceso a datos, la impresion de informes, el
diseno de tablas...

La idea de los servicios es la misma, aunque estos no tienen por que estar en el mismo
ordenador que el cliente y ademas son accedidos a traves de un servidor Web y de un modo
independiente de la plataforma, utilizando protocolos estandar (HTTP, SOAP, WSDL,
UDDI).

Para crear un servicio puede utilizarse cualquiera de los lenguajes disponibles en la


plataforma .NET.

Una vez creado el servicio, para conseguir que sea accesible por los consumidores, es
necesario describirlo utilizando un lenguaje estandar llamado WSDL (Web Service
Description Language).

Los clientes del servicio podran estar creados en cualquier lenguaje y ejecutarse sobre
cualquier sistema operativo y hardware, lo unico necesario es que sean capaces de obtener
y entender la descripcion WSDL de un servicio.

Un archivo WSDL es, en realidad, un archivo XML en el que se identifica el servicio y se


indica el esquema para poder utilizarlo, asi como el protocolo o protocolos que es posible
utilizar.
Una vez dispone de esta informacion, el cliente puede comunicarse con el servicio
utilizando protocolos como HTTP o SOAP (SOAP anade invocacion de metodos a HTTP,
aunque es posible hacerlo con peticiones HTTP-GET y/o HTTP-POST en lugar de SOAP).

Ademas de describir un servicio para que pueda ser utilizado por los clientes es importante
publicar el servicio de modo que pueda ser encontrado por clientes que no conozcan
necesariamente el componente que ofrece el servicio, pero que busquen un servicio de sus
caracteristicas. Esto se logra mediante el estandar UDDI (Universal Description,
Discovery and Integration Registry). Realmente se trata de un servicio mundial en
el que los proveedores de servicios pueden registrarlos de modo gratuito.

Un Servicio Web es una entidad programable, proporcionado un elemento particular de

funcionalidades, como Lgica de aplicacin. Puede ser usado internamente por cualquier

aplicacin o externamente, a travs de la internet por cualquier nmero de aplicaciones

usando estndares como XML (Lenguaje de Marca Extensible) y HTTP (Protocolo de

Transferencia de Hipertexto).

Algunos Especificaciones Ncleos de un servicio Web son:

SOAP: Es un Protocolo basado en XML.

WSDL: Es un formato XML describe la interfaz pblica a los servicios Web

UDDI: Es un protocolo para publicar y descubrir Metadatos.

Existe dos va primaria para crea Servicios en ASP.NET:

1. Servicios Web basado en el Modelo ASP.NET (.asmx).

2. Servicios Web basado en Microsoft Windows Communication Foundation (WCF).

La diferencia fundamental entre ellos es:

Los Servicios Web de ASP.NET se hospedan directamente en Microsoft Internet

Information Service IIS, cuales son procesados y ejecutados a travs de protocolo de

transferencia de Hipertexto (HTTP).

Ahora

Los Servicios Web de Windows Communication Foundation (WCF) pueden trabajar

con una variedad de Hosts, Protocolos y Clientes.

Hosts: IIS, Aplicaciones Consola residente, Servicio de Windows, etc.


Protocolos: HTTP, TCP, MSMQ, Binary HTTP, etc.

Clientes: Windows, Web, Mobile, etc.