Aplicaciones Distribuidas Abiertas

6 El servicio de directorio
125
6.1 El Directorio de OSI
6.1.1 Introduccin El Directorio es una aplicacin distribuida definida dentro de la arquitectura de sistemas abiertos (OSI) para dar soporte a la asignacin de nombres, almacenamiento, bsqueda, catlogo y gestin de informacin relacionada con objetos OSI. En particular, un objeto OSI puede ser un usuario humano, un proceso de aplicacin, un nodo de red, etc. La palabra Directorio siempre aparecer iniciada con mayscula cuando nos refiramos al sistema distribuido OSI. Por el contrario, aparecer iniciada con minscula cuando nos refiramos al trmino general de catlogo o gua. Se debe mencionar que las traducciones oficiales existentes al castellano utilizan la palabra Gua para referirse al trmino ingls Directory. Sin embargo, aqu se opta por el uso del trmino Directorio. Una de las principales misiones del Directorio es la de proveer mecanismos para construir y manipular nombres amigables (esto es, fciles de manejar y recordar por usuarios humanos) para referirse a los distintos objetos OSI. Cualquier objeto OSI tiene asignado un nombre nico de Directorio que lo distinguir de otros objetos, y que permite a las entidades OSI acceder a informacin sobre dicho objeto almacenada en el Directorio utilizando un nombre distintivo como ndice.
los autores, 1998; Edicions UPC, 1998. Quedan rigurosamente prohibidas, sin la autorizacin escrita de los titulares del "copyright", bajo las sanciones establecidas en las leyes, la reproduccin total o parcial de esta obra por cualquier medio o procedimiento, comprendidos la reprografa y el tratamiento informtico, y la distribucin de ejemplares de ella mediante alquiler o prstamo pblicos, as como la exportacin e importacin de ejemplares para su distribucin y venta fuera del mbito de la Unin Europea.
126
Aplicaciones distribuidas abiertas
Aunque el Directorio puede verse como una base de datos de uso general, ste ha sido diseado pensando en los requerimientos de directorio necesarios en las aplicaciones OSI y en los servicios de telecomunicacin. No obstante, el Directorio puede ser implementado sobre una base de datos de uso general. A nivel de transacciones, el servicio de Directorio se caracteriza porque el nmero de interrogaciones (lectura de informacin) al sistema siempre ser muy superior al nmero de actualizaciones (escritura de informacin). El Directorio asla a los usuarios de los cambios frecuentes de una red con la introduccin de nombres para sus componentes. De esta forma, por ejemplo, una mquina o una entidad de aplicacin pueden identificarse mediante un nombre nico y permanente que lo independice de una direccin fsica de red o de una direccin de presentacin respectivamente. Al mismo tiempo, el Directorio proporciona una visin ms amigable de la red en cuanto los nombres son ms manejables por los humanos que las direcciones fsicas. El Directorio se encuentra definido en la Recomendacin ITU-T X.500 y en el estndar internacional ISO/IEC 9594 [DIR0194]. Ambos son documentos tcnicamente alineados, esto es, su contenido es idntico.
6.1.2 Visin general del Directorio El Directorio es un conjunto de sistemas abiertos que cooperan para establecer una base de datos lgica con informacin sobre objetos y entidades que componen o utilizan el mundo OSI. Los usuarios del Directorio, incluyendo personas y programas de ordenador, pueden leer y modificar la informacin, o parte de ella, almacenada en el Directorio, siempre y cuando tengan permiso para realizar tal accin. Cada usuario del Directorio utiliza un agente de usuario de Directorio (DUA, Directory User Agent) para acceder a los servicios proporcionados por el sistema (Fig. 6.1).
Punto de acceso Usuario DUA El Directorio
Fig. 6.1 Acceso al Directorio
La informacin almacenada en el Directorio se denomina de una forma general Base de informacin del directorio (DIB, Directory Information Base). Esta informacin se encuentra distribuida a lo
127
largo de los sistemas que forman el Directorio global. En particular, existirn varios agentes de sistema de Directorio (DSA, Directory System Agent) encargados de proporcionar acceso a los usuarios (a travs de los DUA) a las diferentes partes del DIB (Fig. 6.2). Los DSA cooperarn entre ellos para poder proporcionar a los usuarios la visin de un Directorio global aunque el usuario acceda al sistema a travs de un nico punto (normalmente el ms prximo a l).
El Directorio DSA
Usuario
DUA
DSA
DSA
DUA
Usuario
DSA
DUA
Usuario
Fig. 6.2 Visin global del Directorio
Los agentes del sistema de Directorio forman diferentes dominios de gestin encargados de administrar partes del DIB siguiendo directrices funcionales u organizativas. As, son las distintas autoridades que administren el Directorio quienes impongan control de acceso sobre su parte de informacin. Desde el punto de vista de acceso y cooperacin entre los sistemas que forman el Directorio, ste proporciona un conjunto estndar de servicios abstractos y de protocolos a sus usuarios. La especificacin abstracta del servicio de Directorio incluye la descripcin formal de servicios para la modificacin y recuperacin de informacin. Estos servicios son consumidos por los usuarios a travs de los DUA. Tambin, y aparte de los servicios propios de usuario, el Directorio incluye servicios y protocolos para la gestin y distribucin interna del sistema de Directorio.
6.1.3 La base de informacin del Directorio (DIB) De forma general, la base de informacin del Directorio (DIB) est formada por informacin sobre objetos. Tcnicamente, la DIB est compuesta por entradas (entries) de directorio, las cuales consisten en una coleccin de informacin sobre un objeto. Cada informacin en particular sobre un
128
objeto se denomina atributo (attribute) y se caracteriza mediante un tipo de atributo y uno o varios valores de ese tipo. Los tipos de atributos que pueden aparecer en una entrada depender de la clase (class) de objeto que describe la entrada. Algunos de los atributos ms tpicos se enumeran en la siguiente tabla.
Tabla 6.1 Diferentes tipos de atributos X.500
Tipo de atributo businessCategory commonName countryName description facsimileTelephoneNumber iSDNAddress localityName objectClass organizationName physicalDeleiveryOfficeName postalAddress postalCode postOfficeBox preferredDeliveryMethod
Tipo de atributo presentationAddress registeredAddress roleOccupant serialNumber stateOrProvinceName streetAddress supportedApplicationContext surname telephoneNumber teletexTerminalNumber telexNumber title X121Address
Las entradas de la DIB estn organizadas jerrquicamente en modo de rbol formando el rbol de informacin del Directorio (DIT, Directory Information Tree). Cada vrtice del DIT representa una entrada para un objeto particular, donde entradas de alto nivel cercanas a la raz suelen describir objetos como pases u organizaciones, mientras que entradas de bajo nivel en el rbol suelen describir objetos como personas o aplicaciones. Existen dos tipos de entradas, aqullas que contienen la descripcin de un objeto, llamadas entradas de objeto (object entries), y aquellas que contienen un alias a una entrada de objeto, llamadas entradas de alias (alias entries). Las entradas de alias se utilizan como base para la construccin de nombres alternativos para las entradas de objeto. La figura 6.3 muestra la relacin entre los conceptos de rbol de informacin de Directorio, entrada objeto, entrada alias, atributos, tipo de atributo y valores de atributo. Cada entrada tiene un nombre distintivo (DN, Distinguished Name) el cual identifica de forma nica y no ambigua la entrada dentro del DIT. Sin embargo, un objeto puede tener varios nombres
129
distintivos (DN), esto es, el nombre correspondiente a la entrada objeto y tantos nombres como entradas alias existan para dicha entrada objeto.
DIT
entrada de objeto entrada de alias
Entrada
AA AA AAAA AAAAAAAAAA AAAA AAAAAAAAAAAA AA
AA AAAA AAAAAA AAAAAA
Atributo
AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAA tipo valor(es) AAAAAAAA AAAAAAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA
Fig. 6.3 Estructura del DIT y sus componentes
6.1.4 El nombre distintivo (DN) Un nombre distintivo es una construccin lingstica amigable (que significa cercana o fcil de manipular por las personas) que identifica de forma nica y no ambigua una entrada del Directorio. El DN se utiliza por los usuarios como ndice para acceder a la informacin referente a un objeto almacenado en la DIB.
atributo distintivo (RDN) Entrada atributo

AAAA AA AA AAAA AA AAAA AAAA AA AAAAAA AAAAAA AAAA AA AAAA AA AAAAAA
atributo
Atributo
AAAA AAAAAAAAAAAAAAAAA A AAAA AAAA AAAA AAAA A AAAA AAAAAAAA AAAA AAAA AAAA tipo valor(es) A AAAA AAAA AAAA AAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAAAAAAA A
Fig. 6.4 Estructura de una entrada y del RDN asociado
Un DN est formado por una secuencia de nombres distintivos relativos (RDN, Relative Distinguished Name). Cada entrada en el DIT define un RDN que generalmente coincide con un
130
atributo, denominado atributo distintivo, de la entrada (Fig. 6.4). El RDN (o atributo distintivo en cuestin) se fija en la creacin de la entrada. Formalmente, un RDN est compuesto por una lista de de atributos distintivos, pero en la prctica, los RDN se construyen generalmente con uno slo. Por simplicidad, se ha considerado el caso ms comn. As, un nombre (DN) ser la secuencia jerrquica de nombres relativos de cada una de las entradas que aparecen en una rama del rbol (DIT). La figura 6.5 muestra un ejemplo de DIT en el que aparecen los RDN asociados a cada entrada.
raz
C=ES
C=US
O=UPC
L=Los Angeles
OU=CTT
OU=DAC CN=John Jones
O=Graphic Services
CN=Mquina Fax
CN=Jos Fernndez
CN=Laser Printer
CN=Fax Machine
Fig. 6.5 Ejemplo de DIT
La figura 6.5 tambin muestra ejemplos de algunos tipos de atributos usados (pas -C-, organizacin -O-, unidad organizativa -OU-, localidad -L-, nombre comn -CN-) como atributos distintivos para diferentes objetos. Por ejemplo, el nombre: { C=US, L=Los Angeles, O=Graphic Services, CN=Laser Printer } identifica una entidad de aplicacin Laser Printer que en su DN tiene un atributo geogrfico de localidad. La persona civil "John Jones" cuyo nombre es: { C=US, L=Los Angeles, CN=John Jones } tiene el mismo atributo geogrfico en su nombre. En el caso de una estructuracin del DIT siguiendo un esquema puramente organizativo, vese el ejemplo de "Jos Fernndez", que se trata de una persona afiliada a una unidad organizativa "DAC" dentro de la organizacin "UPC" situada en Espaa. Su nombre distintivo ser entonces:
131
{ C=ES, O=UPC, OU=DAC, CN=Jos Fernndez } Por ltimo, se debe mencionar que la raz del DIT tiene como nombre distintivo el valor nulo, esto es, una secuencia nula de RDN y se representa como el nombre vaco: {}
6.1.5 Dominios de gestin del Directorio La asignacin de nombres conlleva el cumplimiento de un esquema que determina la seleccin de los nombres para las entradas a medida que se van creando stas. La responsabilidad del cumplimiento de dicho esquema es de varias autoridades cuya relacin jerrquica viene fijada por el DIT. En realidad, la jurisdiccin para la asignacin de nombres se va delegando hacia abajo en el rbol, desde autoridades superiores a subordinadas. Por ejemplo, y volviendo a la figura 6.5, la autoridad responsable dentro de la UPC asigna nombres a las entradas que ella cree, por ejemplo el DAC. Entonces, la UPC delega a la autoridad dentro del DAC la asignacin de nombres para sus entradas subordinadas (esto es, Jos Fernndez, etc.). Se denomina dominio de gestin del Directorio (DMD, Directory Management Domain) a la porcin del DIT que se encuentra bajo la responsabilidad de cierta autoridad. Dentro de un dominio se sigue el esquema para la gestin del espacio de nombres especificado por dicha autoridad.
raz
ADMD
C=ES
C=US
ADMD
PRMD O=UPC OU=CCT OU=DAC CN=John Jones L=Los Angeles O=Graphic Services
CN=Mquina Fax
CN=Jos Fernndez PRMD
CN=Laser Printer PRMD
Fig. 6.6 Ejemplo de dominios de gestin
Dependiendo de las autoridades y su naturaleza, se distinguen dos tipos de dominios de gestin:
132
Pblicos o administrativos (ADDMD, ADministration Directory Management Domain). Son dominios gestionados por organismos o administraciones pblicas. Por ejemplo, las PTT (proveedores pblicos de telecomunicaciones) nacionales, que en el caso de Espaa es Telefnica. Privados (PRDMD, PRivate Directory Management Domain). Son dominios gestionados por organizaciones privadas. Por ejemplo, un banco, gran empresa o institucin.
La figura 6.6 muestra un ejemplo de estructuracin del DIT en dominios
6.1.6 Servicios del Directorio Todos los servicios definidos por el Directorio son suministrados en respuesta a peticiones de usuarios a travs de DUA (Fig. 6.1). Existen peticiones que permiten la interrogacin y la modificacin del Directorio. Adems, tambin existen servicios que permiten el establecimiento y la liberacin de una unin temporal entre un usuario y el Directorio a travs de un punto de acceso al Directorio.
6.1.6.1 Servicios de Interrogacin Existen cinco servicios diferentes: servicios de lectura (Read), comparacin (Compare), catlogo o listado (List), bsqueda (Search) y abandono (Abandon). A continuacin se describe brevemente cada una de las operaciones que realizan los servicios. Leer (Read): Operacin de lectura de algunos o todos los atributos de una entrada especfica. Comparar (Compare): Operacin de comparacin de un atributo especfico de una entrada especfica con un valor aportado en la operacin. Listar (List): Operacin para listar todos los RDN de todas las entradas subordinadas a una entrada especfica. Buscar (Search): Operacin que hace al Directorio iniciar una bsqueda de todas las entradas dentro de cierta porcin del DIT que satisfacen un filtro. La informacin retornada para cada entrada puede ser algunos o todos los atributos de cada entrada (como en leer). Abandonar (Abandon): Operacin que hace al Directorio abandonar la peticin de interrogacin en curso. El Directorio cesar el procesado de la peticin en curso y descartar cualquier posible resultado obtenido hasta el momento.
133
6.1.6.2 Servicios de modificacin Existen cuatro servicios diferentes, servicios de aadir entrada (add entry), borrar entrada (remove entry), modificar entrada (modify entry) y modificar DN (modify DN). A continuacin se describe brevemente cada una de las operaciones que realizan los servicios. Aadir entrada (add entry): Operacin que aade una nueva entrada objeto o alias al DIT. Una nueva entrada slo se puede aadir a una hoja del DIT, esto es, bajo un DN especfico que determine una entrada final (sin subordinados). Borrar entrada (remove entry): Operacin que borra una entrada final (sin subordinados) del DIT. Modificar entrada (modify entry): Operacin que hace al Directorio iniciar una secuencia de cambios sobre una entrada especfica. En la operacin siempre se realizan todos los cambios o no se realiza ninguno. Los cambios que se pueden realizar son la adicin, borrado o cambio de atributos completos o valores de atributos. Modificar DN (modify DN): Operacin para ordenar un cambio de nombre distintivo relativo de una entrada (objeto o alias) especfica, o para mover una entrada especfica hacia un nuevo punto superior en el DIT. Ntese que cambiar un RDN implica un cambio en todos los DN que contuvieran dicho RDN. As, si la entrada a modificar el nombre es final, entonces slo se ve modificado un DN, el de la propia entrada. Sin embargo, en el caso de que tuviera subordinados, todos los subordinados tambin se veran modificados.
6.1.6.3 Servicios de establecimiento y liberacin de unin Estrictamente, este no es un servicio que pertenezca al Directorio sino que es un servicio general para todas las aplicaciones OSI. En el caso del Directorio, un usuario a travs de su DUA inicia un establecimiento de unin (bind) con el sistema de Directorio por medio de un punto de acceso al Directorio asociado a un DSA. Este punto de acceso estar localizado en un vrtice del rbol del directorio, esto es, en una entrada especfica del DIT. Una vez realizada la unin, el usuario podr ordenar operaciones que impliquen la entrada asociada al punto de acceso o podr especificar en la operacin otra entrada del DIT. Generalmente, en el proceso de establecimiento de unin se requiere que el usuario incluya algn tipo de credencial para poder realizar su autenticacin y un control de acceso posterior. As, el usuario slo podr realizar operaciones en entradas sobre las que tenga ciertos derechos. El usuario libera la unin (unbind) entre DUA y el sistema de Directorio cuando no requiera solicitar ms operaciones al Directorio.
134
6.1.6.4 Otros servicios definidos en el Directorio Una de las contribuciones ms importantes del Directorio es la definicin de un marco de autenticacin (authentication framework). Aqu se propone un marco estndar para la implantacin de servicios de seguridad utilizando tecnologas de clave pblica (autenticacin, control de acceso, integridad, confidencialidad, etc.) para la proteccin de los usuarios y del propio Directorio. Estas recomendaciones tambin han sido incorporadas a otras aplicaciones OSI y no OSI. Otros servicios, aunque no visibles directamente por el usuario, son los de replicacin de la informacin y gestin de parmetros operacionales entre DSA.
6.1.7 El modelo distribuido del Directorio En la figura 6.2 del apartado 6.1.2 se muestra la visin global o modelo funcional del sistema de Directorio. Bsicamente, un agente de sistema de Directorio (DSA) es un proceso de aplicacin OSI cuya misin es la de proporcionar acceso al DIB a los usuarios del Directorio a travs de los DUA y/o a otros DSA. Un DSA puede utilizar la informacin almacenada en su base de datos local o interaccionar con otros DSA para atender las peticiones. As, un DSA implementa el proveedor del servicio de Directorio y un DUA ser el consumidor de dicho servicio.
DSA1 ADMD DSA1 C=ES
raz ADMD C=US DSA1
DSA2 O=UPC PRMD OU=CCT OU=DAC CN=John Jones PRMD CN=Mquina Fax CN=Jos Fernndez DSA1 PRMD CN=Laser Printer DSA1 O=Graphic Services DSA1 L=Los Angeles
Fig. 6.7 Ejemplo de DIB con distribucin funcional y organizativa
Un DSA gestiona localmente una parte del DIB, y un conjunto de DSA que cooperan entre ellos forman el DIB completo. La forma de implementar la base de datos local que contiene las entradas
135
de una porcin del DIB es dependiente de la implementacin y no est estandarizada (p.e. se pueden utilizar bases de datos relacionales comerciales). Un conjunto de uno o ms DSA y cero o ms DUA gestionados por una nica organizacin forman un dominio de gestin del Directorio (DMD). La figura 6.7 muestra, de forma conjunta, un ejemplo de modelo organizativo y funcional del sistema de Directorio. Ntese que todos los dominios, incluido la raz del Directorio, estn contenidos en un DSA menos el dominio que gestiona la rama de C=ES que est contenido en dos DSA. Una vez vistos los modelo funcional y organizativo del sistema distribuido del Directorio, queda por ver el modelo operacional, esto es, cmo interaccionan DUA y DSA para proveer un servicio global de Directorio a los usuarios.
6.1.8 Modelo operacional del Directorio Un DUA interacciona con el Directorio estableciendo comunicacin con uno o ms DSA. En principio, un DUA no necesita estar sujeto a un nico DSA, sino que puede acceder directamente a varios DSA para solicitar peticiones. Sin embargo, por razones administrativas o de control, puede ocurrir que un DUA no pueda acceder directamente al DSA que contiene la informacin buscada o que el DUA est restringido a interaccionar con un nico DSA de forma fija. Un DSA es responsable de llevar a cabo las peticiones de los DUA para obtener la informacin solicitada, ya sea localmente o remotamente interaccionando con otros DSA en nombre del DUA. Cuando un DUA realiza una peticin a un DSA, la realizacin de esa peticin puede ocurrir de diferentes formas dependiendo de si la informacin se encuentra almacenada localmente o si dicha informacin hay que buscarla en otros DSA.
El Directorio
peticin Usuario DUA respuesta DSA
Fig. 6.8 Interaccin simple
136
Interaccin simple. Es el caso ms sencillo y ocurre cuando la informacin solicitada por el DUA se encuentra en el DSA al cual se realiz la peticin. La figura 6.8 muestra este caso.
El Directorio
DSA B
peticin Usuario DUA indireccin (a A) peticin DSA A DSA C
Fig. 6.9.a Interaccin con un nivel de indireccin
Interaccin con indireccin (referral). En este caso (Fig. 6.9.a), el DUA solicita una informacin que el DSA (C) al que se realiz la peticin no tiene, pero sabe de otro DSA (A) que s la tiene. Entonces, el DSA contactado responde al DUA con una referencia al DSA (A) y ser responsabilidad del DUA acceder al DSA (A) para solicitar la informacin.
El Directorio
i etic 1)p n
DSA B
peticin Usuario DUA 2) indireccin (a B) DSA C

ind pet ici
ire (a B c c i n )
DSA A
Fig. 6.9.b Interaccin con dos niveles de indireccin
La figura 6.9.b muestra otro tipo de indireccin. Puede ocurrir que el DSA al que se realiz la peticin (C) no tenga la informacin y ste encamine (ver siguiente tipo de interaccin) la peticin a otro DSA (A). El DSA (A) tampoco tiene la informacin solicitada pero sabe de otro DSA (B) que s la tiene. Entonces, el DSA (A) pasa un referencia al DSA (C) indicando que el DSA (B) tiene la
137
informacin. Ahora, el DSA (C) puede optar por realizar la peticin directamente al DSA (B) -caso 1)- o responder al DUA con la referencia al DSA (B) -caso 2)-. Interaccin con encadenamiento simple (uni-chaining). Una peticin puede ser encaminada a travs de varios DSA hasta que se encuentra la respuesta a la informacin solicitada (Fig. 6.10).
El Directorio
peticin DSA respuesta
Fig. 6.10 Interaccin con encadenamiento simple
Interaccin con encadenamiento mltiple (multi-chaining). Una peticin ser encaminada por el DSA asociado al DUA hacia varios DSA en paralelo. La peticin es la misma para todos los DSA y puede ocurrir que ninguno, uno o varios DSA respondan con la informacin solicitada (Fig. 6.11).
El Directorio
pet ici n
DSA
ta ues resp
pet
ici
res pue sta
DSA
Fig. 6.11 Interaccin con encadenamiento mltiple
138
6.1.9 Protocolos del Directorio En la versin de 1988 del Directorio existan dos protocolos diferentes: El protocolo de acceso al Directorio (DAP, Directory Access Protocol) que define el intercambio de peticiones y respuestas entre un DUA y un DSA. El protocolo de sistema de Directorio (DSP, Directory System Protocol) que define el intercambio de peticiones y respuestas entre dos DSA.
En la ltima versin del Directorio (1993) aparecen dos protocolos ms que estn relacionados con la replicacin de la informacin entre DSA (DISP, Directory Information Shadowing Protocol) y con la gestin de informacin operacional entre DSA (DOP, Directory Operational binding management Protocol). Ambos protocolos proporcionan servicios de gestin para DSA y no ofrecen ningn servicio directo al usuario, por lo que no han sido tratados aqu. Cada uno de los protocolos existe dentro de un contexto de aplicacin que est formado por elementos de servicio de aplicacin que utilizan ROSE (elemento de servicio de operaciones remotas) para llevar a cabo las interacciones. As, el DAP y el DSP estn definidos como un conjunto de operaciones y errores remotos usando la notacin RO.
6.2 Servicio de nombres de Internet
6.2.1 Introduccin El servicio de nombres de dominio (DNS, Domain Name Service) de Internet es un servicio de nombres que asocia informacin con objetos. Cualitativamente, el DNS de Internet es equivalente al Directorio de OSI pero teniendo en cuenta los siguientes matices: DNS slo manipula informacin sobre mquinas (hosts, siguiendo la terminologa Internet) en la red. DNS se dise con el objetivo principal de sustituir las direcciones de red IP por nombres amigables en el uso de las aplicaciones Internet. As, DNS se utiliza bsicamente como un servicio de resolucin de nombres en direcciones IP.
Se debe mencionar que las siglas DNS se suelen utilizar indistintamente para referirse al sistema de nombres de dominio (DNS, Domain Name System) como al servicio de nombres de dominio. Comparando DNS con el Directorio, el primero es un subconjunto del segundo en cuanto a un servicio final. Mediante el Directorio se puede implementar un servicio de nombres como el que
139
proporciona DNS; sin embargo, utilizando DNS no se puede implementar una base de informacin como la del Directorio. Por otra parte, la generalidad que ofrece el Directorio se paga en agilidad y velocidad de respuesta del sistema; el primero es bastante ms lento que DNS, el cual implementa unos protocolos sumamente sencillos.
6.2.2 Visin general de DNS DNS es un sistema distribuido que est compuesto por varios servidores de nombres (name server) a los cuales se accede mediante un proceso cliente denominado resolver (trmino original sin traducir). Cuando una aplicacin necesita obtener una direccin fsica de red a partir de un nombre, sta invoca al resolver, el cual realiza una interrogacin a su servidor de nombres local. La figura 6.12 muestra el acceso a DNS, as como la visin global del sistema.
DNS
servidor nombres servidor nombres servidor nombres
Usuario
resolver
servidor nombres
resolver
Usuario
resolver
Usuario
Fig. 6.12 Visin global de DNS
Desde un punto de vista arquitectnico, se puede extraer un paralelismo entre las entidades del Directorio y de DNS. As, resolvers y servidores de nombres de DNS seran equivalentes a DUA y DSA del Directorio respectivamente. No se debe olvidar tampoco que los servidores de nombres manipulan una base de datos de informacin sobre mquinas de la red.
140
6.2.3 La base de informacin de DNS La base de informacin de DNS est formada por registros de recursos (RR, Resource Records). Un nombre de dominio identifica un nodo en el DNS y tiene asociado un conjunto de registros RR. De nuevo, extendiendo la equivalencia con el Directorio, los nodos y registros de DNS seran las entradas y los atributos del Directorio respectivamente. Existen unos pocos tipos de registros RR. En particular, a un nombre de dominio se le puede asociar informacin sobre una direccin IP, un alias, informacin textual sobre la CPU y el sistema operativo, servidores de correo asociados, etc. Los nodos de DNS estn organizados jerrquicamente en forma de rbol. Cada vrtice del rbol representa un nodo que contiene informacin sobre un dominio o una mquina de la red. Al contrario que en el Directorio, en DNS se define el formato de la base de datos que implementa la base de informacin. Concretamente, se trata de unos ficheros tipo texto donde cada lnea contiene un registro RR. Cada nodo tiene un nombre de dominio DNS (DNS domain name), el cual identifica de forma nica y no ambigua el nodo dentro del espacio de nombres DNS (DNS domain space). En DNS, un objeto tambin puede tener varios nombres, esto es, el nombre correspondiente al nodo objeto, y tantos nombres como alias existan para dicho objeto.
6.2.4 Nombres de dominio DNS El espacio de nombres de dominio es una estructura en forma de rbol. Cada nodo tiene una etiqueta de 0 a 63 octetos de longitud. Los nodos hermanos no pueden tener la misma etiqueta; sin embargo, nodos superiores o subordinados s pueden tener la misma etiqueta. La etiqueta nula (0 octetos) est reservada para denotar la raz del rbol. El nombre de dominio de un nodo es la lista de etiquetas en el camino desde el nodo hasta la raz del rbol. Comparando con el Directorio, nodos y nombres de dominios de DNS tendran su equivalente en RDN y DN del Directorio. Por convenio, las etiquetas slo pueden tener caracteres imprimibles (sin incluir el punto '.'), en donde maysculas y minsculas indican el mismo carcter. Por tanto, un nombre de dominio es una secuencia de etiquetas separadas por punto. Por ejemplo, el siguiente es el nombre de dominio de la mquina sirius del Departamento de Arquitectura de Computadores (AC) dentro de la Universitat Politcnica de Catalunya (UPC) en Espaa (ES): sirius.ac.upc.es
141
Cada nodo del rbol que no es una hoja (nodo final) representa un dominio del cual se pueden derivar otros dominios subordinados o mquinas. El nodo final representa siempre una mquina (host). En la asignacin de nombres, los nombres de dominios ms superiores (llamados top level domains) ya han sido fijados; como son EDU, ARPA, COM, GOV, ES, US, el resto de pases, y otros. Adems, la asignacin de un nombre de dominio de segundo nivel debe corresponder a la categora adecuada de los niveles superiores existentes (Fig. 6.13).
"."
COM
EDU
ARPA
ES
GOV
(otros)
xxx
xxx
UPC
xxx
(otros)
diable
AC
(otros)
deneb
orion
sirius
vega
(otros)
Fig. 6.13 Jerarqua de dominios de Internet
6.2.5 Gestin de dominios DNS DNS define el concepto de zonas (zone). Una zona est formada por un conjunto de mquinas dispuestas jerrquicamente y gestionadas por una nica autoridad. Una zona se encuentra servida por uno o varios servidores de nombres. Cada servidor de nombres se ejecuta en una mquina distinta de la zona y sus clientes estn jerrquicamente por debajo de estos servidores. Comparando con el Directorio, las zonas seran equivalentes a los dominios de gestin del Directorio. Las zonas generalmente representan fronteras entre autoridades en la administracin del espacio de nombres. La figura 6.14 muestra una estructuracin en zonas para el espacio de nombres dentro de Espaa y de la Universitat Politcnica de Catalunya.
142
"."
zona root
COM
EDU
ARPA
ES
GOV
(otros)
xxx zona upc.es
xxx diable
UPC
xxx (otros)
(otros)
AC zona ac.upc.es
deneb
orion
sirius
vega
(otros)
Fig. 6.14 Ejemplo de zonas en el espacio de nombres de Internet
6.2.6 Servicios y protocolos DNS slo ofrece servicios de interrogacin para obtener informacin sobre un determinado dominio o mquina utilizando un nombre como ndice. DNS no ofrece servicios de modificacin de la base de informacin sino que sta debe ser modificada localmente por el administrador mediante la edicin de los ficheros que contienen los registros RR. En cuanto a los protocolos, DNS es una aplicacin Internet que trabaja directamente sobre el nivel de transporte de Internet, tanto TCP como UDP. Sin embargo, el modo preferido de trabajo es mediante datagramas que utilizan UDP. Actualmente, todas las implementaciones usan UDP y son pocas las que incorporan TCP. El puerto TCP normalizado para acceder a DNS es el nmero 53.
7 Gestin e intercambio de documentos y ficheros en sistemas distribuidos
143

7.1 Introduccin
La gestin y el intercambio de ficheros ha sido siempre un tema importante dentro del software de ordenadores. Cuando se habla de sistemas distribuidos, es bsico el poder realizar la gestin remota, y el intercambio de ficheros entre sistemas, de una manera eficiente, sencilla y, a poder ser, normalizada. Actualmente, en muchos entornos distribuidos, los ficheros ms importantes son los documentos, los cuales tambin pueden necesitar ser gestionados, manipulados e intercambiados en un entorno distribuido. Existen una serie de estndares, tanto OSI como Internet, que definen protocolos para poder realizar dicho intercambio y gestin de documentos y ficheros en sistemas distribuidos. En concreto, este captulo se inicia con el tema de la manipulacin remota de documentos (incluyendo las recomendaciones DTAM, de ITU-T), para seguir con la manipulacin remota de almacenes de documentos (basada en el estndar DFR, de ISO), y acabar con la gestin y transferencia de ficheros en general (donde se trata un estndar de ISO, FTAM, y otro de Internet, ftp).
7.2 Manipulacin remota de documentos: DTAM-DM

Para poder definir una manipulacin de documentos en un entorno distribuido abierto, el primer paso es tener una visin comn del documento. Esto se soluciona utilizando un estndar que
144
permita definir un documento de forma independiente de como se crea y se procesa. Para eso se ha especificado ODA (vase el captulo 5). El segundo paso es definir una serie de operaciones estandarizadas sobre los documentos. Esto se especifica en una nueva parte del estndar ODA (la parte 3, publicada en 1995), que se denomina interfaz abstracto para la manipulacin de documentos ODA [ODA0395] (vase el apartado 7.2.1). Despus, es necesario definir una aplicacin distribuida para poder realizar esas operaciones de forma remota. Para esto se ha especificado el servicio y protocolo manipulacin confirmada de documento -transferencia y manipulacin de documentos (DTAM-DM, Document Transfer And Manipulation - confirmed Document Manipulation) (vase el apartado 7.2.2).
7.2.1 Interfaz abstracto para la manipulacin de documentos ODA El interfaz de operaciones utiliza las caractersticas estructurales de ODA para identificar fragmentos de documento sobre los que realizar las operaciones. Este es un avance importante respecto a la versin inicial de ODA, que no lo permita. Se sigue un modelo cliente/servidor definiendo una serie de operaciones con sus argumentos, resultados y errores. Las operaciones se pueden realizar local o remotamente. Las operaciones disponibles son: Operaciones a nivel de documento: Enumerar (List) los documentos de un almacn, Abrir (Open) y Cerrar (Close) un documento seleccionado. Se puede tener ms de un documento abierto a la vez. Operaciones de slo lectura: Traer (Get) uno o varios elementos ODA (fragmentos de documento), y Buscar (Search) una informacin determinada dentro de un documento. Operaciones bsicas de alteracin: Crear (Create), Borrar (Delete) y Modificar (Modify) fragmentos, y Copiar (Copy) fragmentos a otro lugar (incluso en otro documento). Operaciones compuestas de alteracin: Mover (Move) fragmentos de un lugar a otro y Reemplazar (Replace) uno de ellos. Otras operaciones: Operaciones de reserva: Reservar (Reserve y Unreserve) fragmentos de documento, para evitar acceso simultneo al mismo fragmento.
145
Operaciones independientes del documento: Empezar (BeginGroup) y Acabar (EndGroup) un grupo de operaciones que a una aplicacin pueda interesarle reunir, por ejemplo, para minimizar coste de comunicacin o para procesar varias operaciones a la vez.
Finalmente, dado que estas operaciones utilizan fragmentos de documentos como argumentos o resultados, es necesario disponer de un mecanismo de identificacin de dichos fragmentos, cuya especificacin tambin es una nueva parte del estndar ODA (la parte 12, aprobada en 1995), titulada identificacin de fragmentos de documento [ODA1295].
7.2.2 Protocolos DTAM El interfaz abstracto no es un servicio distribuido con su protocolo, sino un conjunto estndar de operaciones de manipulacin de documentos. Para poder implementar dichas operaciones en un entorno distribuido, por ejemplo entre un sistema cliente (donde est el usuario que quiere manipular los documentos) y un sistema servidor remoto (donde estn los documentos a manipular), se necesita un protocolo de aplicacin, que pueda funcionar, preferentemente, sobre los niveles superiores del modelo OSI, y sobre cualquier tipo de red. Una solucin a este problema es utilizar el protocolo de manipulacin de documentos de DTAM (Document Transfer and Manipulation), definido en las recomendaciones de ITU-T: T.435 (servicio) [DTA0495] y T.436 (protocolo) [DTA0595], publicadas en 1995. DTAM-DM (DTAM-confirmed Document Manipulation), tal como se le conoce para distinguirlo del resto de las recomendaciones DTAM (inicialmente publicadas en 1988 y que, bsicamente, definen un protocolo de transferencia interactiva de documentos), especifica un conjunto de operaciones de manipulacin de documentos (perfectamente alineado con el interfaz de manipulacin ODA), aparte de otras operaciones ms concretas de protocolos de comunicacin. El conjunto de operaciones proporcionadas por DTAM-DM se presenta en la tabla 7.1.
Tabla 7.1 Operaciones proporcionadas por DTAM-DM
Operacin Nivel de documento

Enumerar (List) Abrir (Open) Cerrar (Close) Guardar (Save)
Descripcin
Enumera los documentos en un almacn (sin estructura) Abre un documento para su manipulacin Cierra un documento despus de su manipulacin Guarda un documento despus de su manipulacin
146 Descartar (Discard)
Descarta las manipulaciones hechas sobre un documento
Lectura
Buscar (Search) Traer (Get) Busca un fragmento dado dentro de un documento Obtiene un fragmento de un documento
Alteracin bsica
Crear (Create) Copiar (Copy) Borrar (Delete) Modificar (Modify) Crea un fragmento de documento dentro de un documento Copia un fragmento de documento (incluso entre documentos) Borra un fragmento de un documento Modifica atributos de un fragmento de documento
Alteracin compuesta
Mover (Move) Mueve un fragmento de documento (incluso entre documentos distintos) Reemplaza un fragmento de documento por otro
Reemplazar (Replace)
Otras
Apuntar (Point) Reservar (Reserve/Unreserve) Empezar / Acabar Grupo (BeginGroup / EndGroup) Apunta a un fragmento de documento Reserva (o anula la reserva) de un fragmento de documento
Indica principio y final de un grupo de operaciones
Las operaciones mencionadas corresponden a un mismo elemento de servicio de aplicacin, llamado de manipulacin de documentos (DTAM-DM-SE). Como sistema OSI, se puede especificar usando ASDC (vase captulo 3), donde DTAM-DM es un puerto asimtrico. Para situaciones en las que puede interesar intercambiar un testigo (token) de aplicacin para controlar el turno, por ejemplo en una edicin remota conjunta de un documento, se define un segundo ASE, llamado de intercambio de testigo (DTAM-TK, DTAM-application Token exchange) con simples operaciones de intercambio de testigo. En este caso, el puerto correspondiente es simtrico. Asimismo, es importante destacar que DTAM no obliga a utilizar documentos basados en ODA ( aunque de hecho est intencionadamente adaptado para documentos con interfaz ODA) sino que se podra utilizar sobre cualquier tipo conocido de documentos.
147
7.2.3 Perfiles de manipulacin de documentos Diferentes implementaciones de aplicaciones para manipulacin de documentos pueden no necesitar toda la funcionalidad proporcionada por los estndares o recomendaciones mencionados. Por ello, se estn definiendo perfiles (profiles), o estndares funcionales, que especifican subconjuntos implementables de estndares complejos. Tanto para la manipulacin remota interactiva de documentos, como para la manipulacin de almacenes de documentos basados en DFR (vase el apartado 7.3.2), se estn definiendo diversos perfiles que restringen, entre otras cosas, las operaciones a realizar. Para el caso de manipulacin interactiva de documentos se han definido tres perfiles (cada uno subconjunto del siguiente) que son perfiles sobre DTAM-DM y el interfaz de manipulacin ODA. Se llaman AOD1n, siendo n un nmero que identifica el perfil (el 1 inicial indica que son con DTAM-DM como protocolo). Los perfiles definidos son: Slo lectura (AOD11): Para leer y buscar fragmentos de documento. Incluye las operaciones Traer y Buscar, aparte de Abrir y Cerrar, y, opcionalmente, Enumerar. Insercin (AOD12): Permite aadir informacin a un documento. Incluye, adems de las operaciones de AOD11, las operaciones Crear, Copiar y, opcionalmente, Reservar (Reserve y Unreserve). Manipulacin (AOD13): Permite todas las operaciones de manipulacin. Incluye, adems de las operaciones de AOD12, las operaciones Borrar y Modificar, siendo las dems (Reemplazar, Mover, ...) opcionales.
Estos perfiles restringen el uso de DTAM-DM y el interfaz de manipulacin de ODA, adems de especificar cmo combinar ambos. Todos los perfiles empezarn a publicarse en 1996. Los perfiles AOD se pueden combinar con perfiles similares que se estn definiendo para DFR, los cuales se introducen en la seccin 7.3.2. La tabla 7.2 resume las operaciones disponibles () u opcionales (o) en cada perfil.
Tabla 7.2 Operaciones disponibles en los perfiles AOD
Perfiles AOD Operacin Nivel de documento

Enumerar (List)
AOD11
AOD12
AOD13
148 Abrir (Open) Cerrar (Close) Guardar (Save) Descartar (Discard)

o o
Lectura
Buscar (Search) Traer (Get)
Alteracin bsica
Crear (Create) Copiar (Copy) Borrar (Delete) Modificar (Modify)
Alteracin compuesta
Mover (Move) Reemplazar (Replace)
Otras
Reservar (Reserve/Unreserve) Empezar / Acabar Grupo (BeginGroup / EndGroup)
o o
7.3 Manipulacin remota de almacenes de documentos: DFR

En la seccin anterior se ha visto cmo manipular documentos remotamente. Pero existen aplicaciones, quiz ms habituales, en las que lo que se quiere manipular es un almacn de documentos, es decir, no interesa qu hay dentro de los documentos, sino los documentos enteros y su situacin en el almacn. Como DTAM est pensado para manipular internamente un documento, si una aplicacin necesita, adems, manipular un almacn completo de documentos, es necesario aadir operaciones a nivel de almacn. En este caso, lo ideal es complementar DTAM con otro protocolo del nivel de aplicacin OSI como el de almacenamiento y recuperacin de documentos (DFR, Document Filing and Retrieval), publicado como ISO/IEC 10166 en 1991 [DFR0291], y mejorado y extendido posteriormente. Por supuesto, DFR se puede utilizar aisladamente si no interesan las caractersticas de DTAM.
149
7.3.1 El estndar DFR DFR permite gestionar documentos y otros objetos dentro de almacenes remotos en un sistema distribuido. El modelo de informacin de DFR describe la estructura jerrquica de los almacenes, y el modelo operacional define las operaciones abstractas a realizar sobre los almacenes de documentos. Es importante destacar que DFR es totalmente independiente de los documentos, pues no entra en su estructura interna, sino slo en la estructura del almacn. Dicho de otra manera, as como DTAM-DM permite manipular dentro de documentos y el objeto mximo que puede manipular es un documento entero, DFR permite manipular dentro del almacn, siendo el documento el objeto mnimo que manipula. Por esta razn, DTAM-DM y DFR son complementarios (vase el apartado 7.4). El modelo de informacin de DFR define un almacn de documentos como una estructura jerrquica que incluye los siguientes objetos: Documento DFR: Una entrada en el almacn que representa un documento. DFR no especifica formato ni estructura del documento. Un documento est formado por un contenido (secuencia de octetos) y un conjunto de atributos Grupo DFR: Una entrada en el almacn que contiene otras entradas. Como mnimo existir el grupo raz. Lista de resultados de bsqueda DFR: Una entrada en el almacn que contiene informacin sobre el resultado de una bsqueda. Referencia DFR: Un objeto que acta como enlace a otro objeto.
Grupo raz DFR
Grupo
Documento 1
Documento 2
Documento 3 Referencia
Lista Documento
Fig. 7.1 Ejemplo de estructura de almacn DFR
150
La figura 7.1 muestra un ejemplo de estructura del almacn DFR. Las operaciones definidas en el estndar DFR se describen en la tabla 7.3.
Tabla 7.3 Operaciones definidas en DFR
Operacin
Crear (Create) Borrar (Delete) Copiar (Copy) Mover (Move) Leer (Read) Modificar (Modify) Enumerar (List)
Descripcin
Crea un nuevo objeto dentro de un grupo Borra un objeto Copia un objeto de un grupo a otro Mueve un objeto desde un grupo fuente hasta un grupo destino Devuelve informacin (atributos o contenido) sobre un objeto Modifica la informacin (atributos o contenido) de un objeto Devuelve los miembros de un grupo o el conjunto de objetos identificados en una lista de resultados de bsqueda Busca entradas que satisfagan un determinado criterio de bsqueda Modifica el nivel de reserva de una entrada Abandona la ejecucin de una operacin iniciada previamente
Buscar (Search)
Reservar (Reserve) Abandonar (Abandon)
7.3.2 Perfiles de DFR Tal como se introdujo en el apartado 7.2.3, los perfiles o estndares funcionales de DFR se estn especificando actualmente. Al igual que para el interfaz de manipulacin de ODA y DTAM-DM, la estructura de perfiles est aprobada y existen borradores ms o menos avanzados de diferentes perfiles, los cuales se publicarn a partir de 1996. Los perfiles DFR se llaman ADFnm, siendo n y m nmeros que identifican ciertas caractersticas de los perfiles, y se estn publicando como ISO/IEC ISP 12069. Se especifican dos grupos de perfiles, los cuales definen subconjuntos funcionales de DFR. Estos grupos son: ADF1: Es para aplicaciones comunes de almacenamiento y recuperacin de documentos. ADF2: Es para gestin remota de un almacn de documentos, normalmente combinado con otra aplicacin para manipular documentos internamente, como DTAM-DM.
El primer grupo consta de los siguientes perfiles:
151
Slo lectura (ADF11): Permite recuperar documentos almacenados o buscarlos, pero no permite almacenar nueva informacin o cambiar la ya existente. Archivo (ADF12): Adems de las caractersticas de ADF11, permite almacenar nuevos documentos, pero no cambiar la informacin ya existente. Manipulacin del almacn de documentos (ADF13): Incluye todas las operaciones de DFR.
El segundo grupo consta de los siguientes perfiles: Gestin simple (ADF21): Proporciona una funcionalidad mnima, como enumerar y buscar, para complementar otras aplicaciones de manipulacin de documentos. Gestin completa (ADF22): Adems de las caractersticas de ADF21, permite funciones de manipulacin (pero sin las operaciones Leer y Crear), tambin para complementar otras aplicaciones.
La tabla 7.4 resume las operaciones disponibles () u opcionales (o) en cada perfil.
Tabla 7.4: Operaciones disponibles en los perfiles DFR
Perfiles DFR Operacin

Crear (Create) Borrar (Delete) Copiar (Copy) Mover (Move) Leer (Read) Modificar (Modify) Enumerar (List) Buscar (Search) Reservar (Reserve) Abandonar (Abandon) ADF11 ADF12 ADF13 ADF21 ADF22

o o
152
7.4 Manipulacin y gestin de documentos

Existen aplicaciones de manipulacin de documentos que necesitan, adems de las operaciones de manipulacin interna de los documentos, otras operaciones para lo que se podra llamar gestin del almacn de documentos. En algunos casos, podra ser suficiente poder buscar y seleccionar el documento deseado antes de su manipulacin, y, en otros casos, podra ser necesario disponer de operaciones ms complejas, como mover, copiar o borrar documentos enteros, o incluso grupos de documentos. En este caso, la aplicacin DTAM-DM puede complementarse con la aplicacin DFR. Para lograr la integracin prctica de los dos estndares, y evitar tener que establecer dos asociaciones de aplicacin (es decir, tener DTAM-DM y DFR de forma independiente), se ha definido, tras largos aos de negociacin entre los diferentes grupos de estandarizacin, una solucin muy simple tcnicamente que consiste en definir un nuevo contexto de aplicacin que incluye los elementos de servicio de aplicacin especficos de DTAM-DM y DFR. De esta forma, cuando se quiera disponer de la funcionalidad conjunta de ambos estndares, bastar con establecer una nica asociacin con el contexto de aplicacin definido especficamente para esto tanto en el estndar DFR como en las recomendaciones DTAM-DM.
7.5 Transferencia y gestin de ficheros en OSI (FTAM)

La aplicacin OSI estandarizada especfica para la transferencia y gestin de ficheros distribuidos es FTAM (File Transfer, Access and Management). La primera versin de FTAM data de 1988 y es previa al modelo DOAM.
Usuario FTAM
Almacn real
Cliente FTAM
Servidor FTAM
Almacn real
Entidad de aplicacin FTAM
Protocolo de acceso FTAM
Entidad de aplicacin FTAM
Conexin de presentacin
Figura 7.2 Arquitectura general de FTAM
153
Los estndares [FTA0188], [FTA0288], [FTA0388], [FTA0488] describen el servicio y el protocolo de FTAM correspondiente a la primera versin de 1988. Posteriormente, en 1990, se aadieron nuevas funcionalidades para la gestin del almacn virtual de ficheros, las cuales se describen en el estndar [FTA0590]. Con el objeto de permitir la transferencia de ficheros entre sistemas heterogneos, FTAM define el concepto de almacn virtual de ficheros (Virtual File Store), de forma que cada sistema de ficheros local, o almacn real, se debe mapear en ese almacn lgico. (vase figura 7.2). Como ya se ha mencionado anteriormente, la aplicacin estndar FTAM es previa a la creacin del modelo DOAM, por lo que la entidad de aplicacin FTAM no tiene ROSE y consta nicamente de un ASE comn para la gestin de asociaciones, que es ACSE, ms el ASE especfico para FTAM que es FTAM-SE (vase figura 7.3).
Cliente de FTAM Servidor de FTAM
UE
UE
Nivel de aplicacin
FTAMSE
Protocolo FTAM
FTAMSE
ACSE
ACSE
Nivel de presentacin
Figura 7.3 Entidad de aplicacin de FTAM
7.5.1 El almacn virtual En la versin del 88, el almacn virtual de FTAM no es ms que una coleccin de ficheros que no tienen relacin entre s (as, por ejemplo, no existe el concepto de directorio). En este apartado se describe la visin de un fichero aislado dentro del almacn virtual. Un fichero FTAM consta del contenido ms una serie de atributos. Los atributos contienen informacin acerca del fichero y pueden ser de dos tipos: atributos de fichero y atributos de actividad. Los atributos de fichero (o estticos) estn asociados a un fichero en particular, de forma que todos los clientes siempre ven el mismo valor del atributo. Existen cuatro grupos de atributos de fichero:
154
kernel almacenamiento seguridad privado
Los atributos de fichero de tipo kernel son obligatorios y bsicamente incluyen informacin sobre el nombre del fichero, las acciones permitidas y el tipo de contenido. El nombre del fichero es nico y se utiliza una cadena de caracteres. Las acciones permitidas indican el tipo de acceso que se puede realizar sobre el fichero, como lectura, escritura, etc. El atributo de tipo de contenido describe la estructura del fichero. Los atributos de almacenamiento contienen informacin respecto al responsable del fichero, fecha y usuario de creacin, ltima lectura y ltima modificacin de contenido y atributos, tamao estimado y mximo, y disponibilidad inmediata o retardada, etc. Los atributos de seguridad contienen informacin relacionada con el control de acceso como passwords, limitaciones de acceso concurrente, acciones permitidas, algoritmo de encriptacin, etc. Finalmente, el cuarto grupo permite a los usuarios aadir atributos no estndar adecuados para sus aplicaciones. Los atributos de fichero de almacenamiento, seguridad y privados son opcionales y se negocian para cada asociacin. Los atributos de actividad (o dinmicos) estn ligados a una determinada asociacin o actividad, de forma que su valor puede variar para cada actividad. Existen tres grupos de atributos de actividad: kernel almacenamiento seguridad
Los atributos de actividad del grupo kernel contienen bsicamente informacin sobre el tipo de contenido del fichero, el acceso solicitado, la identificacin del usuario iniciador de la actividad, localizacin, tipo de procesado y ttulo de las entidades de aplicacin. Los atributos de actividad relacionados con el grupo de almacenamiento estn relacionados bsicamente con el control de la concurrencia y la contabilidad. Finalmente, los atributos de actividad del grupo de seguridad contienen informacin relacionada con el control de acceso y la calificacin legal.
7.5.2 Estructura de los ficheros La estructura de un fichero dentro del almacn virtual consta de unidades de datos (DU, Data Unit) y unidades de datos de acceso al fichero (FADU, File Access Data Unit). Una DU es el menor elemento de datos identificable en un fichero FTAM y es la unidad de datos mnima de
155
transferencia. La relacin entre DU est basada en un modelo jerrquico (vase figura 7.4). Un fichero FTAM es una secuencia de FADU, una FADU se puede ver como una unidad de localizacin (subrbol). Una FADU consta de un nodo (nodo raz de la FADU), que puede tener asociada una DU o no, y opcionalmente puede tener una serie de FADU hijas. Un nodo puede tener asociado un descriptor que indica el nombre del nodo y la distancia al nodo padre, que indica su nivel. Por definicin, el nodo raz tiene nivel 0.
FADU
DU Nivel 0
FADU
FADU
Nivel 1
DU
FADU
FADU
FADU
FADU Nivel 2
DU
DU
DU
Nodo
Unidad de datos (DU)
Fig. 7.4 Estructura general de un fichero FTAM
El estndar define una serie de subestructuras ms sencillas que se pueden derivar de la estructura general de un fichero FTAM, y que se corresponden con algunas de las estructuras de ficheros ms habituales. Por ejemplo, un fichero no estructurado, como un fichero UNIX, consta de una nica FADU con una nica DU asociada (vase figura 7.5).
FADU DU
Fig. 7.5 Estructura FTAM para un fichero no estructurado
Otra estructura de fichero real que se puede representar en un almacn virtual FTAM es un fichero plano o secuencial, que consta de una FADU de nivel 0 con un nodo raz sin DU asociada,
156
ms una serie de FADU de nivel 1 cada una de las cuales es un nodo terminal con DU asociadas (vase figura 7.6).
FADU
Nivel 0
DU (1)
DU (2)
DU (3)
Nivel 1
Fig. 7.6 Estructura FTAM para un fichero secuencial
7.5.3 Regmenes de FTAM Cuando una entidad de aplicacin establece una asociacin para utilizar FTAM, entra en lo que se llama un rgimen FTAM. En la fase de establecimiento del rgimen FTAM se negocia los servicios (unidades funcionales) que se podrn utilizar mientras dura dicha asociacin. A lo largo del progreso de dicho rgimen FTAM, es posible utilizar una serie de servicios que se agrupan a su vez en regmenes que deben tener lugar en una determinada secuencia temporal (vase figura 7.7). El rgimen FTAM se inicia mediante la utilizacin del servicio F-INITIALIZE y puede finalizar de forma normal con el servicio F-TERMINATE o de forma abrupta con los servicios F-ABORT (F-U-ABORT si aborta el usuario o F-P-ABORT si lo hace el proveedor del servicio FTAM). Una vez establecido un rgimen FTAM, se puede seleccionar un fichero dentro del almacn virtual sobre el que poder realizar posteriormente una serie de operaciones mediante el rgimen de seleccin de fichero. Dicho rgimen se puede iniciar mediante la utilizacin de los servicios FSELECT, para seleccionar un fichero ya existente, o F-CREATE para seleccionar un fichero nuevo, es decir, crearlo. Para finalizar el rgimen de seleccin de fichero es posible utilizar los servicios F-DESELECT o F-DELETE, siendo borrado el fichero en el ltimo caso. Todas las operaciones que se realicen a lo largo del rgimen de seleccin de fichero sern sobre el fichero previamente seleccionado siempre y cuando los derechos de acceso as lo permitan. Dentro del rgimen de seleccin de fichero es posible realizar operaciones de gestin del fichero como leer un atributo del fichero, con F-READ-ATTRIBUTE, o cambiarlo, con F-CHANGE-ATTRIBUTE. Estas operaciones son opcionales y se pueden realizar tantas como se desee.
157
A continuacin, y antes de poder realizar operaciones sobre el contenido del fichero, es necesario establecer el rgimen de apertura de fichero, que se inicia con el servicio F-OPEN y finaliza con F-CLOSE. Dentro del rgimen de apertura de fichero es posible realizar operaciones como, por ejemplo, situarse en un determinado punto dentro del fichero abierto, es decir, referenciar una determinada FADU (con F-LOCATE) o borrar una FADU del fichero abierto (con F-ERASE).
Rgimen FTAM Rgimen de seleccin de fichero Rgimen de apertura de fichero Rgimen de transferencia de datos
F-DATA F-DATA-END F-READ F-WRITE F-LOCATE F-ERASE F-OPEN F-READ-ATTRIBUTE F-CHANGE-ATTRIBUTE F-SELECT F-CREATE F-INITIALIZE F-DESELECT F-DELETE F-TERMINATE F-U-ABORT F-P-ABORT F-CLOSE F-TRANSFER-END F-CANCEL
Fig. 7.7 Regmenes FTAM (versin 88)
Para poder realizar operaciones de transferencia es necesario establecer primero el rgimen de transferencia de datos, que se puede establecer en dos direcciones. Si la transferencia de DU se realiza desde el servidor hacia el cliente, el servicio que debe utilizarse para establecer el rgimen de transferencia es F-READ; si, por el contrario, el flujo de DU es de cliente hacia servidor, el servicio es F-WRITE. El rgimen de transferencia de datos finaliza mediante la utilizacin del servicio F-TRANSFER-END. Es posible finalizar el rgimen de transferencia de datos de forma abrupta mediante el servicio F-CANCEL. Para transferir cada una de las DU de la FADU seleccionada es necesario utilizar el servicio F-DATA. El orden en el que se deben transmitir las DU de una FADU viene dado por el tipo de algoritmo seleccionado para atravesar la estructura
158
jerrquica del almacn virtual FTAM. Cuando se han transferido todas las DU se indica mediante el servicio F-DATA-END. En un momento dado, nicamente es posible tener un rgimen abierto de cada tipo pero dentro de un rgimen concreto es posible establecer y terminar tantos regmenes interiores consecutivos del mismo tipo como se desee.
7.5.4 Gestin del almacn virtual Las facilidades relacionadas con la gestin del almacn virtual aparecen en la versin de FTAM de 1990, en la que los ficheros dentro del almacn virtual estn relacionados entre s mediante una estructura de directorios. Dichas operaciones de gestin del almacn virtual se han agrupado en un rgimen opcional llamado rgimen de seleccin generalizada que permite la gestin de subalmacenes. Un fichero, desde el punto de vista de las operaciones de gestin del almacn virtual, es una unidad indivisible, que llamada objeto, sobre la que se pueden realizar operaciones como mover de un directorio a otro, etc. Existen adems otros tipos de objetos en el almacn virtual como son los directorios y las referencias.
Directorio Fichero Referencia
Fig. 7.8 Almacn virtual FTAM
Los objetos tienen asociados una serie de atributos que no son ms que una generalizacin de los atributos asociados a un fichero que ya se han comentado, pero que en este caso se aplican a cualquier tipo de objeto, ya sea fichero, directorio o referencia. Un objeto en el almacn virtual se identifica mediante una ruta de acceso (pathname) que puede contener varios objetos. Algunos de los atributos genricos nuevos son la ruta de acceso primaria (primary pathname), que contiene la ruta de acceso completa desde el objeto raz o el identificador permanente nico (unique permanent identifier) que permite asociar un identificador a un objeto en el momento de su creacin y que no se puede modificar mientras ste exista. Tambin existen atributos especficos para los objetos de tipo directorio o referencia.
159
Los directorios mantienen una relacin de parentesco con otros objetos del almacn de forma que proporcionan una estructura jerrquica al almacn virtual. Las referencias permiten mantener un enlace con otro objeto por lo que permiten que un objeto aparezca en diferentes lugares del almacn sin necesidad de estar fsicamente repetido (vase figura 7.8). La figura 7.9 muestra el esquema completo donde figuran todos los regmenes posibles de FTAM, los analizados en la figura 7.7 correspondientes a la primera versin ms los nuevos aadidos en la segunda versin de FTAM correspondientes a la gestin del almacn virtual. A continuacin se analiza la figura 7.9, de izquierda a derecha, haciendo especial nfasis en los nuevos servicios. El rgimen FTAM es bsicamente el mismo que el descrito en el apartado anterior. Una vez establecido dicho rgimen se puede utilizar el servicio F-LIST para obtener un listado del directorio especificado del almacn virtual. Mediante parmetros es posible seleccionar el tipo de atributos a listar o utilizar palabras de acceso para verificar los derechos de acceso al directorio solicitado. Otro de los servicios que se puede utilizar, una vez inicializado el rgimen FTAM, es F-CHANGE-PREFIX que se utiliza para cambiar el prefijo. El prefijo es un valor de la ruta de acceso de un directorio que sirve para facilitar la referencia posterior de objetos subordinados a dicho directorio, sobre todo cuando estos objetos pertenecen a un almacn con una estructura jerrquica compleja. El prefijo se asigna en la fase de inicializacin del rgimen FTAM y permite utilizar rutas de acceso mucho ms sencillas. El rgimen de seleccin generalizada, que es opcional, empieza con la utilizacin del servicio FGROUP-SELECT y acaba con el servicio F-GROUP-DESELECT. Una vez establecido dicho rgimen es posible utilizar los servicios relacionados con la gestin de grupos de objetos que pueden ser ficheros o referencias a ficheros. Estos servicios son F-GROUP-COPY, F-GROUPMOVE y F-GROUP-LIST. Esta facilidad posibilita realizar operaciones como copiar o mover un grupo de ficheros de un lugar o otro del almacn virtual mediante la utilizacin de un nico servicio. Con el servicio F-GROUP-LIST es posible obtener un listado de los objetos que forman parte del grupo seleccionado. El rgimen de seleccin de objeto puede inicializarse mediante la utilizacin de los servicios siguientes: F-SELECT, F-SELECT-ANOTHER, F-CREATE, F-CREATE-DIRECTORY o FLINK. Los servicios F-SELECT y F-CREATE son los mismos que se muestran en la figura 7.7 para inicializar el rgimen de seleccin de fichero, pero existen nuevos servicios que slo tienen sentido si previamente se ha establecido un rgimen de seleccin generalizado, como son FSELECT-ANOTHER, F-CREATE-DIRECTORY y F-LINK. El servicio F-SELECT-ANOTHER se utiliza para seleccionar el siguiente objeto dentro del grupo previamente seleccionado, el servicio F-CREATE-DIRECTORY, como su nombre indica, sirve para crear un nuevo directorio en el almacn virtual y el servicio F-LINK se utiliza para crear un objeto referencia a fichero. El rgimen de seleccin de objeto se finaliza mediante los servicios F-DESELECT, F-DELETE (ya existentes) y F-UNLINK que slo tiene sentido utilizar si el objeto seleccionado previamente es una referencia. Los servicios F-DELETE y F-DESELECT actan en este caso sobre cualquier tipo de objetos, por ejemplo en el caso de que el objeto seleccionado sea una referencia a fichero, el
160
servicio F-DELETE borra el objeto referencia ms el fichero referenciado por ste; en cambio, si el objeto seleccionado es un directorio, ste slo se puede borrar si el directorio est vaco.
Rgimen FTAM Rgimen de seleccin generalizada Rgimen de seleccin de objeto Rgimen de apertura de fichero Rgimen de transferencia de datos
F-DATA F-DATA-END F-READ F-WRITE F-LOCATE F-ERASE F-OPEN F-READ-ATTRIBUTE F-READ-LINK-ATTRIBUTE F-CHANGE-ATTRIBUTE F-CHANGE-LINK-ATTRIBUTE F-COPY F-MOVE F-SELECT F-SELECT-ANOTHER F-CREATE F-CREATE-DIRECTORY F-LINK F-GROUP-COPY F-GROUP-MOVE F-GROUP-LIST F-GROUP-SELECT F-CHANGE-PREFIX F-LIST F-INITIALIZE F-TERMINATE F-U-ABORT F-P-ABORT F-GROUP-DESELECT F-DESELECT F-DELETE F-UNLINK F-CLOSE F-TRANSFER-END F-CANCEL
Fig. 7.9 Regmenes de FTAM
161
Una vez establecido el rgimen de seleccin de objeto es posible utilizar los servicios F-READATTRIBUTE y F-CHANGE-ATTRIBUTE para leer o alterar atributos sobre los objetos de tipo fichero o directorio previamente seleccionados, pero tambin se pueden utilizar los nuevos servicios F-READ-LINK-ATTRIBUTE y F-CHANGE-LINK-ATTRIBUTE para realizar las mismas operaciones cuando el objeto seleccionado es una referencia. Los servicios F-MOVE y FCOPY son una generalizacin para actuar sobre objetos de tipo fichero o referencia. Por ejemplo, si el objeto seleccionado es un fichero el servicio F-MOVE traslada el fichero dentro del almacn cambiando su ruta de acceso; pero, en cambio, si el objeto seleccionado es una referencia a fichero slo mueve la referencia pero no cambia la ruta de acceso del fichero referenciado. El resto de regmenes y servicios que se muestran en la figura 7.9 son los mismos que ya se han descrito en el apartado 7.5.3.
7.5.5 Unidades funcionales de FTAM Los servicios proporcionados por FTAM estn agrupados en unidades funcionales (UF), cada una de las cuales contiene una serie de elementos de servicio. Las UF de FTAM relacionadas con la gestin de ficheros son: kernel (obligatoria) lectura escritura gestin de ficheros limitada gestin de ficheros mejorada acceso a fichero grupos recuperacin reinicializacin
Durante la fase de establecimiento de un rgimen FTAM se negocian las UF vlidas para dicho rgimen. Con el objeto de simplificar dicha negociacin el estndar define un conjunto de clases de servicio. Cada clase de servicio contiene el conjunto de UF adecuadas para cada tipo de aplicacin donde algunas de dichas UF son opcionales. Las clases de servicio definidas por el estndar FTAM son las siguientes: transferencia (T) gestin (G) transferencia ms gestin (T&G) acceso (A) no limitada (NL)
162
La clase de servicio de transferencia permite el movimiento de ficheros o partes de ficheros entre diferentes sistemas. La clase de gestin permite la lectura y modificacin de atributos de fichero. La clase de transferencia ms gestin permite disponer las funcionalidades de las dos clases anteriores. La clase de acceso permite localizar una parte de un fichero dentro del almacn virtual para despus realizar sobre ella operaciones como lectura, escritura, borrado, etc. Finalmente la clase no limitada slo incluye la UF kernel y deja la inclusin de otras UF para la fase de negociacin en el establecimiento del rgimen de FTAM. En la tabla 7.5 se muestra la relacin entre las UF de FTAM, las clases de servicio y los elementos de servicio correspondientes a la primera versin de FTAM.
Tabla 7.5 Unidades funcionales, clases de servicio y elementos de servicio de FTAM (versin 88)
UF
Clase de servicio T A G T&G NL M M M O M O M - M O O M O O M M O M O O O O M O O O O M O O M O O O O O O O O
Elementos de servicio
Kernel Lectura Escritura Acceso a fichero Gestin de ficheros limitada Gestin de ficheros mejorada Grupos Recuperacin Reinicializacin
F-INICIALIZE, F-TERMINATE, F-U-ABORT, F-P-ABORT, F-SELECT y F-DESELECT F-READ, F-DATA, F-DATA-END, F-CANCEL, F-TRANSFER-END, F-OPEN y F-CLOSE F-WRITE, F-DATA, F-DATA-END, F-CANCEL, F-TRANSFER-END, F-OPEN y F-CLOSE F-LOCATE y F-ERASE F-CREATE, F-DELETE y F-READ-ATTRIB F-CHANGE-ATTRIBUTE F-BEGIN-GROUP y F-END-GROUP F-RECOVERY, F-CHECK y F-CANCEL F-RESTART, F-CHECK y F-CANCEL
M: obligatorio, O: opcional y -: no disponible.
La gestin del almacn virtual introduce una serie de unidades funcionales adicionales que son: gestin limitada del almacn gestin mejorada del almacn manipulacin de objetos manipulacin de grupos
En la tabla 7.6 se muestra la relacin entre las nuevas UF relacionadas con la gestin del almacn virtual, las clases de servicio y los elementos de servicio.
163
Tabla 7.6 Unidades funcionales de FTAM relacionadas con la gestin del almacn virtual
UF
Clase de servicio T A G T&G NL M M M O O O O M O O M O O
Elementos de servicio
Kernel
Gestin limitada del almacn Gestin mejorada del almacn Manipulacin de objetos Manipulacin de grupos -
F-INICIALIZE, F-TERMINATE, F-U-ABORT, F-P-ABORT, F-SELECT y F-DESELECT F-CHANGE-PREFIX y F-LIST F-CREATE-DIRECTORY, F-LINK, F-UNLINK, F-READ-LINK-ATTRIBUTE y F-CHANGE-LINK-ATTRIBUTE F-MOVE y F-COPY F-GROUP-SELECT, F-GROUP-DESELECT, F-GROUP-MOVE, F-GROUP-COPY, F-GROUP-LIST y F-SELECT-ANOTHER
O O O O
O O
O O
M: obligatorio, O: opcional y -: no disponible.
7.6 Transferencia de ficheros en Internet (FTP)

La transferencia de ficheros fue una de las primeras aplicaciones utilizadas para el intercambio de informacin entre ordenadores. Aparece por la necesidad de compartir ficheros como programas de ordenador o datos de usuario entre diferentes sistemas. Una aplicacin de transferencia de ficheros debe garantizar transparencia en el almacenamiento de los datos independientemente del sistema utilizado por los ordenadores que intercambian informacin y, adems, deber garantizar fiabilidad y eficiencia en la transferencia. En Internet existe un servicio de transferencia de ficheros que garantiza estos requerimientos mediante la implementacin de un protocolo bastante sencillo. El protocolo de transferencia de ficheros (FTP, File Transfer Protocol) de Internet es un protocolo fiable y eficiente para la transferencia de ficheros, ya sean programas o datos, independientemente de los tipos de sistemas de almacenamiento. Dicho protocolo se encuentra definido en la [RFC 959].
164
7.6.1 Visin general de FTP El objetivo final de un servicio de transferencia de ficheros es compartir datos que se encuentran almacenados en un sistema de ficheros con otro sistema de ficheros a travs de una red. Este servicio no ser un mero proceso de copia transparente de informacin de un sistema a otro, sino que se deber realizar un procesado inteligente de la informacin de forma que los datos que tenan un cierto sentido en un sistema, conserven el mismo significado en el otro sistema. Uno de los ejemplos ms claros es el de la transferencia de ficheros entre un sistema bajo DOS a otro sistema bajo UNIX. En el caso de transferencia de informacin textual, se sabe que un sistema bajo DOS almacena las lneas separndolas por medio de los caracteres ASCII retorno de carro (CR) y cambio de lnea (LF); sin embargo, un sistema bajo UNIX almacena las lneas separndolas por medio de un nico carcter LF. La transferencia transparente de un fichero de texto de un sistema bajo UNIX a otro bajo DOS, o viceversa, lleva a la obtencin de un fichero diferente del fuente. El resultado es bien conocido por aquellos usuarios que suelen compartir ficheros entre ambos sistemas. Aunque el caso del CR y LF es el ms popular, tambin existen problemas para compartir ficheros entre entornos en los que se almacenan datos textuales en EBCDIC 8 bits y en ASCII 7 bits, o datos binarios con diferentes tamaos de palabra. Por este motivo, en una aplicacin de transferencia de ficheros se diferencia entre los formatos de almacenamiento y la representacin de los datos. La representacin siempre es nica mientras que el almacenamiento puede variar dependiendo del sistema. Es misin de la aplicacin de transferencia el aplicar el procesado necesario a la informacin para que los datos almacenados en sistemas diferentes tengan una misma representacin (Fig. 7.10).
Aplicacin de transferencia de ficheros
Sistema de ficheros
Proceso de transferencia de ficheros
Proceso de transferencia de ficheros
Sistema de ficheros
Formato de almacenamiento 1
Formato de representacin
Formato de almacenamiento 2
Fig. 7.10 Visin general de una transferencia de ficheros
165
7.6.2 Modelo FTP. Servicio y protocolo. El modelo de transferencia de ficheros de Internet est definido en la [RFC 959] e implementa los conceptos introducidos en el punto anterior (Fig. 7.10). En FTP se distingue entre proceso de transferencia de datos servidor (servidor-DTP, Data Transfer Process) y proceso de transferencia de datos usuario (usuario-DTP). Ambos procesos existen de forma independiente y pueden residir en sistemas diferentes o en el mismo sistema. El proceso usuario es el encargado de iniciar la aplicacin de transferencia y sta puede realizarse en ambos sentidos. La fase de transferencia de datos no es suficiente para obtener una aplicacin de transferencia final, sino que son necesarios mecanismos de control por medio de los cuales el iniciador de una transferencia pueda programar cmo debe ocurrir dicha transferencia. Por ejemplo, si se quiere enviar o recibir un fichero, si los datos a transferir son de tipo texto o binarios, si se deben transmitir los datos por red en unidades separadas o en un flujo continuo de datos, si se quiere abortar la transferencia, si se quiere empezar la transferencia desde un punto predeterminado del fichero, etc.
PI: Intrprete de protocolo (Protocol interpreter) DTP: Proceso de transferencia de datos (Data transfer process) Interficie de usuario Usuario
Servidor PI
Comandos FTP Respuestas FTP
Usuario PI
Sistema de ficheros
Servidor DTP
Conexin de datos
Usuario DTP
Sistema de ficheros
Servidor FTP
Cliente FTP
Fig. 7.11 Modelo FTP
En FTP se distinguen los procesos de transferencia de datos de los procesos de control de la transferencia (Fig. 7.11). El control de la transferencia se lleva a cabo por medio de una serie de comandos que forman parte del protocolo de FTP. As, existirn dos procesos diferentes de control, uno en el lado del servidor, que se denomina intrprete de protocolo servidor (servidorPI, Protocol Interpreter), y otro en el lado del usuario denominado intrprete de protocolo usuario (usuario-PI, Protocol Interpreter). Ser un usuario (programa o humano) por medio del interfaz de usuario apropiado quien ordene y controle la transferencia de ficheros. Por medio de ese interfaz, el usuario proporcionar los comandos necesarios al intrprete de usuario (usuario-PI), el cual establecer una conexin de
166
control con el intrprete servidor (servidor-PI). A travs de la conexin de control y por medio del intercambio de comandos, usuario y servidor negocian el modo de la transferencia. El primer intercambio de control que se realiza es el de credenciales de usuario (nombre y contrasea) para permitir o denegar el acceso del usuario al servidor de ficheros. Una vez se ha permitido el acceso del usuario al servidor, ste puede ejecutar diferentes comandos referentes a la representacin de la informacin a intercambiar, esto es, tipo y estructura de los datos, modo de transmisin, etc. Adems, el usuario podr ejecutar tambin comandos que le permitirn gestionar el sistema de ficheros del servidor, por ejemplo, cambiar de directorio, crear directorio, borrar directorio, listar un directorio, visualizar el directorio actual, etc. Ntese que un usuario de FTP dispondr de las mismas facilidades de que dispone para la gestin de un sistema de ficheros local pero aplicadas a un sistema de ficheros remoto. Por supuesto, un usuario slo podr manipular aquellas partes del sistema de ficheros sobre las cuales tenga derechos de acceso. Un usuario podr iniciar una transferencia de ficheros por medio de los comandos enviar (Put) y recibir (Get) un fichero. En el primer caso se transfiere un fichero local al sistema remoto y en el segundo caso se transfiere un fichero remoto al sistema local. El proceso de transferencia de datos entre el usuario y el servidor se realiza por un canal diferente al de control, esto es, se establece una conexin diferente entre usuario y servidor para el intercambio de datos. De esta manera, el canal de control siempre est disponible para intercambiar comandos, por ejemplo, el comando de abortar transferencia, etc. FTP contempla la situacin en la que un usuario quiera transferir ficheros entre dos sistemas, ninguno de los cuales es su sistema local. En este caso, el usuario ser el encargado de iniciar sendas conexiones de control entre los sistemas remotos para establecer y sincronizar una conexin de datos entre ellos (Fig. 7.12).
Conexin de control
Usuario FTP Usuario PI (C)
Conexin de control
Servidor FTP (A)
Conexin de datos
Servidor FTP (B)
Fig. 7.12 Transferencia entre dos servidores FTP
Por ltimo, se debe mencionar que FTP es una aplicacin Internet que hace uso de los servicios de transporte de TCP para proporcionar la fiabilidad en la transferencia. Adems, cada sesin de FTP mantendr una conexin TCP fija para el control de la transferencia y una conexin TCP temporal para cada transferencia de datos (fichero) ordenada. El nmero de puerto TCP utilizado
167
para el control de la conexin es el 21 y para la transferencia de datos existe un puerto por defecto que en el caso del proceso usuario es el mismo que el de control y en el caso del proceso servidor es el puerto nmero 20.
1 Introduccin
15
1 Introduccin
1.1 Aplicaciones distribuidas abiertas?
Las tres palabras que forman el ttulo de este libro pueden tener, si se toman aisladamente, significados muy variados. Sin embargo, aqu se agrupan con un objetivo muy concreto. Cuando se habla de aplicaciones distribuidas, se estn considerando aplicaciones que se ejecutan en mquinas separadas fsicamente. Estas mquinas, dos o ms, cooperan para alcanzar objetivos determinados. El intercambio de mensajes (o correo electrnico), la transferencia de ficheros, la manipulacin remota de documentos, la gestin de informacin remota, etc, son simples ejemplos de aplicaciones distribuidas. Cuando al conjunto de palabras aplicaciones distribuidas le aadimos el adjetivo abiertas, estamos resaltando un aspecto importante de stas, la interconectabilidad de sistemas heterogneos. Una aplicacin distribuida es abierta cuando sigue unas reglas estandarizadas (o normalizadas), que son pblicas, que especifican qu servicio va a dar la aplicacin y qu protocolo va a seguir para dar dicho servicio. Por supuesto, esto no tiene que restringir la implementacin de la aplicacin, sino que, al contrario, sirve para que implementaciones independientes en sistemas diferentes se puedan interconectar gracias a que siguen las reglas definidas en los estndares. Por tanto, este libro describe aplicaciones distribuidas abiertas para intercambiar mensajes, transferir ficheros y documentos, manipular documentos y almacenes de documentos remotamente, acceder a informacin sobre mquinas y usuarios, etc.
16
1.2 OSI e Internet

En el cambiante mundo actual de la comunicacin entre ordenadores, dos enfoques (dos arquitecturas de comunicacin entre ordenadores) distintos, aunque no incompatibles, destacan sobre los dems. Podemos llamarlos OSI e Internet. Cuando se habla de OSI (Open Systems Interconnection), o interconexin de sistemas abiertos, se est haciendo referencia a los sistemas de comunicacin entre ordenadores basados en la arquitectura conocida como OSI (o modelo arquitectnico de referencia OSI), estandarizado por la Organizacin Internacional de Estandarizacin (ISO, International Standards Organization), juntamente con lo que se llamaba (hasta mediados de 1992) Comit Consultivo Internacional de Telefona y Telegrafa (CCITT), y ahora se denomina sector de normalizacin de las Telecomunicaciones de la Unin Internacional de Telecomunicaciones (ITU-T). En el modelo OSI, se definen 7 niveles o capas en los que se estructura la comunicacin entre aplicaciones que funcionan en ordenadores remotos. Los tres primeros niveles corresponden a la red, mientras que los tres ltimos estn orientados a dar servicio a la aplicacin, siendo el nivel intermedio, el nivel 4 o de transporte, el encargado de independizar la red del ordenador, donde residen los niveles del 4 al 7. Este libro se concentra en la capa superior, el nivel 7, o de aplicacin. El lector se supone familiarizado con los conceptos OSI y con las facilidades proporcionadas por los 6 primeros niveles. Existe una amplia bibliografa sobre el modelo OSI y los 6 primeros niveles [vase apartado de bibliografa general OSI]. Cuando se habla de Internet, se est hablando de sistemas de comunicacin basados en el modelo nacido a partir de la idea de un servicio y protocolo sin conexin (connectionless-oriented) para interconectar redes, al cual se llam IP (Internet Protocol). Sobre IP se dise el protocolo de transporte TCP (Transmission Control Protocol). Aunque estos protocolos (TCP/IP) se originaron en un entorno militar (en Estados Unidos), rpidamente se extendieron a entornos cientficos, acadmicos y, sobre todo ltimamente, a entornos comerciales, por supuesto ya en todo el mundo. En Internet, las aplicaciones se implementan directamente sobre el nivel de transporte, y es tambin en estas aplicaciones donde se concentra este libro que, sin llegar a profundizar en todas las aplicaciones Internet tan en auge estos das, s trata sobre la versin Internet de algunas aplicaciones habituales en un entorno OSI. Las aplicaciones distribuidas es una disciplina que est cambiando a gran velocidad, por lo que se corre el riesgo de quedar obsoleto rpidamente. Sin embargo, el contenido de este libro est actualizado de forma que se detalla lo que se est utilizando actualmente y se comenta lo que se utilizar en un futuro prximo.
1 Introduccin
17
1.3 Estandarizacin ISO

Las palabras estndar, norma o recomendacin son habituales a lo largo de este libro, al igual que lo deben ser para cualquier persona que trabaje en el campo de aplicaciones distribuidas. Los conceptos de sistemas abiertos (en OSI) o de interconexin (tanto en Internet como en OSI) estn detrs de esta filosofa. Si queremos conseguir que sistemas heterogneos puedan comunicarse, deben seguir ciertas reglas, y estas reglas se deben acordar internacionalmente. De ah la necesidad de disponer de estndares. Formalmente, los estndares slo pueden ser publicados por ISO, organizacin internacional formada por los organismos de normalizacin de todos los pases del mundo, como AENOR en Espaa, ANSI en Estados Unidos, DIN en Alemania, BSI en el Reino Unido y AFNOR en Francia. En cada pas, el mecanismo de funcionamiento del organismo de normalizacin vara, pero siempre se trata de armonizar los intereses de las empresas privadas, las pblicas y los centros de investigacin. ISO, al igual que sus equivalentes nacionales, est estructurada en comits que trabajan en diferentes temas. Por lo que a los contenidos de este libro incumbe, existe un comit conjunto con el CEI o Comit Electrotcnico Internacional (IEC, International Electrotechnical Committee) llamado JTC1 (Joint Technical Committee 1), que trata todos los temas de las llamadas tecnologas de la informacin. A su vez, el JTC1 est estructurado en subcomits, como el SC18 que trata, en sus distintos grupos de trabajo (WG, Working Group), documentos y protocolos asociados. Ha sido y es responsabilidad del JTC1 SC18 el desarrollo de los estndares de correo electrnico X.400 (vase captulo 4), arquitectura e intercambio de documentos ODA (vase captulo 5), almacenamiento y recuperacin de documentos DFR (vase captulo 7), la notacin para especificar aplicaciones distribuidas (vase captulo 3), etc. Otros temas tratados en este libro, como el directorio X.500 (vase captulo 6), o la propia estructura del nivel de aplicacin (vase captulo 2), son responsabilidad del SC21; y as podramos enumerar los diferentes subcomits del JTC1. A pesar de que, formalmente, los estndares slo pueden ser publicados por ISO, tambin ITU-T (y anteriormente el CCITT) est capacitado para publicar lo que ellos llaman recomendaciones que, a efectos prcticos, tambin son estndares, aunque ms orientados a aspectos de telecomunicaciones, en los que ITU-T, por estar formado por las industrias de telecomunicaciones, compaas telefnicas principalmente, y las administraciones nacionales, tiene algo que decir. La ITU-T tambin tiene una estructura interna, similar de alguna manera a la de ISO, pero con una terminologa propia. ITU-T est formado por grupos de estudio (SG, Study Group), que tratan temas diferentes, como el SG8, que trabaja en intercambio y manipulacin de documentos (vase captulo 6), fax, etc., y el SG7, que trabaja en temas como correo electrnico (vase captulo 4). Cada SG se estructura, a su vez, en lo que se llaman cuestiones (Q, Question). Como se puede deducir de la sencilla enumeracin de los temas de trabajo de algunos subcomits de ISO y grupos de estudio de ITU-T, existen temas comunes. Para evitar que ambos organismos
18
produzcan normas divergentes, muchos grupos de trabajo de ISO han creado equipos de colaboracin o comits conjuntos con cuestiones de ITU-T para desarrollar estndares concretos. En las secciones 1.5 y 1.6 se narra, a modo de ejemplo, la historia del desarrollo de dos estndares conjuntos de ISO/IEC e ITU-T, como son X.400 (vase captulo 4) y ODA (vase captulo 5). Por su parte, las normas de Internet siguen un proceso de estandarizacin diferente a los de ISO e ITU-T (basados en comits o grupos de trabajo que desarrollan los estndares a aprobar posteriormente por los organismos miembros), ya que el desarrollo de normas se basa en la implementacin y prueba de lo que se propone especificar. Un estndar Internet no se acepta si no existen implementaciones probadas. Debido a la complejidad que pueden tener los estndares de ISO o recomendaciones de ITU-T, se definen lo que se llaman estndares funcionales o perfiles, que son subconjuntos implementables de los estndares base. Estos subconjuntos restringen las caractersticas de los estndares al eliminar complejidades innecesarias en aplicaciones menos exigentes, con lo que se facilita su implementacin. Aunque la aprobacin formal de los estndares funcionales (ISP, International Standardized Profile) la hace tambin ISO/IEC, su desarrollo corresponde en muchas ocasiones a grupos regionales (entendiendo por regin un continente entero) y la coordinacin entre estos y, a veces, tambin ITUT. En Europa, existe EWOS (European Workshop for Open Systems) que, a travs de sus grupos de expertos en diversos temas, desarrolla perfiles que despus coordina con otros organismos regionales para producir estndares funcionales a aprobar por ISO/IEC. EWOS tambin es responsable de la produccin de estndares europeos, aprobados oficialmente por el Comit Europeo de Normalizacin (CEN). Otros organismos regionales activos en los temas que trata este libro son OIW (Open Implementors Workshop), en Norteamrica, y AOW (Asia Oceania Workshop), principalmente en Japn, Corea y Australia. Finalmente, en Europa existe otro organismo oficial de normalizacin, el Instituto Europeo de Estndares de Telecomunicaciones (ETSI, European Telecommunications Standards Institute), que como su nombre indica es responsable en Europa del desarrollo de estndares relacionados con las telecomunicaciones. De alguna manera, ETSI es un complemento de ITU-T en aspectos europeos.
1.4 Estandarizacin en Internet

En cuanto al proceso de estandarizacin en Internet, y como caractersticas ms importantes, hay que mencionar que existen muchos menos organismos en el proceso de estandarizacin, y que adems este tiene un fuerte carcter prctico.
1 Introduccin
19
La mejor definicin de lo que es un estndar de Internet (IS, Internet Standard) se encuentra en el documento [RFC1602], y que a continuacin se cita: "En general, un estndar de Internet es una especificacin que es estable y comprensible, es tcnicamente competente, tiene mltiples e independientes implementaciones que interoperan con bastante experiencia demostrable, posee un importante soporte y es reconocido como til por alguna parte o toda la comunidad de la Internet." Como puede desprenderse de la definicin, un estndar de Internet slo puede generarse si primero se demuestra de forma explcita su inters y utilidad prctica. En esencia, el proceso para crear un estndar de Internet es muy sencillo. Cualquier usuario de la Internet puede proponer un borrador de especificacin para ser comentado por los dems. A esta especificacin se la conoce como borrador Internet (ID, Internet Draft). Este documento se pblica en la Internet por medio de servidores de informacin (bsicamente ftp, aunque ahora tambin WWW) para que sea analizado, y comentado pblicamente. Si en el plazo de seis meses este documento no pasa a ser catalogado como peticin de comentarios (RFC, Request For Comments), se ha actualizado generando una nueva versin, el documento simplemente se borra del servidor de informacin y desaparece. Una vez un documento es catalogado como RFC, este puede permanecer as para siempre o iniciar el proceso para alcanzar el estado de estndar de Internet. Para llegar a este estado, el documento deber pasar por varios niveles de madurez, pudindose quedar en alguno de ellos. Segn la terminologa Internet, los niveles de madurez de un documento que pretende ser estndar son: propuesta de estndar (PS, Proposed Standard), borrador de estndar (DS, Draft Standard) y finalmente estndar de Internet (IS, Internet Standard). La diferencia bsica entre ellos, segn se desprende de la definicin de estndar de Internet antes citada, es que una propuesta de estndar no necesita de implementaciones que interoperen, para pasar a borrador de estndar es necesario disponer de por lo menos dos implementaciones independientes, y el grado de estndar slo se alcanza con implementaciones y bastante experiencia en su operacin. Todo el proceso de revisin y aceptacin de especificaciones para su designacin como RFC o estndar de Internet se lleva a cabo mediante un proceso en el que participa toda la comunidad de Internet y unos organismos que la representan y gestionan. De forma resumida, estos organismo son: IETF (Internet Engineering Task Force), que se encarga de los aspectos tecnolgicos y la evolucin de la Internet; ISOC (Internet Society) que entre otras tiene como actividad la estandarizacin en la Internet; IESG (Internet Engineering Steering Group) que controla las actividades del IETF; y el IAB (Internet Architecture Board) que es un grupo tcnico de asesora dentro del ISOC. Por ejemplo, una de las actividades del IAB es, a travs del IANA (Internet Assigned Number Authority), asignar identificadores y parmetros nicos a las RFC, estndares, protocolos, servicios, etc. de la Internet.
20
Esta ha sido una rpida visin del proceso de estandarizacin en la Internet (una descripcin completa puede encontrarse en [RFC-1602]), pero nos permite resaltar dos caractersticas muy importantes en el campo de los sistemas abiertos: Una iniciativa no alcanza el nivel de estndar de Internet si no se demuestra su utilidad prctica y existen implementaciones interoperables. Esto no es as en el caso de ISO y ITU-T, con lo cual es posible tener estndares que nunca se han implementado. Adems, en Internet no existen perfiles, ya que todo lo que se estandariza debe estar implementado. Todos los documentos (Internet Drafts, RFC, Internet Standards, etc.) son pblicos y estn disponibles gratuitamente a toda la comunidad Internet. Esto tampoco es as en el caso de ISO y ITU-T, ya que sus documentos no se encuentran accesibles a todo el pblico y adems hay que pagar por ellos, aunque esto est cambiando ltimamente.
1.5 Historia de X.400

Fue la Federacin Internacional para el Procesado de la Informacin (IFIP, International Federation for Information Processing), una organizacin profesional de informticos, desde su comit tcnico 6 (TC6, Data Communications) quien empez el trabajo de normalizacin del correo electrnico. Para ello cre, a finales de los 70, un grupo de trabajo (WG6.5) para trabajar en la definicin de un modelo de sistema de gestin de mensajes. Este trabajo fue seguido por el entonces CCITT que, en 1984, aprob las primeras recomendaciones internacionales de mensajera electrnica. A pesar de que se fueron descubriendo fallos y limitaciones, estas recomendaciones del CCITT tienen un mrito innegable, especialmente teniendo en cuenta que es la primera norma completamente desarrollada del nivel de aplicacin del modelo de referencia OSI. La experiencia adquirida con estas recomendaciones y las primeras implementaciones llevaron al CCITT a desarrollar una nueva versin, aprobada en 1988, que corrige muchas de las limitaciones de la versin del 84. En este trabajo tambin colabor ISO, lo que dio lugar a una norma conjunta entre CCITT, Recomendaciones X.400 (MHS) e ISO, Estndar Internacional MOTIS (Message Oriented Text Interchange Systems). En los ltimos aos, se ha unificado el nombre (MHS, Message Handling System), aparte de haber ocurrido los cambios administrativos mencionados, como el paso de CCITT a ITU-T, y la creacin del ISO/IEC JTC1. Finalmente, despus de 1988 se han publicado nuevas versiones del estndar que no cambian demasiado la funcionalidad, pero que corrigen y extienden algunas cosas. De hecho, existe una nueva republicacin en 1995.
1 Introduccin
21
1.6 Historia de ODA

La primera norma sobre el tema de arquitectura e intercambio de documentos fue publicada en 1985 por ECMA (European Computer Manufacturers Association) con el nmero ECMA-101, y el ttulo Open Document Architecture . Seguidamente, ISO decidi que era necesario un estndar internacional sobre representacin e intercambio de documentos, por lo que empez a producir su propio estndar. Para ello, se consider la norma de ECMA como documento de partida. De esta manera, tambin, se pas de un mbito europeo a uno ms internacional, en el que se debe destacar la activa participacin de empresas americanas y japonesas. La tarea se encarg inicialmente a dos grupos de trabajo del subcomit 18 (SC18) de lo que es ahora el comit conjunto nmero 1 de ISO y la IEC (ISO/IEC JTC1). Actualmente, el grupo de trabajo nmero 3 del mencionado subcomit (es decir, ISO/IEC JTC1 SC18/WG3) es quien tiene la total responsabilidad sobre el estndar y sus extensiones. La produccin del estndar ODA no es slo debida al trabajo de ISO/IEC, sino que tambin el CCITT (y despus ITU-T), ha hecho suyo el compromiso de la estandarizacin del intercambio de documentos, y est publicando el estndar ODA en paralelo con ISO. La primera versin del estndar ODA fue aprobada oficialmente en 1989 con el nmero ISO 8613 (que consta de 7 partes, de la 1 a la 8 aunque no existe la parte 3), y el ttulo Office Document Architecture (ODA) and Interchange Format (ODIF). Conviene mencionar aqu que el uso inicial de la palabra Office en vez de Open fue debido a las restricciones a sistemas de oficina que originalmente tena el SC18, quien produjo esta primera versin. La versin del estndar publicada por el CCITT era prcticamente idntica a la de ISO, aunque el CCITT usa una estructura diferente, y en vez de tener un estndar con varias partes, tiene varias Recomendaciones que forman una serie. En concreto, el nmero y ttulo dado por el CCITT era CCITT T.410 Series of Recommendations: Open Document Architecture (ODA) and Interchange Format (ODIF). En este caso, las siete partes de ISO 8613 equivalen a las recomendaciones T.411, T.412, T.414, T.415, T.416, T.417 y T.418. El ttulo del estndar est ya unificado, pues ISO decidi, ya en 1990, cambiar la palabra Office por Open. Actualmente, el trabajo de extensin del estndar que se est efectuando, lo realiza un comit formado por ISO/IEC e ITU-T, cuyo objetivo es la mejora y el mantenimiento conjunto del estndar, incluyendo una republicacin realizada en 1994, y extensiones que se han venido publicando desde entonces.
22
ODA 1994 tiene una nueva parte (aunque slo en la versin de ISO/IEC, no en la de ITU-T), que es la 10, titulada Especificaciones formales que, mediante un lenguaje definido en el propio estndar, especifica, sin posibilidad de ambigedades, el estndar completo. Asimismo, otras nuevas partes, como la 3 (Recomendacin T.413 de ITU-T), la 9 (T.419), la 11 (T.421), la 12 (T.422) y la 14 (T.424) (vase captulo 5) se han publicado posteriormente (concretamente en 1995 y 1996).
2 Nivel de aplicacin
23
2.1 Introduccin
El objetivo de los primeros captulos de este libro es presentar los elementos tericos bsicos para especificar y disear aplicaciones en las cuales se procese informacin de una forma distribuida. Para ello es necesario disponer de una serie de funcionalidades orientadas a resolver los problemas relacionados con la distribucin. Estos recursos los proporcionan los sietes niveles del modelo de interconexin de sistemas abiertos (OSI, Open Systems Interconnection) de ISO. Los niveles inferiores del modelo OSI (niveles fsico, enlace, red y transporte), o niveles orientados a la comunicacin, proporcionan los medios necesarios para la transmisin fiable de datos. Los niveles superiores del modelo OSI (niveles sesin, presentacin y aplicacin), o niveles orientados a la aplicacin, proporcionan una serie de servicios para la gestin y sincronizacin del dilogo, la transferencia estndar de estructuras de datos, etc.
El ltimo nivel del modelo OSI es el nivel de aplicacin, que proporciona los servicios necesarios para que una aplicacin pueda gestionar informacin distribuida, facilitando los medios adecuados para acceder al resto de niveles. En una aplicacin distribuida se pueden distinguir dos partes diferenciadas: la aplicacin propiamente dicha y la parte que realiza el acceso a los recursos de comunicacin. Es este ltimo aspecto el que diferencia una aplicacin local de su versin distribuida, y es este aspecto del diseo de aplicaciones distribuidas el que se trata en los primeros captulos de este libro.
24
2.2 Estructura del nivel de aplicacin

El propsito del nivel de aplicacin es servir como intermediario entre procesos de aplicacin de usuario que estn utilizando los recursos OSI para intercambiar informacin (vase la figura 2.1).
Proceso Aplicacin Usuario Protocolo de aplicacin
Proceso Aplicacin Usuario
Nivel de aplicacin
Nivel de aplicacin
Proveedor del servicio de presentacin
Fig. 2.1 Procesos de aplicacin de usuario y nivel de aplicacin
Se define un proceso de aplicacin (AP, Application Process) como un elemento dentro de un sistema abierto que realiza el procesado distribuido de informacin (es decir, que implica comunicacin) para una determinada aplicacin. Los procesos de aplicacin intercambian informacin por medio de entidades de aplicacin que implementan protocolos de aplicacin utilizando servicios de presentacin. Una entidad de aplicacin (AE, Application Entity) define los aspectos concernientes a la comunicacin de un proceso de aplicacin. Las entidades de aplicacin intercambian informacin por medio de unidades de datos del protocolo de aplicacin (APDU, Application Protocol Data Unit) (vase la figura 2.2). En el caso ms general, un proceso de aplicacin puede definir varios tipos de intercambio de informacin. Por lo tanto, su comunicacin tendr varios aspectos que se implementarn mediante diferentes AE. Para la mayor parte de las aplicaciones distribuidas es suficiente una nica entidad de aplicacin. Para que dos entidades de aplicacin puedan cooperar es necesario establecer previamente una asociacin de aplicacin o simplemente una asociacin (Application Association). El concepto de asociacin en el nivel de aplicacin equivale al concepto de conexin en el resto de niveles del modelo OSI. Una asociacin se mapea directamente sobre una conexin de presentacin. La entidad de aplicacin que toma la iniciativa de establecer la asociacin es la entidad que inicia la asociacin (Initiator Entity) y la que acepta o rechaza la asociacin es la entidad que responde (Responder Entity). Una entidad de aplicacin consta de un elemento de usuario (UE, User Element) y un conjunto de elementos de servicio de aplicacin (ASE, Application Service Element) (vase la figura 2.2).
25
El elemento de usuario (UE, User Element) representa aquella parte de la entidad de aplicacin que coordina los elementos de servicio de aplicacin (ASE) necesarios para llevar a cabo los objetivos de comunicacin de dicho proceso de aplicacin. Es decir, gestiona los diferentes ASE que constituyen dicha AE y adems es el interfaz con el proceso de aplicacin de usuario. Un elemento de servicio de aplicacin (ASE, Application Service Element) es aquella parte de una entidad de aplicacin que proporciona una funcin particular en el entorno OSI. Para ello, si es necesario, puede utilizar los servicios proporcionados por otros ASE o por los niveles inferiores. Un ASE no es ms que un conjunto de funciones que permiten a las AE cooperar para un determinado propsito.
Proceso Aplicacin Usuario AE UE ASE 1 ... ASE n Protocolos de aplicacin (APDU) AE
UE ASE 1 ... ASE n
Fig. 2.2 Estructura de una entidad de aplicacin
Un ASE queda definido por un servicio y un protocolo. Por lo tanto, cada ASE genera sus propias APDUs y define diferentes sintaxis abstractas y de transferencia, con lo que da lugar a diferentes contextos de presentacin. En el nivel de aplicacin no se puede hablar de un protocolo de aplicacin nico sino de un conjunto de protocolos de aplicacin, uno para cada par de ASE residentes en entidades de aplicacin remotas. Algunos ASE son obligatorios, es decir, siempre deben formar parte de cualquier entidad de aplicacin, mientras que otros son opcionales. En OSI, el usuario del servicio de presentacin es siempre un ASE. Se define un contexto de aplicacin (AC, Application Context) como el conjunto de servicios y protocolos de aplicacin utilizados por una entidad de aplicacin en una asociacin. Bsicamente indica el conjunto de ASE que componen el proceso de aplicacin definiendo implcitamente los protocolos (vase la figura 2.3). Los ASE que constituyen una entidad de aplicacin pueden ser iguales en los dos extremos y reciben el nombre de ASE simtricos, o complementarios y reciben el nombre de ASE asimtricos. En los ASE asimtricos uno tiene el papel de consumidor o cliente y el otro el papel de suministrador o servidor del servicio (vase el apartado 3.1.1 correspondiente a la arquitectura cliente/servidor).
26
Proceso Aplicacin Usuario AE UE ASE ASE Protocolo de aplicacin AE
UE ASE ASE ROSE
ROSE RTSE ACSE
RTSE ACSE
Fig. 2.3 Estructura de un contexto de aplicacin
Un elemento de servicio de aplicacin (ASE) puede ser de dos tipos: comn especfico
Los ASE comunes son aqullos que ofrecen una funcionalidad que la mayor parte de aplicaciones distribuidas utilizan. Por esta razn se crey conveniente estandarizarlos y se ofrecen como un recurso comn en los entornos de desarrollo de aplicaciones distribuidas. As el diseador puede utilizar estos ASEs comunes y concentrarse en el diseo de la aplicacin propiamente dicha. Los ASE especficos son aquella parte de una entidad de aplicacin que implementan las funcionalidades concretas del sistema distribuido que se est diseando y son la parte que diferencia unas aplicaciones de otras. Se han normalizado varios ASE comunes. Los ms utilizados son: ACSE (Association Control Service Element). Se encarga de la gestin de asociaciones entre entidades de aplicacin. RTSE (Reliable Transfer Service Element). Realiza la transferencia fiable y masiva de APDU. ROSE (Remote Operation Service Element). Se utiliza para implementar interacciones del tipo peticin/respuesta (paradigma cliente/servidor).
Estos ASE comunes no son los nicos que se han normalizado, pero a lo largo del libro solamente se va a hacer referencia a estos tres.
27
La figura 2.3 ilustra el concepto de contexto de aplicacin. Se puede observar que existe una relacin entre los ASE comunes y especficos que constituyen una entidad de aplicacin.
2.3 Direccionamiento en el nivel de aplicacin

Para establecer una asociacin entre dos entidades de aplicacin es necesario poder direccionar una entidad de aplicacin dentro del entorno OSI. Para conseguirlo se utilizan, a nivel de direccionamiento, dos informaciones: contexto de aplicacin (AC) ttulo de la entidad de aplicacin (AE-Title)
El contexto de aplicacin determina el conjunto de protocolos a soportar, pero es en el establecimiento de la asociacin donde se concreta el conjunto de protocolos que se van a utilizar en esa asociacin. El ttulo de un proceso de aplicacin (AP-Title, Application Process Title) identifica un proceso de aplicacin concreto dentro del entorno OSI. Un calificador de entidad de aplicacin (AE-Qualifier, Application Entity Qualifier) identifica una entidad de aplicacin en particular dentro de un proceso de aplicacin. El ttulo de una entidad de aplicacin (AE-Title, Application Entity Title) identifica una entidad de aplicacin concreta dentro del entorno OSI y est formado por: AE-Title = AP-Title + AE-Qualifier En la prctica, como dentro de un proceso de aplicacin (AP) se dispone nicamente de una entidad de aplicacin (EA), es suficiente con disponer de AP-Title con lo que, al no utilizar el AE-Qualifier, el AP-Title y el AE-Title coinciden. Normalmente, estas estructuras de datos de direccionamiento son del tipo OBJECT IDENTIFIER de ASN.1. A partir de la informacin de direccionamiento de aplicacin, normalmente el AP-Title, se debe obtener la direccin de presentacin, a partir de la cual se puede obtener la direccin de red. Este proceso puede ser local mediante un mapeo, en cuyo caso se est utilizando un mtodo no estndar, o normalizado utilizando el servicio de directorio estndar (X.500) donde, a partir de un nombre distintivo, como AP-Title, es posible obtener la direccin de presentacin. (vase el captulo 5).
2.4 ACSE (Elemento de servicio de control de asociacin)

El elemento de servicio de control de asociacin (ACSE, Association Control Service Element) es el encargado de suministrar facilidades para la gestin de asociaciones entre entidades de aplicacin que se comunican a travs de una conexin de presentacin. El elemento de servicio comn ACSE es
28
obligatorio, es decir, debe formar parte de cualquier entidad de aplicacin. Existe una correspondencia uno a uno entre una conexin de presentacin y una asociacin de aplicacin. Los estndares [ACS0192] y [ACS0194] definen el servicio de ACSE, y [ACS0288] y [ACS0391] describen el protocolo.
2.4.1 Servicio El servicio ACSE asume que se dispone como mnimo de la unidad funcional Kernel de presentacin. Los servicios que suministra ACSE son los siguientes: Servicio A-ASSOCIATE A-RELEASE A-ABORT A-P-ABORT Tipo Confirmado Confirmado No confirmado No confirmado (iniciado por el proveedor)
A-ASSOCIATE El servicio A-ASSOCIATE sirve para establecer una asociacin y es un servicio confirmado (Fig. 2.4). Mediante los parmetros del servicio A-ASSOCIATE se especifica, entre otras cosas, el contexto de aplicacin, la lista de contextos de presentacin vlidos para cada ASE y el contexto de presentacin por defecto para una asociacin determinada.
Usuario ACSE
Proveedor ACSE
Usuario ACSE
A-ASSOCIATE.request A-ASSOCIATE.indication A-ASSOCIATE.response A-ASSOCIATE.confirm
Fig 2.4 Primitivas del servicio A-ASSOCIATE de ACSE
El servicio A-ASSOCIATE tiene los siguientes parmetros: modo: normal o X.410-1984 contexto de aplicacin ttulo de la entidad de aplicacin iniciadora
29
ttulo de la entidad de aplicacin llamada ttulo de la entidad de aplicacin que responde (opcional) informacin de usuario resultado diagnstico (slo si se ha rechazado la asociacin) direccin de la entidad de presentacin iniciadora direccin de la entidad de presentacin llamada direccin de la entidad de aplicacin que responde (opcional) lista de contextos de presentacin: inicial y resultante contexto de presentacin por defecto: inicial y resultante calidad de servicio parmetros relacionados con presentacin y sesin: tokens, puntos de sincronizacin, etc.
Estos parmetros aparecen en las cuatro primitivas del servicio A-ASSOCIATE. De todas formas, existen algunas pequeas diferencias entre los parmetros de cada una de las primitivas en lo que hace referencia a la opcionalidad. El parmetro modo selecciona entre un modo de funcionamiento de ACSE normal, que adems es el valor por defecto, y un modo de funcionamiento especfico para mensajera electrnica. Con el parmetro contexto de aplicacin, el iniciador de la asociacin propone un contexto de aplicacin para la asociacin que solicita. A continuacin hay una serie de parmetros donde se identifican las entidades de aplicacin que inicia y acepta la asociacin. El ttulo de la entidad de aplicacin consta del ttulo del proceso de aplicacin y el calificador de la entidad de aplicacin. El campo de informacin de usuario lo pueden utilizar indistintamente las dos entidades para incluir informacin (por ejemplo, credenciales de autenticacin, etc.). El parmetro resultado contiene informacin relativa al resultado de la negociacin del establecimiento de la asociacin: aceptada, rechazada de forma transitoria o rechazada de forma permanente. El parmetro diagnstico indica la causa del rechazo de la asociacin si as lo indica el parmetro resultado; los valores pueden ser no existe razn aparente, contexto de aplicacin no soportado y ttulo de la entidad de aplicacin iniciadora o llamada desconocido. El resto son parmetros relacionados con los niveles de presentacin y sesin. El servicio A-ASSOCIATE se mapea directamente sobre el servicio P-CONNECT de presentacin. La entidad de aplicacin que ha generado la primitiva A-ASSOCIATE.request antes de recibir AASSOCIATE.confirmation slo puede utilizar el servicio A-ABORT.
A-RELEASE El servicio A-RELEASE, que es confirmado, es una liberacin ordenada y sirve para finalizar una asociacin sin prdida de informacin en trnsito (Fig. 2.5). La liberacin de una asociacin puede iniciarla cualquiera de las dos entidades de aplicacin.
30
Usuario ACSE
Proveedor ACSE
Usuario ACSE
A-RELEASE.request A-RELEASE.indication A-RELEASE.response A-RELEASE.confirm
Fig 2.5 Primitivas del servicio A-RELEASE de ACSE
Los parmetros de las primitivas del servicio A-RELEASE son: Causa de la liberacin Informacin de usuario Resultado: afirmativo o negativo
El parmetro causa de la liberacin, si figura en al primitiva A-RELEASE.request, puede tener los valores normal, urgente o definido por el usuario, pero si es un parmetro de la primitiva ARELEASE.response, los valores posibles son: normal, no finalizada o definida por el usuario. El parmetro resultado lo utiliza la entidad de aplicacin que acepta la asociacin para indicar la aceptacin o rechazo de la liberacin de la asociacin. El servicio A-RELEASE se mapea directamente sobre el servicio P-RELEASE de presentacin.
A-ABORT El servicio A-ABORT lo utiliza el usuario de ACSE para liberar una asociacin de forma abrupta. Es un servicio no confirmado (Fig. 2.6).
Usuario ACSE
Proveedor ACSE
Usuario ACSE
A-ABORT.request A-ABORT.indication
Fig. 2.6 Primitivas del servicio A-ABORT de ACSE
31
Los parmetos de las primitivas del servicio A-ABORT son los siguientes: Origen del aborto: usuario de ACSE o proveedor del servicio ACSE Informacin de usuario
El primer parmetro, como su nombre indica, contiene informacin del origen de la liberacin. El campo de informacin de usuario pueden utilizarlo las entidades de aplicacin para incluir informacin cuyo significado depende del contexto de aplicacin. El servicio A-ABORT se mapea directamente sobre el servicio P-U-ABORT de presentacin. Una vez generada la primitiva A-ABORT.request, para el iniciador la asociacin ha sido liberada. El proveedor del servicio ACSE puede utilizar el servicio A-ABORT para liberar una asociacin por problemas internos del protocolo de aplicacin.
A-P-ABORT El servicio A-P-ABORT se utiliza para liberar una asociacin de forma abrupta fruto de una iniciativa del proveedor del servicio. El servicio A-P-ABORT es un servicio no confirmado que consta de una sola primitiva A-PABORT.indication, y que inicia el proveedor del servicio ACSE (Fig. 2.7). El proveedor del servicio ACSE utiliza este servicio para indicar que se ha producido una liberacin de la asociacin anmala, normalmente debida a problemas en los niveles inferiores. Esta situacin puede originar prdida de informacin en trnsito. El nico parmetro de la primitiva de servicio A-P-ABORT.indication es: Causa del aborto iniciado por el proveedor
Usuario ACSE
Proveedor ACSE
Usuario ACSE
A-P-ABORT.indication
A-P-ABORT.indication
Figura 2.7 Primitivas del servicio A-P-ABORT de ACSE
El servicio A-P-ABORT de ACSE se mapea directamente sobre el servicio P-P-ABORT de presentacin.
32
2.4.2 Protocolo El protocolo ACSE describe la transferencia de informacin entre entidades de aplicacin para la gestin de asociaciones, es decir, las unidades de datos de aplicacin (APDU). El protocolo ACSE consta de los siguientes elementos de protocolo: Establecimiento de una asociacin Liberacin normal de una asociacin Liberacin abrupta de una asociacin
Las unidades de datos del protocolo de aplicacin (APDU) de ACSE son las siguientes: AARQ AARE RLRQ RLRE ABRT A-ASSOCIATE-REQUEST A-ASSOCIATE-RESPONSE A-RELEASE-REQUEST A-RELEASE-RESPONSE A-ABORT
La fase de establecimiento de una asociacin utiliza las APDU AARQ y AARE, la fase de liberacin normal RLRQ y RLRE, y la fase de liberacin abrupta utiliza la APDU ABRT. A continuacin se muestra una tabla donde aparecen las primitivas de servicio de ACSE y las correspondientes APDU que las transportan. Primitiva ACSE A-ASSOCIATE.request/indication A-ASSOCIATE.response/confirmation A-RELEASE.request/indication A-RELEASE.response/confirmation A-ABORT.request/indication A-P-ABORT.indication APDU AARQ AARE RLRQ RLRE ABRT ---
Para hacerse una idea de la complejidad del protocolo ACSE, la mquina de protocolo de control de asociaciones consta de ocho estados, del orden de 40 transacciones, 15 eventos entrantes y otros tantos salientes.
2.5 RTSE (Elemento de servicio de transferencia fiable)

El elemento de servicio comn RTSE (Reliable Transfer Service Element) es el encargado de suministrar facilidades para la transferencia de APDU de gran tamao, garantizando la recepcin ntegra y nica de las APDU en el otro extremo. El elemento de servicio RTSE es opcional, es decir, puede formar parte o no de una entidad de aplicacin. En el caso de que est presente, es el encargado de manejar el elemento de servicio ACSE para la gestin de asociaciones, y del nivel de
33
presentacin para la transferencia de APDU. El estndar [RTS0189] define el servicio de RTSE, y [RTS0289] describe el protocolo. RTSE proporciona un mecanismo independiente de la aplicacin para recuperarse de fallos durante el proceso de transmisin de la informacin, minimizando el nmero de retransmisiones. De esta forma, libera al diseador de aplicaciones distribuidas de tener que preocuparse por la gestin de las facilidades que suministra sesin, a travs de presentacin, para recuperarse de dicho tipo de problemas.
2.5.1 Servicio El servicio RTSE utiliza el servicio de ACSE para gestionar asociaciones, y asume que se dispone como mnimo del subconjunto bsico de actividades de sesin (BAS) accesible a travs del servicio de presentacin. Recordar que el servicio de sesin BAS consta de las unidades funcionales: kernel, half-duplex, datos tipificados, datos con capacidad, puntos de sincronizacin menor, excepciones y actividades. Los servicios que suministra RTSE son los siguientes: Servicio RT-OPEN RT-TRANSFER RT-TURN-PLEASE RT-TURN-GIVE RT-CLOSE RT-U-ABORT RT-P-ABORT Tipo Confirmado Confirmado (Slo solicitud, indicacin y confirmacin) No confirmado No confirmado Confirmado No confirmado No confirmado (Slo indicacin)
RT-OPEN El servicio RT-OPEN, que es confirmado, utiliza el elemento de servicio ACSE para establecer una asociacin, concretamente mediante el servicio A-ASSOCIATE (Fig. 2.8).
Usuario RTSE
Proveedor RTSE
Usuario RTSE
RT-OPEN.request RT-OPEN.indication RT-OPEN.response RT-OPEN.confirmation
Fig 2.8 Primitivas del servicio RT-OPEN de RTSE
34
El servicio RT-OPEN tiene los siguientes parmetros: Modo de dilogo: monlogo o alternativo (TWA, Two-way-alternate) Turno inicial Protocolo de aplicacin Datos de usuario Parmetros relacionados con ACSE Parmetros relacionados con presentacin y sesin
El primero de los parmetros especficos relacionados con el servicio RT-OPEN es el modo del dilogo, que puede ser monlogo, es decir, que nicamente la entidad que est inicialmente en posesin del turno puede transmitir APDU, o TWA, donde las dos entidades pueden hacerlo alternativamente siempre y cuando estn en posesin del turno, el cual puede intercambiarse. Otro parmetro nuevo es el turno inicial, que lo puede poseer la entidad que inicia o la que responde la asociacin. El parmetro protocolo de aplicacin slo tiene sentido en el modo X.410-1984 (vase el apartado 2.4 relacionado con ACSE). El parmetro datos de usuario se puede utilizar para almacenar informacin relacionada con el proceso de establecimiento de la asociacin de aplicacin. El resto de parmetros son los mismos que se han descrito en el apartado 2.4.1, correspondiente a ACSE.
RT-TRANSFER El servicio RT-TRANSFER lo utiliza el usuario de RTSE que est en posesin del turno para transmitir APDU de forma fiable mediante una asociacin de aplicacin. Normalmente, los servicios confirmados constan de cuatro primitivas; en cambio, el servicio RT-TRANSFER slo tiene tres primitivas (vase la figura 2.9). La razn es que una APDU se transmite dentro de una actividad, por lo que la finalizacin de la actividad con normalidad significa que la APDU ha sido transferida correctamente por el proveedor de RTSE. Es el protocolo RTSE el que garantiza que la APDU se ha transmitido, por lo que el usuario receptor no necesita confirmarlo, ya que lo hace directamente el proveedor de RTSE (vase el apartado 2.5.2 correspondiente al protocolo RTSE).
Usuario RTSE
Proveedor RTSE
Usuario RTSE
RT-TRANSFER.request RT-TRANSFER.indication RT-TRANSFER.confirmation
Fig. 2.9 Primitivas del servicio RT-TRANSFER de RTSE
Los parmetros del servicio RT-TRANSFER son: APDU a transmitir
35
Tiempo mximo de transferencia estimado Resultado de la transferencia: positivo o negativo
El primer parmetro contiene la APDU que se desea transmitir, el segundo define el tiempo mximo estimado para la transferencia de la APDU; es decir, el tiempo que transcurre entre que el usuario de RTSE invoca el servicio RT-TRANSFER con la primitiva RT-TRANSFER.request y el mismo usuario recibe la confirmacin con la primitiva RT-TRANSFER.confirmation. El parmetro resultado contiene informacin respecto al xito o fracaso de la transferencia de la APDU. El caso en que el resultado es negativo significa que el proveedor de RTSE no ha podido entregar la APDU en el tiempo de transferencia especificado, mientras que si el resultado es positivo, significa que el proveedor de RTSE ha podido entregar de forma fiable la APDU al usuario de RTSE remoto. El servicio RT-TRANSFER desencadena la utilizacin de una serie de servicios de presentacin que hacen posible que la transferencia de APDU se realice dentro de una actividad (vase el apartado 2.5.2, correspondiente al protocolo RTSE).
RT-TURN-PLEASE El servicio RT-TURN-PLEASE es no confirmado, y lo utiliza el usuario de RTSE de la entidad de aplicacin que quiere transmitir APDU para conseguir el turno si no lo tiene (vase la figura 2.10). Tambin lo debe utilizar el usuario de RTSE de la entidad de aplicacin iniciadora de la asociacin para liberarla.
Usuario RTSE
Proveedor RTSE
Usuario RTSE
RT-TURN-PLEASE.request RT-TURN-PLEASE.indication
Fig. 2.10 Primitivas del servicio RT-TURN-PLEASE de RTSE
El servicio RT-TURN-PLEASE slo tiene un parmetro, que es la prioridad asociada a la accin para la que se solicita el turno. Con esta informacin, el usuario de RTSE remoto puede decidir cundo entrega el turno. La prioridad cero indica la prioridad ms alta y se reserva para liberar la asociacin. El servicio RT-TURN-PLEASE se mapea sobre el servicio de presentacin P-TOKEN-PLEASE.
RT-TURN-GIVE El servicio RT-TURN-GIVE, que es no confirmado, permite a un usuario de RTSE de una entidad de aplicacin entregar el turno al usuario de RTSE remoto, siempre y cuando est en posesin del turno
36
y no est pendiente de la finalizacin de un servicio de transferencia de APDU (RT-TRANSFER) (vase la figura 2.11).
Usuario RTSE
Proveedor RTSE
Usuario RTSE
RT-TURN-GIVE.request RT-TURN-GIVE.indication
Fig. 2.11 Primitivas del servicio RT-TURN-GIVE de RTSE
El servicio RT-TURN-GIVE no tiene parmetros y se mapea directamente sobre el servicio de presentacin P-CONTROL-GIVE.
RT-CLOSE El servicio RT-CLOSE, que es confirmado, permite al usuario de RTSE liberar de forma ordenada una asociacin de aplicacin (vase la figura 2.12). La liberacin slo puede realizarla el usuario de RTSE de la entidad iniciadora de la asociacin cuando est en posesin del turno y no tiene pendiente la finalizacin de una transferencia de APDU (recepcin de RTTRANSFER.confirmation). El usuario de RTSE de la entidad de aplicacin que responde la asociacin no puede rechazar la liberacin.
Usuario RTSE
Proveedor RTSE
Usuario RTSE
RT-CLOSE.request RT-CLOSE.indication RT-CLOSE.response RT-CLOSE.confirmation
Fig. 2.12 Primitivas del servicio RT-CLOSE de RTSE
Los parmetros de las primitivas del servicio RT-CLOSE son: Causa de la liberacin Informacin de usuario
Estos parmetros nicamente tienen sentido en modo de operacin normal, ya que en modo X.4101984 no existen parmetros.
37
El servicio RT-CLOSE de RTSE se mapea directamente sobre el servicio A-RELEASE de ACSE, que a su vez se mapea sobre el servicio P-RELEASE de presentacin.
RT-U-ABORT El servicio RT-U-ABORT lo pueden utilizar los dos usuarios de RTSE para liberar una asociacin de forma abrupta, y utiliza los servicios equivalentes de ACSE. El servicio RT-U-ABORT es un servicio no confirmado (vase la figura 2.13).
Usuario RTSE Proveedor RTSE Usuario RTSE
RT-U-ABORT.request RT-U-ABORT.indication
Fig. 2.13 Primitivas del servicio RT-U-ABORT de RTSE
El servicio RT-U-ABORT slo tiene un parmetro, que es un campo de informacin del usuario que se utiliza para informar sobre el proceso de liberacin abrupta de la asociacin de aplicacin. El servicio RT-U-ABORT de RTSE se mapea directamente sobre el servicio A-ABORT de ACSE.
RT-P-ABORT El servicio RT-P-ABORT se utiliza para liberar una asociacin de forma abrupta fruto de una iniciativa del proveedor del servicio RTSE y, como en el caso anterior, lo hace utilizando el servicio equivalente de ACSE A-P-ABORT (vase la figura 2.14). El proveedor del servicio informa a los dos usuarios de RTSE que le es imposible mantener la asociacin de aplicacin.
Usuario RTSE
Proveedor RTSE
Usuario RTSE
RT-P-ABORT.indication
RT-P-ABORT.indication
Fig. 2.14 Primitivas del servicio RT-P-ABORT de RTSE
El servicio RT-P-ABORT, que no tiene parmetros, es un servicio no confirmado que consta de una sola primitiva (RT-P-ABORT.indication) que inicia el proveedor del servicio RTSE. El servicio RT-P-ABORT de RTSE se mapea directamente sobre el servicio A-P-ABORT de ACSE.
38
2.5.2 Protocolo La mquina de protocolo de RTSE (RTPM, Reliable Transfer Protocol Machine), proporciona el servicio RTSE que se ha descrito en el apartado anterior utilizando el elemento de servicio ACSE y el servicio de presentacin. El protocolo RTSE consta de los siguientes elementos de protocolo: Establecimiento de una asociacin (que se realiza mediante ACSE) Transferencia de APDU Peticin y cesin de turno Liberacin de una asociacin: ordenada y abrupta (que se realiza mediante ACSE) Gestin de errores
Las unidades de datos del protocolo de aplicacin (APDU) de RTSE son las siguientes: RTORQ RTOAC RTORJ RTTR RTTP RTAB RT-OPEN-REQUEST RT-OPEN-ACCEPT RT-OPEN-REJECT RT-TRANSFER RT-TOKEN-PLEASE RT-P-ABORT y RT-U-ABORT
A continuacin se muestra una tabla donde se indica el mapeo entre las primitivas de servicio de RTSE y las primitivas de ACSE, as como las APDU que las transportan. Primitiva RTSE RT-OPEN.request/indication RT-OPEN.response/confirmation RT-OPEN.response/confirmation RT-CLOSE.request/indication RT-CLOSE.response/confirmation RT-U-ABORT.request/indication RT-P-ABORT.indication APDU RTORQ RTOAC RTORJ ----RTAB RTAB Primitiva ACSE A-ASSOCIATE.request/indication A-ASSOCIATE.response/confirmation A-ASSOCIATE.response/confirmation A-RELEASE.request/indication A-RELEASE.response/confirmation A-ABORT.request/indication A-P-ABORT.indication
Cuando un usuario de RTSE invoca el servicio RT-TRANSFER, la transferencia fiable de la APDU se realiza a nivel de presentacin dentro de una actividad (servicios P-ACTIVITY-START y PACTIVITY-END). Para poder transmitir la APDU ser necesario fraccionar la APDU en una serie de trozos de un determinado tamao que se habr negociado en la fase de establecimiento de la asociacin (espaciado entre puntos de sincronizacin). Para poder fraccionar la APDU primero es necesario serializar la informacin, para lo cual, la mquina de protocolo de RTSE deber obtener la sintaxis de transferencia y entregar cada fragmento al servicio de presentacin. A cada uno de estos fragmentos de la APDU original as obtenidos se le asigna el tipo OCTECT STRING de ASN.1, y se entregan al servicio de presentacin mediante tantas primitivas del servicio P-DATA como sea necesario. Con el objeto de facilitar las retransmisiones en caso de problemas, se va marcando la transmisin con puntos de sincronizacin menor (servicio P-MINOR-SYNC). El nmero de puntos
39
de sincronizacin que pueden existir sin confirmar se negocia tambin en la fase de establecimiento de la asociacin (tamao de la ventana). La utilizacin de actividades a nivel de presentacin justifica que el servicio RT-TRANSFER tenga tres primitivas en vez de cuatro como tienen todos los servicios confirmados. Efectivamente, el hecho de que la actividad de presentacin acabe normalmente significa que la APDU se ha transmitido correctamente y se encuentra ntegra en el proveedor de RTSE remoto. Incluir una primitiva de respuesta a nivel de usuario de RTSE no aportara nada respecto a la transmisin de la APDU, pero en cambio introducira redundancia en la transmisin. En la figura 2.15 se ilustra grficamente la relacin entre la utilizacin por un usuario de RTSE del servicio RT-TRANSFER para transmitir una APDU, y los servicios de presentacin necesarios para transmitirla dentro de una actividad.
Usuario RTSE
Proveedor P-ACTIVITY-START . request
Usuario RTSE
RT-OPEN.request P-DATA.request
P-ACTIVITY-START . indication P-DATA.indication
P-SYNC-MINOR. request P-ACTIVITY-END. request P-SYNC-MINOR. indication P-ACTIVITY-END. indication RT-TRANSFER.indication P-ACTIVITY-END. response P-ACTIVITY-END. confirmation RT-OPEN.confirmation
Fig. 2.15 Transferencia fiable de una APDU de RTSE y su relacin con el nivel de presentacin
El proceso de serializacin de la informacin aplicando unas reglas de codificacin concretas para obtener una sintaxis de transferencia es una funcin del nivel de presentacin. En cambio se ha dicho que la mquina de protocolo de RTSE realiza dicha funcin cuando tiene que transferir una APDU. Esto vulnera la independencia de los niveles que preconiza ISO en su modelo de interconexin de sistemas abiertos y es una de las incoherencias que presenta el nivel de aplicacin. A continuacin se muestra una tabla donde aparece el mapeo entre las primitivas de RTSE y las primitivas de presentacin, as como tambin las APDU que las transportan. Primitiva RTSE RT-TRANSFER.request/indication APDU --RTTR ----Primitiva Presentacin P-ACTIVITY-START.request/indication P-DATA.request/indication P-MINOR-SYNCHRONIZE P-ACTIVITY-END
RT-TRANSFER.indication/confirmation
40
RT-TURN-PLEASE.request/indication RT-TURN-GIVE.request/indication
RTTP ---
P-TOKEN-PLEASE.request/indication P-CONTROL-GIVE.request/indication
2.6 ROSE (Elemento de servicio de operaciones remotas)

El tercer elemento de servicio comn del nivel de aplicacin es ROSE (Remote Operations Service Element), que se utiliza para implementar aplicaciones distribuidas interactivas del tipo peticin/respuesta (paradigma cliente/servidor). Una entidad de aplicacin invoca la operacin remota (invoker entity) y la otra la realiza y genera un resultado (performer entity). El mecanismo de operaciones remotas se implementa utilizando el elemento de servicio comn de aplicacin ROSE. Los estndares [ROS0189] y [ROS1294] describen el servicio de ROSE y los estndares [ROS0289] y [ROS1394] el protocolo. La respuesta (reply) generada a partir de una solicitud (request) puede ser de tres tipos en funcin del resultado de la operacin remota. As, si se ha ejecutado correctamente, la respuesta ser un resultado; si se ha ejecutado pero sin xito, la respuesta ser un error; y la ltima posibilidad es que la operacin no se haya podido ejecutar por alguna razn, en ese caso la respuesta ser un rechazo (vase la figura 2.16).
AE Invoca operacin remota
Invocacin Resultado Rechazo Error
AE Realiza operacin remota
Fig 2.16 Modelo funcional para ROSE
Las operaciones remotas se pueden clasificar segn dos modos de funcionamiento llamados modo sncrono y modo asncrono. El modo sncrono consiste en la posibilidad de invocar las operaciones de forma secuencial, de forma que, cuando se lanza una operacin remota en modo sncrono, no se puede lanzar la siguiente hasta que no se ha recibido su correspondiente respuesta. En modo asncrono se pueden lanzar varias operaciones remotas sin necesidad de esperar las respectivas respuestas, sino que stas van llegando conforme se van produciendo. Las operaciones remotas tambin se pueden clasificar en cinco tipos o clases en funcin del modo de operacin que utilizan y el tipo de resultado que generan. La operacin clase 1 utiliza modo sncrono y genera siempre una respuesta, ya sea resultado o error. La operacin clase 2 utiliza modo asncrono y genera siempre una respuesta. La operacin clase 3 utiliza modo asncrono y slo genera un error si existe, y si se ejecuta correctamente no genera ninguna respuesta. Las operaciones clase 4 utilizan modo asncrono y slo generan un resultado, mientras que las de clase 5, que tambin utilizan modo asncrono, no devuelven ninguna respuesta en ningn caso (vase la figura 2.17).
41
Invoca RO AE Invocacin Respuesta Invocacin Respuesta Invocaciones Clase 2 Respuestas Invocaciones Clase 3 Error Invocaciones Clase 4 Clase 5 Resultado Invocaciones
Realiza RO AE
Clase 1
Fig. 2.17 Clases de operaciones remotas de ROSE
En algunos casos es til disponer de la posibilidad de agrupar operaciones de forma que una operacin inicial, llamada operacin padre, desencadene como respuesta nuevas operaciones llamadas operaciones hijas. Se dice que las operaciones hijas estn enlazadas ("linked") con la operacin padre (vase la figura 2.18).
AE
invocacin de operacin padre invocacin de operacin hija
AE ejecucin de operacin padre ejecuta la operacin padre
ejecuta las operaciones hijas enlazadas
invocacin de operacin hija
Fig 2.18 Operaciones remotas enlazadas
2.6.1 Servicio Los servicios que ofrece ROSE son los siguientes: Servicio RO-INVOKE RO-RESULT Tipo No confirmado No confirmado
42
RO-ERROR RO-REJECT-U RO-REJECT-P
No confirmado No confirmado (Iniciado por el usuario) No confirmado (Iniciado por el proveedor)
RO-INVOKE El servicio RO-INVOKE, que es no confirmado, lo utiliza un usuario de ROSE para invocar una operacin remota que deber ejecutar el usuario de ROSE remoto (vase la figura 2.19).
Usuario ROSE
Proveedor ROSE
Usuario ROSE
RO-INVOKE.request RO-INVOKE.indication
Fig. 2.19 Primitivas del servicio RO-INVOKE de ROSE
Los parmetros del servicio RO-INVOKE son los siguientes: Identificador de la operacin Clase de la operacin Argumento Identificador de la invocacin Identificador de la operacin enlazada Prioridad
El parmetro "identificador de la operacin" identifica la operacin que se va a invocar y tiene que ser el mismo para los dos usuarios de ROSE. El argumento "clase de la operacin" sirve para saber si se utiliza modo sncrono o asncrono y el tipo de respuesta esperada (resultado, error o rechazo); su uso permite optimizar la gestin del turno en el caso de que se utilice RTSE. El parmetro "argumento", como su nombre indica, es el argumento de la operacin invocada. El "identificador de la invocacin" sirve para asociar una respuesta a una invocacin cuando se trabaja en modo asncrono o para el caso de que existan operaciones enlazadas (o hijas). El parmetro "identificador de la operacin enlazada", que es opcional, si existe significa que la operacin invocada es una operacin hija y se utiliza para indicar la operacin padre. El parmetro "prioridad" se utiliza para asignar una escala de prioridades a las diferentes transferencias de APDU entre las entidades de aplicacin. El servicio RO-INVOKE de ROSE se mapea directamente sobre el servicio P-DATA del nivel de presentacin.
43
RO-RESULT El servicio RO-RESULT lo utiliza el usuario de ROSE que ejecuta la operacin para devolver el resultado de la operacin solicitada en el caso de que sta se haya ejecutado con xito. Es un servicio no confirmado (vase la figura 2.20).
Usuario ROSE
Proveedor ROSE
Usuario ROSE
RO-RESULT.request RO-RESULT.indication
Fig. 2.20 Primitivas del servicio RO-RESULT de ROSE
Los parmetros del servicio RO-RESULT son los siguientes: Identificador de la operacin Resultado Identificador de la invocacin Prioridad
Los parmetros de las primitivas del servicio RO-RESULT, "identificador de la operacin" e "identificador de la invocacin", son los mismos que se han estudiado en la invocacin de la operacin con el servicio RO-INVOKE. Como su nombre indica, el parmetro "resultado" contiene el resultado de una invocacin remota ejecutada con xito. Finalmente, con el parmetro "prioridad" se asigna prioridad a la transferencia de la correspondiente APDU. El servicio RO-RESULT de ROSE se mapea directamente sobre el servicio P-DATA del nivel de presentacin.
RO-ERROR El servicio RO-ERROR, que es un servicio no confirmado, lo utiliza el usuario de ROSE que ejecuta la operacin para indicar al usuario que invoca la operacin solicitada que se ha ejecutado con errores (vase la figura 2.21). Los parmetros del servicio RO-RESULT son los siguientes: Identificador del error Parmetro del error Identificador de la invocacin Prioridad
44
Usuario ROSE
Proveedor ROSE
Usuario ROSE
RO-ERROR.request RO-ERROR.indication
Fig. 2.21 Primitivas del servicio RO-ERROR de ROSE
El parmetro "identificador del error" identifica el tipo de error que se ha producido al ejecutar la operacin y en el parmetro "parmetro del error" el usuario de ROSE puede incluir informacin adicional respecto al error. Los parmetros "identificador de la invocacin" y "prioridad" son los mismos que se ha estudiado en la invocacin de la operacin mediante el servicio RO-INVOKE. El servicio RO-ERROR de ROSE se mapea directamente a nivel de presentacin mediante el servicio P-DATA.
RO-REJECT-U El servicio RO-REJECT-U lo puede utilizar un usuario de ROSE para indicar al otro usuario de ROSE que no puede ejecutar la operacin remota solicitada mediante el servicio RO-INVOKE, al detectar algn tipo de problemas (vase la figura 2.22). Tambin se puede utilizar este servicio para rechazar una respuesta (resultado o error) de una invocacin anterior.
Usuario ROSE
Proveedor ROSE
Usuario ROSE
RO-REJECT-U.request RO-REJECT-U.indication
Fig 2.22 Primitivas del servicio RO-REJECT-U de ROSE
Los parmetros de las primitivas del servicio RO-REJECT-U son los siguientes: Causa del rechazo Identificador de la invocacin Prioridad
Los parmetros "identificador de la invocacin" y "prioridad" son los mismos que se han visto en la descripcin de los otros servicios de ROSE. El parmetro "causa del error" contiene informacin
45
diferente segn sea un rechazo a una primitiva RO-INVOKE.indication, RO-RESULT.indication o RO-ERROR.indication anteriores. Las causas de rechazo de una primitiva RO-INVOKE.indication son las siguientes: invocacin duplicada, operacin desconocida, argumento errneo, recursos limitados, liberacin del iniciador de la asociacin, identificador de la operacin enlazada desconocido, respuesta de la operacin enlazada no esperada y operacin hija no esperada. En el caso de rechazo de una primitiva RO-RESULT.indication anterior, las causas de rechazo son: invocacin no desconocida, resultado no esperado y resultado errneo. Finalmente, si el rechazo corresponde a una primitiva RO-ERROR.indication, las causas de rechazo son: invocacin desconocida, error no esperado, error desconocido y parmetro errneo. El servicio RO-REJECT-U de ROSE se mapea directamente sobre el servicio P-DATA del nivel de presentacin.
RO-REJECT-P El servicio RO-REJECT-P lo utiliza el proveedor del servicio ROSE para indicar a sus usuarios que ha detectado algn tipo de problema. Es un servicio no confirmado que, al ser iniciado por el proveedor, nicamente tiene una primitiva que es RO-REJECT-P.indication (vase la figura 2.23).
Usuario ROSE
Proveedor ROSE
Usuario ROSE
RO-REJECT-P.indication
RO-REJECT-P.indication
Fig. 2.23 Primitivas del servicio RO-REJECT-P de ROSE
Los parmetros de las primitivas del servicio RO-REJECT-P son los siguientes: Causa del rechazo Identificador de la invocacin Parmetros retornados
Los parmetros de la primitiva RO-REJECT-P.indication, que son todos opcionales, son el identificador de la invocacin, la causa del rechazo y un campo de parmetros del rechazo que contiene el parmetro de la primitiva rechazada para el caso de que el proveedor de ROSE no haya podido transferir la APDU correspondiente. La causa del rechazo puede ser: APDU irreconocible, APDU errnea o estructura de la APDU errnea. El servicio RO-REJECT-P de ROSE se mapea directamente a nivel de presentacin mediante el servicio P-DATA.
46
2.6.2 Protocolo El protocolo ROSE queda definido por la mquina de protocolo de ROSE (ROPM, Remote Operations Protocol Machine). Se pueden identificar una serie de elementos de protocolo que son los siguientes: Invocacin Retorno de resultado Retorno de error Rechazo del usuario Rechazo del proveedor
El protocolo de ROSE define las siguientes APDU: ROIV RORS ROER RORJ RO-INVOKE RO-RESULT RO-ERROR RO-REJECT
A continuacin se muestra el mapeo entre las primitivas de servicio de ROSE y el servicio de presentacin, as como las APDU que se utilizan para transportar dichas primitivas. Servicio ROSE RO-INVOKE.request/indication RO-RESULT.request/indication RO-ERROR.request/indication RO-REJECT-U.request/indication RO-REJECT-P.request/indication APDU ROIV RORS ROER RORJ RORJ Servicio presentacin P-DATA.request/indication P-DATA.request/indication P-DATA.request/indication P-DATA.request/indication P-DATA.request/indication
3 Especificacin y diseo de aplicaciones distribuidas
47

En este captulo se describen herramientas para el desarrollo de aplicaciones distribuidas abiertas. En el apartado 3.1 se estudia un modelo arquitectnico y funcional mediante el cual se puede modelar una gran parte de sistemas distribuidos. Este modelo, llamado DOAM, se corresponde con la llamada arquitectura cliente/servidor. En el apartado 3.2 se describe un lenguaje estndar de especificacin formal independiente de la implementacin, llamado ASDC, mediante el cual se puede describir formalmente cualquier aplicacin distribuida. En el apartado 3.3 se muestra como realizar una implementacin OSI del sistema distribuido as especificado. Para ello, se describe una notacin llamada notacin-RO porque permite especificar las operaciones remotas que, en OSI, se implementan utilizando ROSE (vase el captulo 2). El uso de tcnicas formales estandarizadas, contribuye no tan solo a la legibilidad de los estndares, sino tambin, lo que es ms importante, facilitan enormemente la automatizacin del proceso de diseo.
3.1 DOAM (Modelo para aplicaciones distribuidas)

El modelo arquitectnico para aplicaciones distribuidas, conocido como el modelo para aplicaciones de oficina distribuida (DOAM, Distributed Office Applications Model) se describe en los estndares [DOA0191] y [DOA0291] y suministra las bases para: Especificacin del modelo cliente/servidor Modelo abstracto de aplicaciones distribuidas Utilizacin de los protocolos de comunicacin OSI Utilizacin de ASDC y ROSE Aplicaciones distribuidas mltiples
48
3.1.1 Modelo cliente/servidor En una aplicacin local el usuario y la aplicacin se encuentran en la misma mquina, y el usuario accede a la aplicacin a travs del interfaz de aplicacin (Application Interface) (Fig. 3.1).
Usuario Interfaz de aplicacin Cliente Definicin de servicio Servidor Nivel de aplicacin
Fig. 3.1 Aplicacin local
Cuando se quiere distribuir la aplicacin es necesario dividirla en dos partes que se llaman cliente (client) y servidor (server). El proceso cliente ser la parte de la aplicacin que se quedar en la misma mquina que el usuario y ser el encargado de convertir las llamadas locales del usuario en llamadas remotas al servidor. El proceso servidor, que normalmente residir en otra mquina, ser el encargado de ejecutar las operaciones solicitadas por el usuario.
Usuario Interfaz de aplicacin Cliente Definicin de servicio
Protocolo de acceso
Nivel de aplicacin
Servidor
Fig 3.2 Aplicacin distribuida: modelo cliente/servidor
El interfaz entre el cliente y el servidor es lo que se llama definicin del servicio (Service definition). El cliente y el servidor remoto utilizarn para comunicarse los servicios de los siete niveles OSI mediante lo que se llama protocolo de acceso al servicio (Access protocol). La distribucin de una
49
aplicacin debe siempre hacerse de forma transparente al usuario, es decir, el interfaz de aplicacin que utiliza el usuario debe ser el mismo que si la aplicacin fuese local (Fig. 3.2). Normalmente, el cliente es poco complejo y reside en la mquina local del usuario; en cambio, los servidores pueden llegar a tener cierta complejidad y suelen residir en mquinas ms potentes. En el caso de aplicaciones distribuidas complejas, el servidor no tiene por qu ser nico, sino que puede ser a su vez un servidor distribuido formado por una serie de servidores componentes que cooperan entre s con el objeto de proporcionar un servicio global a sus usuarios. Por tanto puede refinarse el modelo anterior para el servidor tal y como se muestra en la figura 3.3, en la que puede observarse el servidor global o sistema servidor compuesto de una serie de servidores elementales o simplemente servidores que se comunican entre s gracias al protocolo de sistema, para suministrar los servicios solicitados por el cliente, que accede al sistema servidor por medio del protocolo de acceso. Los servidores componentes no tienen que ser necesariamente iguales.
Definicin del servicio
Sistema servidor Servidor 2) 3) 1)
Cliente
Servidor 3) 2)
3)
Servidor
1) Protocolo de acceso 2) Protocolo de acceso (opcional) 3) Protocolo de sistema (si es necesario)
Fig. 3.3 Modelo DOAM para servidores distribuidos
En el caso ms general, es posible pensar en aplicaciones distribuidas en las que el cliente deba tener acceso a ms de un servidor componente y no nicamente al servidor elemental mediante el que accede normalmente al sistema servidor. En este caso, aparece la necesidad de un nuevo protocolo de acceso, normalmente opcional, que aparece en la figura 3.3 con el nmero 2. Los otros dos protocolos corresponden al protocolo de acceso del cliente al sistema servidor del que ya se ha hablado anteriormente, y al protocolo entre los servidores componentes, que se ha llamado protocolo de sistema. Supngase, por ejemplo, que el servidor mantiene una base de datos distribuida. Si existe el protocolo de acceso 2, el cliente podr acceder directamente al servidor componente que tiene la informacin que solicita. Si no dispone de ese protocolo de acceso, lo tendr que hacer indirectamente a travs del protocolo de acceso 1, y ser el servidor componente al que tiene acceso,
50
el encargado de tramitar la solicitud hasta el servidor adecuado mediante la utilizacin del protocolo del sistema.
3.1.2 Modelo de comunicacin cliente/servidor y protocolos de comunicacin OSI En este apartado se va a relacionar el modelo DOAM para aplicaciones distribuidas con los protocolos OSI, en concreto con el nivel de aplicacin. En la figura 3.4 se muestra cmo realizar la implementacin OSI de una aplicacin distribuida DOAM, en la que pueden relacionarse todos los conceptos que se han introducido en este captulo con los que se han descrito en el captulo anterior, correspondiente al nivel de aplicacin. Las dos entidades de aplicacin correspondientes al cliente y al servidor que se comunican mediante el protocolo de acceso estn compuestas por una serie de ASE comunes, como son ACSE, RTSE (opcional) y ROSE (para implementar las interacciones cliente/servidor), y los ASE especficos que en este caso son asimtricos y estn representados por los elementos de servicio del cliente (ASE del cliente) y del servidor (ASE del servidor). La parte del cliente y del servidor que no requiere una comunicacin OSI vendran representadas respectivamente por la parte del cliente y del servidor que no forman parte de las entidades de aplicacin (vase la figura 3.4).
Usuario
Cliente
Servidor
AE UE ASE cliente ROSE RTSE ACSE Protocolo de accesso
AE UE ASE serv. ROSE RTSE ACSE
Nivel de aplicacin
Nivel de presentacin e inferiores
Fig. 3.4 Modelo DOAM y realizacin OSI
51
El modelo DOAM de la figura 3.4 se puede generalizar para el caso de servidores distribuidos (Fig. 3.5). En la figura 3.5 se ilustra la realizacin OSI para ese tipo de sistemas distribuidos, en la que se pueden identificar dos tipos de servidores elementales, aqullos que nicamente se comunican con otro servidor elemental, y aqullos que adems tambin deben establecer comunicacin con un cliente. En el caso del primer tipo de servidores elementales, slo necesitan una entidad de aplicacin (EA 2) con sus ASE comunes y especficos; normalmente sta ser una comunicacin simtrica mediante el protocolo que hemos llamado protocolo de sistema. El segundo tipo de servidor elemental requiere la utilizacin de dos contextos de aplicacin, que se pueden implementar mediante una o dos entidades de aplicacin. En el caso de la figura 3.5 se ha optado por utilizar dos entidades de aplicacin (EA 1 y EA 2). Una EA se utiliza para la comunicacin con otro servidor elemental (EA 2) mediante el protocolo de sistema y la otra EA (EA 1) sirve para la comunicacin con el cliente mediante el protocolo de acceso. Recordemos que sta ltima es una relacin asimtrica.
Usuario
Cliente
Servidor
Servidor
Nivel de aplicacin
Entidad de Entidad de aplicacin Protocolo de aplicacin 1) 1) acceso ASE (1) ASE (1)
Entidad de aplicacin Protocolo de 2) sistema ASE (2)
Entidad de aplicacin 2) ASE (2)
Nivel de presentacin y niveles inferiores
Fig. 3.5 Modelo DOAM y realizacin OSI para servidores distribuidos
Uno de los objetos ms importantes en aplicaciones distribuidas en un entorno de oficina es el documento. ISO ha estandarizado una serie de operaciones sobre documentos, concretamente aquellas ms comunes, con la finalidad de que los diseadores de este tipo de aplicaciones dispongan de su especificacin y la puedan utilizar en sus diseos, lo cual no significa que stos puedan definir sus propias operaciones. En el estndar se define, para cada operacin, los parmetros que utiliza y los resultados que se obtienen. A continuacin se listan dichas operaciones normalizadas junto con una breve descripcin de cada una de ellas.
52
Operacin
Listar (List) Leer (Read) Escribir (Write) Modificar (Modify) Copiar (Copy) Mover (Move) Buscar (Search) Crear (Create) Borrar (Delete) Reservar (Reserve) Notificar (Notify) Abandonar (Abandon)
Descripcin
Listar los componentes de un objeto Leer determinados atributos de un objeto Escribir determinados atributos de un objeto Cambiar los atributos de un objeto Copiar un objeto Mover un objeto Identificar objetos con caractersticas especficas Crear un objeto Borrar un objeto Bloquear un objeto para uso posterior Informar sobre cambios en un objeto Abandonar la operacin en curso
3.1.3 Aplicaciones distribuidas mltiples El modelo DOAM tambin contempla la posibilidad de disear aplicaciones distribuidas donde un usuario pueda acceder a ms de un servicio remoto (o servidor). En este caso se define un sistema tipo cliente/servidor para cada servicio remoto segn el modelo DOAM. La adaptacin del modelo general DOAM para el caso de aplicaciones distribuidas mltiples se ilustra en la figura 3.6, donde para cada servicio se define un interfaz de aplicacin (interfaz de aplicacin A, interfaz de aplicacin B,..), un cliente (cliente A, cliente B,..), un protocolo de acceso al servicio (protocolo de acceso A, protocolo de acceso B,..) y un servidor (servidor A, servidor B,...). En este caso el proceso de aplicacin de usuario consta de todos los clientes ms un elemento de usuario que se encargar, por una parte, de interaccionar con el usuario y por otra de gestionar todas los interfaces de aplicacin (interfaz de aplicacin A, interfaz de aplicacin B,..).
Usuario Interfaz de aplicacin A Cliente A Cliente B Interfaz de aplicacin B
Protocolo de acceso A Servidor A
Protocolo de acceso B Servidor B
Fig. 3.6 Modelo DOAM para aplicaciones distribuidas mltiple
53
3.2 Especificacin y diseo de sistemas distribuidos: ASDC

Se han estandarizado unas reglas o convenciones para la definicin de servicios abstractos conocidas como ASDC (Abstract Service Definition Conventions). El lenguaje de especificacin ASDC sirve para especificar formalmente sistemas distribuidos, estandarizados o no, que se pueden utilizar o no en un entorno OSI. El que sea una especificacin abstracta significa que es independiente de la implementacin y, al ser formal, es posible utilizar herramientas automticas o semiautomticas que, a partir de la especificacin, nos permitan llegar hasta la implementacin. En el estndar [ASD0190] se define el lenguaje formal de especificacin ASDC que forma parte de los estndares de la mensajera electrnica. En el lenguaje ASN.1 se pueden utilizar las macros para definir un nuevo lenguaje de especificacin. La notacin ASDC est basada en la utilizacin de macros de ASN.1 La especificacin de un sistema distribuido utilizando ASDC consta de dos puntos de vista: Visin macroscpica o modelo abstracto: donde se define la arquitectura del sistema, y se muestran los mdulos que lo componen, el entorno que definen y cmo se relacionan entre s. Visin microscpica o servicio abstracto: donde se define la funcionalidad del sistema, as como el nuevo servicio que proporciona.
3.2.1 Visin macroscpica En el modelo abstracto, o visin macroscpica, se define el sistema como un conjunto de mdulos llamados objetos abstractos (Abstract Objects) los cuales cooperan a travs de canales de comunicacin llamados puertos abstractos (Abstract Ports).
nombre-objeto OBJECT { PORTS { nombre-puerto-1 nombre-puerto-2 nombre-puerto-3 ............}} ::= identificador-objeto-abstracto
[S], [C],
-- puerto asimtrico papel suministrador -- puerto asimtrico papel consumidor -- puerto simtrico -- es un Object Identifier o un identificador local
Fig. 3.7 Definicin de un objeto abstracto mediante la macro OBJECT de ASDC
Un objeto abstracto es un ente que posee una funcionalidad propia y que se comunica con otros objetos por medio de uno o varios puertos abstractos. Para la especificacin de un objeto abstracto en ASDC se utiliza una macro de ASN.1 llamada OBJECT, a travs de la que se le adjudica un identificador y se le asocia una lista de puertos abstractos para su acceso. El identificador no es ms
54
que un tipo de dato Object Identifier de ASN.1 mediante el cual se le adjudica un identificador nico en el entorno OSI. Para cada puerto abstracto asimtrico se debe indicar el papel, que puede ser consumidor ([C]) o suministrador ([S]). En la figura 3.7 se muestra la sintaxis del uso de la macro OBJECT de ASDC para definir un objeto abstracto. Un objeto abstracto se puede refinar mediante la utilizacin de la macro REFINE de ASN.1. En este refinamiento, llamado refinamiento abstracto, aparecen los objetos abstractos que lo componen y mediante la palabra reservada RECURRING se indica si puede existir ms de un objeto abstracto de este tipo (por defecto el objeto es nico). Tambin se enumeran los puertos abstractos asociados a cada objeto componente, el tipo del puerto y, en el caso de puerto asimtrico, el papel ([C] o [S]). Para cada objeto abstracto componente, y para cada puerto abstracto al que est unido, se indica la lista de objetos abstractos relacionados con l mediante dicho puerto (PAIRED WITH). Adems, si se quiere que un puerto abstracto sea visible desde el exterior del objeto que se est refinando, se indica con la palabra reservada VISIBLE. Es decir, ste sera el caso de puertos abstractos que estn en la frontera de dos sistemas. En la figura 3.8 se muestra la sintaxis del uso de la macro REFINE de ASDC para refinar un objeto abstracto en sus objetos componentes.
nombre-del-refinamiento REFINE objeto-a-refinar AS nombre-objeto-1 -- objeto abstracto nico nombre-objeto-2 RECURRING -- objeto abstracto mltiple nombre-objeto-3 puerto-abstracto papel PAIRED WITH {lista-objetos-abstractos} nombre-objeto-4 puerto-abstracto papel VISIBLE -- puerto visible desde el exterior ........................ ::= identificador-refinamiento-abstracto Fig. 3.8 Refinamiento de un objeto abstracto mediante la macro REFINE de ASDC
3.2.2 Visin microscpica En la especificacin del servicio abstracto, o visin microscpica, se definen dos aspectos: El conjunto de funcionalidades o servicios que ofrece un objeto a otro objeto a travs de uno o varios puertos abstractos. Estos servicios reciben el nombre de operaciones abstractas (Abstract Operations) y se deben definir mediante la utilizacin de la macro ABSTRACTOPERATION de ASN.1. Los puertos abstractos a travs de los cuales se puede acceder a las operaciones abstractas. Para cada puerto se indica su tipo (simtrico o asimtrico) y la lista de operaciones que se pueden utilizar a travs de cada puerto y quin las debe invocar.
55
Un puerto abstracto puede ser de dos formas distintas: Asimtrico: cada instanciacin del puerto es diferente y puede ser de dos tipos, consumidor o suministrador. El tipo de papel se indica mediante las palabras reservadas CONSUMER (consumidor o cliente) y SUPPLIER (suministrador o servidor). Simtrico: todas las instanciaciones del puerto son idnticas, tienen el mismo papel, y pueden actuar indistintamente como consumidor o suministrador.
Objeto entorno Objeto cliente Puerto asimtrico Objeto servidor ... Objeto cliente Operacin Objeto servidor
Puerto simtrico
Fig. 3.9 Representacin grfica de objetos y puertos (simtricos y asimtricos) abstractos
Un puerto abstracto se especifica mediante la macro PORT de ASN.1, por medio de la que se le dota de un identificador (que es un Object Identifier de ASN.1) y se enumera las operaciones abstractas que se pueden utilizar y quin las invoca. Si el puerto es simtrico se indica mediante la palabra reservada ABSTRACT OPERATIONS y se enumeran las operaciones abstractas que se pueden utilizar en ese puerto, que pueden ser invocadas indistintamente por los dos extremos (vase la figura 3.10).
nombre-puerto PORT ABSTRACT OPERATIONS {lista-operaciones} ::= identificador-puerto --puerto abstracto simtrico --operaciones abstractas definidas
Fig. 3.10 Definicin de un puerto abstracto simtrico mediante la macro PORT de ASDC
Si el puerto es asimtrico se deben enumerar qu operaciones deben ser invocadas por el consumidor (CONSUMER INVOKES) y por el suministrador (SUPPLIER INVOKES) (vase la figura 3.11).
56
nombre-puerto PORT CONSUMER INVOKES {lista-operaciones} SUPPLIER INVOKES {lista-operaciones} ::= identificador-puerto
--puerto abstracto asimtrico --operaciones invocadas por consumidor --operaciones invocadas por suministrador
Fig. 3.11 Definicin de un puerto abstracto asimtrico mediante la macro PORT de ASDC
Cada una de las operaciones abstractas se debe definir mediante la utilizacin de la macro ABSTRACT-OPERATION de ASN.1. Para cada procedimiento u operacin abstracta se pueden indicar los argumentos (ARGUMENT), los resultados (RESULT) y los posibles errores (ERRORS) (vase la figura 3.12).
nombre-operacin ABSTRACT-OPERATION ARGUMENT TipoArgumento RESULT TipoResultado ERRORS {lista-errores} } {
Fig. 3.12 Definicin de una operacin abstracta mediante la macro ABSTRACT-OPERATION de ASDC
El enlace de dos puertos abstractos se llama unin abstracta (Abstract Bind). Dos objetos no se pueden comunicar si previamente no se han unido sus puertos abstractos. Dicha unin debe seguir las siguientes reglas: Dos puertos se pueden unir siempre y cuando sean simtricos. Si dos puertos son asimtricos, slo se pueden unir si tienen distinto papel, es decir, uno es consumidor y el otro suministrador.
La unin abstracta se debe especificar mediante la utilizacin de la macro ABSTRACT-BIND de ASN.1, en la que se debe indicar a qu puerto abstracto hace referencia dicha unin, y podemos asociar argumentos (ARGUMENT), resultados (RESULT) y/o errores (BIND-ERROR) (vase la figura 3.13).
nombre-bind ::= ABSTRACT-BIND TO {lista-puertos} BIND ARGUMENT TipoArgumento RESULT TipoResultado BIND-ERROR TipoErrorBind Fig. 3.13 Definicin de una unin abstracta mediante la macro ABSTRACT-BIND de ASDC
57
La ruptura del enlace de dos puertos abstractos se llama liberacin de una unin abstracta (Abstract Unbind) y se realiza mediante la utilizacin de la macro ABSTRACT-UNBIND de ASN.1. Como en el caso de la unin abstracta, es necesario indicar a qu puertos abstractos hace referencia la liberacin de la unin abstracta que estamos definiendo, as como los argumentos (ARGUMENT), resultados (RESULT) o errores (UNBIND-ERROR), si es que existen (vase la figura 3.14).
nombre-unbind ::= ABSTRACT-UNBIND FROM {lista-puertos} UNBIND ARGUMENT TipoArgumento RESULT TipoResultado UNBIND-ERROR TipoErrorUnbind Fig. 3.14 Definicin de la liberacin de una unin abstracta mediante la macro ABSTRACT-UNBIND de ASDC
Cada error abstracto (Abstract Error) que aparece en la especificacin, es necesario definirlo mediante la macro ABSTRACT-ERROR de ASN.1, donde es posible asociar parmetros a cada error de forma opcional (vase la figura 3.15).
nombre-error ::= PARAMETER ABSTRACT-ERROR TipoParametro
Fig. 3.15 Definicin de un error abstracto mediante la macro ABSTRACT-ERROR de ASDC
Finalmente, es necesario indicar que las macros de ASN.1, que se han utilizado para la especificacin ASDC, de operaciones (ABSTRACT-OPERATION), errores (ABSTRACT-ERROR), uniones (ABSTRACT-BIND) y liberaciones de uniones (ABSTRACT-UNBIND) abstractas son las mismas que las utilizadas en la notacin-RO de ROSE para su implementacin OSI, es decir, se definen (vase apartado 3.3):
ABSTRACT-OPERATION ABSTRACT-ERROR ABSTRACT-BIND ABSTRACT-UNBIND MACRO MACRO MACRO MACRO ::= ::= ::= ::= OPERATION ERROR BIND UNBIND
3.3 Notacin-RO (Remote Operations Notation)

La notacin-RO es un lenguaje de especificacin de aplicaciones distribuidas que utilizan ROSE para implementar las operaciones remotas. Este lenguaje deriva de ASN.1 y se ha generado a partir de la
58
utilizacin de una serie de macros. A partir de la especificacin de un servicio distribuido en notacin-RO se pueden utilizar herramientas automticas o semiautomticas mediante las cuales es posible llegar hasta la implementacin. As se obtienen dos programas ejecutables correspondientes al que invoca (Invoker o cliente) la operacin remota y al que la ejecuta (Performer o servidor). A continuacin nicamente es necesario ejecutar dichos programas en dos mquinas con servicios OSI completos (vase la figura 3.16).
Cliente
CompiladorEnlazador
Ejecutable cliente
Notacin RO
Compilador Notacin-RO
CompiladorEnlazador
Ejecutable servidor
Servidor
Fig. 3.16 Entorno de desarrollo de aplicaciones distribuidas OSI especificadas en notacin-RO
Para especificar una aplicacin basada en operaciones remotas se han normalizado cuatro macros de ASN.1, que son las siguientes: OPERATION: Para especificar una operacin remota con argumentos, resultados y/o errores. ERROR: Para especificar cada uno de los errores que aparecen en las operaciones remotas. BIND: Para establecer una asociacin de aplicacin previamente a las llamadas remotas. UNBIND: Para liberar una asociacin previamente establecida. Con estas cuatro macros se puede definir en qu consiste el nuevo servicio distribuido que se quiere disear, pero es necesario tambin indicar cmo identificarlo en el entorno OSI. Para esto se han creado dos macros de ASN.1 adicionales que sirven para especificar los elementos de servicio de aplicacin (ASE) especficos necesarios para implementar dicho servicio (macro APPLICATIONSERVICE-ELEMENT), y con la segunda macro, llamada APPLICATION-CONTEXT, se especifica el contexto de aplicacin asociado a dicho nuevo servicio. Las macros normalizadas de ASN.1 para definir ASE especficos y contextos de aplicacin son las siguientes:
59
APPLICATION-SERVICE-ELEMENT: Para cada ASE especfico del contexto de aplicacin APPLICATION-CONTEXT: Para cada contexto de aplicacin
3.3.1 Operaciones remotas Para especificar una operacin remota es necesario utilizar la macro de ASN.1 OPERATION, mediante la cual se dota a la operacin de un identificador que el usuario de ROSE de la entidad invocadora de la operacin utiliza como identificador de operacin cuando quiera que la entidad remota ejecute la operacin. Este identificador puede tener un mbito de validez local o global. En este ltimo caso es necesario que sea del tipo OBJECT IDENTIFIER de ASN.1. Mediante la palabra clave ARGUMENT se pueden especificar los tipos de datos correspondientes a los argumentos de la operacin remota. Si la operacin se ha ejecutado con xito y devuelve resultados, stos se especifican con la palabra clave RESULT. Es posible que la operacin se ejecute incorrectamente; en cuyo caso los posibles errores generados se especifican con la palabra clave ERRORS. Finalmente, si la operacin especificada es la operacin padre de una serie de operaciones enlazadas, es necesario utilizar la palabra clave LINKED para listar las operaciones hijas (vase la figura 3.17).
nombre-operacin OPERATION ARGUMENT TipoArgumento RESULT TipoResultado ERRORS {lista-errores} LINKED {lista-operaciones-hijas} ::= identificador-operacin Fig.3.17 Definicin de una operacin mediante la macro OPERATION de la notacin-RO
3.3.2 Errores Todos los errores que aparezcan en las macros OPERATION de las operaciones remotas se deben especificar con la utilizacin de la macro ERROR, que permite asociar a cada error un identificador y, opcionalmente, con la palabra clave PARAMETER, una serie de parmetros. Si el error tiene una validez local, es suficiente que el identificador asociado sea un entero, pero si debe tener una validez global es necesario que sea un OBJECT IDENTIFIER de ASN.1 (vase la figura 3.18).
nombre-error ERROR PARAMETER TipoParametro ::= identificador-error Fig. 3.18 Definicin de un error mediante la macro ERROR de la notacin-RO
60
El valor de un tipo de dato correspondiente a un error no es ms que el identificador que utilizar el usuario de ROSE de una entidad de aplicacin para informar al usuario de ROSE homnimo de una situacin excepcional que se ha producido al intentar ejecutar una operacin remota que ste le ha solicitado con anterioridad.
3.3.3 Operacin de establecer una unin (Bind) Para poder invocar una operacin remota es necesario establecer previamente una asociacin de aplicacin. Esta operacin se llama establecer una unin o bind y se especifica con la macro BIND. Con esta macro es posible asociar a la operacin de establecer una unin un identificador y asociarle argumentos, resultados y errores. Con la palabra reservada ARGUMENT se pueden definir argumentos de entrada asociados con una operacin de establecer una unin. Si el establecimiento de la unin se ha resuelto con xito, la palabra clave RESULT especifica el tipo del resultado y, en caso contrario, los errores asociados se pueden especificar mediante la palabra reservada BIND-ERROR. Estos tres ltimos campos son opcionales (vase la figura 3.19).
nombre-establecer-unin BIND ARGUMENT TipoArgumento RESULT TipoResultado BIND-ERROR TipoErrorBind ::= identificador-establecer-unin Fig. 3.19 Establecer una unin mediante la macro BIND de la notacin-RO
3.3.4 Operacin de liberacin de la unin (Unbind) La operacin de liberar una unin (o unbind) destruye la asociacin de aplicacin que se ha utilizado para una operacin remota. La liberacin de la unin se especifica mediante la macro UNBIND que tiene una sintaxis muy parecida a la macro BIND del apartado anterior. La nica diferencia en cuanto a sintaxis es que la palabra reservada para indicar los errores es en este caso UNBINDERROR (vase la figura 3.20).
nombre-liberar-unin UNBIND ARGUMENT TipoArgumento RESULT TipoResultado UNBIND-ERROR TipoErrorUnbind ::= identificador-liberar-unin Fig 3.20 Liberar una unin mediante la macro UNBIND de la notacin-RO
61
3.3.5 Elementos de servicio de aplicacin (ASE) especficos Con la macro APPLICATION-SERVICE-ELEMENT se especifican los ASE especficos dotndolos de un identificador nico y se definen sus caractersticas particulares. Debe recordarse que el protocolo definido entre dos ASE especficos puede ser simtrico o asimtrico. En el caso de ASE simtricos los dos usuarios indistintamente pueden invocar todas las operaciones remotas. En el caso asimtrico es necesario indicar para cada operacin quin la invoca, es decir, si es el consumidor o el proveedor de la operacin remota. Para cada ASE especfico asimtrico, y mediante la macro APPLICATION-SERVICE-ELEMENT, se indica la lista de operaciones que puede invocar nicamente el consumidor de la operacin remota (CONSUMER INVOKES) y las que slo puede invocar el proveedor de la operacin (SUPPLIER INVOKES). En el caso de ASE simtricos las operaciones las pueden invocar indistintamente los dos extremos y se utiliza la palabra reservada OPERATIONS para indicar la lista (vase la figura 3.21).
nombre-ase APPLICATION-SERVICE-ELEMENT OPERATIONS {lista-operaciones} -- operaciones ase simtrico CONSUMER INVOKES {lista-operaciones} --operaciones ase asimtrico SUPPLIER INVOKES {lista-operaciones} -- operaciones ase asimtrico ::= identificador-ase Fig. 3.21 Definicin de un ASE mediante la macro APPLICATION-SERVICE-ELEMENT de la notacin-RO
3.3.6 Contexto de aplicacin Un contexto de aplicacin (AC) queda definido por las operaciones de establecimiento de una unin (bind), liberacin de dicha unin (unbind) y el conjunto de ASE (comunes y especficos) que lo componen, utilizando cada uno de estos ASE sintaxis abstractas distintas. Con la macro APPLICATION-CONTEXT se identifica de forma nica un contexto de aplicacin concreto y se definen sus caractersticas. La composicin del contexto de aplicacin asociado al servicio que se est especificando, consta de la lista de ASE que lo constituyen (APPLICATIONSERVICE-ELEMENT), cmo establecer la unin asociada al servicio (BIND), cmo liberarla (UNBIND), el ASE utilizado para implementar las operaciones remotas, que normalmente ser ROSE (REMOTE OPERATIONS), y las sintaxis abstractas utilizadas para cada uno de los ASE constitutivos del contexto de aplicacin (ABSTRACT SYNTAXES). Los ASE simtricos de los que consta el contexto de aplicacin se deben listar utilizando la palabra clave OPERATIONS OF. Para los ASE asimtricos es necesario listar por separado aqullos para los que la entidad iniciadora de la asociacin es la consumidora de dichos ASE (INITIATOR CONSUMER OF) y aqullos para los que
62
la entidad que responde a la iniciacin de la asociacin es su consumidora (RESPONDER CONSUMER OF) (vase la figura 3.22).
nombre-ac APPLICATION-CONTEXT APPLICATION-SERVICE-ELEMENT BIND UNBIND REMOTE OPERATIONS OPERATIONS OF INITIATOR CONSUMER OF RESPONDER CONSUMER OF ABSTRACT SYNTAXES ::= identificador-ac
{lista-ases} TipoBind TipoUnbind {lista-identificadores-ases(ROSE)} {lista-ases} {lista-ases} {lista-ases} {lista-as}
Fig. 3.22 Definicin de un contexto de aplicacin mediante la macro APPLICATION-CONTEXT de la notacin-RO
3.4 Ejemplo: minimensajera electrnica

En este ejemplo se propone disear un nuevo servicio (o aplicacin) distribuido OSI utilizando la notacin ASDC para su especificacin y la notacin-RO para su posterior implementacin con ROSE.
Usuario
...
Usuario
Sistema de mensajera
Administrador
...
Administrador
Fig 3.23 Arquitectura general del miniservicio de mensajera
Se pretende especificar en ASDC una aplicacin que modela un miniservicio de mensajera electrnica (la aplicacin que se va a especificar no pretende ser un modelo real o estndar, sino que debe tomarse como un simple ejemplo). Con este nuevo servicio, los usuarios de dicha aplicacin disponen de la posibilidad de enviar y leer mensajes de otros usuarios del servicio de mensajera.
63
Tambin existen unos usuarios especiales, que son los administradores del sistema que, adems de poseer las funcionalidades de un usuario normal, tambin pueden realizar operaciones de gestin (vase la figura 3.23). Del nuevo servicio de mensajera que se va a disear, slo interesa aquella parte relacionada con la distribucin, esto es, el proceso de la aplicacin distribuida que utiliza los servicios OSI para intercambiar informacin con otros sistemas. Cada sistema (ordenador) involucrado en la realizacin del servicio de mensajera debe poseer una torre de comunicaciones OSI completa (los siete niveles). Las entidades de aplicacin necesarias para implementar dicho servicio deben contener los ASE comunes, esto es, ACSE y ROSE (y opcionalmente RTSE), ms los ASE especficos necesarios para implementar el nuevo servicio. La arquitectura de comunicaciones OSI puede estar presente en el kernel del sistema operativo o como un proceso de usuario. A continuacin, en la figura 3.24, se muestra la estructura de la entidad de aplicacin del servicio de mensajera electrnica del ejemplo.
Proceso Aplicacin Usuario AE UE ASE ... ROSE ACSE ASE
Fig. 3.24 Entidad de aplicacin del servicio de mensajera electrnica
3.4.1 Especificacin ASDC Se puede realizar una representacin grfica de la arquitectura del servicio de mensajera electrnica donde aparecen todos los objetos abstractos que lo componen y los puertos abstractos que los relacionan ente s. En realidad se trata de una representacin grfica de la visin macroscpica del servicio, que nos da la misma informacin que la especificacin formal segn la notacin ASDC. El entorno de mensajera electrnica tendr un aspecto como el mostrado en la figura 3.25 en trminos de objetos y puertos abstractos ASDC.
64
Usuariomensajera
enva recibe
usomensajera
Administradormensajera
enva recibe prueba registra adminmensajera
Entornomensajera Sistema-mensajera
Fig. 3.25 Representacin grfica del entorno del servicio de mensajera electrnica
El servicio consta de cuatro tipos de objetos abstractos distintos llamados: sistema-mensajera usuario-mensajera administrador-mensajera entorno-mensajera
Estos objetos abstractos se comunican entre s mediante puertos abstractos. Existen dos puertos abstractos distintos llamados uso-mensajera y admin-mensajera. El puerto uso-mensajera lo utiliza un usuario para invocar las operaciones normales de utilizacin del sistema, y relaciona los objetos usuario-mensajera y admin-mensajera con el objeto sistema-mensajera. El puerto abstracto uso-mensajera es asimtrico y tiene los papeles de cliente en los extremos correspondientes a los objetos usuario-mensajera y administrador-mensajera, y el papel de servidor en el extremo del objeto sistema-mensajera. El puerto abstracto admin-mensajera lo utiliza el usuario administrador del sistema para realizar las operaciones propias de gestin, y por lo tanto relaciona slo el objeto administrador-mensajera con el objeto sistema-mensajera. Tambin es un puerto asimtrico y tiene el papel de cliente en el extremo correspondiente al objeto administrador-mensajera y el papel de servidor en el extremo del objeto sistema-mensajera. Las operaciones que se pueden utilizar en el puerto abstracto uso-mensajera son enviar un mensaje (Enva) y leer un mensaje (Recibe). Estas operaciones las invoca siempre el usuario del servicio (usuario-mensajera o administrador-mensajera). Para gestin, en el puerto abstracto admin-mensajera, se han definido las operaciones de registrar un nuevo usuario del servicio (Registrar) y enviar un mensaje de prueba (Prueba). Estas operaciones las invoca siempre el usuario administrador.
65
A partir de la descripcin grfica se puede especificar la aplicacin de mensajera electrnica utilizando la notacin formal ASDC. El diseo se realiza mediante la definicin de dos mdulos: Especificacin en ASDC del entorno abstracto, o visin macroscpica Especificacin en ASDC del servicio abstracto, o visin microscpica
3.4.1.1 Visin macroscpica

EntornoMensajeria DEFINITIONS ::= BEGIN -- Entorno de mensajera entorno-mensajeria OBJECT ::= id-ot-mensajeria-entorno -- Refinamiento del entorno de mensajera entorno-mensajeria-refinamiento REFINE entorno-mensajeria AS usuario-mensajeria RECURRING administrador-mensajeria RECURRING sistema-mensajeria uso-mensajeria [ S ] PAIRED WITH { usuario-mensajeria, administrador-mensajeria } admin-mensajeria [ S ] PAIRED WITH { administrador-mensajeria } ::= id-ref-mensajeria-entorno -- Objetos abstractos de la definicin sistema-mensajeria OBJECT PORTS { uso-mensajeria [S], admin-mensajeria [ S ] } ::= id-ot-mensajeria-sistema usuario-mensajeria OBJECT PORTS { uso-mensajeria [ C ] } ::= id-ot-mensajeria-usuario administrador-mensajeria OBJECT PORTS { uso-mensajeria [C] admin-mensajeria [ C ] }
66 ::= id-ot-mensajeria-admin END
3.4.1.2 Visin microscpica

ServicioMensajeria DEFINITIONS ::= BEGIN -- Puertos abstractos uso-mensajeria PORT CONSUMER INVOKES { Enva, Recibe } ::= id-pt-mensajeria-uso admin-mensajeria PORT CONSUMER INVOKES { Registra, Prueba } ::= id-pt-mensajeria-admin -- Bind abstracto BindUsoMensajeria ::= ABSTRACT-BIND TO { uso-mensajeria } BIND ARGUMENT Credenciales BIND-ERROR {NoAutorizado} BindAdminMensajeria ::= ABSTRACT-BIND TO { admin-mensajeria, uso-mensajeria } BIND ARGUMENT Credenciales BIND-ERROR { NoAutorizado } Credenciales ::= SET { nombre [ 0 ] IA5String, password [ 1 ] IA5String } -- Unbind abstracto UnbindMensajeria ::= ABSTRACT-UNBIND
67
FROM { uso-mensajeria, admin-mensajeria } -- Operaciones abstractas Enva ::= ABSTRACT-OPERATION ARGUMENT ...... RESULT ...... ERROR ...... -- Resto de operaciones abstractas: Recibe, Registra y Prueba -- Errores abstractos NoAutorizado ::= ABSTRACT-ERROR PARAMETER ...... -- Resto de errores abstractos END
3.4.2 Realizacin con ROSE: Notacin-RO El servicio de mensajera electrnica que se ha especificado en los apartados anteriores mediante la notacin ASDC, se va a implementar utilizando ROSE. Para su diseo es necesario utilizar la notacin-RO. A continuacin se muestra cmo sera la especificacin del servicio utilizando la notacin-RO. Se puede observar que se implementa con dos contextos de aplicacin llamados usomensajera-AC y admin-mensajera-AC, donde cada uno de ellos consta de uno o varios ASE especficos. El contexto de aplicacin uso-mensajera-AC lo utilizan los usuarios normales de mensajera y contiene el ASE especfico uso-mensajera-ASE que utiliza la sintaxis abstracta usomensajera-AS. El otro contexto de aplicacin, que es admin-mensajera-AC, y es utilizado por los administradores de la mensajera y contiene los ASE especficos admin-mensajera-ASE y uso-mensajera-ASE. Los usuarios administradores utilizan el ASE admin-mensajera-ASE para las operaciones de gestin (utilizando la sintaxis abstracta admin-mensajera-AS), y el ASE usomensajera para las operaciones normales (utilizando la sintaxis abstracta admin-mensajera-AC).
RealizacionMensajeria DEFINITIONS ::= BEGIN -- Contextos de aplicacin uso-mensajeria-AC APPLICATION-CONTEXT -- para el usuario mensajera APPLICATION SERVICE ELEMENTS {aCSE}
68 BIND BindUsoMensajeria UNBIND UnbindMensajeria REMOTE OPERATIONS INITIATOR CONSUMER OF ABSTRACT SYNTAXES ::= id-ac-mensajeria-uso
{rOSE} {uso-mensajeria-ASE} {uso-mensajeria-AS, aCSE-AS}
admin-mensajeria-AC APPLICATION-CONTEXT -- para el administrador APPLICATION SERVICE ELEMENTS {aCSE} BIND BindAdminMensajeria UNBIND UnbindMensajeria REMOTE OPERATIONS {rOSE} INITIATOR CONSUMER OF {admin-mensajeria-ASE, uso-mensajeria-ASE} ABSTRACT SYNTAXES {admin-mensajeria-AS, aCSE-AS, uso-mensajeria-AS} ::= id-ac-mensajeria-admin -- Elementos de servicio de aplicacin uso-mensajeria-ASE APPLICATION-SERVICE-ELEMENT CONSUMER-INVOKES { enva, recibe } ::= id-ase-mensajeria-uso admin-mensajeria-ASE APPLICATION-SERVICE-ELEMENT CONSUMER-INVOKES { registra, prueba } ::= id-ase-mensajeria-admin -- Sintaxis abstractas uso-mensajeria-AS OBJECT IDENTIFIER ::= id-as-mensajeria-uso admin-mensajeria-AS OBJECT IDENTIFIER ::= id-as-mensajeria-admin --Operaciones enva Enva ::= 1
--Resto de operaciones: recibe, registra y prueba --Errores END
69
De la definicin de un puerto se desprenden los servicios que puede suministrar dicho puerto. Dichos servicios al final sern realizados por un ASE especfico, que define una sintaxis abstracta y pertenece a un contexto de aplicacin determinado en el nivel de aplicacin. En nuestro ejemplo, el sistema entorno de mensajera se implementa con dos puertos, por lo tanto con dos ASE especficos distintos que, combinados, dan lugar a dos contextos de aplicacin que se muestran en la figura 3.26. Los servicios (operaciones) disponibles en cada contexto son los siguientes: uso-mensajeria-AC: enva y recibe admin-mensajeria-AC: enva, recibe, registra y prueba
Usuario administrador de sistema-mensajera
Sistema-mensajera
UE usomensajera ROSE ACSE ACSE adminmensajera Protocolo entre administradores y sistema-mensajera
UE usomensajera adminmensajera
Nivel de aplicacin
ROSE
Usuario de sistema-mensajera
Sistema-mensajera
UE usomensajera ROSE ACSE ACSE Protocolo entre usuarios y sistema-mensajera
UE usomensajera ROSE
Nivel de aplicacin
Fig. 3.26 Contextos de aplicacin del sistema entorno de mensajera
70
3.4.3 Refinamiento del sistema de mensajera En una aplicacin de mensajera electrnica, se distinguen bsicamente dos componentes distintos. Por una parte se tiene el acceso al servicio de mensajera, que incluye los usuarios y administradores de la mensajera antes mencionados, y que se encargan de manipular los mensajes. Y el otro componente es el sistema de transferencia de mensajes, encargado de transferir los mensajes de un usuario a otro. Dentro del entorno de mensajera, se vio que tenamos varias clases de objetos, y entre ellos el sistema-mensajera. Como objeto abstracto, puede refinarse para definir con ms detalle cul es su composicin. Como se puede observar en la figura 3.27, se trata de la misma arquitectura (visin macroscpica) que la definida anteriormente, donde aparecen nuevos objetos llamados agentes. Un agente es, en nuestro caso, una entidad que acta como intermediaria entre el sistema de transferencia y los usuarios (normales o privilegiados) de la mensajera. En cualquier caso, es el proveedor de un puerto de mensajera (uso-mensajera o admin-mensajera) y el consumidor de un puerto del sistema de transferencia (uso-transferencia o admin-transferencia). Tambin puede verse al agente como un valor aadido, en cuanto a la funcionalidad al entorno de transferencia, que hace visible dicho entorno a los usuarios de la mensajera.
agenteusuario
entrega
agenteadministrador
transfiereprueba admintransferencia
sistemamensajera
transfiere usotransferencia
sistema-transferencia
Fig. 3.27 Refinamiento del sistema de mensajera
El entorno de mensajera refinado constar, por tanto, de los objetos definidos en el entorno de mensajera original ms los nuevos objetos que se obtienen del refinamiento del sistema de mensajera. En la figura 3.28 se puede ver la representacin grfica del entorno de mensajera en la que aparece el refinamiento del sistema de mensajera descrito anteriormente.
71
usuariomensajera
usomensajera
administradormensajera
entornomensajeria
sistemamensajera
adminmensajera agenteusuario usomensajera agenteusuario agenteadministrador sistema-transferencia adminmensajera
Fig. 3.28 Refinamiento del entorno de mensajera
La definicin ASDC del refinamiento del sistema-mensajera sera el siguiente:

RefinamientoSistemaMensajeria DEFINITIONS ::= BEGIN -- refinamiento sistema-mensajera sistema-mensajeria-refinamiento REFINE sistema-mensajeria AS agente-usuario RECURRING uso-mensajeria [S] VISIBLE uso-transferencia [C] PAIRED WITH {sistema-transferencia} agente-administrador RECURRING admin-mensajeria [S] VISIBLE admin-transferencia [C] PAIRED WITH {sistema-transferencia} sistema-transferencia ::= id-ref-mensajeria-sistema -- nuevos objetos abstractos agente-usuario OBJECT PORTS { uso-mensajeria [S] , uso-transferencia [C] } ::= id-ot-agente-usuario agente-administrador OBJECT PORTS {
72 admin-mensajeria [S] , admin-transferencia [C] } ::= id-ot-agente-administrador sistema-transferencia OBJECT PORTS { uso-transferencia [S] , admin-transferencia [S] } ::= id-ot-sistema-transferencia END
3.5 Nueva notacin para la especificacin de servicios y protocolos OSI

En la ltima versin del estndar "ITU-T Recommendation X.880 | ISO/IEC 13712-1 Remote Operations - Concepts, Model and Notation" se describe un nuevo lenguaje de especificacin para la definicin de servicios abstractos y su implementacin basada en la utilizacin del protocolo de aplicacin ROSE. Las componentes del modelo abstracto son las siguientes: Objetos abstractos (ROS-OBJECT-CLASS) Contratos abstractos (CONTRACT) Paquetes de conexin (CONNECTION-PACKAGE) Puertos abstractos (OPERATION-PACKAGE) Operaciones abstractas (OPERATION) Errores abstractos (ERROR) Contextos de aplicacin (APPLICATION-CONTEXT)
La macro ROS-OBJECT-CLASS define la capacidad de un objeto abstracto de interaccionar con otros objetos a travs de asociaciones donde se definen los contextos de esas interacciones en trminos de contratos abstractos. Se listan los contratos que soporta un objeto abstracto como entidad que inicia o responde a la asociacin o ambos indistintamente. Cuando se utilizan servicios de comunicacin OSI, un objeto abstracto representa un proceso de aplicacin.
nombre-objeto ROS-OBJECT-CLASS ::= { INITIATES {lista-iniciador-contract} RESPONDS {lista-responde-contract} BOTH {lista-contracts} ID identificador-objeto } Fig. 3.29 Macro ROS-OBJECT-CLASS para la especificacin de aplicaciones basadas en ROSE
73
La macro CONTRACT define el contexto en el que los objetos pueden interaccionar. Se incluye como se establece y libera la asociacin y los puertos abstractos que se pueden utilizar durante la vida de la asociacin. Se listan los puertos en los que la entidad que inicia la asociacin adopta el papel de consumidor, suministrador o ambos (puertos simtricos). Cuando se utilizan protocolos de comunicacin OSI un contrato (CONTRACT) se realiza como un contexto de aplicacin.
nombre-contract CONTRACT ::= CONNECTION INITIATOR CONSUMER OF RESPONDER CONSUMER OF OPERATIONS OF ID { nombre-connection-package {lista-puertos} --puertos asimtricos iniciador es consumidor {lista-puertos} --puertos asimtricos responde es consumidor {lista-puertos} --puertos simtricos identificador-contract }
Fig. 3.30 Macro CONTRACT para la especificacin de aplicaciones basadas en ROSE
La macro CONNECTION-PACKAGE especifica la parte del contrato relacionada con el establecimiento (Bind) y la liberacin (Unbind) de la asociacin. Cuando se utilizan los servicios de comunicacin OSI esto se realiza utilizando los servicios de ACSE directamente o a travs de RTSE.
nombre-connection-package CONNECTION-PACKAGE BIND nombre-operacin-bind UNBIND nombre-operacin-unbind ID identificador-connection-package } ::= {
Fig. 3.31 Macro CONNECTION-PACKAGE para la especificacin de aplicaciones basadas en ROSE
Un puerto abstracto es el punto mediante el cual interaccionan dos objetos abstractos y se definen mediante la macro OPERATION-PACKAGE. Para cada puerto se definen las operaciones que cada objeto puede invocar asumiendo el papel de consumidor, suministrador y las que pueden invocar asumiendo ambos papeles. Los puertos asimtricos son aquellos en los que cada instancia asume un papel diferente, es decir, consumidor o suministrador. Por el contrario en un puerto simtrico ambas instanciaciones son idnticas. Cuando se utilizan servicios de comunicacin OSI un OPERATIONPACKAGE se realiza mediante un ASE especfico.
nombre-puerto OPERATION-PACKAGE ::= { CONSUMER INVOKES {lista-operaciones} SUPPLIER INVOKES {lista-operaciones} OPERATIONS {lista-operaciones} ID identificador-puerto
--operaciones invocadas por el consumidor --operaciones invocadas por el suministrador --operaciones invocadas por ambos }
Fig. 3.32 Macro OPERATION-PACKAGE para la especificacin de aplicaciones basadas en ROSE
74
Las macros OPERATION y ERROR son iguales que las macros ABSTRACT-OPERATION y ABSTRACT-ERROR de ROSE. De hecho se definen de la forma siguiente:
ABSTRACT-OPERATION ABSTRACT-ERROR ::= ::= OPERATION ERROR
nombre-operacin OPERATION ::= { ARGUMENT TipoArgumento RESULT TipoResultado ERRORS {lista-errores} INVOKE PRIORITY {lista-operaciones-prioritarias} CODE identificador-operacin } Fig. 3.33 Macro OPERATION para la especificacin de aplicaciones basadas en ROSE
nombre-error ERROR ::= { PARAMETER TipoParmetro CODE identificador-error } Fig. 3.34 Macro ERROR para la especificacin de aplicaciones basadas en ROSE
La macro APPLICATION-CONTEXT se utiliza para definir los aspectos estticos relacionados con el contexto de aplicacin. Es decir, el contrato vlido, los servicios OSI que se van a utilizar para el establecimiento y la liberacin de la asociacin, la transferencia de informacin y las sintaxis abstractas.
nombre-contexto-aplicacin APPLICATION-CONTEXT ::= { CONTRACT nombre-contract ESTABLISHED BY establecer-asociacin --acse o rtse INFORMATION TRANSFER BY unidad-datos --pData o transfer-by RTSE ABSTRACT SYNTAXES {lista -sintxis-abstractas} APPLICATION CONTEXT NAME identificador-contexto-aplicacin } Fig. 3.35 Macro APPLICATION-CONTEXT para la especificacin de aplicaciones basadas en ROSE
4 El correo electrnico
75
4.1 Introduccin
Aunque correo electrnico es el trmino ms habitual, se utilizar tambin el trmino sistema de mensajera electrnica (SME) y, especialmente en un contexto OSI, el trmino sistema de gestin de mensajes (MHS, Message Handling System) para referirnos a la aplicacin distribuida de manejo e intercambio de mensajes mediante redes de ordenadores. Bsicamente, un sistema de mensajera electrnica es un sistema de comunicacin utilizado para enviar informacin (mensajes) de una persona (o lugar) a otra (u otro). Esta comunicacin tambin puede ser de una persona a muchas a la vez. Los mensajes electrnicos pueden incluir texto, grficos, voz, etc., dependiendo del sistema utilizado. En la mayora de los casos se trata con texto, aunque cada vez es ms habitual el intercambio de mensajes multimedia. Los sistemas de telex y facsmil (o fax), predecesores de los SME, transmiten mensajes de un lugar a otro (punto a punto) requiriendo que las mquinas del remitente y del destinatario estn en lnea a la vez, mientras que el correo electrnico no tiene este requerimiento. El correo electrnico, como aplicacin OSI, inicialmente fue normalizado por el CCITT en 1984, con la aprobacin de las recomendaciones internacionales conocidas como X.400, que tienen el mrito de ser la primera norma del nivel de aplicacin del modelo de referencia OSI que se desarroll. La normalizacin fue el resultado de la necesidad de interoperabilidad de los sistemas que iban apareciendo en el mercado.
76
La experiencia adquirida con estas recomendaciones y las primeras implementaciones llevaron al CCITT a desarrollar una nueva versin, aprobada en 1988, que corrige muchas de las limitaciones de la versin del 84. Asimismo, la experiencia tambin sirvi, como se explica en el captulo 1, para mejorar globalmente el nivel de aplicacin. La versin del 88 se public tambin, aunque con pequeas diferencias, como un estndar de ISO. Finalmente, despus de 1988 se han publicado nuevas versiones del estndar/norma que no cambian demasiado la funcionalidad, pero que corrigen y extienden algunas caractersticas. De hecho, est prevista una nueva republicacin en 1995. La implantacin general de las recomendaciones X.400 est llevando a la posibilidad de un uso ms generalizado de los SME, dado que est siendo realmente factible la interconexin de sistemas de mensajera de todo el mundo. Todos los sistemas ya existentes, y los nuevos por desarrollar, podrn conectarse de forma generalizada, utilizando X.400, al menos como interfaz con otros sistemas. Es necesario mencionar en este punto, aunque se tratar con ms detalle en el apartado 4.10 que, en paralelo con el correo X.400, se ha ido desarrollando, con mucho xito en los ltimos aos, otro sistema de correo electrnico ms sencillo, aunque igualmente til, que se conoce como correo Internet.
4.2 Funcionalidad de los SME

En esta seccin, se presenta la funcionalidad ms habitual ofrecida por los sistemas de correo electrnico. En principio, la funcionalidad ofrecida al usuario es independiente de la funcionalidad de los protocolos y servicios implementados. Por ello, las operaciones que se van a presentar son posibles en muy distintos sistemas, sigan o no un determinado estndar. En concreto, las operaciones ofrecidas ms habitualmente por los SME son: Operaciones de recepcin de mensajes: Enumerar mensajes: da informacin sobre mensajes disponibles, normalmente para ser ledos, aunque podran incluso estar pendientes de envo. Leer: para leer (presentar en pantalla o impresora) un mensaje recibido.
Operaciones de envo de mensajes: Componer: para preparar un mensaje completo, que incluye la informacin que el usuario quiere enviar (texto por ejemplo) y parmetros del mensaje (destinatario, prioridad, etc.). Enviar mensaje: enva un mensaje previamente preparado. Esta operacin puede estar incluida en la anterior (Componer). Reenviar mensaje: permite reenviar un mensaje ya recibido a otro destinatario diferente. Contestar: para enviar respuestas a mensajes recibidos.
77
Notificar: para enviar notificaciones de recepcin de mensajes.
Operaciones de gestin: Editar: permite modificar el contenido de un mensaje. Recuperar: busca un fichero o mensaje en el sistema. Almacenar: almacena mensajes en ficheros. Clasificar: clasifica mensajes segn un criterio determinado, como puede ser la confidencialidad o el nombre del remitente.
4.3 Arquitectura de los SME
4.3.1 Introduccin Una idea bsica en los SME es que no es necesario que el originador y el destinatario (o destinatarios) de un mensaje estn en lnea al mismo tiempo. Esto es as debido a que los SME se basan en la idea de almacenamiento y reenvo (store-and-forward), lo que significa que los mensajes son colocados en el sistema de mensajera cuando el remitente lo desea, independientemente del destinatario. Despus, el sistema se encarga de, paso a paso (esto es, la primera mquina que recibe el mensaje, si no es el destino final, lo almacena para ser reenviado a otra mquina, repitindose tal proceso hasta llegar al destino), hacer llegar el mensaje a su destinatario. La arquitectura del sistema de mensajera electrnica que se presenta aqu es la estandarizada en las recomendaciones X.400. De cualquier forma, muchos de los conceptos son tambin vlidos en otros sistemas propietarios y en el correo electrnico Internet. Lo que normalmente se conoce como X.400 es un conjunto de recomendaciones relacionadas entre s. Los nmeros de las recomendaciones y los estndares correspondientes se detallan en la bibliografa anexa. Las recomendaciones X.400 describen un servicio que permite a sus usuarios el intercambio internacional de mensajes utilizando los servicios telemticos existentes en cada pas. El servicio que se define lo proporciona lo que se llama el sistema de gestin de mensajes (MHS, Message Handling System). Como se siguen los principios del modelo de referencia OSI, el MHS usa los servicios ofrecidos por el nivel de presentacin y por elementos de servicio de aplicacin (ASE) comunes. Por tanto, se puede construir un MHS en cualquier entorno OSI.
78
4.3.2 La arquitectura La arquitectura del MHS est esquematizada en la figura 4.1. Dentro del MHS, se puede encontrar el servicio de transferencia de mensajes proporcionado por el sistema de transferencia de mensajes (MTS, Message Transfer System). El MTS permite transferir mensajes desde un usuario a otro, independientemente del contenido de los mensajes transferidos. Sobre el MTS se pueden definir diferentes aplicaciones para diferentes formatos de los contenidos de los mensajes. Como se ver ms adelante, se estandariz inicialmente la aplicacin llamada de mensajera interpersonal. De todas formas, se puede usar el servicio del MTS para cualquier otra aplicacin.
Usuario
Otros servicios telemticos
Usuario
MHS
AU
MTS MTA Usuario UA MTA Usuario UA MTA UA Usuario MTA MS UA Usuario
PDAU
Usuario
Servicio de entrega fsica
Usuario
Fig 4.1 Arquitectura del MHS
El principio general de funcionamiento es que el usuario originador de un mensaje lo enva al MTS para ser entregado a uno o ms usuarios destinatarios. El MTS est formado por entidades funcionales llamadas agente de transferencia de mensajes (MTA, Message Transfer Agent). Varios MTA cooperan para realizar la funcin de transferencia de mensajes con la tcnica de almacenamiento y reenvo. Entre MTA y MTA es necesario un protocolo OSI (o, ms precisamente, un contexto de aplicacin), el cual se denomina P1. Tanto el usuario originador como el destinatario de un mensaje estn asociados a un MTA determinado. Aparte del MTS (con sus MTA), el MHS contiene otras entidades funcionales interconectadas, que pueden ser de los siguientes tipos (vase la figura 4.1):
79
Agente de usuario (UA, User Agent): Ayuda al usuario final (normalmente una persona) a acceder al MHS. Debe conocer el formato de los mensajes que enviar y recibir a travs del MTS. Si el UA y el MTA estn en mquinas distintas, se define un protocolo de acceso, llamado P3. Almacn de mensajes (MS, Message Store): Proporciona almacenamiento de mensajes (recibidos desde el MTS), y permite su envo, recuperacin y gestin (a instancias del usuario a travs de su agente de usuario). El MS se aadi en 1988 para permitir que la recepcin de mensajes sea controlada por el usuario. Cuando hay un MS, el UA accede al MTS a travs de un MS (el protocolo de acceso del UA al MS se denomina P7). Si, adems, el MS y el MTA estn separados, tambin es necesario el protocolo P3, antes mencionado, para el acceso del MS al MTA. En la seccin 4.7 se trata el almacn de mensajes con ms detalle. Unidad de acceso (AU, Access Unit): Proporciona interfaz con otros sistemas y servicios de comunicacin (servicios telemticos y servicio postal). Ejemplos de AU son las unidades de acceso a servicios telemticos ms antiguos como telex o teletex; y la unidad de acceso al servicio postal o de entrega fsica (PDAU, Physical Delivery Access Unit) que especifica, entre otras cosas, cmo mapear direcciones electrnicas sobre direcciones postales (y viceversa).
4.3.3 Modelo de funcionamiento La figura 4.2, que es una extensin de la figura 4.1, presenta el modelo de funcionamiento del MHS.
MTS originador envo UA originador UA envoindirecto MS envo MTA MTA transferencia MTA MS entrega recuperacin MTA entrega UA destinatario UA destinatario
Fig. 4.2 Modelo de funcionamiento del MHS
Lo que en la figura 4.1 se llama usuario, puede ser una persona o una aplicacin en un ordenador. Un usuario en el SME puede ser originador o remitente (originator), cuando enva un mensaje, o destinatario (recipient) cuando lo recibe.
80
Como ya se ha mencionado, las entidades agente de usuario (UA) son las que sirven para que el usuario pueda preparar mensajes y enviarlos a otro usuario a travs del sistema de transferencia de mensajes (MTS). Es decir, el UA interacciona con el usuario para ayudarle a preparar los mensajes, y con el MTS y el MS para enviarlos o recibirlos. Las funciones del UA que son locales a l no estn estandarizadas por las recomendaciones aunque s, por supuesto, su interaccin con el MTS y el MS. La operacin de envo (submission) de un mensaje se puede hacer directamente del UA al MTA, o indirectamente a travs de un MS. El MTS realiza la operacin de entrega (delivery) de mensajes a un UA, directamente, o bien a travs de un MS. En este ltimo caso, el MS ya tuvo entrega previamente desde el MTS, y la operacin entre UA y MS es de recuperacin (retrieval), e iniciada por el UA. Por tanto, el MS acta de intermediario entre el UA y el MTA. El MTS se encarga de entregar el mensaje a uno o ms UA, MS, o AU, segn lo haya solicitado el UA originador del mensaje. Finalmente, se puede ver en la figura 4.1 que, en el MTS, los MTA se encargan, cooperando unos con otros, de transmitir y retransmitir (es decir, transferir) mensajes para entregarlos a su destinatario.
4.3.4 Implementacin En el MTS, cada MTA se corresponde con una mquina, remota de cualquier otro MTA, por lo que es necesario un protocolo (P1) para comunicarse entre MTA. Normalmente, los MTA se implementan en mquinas grandes que dan servicio a muchos usuarios, ya que deberan estar disponibles en todo momento, y el software que necesitan implementar es bastante complejo. Por su parte, los UA no tienen por qu estar necesariamente separados del MTA al que estn asociados. En muchos casos, se ofrece un UA a cada usuario de las mquinas grandes en las que residen los MTA, con lo que no es necesario, evidentemente, implementar el protocolo P3. Si se quiere que los usuarios accedan al MTS desde mquinas remotas a los MTA, entonces s hay que implementar P3. En estos casos, podra plantearse un acceso desde una mquina no tan grande, como un PC mono-usuario, en el que residira el UA. Un problema del protocolo P3 es que requiere que el UA est preparado para que le entreguen mensajes (no es el UA quien los pide), por lo que muchas veces no es viable implementarlo desde un PC. Esta es una de las razones por las que se introdujo en 1988 el protocolo P7 y el concepto de almacn de mensajes. Con P7, el UA puede estar perfectamente en una mquina mono-usuario, ya que es el UA quien decide cundo se reciben los mensajes (recurdese que el MTA entrega los mensajes al MS, quien los guarda hasta que el UA accede a l para recuperarlos). Normalmente adems, cuando hay P7 el MS suele ser local al MTA, por lo que no se implementa P3.
81
Existen por supuesto otras alternativas de implementacin, como disponer de un MTA en una red local, y que los UA accedan a l desde otras mquinas de la red con protocolos diferentes a los mencionados.
4.3.5 Estructura de un mensaje Los mensajes que se transfieren a travs del MTS tienen una estructura normalizada. Un mensaje, tal como esquematiza la figura 4.3, est dividido, bsicamente, en dos partes: Envoltorio o sobre (envelope): Lleva informacin relacionada con la transferencia del mensaje. Por tanto, esta informacin la usa el MTS. Contenido (content): Es la informacin que el UA originador desea entregar a los destinatarios (vase el apartado 4.8.1).
sobre
cabecera
parte de cuerpo 1 contenido parte de cuerpo 2 cuerpo
parte de cuerpo 3
Fig. 4.3 Estructura de un mensaje
El MTS transfiere los mensajes independientemente de lo que contienen, utilizando nicamente la informacin del sobre. Sin embargo, para que dos agentes de usario puedan intercambiarse mensajes correctamente, deben, lgicamente, poder interpretar el contenido. Por ello, como ya se ha mencionado, los UA deben conocer la estructura del contenido de los mensajes que se intercambian. En la seccin 4.8 se tratar esta cuestin con ms detalle.
82
4.4 Direccionamiento
4.4.1 Direcciones Para poder intercambiar mensajes, se necesita algn mecanismo que permita identificar, es decir, nombrar y direccionar, a los destinatarios (y a los originadores) de los mensajes. Se requieren nombres para: usuarios (sea una persona o un programa) listas de distribucin (conjuntos de usuarios agrupados)
Las listas de distribucin se utilizan para simplificar la distribucin de mensajes a grupos de usuarios. El MTS es el que se encarga de distribuir los mensajes, ya que la lista identifica un MTA destino donde se conoce quines son los miembros de la lista que, a su vez, puede incluir otras listas anidadas. Tanto los usuarios como las listas se identifican por lo que se llama nombre de originador/destinatario o nombre O/R (Originator/Recipient name u O/R name). Dos elementos pueden formar parte de un nombre O/R: nombre distintivo (distinguished name) direccin de originador/destinatario o direccin O/R (O/R Address)
Un nombre O/R (O/R Name) concreto puede constar de una de estas tres alternativas: un nombre distintivo una direccin O/R un nombre distintivo ms una direccin O/R
La direccin O/R es lo que realmente identifica de forma nica a un usuario, o a una lista de distribucin, por medio de atributos predefinidos. Por ello, en el caso de disponer de un nombre distintivo ser necesario obtener la direccin O/R para poder enviar el mensaje. Esto se consigue accediendo al servicio de directorio (vase el captulo 6) que, a partir de un nombre distintivo, se puede obtener una direccin O/R. De cualquier forma, para disponer de un nombre distintivo es necesario estar registrado en el servicio de directorio. Los atributos ms habituales que forman una direccin O/R son: Pas (C, de Country): Un cdigo normalizado que identifica el pas. Por ejemplo, es para Espaa.
83
Dominio de gestin de administracin (ADMD): Identifica el ADMD al que se pertenece (vase 4.4.2). El ADMD de Telefnica es mensatex. Dominio de gestin privado (PRMD): Identifica un PRMD (vase 4.4.2). Por ejemplo, para el caso de las universidades espaolas, todas pertenecen al PRMD iris. Organizacin (O): Un PRMD se puede estructurar en organizaciones, segn su propio criterio. En el caso de las universidades, cada universidad se considera una organizacin del dominio privado iris. Un ejemplo podra ser la UPC, cuyo valor para este atributo es upc. Unidad organizativa (OU): Cada organizacin puede, a su vez, definir varios niveles ms de estructura (podran ser divisiones, departamentos, secciones, grupos, etc., si existen), los cuales se llaman genricamente unidades organizativas. Siguiendo con el ejemplo de la UPC, se define un nico nivel de OU que corresponde, en general, con los departamentos. Un ejemplo sera OU=ac, para el departamento de Arquitectura de Computadores. Nombre personal (PN): Finalmente, en el nivel ms bajo de la jerarqua, est el nombre personal, que corresponde con usuarios finales de un dominio (que podran ser tanto personas, como listas o programas). Es criterio del penltimo nivel de la jerarqua (una OU, una O, o un PRMD) decidir cmo se asignan estos nombres. Una forma habitual para identificar usuarios es utilizar nombres, apellidos o combinaciones de ambos.
Por tanto, una direccin O/R ser una secuencia de algunos de, o todos, los atributos previos que, como puede verse, forman una jerarqua que facilita la asignacin de nombres, as como las rutas que deben utilizar los MTA para hacer llegar los mensajes a sus destinos. Por ejemplo, el hipottico usuario Jos Lpez del departamento de Arquitectura de Computadores de la UPC podra tener una direccin O/R con los siguientes atributos y valores: C=es; ADMD=mensatex; PRMD=iris; O=upc; OU=ac; PN=jlopez.
4.4.2 Dominios de gestin Los usuarios del MHS se organizan segn lo que se llama dominio de gestin (MD, Management Domain). Un MD est formado por uno o ms MTA y cero o ms UA, MS y AU, utilizados por una compaa o institucin. Normalmente, un dominio de gestin estar a su vez estructurado en organizaciones y, posiblemente, en unidades organizativas, tal como se mencion en el apartado anterior. Hay dos tipos de dominios de gestin: de administracin (ADMD) privados (PRMD)
84
Los dominios de administracin corresponden a las compaas (o administraciones) responsables del transporte de datos o comunicaciones en un pas. En algunos pases habr una sola posibilidad de ADMD, mientras que en otros, donde no existe un monopolio, habr varias opciones. Normalmente, los ADMD asignarn PRMD a las compaas o instituciones que deseen disponer de un dominio de mensajera electrnica. La figura 4.4 muestra algunas posibles relaciones entre dominios de gestin.
ADMD 1
ADMD 2 UA MS
UA UA
MTA MTA MTA
MS
MTA
ADMD 3
UA MTA
UA
MTA
UA UA MTA PRMD 2
UA UA MS UA
MTA MTA MS UA UA PRMD 3 PRMD 1 Pas A Pas B UA
UA
UA
Fig. 4.4 Posibles relaciones entre dominios de gestin
Un PRMD puede tener, como ya se ha dicho en la definicin, varios MTA. Una forma posible de organizar los MTA es en funcin de cmo se estructura el dominio. Por ejemplo, se podra decidir que cada organizacin dentro de un PRMD disponga de un MTA, al igual que cada unidad organizativa, por lo que se consigue una relacin entre MTA y atributos en la jerarqua de las direcciones O/R que facilita los algoritmos de direccionamiento. El concepto de dominios de gestin va asociado tambin a cmo se implementa y proporciona el servicio de correo electrnico en una organizacin. Las dos alternativas bsicas son:
85
Implementar (o comprar el software necesario para hacerlo) un MTA y los UA y MS necesarios en funcin de mquinas y usuarios. En este caso ser necesario obtener un PRMD. Comprar o alquilar el servicio (uso de un UA) a un proveedor con su propio dominio, que normalmente ser un ADMD, aunque tambin podra ser un PRMD. Un ejemplo sera el servicio Mensatex, comercializado por una filial de Telefnica.
4.5 Realizacin OSI
4.5.1 Especificacin ASDC Hasta ahora, se ha visto la aplicacin de correo electrnico desde un punto de vista de funcionalidad y de arquitectura. Se trata, evidentemente, de una aplicacin distribuida, por lo que se puede especificar utilizando ASDC, tal como se explica en el captulo 3. Por ello, las propias recomendaciones X.400 especifican el sistema de mensajera siguiendo las tcnicas de ASDC. Tambin se debe recordar que, de hecho, el ASDC fue inicialmente desarrollado como una de las recomendaciones X.400 con el objetivo de especificarlas formalmente. Una vez se tiene el sistema de mensajera especificado en ASDC, se debe definir cmo se implementa en un contexto OSI.
MHS Envo Entrega Usuario-MTS Administracin MTS Administracin Envo Entrega Usuario-MTS
Fig. 4.5 Refinamiento del MHS
Siguiendo la arquitectura ya definida, se puede refinar el MHS como un MTS y una serie de objetos que acceden a l, como en la figura 4.5. Estos objetos pueden ser de varios tipos, pero los ms importantes son el UA y el MS. El nmero de puertos que habr entre el MTS y sus usuarios (en este caso, tanto el UA como el MS se pueden considerar usuario-MTS) depende de cmo se agrupen sus funciones. Por razones que quedan ms claras despus, se ha decidido especificar tres puertos, uno para envo (submission), otro para entrega (delivery) y el ltimo para administracin (administration). Ahora se podra especificar formalmente este refinamiento utilizando ASDC. Sin
86
embargo, no se detallan las especificaciones ASDC para no alargar innecesariamente el texto y por ser, en muchos casos, fcilmente deducibles. Un segundo paso (figura 4.6) podra consistir en especificar la relacin entre el MS y su usuario (es decir, el UA). En este caso, se definen otra vez tres puertos, aunque no son exactamente los mismos que antes. En concreto, los puertos son de envo-indirecto (submission), recuperacin (retrieval) y administracin (administration).
Usuario-MS
Recuperacin Envo-indirecto Administracin
MS
Figura 4.6 Relacin entre el MS y el usuario-MS
Finalmente, se debera refinar el MTS, siguiendo la figura 4.7. Los MTA visibles tienen tres puertos al exterior, como se acaba de mencionar. Entre MTA, solamente se especifica un puerto, llamado de transferencia (transfer).
MTS
P3 Entrega Envo Administracin MTS abstract-service MTA provider P1 MTA Transferencia Transferencia P1 MTA
P3 Entrega Envo Administracin
Fig. 4.7 Modelo refinado del sistema de transferencia de mensajes
4.5.2 Protocolos A la hora de implementar la especificacin anterior en OSI, cada puerto corresponder con un elemento de servicio de aplicacin (ASE) especfico, y cada enlace entre objetos corresponder con un contexto de aplicacin, lo que normalmente se conoce como protocolo. Por tanto, se especifican los protocolos siguientes: protocolo entre usuario del MTS y el MTS (asimtrico o de acceso): P3
87
protocolo entre usuario del MS y el MS (asimtrico o de acceso): P7 protocolo entre MTA (simtrico o de sistema): P1
Teniendo en cuenta los puertos mencionados, stos correspondern con otros tantos ASE, que son: elemento de servicio de envo (submission) de mensajes (MSSE) elemento de servicio de entrega (delivery) de mensajes (MDSE) elemento de servicio de recuperacin (retrieval) de mensajes (MRSE) elemento de servicio de administracin de mensajes (MASE) elemento de servicio de transferencia de mensajes (MTSE)
Los cuatro primeros ASE son asimtricos, mientras que el ltimo es simtrico. Adems de estos ASE, se utilizan algunos de los ASE comunes del nivel de aplicacin, como son el ACSE, el ROSE y el RTSE. En las siguientes subsecciones se detalla la estructura de los diferentes protocolos o contextos de aplicacin.
4.5.2.1 Protocolo de acceso al MTS El acceso al MTS se realizar desde un usuario-MTS (MTS-user), que en unos casos (la mayora) corresponder a un UA y en otros a un MS. Para realizar este acceso, se necesitan tres ASE especficos, cada uno de los cuales soporta un puerto, entre un usuario-MTS y el MTS. En concreto, son el MSSE, el MDSE y el MASE.
Usuario de MTA
MTA
UE MSSEc MDSEc MASEc ROSE ACSE ACSE
UE MSSEs MDSEs MASEs ROSE
Nivel de aplicacin
Protocolo P3
Fig. 4.8 Protocolo P3
88
Adems, se necesitarn el ACSE y el ROSE. Si se desea, en algunos casos se puede utilizar un contexto de aplicacin distinto, que incluya adems el RTSE. La figura 4.8 esquematiza este protocolo (protocolo P3), donde se debe tener en cuenta que acceder al MTS implica acceder a un MTA.
4.5.2.2 Protocolo de acceso al MS En el caso de acceso al servicio proporcionado por el almacn de mensajes (MS), los ASE especficos son el MSSE, el MRSE y el MASE. A diferencia del acceso al MTS, en el acceso al MS, slo el usuario puede establecer una asociacin. El protocolo de acceso al MS se conoce como P7. Asmismo, son adems necesarios el ACSE, el ROSE y, opcionalmente, el RTSE. En la figura 4.9 se pueden ver las entidades de aplicacin necesarias para el protocolo P7.
Usuario de MS
MS
UE MSSEc MRSEc MASEc ROSE ACSE ACSE
UE MSSEs MRSEs MASEs ROSE
Nivel de aplicacin
Protocolo P7
4.5.2.3 Protocolo de transferencia En el protocolo de transferencia entre MTA slo se utiliza un ASE especfico, el MTSE, asociado a puertos de transferencia. Adems, se necesitan el RTSE y el ACSE. Cualquier MTA puede establecer una asociacin con otro MTA. En la figura 4.10 se pueden ver las entidades de aplicacin necesarias para el protocolo P1.
89
MTA
MTA
UE MTSE Nivel de aplicacin RTSE ACSE
UE MTSE RTSE ACSE
Protocolo P1
4.5.3 Servicios Hasta ahora, slo se ha visto la visin macroscpica de la especificacin en ASDC del sistema de mensajera. Para completar la especificacin, es necesario aadir la visin microscpica, es decir, las operaciones que se realizan a travs de cada puerto. En lugar de mostrar estas operaciones como una visin microscpica ASDC, las operaciones se detallan en las siguientes secciones siguiendo los diferentes servicios.
4.6 Servicio de transferencia de mensajes

El servicio de transferencia de mensajes es un servicio general de transferencia de informacin, independiente de la aplicacin. En el servicio de transferencia de mensajes no se tiene en cuenta la informacin que manejan los UA. Estos, en general, se agrupan en clases de UA cooperantes para proporcionar una aplicacin determinada sobre el servicio de transferencia de mensajes. Por tanto, el contenido de la informacin transferida por el MTS es, para ste, transparente, es decir, es una secuencia de octetos. El servicio de transferencia de mensajes puede proporcionar notificaciones de entrega y de noentrega. Es decir, indicar al UA (o usuario del MTS en general) originador del mensaje si ste ha sido entregado a sus destinatarios o no. Esto se detalla en la figura 4.11.
90
Originador Usuario-MTS Entregainforme (no-entrega) Envomensaje Tranferenciamensaje Entregamensaje Usuario-MTS MTA Destinatarios
MTA
MTS
MTA
Transferenciainforme
MTA Usuario-MTS
(no-entrega)
Fig. 4.11 Notificaciones en el MTS
En cuanto al servicio, aparte de las operaciones habituales en todo contexto de aplicacin, como el establecimiento y la liberacin de una unin (MTS-Bind y MTS-Unbind), el MTS ofrece las siguientes operaciones, agrupadas por puertos: Operaciones abstractas del puerto de envo: Envo de mensaje: Es la operacin habitual para enviar un mensaje. Envo de sonda (probe): Para comprobar si un mensaje podr ser enviado. Cancelacin de entrega diferida: Para cancelar una orden previa de entregar un mensaje de forma diferida. Control de envo: Para operaciones de control.
Operaciones abstractas del puerto de entrega: Entrega de mensaje: Es la operacin habitual para entregar un mensaje. Entrega de informe (report): Para entregar un informe de cmo ha ido la transferencia de un mensaje. Control de entrega: Para operaciones de control.
Operaciones abstractas del puerto de administracin: Registrar: Para operaciones de registro. Cambiar credenciales: Para cambio de credenciales.
Las operaciones enumeradas son las que se ofrecen, a travs de protocolo P3, a los usuarios de MTS. Pero adems, tal como se vio en la figura 4.7, el MTS se refina en MTA, los cuales tienen un nuevo puerto (transferencia).
91
Las operaciones del puerto de transferencia son: transferencia de mensaje transferencia de sonda transferencia de informe
4.7 Almacn de mensajes

Las recomendaciones X.400 definen el servicio abstracto del MS, la estructura de la informacin a almacenar y los procedimientos de realizacin. La figura 4.12 presenta los puertos del MS que define la norma.
P7 Recuperacin Envo-indirecto Administracin
P3 Entrega Envo Administracin
UA
MS
MTS
Figura 4.12 El MS y sus puertos
El objeto almacn de mensajes (MS) consta de seis puertos: recuperacin (retrieval) y envoindirecto (indirect-submission) entre UA y MS, entrega (delivery) y envo (submission) entre MS y MTS, y dos puertos de administracin a ambos lados. Por lo que respecta al protocolo de acceso al MS, hay, por tanto, tres puertos (recuperacin, envoindirecto y administracin). El nico puerto totalmente nuevo es el de recuperacin (envo-indirecto es equivalente al de envo visto anteriormente). Las operaciones disponibles en el puerto de recuperacin son: Resumir (Summarize): Para obtener una tabla resumen de los mensajes disponibles en el almacn, como por ejemplo cuntos mensajes hay por leer. Enumerar (List): Para obtener una lista de mensajes con algunos de sus atributos. La lista de mensajes, al igual que en la operacin anterior, se selecciona utilizando una interrogacin basada en valores de atributos, como originador, tema, etc.
92
Leer (Fetch): Para obtener uno o ms mensajes enteros seleccionados. Los mensajes se copian del almacn al agente de usuario. Borrar (Delete): Para borrar mensajes en el almacn. Registrar en MS (Register-MS): Para cambiar algunas caractersticas del usuario en el almacn. Alertar (Alert). Para alertar de la llegada al almacn de mensajes nuevos. Esta ltima operacin, cuando est disponible, es invocada por el MS, a diferencia de las restantes que son invocadas por el UA.
La informacin almacenada en un MS se estructura en tres categoras: mensajes almacenados diarios de correo (entrada y salida) diarios de autocorrelacin
4.7.1 Mensajes almacenados El almacn de mensajes proporciona un almacenamiento temporal a los mensajes que llegan a un UA (por el contrario, no se almacenan los mensajes que se envan). El MS contiene mensajes (con su envoltorio y su contenido) y un conjunto de atributos aadidos que forman la descripcin del mensaje. Estos atributos son, o bien informacin especial de almacenamiento, o bien informacin seleccionada a partir de la ya existente en los mensajes propiamente dichos. Ejemplos de atributos aadidos a la informacin de un mensaje por el servicio de MS son: Nmero de secuencia: se da automticamente por orden cronolgico de llegada. Tipo: sus dos nicos valores posibles son mensaje de servicio (informe de entrega) y mensaje de usuario. Estado: tiene tres posibles valores, que son nuevo, enumerado y procesado.
4.7.2 Diarios de correo Existen disponibles dos diarios de correo donde se guarda informacin para poder controlar la entrada y salida de correo hacia y desde un MS asociado a un agente de usuario.
93
El diario de entrada (inlog) guarda informacin sobre los mensajes que han llegado a un determinado buzn (almacn de mensajes asociado a un UA). El diario de salida (outlog) guarda informacin de los mensajes enviados a travs del MS. Los objetos de los diarios de correo contienen informacin seleccionada sobre los mensajes entregados al MS (diario de entrada) y enviados por el usuario (diario de salida), aparte de otros atributos aadidos. Los objetos del diario de entrada contienen informacin como: nmero de secuencia de MS tiempo de entrega informacin de entrega (atributos dependientes del tipo de mensaje)
Los objetos del diario de salida contienen: nmero de secuencia de envo (generado automticamente) tiempo de envo informacin de envo (atributos dependientes del tipo de mensaje)
4.7.3 Diario de autocorrelacin El diario de autocorrelacin contiene informacin detallada sobre mensajes enviados por los usuarios del MS y cualquier devolucin (notificaciones y respuestas) relacionadas con esos mensajes.
4.8 Mensajera interpersonal

El servicio de mensajera interpersonal (IPMS, InterPersonal Messsaging Service) permite a un usuario comunicarse con otro usuario por medio de una clase especfica de UA cooperantes, llamados agentes de usuario interpersonales (IP-UA). Como el IPMS utiliza el servicio de transferencia de mensajes, es una aplicacin concreta (un formato concreto de mensajes) sobre el MTS. Aunque existen actualmente otros formatos estandarizados, ste es el primero que se normaliz (a la vez que el MTS).
4.8.1 Formato de un mensaje interpersonal (P2) El contenido de un mensaje del IPMS se llama mensaje interpersonal (mensaje IP o IPM), y consta de (vase la figura 4.3 anterior): cabecera (heading): informacin asociada al mensaje
94
partes de cuerpo (body parts): informacin o informaciones que el usuario desea comunicar
Las recomendaciones X.400 incluyen la definicin de la aplicacin de gestin de mensajes que se ha llamado mensajera interpersonal, especificando el tipo de contenido de los mensajes y los procedimientos de funcionamiento asociados. Todo ello se conoce como protocolo P2, aunque es ms un formato que un protocolo. El contenido de un mensaje interpersonal (IPM) est compuesto por una cabecera y una o varias partes de cuerpo. Lo primero es la informacin de control que caracteriza al mensaje y lo segundo la informacin que se desea comunicar. El cuerpo de un IPM puede contener texto, voz, facsmil, etc., o una combinacin de todos o algunos de ellos. Los componentes de la cabecera de un IPM son atributos con informacin para caracterizar el mensaje. No todos ellos tienen que estar presentes en todos los mensajes. Los atributos ms importantes son: Identificador de IPM: Para identificar de forma nica (usando la direccin O/R del originador del mensaje, el tiempo de creacin, etc.) el mensaje. Originador: Direccin O/R de quien enva el mensaje. Usuarios autorizantes: Direccin O/R de quienes autorizan el mensaje. Le da valor el originador. Destinatarios principales: Direcciones O/R de a quienes va dirigido el mensaje. Destinatarios de copia: Direcciones O/R de a quienes va dirigida una copia del mensaje. La copia es exactamente igual al mensaje, pero el originador indica con este atributo que el mensaje no est dirigido principalmente a esa o esas direcciones. Destinatarios de copia ciega: Direcciones O/R de destinatarios ocultados a los dems. Es decir, los destinatarios principales y de copia no conocen los destinatarios de copia ciega. En respuesta a IPM: Identificador del mensaje al cual se responde con ste. Obsoletiza IPM: Identificador del mensaje o mensajes que dejan de tener inters una vez se haya recibido ste. IPM relacionados: Identificadores de mensaje o mensajes relacionados con ste. La relacin la decide el originador del mensaje. Tema: Texto con el que el originador indica de qu trata el mensaje. Fecha de expiracin: Fecha (da y hora) a partir de la cual el mensaje deja de tener inters.
95
Hora de respuesta: Da y hora antes de la cual el originador solicita una respuesta al contenido del mensaje. Destinatarios de respuesta: Direcciones O/R de quien o quienes quiere el originador que reciban la respuesta al mensaje. Importancia: Para indicar la importancia (baja, normal, alta) que el originador da al mensaje. Sensibilidad: Para indicar el tipo de sensibilidad (personal, privado, confidencial a la compaa) que el originador da al mensaje. Auto-reenviado: Para indicar si el mensaje es reenviado automticamente por el sistema de correo del originador o no.
El cuerpo de un IPM est formado por una o ms partes independientes llamadas partes de cuerpo. Cada parte de cuerpo puede ser texto (lo es en la mayora de los casos), voz, facsmil, videotex, documentos normalizados, formatos acordados bilateralmente, etc., aunque no todas estas posibilidades estn totalmente detalladas en las recomendaciones. Asimismo, una parte de cuerpo puede ser un mensaje interpersonal reenviado. Un IPM reenviado consta de: tiempo de entrega informacin de entrega (envoltorio) mensaje interpersonal normal
Adems de mensajes interpersonales, tambin se pueden enviar notificaciones interpersonales, que sern de recepcin o de no-recepcin.
4.8.2 Definicin abstracta del servicio Al igual que se hizo para el MTS, se puede definir y refinar el IPMS usando definiciones de puertos, objetos y operaciones, es decir, ASDC. De cualquier forma, es importante resaltar que esta especificacin no implica una implementacin de un sistema distribuido entre usuarios y el IPMS, sino que sirve para formalizar el servicio ofrecido. La figura 4.13 muestra el entorno del IPMS, donde se pueden ver tres puertos entre usuario e IPMS, que son origen (origination), recepcin (reception) y gestin (management). Entre los objetos usuario e IPMS no hay ningn protocolo, ya que la relacin es local. Este refinamiento sirve nicamente para especificar formalmente las operaciones propias del IPMS.
96
IPME Origen Recepcin Usuario Gestin IPMS Gestin Origen Recepcin Usuario
Fig. 4.13 Entorno IPMS
Las operaciones abstractas de cada uno de los puertos son: operaciones abstractas del puerto origen: originar sonda originar mensaje interpersonal originar notificacin de recepcin
operaciones abstractas del puerto recepcin: recibir informe recibir mensaje interpersonal recibir notificacin de recepcin recibir notificacin de no-recepcin
operaciones abstractas del puerto gestin: cambiar auto-borrado (borrado automtico de mensajes expirados u obsoletos) cambiar auto-reconocimiento (generacin automtica de notificaciones de recepcin) cambiar auto-reenvo (reenvo automtico de mensajes recibidos a determinados usuarios)
El IPMS, a su vez, se refinara igual que el MHS, pero en este caso se dispondra de IP-UA (InterPersonal User Agent) en vez de UA, y los MS seran especficos de mensajera interpersonal (IP-MS).
4.9 Extensiones a las recomendaciones X.400

Las recomendaciones X.400 de 1988, que incorporan todas las caractersticas descritas ms otras tan importantes como la seguridad, son las que se implementan actualmente. Sin embargo, el esfuerzo de estandarizacin est continuando, habindose publicado ltimamente nuevas versiones y extensiones que tratan de mejorar algunas deficiencias y aadir ms capacidades, por ejemplo en el tema de gestin de la mensajera o en nuevos agentes de usuario.
97
4.10 Correo Internet
4.10.1 Introduccin El correo Internet es un servicio de mensajera electrnica basado en almacenamiento y reenvo, e independiente de los subsistemas de transmisin. Debido a esta caracterstica, este servicio slo necesita un canal fiable de datos entre los sistemas de mensajera, con lo que puede ser cubierto por diferentes tipos de redes. Para el correo Internet, al igual que en el caso de MHS, es necesario definir el modelo funcional del sistema, los servicios que proporciona y su protocolo. Estas especificaciones funcionales y de servicio se hallan en los dos estndares siguientes: SMTP (Simple Mail Transfer Protocol) o RFC 821: Especifica el protocolo por el cual un sistema de mensajera actuando como emisor puede intercambiar mensajes con otro sistema de mensajera que acta de receptor. En este estndar se especifican, adems del protocolo, el modelo funcional del sistema y los servicios proporcionados por el mismo. SMTP se describe en el documento RFC 821 [RFC821]. RFC 822 (Standard for the format of ARPA Internet text messages): Especifica el formato de los documentos que pueden ser enviados utilizando el protocolo SMTP. Este formato se describe en el documento RFC 8212 [RFC822].
4.10.2 SMTP / RFC 821 SMTP (Simple Mail Transfer Protocol) es un protocolo para la transferencia de correo a travs de Internet, e independiente de los subsistemas particulares de transmisin. Es un protocolo muy simple, en el cual la comunicacin entre el cliente y el servidor se realiza a travs de comandos de texto ASCII de 7 bits (US-ASCII). En este protocolo, que al igual que el MHS se basa en la idea de almacenamiento y reenvo, la comunicacin entre el emisor y el receptor siempre es un dilogo alternativo controlado por el emisor. Esto es, cuando el emisor invoca un comando, antes de invocar otro comando siempre debe esperar la respuesta del receptor.
4.10.2.1 Modelo funcional SMTP se basa en el modelo de comunicacin de la figura 4.14. A partir del momento en el cual un agente de usuario de correo introduce un mensaje en la cola de correo de salida, el emisor SMTP (SMTP sender) establece una conexin TCP bidireccional con un receptor SMTP (SMTP receiver) utilizando el port 25 de este ltimo. A partir de este momento, el emisor SMTP genera comandos
98
SMTP, que son enviados hacia el receptor SMTP. A su vez, las respuestas a estos comandos son enviadas del receptor SMTP hacia el emisor SMTP. Una vez los mensajes llegan al receptor SMTP de la mquina donde se encuentra el destinatario, el mensaje es introducido dentro del buzn de usuario correspondiente.
Cola correo de salida Conexin TCP Agente de usuario Mensajes en la cola Emisor SMTP Receptor SMTP Buzones de usuarios
Fig. 4.14 Modelo de comunicacin SMTP / RFC 821
Cabe resear que el receptor SMTP tanto puede ser el destino final como un destino intermedio ms cercano al destino final, tal y como se puede ver en la figura 4.15. En el caso en el cual el sistema receptor es un destino intermedio, el mensaje recibido es introducido de nuevo en la cola de correo de salida de la misma mquina, para ser enviado a otro receptor.
Sistema emisor Cola correo de salida Agente de usuario Mensajes en la cola Emisor SMTP Receptor SMTP
Sistema intermedio Cola correo de salida Mensajes en la cola Emisor SMTP
Sistema receptor
Receptor SMTP
Buzones de usuarios
Fig. 4.15 Comunicacin a travs de sistema intermedio
4.10.2.2 Direccionamiento Para el envo de un mensaje a un usuario es necesario conocer su direccin electrnica. Este usuario, que se encuentra en una mquina conectada en algn lugar dentro de un dominio, tendr una direccin electrnica de la forma: usuario@nombre_dominio. La segunda parte de la direccin electrnica es un nombre de dominio tal y como se define en DNS (vase apartado 6.2). Con este tipo de direccionamiento electrnico, el mensaje es enviado a la mquina identificada por la parte de la direccin que se halla a la derecha del signo @ (esto es, nombre_dominio). El proceso emisor SMTP utiliza el DNS para obtener la direccin fsica (IP) de la mquina destino. Una vez en
99
esta mquina, el mensaje es entregado al usuario identificado por la parte de la direccin que se halla a la izquierda del signo @ (esto es, usuario). Por ltimo, se debe mencionar que el proceso emisor SMTP no siempre puede establecer una conexin directa con el proceso receptor. Generalmente, a nivel de dominio siempre se dispone de una mquina servidora de correo que es la encargada de centralizar los procesos de transmisin y recepcin de correo hacia y desde el exterior.
4.10.2.3 Servicio / comandos SMTP El servicio que proporciona el correo de Internet viene definido por todos los comandos que pueden ser intercambiados entre el emisor SMTP y el receptor SMTP. Estos comandos son cadenas de caracteres de 7 bits acabadas por los caracteres CR (retorno de carro) y LF (cambio de lnea). Cada uno de los comandos est formado por una cadena de caracteres alfanumricos con un cdigo de comando y en algunos casos un parmetro. El parmetro se separa del cdigo mediante un espacio en blanco. La lista de los comandos permitidos en SMTP es la siguiente: Identificacin del emisor SMTP. Inicio de transaccin de correo. Inicio de una transaccin de entrega en el terminal o de correo. Inicio de una transaccin de entrega en el terminal y de correo. Identificacin de un receptor individual. Envo del mensaje. Aborto de la transaccin actual. Inicio de una transaccin de entrega en el terminal. Confirmacin de identificacin de un usuario. Peticin de confirmacin de una lista de correo. Peticin de ayuda. Cierre del canal de transmisin. Cambio de rol emisor-receptor.
4.10.3 Formato de los mensajes / RFC 822 Todo mensaje SMTP debe seguir la norma definida por el documento RFC 822. Esta norma, define un mensaje como una serie de campos de cabecera y, opcionalmente, un cuerpo separado de los campos de cabecera por la primera lnea en blanco del mensaje. Cabecera: La cabecera es un conjunto de campos estructurados que proporcionan informacin sobre el mensaje. Cada lnea de la cabecera es un campo diferente, excepcin hecha de si
100
empieza con un carcter de espacio en blanco, en cuyo caso esa lnea es continuacin de la anterior. La estructura de cada uno de los campos es de la forma: nombre-campo[: cuerpo-del-campo] Los campos ms importantes son: Date : fecha de envo From : originador To : destinatario Subject : tema Sender : emisor Cc : destinatario de la copia Message-id : identificador del mensaje Reply-to : destinatario de la respuesta In-reply-to : identificador del mensaje que se contesta. Cuerpo: El cuerpo es una secuencia de lneas de caracteres US-ASCII.
Aqu se incluye un ejemplo de mensaje con formato RFC822 con cabecera con los campos fecha, originador, tema, destinatarios e identificador de mensaje, y con un cuerpo con texto: Date: 26 Aug 76 1430 EDT From: antonio@empresa1.es Subject: Aqu el tema sobre el que va el mensaje To: jose@empresa2.es Message-ID: <some.string@SHOST> Antes de la primera linea en blanco aparecen los campos de cabecera. A partir de la primera linea en blanco empieza el cuerpo del mensaje. Existen unos dispositivos de interconexin llamados pasarelas de correo que permiten a usuarios de sistemas de mensajera X.400 intercambiar mensajes con usuarios de correo Internet. Para conseguirlo, las pasarelas de correo deben realizar un proceso de transformacin entre los dos formatos de mensajes que no siempre se puede realizar conservando toda la informacin que figura en el formato original del mensaje. Como el formato de un mensaje X.400 es ms complejo que el de un mensaje RFC-822, ser en el caso de que un usuario de X.400 desee enviar un mensaje a un usuario de correo Internet cuando la transformacin comportar prdida de informacin.
4.10.4 Diferencias SMTP - X.400 Algunas de las diferencias ms importantes entre SMTP y X.400 son que en SMTP:
101
Los mensajes no tienen sobre. No existe almacn de mensajes. Los mensajes slo pueden ser monocuerpo. La cabecera y el cuerpo slo pueden contener caracteres US-ASCII. La transferencia es slo de caracteres de 7 bits. Existen menos facilidades: - No existe confirmacin de recepcin - Sensibilidad - Fecha de expiracin - Mensajes obsoletos ni no vlidos - Prioridad - Destinatarios alternativos - Entrega diferida - Fecha lmite de entrega - Devolucin del contenido, etc.
4.11 MIME
4.11.1 Introduccin Los sistemas de correo Internet basados en los estndares RFC 821 (protocolo de transferencia SMTP) y RFC 822 (formato del mensaje) ven el cuerpo de un mensaje como un texto US-ASCII, lo que limita mucho las posibilidades de dichos sistemas de correo. La comunidad Internet, consciente del problema, ha introducido mejoras en su sistema de correo que se recogen en el estndar [RFC1341] de extensiones multipropsito al correo Internet (MIME, Multipurpose Internet Mail Extensions). MIME mantiene la compatibilidad con los sistemas de correo Internet antiguos basados en los estndares [RFC821] y [RFC822]. Los usuarios de correo MIME pueden, por una parte, enriquecer el juego de caracteres de los mensajes de texto que se intercambian y, por otra, incluir en sus mensajes informacin correspondiente a grficos, voz, vdeo, etc. Los mensajes MIME pueden ser estructurados, es decir, se pueden generar mensajes con diferentes tipos de informacin, como texto, grficos, tablas, etc. Esto es posible gracias al concepto de partes de cuerpo de un mensaje que se introduce por primera vez en los sistemas de correo Internet. Como se ha descrito en el apartado 4.8 de este captulo, la primera versin de los sistemas de correo OSI (X.400-84) ya contempla la posibilidad de utilizar diferentes tipos de contenido en un mensaje, as como estructurar el cuerpo de un mensaje en partes, cada una de ellas con un tipo de contenido diferente. Ya se han mencionado algunas de las limitaciones del correo Internet basados en RFC 821 y 822 como son los mensajes monocuerpo de texto US-ASCII o la transferencia a siete bits, pero existe otro inconveniente que es la longitud de las lneas de un mensaje, que est limitada a mil caracteres. Este
102
problema tambin se resuelve en MIME gracias al proceso de codificacin/decodificacin para la transferencia de mensajes (vase el apartado 4.11.2) . Para que un usuario de correo electrnico pueda enviar y leer mensajes multimedia de forma transparente es necesario normalizar: Los procesos de codificacin/decodificacin para la transferencia de los mensajes Los formatos de los contenidos de los mensajes
4.11.2 Tipos de codificacin para la transferencia La mayor parte de los mtodos que permiten representar informacin de texto, imgenes, vdeo, voz, etc., estn basados en la utilizacin de cdigos de ocho bits. Dos usuarios de correo MIME pueden intercambiar mensajes utilizando el protocolo SMTP extendido para transferir informacin de ocho bits (RFC 1426, SMTP Service Extension for 8bit-MIME Transport). Actualmente esta opcin es muy poco utilizada debido a que los sistemas de correo MIME estn poco extendidos y lo normal es que los usuarios de MIME deban intercambiar mensajes con usuarios de SMTP que utilizan un protocolo de transferencia de siete bits. Esta es la razn por la que los sistemas MIME actualmente soportan los dos tipos de protocolos de transferencia, garantizando de esta forma una gran interoperatividad entre la comunidad de usuarios de correo Internet (vase la figura 4.16).
Usuario MIME
Contenido mensaje MIME
SMTP 8 bits (RFC 1426) SMTP 7 bits (RFC 821/822) Internet
Contenido mensaje MIME
Usuario
Codificacin 8 bits a 7 bits
Decodificacin 7 bits a 8 bits
Agente de usuario MIME
Agente de usuario MIME
Fig. 4.16 Estructura general de un agente de usuario MIME
En caso de que un mensaje MIME (que contiene informacin codificada en ocho bits) se transfiera utilizando el protocolo SMTP (que es un protocolo basado en un cdigo de 7 bits) es necesario utilizar algn mtodo de codificacin que permita transportar octetos sobre septetos. Adems, es necesario que estos procesos de codificacin/decodificacin sean normalizados, ya que es la nica manera de garantizar tanto la compatibilidad entre los diferentes sistemas de correo como la utilizacin de los mismos de una forma transparente para el usuario. Los sistemas de correo MIME suelen permitir que los usuarios puedan escoger el mtodo de codificacin a aplicar a los mensajes en funcin del tipo de informacin que contengan. El tipo de
103
codificacin se indica en un campo opcional de la cabecera del mensaje llamado codificacin de transferencia de contenido (Content-transfer-encoding) que tiene el siguiente formato: Content-transfer-encoding: tipo de codificacin Los valores permitidos para el tipo de codificacin son: 7bit, 8bit y binary quoted-printable base64
En realidad, los tipos de codificacin 7bit, 8bit y binary no aplican ningn tipo de codificacin. Los dos primeros corresponden a mensajes de texto codificados respectivamente en ASCII de 7 bits y 8 bits, pero con longitudes de lnea compatibles con SMTP. En el caso de utilizar el tipo de codificacin 8bit el mensaje puede contener caracteres no US-ASCII. El tipo de codificacin binary permite utilizar lneas de cualquier longitud, y por lo tanto no necesariamente compatible con SMTP. El tipo de codificacin quoted-printable se puede considerar una semicodificacin o codificacin blanda, en el sentido de que nicamente se codifican los caracteres no US-ASCII. Estos caracteres se codifican con la secuencia formada por un carcter de escape (ESC) ms un carcter del cdigo original US-ASCII. El resultado de este tipo de codificacin para un usuario de correo SMTP es que obtiene un mensaje bastante legible. Finalmente, el tipo base64 consiste en aplicar una codificacin para pasar de un mensaje que contiene 8 bits de informacin a otro que se pueda transportar con siete bits. En concreto consiste en convertir cada 3 octetos de 8 bits de informacin (24 bits de informacin) en 4 octetos con 6 bits de informacin cada uno (contienen tambin 24 bits de informacin). Este tipo de codificacin expande la informacin a transmitir un 33%. A cada uno de los 6 bits obtenidos se le asocia el carcter equivalente utilizando un juego de caracteres de 6 bits (caracteres A-Z, a-z, 0-9, +, /). Si faltan octetos para llegar a un mltiplo de 3, se aaden = al final. El resultado para un usuario no MIME (por ejemplo SMTP) sera un mensaje totalmente ilegible. Por ejemplo, al aplicar el tipo de codificacin base64 a la secuencia de octetos ABC (US-ASCII 65, 66 y 67), se convierte en la secuencia QUJD (que en un cdigo de 64 caracteres corresponde a 16, 20, 9 y 3).
4.11.3 Tipos de contenido de los mensajes Para garantizar la compatibilidad entre los diferentes formatos existentes para representar cada tipo de informacin, MIME ha estandarizado un conjunto reducido de tipos de contenido diferentes (texto, grficos, audio, vdeo, etc.), y para cada tipo dos o tres subtipos que corresponden a formatos concretos.
104
Para indicar el tipo de contenido de un mensaje, MIME utiliza un nuevo campo de la cabecera con informacin referente al contenido. Este campo llamado tipo de contenido (Content-type) tiene el siguiente formato: Content-type: tipo / subtipo [;parmetro] La siguiente tabla incluye los tipos, subtipos y parmetros normalizados en el primer estndar de MIME.
Tabla 4.1 Tipos de contenido de un mensaje MIME
Tipo
text image audio video multipart text richtext gif jpeg basic mpeg h261
Subtipo
Parmetros
charset=ISO-8859-[1-9] / US-ASCII charset=ISO-8859-[1-9] / US-ASCII
mixed alternative parallel digest rfc822 partial external-body octet-stream PostScript ODA
boundary boundary boundary boundary
message
application
Por ejemplo, un mensaje MIME de texto que utiliza el conjunto de caracteres ISO-8859-1, vlido para la mayor parte de las lenguas de Europa occidental, dispone de un campo en la cabecera del mensaje que indica el tipo de contenido cuyo valor es el siguiente: Content-type: text/plain; charset=ISO-8859-1 El tipo de contenido por defecto corresponde a un mensaje RFC 822. Existen otros campos opcionales que se pueden utilizar en la cabecera de un mensaje MIME para indicar informacin adicional respecto al contenido de los mensajes. Algunos de estos campos son los siguientes: El campo de descripcin del contenido (Content-description) sirve para asociar alguna informacin descriptiva a un cuerpo de mensaje. El formato es el siguiente:
105
Content-description: descripcin El campo de identificador del contenido sirve para dotar a cada una de las partes del cuerpo de un mensaje de un identificador nico. El formato es el siguiente: Content-id: identificador El campo de longitud del contenido sirve para indicar la longitud del cuerpo de un mensaje. El formato es el siguiente: Content-length:longitud
5 Arquitectura de documentos
107
5.1 Necesidad de normalizacin de la arquitectura de documentos
Por medio de los sistemas de comunicacin electrnica actualmente en uso, es posible intercambiar documentos. Por ejemplo, el correo electrnico es uno de estos medios de comunicacin (vase el captulo 4). Sin embargo, el contenido de la informacin que se transmite no tiene por qu estar estructurado como un documento.
Formato local A Formato estndar de intercambio
Formato local C
Formato local B
Formato local D
Fig. 5.1 Arquitectura general para el intercambio de documentos
108
Asimismo, el fax, tan ampliamente extendido hoy en da, tambin es un sistema de comunicacin electrnica, pero tiene la desventaja de que el documento recibido no se puede reprocesar fcilmente. Si, por ejemplo, se quiere reutilizar en otro documento informacin recibida por fax, probablemente no habr ms remedio que reescribir su contenido, con el coste que esto supone. Para que el intercambio electrnico de documentos sea posible fuera de un entorno cerrado, se requiere un formato de intercambio estandarizado. Si se dispone de dicho formato, cada sistema de gestin y procesado de documentos slo tiene que preocuparse de conocer el formato estndar, con lo que los usuarios pueden seguir trabajando independientemente del estndar. Esto se ve grficamente en la figura 5.1. En los ltimos aos, se ha realizando un gran trabajo de normalizacin en este campo. Lo primero que se hizo fue definir un modelo para describir cmo se estructuran los documentos, al que se llam arquitectura abierta de documento (ODA, Open Document Architecture). Este modelo lleva asociado un formato de intercambio de documentos (ODIF, Open Document Interchange Format), el cual define la codificacin de los documentos cuando se intercambian. El estndar ODA se public por primera vez en 1989. Actualmente, se han realizando correcciones y extensiones de la norma, republicada en 1994. Posteriormente, se estn realizando nuevas extensiones, algunas de las cuales ya se han publicado en 1995.
5.1.1 Beneficios del uso de ODA Muchos son los beneficios obtenidos por el uso de un estndar de representacin e intercambio de documentos como ODA. Se pueden enumerar algunos de ellos: Resuelve el problema de equipos de suministradores diferentes, permitiendo la integracin de informacin procesable generada en sistemas diferentes. Protege inversiones ya realizadas en equipo de automatizacin de oficinas. Esto se realiza mediante la utilizacin de convertidores y la sustitucin gradual de los sistemas de procesado y gestin de documentos. Facilita la transferencia de documentos. Con ODA no hay prdida de informacin en cada transferencia. Se puede, adems, realizar un intercambio electrnico de documentos (X.400, protocolos de transferencia de ficheros, disquetes, ...). Permite tener un almacenamiento comn para todos los documentos. A este almacn podrn acceder sistemas presentes y futuros. Facilita la bsqueda de documentos, pues en un documento ODA se incluye informacin de gestin y estructura, aparte del contenido.
109
Posibilita el control del uso del documento, puesto que se definen documentos procesables, formateados y formateado-procesables. Asimismo, se pueden definir mecanismos de seguridad basados en derechos de acceso y cifrado (esto ltimo es una extensin aparecida en 1994). Facilita la produccin de formularios y documentos con estructura predefinida, mediante los estilos y las estructuras genricas.
5.2 Situacin del estndar ODA

Las primeras ideas sobre lo que hoy en da es el estndar ODA surgieron a principio de los ochenta y han ido evolucionando, y siguen hacindolo, hasta ahora. La norma ha sido, y est siendo, desarrollada por un comit conjunto de ISO/IEC e ITU-T, y su primera versin se public, como se ha dicho, en 1989. Aquella versin consta de 7 partes, que son: Parte 1: Introduccin y principios generales. Parte 2: Estructuras de documento. Parte 4: Perfil de documento. Parte 5: Formato de intercambio de documentos (ODIF). Parte 6: Arquitectura de contenido de caracteres. Parte 7: Arquitectura de contenido de grficos de puntos. Parte 8: Arquitectura de contenido de grficos geomtricos.
Ntese que no exista la parte 3. Ello es debido a razones del desarrollo original del estndar. Tambin se puede deducir de los ttulos de las diferentes partes que un documento ODA incluye cuatro conceptos bsicos, como son la estructura (vase apartado 5.3.2), el perfil (vase apartado 5.3.4), el formato de intercambio (vase apartado 5.5) y las arquitecturas de contenido (vase apartado 5.3.3). Despus de 1989 se ha seguido trabajando en mejorar diversos aspectos (fruto, entre otras cosas, del desarrollo de prototipos que validan los conceptos ODA), que han llevado a una republicacin de las 7 partes en 1994. Adems, se han desarrollado, o se estn desarrollado, otras nuevas partes que tratan otros tantos nuevos conceptos. Estas son: Parte 10: Especificacin formal de ODA (la primera versin se public en 1991, y una segunda ha sido publicada en 1995). Parte 3: Interfaz abstracto para la manipulacin de documentos ODA (publicada en 1995). Se trata con ms detalle en el captulo 7, pues tiene mucho que ver con acceso remoto a documentos.
110
Parte 9: Arquitectura de contenido de audio (publicada en 1995). Especifica cmo poder incluir informacin audio en documentos ODA. Parte 11: Estructuras tabulares y layout de tablas (publicada en 1995). Especifica caractersticas complejas para tablas. Parte 12: Identificacin de fragmentos de documento (publicada en 1995). Al igual que la parte 3, se explica en el captulo 7. Parte 14: Relaciones temporales y estructuras no lineales (a publicar en 1996). Trata la posibilidad de aadir caractersticas de hiperdocumentos a los documentos ODA.
5.3 Documentos ODA

El estndar ODA define una representacin de documentos con el objetivo de intercambiarlos entre sistemas de procesado de documentos heterogneos. Permite especificar documentos procesables (es decir, revisables) y/o formateados. Actualmente, ODA permite contenidos representados como caracteres, grficos o imgenes de puntos (raster), grficos geomtricos y, recientemente publicado en 1995, audio. Informacin de color es tambin posible en la versin de 1994. La arquitectura ODA define un documento como un conjunto de elementos, llamados constituyentes (constituents), formados por una serie de atributos especificados por un nombre y un valor. Los atributos de un constituyente representan propiedades de ese constituyente o una relacin con otros constituyentes. El estndar enumera qu atributos se pueden especificar para cada tipo de constituyente y sus posibles valores. Los tipos de constituyentes ms comunes son: el perfil de documento (vase apartado 5.3.4), estilos (vase apartado 5.3.2), porciones de contenido (vase apartado 5.3.3) y componentes (vase apartados 5.3.1 y 5.3.2).
5.3.1 Estructuras lgica y fsica En una primera visin, un documento tiene dos estructuras: Estructura lgica: Subdivide el documento en captulos, secciones, prrafos, apndices, etc. Estructura de aspecto o fsica (layout): Da su disposicin en el medio de representacin; es decir, pginas, reas en pginas, mrgenes, separaciones, etc.
111
El modelo de arquitectura de ODA se basa en un enfoque declarativo, es decir, las estructuras (sean lgicas o fsicas) no se expresan implcitamente por medio de caracteres de control dentro del contenido del documento, sino que se dan explcitamente por medio de una jerarqua de componentes (un caso particular de constituyentes), formando una estructura en rbol. Adems de las relaciones jerrquicas entre componentes, tambin existen relaciones no jerrquicas, como referencias a notas a pie de pgina, por ejemplo. Finalmente, se pueden expresar por medio de atributos otras muchas caractersticas, como tamao, dimensiones, alineado, etc. Como se ha dicho, cada una de las dos estructuras, lgica y fsica, se expresa por medio de una jerarqua de componentes. Estos componentes pueden ser objetos o clases de objeto. Los objetos pueden ser de tipos diferentes. Los tipos de objeto proporcionados por ODA para construir la estructura lgica son: Raz lgica de documento: Primer nivel de la estructura. Objeto lgico compuesto: No tiene contenido real, sino que contiene otros objetos compuestos o lgicos. Ejemplos seran captulos o secciones. Objeto lgico bsico: El nivel ms bajo de la jerarqua (por ejemplo, un prrafo). Tiene asociadas las porciones de contenido del documento, como texto o imgenes.
Anlogamente, para la estructura fsica: Raz fsica de documento: Mximo nivel. Conjunto de pginas. Pgina: rea de dos dimensiones sobre la que se posiciona y representa el contenido de un documento. Marco (frame): rea rectangular de una pgina. Su contenido se puede formatear, lo que produce bloques dentro de los marcos. Bloque: Su contenido es de un solo tipo. Por ejemplo, slo texto o slo grficos. Son los nicos objetos fsicos que tienen asociadas porciones de contenido directamente.
5.3.2 Estructuras genrica y especfica. Estilos Los objetos con un conjunto de propiedades comunes se conocen como instancias de una determinada clase de objeto. Un documento puede contener cualquier nmero de clases de objetos lgicos y/o fsicos, que forman su estructura genrica.
112
Las clases de objetos se pueden utilizar para agrupar caractersticas de una serie de objetos (factorizacin) y para describir las relaciones permitidas entre ellos, dando de esta manera una referencia para crear nuevos objetos. Las porciones de contenido (vase apartado 5.3.3) se pueden asociar tambin con clases de objetos bsicos (por ejemplo, contenido a imprimir al principio de cada pgina, como un logotipo). La estructura real (lgica o fsica) de un documento concreto se llama estructura especfica y consta de un conjunto de objetos enlazados con relaciones de subordinacin que forman la estructura en rbol mencionada en 5.3.1. Tambin existe la estructura genrica, que es un conjunto de descripciones de clase de objeto, que constan, bsicamente, de reglas de construccin que ayudan a obtener la estructura especfica. Otro tipo de constituyentes que puede haber en un documento son los estilos, cuyos atributos se utilizan para dar determinadas caractersticas a los objetos con los que estn asociados. Para ello, los estilos de documento definen cmo mapear estructuras lgicas sobre estructuras fsicas. Hay dos tipos de estilos: Estilos fsicos (layout styles): Estn asociados a constituyentes lgicos. Sus atributos dirigen el proceso de creacin de la estructura especfica fsica. Un ejemplo de estos atributos es el offset. Estilos de presentacin (presentation styles): Estn asociados a constituyentes bsicos. Sus atributos guan la apariencia del contenido en el medio de presentacin; es decir, describen objetos fsicos. Un ejemplo de estos atributos es el espaciado de lnea.
5.3.3 Contenidos El contenido de un documento, incluido en objetos llamados porciones de contenido, est asociado directamente con sus objetos bsicos, es decir, aqullos sin objetos subordinados (las hojas del rbol). Un objeto bsico y su contenido deben corresponder a una de las arquitecturas de contenido definidas en el estndar, las cuales se detallan posteriormente. Una porcin de contenido se puede asociar a un objeto lgico bsico, a un objeto de layout bsico, o a ambos. En el ltimo caso, pertenece a la vez a la estructura especfica lgica y a la estructura especfica de layout. La figura 5.2 muestra la estructura especfica de un documento formateadoprocesable muy simple, que consta de una portada y un cuerpo con 3 prrafos. El segundo prrafo se imprime al final de una pgina y al principio de la siguiente. Como ya se ha visto, se definen arquitecturas de contenido para cada tipo de contenido, las cuales no forman parte de las estructuras de documento, sino que la arquitectura de documento proporciona un interfaz uniforme entre la estructura y el contenido (los contenidos estn asociados solamente a los
113
objetos bsicos de la estructura). Por ahora, en ODA se han definido las siguientes arquitecturas de contenido: Caracteres (character content architecture). La informacin de contenido se representa como una cadena de caracteres combinando caracteres grficos, el carcter espacio y funciones de control. Se utiliza la codificacin de caracteres definida en el estndar ISO 2022. Grficos de puntos, o no estructurados (raster graphics content architecture). En la primera versin de ODA slo se consideraron grficos en blanco y negro, pero en la de 1994 ya existe la posibilidad de intercambiar grficos en color. La codificacin de puntos sigue los estndares ms habituales, como fax Grupo III y fax Grupo IV (recomendaciones T.4 y T.6), adems de simple bitmap. Grficos geomtricos (geometric graphics content architecture). Sigue las reglas definidas por el estndar CGM (Computer Graphics Metafile). Audio (audio content architecture). Publicada en 1995, especifica cmo usar, dentro de documentos, los diferentes formatos de codificacin de audio.
raz lgica
cabecera estructura lgica ttulo autor prrafo
cuerpo
prrafo
prrafo
contenido
contenido
contenido
contenido
contenido
contenido
bloque
bloque
bloque
bloque
bloque
bloque estructura de layout
pgina frontal
pgina recto
pgina verso
page set de cabecera
page set del cuerpo
raz de layout
Fig. 5.2 Ejemplo de estructura especfica lgica y de layout
114
El estndar ODA puede extenderse fcilmente por medio del interfaz entre la estructura de documento y el contenido de documento. Las arquitecturas de contenido definidas por ahora pueden ser fcilmente ampliadas sin tener que modificar, slo extender, el estndar actual. Esto es lo que se ha hecho por ejemplo, para aadir contenido audio. Es importante resaltar, por tanto, que las estructuras de documento son totalmente independientes de las arquitecturas de contenido.
5.3.4 Un documento ODA La figura 5.3 muestra los componentes del modelo de documento de ODA. Un documento, formado por estructuras especficas y porciones de contenido, se ve como una instancia de una clase de documento descrita en la descripcin de clase de documento. Esta consta de tres componentes:
Perfil de documento
Clases de objetos lgicos
Porciones contenido
Porciones contenido
Clases de objetos de layout
Estructura lgica genrica Estructura lgica especfica
Estructura de layout genrica Estructura de layout especfica Porciones contenido
Objetos lgicos
Porciones contenido
Objetos de layout
Estilos de layout
Estilos de presentacin
Fig. 5.3 Constituyentes de un documento ODA
Estructura lgica genrica: Es un conjunto de descripciones de clase de objeto lgico, que constan, bsicamente, de reglas de construccin que permiten saber cmo calcular los valores de los atributos. Adems, pueden existir porciones de contenido genrico, que ayudan a crear contenido predefinido.
115
Estructura de layout genrica: Similar a lo anterior, pero respecto al layout. Estilos de documento: Estilos de layout y estilos de presentacin (vase apartado 5.3.2).
Finalmente, todos los atributos que especifican propiedades de un documento completo estn contenidos en un constituyente llamado perfil de documento. Es decir, el perfil de documento es un conjunto de atributos que especifican las caractersticas de un documento visto como algo compacto e independiente. Incluye informacin para procesar el documento. Un perfil de documento se puede intercambiar o almacenar sin el cuerpo del documento. Aparte de los atributos que indican la estructura ODA del documento, existen atributos de gestin como ttulo, palabras clave, fecha de creacin, autores, referencias a otros documentos, etc.
5.4 Procesado de documentos ODA

El estndar define tres clases de arquitectura de documento: Formateado: Esta forma de intercambio slo permite reproducir el documento tal como se envi. Bsicamente, lo que se transmite es la estructura especfica de layout y el contenido formateado. Procesable: Permite que el receptor pueda procesar el documento recibido. En este caso, se transmite la estructura lgica y el contenido procesable. Tambin podra transmitirse la definicin de clase de documento. Por tanto, para reproducir el documento, deber generarse previamente el layout. Formateado-procesable: Ahora se transmiten todos los componentes de un documento, lo que permitir su procesado y reproduccin.
El modelo de procesado de documentos ODA define tres diferentes procesos que se pueden realizar sobre un documento (vase la figura 5.4): Edicin: Procesado (creacin o correccin) de la estructura lgica especfica y del contenido. Layout: Consiste en la creacin de una estructura de layout especfica, a partir de una estructura lgica, y el formateado del contenido. Materializacin (imaging): Materializacin o visualizacin del documento en un medio de presentacin (papel, pantalla, ...). Utiliza los estilos de presentacin y la estructura de layout especfica.
116
Proceso de edicin Documento procesable
Proceso de layout
Documento formateado Proceso de edicin
Proceso de layout
Documento formateado procesable Proceso de materializacin
Documento material
Fig. 5.4 Tipos de procesos y clases de arquitectura de documento
5.5 Formato de intercambio de documentos

En ISO 8613 se define el formato de intercambio ODIF (Open Document Interchange Format), es decir, la manera en que se ha de generar una cadena de bits para que exprese la informacin de la descripcin de un documento de acuerdo con ODA. ODIF es un conjunto de definiciones ASN.1 correspondientes a todos los constituyentes ODA, de acuerdo con las reglas ASN.1 de ISO 8824. Se utiliza la sintaxis de transferencia de ISO 8825 para codificar y decodificar estructuras de datos, siguiendo las definiciones de ODIF, en y desde una secuencia de octetos.
5.6 Perfiles de aplicacin de documentos ODA

El estndar ODA es complejo y, dependiendo del tipo de documento, a veces no son necesarias todas las caractersticas del estndar. Para simplificar las aplicaciones ODA, se define el concepto de perfil de aplicacin de documento (DAP, Document Application Profile), que es la especificacin de un subconjunto de las caractersticas disponibles en el estndar ODA, adecuadas para un conjunto de aplicaciones determinado. Los tres perfiles aprobados para aplicaciones de procesado e intercambio de documentos son FOD011, FOD026 y FOD036. Estos perfiles estn definidos de forma jerrquica, de los cuales
117
FOD011 es el perfil de menor funcionalidad y FOD036 el de mayor funcionalidad. Adems, existen dos perfiles para aplicaciones de procesado e intercambio de imgenes de gran formato. Estos perfiles son el FOD112 y el FOD126. Por lo dicho anteriormente sobre compatibilidad, un documento que es conforme a uno de estos DAP lo es tambin a cualquiera de los que le siguen en esta jerarqua de DAP, as como al estndar base. Los DAP fueron inicialmente desarrollados por EWOS (European Workshop for Open Systems), NIST (National Institute of Standards, USA) y el entonces CCITT, entre otros. Desde un punto de vista europeo, algunos DAP definidos por EWOS estn siendo adoptados por el CEN/CENELEC (organismo de normalizacin europeo responsable de los estndares funcionales), puesto que los DAP son estndares funcionales de ODA. De cualquier forma, los DAP definidos por los diferentes organismos han convergido en una serie de DAP internacionales. A travs de PAGODA (Profile Alignment Group for ODA), un grupo formado por todos los workshops continentales, se han definido lo que se llaman ISP (International Standardized Profiles), que han sido adoptados y aprobados por ISO en 1992. Estos ISP contienen los DAP inicialmente desarrollados por los workshops y alineados por PAGODA.
5.6.1 FOD011 FOD011, contenido de caracteres bsico (Basic Character Content), es el DAP de nivel 1. Este perfil soporta documentos tipo carta o informe, generados con sistemas bsicos: documentos con estructuras lgica y fsica simples, y con contenido slo de caracteres. El perfil FOD011 permite: Las 4 estructuras (lgica especfica, de layout especfica, lgica genrica y de layout genrica) Pginas primera, recto y verso con cabecera, cuerpo y pie de pgina Pginas con numeracin automtica y una sola columna de contenido Texto con caracteres de control y con estructura lgica lineal Caractersticas de formateado y presentacin como tabulaciones, mrgenes, separaciones de prrafos, control de lneas viudas y hurfanas, etc.
5.6.2 FOD026 FOD026, modo mixto extendido (Extended Mixed Mode), es el DAP de nivel 2. Este perfil soporta documentos generados con procesadores de texto: documentos con estructuras lgica y de layout ms complejas, y con contenido de caracteres y grficos. Este es el perfil ms utilizado actualmente. El perfil FOD026 permite: Todas las caractersticas del perfil FOD011 Multicolumnas periodsticas y sincronizadas Notas al pie de pgina
118
Segmentos numerados formando estructura lgicas en forma de rbol Grficos raster y vectoriales
5.6.3 FOD036 FOD036, modo mixto mejorado (Enhanced Mixed Mode), es el DAP de nivel 3. Este perfil soporta documentos, generados con sistemas de edicin de publicaciones (Desktop publishing): documentos con estructuras lgica y de layout an ms complejas, y con contenido de caracteres y grficos. El perfil FOD036 permite: Todas las caractersticas del perfil FOD026 Ttulos en pasajes y segmentos numerados Frases como agrupacin de caracteres Figuras con ttulo y descripcin Tablas Listas numeradas y no numeradas Referencias, con contenido de caracteres derivado total o parcialmente de otra parte del documento
5.6.4 FOD112 Este perfil soporta documentos consistentes en imgenes raster. El perfil FOD112 permite: Documentos con informacin de gestin en el perfil Imgenes raster en blanco y negro en los formatos CCITT T.4 (fax grupo 3), T.6 (fax grupo 4), tiled (mosaico) y bitmap Una imagen por pgina Tantas pginas, y de tamao hasta A0, como se desee
5.6.5 FOD126 Este perfil soporta documentos consistentes en imgenes raster, imgenes vectoriales o caracteres. El perfil FOD126 permite: Todas las caractersticas del perfil FOD112 Imgenes raster, imgenes vectoriales, y caracteres Anotaciones como revisin a un original
119
5.7 Otros estndares de documentos: SGML
5.7.1 Principios bsicos En pocas anteriores al procesado automtico de documentos, los editores de publicaciones utilizaban el marcaje (markup) manual de los manuscritos con una serie de instrucciones especficas, tal como se puede ver en la figura 5.5, que eran utilizadas posteriormente, en el momento de la composicin, con el fin de crear el formato y la apariencia final deseados. Se puede apreciar que este tipo de marcaje presenta las siguientes caractersticas: El marcaje se encuentra en el documento, pero separado del contenido. El marcaje se suele realizar marcando el inicio y el fin del contenido sobre el que se aplica.
negrita/20 pt. 2 cm 2,5 cm
2,5 cm cursiva 2 cm
2,5 cm 4 cm 8 cm
subrayado
4 cm
Fig. 5.5 Documento con marcaje manual
Los primeros sistemas computerizados utilizaron esta idea de aadir marcaje (markup) especfico a los manuscritos electrnicos. Este marcaje ya consista en instrucciones de procesado, y que tambin se hallaban separadas del documento en s, pero en el formato especfico del lenguaje del programa utilizado para el formateado del documento. El estndar de lenguaje de marcaje generalizado (SGML, Standard Generalized Markup Language) [SGM0186] [SGM0288] apareci con la intencin de normalizar el marcaje de documentos. Por este motivo, SGML se basa en los siguientes principios bsicos:
120
SGML describe la estructura de un documento as como atributos de formateado, pero no especifica el procesado concreto a realizar sobre el mismo. SGML es riguroso, es decir, cada tipo de documento puede ser definido de manera formal, y de modo que las tcnicas informticas tambin puedan ser utilizadas para el procesado de los documentos.
SGML es un lenguaje, en el sentido de un lenguaje informtico, para la descripcin de la estructura de documentos electrnicos y su codificacin mediante caracteres ASCII. SGML utiliza marcaje general, independiente del sistema, entorno o aplicacin, para la descripcin de la estructura de un documento. SGML es un lenguaje flexible que permite la representacin de las caractersticas de un documento. Como tal lenguaje, no tiene limitaciones en las caractersticas que permite representar, sino que son los entornos reales existentes quienes imponen las limitaciones. SGML es principalmente un medio para la definicin y descripcin de la estructura lgica especfica de un documento. Las especificaciones de los estilos, que dan la apariencia visual del documento, tambin se pueden representar utilizando una sintaxis SGML llamada instancia de especificacin de salida de formateado (FOSI, Formatting Output Specification Instance).
5.7.2 Documento SGML Un documento SGML se puede ver como una jerarqua de elementos formando una estructura lgica especfica en forma de rbol a partir de un nodo principal, el cual da forma al documento. En los extremos del rbol, se encuentra el contenido, que puede ser de cualquier tipo, incluso sin representacin estndar. Todo documento SGML puede estar formado por: Definicin de la estructura lgica genrica a seguir Definicin de los estilos aplicables Contenido con estilos y con estructura lgica especfica
Adems de todos estos elementos, tambin se debe tener en cuenta la manera cmo se introduce toda la informacin dentro del documento.
5.7.3 Marcaje A un documento SGML es necesario: Dotarlo de una estructura lgica.
121
Dotar de formateado al contenido de informacin.
Por este motivo, al contenido de los datos se le aade una informacin general, independiente del sistema, entorno o aplicacin. Esta informacin se introduce mediante el marcaje, con lo se puede decir que cualquier documento SGML consta de dos tipos de informacin: datos y marcaje. El marcaje de un trozo de contenido consiste en un marcador inicial (start-tag), de la forma <tag_inicio>, al inicio y un marcador final (end-tag), de la forma </tag_final>, al final, los cuales definen las caractersticas de la parte del documento SGML que se encuentra entre ambos marcadores.
5.7.4 Estructura Dentro de un documento, el marcaje describe su estructura especfica y los atributos para su formateado, pero no el proceso a aplicar sobre l. Debido a esto, para cada tipo de documento se debe definir de manera formal el modelo que tiene que seguir su estructura lgica. Una vez definido el modelo, ste puede ser utilizado para validar de forma rigurosa la estructura especfica de un documento. Para cada tipo de documento SGML, las reglas que definen las estructuras permitidas en un documento se deben especificar formalmente. Esto se realiza en la definicin de tipo de documento (DTD, Document Type Definition). Los DTD son las especificaciones que dan las reglas de cmo estructurar el documento desde el punto de vista lgico. Es decir, un DTD especifica la estructura lgica genrica. Todo documento SGML tiene asociado un DTD, el cual define qu elementos lgicos pueden o deben encontrarse, en qu orden, en qu contexto jerrquico y cules son los marcadores a utilizar. Cabe destacar que los DTD no estn estandarizados, por lo que se debe definir un DTD para cada tipo de documento a utilizar.
5.7.5 Estilos Para cada tipo de documento SGML, las reglas para el formateado del contenido tambin se pueden definir formalmente. Estas reglas se agrupan en estilos, los cuales se especifican en formato FOSI, antes mencionado. Una especificacin FOSI permite definir las caractersticas de los estilos, que son aquellas que dan una apariencia visual al documento, como pueden ser los fuentes, los espaciados de lnea, los mrgenes, etc. Cualquier documento puede tener asociado una especificacin FOSI, la cual define qu estilos pueden encontrarse, sus caractersticas, y cules son los marcadores a utilizar.
122
5.7.6 Contenido Todo documento, y por lo tanto tambin un documento SGML, tiene un contenido. En un documento SGML, tal y como se ha descrito anteriormente, a este contenido se le puede asociar una serie de caractersticas, tanto desde el punto de vista lgico como desde el punto de vista de apariencia visual. Estas caractersticas se aplican al contenido utilizando marcadores, los cuales han de seguir unas reglas que vienen fijadas asociando un DTD y, opcionalmente, una especificacin FOSI a cada documento SGML. Debido a esto, el contenido de un documento SGML puede ser de cualquier tipo, y la nica restriccin que existe es la que le fije su DTD asociado. Lo mismo sucede con los atributos de formateado, que pueden ser de cualquier tipo, pero que en un documento SGML vienen restringidos por su especificacin FOSI asociada.
5.7.7 Ejemplo de documento SGML Como ejemplo se puede tomar la siguiente codificacin de la estructura lgica especfica de un documento utilizando SGML:
... <times_9><para> <paratitle><times_12><bold>Ttulo de la seccin</bold></times_12><paratitle> <parabody>Este es un texto de ejemplo para ver cmo se puede representar en SGML un documento. Se ve que es un formato ASCII que permite texto en <bold>negrita</bold>, <italics>cursiva</italics> o <uline>subrayado</uline> utilizando marcadores iniciales y finales. </parabody></para><para><parabody> Este es otro prrafo. </parabody></para></times_9> ...
En este fragmento de documento SGML se puede apreciar el contenido, as como la existencia y formato de los marcadores iniciales y los marcadores finales, todos ellos en texto US-ASCII. A su vez, tambin se ve que existen dos tipos diferenciados de marcadores: Los que forman la estructura del documento: paratitle, parabody y para. El significado lgico de estos marcadores se encuentra en el DTD asociado al documento. Los que dan caractersticas de apariencia visual: times_12, times_9, bold, italics y uline. A su vez, paratitle, parabody y para tambin pueden implicar ciertas caractersticas visuales. El significado, desde el punto de vista de aspecto final del documento, de estos marcadores se encuentra en la especificacin FOSI asociada al documento.
A continuacin se presenta un posible aspecto del texto una vez formateado:
123
Ttulo de la seccin
Este es un texto de ejemplo para ver cmo se puede representar en SGML un documento. Se ve que es un formato ASCII que permite texto en negrita, cursiva o subrayado utilizando marcadores iniciales y finales. Este es otro prrafo.

Aplicaciones Distribuidas Abiertas

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Aplicaciones Distribuidas Abiertas

Загружено:

Авторское право:

Доступные форматы

6 El servicio de directorio

Aplicaciones distribuidas abiertas

Punto de acceso Usuario DUA El Directorio

Fig. 6.1 Acceso al Directorio

Fig. 6.2 Visin global del Directorio

Aplicaciones distribuidas abiertas

Tabla 6.1 Diferentes tipos de atributos X.500

entrada de objeto entrada de alias

AA AA AAAA AAAAAAAAAA AAAA AAAAAAAAAAAA AA

AA AAAA AAAAAA AAAAAA

Fig. 6.3 Estructura del DIT y sus componentes

atributo distintivo (RDN) Entrada atributo

Fig. 6.4 Estructura de una entrada y del RDN asociado

Aplicaciones distribuidas abiertas

OU=DAC CN=John Jones

Fig. 6.5 Ejemplo de DIT

CN=Jos Fernndez PRMD

CN=Laser Printer PRMD

Fig. 6.6 Ejemplo de dominios de gestin

Dependiendo de las autoridades y su naturaleza, se distinguen dos tipos de dominios de gestin:

Aplicaciones distribuidas abiertas

La figura 6.6 muestra un ejemplo de estructuracin del DIT en dominios

Aplicaciones distribuidas abiertas

DSA1 ADMD DSA1 C=ES

raz ADMD C=US DSA1

Fig. 6.7 Ejemplo de DIB con distribucin funcional y organizativa

peticin Usuario DUA respuesta DSA

Fig. 6.8 Interaccin simple

Aplicaciones distribuidas abiertas

peticin Usuario DUA indireccin (a A) peticin DSA A DSA C

Fig. 6.9.a Interaccin con un nivel de indireccin

peticin Usuario DUA 2) indireccin (a B) DSA C

Fig. 6.9.b Interaccin con dos niveles de indireccin

peticin Usuario DUA respuesta DSA

peticin DSA respuesta

Fig. 6.10 Interaccin con encadenamiento simple

peticin Usuario DUA respuesta DSA

res pue sta

Fig. 6.11 Interaccin con encadenamiento mltiple

Aplicaciones distribuidas abiertas

6.2 Servicio de nombres de Internet

servidor nombres servidor nombres servidor nombres

Fig. 6.12 Visin global de DNS

Aplicaciones distribuidas abiertas

Fig. 6.13 Jerarqua de dominios de Internet

Aplicaciones distribuidas abiertas

xxx zona upc.es

Fig. 6.14 Ejemplo de zonas en el espacio de nombres de Internet

7 Gestin e intercambio de documentos y ficheros en sistemas distribuidos

7 Gestin e intercambio de documentos y ficheros en sistemas distribuidos

7.2 Manipulacin remota de documentos: DTAM-DM

Aplicaciones distribuidas abiertas

7 Gestin e intercambio de documentos y ficheros en sistemas distribuidos

Tabla 7.1 Operaciones proporcionadas por DTAM-DM

Operacin Nivel de documento

146 Descartar (Discard)

Aplicaciones distribuidas abiertas

Descarta las manipulaciones hechas sobre un documento

Indica principio y final de un grupo de operaciones

7 Gestin e intercambio de documentos y ficheros en sistemas distribuidos

Tabla 7.2 Operaciones disponibles en los perfiles AOD

Perfiles AOD Operacin Nivel de documento

148 Abrir (Open) Cerrar (Close) Guardar (Save) Descartar (Discard)

Aplicaciones distribuidas abiertas