El Distributed Computer Enviroment (DCE) es un entorno de computación distribuida independiente de vendedores definido por la Open Software Foundation.
DCE soporta la construcción e integración de aplicaciones basadas en clientes/servidores en C en entornos distribuidos heterogéneos.
 

3.1. LA CÉLULA DE DCE

  Una célula DCE es una colección de máquinas , usuarios y recursos manejados como un grupo. como un departamento dentro de una empresa.
Una célula tiene su propio Security Service, Cell Directory Service y opcionalmente Distributed File Service.

El Security Service para una celda controla el registro de la célula, donde se guarda la información de las cuentas de usuario. Cada célula tiene su propio espacio de nombres . El Cell Directory Service controla el espacio de nombres y su jerarquía. Si la opción de DFS esta presente el Distributed File Service permite acceso remoto a los ficheros desde cualquier parte de la célula. Cada célula tiene además su propio Distributed Time Service, que mantiene los relojes de todas las máquinas en la célula sincronizados.

Una célula provee un único dominio de seguridad . Las Acces Control List identifican a los usuarios y grupos dentro de una célula . Además cada célula tiene un nombre y todos los objetos de la célula comparten ese nombre.
Una célula puede tener más de un nombre, aunque siempre uno de ellos actuará como nombre primario y el resto como alias. El nombre primario es el nombre por defecto, el que devolverán los servicios DCE. Los alias permiten a la célula estar registrada en más de un espacio de nombres global, y facilitan cambios de nombres por razones logísticas.

Las células pueden estar conectadas unas con otras para así poder comunicarse. Para conectar unas células con otras se utiliza el Global Directory Service, una vez que la célula está registrada en dicho servicio, puede conectarse con todas las demás ya registradas. La comunicación entre células no es automática sino que dos células que quieren comunicarse primero deben de realizar un proceso llamado "cross-cell authentication" por el que sus servicios de seguridad se ponen en contacto para verificarse.

Una célula DCE puede configurarse de muchas formas dependiendo de los requerimientos del usuario.Una célula está compuesta por una red con tres clases de nodos:

        - DCE User Machines: Máquinas de propósito general que contienen software que les permite actuar como clientes de todos los servicios DCE.

        - DCE Administrator Machines: Contienen software que permite al administrador dirigir el sistemas de servicios DCE remotamente.

        - DCE Server Machines: Son máquinas provistas de un software especial que les permite proveer uno o más servicios DCE. Cada célula debe tener al menos un servidor de cada uno de los siguientes servicios:

                        - Cell Directory Server
                        - Security Server
                        - Distributed time Server

También pueden estar presentes otros servicios como el Global Directory Agent, Local File System...

 
3.2. LA ARQUITECTURA DE DCE

 Los componentes de DCE son los que se muestran en la figura y que explicaremos a continuación

                                                            FIGURA 5: Arquitectura de DCE

Los componentes de DCE pueden agruparse en dos categorías: Facilidades para la programación Distribuida y Servicios Distribuidos. Los DCE Threads y los componentes RPC son facilidades que incluyen librerías que implementan API's (Application Programming Interfaces) .

El resto de componentes DCE son servicios distribuidos, y consisten en una parte de daemon que esta en ejecución permanente para servir las peticiones de la red. También cuentan con API's por las que el programador puede acceder al servidor.
En general, los programadores de aplicaciones trabajan más con las facilidades threads y RPC, aunque indirectamente usan los servicios DCE pues son utilizados por RPC. Por el contrario los administradores de sistemas tratan más con los servicios distribuidos ya que con ellos puede controlar y dirigir el sistema.

 
 3.1.1. Distributed Time Services (DTS)

Sincroniza todos los relojes de los diferentes host en una célula DCE. DTS sincroniza periódicamente todos los relojes y provee de un mecanismo para mantenerlos cercanos al valor correcto utilizando el estándar Universal Time Coordinated.
DTS es capaz de interoperar con el Network Time Protocol, el estándar de tiempos más usado en Internet, de forma que un servidor NTP puede darle le tiempo a un sistema DTS y viceversa.

El DTS está compuesto de:

a) Time Clerk: es la parte cliente de DTS, mantiene la máquina servidora local sincronizada preguntando periódicamente a los servidores por el tiempo correcto y ajustando el valor de la máquina local.

b) Time Servers: Un Time Server es un nodo cuya función es contestar las peticiones acerca del tiempo. El Time Clerk consulta al Time Server por el tiempo, para sincronizarse, y el time Clerk pregunta a los otros Time Clerk de la red para ajustar el valor de los relojes entre ellos. Normalmente suele haber tres Time Server por LAN.

Los diferentes tipos de servidores de tiempos son:

                                                        Local Time Server
                                                        Global Time Server
                                                        Courier Time Server
                                                        Backup Courier Time Server

 c) DTS Application Programming Interface: DTS provee una librería API que permite a los programadores manipular los "timestamps".

d) Time Provider Interface: Es el mecanismo por el que a nuestra máquina le llega el tiempo correcto desde el exterior.

e) Time Format: DTS utiliza el estándar de formato de tiempos UTC que marca el tiempo desde el 15 de octubre de 1582, el principio del calendario Gregoriano. Para interpretarlo utilizan el Time Differential Factor que da valores diferentes ajustados a las zonas horarias.

Los componentes activos son el Time Clerk y los diferentes tipos de servidores.

3.1.2. Security Services

Los servicios de seguridad proveen comunicaciones seguras y accesos controlados a recursos en el sistema distribuido.
Estos servicios soportan,

• autentificación: usando Kerberos v5, de forma que los clientes y servidores pueden probar quien son.
• autorización: los servidores pueden utilizar listas de control de acceso (ACL's) para determinar que un cliente está autorizado a obtener el servicio que solicita.
• integridad: con un control de checksums se garantiza que la información recibida es exactamente la que se transmitió.
• privacidad: la encriptación DES protege a la información de posible "aperturas" mientras es transmitida entre clientes y servidores.

La Login Facility inicializa un entorno de seguridad para el usuario.

El Register Service dirige la DCE Security Database, base de datos en la que se almacena la información necesaria para el control de seguridad.

El Audit Service monitoriza los eventos que se van sucediendo y que pueden ser relevantes en materia de seguridad.

Cuando una célula es creada, el administrador de la seguridad en el sistema ejecuta un programa para crear la base de datos de seguridad inicial . Entonces, inicia el Security Service, llamado secd, en la misma máquina donde crea la base de datos. Usando el programa dcecp el administrador crea cuentas de usuario en la base de datos.

Una vez el administrador ha creado una cuenta para el usuario, éste puede participar del sistema DCE seguro. Cuando el usuario inicia una sesión La Login Facility interactúa con los servidores de autentificación y el de privilegios; envía una petición al servidor de autentificación con los credenciales del usuario que ha abierto la cuenta. La respuesta del servidor de autentificación va encriptada usando la clave del usuario, por lo que si el usuario da la clave correcta podrá desencriptar el mensaje. Estos mensajes enviados por el servidor de autentificación se llaman tickets y los usan los clientes para darse a conocer a los servidores como los clientes auténticos.

Después la Login Facility envía el ticket al servidor de privilegios, que devuelve un EPAC ( Extended Privilege Attribute Certificate ) que contiene información específica de la autorización del usuario.

Los EPAC son usados para autorizar a usuarios. Cuando la Login Facility termina su ejecución el usuario cuenta con un entorno seguro y puede comunicarse de forma segura con las aplicaciones servidoras.

La información de autorización y autentificación viaja por la red encriptada de forma que solo los clientes adecuados pueden desencriptarla y leer los mensajes. Si se desea la información de la aplicación puede también encriptarse lo que nos protege de que usuarios no autorizados accedan a dicha información.
Todos los eventos que suceden en los servicios de seguridad son grabados en un fichero por el Audit Service Daemon, o auditd.
Los servicios de seguridad de DCE están integrados en el DCE RPC, por lo que un programador no necesitará tratar directamente con estos servicios.

Por último, comentar la relación existente entre el Security Service de DCE y Kerberos. El servicio de autentificación de DCE está basado en MIT Project Athena's Kerberos Network Authentication Service y el KDC (Kerberos Key Distribution Center ) server es parte del servidor de servicios de seguridad secd

 
3.1.3. Directory Services

El Directory Service es el almacén central de información acerca de los del recursos (usuarios, máquinas, servicios basados en RPC...) en el sistema distribuido. La información que guarda es el nombre del recurso y los atributos asociados a él ( directorio home del usuario, la localización del servidor RPC...).

El DS un servicio de base de datos replicada y distribuida. Es distribuida porque la información que almacena la base de datos está guardada en diferentes lugares. Es replicado porque la información acerca de un nombre dado o un grupo de nombres puede ser guardada en más de un lugar, par una mayor disponibilidad. La base de datos está formada por una serie jerárquica de nombres llamada el espacio de nombres, que tienen asociados una serie de atributos.
El Directory Service ofrece a sus usuarios un almacén central de información, utilizable desde cualquier lugar de la red.

Soporta la administración de dominios DCE llamados células y la resolución del nombramiento entre células. Estos servicios están compuestos por:

El paquete de threads DCE es una librería de threads al nivel usuario que está basada en la interface definida por POSIX en su estándar 1003.4a (Portable Operating System Interface for UNIX) que soporta la creación, manejo y sincronización de múltiples threads de control dentro de un cliente o servidor.

Esta parte es conceptualmente parte del sistema operativo subyacente a DCE. Si el sistema operativo del host soporta threads DCE puede utilizar este software y entonces no es necesario este paquete. Sin embargo como no todos los sistemas operativos contienen el software necesario para el uso de threads, DCE incluye su propio software. Este consiste en una API que da a los programadores la capacidad de manipular threads.

Un cliente multi-thread puede realizar trabajo adicional, mientras una RPC está pendiente. Un entorno distribuido basado en el modelo cliente/servidor y RPC puede beneficiarse del uso de los múltiples threads de control. Cuando un cliente realiza una llamada RPC, se bloquea hasta que recibe la respuesta del servidor. Si en el sistema cliente hay múltiples threads de control, otro thread puede continuar con el trabajo mientras el thread que espera la respuesta del servidor sigue bloqueado.

En la parte del servidor, el despachador que en el servidor recibe la RPC e invoca al manejador adecuado es también un multi-thread, lo que permite manejar a un servidor manejar varias RPC's concurrentemente.

El numero máximo de RPC's concurrentes en el servidor es configurado por el desarrollador que es el responsable de asegurar el correcto funcionamiento del manejo de las RPC's.

Para saber en cada momento cual de los múltiples threads ha de ejecutarse existe una planificación basada en dos mecanismos que interactuan entre si, el método basado en las prioridades de los threads y las distintas políticas de planificación.

Cada thread tiene asociada una prioridad y tienen preferencia de ejecución los que poseen una prioridad más alta. El tratamiento de los threads de diferentes prioridades está basado en una de las tres políticas siguientes:

                a) Firts-In, First-Out (FIFO), en esta planificación el thread del grupo con mayor prioridad que ha estado esperando durante más tiempo empieza a ejecutarse. Cuando este se bloquea, entra a ejecutarse el thread que más tiempo lleva esperando después que el anterior. Cuando se terminan los procesos de la mayor prioridad se pasa a los de la prioridad siguiente que se ejecutan del mismo modo, primero el que antes ha llegado, es decir, el que más tiempo lleva esperando.

                b) Round-Robin: Según esta planificación todos los threads de la misma prioridad se van turnando en ciclos para acceder al procesador. Cuando se ha terminado, tras uno o varios ciclos, la ejecución de todos los threads de una prioridad se pasa al siguiente grupo de prioridad inferior.

                c) Modo por defecto: A cada thread se le da un tiempo de ejecución y se le concede un turno. A los threads de mayor prioridad se les concede un tiempo de ejecución bastante alto, mientras que los threads de baja prioridad corren eventualmente en el procesador. Este método contrasta con los dos anteriores ya que es posible que corran threads de baja prioridad en el procesador antes de que se termine la ejecución de todos los threads de prioridad superior.

 3.1.5. Remote Procedure Call (RPC)

  Una aplicación distribuida basada en el modelo cliente/servidor necesita de unos mecanismos para que ambas partes (cliente y servidor) puedan comunicarse. Una de las formas en las que puede implementarse la comunicación es la llamada a procedimiento remoto (RPC).

Con RPC se puede llamar a un proceso que se está ejecutando en una máquina distinta a la que estamos utilizando, de forma que parezca ante es usuario que se está realizando una llamada local a procedimiento.
RPC es el mecanismo por el que los clientes invocan a los servicios dispuestos por los servidores. Un procedimiento remoto se identifica de la siguiente forma:

{ numero de programa, numero de versión, numero de procedimiento }

los dos primeros números identifican al programa servidor y el tercer identificador es el de el procedimiento perteneciente al programa servidor al que queremos llamar.
Un cliente ha de usar los Directory Services para conectarse al servidor en que está interesado en tiempo de ejecución, y tanto el cliente como el servidor deben de utilizar los Security Services para garantizar la autentificación, autorización, integridad y privacidad de la comunicación.
En la figura se muestra el mecanismo para la comunicación entre clientes/servidor:

                                                    FIGURA 6: Comunicación cliente/servidor

 
El servidor queda a la escucha de peticiones en un puerto especifico para esa tarea. Cuando un cliente requiere alguno de los servicios, envía una petición a dicho puerto preguntando por la localización del servicio que necesita. A continuación el Portmapper le informa de la localización del puerto por el que será atendida la petición al procedimiento que desee, al que el cliente enviará ya la petición con los datos pertinentes.

 El mecanismo de RPC aísla a los clientes de los detalles como la localización de los servidores en la red, el tipo e plataformas sobre el que están corriendo, la representación de los datos en las diferentes plataformas cliente y servidor, la fragmentación y reensamblaje de los mensajes, uso de servicios de seguridad en las comunicaciones...
 
El RPC esta formado por una herramienta de desarrollo y un servicio en tiempo de ejecución.
La herramienta de desarrollo consiste en un lenguaje de programación ( y su compilador) que soporta el desarrollo de aplicaciones distribuidas siguiendo el modelo cliente/servidor. Automáticamente transforma las llamadas a procedimiento en mensajes de red.
El servicio en tiempo de ejecución implementa los protocolos de red necesarios para la comunicación entre las partes cliente y servidor de una aplicación.
Además RPC incluye software para la generación de identificadores únicos que son muy utilizados para identificar la interface del servicio y otros recursos.
Pero conozcamos estos y otros elementos que componen DCE RPC más a fondo:
 

• El Interface Definition Language (IDL) y su compilador: En el fichero IDL se describe una interface RPC. Este fichero es compilado con el compilador de IDL dentro del código del objeto. El programador de la aplicación define una interface y los tipos de datos asociados a ella mediante el IDL. La forma del interface es similar a la de un modulo o librería de un lenguaje de programación convencional. Entonces, el programador compila la interface descrita en el fichero IDL con el compilador que nos proporciona el Interface Definition Language y como resultado obtenemos los siguientes procesos: client stub, server stub y un fichero de cabecera. Los dos stubs son las rutinas encargadas de que las llamadas remotas parezcan locales de cara al usuario, y para generarlas seguimos los siguientes pasos.
• La RPC Runtime Library: Esta librería está compuesta de una serie de rutinas linkadas con las partes cliente y el servidor de la aplicación y que implementan la parte de comunicación entre ambos. Esto incluye la búsqueda del servidor por parte del cliente, el procesado de errores, enviado y recepción de mensajes..
• Authenticated RPC: DCE RPC está integrado con el componente de DCE Security Service para ofrecer comunicaciones seguras. Los niveles de seguridad pueden ser controlados por el programador de la aplicación a través de la Authenticated RPC API.
• Name Service Independent (NSI) API: El DCE RPC está también integrado con el componente Directory Service para facilitar la localización de servidores basados en RPC por sus clientes. El NSI permite al programador controlar la asociación de un cliente a un servidor por RPC.
• DCE Host Daemon: El dced, es un programa que corre en todas las máquinas DCE. Incluye , entre otros, un servidor de nombres especifico de RPC llamado "endpoint mapper service", que dirige una base de datos que asocia los servidores RPC con los "puntos" (como los puertos en IP) a los que está escuchando.
• El DCE Control Program: El dcecp es una herramienta para la administración de DCE.
• UUID Facility: Son comandos y rutinas que generan Universal Unique Identifiers (UUID's), que identifican de forma única a una interface RPC u otro recurso. El programa uuidgen puede generar también plantillas de IDL como modelo para interfaces con un identificador único para dicho interface.

En el lado del servidor es donde va a estar la mayor parte del código RPC de las aplicaciones distribuidas, el programador escribirá las rutinas que implementan las operaciones descritas en el fichero IDL. El stub del servidor (generado por el compilador IDL) está linkado al código de la aplicación correspondiente al servidor, y es el encargado de desempaquetar la información que le llega pasando a la operación adecuada los argumentos que recibe y mandado ejecutar a la vez dicha operación.

Para que el cliente pueda comunicarse con el servidor que desea debe conocer de alguna forma donde se encuentra este servidor. DCE libera al usuario de esta carga, utilizando el Directory Service. El cliente le pregunta al Directory Service donde se encuentra el servidor que ofrece la interface X que él necesita. Para que el Directory Service conozca esa localización es necesario que el servidor se haya dado de alta, indicando los servicios que ofrece, que protocolos soporta para la comunicación y donde se encuentra en la red. De este modo al cliente no le importa que el servidor cambie de dirección, pues él solo consultará al Diretory Service que estará actualizado en todo momento.

La dirección del servidor viene dada por dos componentes, la localización de la máquina que está corriendo dentro de la red (es una dirección bastante estable) y la dirección del proceso servidor dentro de esa máquina. Esta última dirección puede variar cada vez que se reinicia el proceso servidor. Para no tener que actualizar directamente la Cell Directory Service cada vez que esto sucede, DCE propone un tipo especializado de directory service, el Endpoint Mapper Service (un servicio del daemon dced).

Una máquina que contiene a un servidor siempre ejecuta un daemon dced; el puerto en el que el dced está escuchando es fijo. Una vez que el cliente sabe en que máquina está ejecutándose el proceso al que desea llamar, puede localizar al Endpoint Mapper Service y preguntarle a que "puerto" debe enviar sus peticiones.

En resumen, veamos como funciona todo el proceso de llamada RPC.

El servidor, después de darse de alta en el Cell Directory Service, iniciará su ejecución y quedará en escucha de posibles peticiones en la red.

En algún momento un cliente requerirá de los servicios de alguna interface remota. El código cliente llamará a la RPC Runtime para encontrar al servidor que ofrece la operación que necesita. El código de la aplicación cliente hace una llamada a procedimiento remoto, lo que se convierte en una llamada al stub del cliente. El stub convertirá los argumentos de la llamada a un formato de mensaje de red, y llamará a la RPC Runtime Library para que envíe el mensaje.

La petición RPC es recibida por la máquina servidora por la RPC Runtime que estaba a la escucha y pasa el mensaje al stub del servidor, que como ya hemos dicho, desempaqueta los datos y los envía a la operación especificada.

El resultado de la operación realizada toma el camino inverso; una vez ejecutada, la operación devuelve el resultado al stub servidor, quién después de empaquetarlo se lo pasa a la Runtime La RPC Runtime lo envía por la red al cliente.

En la máquina cliente la Runtime recibe la respuesta y la cede al stub cliente, éste desempaqueta la información y la pasa al proceso que formuló la petición.

Todo esto sucede de forma transparente al usuario, de modo que jamas toma conciencia de dejar de trabajar en una máquina diferente a la que tiene enfrente de él.

Otro hecho muy importante en RPC es la independencia del sistema. RPC funciona indistintamente en cualquier sistema operativo, sobre cualquier plataforma hardware, independiente de los lenguajes de programación utilizados, los mecanismos de transferencia de datos y los protocolos de red.

Independencia del Lenguaje: Los stubs generados por el compilador IDL, pueden ser llamados desde programas escritos en cualquier lenguaje de programación.
La única imposición es la forma de llamar a los procedimientos de los stubs, que sigue las convenciones de una llamada a procedimiento C.

Independencia de la Representación de los Datos: El formato de representación de datos por defecto es el DCE Transfer Syntax, que es el modo de representar los datos en la red. (Network Data Representation). Esta NDR ofrece varios tipos canónicos de datos a los que debe transformar el emisor el tipo que él tiene definido para la transmisión por red.
Cuando un cliente realiza una petición, el stub cliente se encarga de transformar los datos de la representación interna de la máquina cliente a una representación externa estándar en la red. El servidor al recibir la petición la transformará de la representación estándar a la propia de la máquina servidora, trabajará con ella y a la hora de devolver al cliente los resultados de la operación repetirá el proceso de transformación de datos.
El formato interno del emisor y el receptor puede coincidir, caso en el que este tipo de protocolos es más eficiente, aunque no es necesario que ambos tengan la misma representación de datos.
En principio, no es necesario utilizar la DCE Transfer Syntax sino que podría utilizarse cualquier otra sintaxis, aunque OSF tan sólo ha implementado esta opción.

Independencia del Protocolo: DCE RPC implementa dos protocolos de transporte, uno corre sobre protocolos de transporte orientados a la conexión y otro sobre protocolos no orientados a conexión. Aunque cualquier otro protocolo podría utilizarse. Cuando los servidores se dan de alta en el Directory Service notifican que tipo de protocolo utilizan con el fin de que los clientes vena como comunicarse con ellos.

Independencia de la Máquina: Al utilizar, como ya se ha dicho antes , el DCE Transfer Syntax las aplicaciones distribuidas son independientes de la máquina en la que están corriendo, pues los datos son convertidos al formato con el que ellas trabajan.

Independencia del Sistema Operativo: El programador de una aplicación no utiliza directamente las llamadas a sistema de la red provistas por el sistema operativo local, por lo que está aislado del sistema que utiliza.

 
3.1.6. Distributed File Service (DFS)

  DFS es una aplicación de DCE que implementa un único sistema de ficheros lógico disponible a troves de la red. DFS soporta la replicación de ficheros para mayor disponibilidad, y la tolerancia a fallos.

DFS no pertenece propiamente al grupo ejecutivo de DCE sino que es un servicio extendido.

DFS permite a los usuarios acceder y compartir ficheros almacenados en un Servidor de Ficheros localizado en cualquier parte de la red, sin tener que conocer la localización física del fichero al que accedo. El DFS alcanza grandes prestaciones pues permite el acceso a un fichero por varios usuarios sin que aumente demasiado el trafico ni retardos. El DFS incluye un sistema de ficheros físico, el Local File System (LFS), que soporta características especiales que son muy utilizadas en entornos distribuidos, como la habilidad de replicar datos, simplificar la administración del sistema de ficheros dividiéndolo en pequeñas partes fácilmente manejables por unidades llamadas filesets, cargar datos del sistemas de ficheros permitiendo una rápida recuperación en caso de fallo y asociar ACL's (Control Access List) a ficheros y directorios.

 
3.1.7. Management Block

El bloque Management actualmente no es un único componente sino que está formado por un parte del resto de componentes. Cada servicio DCE contiene un componente administrativo que puede ser controlado y dirigido a través de la red.