UPC - Aplicaciones Distribuidas Abiertas

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.
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.
16
Aplicaciones distribuidas abiertas
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.
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.
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.
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.
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
Nivel de
aplicacin
Proceso
Aplicacin
Usuario
Protocolo 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
Proceso
Aplicacin
Usuario
AE
AE
Protocolos de
aplicacin
UE
ASE
1
...
ASE
n
(APDU)
UE
ASE
1
...
ASE
n
Conexin de presentacin
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
Proceso
Aplicacin
Usuario
AE
AE
UE
ASE
UE
ASE
Protocolo de
aplicacin
ASE ASE
ROSE
ROSE
RTSE
RTSE
ACSE
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

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
A-P-ABORT.indication
Proveedor ACSE
Usuario ACSE
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
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
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
RT-P-ABORT.indication
Proveedor RTSE
Usuario RTSE
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
APDU
RTORQ
RTOAC
RTORJ
----RTAB
RTAB
Primitiva ACSE
A-ASSOCIATE.request/indication
A-RELEASE.request/indication
A-RELEASE.response/confirmation
A-ABORT.request/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
Usuario RTSE
P-ACTIVITY-START .
request
RT-OPEN.request
P-ACTIVITY-START .
indication
P-DATA.request
P-DATA.indication
P-SYNC-MINOR.
request
P-SYNC-MINOR.
indication
P-ACTIVITY-END.
request
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
RT-TRANSFER.indication/confirmation
APDU
--RTTR
-----
Primitiva Presentacin
P-ACTIVITY-START.request/indication
P-DATA.request/indication
P-MINOR-SYNCHRONIZE
P-ACTIVITY-END
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
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
Realiza RO
AE
Clase 1
AE
Invocacin
Respuesta
Invocacin
Respuesta
Invocaciones
Clase 2
Respuestas
Invocaciones
Clase 3
Error
Invocaciones
Clase 4
Clase 5
Resultado
Invocaciones
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
ejecuta las
operaciones hijas
enlazadas
invocacin de
operacin padre
AE
invocacin de
operacin hija
ejecucin de
operacin
padre
invocacin de
operacin hija
ejecuta la
operacin padre
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
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
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

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
RO-REJECT-P.indication
Proveedor ROSE
Usuario ROSE
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

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
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
Nivel de
aplicacin
Servidor
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)
Cliente
1)
3)
Servidor
3)
2)
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
AE
UE
UE
ASE
cliente
Nivel de
aplicacin
Protocolo de
accesso
ASE
serv.
ROSE
ROSE
RTSE
RTSE
ACSE
Nivel de
presentacin
e inferiores
ACSE
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
Nivel de
aplicacin
Nivel de
presentacin
y niveles
inferiores
Servidor
Entidad de
Entidad de
aplicacin Protocolo de aplicacin
1)
1)
acceso
ASE (1)
ASE (1)
Servidor
Entidad de
aplicacin Protocolo de
2)
sistema
ASE (2)
Entidad de
aplicacin
2)
ASE (2)
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
Descripcin
Listar (List)
Leer (Read)
Escribir (Write)
Modificar (Modify)
Copiar (Copy)
Mover (Move)
Buscar (Search)
Crear (Create)
Borrar (Delete)
Reservar (Reserve)
Notificar (Notify)
Abandonar (Abandon)
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
Interfaz de
aplicacin B
Cliente A
Protocolo de acceso A
Servidor A
Cliente B
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
Puerto
simtrico
Objeto
servidor
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)
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
Notacin
RO
CompiladorEnlazador
Ejecutable
cliente
CompiladorEnlazador
Ejecutable
servidor
Compilador
Notacin-RO
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
--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
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
...
ASE
ROSE
ACSE
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
usomensajera
enva
recibe
Administradormensajera
enva
recibe
Entornomensajera
prueba
registra
adminmensajera
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
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}
{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 ::=
--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
UE
usomensajera
Nivel de
aplicacin
adminmensajera
Protocolo entre
administradores y
sistema-mensajera
usomensajera
ROSE
adminmensajera
ROSE
ACSE
ACSE
Nivel de
presentacin
Usuario de
sistema-mensajera
Sistema-mensajera
UE
UE
usomensajera
Nivel de
aplicacin
Protocolo entre
usuarios y
sistema-mensajera
usomensajera
ROSE
ROSE
ACSE
Nivel de
presentacin
ACSE
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
agenteadministrador
entrega
sistemamensajera
transfiere
transfiereprueba
usotransferencia
admintransferencia
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
adminmensajera
entornomensajeria
agenteusuario
usomensajera
agenteusuario
agenteadministrador
sistemamensajera
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}
::= 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
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 ::= {
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.
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.
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
MTA
MS
UA
Usuario
UA
Usuario
UA
MTA
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
destinatario
MTA
envo
entrega
UA
UA
transferencia
originador
UA
MTA
MS
envoindirecto
destinatario
MTA
MS
envo
UA
entrega
MTA
recuperacin
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 2
ADMD 1
UA
UA
MS
MTA
UA
MTA
MTA
MS
MTA
ADMD 3
UA
MTA
UA
MTA
UA
UA
PRMD 2
MTA
UA
UA
MS
MTA
UA
UA
MTA
MS
UA
UA
UA
UA
PRMD 3
PRMD 1
Pas A
Pas B
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
Envo
Entrega
Usuario-MTS
Entrega
MTS
Administracin
Usuario-MTS
Administracin
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).
Recuperacin
Envo-indirecto
Administracin
Usuario-MS
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
P3
MTS
abstract-service
MTA
provider
P1
P1
MTA
Transferencia
MTA
Transferencia
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
UE
MSSEc MDSEc MASEc
Nivel de
aplicacin
MSSEs MDSEs MASEs
Protocolo P3
ROSE
ROSE
ACSE
Nivel de
presentacin
ACSE
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
UE
MSSEc MRSEc MASEc
Nivel de
aplicacin
MSSEs MRSEs MASEs
Protocolo P7
ROSE
ROSE
ACSE
Nivel de
presentacin
ACSE
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
UE
MTSE
Nivel de
aplicacin
MTSE
Protocolo P1
RTSE
RTSE
ACSE
ACSE
Nivel de
presentacin
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
MTA
MTS
Entregamensaje Usuario-MTS
Tranferenciamensaje
MTA
Destinatarios
MTA
Transferenciainforme
MTA
(no-entrega)
Usuario-MTS
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:

-
Operaciones abstractas del puerto de entrega:

-
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.
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
UA
Recuperacin
Envo-indirecto
Administracin
P3
MS
Entrega
Envo
Administracin
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
Origen
Recepcin
Recepcin
Usuario
IPMS
Gestin
Usuario
Gestin
Fig. 4.13 Entorno IPMS
Las operaciones abstractas de cada uno de los puertos son:

-
operaciones abstractas del puerto origen:

-
operaciones abstractas del puerto recepcin:

-
originar sonda
originar mensaje interpersonal
originar notificacin de 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
Sistema intermedio
Cola correo
de salida
Agente
de usuario
Mensajes
en la cola
Sistema receptor
Cola correo
de salida
Emisor
SMTP
Receptor
SMTP
Mensajes
en la cola
Emisor
SMTP
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
Codificacin
8 bits a 7 bits
SMTP 8 bits
(RFC 1426)
SMTP 7 bits
(RFC 821/822)
Contenido
mensaje
MIME
Usuario
Decodificacin
7 bits a 8 bits
Internet
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
Subtipo
text
text
richtext
image
gif
jpeg
audio
basic
video
mpeg
h261
multipart
mixed
alternative
parallel
digest
message
rfc822
partial
external-body
application
octet-stream
PostScript
ODA
Parmetros
charset=ISO-8859-[1-9] / US-ASCII
charset=ISO-8859-[1-9] / US-ASCII
boundary
boundary
boundary
boundary
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
107
5 Arquitectura de documentos
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 C
Formato local A
Formato estndar
de intercambio
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
cuerpo
estructura
lgica
ttulo
autor
prrafo
prrafo
prrafo
contenido
contenido
contenido
contenido
contenido
contenido
bloque
bloque
bloque
bloque
bloque
bloque
estructura
de layout
pgina frontal
pgina recto
page set
de cabecera
pgina verso
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 de layout genrica
Estructura lgica especfica
Estructura de layout especfica

Porciones
contenido
Objetos
lgicos
Porciones
contenido
Estilos de
layout
Objetos 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.
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).
115
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
Proceso de layout
Documento
procesable
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
-

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
-

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.
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.
126
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
entrada de
alias
AA
AA
AAAA
AAAAAAAAAA
AAAA
AAAAAAAAAAAA
AA
AA
AAAA
AAAAAA
AAAAAA
AAAAAAAA
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAA
AAAAAAAA
AAAAAAAA
AAAA
tipo
valor(es)
AAAAAAAA
AAAAAAAA
AAAA
AAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAA
AAAAAAAA
Atributo
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
atributo
AAAA
AA
AA
AAAA
AA AAAA
AAAA
AA
AAAAAA
AAAAAA
AAAA
AA
AAAA
AA
AAAAAA
atributo
AAAA
AAAAAAAAAAAAAAAAAA
AAAA
AAAA
AAAA
AAAA
A
AAAA
AAAAAAAA
AAAA
AAAA
AAAA
tipo
valor(es)
AAAA
AAAA
AAAA
AAAAAA
AAAAAAAA
AAAA
AAAA
AAAA
AAAAAAAAAAAAAAAAAAAA
AAAAA
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
L=Los Angeles
O=UPC
OU=CTT
OU=DAC
O=Graphic Services
CN=John Jones
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
C=US
C=ES
ADMD
ADMD
PRMD
L=Los Angeles
O=UPC
OU=DAC
OU=CCT
O=Graphic Services
CN=John Jones
CN=Mquina Fax
CN=Jos Fernndez
CN=Laser Printer
PRMD
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
raz
ADMD
DSA1
ADMD
C=ES
C=US
DSA1
DSA2
DSA1
O=UPC
L=Los Angeles
PRMD
OU=CCT
O=Graphic Services
OU=DAC
CN=John Jones
PRMD
CN=Mquina Fax
CN=Jos Fernndez
DSA1
CN=Laser Printer
PRMD
DSA1
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
DSA
respuesta
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
DSA
C
DUA
indireccin
(a A)
peticin
DSA
A
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
DSA
B
peticin
Usuario
DUA
2) indireccin
(a B)
DSA
C
pet
ind
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
Usuario
DUA
peticin
DSA
DSA
respuesta
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
DUA
DSA
ta
ues
resp
peticin
Usuario
ici
DSA
respuesta
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
Usuario
resolver
servidor
nombres
servidor
nombres
servidor
nombres
resolver
Usuario
servidor
nombres
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
deneb
AC
orion
sirius
(otros)
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
"."
COM
zona root
EDU
ARPA
ES
GOV
(otros)
xxx
xxx
UPC
xxx
(otros)
zona upc.es
diable
(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 Gestin e intercambio de documentos y ficheros en sistemas

distribuidos
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
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
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
Descripcin
Nivel de documento
Enumerar (List)
Enumera los documentos en un almacn (sin estructura)
Abrir (Open)
Abre un documento para su manipulacin
Cerrar (Close)
Cierra un documento despus de su manipulacin
Guardar (Save)
Guarda un documento despus de su manipulacin
146
Descartar (Discard)
Descarta las manipulaciones hechas sobre un documento
Lectura
Buscar (Search)
Busca un fragmento dado dentro de un documento
Traer (Get)
Obtiene un fragmento de un documento
Alteracin bsica
Crear (Create)
Crea un fragmento de documento dentro de un documento
Copiar (Copy)
Copia un fragmento de documento (incluso entre documentos)
Borrar (Delete)
Borra un fragmento de un documento
Modificar (Modify)
Modifica atributos de un fragmento de documento
Alteracin compuesta
Mover (Move)
Mueve un fragmento de documento (incluso entre documentos

distintos)
Reemplazar (Replace)
Reemplaza un fragmento de documento por otro
Otras
Apuntar (Point)
Apunta a un fragmento de documento
Reservar
(Reserve/Unreserve)
Reserva (o anula la reserva) de un fragmento de documento
Empezar / Acabar Grupo

(BeginGroup / EndGroup)
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
AOD11
AOD12
AOD13
Nivel de documento
Enumerar (List)
148
Abrir (Open)
Cerrar (Close)
Guardar (Save)
Descartar (Discard)
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 3
Documento 2
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
Descripcin
Crear (Create)
Crea un nuevo objeto dentro de un grupo
Borrar (Delete)
Borra un objeto
Copiar (Copy)
Copia un objeto de un grupo a otro
Mover (Move)
Mueve un objeto desde un grupo fuente hasta un grupo destino
Leer (Read)
Devuelve informacin (atributos o contenido) sobre un objeto
Modificar (Modify)
Modifica la informacin (atributos o contenido) de un objeto
Enumerar (List)
Devuelve los miembros de un grupo o el conjunto de objetos

identificados en una lista de resultados de bsqueda
Buscar (Search)
Busca entradas que satisfagan un determinado criterio de

bsqueda
Reservar (Reserve)
Modifica el nivel de reserva de una entrada
Abandonar (Abandon)
Abandona la ejecucin de una operacin iniciada previamente
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
ADF11
Crear (Create)
ADF12
ADF13
Borrar (Delete)
Copiar (Copy)
Mover (Move)
Leer (Read)
Modificar (Modify)
Enumerar (List)
Buscar (Search)
Reservar (Reserve)
Abandonar (Abandon)
ADF21
ADF22
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
Entidad de
aplicacin
FTAM
Servidor
FTAM
Protocolo de
acceso FTAM
Almacn
real
Entidad de
aplicacin
FTAM
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
ACSE
ACSE
Nivel de
presentacin
FTAMSE
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
DU
Nodo
FADU
FADU
DU
FADU
DU
Nivel 2
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-TRANSFER-END
F-CANCEL
F-LOCATE
F-ERASE
F-OPEN
F-CLOSE
F-READ-ATTRIBUTE
F-CHANGE-ATTRIBUTE
F-SELECT
F-DESELECT
F-CREATE
F-DELETE
F-TERMINATE
F-INITIALIZE
F-U-ABORT
F-P-ABORT
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-TRANSFER-END
F-WRITE
F-CANCEL
F-LOCATE
F-ERASE
F-OPEN
F-CLOSE
F-READ-ATTRIBUTE
F-READ-LINK-ATTRIBUTE
F-CHANGE-ATTRIBUTE
F-CHANGE-LINK-ATTRIBUTE
F-COPY
F-MOVE
F-SELECT
F-DESELECT
F-SELECT-ANOTHER
F-DELETE
F-CREATE
F-UNLINK
F-CREATE-DIRECTORY
F-LINK
F-GROUP-COPY
F-GROUP-MOVE
F-GROUP-LIST
F-GROUP-SELECT
F-CHANGE-PREFIX
F-GROUP-DESELECT
F-LIST
F-INITIALIZE
F-TERMINATE
F-U-ABORT
F-P-ABORT
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
Elementos de servicio
Kernel
M M M
Lectura
O M -
Escritura
O M -
Acceso a fichero
Gestin de ficheros
limitada
Gestin de ficheros
mejorada
Grupos
Recuperacin
Reinicializacin
- M O O M
O
O
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
O O M
F-CHANGE-ATTRIBUTE
M O M
O O O O -
M
O
O
O
O
O
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
Kernel
M M M
Gestin limitada del almacn

Gestin mejorada del almacn
O O
O O
Manipulacin de
objetos
Manipulacin de
grupos
O O
O O
Elementos de servicio
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
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
Formato de
almacenamiento 1
Proceso de
transferencia de
ficheros
Formato de
representacin
Sistema de
ficheros
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
Servidor
PI
Sistema de
ficheros
Servidor
DTP
Comandos FTP
Respuestas FTP
Conexin de datos
Servidor FTP
Usuario
Usuario
PI
Usuario
DTP
Sistema de
ficheros
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
Servidor FTP
(A)
Usuario FTP
Usuario PI
(C)
Conexin de datos
Conexin de control
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.

UPC - Aplicaciones Distribuidas Abiertas

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

UPC - Aplicaciones Distribuidas Abiertas

Caricato da

Copyright:

Formati disponibili

1 Introduccin

Aplicaciones distribuidas abiertas

1.2 OSI e Internet

1.3 Estandarizacin ISO

Aplicaciones distribuidas abiertas

1.4 Estandarizacin en Internet

La mejor definicin de lo que es un estndar de Internet (IS, Internet Standard) se encuentra en el

Aplicaciones distribuidas abiertas

Una iniciativa no alcanza el nivel de estndar de Internet si no se demuestra su utilidad

1.5 Historia de X.400

1.6 Historia de ODA

Aplicaciones distribuidas abiertas

Aplicaciones distribuidas abiertas

2.2 Estructura del 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

Fig. 2.2 Estructura de una entidad de aplicacin

Aplicaciones distribuidas abiertas

Fig. 2.3 Estructura de un contexto de aplicacin

Un elemento de servicio de aplicacin (ASE) puede ser de dos tipos:

ACSE (Association Control Service Element). Se encarga de la gestin de asociaciones entre

2.3 Direccionamiento en el nivel de aplicacin

contexto de aplicacin (AC)

El contexto de aplicacin determina el conjunto de protocolos a soportar, pero es en el

2.4 ACSE (Elemento de servicio de control de asociacin)

Aplicaciones distribuidas abiertas

Fig 2.4 Primitivas del servicio A-ASSOCIATE de ACSE

El servicio A-ASSOCIATE tiene los siguientes parmetros:

modo: normal o X.410-1984

ttulo de la entidad de aplicacin llamada

Aplicaciones distribuidas abiertas

Fig 2.5 Primitivas del servicio A-RELEASE de ACSE

Los parmetros de las primitivas del servicio A-RELEASE son:

El parmetro causa de la liberacin, si figura en al primitiva A-RELEASE.request, puede tener los

Fig. 2.6 Primitivas del servicio A-ABORT de ACSE

Origen del aborto: usuario de ACSE o proveedor del servicio ACSE

Causa del aborto iniciado por el proveedor

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

Aplicaciones distribuidas abiertas

Establecimiento de una asociacin

2.5 RTSE (Elemento de servicio de transferencia fiable)

presentacin para la transferencia de APDU. El estndar [RTS0189] define el servicio de RTSE, y

Fig 2.8 Primitivas del servicio RT-OPEN de RTSE

Aplicaciones distribuidas abiertas

El servicio RT-OPEN tiene los siguientes parmetros:

Modo de dilogo: monlogo o alternativo (TWA, Two-way-alternate)

Fig. 2.9 Primitivas del servicio RT-TRANSFER de RTSE

Los parmetros del servicio RT-TRANSFER son:

Tiempo mximo de transferencia estimado

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

Aplicaciones distribuidas abiertas

y no est pendiente de la finalizacin de un servicio de transferencia de APDU (RT-TRANSFER)

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

Fig. 2.12 Primitivas del servicio RT-CLOSE de RTSE

Los parmetros de las primitivas del servicio RT-CLOSE son:

El servicio RT-CLOSE de RTSE se mapea directamente sobre el servicio A-RELEASE de ACSE,

Fig. 2.13 Primitivas del servicio RT-U-ABORT de RTSE

Fig. 2.14 Primitivas del servicio RT-P-ABORT de RTSE

Aplicaciones distribuidas abiertas

Establecimiento de una asociacin (que se realiza mediante ACSE)