\newpage
%===========================================================================
%       x.5 > Sistemas distribuidos
%===========================================================================
\pagestyle{empty}
\begin{latexonly}
\ifpdf
 \begin{figure}[htbp]
%       \includegraphics[bb = -350 150 0 0, scale=1]{./TuXes/tux-peeping.jpg}
 \end{figure}
 \vspace{5in}
\else
 \begin{figure}
       \includegraphics[-280,610][0,0]{./TuXes/tux-sherlock}
 \end{figure}
\fi
\hfill\line(1,0){400}
\end{latexonly}
\topmargin 1in
\section{SISTEMAS DISTRIBUIDOS}
\begin{latexonly}
\line(1,0){400}
\newpage
\end{latexonly}
\topmargin 0in
\pagestyle{fancy}
%========================cita===============================================
\begin{latexonly}
\hspace{1in}\textcolor{blue_omosix}{{\em The best way to accelerate a Macintosh is at 9.8m sec sec.}}

\hspace{4in}\textcolor{blue_omosix}{{\em Marcus Dolengo}}
\vspace{0.5in}

\end{latexonly}

%===========================================================================
\subsection{Concepto de sistema distribuido y sistema operativo distribuido}
Un sistema distribuido es un conjunto de ordenadores o procesadores
 independientes que cara al usuario funcionan como uno solo.
 Est\'a formado por varios componentes, relativamente peque\~{n}os e independientes,
 que cooperan estrechamente para dar un servicio \'unico.

Un sistema operativo distribuido es el encargado de cumplir lo anterior.
 Hay un particionado y cooperaci\'on entre todos los componentes, ninguno
 sobrevive solo, el propio kernel est\'a distribuido por las m\'aquinas.
 El hardware no da ninguna facilidad, es el software el que determina que
 un sistema sea distribuido o no.
 El usuario no sabe d\'onde se est\'an ejecutando los procesos ni d\'onde est\'an
 los recursos.
 Llevar a la pr\'actica la idea de un kernel global distribuido es muy
 dif\'\i cil, pues podr\'\i a haber inconsistencias de datos en el kernel,
 adem\'as se necesita al menos el kernel m\'\i nimo para enviar y recibir informaci\'on
 y un mecanismo robusto de comunicaci\'on y eficiente para evitar latencias
 demasiado elevadas.

Lo que se han desarrollado hasta ahora son los llamados {\bf sistemas operativos
 en red.}
 En estos sistemas cada m\'aquina tiene su propio kernel.
 Los sistemas est\'an conectados por una red y se puede hacer {\em
 remote login} en ellos,
 en todo momento el usuario sabe donde se encuentran todos los recursos
 (ficheros, procesos, {\em etc.}).
 No es un sistema distribuido por lo que no tiene las ventajas que se ver\'an
 en el siguiente apartado.

Actualmente se est\'a caminando desde los sistemas operativos en red a los
 sistemas distribuidos, aunque a\'un no se han cumplido los objetivos de un
 sistema distribuido completamente tenemos ya algunos avances.
 Por ejemplo ya hay grandes avances en sistemas de ficheros para conseguir
 que exista un solo directorio ra\'\i z al igual que la existencia de una ubicaci\'on
 autom\'atica por parte del sistema de los ficheros.
 Se puede implementar un balanceo de la capacidad y redundancia en los datos
 para minimizar el impacto de posibles ca\'\i das de nodos.

Un cluster openMosix ya implementa una migraci\'on de procesos, que a ojos del usuario es
 transparente.
 El cluster se usa como un gran computador donde se ejecutan los procesos
 en todos sus nodos.
 La ubicaci\'on de los procesos la elige el sistema operativo o el usuario,
 en un intento de balancear la carga.
%===========================================================================
\subsection{Necesidad de sistemas distribuidos}
En un sistema operativo distribuido se cumplen todas los criterios de transparencia, con
 todas las ventajas que esto supone. Aparte tambi\'en se deben tener en consideraci\'on las siguientes
 caracter\'\i sticas:
\begin{enumerate}
  \item \underline{Econom\'\i a:} la relaci\'on precio-rendimiento es mayor que en
  los sistemas centralizados sobretodo cuando lo que se busca son
  altas prestaciones.

  \item \underline{Velocidad:} llega un momento en el que no se puede encontrar un sistema centralizado suficientemente potente, con los sistemas distribuidos siempre se podr\'a
 encontrar un sistema m\'as potente uniendo m\'as nodos.
 Se han hecho comparativas y los sistemas distribuidos especializados en
 c\'omputo han ganado a los mayores mainframes.

  \item \underline{Distribuci\'on de m\'aquinas:} podemos tener unas m\'aquinas
  inherentemente distribuidas por el tipo de trabajo que realizan.

  \item \underline{Alta disponibilidad:} cuando una m\'aquina falla no tiene que caer todo el
 sistema sino que este se recupera de las ca\'\i das y sigue funcionando con
 quiz\'as algo menos de velocidad.

  \item \underline{Escalabilidad:} puede empezarse un cluster con unas pocas m\'aquinas y seg\'un
 la carga aumenta, a\~{n}adir m\'as nodos.
 No hace falta tirar las m\'aquinas antiguas ni inversiones iniciales elevadas
 para tener m\'aquinas suficientemente potentes.
\begin{latexonly}
\ifpdf
        \begin{figure}[htbp]
        \includegraphics[bb = -37 180 0 0, scale=1]{./pics/escalabilidad_servicios.png}
        \vspace{2.6in}
        \caption{Sistemas distribuidos: Escalabilidad de servicios}
        \end{figure}
\else
\end{latexonly}
        \begin{figure}
        \centering
        \includegraphics{pics/escalabilidad_servicios}
        \caption{Sistemas distribuidos. Escalabilidad de servicios en
        una empresa}
        \end{figure}
\begin{latexonly}
\fi
\end{latexonly}

  \item \underline{Comunicaci\'on:} los ordenadores necesariamente estar\'an comunicados, para el
 correcto y eficaz funcionamiento del cluster se crean unas nuevas funcionalidades avanzadas de comunicaci\'on.
 Estas nuevas primitivas de comunicaci\'on pueden ser usadas por los programas
 y por los usuarios para mejorar sus comunicaciones con otras m\'aquinas.

  \item \underline{Sistema de ficheros con ra\'\i z \'unica:} este sistema de ficheros hace que la
 administraci\'on sea m\'as sencilla (no hay que administrar varios discos independientemente) y deja a cargo del sistema varias de las tareas.
 
  \item \underline{Capacidad de comunicaci\'on de procesos y de intercambio de datos universal:}
 permite enviar se\~{n}ales a cualquier proceso del cluster, asimismo permite
 trabajar conjuntamente con cualquier proceso e intercambiar datos.
 Por lo tanto ser\'a posible tener todos los procesos trabajando en un mismo
 trabajo.
\end{enumerate}
%===========================================================================
\subsection{Desventajas: el problema de la transparencia}
La principal desventaja de estos sistemas es la complejidad que implica
 su creaci\'on.
 B\'asicamente se tienen todos los problemas que se puedan tener en un nodo
 particular pero escalados.
 Vamos a ver los problemas que ocurren al intentar implantar las ventajas
 que hemos visto en el apartado anterior.
 Los puntos 1, 2 y 3 no tienen problemas de implantaci\'on porque son inherentes
 a los sistemas distribuidos.
\begin{itemize}
  \item \underline{4.- Alta disponibilidad:} podemos conseguir alta disponibilidad pues al tener
 varios nodos independientes, hay muchas menos posibilidades de que caigan
 todos a la vez.
 Pero esto por s\'\i\ s\'olo no nos da alta disponibilidad.
 Tenemos que implantar los mecanismos necesarios para que cuando una m\'aquina
 caiga, se sigan dando todos los servicios.

Normalmente se apuesta por la replicaci\'on de informaci\'on.
 Si tenemos 3 servidores de ficheros, sirviendo los mismos ficheros, si
 uno de ellos cae podemos seguir obteniendo el servicio de alguno de los
 otros servidores (en el peor de los casis el servicio quiz\'as se
 ralentice).

 Este caso adem\'as ilustra otro problema que es la necesidad de actualizar
 todas las r\'eplicas de un servicio: si un nodo escribe en uno de los servidores
 \'este debe mandar los nuevos datos a los otros servidores para mantenerlos todos coherentes.
 De otro modo al caer uno de estos servidores perder\'\i amos toda la informaci\'on
 que hubi\'eramos ido grabando en este servidor y no en el resto.

 Tambi\'en se tiene que disponer de los mecanismos adecuados para que el nodo
 que ve el fallo del servidor busque los servidores alternativos en busca
 de la informaci\'on que necesita.
 Adem\'as tambi\'en se debe disponer de los mecanismos necesarios para que los
 nodos que han ca\'\i do, cuando vuelvan a conectarse al cluster puedan continuar
 con su trabajo normalmente.

  \item \underline{5.- Escalabilidad:} el problema es que m\'as nodos suele implicar m\'as comunicaci\'on, por lo que tenemos que dise\~{n}ar un sistema lo m\'as escalable posible. Por
 ejemplo elegir una comunicaci\'on {\em todos con todos} aunque tenga ciertas ventajas
 no es una soluci\'on en absoluto escalable pues cada nuevo nodo tiene que
 comunicarse con todos los dem\'as, lo que hace que incluir un nodo no sea
 lineal.
 
Una soluci\'on para este problema son los clusters jer\'arquicos propuestos
 por Stephen Tweedie: clusters divididos en niveles. Un cluster como lo conocemos
 es un cluster de primer nivel, los nodos forman una lista de miembros.
 Hay un nodo privilegiado llamado l\'\i der.
 Para hacer cl\'usteres m\'as grandes se juntan todos los l\'\i deres en un metacluster.
 Se crean entonces dos listas, una de ellas contiene todos los nodos
 llamada {\em subcluster membership} y la otra contiene \'unicamente los
 l\'\i deres llamada {\em metacluster membership}.
 Si se cambia de l\'\i der se cambia tambi\'en en el metacluster.
 As\'\i\  podemos agrupar l\'\i deres de metaclusters en un cluster de tercer nivel,
 {\em etc.}

 Esta disposici\'on evita transiciones de todo el cluster, pues si hace falta a\~{n}adir un
 nodo y crear una transici\'on en el cluster s\'olo involucramos a los nodos
 de esa rama.
 Cuando el cluster necesite recuperaci\'on habr\'a nodos que participen y otros que no.

  \item \underline{6.- Comunicaci\'on:} un cluster tiene m\'as necesidades de comunicaci\'on que los
 sistemas normales por lo tanto tenemos que crear nuevos m\'etodos de comunicaci\'on
 lo m\'as eficientes posibles.
 Un ejemplo de esto es Heartbeat.

  \item \underline{7.-Sistemas de ficheros con ra\'\i z \'unica:} tenemos que independizar los sistemas
 de ficheros distintos de cada uno de los nodos para crear un sistema de
 ficheros general.
 Tenemos una f\'acil analog\'\i a con LVM, la cual abstrae al usuario
 de las particiones del disco duro y le hace ver un \'unico volumen
 l\'ogico.

 Entre los problemas que nos encontramos en los sistemas de sabor UNIX se encuentran
 por ejemplo c\'omo manejar los directorios {\em /proc} y {\em /dev}.
 Hacer un solo directorio con ellos significar\'\i a en {\em /proc} tener
 PIDs independientes para cada nodo, algo que no es tan complicado de
 conseguir y que tiene beneficios como que cada nodo sabe a ciencia
 cierta y sin ning\'un retardo cual es el siguiente PID que tiene que
 asignar.

 Pero adem\'as incluye otra informaci\'on como {\em /proc/cpuinfo},
 {\em /proc/meminfo}, {\em etc.}
 que es espec\'\i fica del nodo y que o se modifican esos ficheros para poner
 la informaci\'on de todos los nodos en ellos (lo cual romper\'\i a la compatibilidad
 con algunas aplicaciones de usuario) o poner la informaci\'on en directorios
 distintos que tuvieran como nombre el n\'umero del nodo (lo que traer\'\i a la
 duda de qu\'e informaci\'on colocar en {\em /proc}).
 A\'un peor es el caso de {\em /dev} pues aqu\'\i\  est\'an los dispositivos de cada nodo.
 Cuando los dispositivos de un nodo son totalmente distintos a los de otro
 no hay ning\'un problema (incluso poder acceder al dispositivo de otro nodo
 por este fichero ser\'\i a perfecto) pero si todos los nodos tuvieran por ejemplo
 un disco duro IDE conectado en el primer slot como maestro con 3 particiones,
 tendr\'\i amos repetidos en cada nodo {\tt hda1, hda2} y {\tt hda3}; por lo tanto tendremos
 que tener un nuevo esquema para nombrar los dispositivos.

  \item \underline{8.-Capacidad de comunicaci\'on de procesos y de intercambio de datos universal:}
 para conseguir este objetivo necesitamos una forma de distinguir un\'\i vocamente
 cada proceso del cluster. La forma m\'as sencilla es dando a cada proceso
 un PID \'unico, que llamaremos CPID (cluster process ID).
 Este CPID podr\'\i a estar formado por el n\'umero de nodo y el n\'umero de proceso
 dentro de ese nodo.
 Una vez podemos direccionar con que proceso queremos comunicarnos, para
 enviar se\~{n}ales necesitaremos un sencillo mecanismo de comunicaci\'on y seguramente el mismo sistema operativo en el otro extremo que entienda las se\~{n}ales.
 Para compartir datos, podemos enviarlos por la red o podemos crear memoria
 compartida a lo largo del cluster.
 Sobre como crear esta memoria compartida hablaremos en el cap\'\i tulo de sistemas
 operativos.
\end{itemize} 
Como se expone en el anterior apartado otras de las ventajas de los sistemas
 distribuidos es que cumple con todos los criterios de transparencia.
 Pero conseguir estos criterios implica ciertos mecanismos que debemos implementar: 
\begin{enumerate}
  \item {\bf Transparencia de acceso.}

Implica tener que mantener el viejo sistema para
 el nuevo cluster, por ejemplo mantener un \'arbol de directorios usual para
 manejar todos los dispositivos de almacenamiento del cluster.
 No tenemos que romper las APIs para introducir las nuevas funcionalidades.
 
  \item {\bf Transparencia de localizaci\'on.}

A nivel m\'as bajo tenemos que implantar una
 forma de conocer donde se encuentran los recursos, tradicionalmente se
 han usado servidores centralizados que lo sab\'\i an todo, ahora ya se va consiguie
ndo que esta informaci\'on se distribuya por la red.

  \item {\bf Transparencia de concurrencia.}

Esto que no es excesivamente complicado en
 un sistema local, se ha convertido en un quebradero de cabeza en un sistema
 distribuido.
 Se han desarrollado varios m\'etodos para conseguirlo.
 El mayor problema es la desincronizaci\'on de los relojes pues es muy complejo
 que todos los relojes hardware lleven exactamente la misma temporizaci\'on
 por tanto algunos ordenadores ven los acontecimientos como futuros o pasados
 respecto a otros ordenadores.
 Este tema se tratar\'a con m\'as profundidad en el cap\'\i tulo de sistemas operativos.
 
  \item {\bf Transparencia de replicaci\'on.}

B\'asicamente el problema es que el sistema
 sepa que esas r\'eplicas est\'an ah\'\i  y mantenerlas coherentes y sincronizadas.
 Tambi\'en tiene que activar los mecanismos necesarios cuando ocurra un error
 en un nodo.

  \item {\bf Transparencia de fallos.}

Aunque haya fallos el sistema seguir\'a funcionando.
 Las aplicaciones y los usuarios no sabr\'an nada de estos fallos o intentar\'an
 ser m\'\i nimamente afectados, como mucho, el sistema funcionar\'a m\'as lentamente.
 Este punto est\'a muy relacionado con la transparencia de replicaci\'on.

  \item {\bf Transparencia de migraci\'on.}

Tenemos que solucionar problemas sobre las decisione
s que tomamos para migrar un proceso, hay que tener en cuenta las pol\'\i ticas
 de migraci\'on, ubicaci\'on, {\em etc.}
 Adem\'as tenemos que ver otros aspectos pr\'acticos como si al nodo que vamos
 encontraremos los recursos que necesitamos, {\em etc.}
 La aplicaci\'on no tiene que saber que fue migrada.

  \item {\bf Transparencia para los usuarios.}

Implica una buena capa de software que
 de una apariencia similar a capas inferiores distintas.

  \item {\bf Transparencia para programas.}

La m\'as compleja. Implica que los programas no tienen porque usar llamadas al sistema nuevas
 para tener ventaja del cluster.
 Mosix hace esto muy inteligentemente tomando la natural divisi\'on en procesos
 de los programas para migrarlos de forma transparentemente.
\end{enumerate}
%===========================================================================
\subsection{La tendencia a lo distribuido}
Existen varios m\'etodos para intentar distribuir a nivel
 de aplicaci\'on, son m\'etodos que abstraen las capas inferiores y hacen la
 vida m\'as f\'acil a los programadores de las aplicaciones, que no se tendr\'an
 que preocupar sobre las peculiaridades de las capas inferiores consigui\'endose
 una mayor efectividad en la programaci\'on.
 Las tecnolog\'\i as que se ver\'an, en este orden, son:\\
\\
RPC: Remote Procedure Calls.\\
RMI: Remote Method Invocation.\\
CORBA: Est\'andar de comunicaci\'on de objetos.\\
Bonobo: Abstracci\'on sobre CORBA de GNOME.\\
KDE:  Desktop Enviroment. Veremos: KIO, XMLRPC, DCOP.\\
SOAP: Simple Object Access Protocol.\\

{\bf RPC.-}

El concepto de RPC o llamada a procedimiento remoto ha sido explotado desde
 hace ya varias d\'ecadas, de hecho, existen varias implementaciones creadas
 por distintos grupos e incluso varios protocolos.
 El concepto de llamada a procedimiento remoto no es otra que la que su
 propio nombre indica, es decir, se pretende ejecutar funciones o procedimientos
 en otras m\'aquinas distintas a la nuestra y que el resultado retorne a nuestra
 m\'aquina, todo ello de manera transparente.
 Hasta aqu\'\i\  el concepto de llamada a procedimiento remoto parece bastante
 asequible.
 El problema surge como siempre a la hora de implementarlo, codificarlo
 y tener en cuenta consideraciones de sistema.

 Para empezar se deben tener en cuenta cosas como que tipo de protocolo
 se va a utilizar en capas inferiores.
Puede ser {\bf conectivo}, perfecto para olvidarse de las retransmisiones y fallos
 o {\bf no conectivos} y aprovechar al m\'aximo la capacidad de la
 red. Tambi\'en hay que prestar atenci\'on al formato de
 representaci\'on entre distintas m\'aquinas de un mismo sistema, como
 podr\'\i an ser ASCII, EBCDIC o Little Endian y Big Endian, y en
 otros muchos problemas que implican las llamadas a procedimientos
 remotos\footnote{Como el paso de variables por referencia que implica
 el paso de un buffer, con lo que se tienen que tener en cuenta,
 fallos de consistencia o simplemente eficiencia del proceso.}.

Por \'ultimo (como colof\'on de las pegas de los sistemas implementados
 de los RPC) est\'a el que generalmente no son tan transparentes como debieran.
 En el caso ideal, se supone que, el programador no debe saber si los
 procedimientos de una biblioteca son locales o remotos, ni necesitar
 de ning\'un tipo de interface para poder llamar a dichos procedimientos. Esto no se cumple,
 no s\'olo en el caso de RPC, sino en pr\'acticamente cualquier sistema distribuido.
 
El RPC por excelencia es el RPC dise\~{n}ado e implementado por
 Sun Microsystems cuya versi\'on 2 esta especificada y tipificada en el RFC
 1831. En esta RFC se puede leer no s\'olo el modelo de llamada a procedimiento
 remoto, sino tambi\'en ejemplos de programaci\'on de RPC, sem\'anticas de transporte,
 sistema de autenticaci\'on y modelo de programaci\'on en general de esta implementaci\'on.
 Dicha implementaci\'on utiliza como modelo de comunicaci\'on IP/UDP ya que
 la mayor\'\i a de las aplicaciones suelen estar en una LAN y por tanto se obtiene
 m\'as efectividad que con TCP.
 Se utiliza tambi\'en XDR para hacer compatible entre varios formatos de representaci\'on.
 Los programas requieren de librer\'\i as y funciones especiales y al mismo
 tiempo se requiere rpcportmapper instalado como demonio para efectuar las
 transacciones.
 Existen varias referencias acerca de como podr\'\i a implementarse un sistema distribuido
 de este tipo en el libro {\em Sistemas Operativos Distribuidos} de Andrew S. Tanembaum.
 
?`Por qu\'e no utilizar RPC en sistemas distribuidos o clusters?
 Existen diversas causas, unas con m\'as peso que otras.
 Por norma general el modelo RPC suele ser bastante lento a pesar de utilizar
 UDP, por ejemplo en lo que se refiere al {\em checksum}, cambio de
 referencias en memoria, traducci\'on XDR, rellenado de cabeceras y
 otras tantas operaciones que hacen que dicho sistema sea compatible
 en un entorno de trabajo hetereog\'eneo.

 Es decir, en entornos de trabajo en los cuales no se requiere de
 confiabilidad, autenticaci\'on (y seguridad en general), eficiencia,
 y consistencia; la soluci\'on RPC es aceptable.
 En el caso de los clusters, suele implementarse con unos requerimientos
 de sistema bastante exigentes en lo que se requiere a eficiencia, y es
 mejor considerada una macro en el programa que utilizar todo un sistema
 como puede ser XDR.
 Generalmente los sistemas distribuidos suelen basar su desarrollo en nuevas
 implementaciones o modelos, que no tienen por que ser el de RPC, y no utilizan
 RPC debido a la poca eficiencia que este reporta y a la mala fama en seguridad
 que este posee.

\vspace{.3in}
{\bf RMI.-}

Tambi\'en desarrollado por Sun para Java, mucha gente considera a RMI el sucesor
 de RPC.

RMI es un concepto confuso, tiene dos aceptaciones:
  \begin{itemize}
    \item RMI es cualquier protocolo que invoque m\'etodos de objetos remotamente.
 Aparte de la implementaci\'on de Java, existen otras implementaciones que
 se pueden considerar RMI como las implementaciones de CORBA, DCOM y DCOP.
    \item RMI como Java RMI, se suele abreviar como RMI, es espec\'\i fico de Java y es
 del que hablaremos aqu\'\i\  pues las dem\'as tecnolog\'\i as las vemos en los siguientes
 apartados.
  \end{itemize}
RMI es un mecanismo que permite invocar un m\'etodo de un objeto que no existe
 en el espacio de direccionamiento de la propia aplicaci\'on, este otro espacio
 de direcciones puede encontrarse en la propia m\'aquina o en otra diferente.
 B\'asicamente podemos aplicar lo explicado en RPC pero teniendo en cuenta
 que este mecanismo es orientado a objetos.
 Comparando con el siguiente punto CORBA, aunque b\'asicamente ambos m\'etodos
 son un RPC para lenguajes orientados a objetos, CORBA es un estandard e
 independiente del lenguaje, RMI s\'olo es para Java.
 CORBA incluye muchos otros mecanismos en su est\'andar (lo que le hace ser
 una implementaci\'on m\'as lenta y pesada) que no son parte de RMI.
 Tampoco existe el concepto de ORB (Object Request Broker) en RMI.
 Java RMI ha estado evolucionando y convirti\'endose en m\'as compatible
 con CORBA, en particular hay ahora una nueva forma de RMI llamada RMI/IIOP
 (RMI sobre IIOP) que usa IIOP (Internet Inter-ORB Protocol de CORBA como
 protocolo de bajo nivel para las comunicaciones RMI.
 Por supuesto podemos imaginar las consecuencias para el rendimiento.

Hay 3 procesos que participan en que la invocaci\'on de m\'etodos remotos se
 haga efectiva:
  \begin{itemize}
    \item \underline{El cliente:} es el proceso que est\'a invocando a un m\'etodo en un objeto remoto.
    \item \underline{El servidor:} es el proceso al que pertenece el objeto remoto.
 El objeto remoto es un objeto ordinario en el espacio de direcciones del
 proceso servidor.
    \item \underline{El registro de objetos:} es el servidor de nombre que relaciona objetos con
 nombres.
 Objetos est\'an registrados con el registro de objetos.
 Una vez que un objeto ha sido registrado, cualquiera puede usar el registro
 de objetos para obtener acceso a los objetos remotos usando el nombre del
 objeto.
  \end{itemize}

Hay dos tipos de clases que pueden ser usadas en Java RMI.
  \begin{itemize}
  \item {\bf Remote class:} es una clase cuyas instancias pueden ser usadas remotamente.
 Un objeto de esa clase puede ser referenciado de dos maneras:
    \begin{enumerate}
      \item Dentro de su propio espacio de direcciones donde el objeto fue construido,
 este objeto es un objeto ordinario Java.
      \item Dentro de otro espacio de direcciones, el objeto puede ser referenciado
 usando un manejador de objeto.
 Aunque hay limitaciones en c\'omo se puede usar un manejador de objeto comparado
 con un objeto, la mayor parte del tiempo los manejadores de objetos se
 pueden usar de la misma forma que un objeto.
    \end{enumerate}
  \item {\bf Serialized class:} las instancias de este objeto ({\em serializable object}) pueden ser copiadas de un espacio de direcciones a otro.
 Se puede usar para el protocolo entre objetos.
 Si uno de estos objetos es pasado como par\'ametro (o es un valor de retorno)
 de una invocaci\'on remota a un m\'etodo, entonces el valor del objeto ser\'a
 copiado de un espacio de direcciones a otro.
 En cambio si un {\em remote object} es pasado como par\'ametro ( o valor de retorno) el manejador del objeto
 ser\'a copiado de un espacio de direcciones a otro.
 \end{itemize}

\vspace{.3in}
{\bf CORBA.-}

Es un est\'andar desarrollado por una fundaci\'on creada por distintas empresas
 llamada OMG ({\em Object Management Group}) para poder hacer
 f\'acilmente programaci\'on distribuida, reutilizaci\'on de objetos y de c\'odigo ya hecho.
 CORBA cumple correctamente estos objetivos, para ello la estructura de
 CORBA cuenta de un lenguaje estandar llamado IDL (Interfaz Definition Language)
 que sirve para determinar los interfaces entre objetos, la implementaci\'on
 de los objetos se hace con cualquier lenguaje que tenga un compilador capaz
 de enlazar IDL.

 CORBA es un {\em middleware} entre el sistema operativo y las aplicaciones usuario,
 entre ese middleware se encuentra el ORB encargado de hacer las llamadas
 entre objetos.
 En resumidas cuentas, CORBA es un nivel m\'as de abstracci\'on.\\
 
{\bf --- Ventajas:}
\begin{itemize}
  \item Abstrae a la aplicaci\'on de todo lo referente a las comunicaciones, el programa
 ni siquiera sabe donde esta el objeto al que llama.

  \item Se pueden reutilizar programas anteriores simplemente a\~{n}adiendo algo de
 c\'odigo 

  \item Tiene todas las ventajas de la programaci\'on orientada a objetos.

  \item Se puede programas en varios lenguajes.
 Puedes crear un programa con varios lenguajes distintos ya que cada una
 de las partes solo ver\'a el interfaz CORBA de la otra.

  \item Las simplificaciones en la programaci\'on deber\'\i an llevar a una programaci\'on
 con menos errores.

  \item Abstrae el Sistema Operativo.
 
  \item Es un est\'andar para todas las plataformas y abierto.
\end{itemize}

{\bf ---Desventajas:}
\begin{itemize}
  \item M\'as capas de software, m\'as carga.

  \item Usa RPC en su nivel m\'as bajo, anteriormente explicamos los problemas que
 acarrea esto.

  \item En sus versiones Real Time o QoS necesita dar preferencia a unas llamadas
 sobre otras para conseguir el objetivo.

  \item CORBA es muy grande, un fallo en CORBA podr\'\i a ser dif\'\i cil de detectar.

  \item Aunque se necesite a\~{n}adir poco c\'odigo las aplicaciones se necesitan reescribir.

  \item Un objeto se ejecuta en el sistema que le alberga.
\end{itemize}
Aunque haya m\'as ventajas que inconvenientes estos \'ultimos son
 m\'as relevantes puesto que no podemos suponer que los procesos con los que trabajemos vayan a estar
 desarrollados en CORBA, adem\'as CORBA no nos soluciona el problema de migrar
 procesos y si lo hiciera ser\'\i a extremadamente lento.

 A\'un se podr\'\i a pensar en usar CORBA para env\'\i o de mensajes, pero la sobrecarga
 que genera no merece la pena.
 CORBA es muy potente para aplicaciones distribuidas o no de nueva creaci\'on
 y seguramente se le pudieran a\~{n}adir funciones de balanceo de carga, pero
 para que nuestra soluci\'on sea m\'as general es preferible no usar CORBA y
 tratar todo a nivel de proceso, sin abstracciones mayores.
 Aunque el est\'andar CORBA no a\~{n}ade estas capacidades de balanceo, implementaci\'on
es espec\'\i ficas si que tienen reconfiguraci\'on din\'amica, por ejemplo, Dinamic
 TAO.

\vspace{.3in}
{\bf Bonobo.-}

Abstracci\'on por encima de CORBA desarrollada por el proyecto GNOME.

Bonobo es un conjunto de interfaces CORBA, algunos implementados por objetos
 contenedores y otros por los objetos que ser\'an contenidos (por ejemplo
 cuando pulsamos sobre un pdf y este se abre en nuestro propio navegador,
 el navegador es el contenedor y el programa lector de pdf el contenido).
 Bonobo es tambi\'en una implementaci\'on por defecto de estos interfaces CORBA
 que es exportado en forma de API C para evitar a la mayor\'\i a de
 los programadores de preocuparse por tener que codificar directamente
 los interfaces CORBA.

Aunque no lo hemos mostrado en el punto anterior la programaci\'on en CORBA
 es ciertamente compleja, por tanto dentro del esfuerzo del proyecto GNOME
 para incorporar CORBA se ha desarrollado una librer\'\i a de un nivel m\'as alto
 llamada Bonobo (el nombre es de ciertos monos en v\'\i as de extinci\'on que
 sirven para ilustrar la teor\'\i a de conexi\'on de componentes).
 Otro de estos desarrollos fue ORBit que es un ORB pero con la particularidad
 de estar altamente mejorado en velocidad, siendo el m\'as r\'apido existente
 (casi el doble que su m\'as cercano competidor Omniorb) y de los que menos
 memoria necesita.

A parte de ORBit tenemos Gnorba que facilita en algo algunas tareas de ORBit
 y es m\'as espec\'\i fico de GNOME, por ejemplo permite la integraci\'on del bucle
 principal de ORBit con el bucle principal de Gtk+, a\~{n}ade seguridad a las
 comunicaciones y un m\'etodo est\'andar para acceder al servicio de nombres
 de GNOME.
 Para permitir acceso a un objeto en concreto se dispone la informaci\'on
 en GOAD ({\em GNOME Object Activation Directory}) donde tenemos el id
 del objeto, las interfaces que exporta y como crear un ejemplar,
 gracias a esto se pueden usar m\'etodos a trav\'es de la red.


Bonobo se cre\'o para intentar mantener las aplicaciones con poca complejidad
 para que a los nuevos programadores les cueste poco saber c\'omo funciona
 el c\'odigo y sea m\'as f\'acil el mantenimiento y desarrollo.
 Usando todas las facilidades de CORBA que es usado para la capa de comunicaci\'on
 y para unir todos los componentes Bonobo entre s\'\i .
 Cada componente tiene su interfaz (definido en t\'erminos de las interfaces
 CORBA) que exporta, ah\'\i  es donde cualquier otro componente puede conseguir
 informaci\'on o unirse al componente.

El interface CORBA se introduce en un objeto GTK+, esto quiere decir que
 los objetos GTK+ son la implementaci\'on del interface IDL.
 Las implementaciones contienen ciertas acciones por defecto para no molestar
 al programador con detalles de CORBA, pero se dan unos m\'etodos para cambiar
 este comportamiento.

\vspace{.3in} 
{\bf KDE.-}

En este apartado vamos a ver tres tecnolog\'\i as que utiliza KDE a partir de
 sus versiones 2.0 y posteriores:
\begin{enumerate}
  \item KIO: entrada y salida , transparencia de red.
  \item XML-RPC: manejo de programas remotamente.
  \item DCOP: comunicaci\'on entre componentes Kparts.
\end{enumerate}

Estas tres tecnolog\'\i as permiten acercarnos a un proceso distribuido y a
 una transparencia de red enormes.
 KDE es muy buen ejemplo de c\'omo se intenta cumplir algunos de los objetivos
 de los sistemas distribuidos, y c\'omo usuarios que somos de este entorno
 podemos decir que esta tecnolog\'\i a hace el d\'\i a a d\'\i a m\'as sencillo.
 
\begin{itemize}
  \item 1.- KIO: 

Esta es la librer\'\i a que implementa pr\'acticamente todas la funciones de manejo
 de ficheros.
 Es la librer\'\i a que se usa para proveer un manejo de ficheros transparente
 a red.
 La implementaci\'on de los distintos protocolos (FTP, HTTP, SMB, POP3, IMAP4,
 gopher, printer, man, gzip, {\em etc.}) es hecha por un proceso independiente
 llamado kioslave, uno por cada protocolo, kio\_ftp implementa FTP, kio\_http
 implementa HTTP {\em etc.}
 La aplicaci\'on indica el protocolo a usar y KIO decide que kioslave usar.

Por tanto gracias a estos kioslaves por ejemplo podemos tener acceso transparent
e a servidores ftp, subir y bajar informaci\'on simplemente copiando y pegando
 o haciendo {\em drag'n drop}.
 Podemos tener acceso a discos remotos e informaci\'on remota de forma totalmente
 transparente.
 Un usuario sin mucho conocimiento de inform\'atica podr\'\i a incluso nunca darse
 cuenta de que no estaba accediendo a su propio disco duro.

\item 2.-XML-RPC

Esta tecnolog\'\i a no es espec\'\i fica de KDE sino que se usa en este entorno
 como en otros, vamos a ilustrar el ejemplo de KDE.
 En KDE existe el kxmlrpcd que permite que un cliente escrito en cualquier
 lenguaje, en cualquier plataforma pueda acceder a los servidores DCOP de
 KDE .
 Como casi todas las aplicaciones de KDE son servidores DCOP, se puede manejar
 este entorno remotamente, de forma transparente.
 Por tanto vemos una vez m\'as que el l\'\i mite entre local y remoto se difumina
 permiti\'endonos ejecutar KDE como si estuvi\'eramos ejecutando un telnet.
 
XmlRpc es la forma est\'andar de implementar RPC usando XML y HTTP.
 Con XML se marcan todas las llamadas a funciones , sus par\'ametros y sus
 valores de retorno.
 Entonces se utiliza HTTP para transferir la llamada al m\'etodo.
 Much\'\i simos lenguajes disponen de parsers XML y clientes HTTP por lo que
 la implementaci\'on es bastante sencilla.
 Como el proyecto KDE ya ten\'\i a el protocolo DCOP para hacer RPC e IPC, kxmlrpcd
 es b\'asicamente un traductor (servidor web por soportar HTTP), que traduce
 las peticiones XmlRpc en llamadas a DCOP y viceversa.
 Tanto el cliente XmlRpc como el servidor DCOP creen que est\'an comunic\'andose
 solamente en su protocolo nativo con el demonio.
 
  \item 3.- DCOP : Desktop COmunication Protocol

Fue creado por la necesidad de comunicaci\'on entre aplicaciones, no pod\'\i an
 usar X Atoms por ser demasiado simples y crear una dependencia con Xwindow.
 Tambi\'en estuvieron intentando implementar CORBA pero se dieron cuenta que
 para la simple tarea de intercomunicar tareas era demasiado lento y requer\'\i a
 demasiada memoria, adem\'as no ten\'\i a ning\'un tipo de autentificaci\'on.

Lo que realmente se quer\'\i a era un protocolo simple con autentificaci\'on b\'asica,
 aunque no fuera capaz de hacer todo lo que era capaz de hacer CORBA, pero
 que fuera suficientemente bueno para la tarea encomendada.
 Un ejemplo de estas llamadas es una aplicaci\'on reci\'en iniciada que pregunta
 si hay otra aplicaci\'on con el mismo nombre abierta, si es as\'\i\  abrir\'a una
 nueva ventana en la antigua aplicaci\'on en vez de abrir una nueva.

DCOP es un mecanismos IPC/RPC muy simple que funciona sobre sockets.
 Est\'an soportados los sockets del dominio UNIX y TCP/IP.
 Como capa inferior utiliza el protocolo ICE (Inter Client Exchange), que
 viene est\'andar como parte de X11R6.
 Tambi\'en depende de Qt, pero m\'as all\'a de estos requerimientos no necesita
 m\'as librer\'\i as.
 Es una capa de software muy ligera.

Las aplicaciones son clientes DCOP y se comunican entre s\'\i  a trav\'es de un
 servidor DCOP, que funciona como director del tr\'afico, enviando los mensajes
 o las llamadas a los destinos apropiados.
 Todos los clientes son pares entre ellos.
 Hay dos tipos de acciones posibles:

\underline{Mensajes:} en estos mensajes se env\'\i a el mensaje y no se espera la vuelta,
 por lo que la llamada no bloquea y es muy r\'apida.

\underline{Llamadas:} se llama a una funci\'on y se debe esperar a que se devuelva alg\'un
 dato.

Para crear las llamadas se ha desarrollado un compilador al estilo del
 compilador IDL que vimos en CORBA, llamado dcopidl (y dcopidl2cpp)
 que generan los stubs y skels al estilo que CORBA lo hac\'\i a para ahorrar el trabajo del
 programador.

En definitiva DCOP provee un m\'etodo sencillo y eficiente que fue desarrollado
 exactamente para ese uso que evita la complejidad de CORBA pero que tambi\'en
 permite la interconexi\'on de objetos en una m\'aquina o en m\'aquinas distintas.
 Adem\'as en uni\'on con XML-RPC del cap\'\i tulo anterior se permite usar este
 protocolo desde cualquier lenguaje que era otra de las caracter\'\i sticas
 de CORBA.

Las ventajas para crear aplicaciones distribuidas usando este protocolo
 son las mismas que se vieron en el apartado de CORBA.
\end{itemize}

{\bf SOAP.-}

Hoy en d\'\i a lo que se le pide a un sistema que use RPC o RMI es que
 sea confiable, robusto, que tenga APIs desarrolladas para varios
 lenguajes, interoperabilidad entre lenguajes, plataformas y modelos
 de componentes.

 Desafortunadamente no hay un \'unico sistema que tenga todas esas caracter\'\i sticas.
 El formato de los datos y el protocolo usado para intercambiarlos es un
 factor determinante en el grado de interoperabilidad que pueden alcanzar
 las aplicaciones.

 XML(eXtensible Markup Language) se est\'a convirtiendo en un estandar para
 representar datos en un formato independiente de la plataforma.
 XML es un lenguaje f\'acil de general y de leer.
 HTTP (HyperText Transfer Protocol) tambi\'en se est\'a convirtiendo en un protocolo
 muy usado gracias a las aplicaciones web, que est\'a soportado por todos
 los sistemas.

 Las peticiones/respuesta de HTTP se pasan a trav\'es de firewall y son manejadas
 de forma segura, todo lo contrario que una ejecuci\'on de una llamada RPC
 o RMI.

 Por lo tanto XML sobre HTTP parece una forma bastante inteligente para
 las aplicaciones distribuidas de comunicarse entre ellas.
 SOAP hace exactamente eso.

 Representando RPCs de forma independiente a la plataforma, abre la posibilidad
 de implementar otros protocolos espec\'\i ficos de arquitectura en SOAP.
 Por ejemplo Microsoft parece querer usar SOAP como protocolo intermedio
 de intercambio al que otros protocolos pueden ser f\'acilmente traducidos,
 para potenciar el uso de sus componentes COM.

RPC en SOAP son interacciones cliente servidor sobre HTTP donde la petici\'on/resp
uesta se hacen de acuerdo con las reglas SOAP.
 Para elegir el objeto se usa el URI (Universal Resource Identifier) que
 es propio de HTTP o la cabecera SOAPAction que indica el nombre del interface.
 Se especifica una convenci\'on de la llamada remota , que determina la representa
ci\'on y el formato de las llamadas y respuestas.
 Una llamada es un dato compuesto con varios campos, uno por cada par\'ametro.
 Un mensaje de retorno es un valor de retorno y unos par\'ametros.
