UPC - Aplicaciones Distribuidas Abiertas

1 Introducción

15

1 Introducción 1.1 ¿Aplicaciones distribuidas abiertas? Las tres palabras que forman el título 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 están considerando aplicaciones que se ejecutan en máquinas separadas físicamente. Estas máquinas, dos o más, cooperan para alcanzar objetivos determinados. El intercambio de mensajes (o correo electrónico), la transferencia de ficheros, la manipulación remota de documentos, la gestión de información remota, etc, son simples ejemplos de aplicaciones distribuidas. Cuando al conjunto de palabras “aplicaciones distribuidas” le añadimos el adjetivo “abiertas”, estamos resaltando un aspecto importante de éstas, la interconectabilidad de sistemas heterogéneos. Una aplicación distribuida es abierta cuando sigue unas reglas estandarizadas (o normalizadas), que son públicas, que especifican qué servicio va a dar la aplicación y qué protocolo va a seguir para dar dicho servicio. Por supuesto, esto no tiene que restringir la implementación de la aplicación, sino que, al contrario, sirve para que implementaciones independientes en sistemas diferentes se puedan interconectar gracias a que siguen las reglas definidas en los estándares. Por tanto, este libro describe aplicaciones distribuidas abiertas para intercambiar mensajes, transferir ficheros y documentos, manipular documentos y almacenes de documentos remotamente, acceder a información sobre máquinas y usuarios, etc.

© los autores, 1998; © Edicions UPC, 1998. Quedan rigurosamente prohibidas, sin la autorización escrita de los titulares del "copyright", bajo las sanciones establecidas en las leyes, la reproducción total o parcial de esta obra por cualquier medio o procedimiento, comprendidos la reprografía y el tratamiento informático, y la distribución de ejemplares de ella mediante alquiler o préstamo públicos, así como la exportación e importación de ejemplares para su distribución y venta fuera del ámbito de la Unión Europea.

16

Aplicaciones distribuidas abiertas

1.2 OSI e Internet En el cambiante mundo actual de la comunicación entre ordenadores, dos enfoques (dos arquitecturas de comunicación entre ordenadores) disti ntos, aunque no incompatibles, destacan sobre sobre los demás. Podemos llamarlos OSI e e Internet . Cuando se habla de OSI (Open Systems Interconnection), o interconexión de sistemas abiertos, se está haciendo referencia a los sistemas de comunicación entre ordenadores basados e n la arquitectura conocida como OSI (o modelo arquitectónico de referencia OSI), estandarizado por la Organización Internacional de Estandarización (ISO, International Standards Organization), juntamente con lo que se llamaba (hasta mediados de 1992) Comité Consultivo Internacional de Telefonía y Telegrafía (CCITT), y ahora se denomina sector de normalización de las Telecomunicaciones de la Unión Internacional de Telecomunicaciones Telecomunicaciones (ITU-T). En el modelo OSI, se definen 7 niveles o capas en los que se estructura la comunicación entre aplicaciones que funcionan en ordenadores remotos. Los tres primeros niveles corresponden a la red, mientras que los tres últimos están orientados a dar servicio a la aplicación, 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 aplicación. El lector se supone familiarizado con los conceptos OSI y con las facilidades proporcionadas por los 6 primeros niveles. Existe una amplia bibliografía sobre el modelo OSI y los 6 primeros niveles [véase apartado de bibliografía general OSI]. Cuando se habla de Internet, se está hablando de sistemas de comunicación basados en el modelo nacido a partir de la idea de un servicio y protocolo sin conexión (connectionless-oriented) para interconectar redes, al cual se llamó IP (Internet Protocol). Sobre IP se diseñó el protocolo de transporte TCP (Transmission Control Protocol). Protocol). Aunque estos protocolos protocolos (TCP/IP) se originaron en un entorno militar (en Estados Unidos), rápidamente se extendieron a entornos científicos, académicos 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 también en estas aplicaciones donde se concentra este libro que, sin llegar a profundizar en todas las aplicaciones Internet tan en auge estos días, sí trata sobre la versión 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 rápidamente. 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 próximo.


16


1.2 OSI e Internet En el cambiante mundo actual de la comunicación entre ordenadores, dos enfoques (dos arquitecturas de comunicación entre ordenadores) disti ntos, aunque no incompatibles, destacan sobre sobre los demás. Podemos llamarlos OSI e e Internet . Cuando se habla de OSI (Open Systems Interconnection), o interconexión de sistemas abiertos, se está haciendo referencia a los sistemas de comunicación entre ordenadores basados e n la arquitectura conocida como OSI (o modelo arquitectónico de referencia OSI), estandarizado por la Organización Internacional de Estandarización (ISO, International Standards Organization), juntamente con lo que se llamaba (hasta mediados de 1992) Comité Consultivo Internacional de Telefonía y Telegrafía (CCITT), y ahora se denomina sector de normalización de las Telecomunicaciones de la Unión Internacional de Telecomunicaciones Telecomunicaciones (ITU-T). En el modelo OSI, se definen 7 niveles o capas en los que se estructura la comunicación entre aplicaciones que funcionan en ordenadores remotos. Los tres primeros niveles corresponden a la red, mientras que los tres últimos están orientados a dar servicio a la aplicación, 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 aplicación. El lector se supone familiarizado con los conceptos OSI y con las facilidades proporcionadas por los 6 primeros niveles. Existe una amplia bibliografía sobre el modelo OSI y los 6 primeros niveles [véase apartado de bibliografía general OSI]. Cuando se habla de Internet, se está hablando de sistemas de comunicación basados en el modelo nacido a partir de la idea de un servicio y protocolo sin conexión (connectionless-oriented) para interconectar redes, al cual se llamó IP (Internet Protocol). Sobre IP se diseñó el protocolo de transporte TCP (Transmission Control Protocol). Protocol). Aunque estos protocolos protocolos (TCP/IP) se originaron en un entorno militar (en Estados Unidos), rápidamente se extendieron a entornos científicos, académicos 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 también en estas aplicaciones donde se concentra este libro que, sin llegar a profundizar en todas las aplicaciones Internet tan en auge estos días, sí trata sobre la versión 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 rápidamente. 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 próximo.


1 Introducción

17

1.3 Estandarización ISO Las palabras estándar , norma o recomendación 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 interconexión (tanto en Internet como en OSI) están detrás de esta filosofía. Si queremos conseguir que sistemas heterogéneos heterogéneos puedan comunicarse, deben seguir ciertas reglas, y estas reglas se deben acordar internacionalmente. De ahí la necesidad de disponer de estándares. Formalmente, los estándares sólo pueden ser publicados por ISO, organización internacional formada por los organismos de normalización de todos los países del mundo, como AENOR en España, ANSI en Estados Unidos, DIN en Alemania, BSI en el Reino Unido y AFNOR en Francia. En cada país, el mecanismo de funcionamiento del organismo de normalización varía, pero siempre se trata de armonizar los intereses de las empresas privadas, las públicas y los centros de investigación. ISO, al igual que sus equivalentes nacionales, está estructurada en comités que trabajan en diferentes temas. Por lo que a los contenidos de este libro incumbe, existe un comité conjunto con el CEI o Comité Electrotécnico Internacional (IEC, International Electrotechnical Committee) llamado JTC1 (Joint Technical Committee 1), que trata todos los temas de las llamadas tecnologías de la información. A su vez, el JTC1 está estructurado en subcomités, 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 estándares de correo electrónico X.400 (véase capítulo 4), arquitectura e intercambio de documentos ODA (véase capítulo 5), almacenamiento y recuperación de documentos DFR (véase capítulo 7), la notación para especificar aplicaciones distribuidas (véase capítulo 3), etc. Otros temas tratados en este libro, como el directorio X.500 (véase capítulo 6), o la propia estructura del nivel de aplicación (véase capítulo 2), son responsabilidad del SC21; y así podríamos enumerar los diferentes subcomités del JTC1. A pesar de que, formalmente, los estándares sólo pueden ser publicados por ISO, también ITU-T (y anteriormente el CCITT) está capacitado para publicar lo que ellos llaman recomendaciones que, a efectos prácticos, también son estándares, aunque más orientados a aspectos de telecomunicaciones, en los que ITU-T, por estar formado por las industrias de telecomunicaciones, compañías telefónicas principalmente, y las administraciones nacionales, tiene algo que decir. La ITU-T también tiene una estructura interna, similar de alguna manera a la de ISO, pero con una terminología propia. ITU-T está formado por grupos de estudio (SG, Study Group), que tratan temas diferentes, como el SG8, que trabaja en intercambio y manipulación de documentos (véase capítulo 6), fax, etc., y el SG7, que trabaja en temas como correo electrónico (véase capítulo 4). Cada SG se estructura, a su vez, en lo que se llaman cuestiones (Q, Question). Como se puede deducir de la sencilla enumeración de los temas de trabajo de algunos subcomités 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 colaboración o comités conjuntos con cuestiones de ITU-T para desarrollar estándares concretos. En las secciones 1.5 y 1.6 se narra, a modo de ejemplo, la historia del desarrollo de dos estándares conjuntos de ISO/IEC e ITU-T, como son X.400 (véase capítulo 4) y ODA (véase capítulo 5). Por su parte, las normas de Internet siguen un proceso de estandarización diferente a los de ISO e ITU-T (basados en comités o grupos de trabajo que desarrollan los estándares a aprobar posteriormente por los organismos miembros), ya que el desarrollo de normas se basa en la implementación y prueba de lo que se propone especificar. Un estándar Internet no se acepta si no existen implementaciones probadas. Debido a la complejidad que pueden tener los estándares de ISO o recomendaciones de ITU-T, se definen lo que se llaman estándares funcionales o perfiles, que son subconjuntos implementables de los estándares base. Estos subconjuntos restringen las características de los estándares al eliminar complejidades innecesarias en aplicaciones menos exigentes, con lo que se facilita su implementación. Aunque la aprobación formal de los estándares funcionales (ISP, International Standardized Profile) la hace también ISO/IEC, su desarrollo corresponde en muchas ocasiones a grupos regionales (entendiendo por región un continente entero) y la coordinación entre estos y, a veces, también ITUT. En Europa, existe EWOS (European Workshop for Open Systems) que, a través de sus grupos de expertos en diversos temas, desarrolla perfiles que después coordina con otros organismos regionales para producir estándares funcionales a aprobar por ISO/IEC. EWOS también es responsable de la producción de estándares europeos, aprobados oficialmente por el Comité Europeo de Normalización (CEN). Otros organismos regionales activos en los temas que trata este libro son OIW (Open Implementors Workshop), en Norteamérica, y AOW (Asia Oceania Workshop), principalmente en Japón, Corea y Australia. Finalmente, en Europa existe otro organismo oficial de normalización, el Instituto Europeo de Estándares de Telecomunicaciones (ETSI, European Telecommunications Standards Institute), que como su nombre indica es responsable en Europa del desarrollo de estándares relacionados con las telecomunicaciones. De alguna manera, ETSI es un complemento de ITU-T en aspectos europeos.

1.4 Estandarización en Internet En cuanto al proceso de estandarización en Internet, y como características más importantes, hay que mencionar que existen muchos menos organismos en el proceso de estandarización, y que además este tiene un fuerte carácter práctico.


1 Introducción

19

La mejor definición de lo que es un estándar de Internet (IS, Internet Standard) se encuentra en el documento [RFC1602], y que a continuación se cita: "En general, un estándar de Internet es una especificación que es estable y comprensible, es técnicamente competente, tiene múltiples 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 definición, un estándar de Internet sólo puede generarse si primero se demuestra de forma explícita su interés y utilidad práctica. En esencia, el proceso para crear un estándar de Internet es muy sencillo. Cualquier usuario de la Internet puede proponer un borrador de especificación para ser comentado por los demás. A esta especificación se la conoce como borrador Internet (ID, Internet Draft). Este documento se pública en la Internet por medio de servidores de información (básicamente ftp, aunque ahora también WWW) para que sea analizado, y comentado públicamente. Si en el plazo de seis meses este documento no pasa a ser catalogado como petición de comentarios (RFC, Request For Comments), se ha actualizado generando una nueva versión, el documento simplemente se borra del servidor de información 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 estándar de Internet. Para llegar a este estado, el documento deberá pasar por varios niveles de madurez, pudiéndose quedar en alguno de ellos. Según la terminología Internet, los niveles de madurez de un documento que pretende ser estándar son: propuesta de estándar (PS, Proposed Standard), borrador de estándar (DS, Draft Standard) y finalmente estándar de Internet (IS, Internet Standard). La diferencia básica entre ellos, según se desprende de la definición de estándar de Internet antes citada, es que una propuesta de estándar no necesita de implementaciones que interoperen, para pasar a borrador de estándar es necesario disponer de por lo menos dos implementaciones independientes, y el grado de estándar sólo se alcanza con implementaciones y bastante experiencia en su operación. Todo el proceso de revisión y aceptación de especificaciones para su designación como RFC o estándar 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 tecnológicos y la evolución de la Internet; ISOC (Internet Society) que entre otras tiene como actividad la estandarización en la Internet; IESG (Internet Engineering Steering Group) que controla las actividades del IETF; y el IAB (Internet Architecture Board) que es un grupo técnico de asesoría dentro del ISOC. Por ejemplo, una de las actividades del IAB es, a través del IANA (Internet Assigned Number Authority), asignar identificadores y parámetros únicos a las RFC, estándares, protocolos, servicios, etc. de la Internet.


20


Esta ha sido una rápida visión del proceso de estandarización en la Internet (una descripción completa puede encontrarse en [RFC-1602]), pero nos permite resaltar dos características muy importantes en el campo de los sistemas abiertos: -

Una iniciativa no alcanza el nivel de estándar de Internet si no se demuestra su utilidad práctica y existen implementaciones interoperables. Esto no es así en el caso de ISO y ITU-T, con lo cual es posible tener estándares que nunca se han implementado. Además, en Internet no existen perfiles, ya que t odo lo que se estandariza debe estar implementado.

-

Todos los documentos (Internet Drafts, RFC, Internet Standards, etc.) son públicos y están 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 público y además hay que pagar por ellos, aunque esto está cambiando últimamente.

1.5 Historia de X.400 Fue la Federación Internacional para el Procesado de la Información (IFIP, International Federation for Information Processing), una organización profesional de informáticos, desde su comité técnico 6 (TC6, Data Communications) quien empezó el trabajo de normalización del correo electrónico. Para ello creó, a finales de los 70, un grupo de trabajo (WG6.5) para trabajar en la definición de un modelo de sistema de gestión de mensajes. Este trabajo fue seguido por el entonces CCITT que, en 1984, aprobó las primeras recomendaciones internacionales de mensajería electrónica. A pesar de que se fueron descubriendo fallos y limitaciones, estas recomendaciones del CCITT tienen un mérito innegable, especialmente teniendo en cuenta que es la primera norma completamente desarrollada del nivel de aplicación del modelo de referencia OSI. La experiencia adquirida con estas recomendaciones y las primeras implementaciones llevaron al CCITT a desarrollar una nueva versión, aprobada en 1988, que corrige muchas de las limitaciones de la versión del 84. En este trabajo también colaboró ISO, lo que dio lugar a una norma conjunta entre CCITT , Recomendaciones X.400 (MHS ) e ISO, Estándar Internacional MOTIS (Message Oriented Text Interchange Systems). En los últimos años, 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 creación del ISO/IEC JTC1. Finalmente, después de 1988 se han publicado nuevas versiones del estándar que no cambian demasiado la funcionalidad, pero que corrigen y extienden algunas cosas. De hecho, existe una nueva republicación en 1995.


1 Introducción

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 número ECMA-101, y el título Open Document Architecture. Seguidamente, ISO decidió que era necesario un estándar internacional sobre representación e intercambio de documentos, por lo que empezó a producir su propio estándar. Para ello, se consideró la norma de ECMA como documento de partida. De esta manera, también, se pasó de un ámbito europeo a uno más internacional, en el que se debe destacar la activa participación 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 número 1 de ISO y la IEC (ISO/IEC JTC1). Actualmente, el grupo de trabajo número 3 del mencionado subcomité (es decir, ISO/IEC JTC1 SC18/WG3) es quien tiene la total responsabilidad sobre el estándar y sus extensiones. La producción del estándar ODA no es sólo debida al trabajo de ISO/IEC, sino que también el CCITT (y después ITU-T), ha hecho suyo el compromiso de la estandarización del intercambio de documentos, y está publicando el estándar ODA en paralelo con ISO. La primera versión del estándar ODA fue aprobada oficialmente en 1989 con el número ISO 8613 (que consta de 7 partes, de la 1 a la 8 aunque no existe la parte 3), y el título 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 tenía el SC18, quien produjo esta primera versión. La versión del estándar publicada por el CCITT era prácticamente idéntica a la de ISO, aunque el CCITT usa una estructura diferente, y en vez de tener un estándar con varias partes, tiene varias Recomendaciones que forman una serie. En concreto, el número y título 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 título del estándar está ya unificado, pues ISO decidió, ya en 1990, cambiar la palabra Office por Open. Actualmente, el trabajo de extensión del estándar 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 estándar, incluyendo una republicación realizada en 1994, y extensiones que se han venido publicando desde entonces.


22


ODA 1994 tiene una nueva parte (aunque sólo en la versión de ISO/IEC, no en la de ITU-T), que es la 10, titulada Especificaciones formales que, mediante un lenguaje definido en el propio estándar, especifica, sin posibilidad de ambigüedades, el estándar completo. Asimismo, otras nuevas partes, como la 3 (Recomendación T.413 de ITU-T), la 9 (T.419), la 11 (T.421), la 12 (T.422) y la 14 (T.424) (véase capítulo 5) se han publicado posteriormente (concretamente en 1995 y 1996).


2 Nivel de aplicación

23

2 Nivel de aplicación 2.1 Introducción El objetivo de los primeros capítulos de este libro es presentar los elementos teóricos básicos para especificar y diseñar aplicaciones en las cuales se procese información de una forma distribuida. Para ello es necesario disponer de una serie de funcionalidades orientadas a resolver los problemas relacionados con la distribución. Estos recursos los proporcionan los sietes niveles del modelo de interconexión de sistemas abiertos (OSI, Open Systems Interconnection) de ISO.

-

Los niveles inferiores del modelo OSI (niveles físico, enlace, red y transporte), o niveles orientados a la comunicación, proporcionan los medios necesarios para la transmisión fiable de datos.

-

Los niveles superiores del modelo OSI (niveles sesión, presentación y aplicación), o niveles orientados a la aplicación, proporcionan una serie de servicios para la gestión y sincronización del diálogo, la transferencia estándar de estructuras de datos, etc.

El último nivel del modelo OSI es el nivel de aplicación, que proporciona los servicios necesarios para que una aplicación pueda gestionar información distribuida, facilitando los medios adecuados para acceder al resto de niveles. En una aplicación distribuida se pueden distinguir dos partes diferenciadas: la aplicación propiamente dicha y la parte que realiza el acceso a los recursos de comunicación. Es este último aspecto el que diferencia una aplicación local de su versión distribuida, y es este aspecto del diseño de aplicaciones distribuidas el que se trata en los primeros capítulos de este libro.


24


2.2 Estructura del nivel de aplicación El propósito del nivel de aplicación es servir como intermediario entre procesos de aplicación de usuario que están utilizando los recursos OSI para intercambiar i nformación (véase la figura 2.1).

Proceso Aplicación Usuario

Nivel de aplicación


Protocolo de aplicación


Proveedor del servicio de presentación

Fig. 2.1 Procesos de aplicación de usuario y nivel de aplicación

Se define un proceso de aplicación (AP, Application Process) como un elemento dentro de un sistema abierto que realiza el procesado distribuido de información (es decir, que implica comunicación) para una determinada aplicación. Los procesos de aplicación intercambian información por medio de entidades de aplicación que implementan protocolos de aplicación utilizando servicios de presentación. Una entidad de aplicación (AE, Application Entity) define los aspectos concernientes a la comunicación de un proceso de aplicación. Las entidades de aplicación intercambian información por medio de unidades de datos del protocolo de aplicación (APDU, Application Protocol Data Unit) (véase la figura 2.2). En el caso más general, un proceso de aplicación puede definir varios tipos de intercambio de información. Por lo tanto, su comunicación tendrá varios aspectos que se implementarán mediante diferentes AE. Para la mayor parte de las aplicaciones distribuidas es suficiente una única entidad de aplicación. Para que dos entidades de aplicación puedan cooperar es necesario establecer previamente una asociación de aplicación o simplemente una asociación (Application Association). El concepto de asociación en el nivel de aplicación equivale al concepto de conexión en el resto de niveles del modelo OSI. Una asociación se mapea directamente sobre una conexión de presentación. La entidad de aplicación que toma la iniciativa de establecer la asociación es la entidad que inicia la asociación (Initiator Entity) y la que acepta o rechaza la asociación es la entidad que responde (Responder Entity). Una entidad de aplicación consta de un elemento de usuario (UE, User Element) y un conjunto de elementos de servicio de aplicación (ASE, Application Service Element) (véase la figura 2.2).


25


El elemento de usuario (UE, User Element) representa aquella parte de la entidad de aplicación que coordina los elementos de servicio de aplicación (ASE) necesarios para llevar a cabo los objetivos de comunicación de dicho proceso de aplicación. Es decir, gestiona los diferentes ASE que constituyen dicha AE y además es el interfaz con el proceso de aplicación de usuario. Un elemento de servicio de aplicación (ASE, Application Service Element) es aquella parte de una entidad de aplicación que proporciona una función 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 más que un conjunto de funciones que permiten a las AE cooperar para un determinado propósito.



AE

AE Protocolos de aplicación

UE ASE 1

...

ASE n

(APDU)

UE ASE 1

...

ASE n

Conexión de presentación

Fig. 2.2 Estructura de una entidad de aplicación

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 presentación. En el nivel de aplicación no se puede hablar de un protocolo de aplicación único sino de un conjunto de protocolos de aplicación, uno para cada par de ASE residentes en entidades de aplicación remotas. Algunos ASE son obligatorios, es decir, sie mpre deben formar parte de cualquier entidad de aplicación, mientras que otros son opcionales. En OSI, el usuario del servicio de presentación es siempre un ASE. Se define un contexto de aplicación (AC, Application Context) como el conjunto de servicios y protocolos de aplicación utilizados por una entidad de aplicación en una asociación. Básicamente indica el conjunto de ASE que componen el proceso de aplicación definiendo implícitamente los protocolos (véase la figura 2.3). Los ASE que constituyen una entidad de aplicación pueden ser iguales en los dos extremos y reciben el nombre de ASE simétricos, o complementarios y reciben el nombre de ASE asimétricos. En los ASE asimétricos uno tiene el papel de consumidor o cliente y el otro el papel de suministrador o servidor del servicio (véase el apartado 3.1.1 correspondiente a la arquitectura cliente/servidor).


26



Proceso Aplicación Usuario AE

AE UE ASE

UE ASE

Protocolo de aplicación

ASE

ASE

ROSE

ROSE

RTSE

RTSE

ACSE

ACSE


Fig. 2.3 Estructura de un contexto de aplicación

Un elemento de servicio de aplicación (ASE) puede ser de dos tipos: -

común específico

Los ASE comunes son aquéllos que ofrecen una funcionalidad que la mayor parte de aplicaciones distribuidas utilizan. Por esta razón se creyó conveniente estandarizarlos y se ofrecen como un recurso común en los entornos de desarrollo de aplicaciones distribuidas. Así el diseñador puede utilizar estos ASEs comunes y concentrarse en el diseño de la apli cación propiamente dicha. Los ASE específicos son aquella parte de una entidad de aplicación que implementan las funcionalidades concretas del sistema distribuido que se está diseñando y son la parte que diferencia unas aplicaciones de otras. Se han normalizado varios ASE comunes. Los más utilizados son:

- ACSE (Association Control Service Element). Se encarga de la gestión de asociaciones entre entidades de aplicación. - 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 petición/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 t res.



27

La figura 2.3 ilustra el concepto de contexto de aplicación. Se puede observar que existe una relación entre los ASE comunes y específicos que constituyen una entidad de aplicación.

2.3 Direccionamiento en el nivel de aplicación Para establecer una asociación entre dos entidades de aplicación es necesario poder direccionar una entidad de aplicación dentro del entorno OSI. Para conseguirlo se utilizan, a nivel de direccionamiento, dos informaciones: -

contexto de aplicación (AC) título de la entidad de aplicación (AE-Title)

El contexto de aplicación determina el conjunto de protocolos a soportar, pero es en el establecimiento de la asociación donde se concreta el conjunto de protocolos que se van a utilizar en esa asociación. El título de un proceso de aplicación (AP-Title, Application Process Title) identifica un proceso de aplicación concreto dentro del entorno OSI. Un calificador de entidad de aplicación (AE-Qualifier, Application Entity Qualifier) identifica una entidad de aplicación en particular dentro de un proceso de aplicación. El título de una entidad de aplicación (AE-Title, Application Entity Title) identifica una entidad de aplicación concreta dentro del entorno OSI y está formado por: AE-Title = AP-Title + AE-Qualifier En la práctica, como dentro de un proceso de aplicación (AP) se dispone únicamente de una entidad de aplicación (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 información de direccionamiento de aplicación, normalmente el AP-Title, se debe obtener la dirección de presentación, a partir de la cual se puede obtener la dirección de red. Este proceso puede ser local mediante un mapeo, en cuyo caso se está utilizando un método no estándar, o normalizado utilizando el servicio de directorio estándar (X.500) donde, a partir de un nombre distintivo, como AP-Title, es posible obtener la dirección de presentación. (véase el capítulo 5).

2.4 ACSE (Elemento de servicio de control de asociación) El elemento de servicio de control de asociación (ACSE, Association Control Service Element) es el encargado de suministrar facilidades para la gestión de asociaciones entre entidades de aplicación que se comunican a través de una conexión de presentación. El elemento de servicio común ACSE es


28


obligatorio, es decir, debe formar parte de cualquier entidad de aplicación. Existe una correspondencia uno a uno entre una conexión de presentación y una asociación de aplicación. Los estándares [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 mínimo de la unidad funcional Kernel de presentación. 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 asociación y es un servicio confirmado (Fig. 2.4). Mediante los parámetros del servicio A-ASSOCIATE se especifica, entre otras cosas, el contexto de aplicación, la lista de contextos de presentación válidos para cada ASE y el contexto de presentación por defecto para una asociación 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 parámetros: -

modo: normal o X.410-1984 contexto de aplicación título de la entidad de aplicación iniciadora



-

29

título de la entidad de aplicación llamada título de la entidad de aplicación que responde (opcional) información de usuario resultado diagnóstico (sólo si se ha rechazado la asociación) dirección de la entidad de presentación iniciadora dirección de la entidad de presentación llamada dirección de la entidad de aplicación que responde (opcional) lista de contextos de presentación: inicial y resultante contexto de presentación por defecto: inicial y resultante calidad de servicio parámetros relacionados con presentación y sesión: tokens, puntos de sincronización, etc.

Estos parámetros aparecen en las cuatro primitivas del servicio A-ASSOCIATE. De todas formas, existen algunas pequeñas diferencias entre los parámetros de cada una de las primitivas en lo que hace referencia a la opcionalidad. El parámetro “modo” selecciona entre un modo de funcionamiento de ACSE normal, que además es el valor por defecto, y un modo de funcionamiento específico para mensajería electrónica. Con el parámetro “contexto de aplicación”, el iniciador de la asociación propone un contexto de aplicación para la asociación que solicita. A continuación hay una serie de parámetros donde se identifican las entidades de aplicación que inicia y acepta la asociación. El “título de la entidad de aplicación” consta del título del proceso de aplicación y el calificador de la entidad de aplicación. El campo de “información de usuario” lo pueden utilizar indistintamente las dos entidades para incluir información (por ejemplo, credenciales de autenticación, etc.). El parámetro “resultado” contiene información relativa al resultado de la negociación del establecimiento de la asociación: aceptada, rechazada de forma transitoria o rechazada de forma permanente. El parámetro “diagnóstico” indica la causa del rechazo de la asociación si así lo indica el parámetro resultado; los valores pueden ser ‘no existe razón aparente’, ‘contexto de aplicación no soportado’ y ‘título de la entidad de aplicación iniciadora o llamada desconocido’. El resto son parámetros relacionados con los niveles de presentación y sesión. El servicio A-ASSOCIATE se mapea directamente sobre el servicio P-CONNECT de presentación. La entidad de aplicación que ha generado la primitiva A-ASSOCIATE.request antes de recibir AASSOCIATE.confirmation sólo puede utilizar el servicio A-ABORT.

A-RELEASE El servicio A-RELEASE, que es confirmado, es una liberación ordenada y sirve para finalizar una asociación sin pérdida de información en tránsito (Fig. 2.5). La liberación de una asociación puede iniciarla cualquiera de las dos entidades de aplicación.


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 parámetros de las primitivas del servicio A-RELEASE son: -

Causa de la liberación Información de usuario Resultado: afirmativo o negativo

El parámetro “causa de la liberación”, si figura en al primitiva A-RELEASE.request, puede tener los valores ‘normal’, ‘urgente’ o ‘definido por el usuario’, pero si es un parámetro de la primitiva ARELEASE.response, los valores posibles son: ‘normal’, ‘no finalizada’ o ‘definida por el usuario’. El parámetro “resultado” lo utiliza la entidad de aplicación que acepta la asociación para indicar la aceptación o rechazo de la liberación de la asociación. El servicio A-RELEASE se mapea directamente sobre el servicio P-RELEASE de presentación.

A-ABORT El servicio A-ABORT lo utiliza el usuario de ACSE para liberar una asociación 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 parámetos de las primitivas del servicio A-ABORT son los siguientes: -

Origen del aborto: usuario de ACSE o proveedor del servicio ACSE Información de usuario

El primer parámetro, como su nombre indica, contiene información del origen de la liberación. El campo de “información de usuario” pueden utilizarlo las entidades de aplicación para incluir información cuyo significado depende del contexto de aplicación. El servicio A-ABORT se mapea directamente sobre el servicio P-U-ABORT de presentación. Una vez generada la primitiva A-ABORT.request, para el iniciador la asociación ha sido liberada. El proveedor del servicio ACSE puede utilizar el servicio A-ABORT para liberar una asociación por problemas internos del protocolo de aplicación.

A-P-ABORT El servicio A-P-ABORT se utiliza para liberar una asociación 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 liberación de la asociación anómala, normalmente debida a problemas en los niveles inferiores. Esta situación puede originar pérdida de información en tránsito. El único parámetro 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

A-P-ABORT.indication

Figura 2.7 Primitivas del servicio A-P-ABORT de ACSE

El servicio A-P-ABORT de ACSE se mapea directamente sobre el servicio P-P-ABORT de presentación.


32


2.4.2 Protocolo El protocolo ACSE describe la transferencia de información entre entidades de aplicación para la gestión de asociaciones, es decir, las unidades de datos de aplicación (APDU). El protocolo ACSE consta de los siguientes elementos de protocolo: -

Establecimiento de una asociación Liberación normal de una asociación Liberación abrupta de una asociación

Las unidades de datos del protocolo de aplicación (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 asociación utiliza las APDU AARQ y AARE, la fase de liberación normal RLRQ y RLRE, y la fase de liberación abrupta utiliza la APDU ABRT. A continuación se muestra una tabla donde aparecen las primitivas de servicio de ACSE y las correspondientes APDU que las t ransportan. Primitiva ACSE A-ASSOCIATE.request/indication A-ASSOCIATE.response/confirmation A-RELEASE.request/indication A-RELEASE.response/confirmation A-ABORT.request/indication A-P-ABORT.indication

APDU AARQ AARE RLRQ RLRE ABRT ---

Para hacerse una idea de la complejidad del protocolo ACSE, la máquina 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 común RTSE (Reliable Transfer Service Element) es el encargado de suministrar facilidades para la transferencia de APDU de gran tamaño, garantizando la recepción í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 aplicación. En el caso de que esté presente, es el encargado de manejar el elemento de servicio ACSE para la gestión de asociaciones, y del nivel de


33


presentación para la transferencia de APDU. El estándar [RTS0189] define el servicio de RTSE, y [RTS0289] describe el protocolo. RTSE proporciona un mecanismo independiente de la aplicación para recuperarse de fallos durante el proceso de transmisión de la información, minimizando el número de retransmisiones. De esta forma, libera al diseñador de aplicaciones distribuidas de tener que preocuparse por la gestión de las facilidades que suministra sesión, a través de presentación, 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 mínimo del subconjunto básico de actividades de sesión (BAS) accesible a través del servicio de presentación. Recordar que el servicio de sesión BAS consta de las unidades funcionales: kernel, half-duplex, datos tipificados, datos con capacidad, puntos de sincronización 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 (Sólo solicitud, indicación y confirmación) No confirmado No confirmado Confirmado No confirmado No confirmado (Sólo indicación)

RT-OPEN El servicio RT-OPEN, que es confirmado, utiliza el elemento de servicio ACSE para establecer una asociación, 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 si guientes parámetros: -

Modo de diálogo: monólogo o alternativo (TWA, Two-way-alternate) Turno inicial Protocolo de aplicación Datos de usuario Parámetros relacionados con ACSE Parámetros relacionados con presentación y sesión

El primero de los parámetros específicos relacionados con el servicio RT-OPEN es el “modo del diálogo”, que puede ser monólogo, es decir, que únicamente la entidad que está inicialmente en posesión del turno puede transmitir APDU, o TWA, donde las dos entidades pueden hacerlo alternativamente siempre y cuando estén en posesión del turno, el cual puede intercambiarse. Otro parámetro nuevo es el “turno inicial”, que lo puede poseer la entidad que inicia o la que responde la asociación. El parámetro “protocolo de aplicación” sólo tiene sentido en el modo X.410-1984 (véase el apartado 2.4 relacionado con ACSE). El parámetro “datos de usuario” se puede utilizar para almacenar información relacionada con el proceso de establecimiento de la asociación de aplicación. El resto de parámetros 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 posesión del turno para transmitir APDU de forma fiable mediante una asociación de aplicación. Normalmente, los servicios confirmados constan de cuatro primitivas; en cambio, el servicio RT-TRANSFER sólo tiene tres primitivas (véase la figura 2.9). La razón es que una APDU se transmite dentro de una actividad, por lo que la finalización 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 (véase 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 parámetros del servicio RT-TRANSFER son: -

APDU a transmitir


35


-

Tiempo máximo de transferencia estimado Resultado de la transferencia: positivo o negativo

El primer parámetro contiene la APDU que se desea transmitir, el segundo define el tiempo máximo 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 confirmación con la primitiva RT-TRANSFER.confirmation. El parámetro “resultado” contiene información 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 utilización de una serie de servicios de presentación que hacen posible que la transferencia de APDU se realice dentro de una actividad (véase 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 aplicación que quiere transmitir APDU para conseguir el turno si no lo tiene (véase la figura 2.10). También lo debe utilizar el usuario de RTSE de la entidad de aplicación iniciadora de la asociación 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 sólo tiene un parámetro, que es la prioridad asociada a la acción para la que se solicita el turno. Con esta información, el usuario de RTSE remoto puede decidir cuándo entrega el turno. La prioridad cero indica la prioridad más alta y se reserva para liberar la asociación. El servicio RT-TURN-PLEASE se mapea sobre el servicio de presentación 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 aplicación entregar el turno al usuario de RTSE remoto, siempre y cuando esté en posesión del turno


36


y no esté pendiente de la finalización de un servicio de transferencia de APDU (RT-TRANSFER) (véase 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 parámetros y se mapea directamente sobre el servicio de presentación P-CONTROL-GIVE.

RT-CLOSE El servicio RT-CLOSE, que es confirmado, permite al usuario de RTSE liberar de forma ordenada una asociación de aplicación (véase la figura 2.12). La liberación sólo puede realizarla el usuario de RTSE de la entidad iniciadora de la asociación cuando está en posesión del turno y no tiene pendiente la finalización de una transferencia de APDU (recepción de RTTRANSFER.confirmation). El usuario de RTSE de la entidad de aplicación que responde la asociación no puede rechazar la liberación.

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 parámetros de las primitivas del servicio RT-CLOSE son: -

Causa de la liberación Información de usuario

Estos parámetros únicamente tienen sentido en modo de operación normal, ya que en modo X.4101984 no existen parámetros.


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 presentación.

RT-U-ABORT El servicio RT-U-ABORT lo pueden utilizar los dos usuarios de RTSE para liberar una asociación de forma abrupta, y utiliza los servicios equivalentes de ACSE. El servicio RT-U-ABORT es un servicio no confirmado (véase 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 sólo tiene un parámetro, que es un campo de información del usuario que se utiliza para informar sobre el proceso de liberación abrupta de la asociaci ón de aplicación. 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 asociación 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 (véase la figura 2.14). El proveedor del servicio informa a los dos usuarios de RTSE que le es imposible mantener la asociación de aplicación.

Usuario RTSE

RT-P-ABORT.indication

Proveedor RTSE

Usuario RTSE

RT-P-ABORT.indication

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

El servicio RT-P-ABORT, que no tiene parámetros, 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 máquina 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 presentación. El protocolo RTSE consta de los siguientes elementos de protocolo: -

Establecimiento de una asociación (que se realiza mediante ACSE) Transferencia de APDU Petición y cesión de turno Liberación de una asociación: ordenada y abrupta (que se realiza mediante ACSE) Gestión de errores

Las unidades de datos del protocolo de aplicación (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 continuación se muestra una tabla donde se indica el mapeo entre las primitivas de servicio de RTSE y las primitivas de ACSE, así como las APDU que las transportan. Primitiva RTSE RT-OPEN.request/indication RT-OPEN.response/confirmation RT-OPEN.response/confirmation RT-CLOSE.request/indication RT-CLOSE.response/confirmation RT-U-ABORT.request/indication RT-P-ABORT.indication

APDU RTORQ RTOAC RTORJ ----RTAB RTAB

Primitiva ACSE A-ASSOCIATE.request/indication A-ASSOCIATE.response/confirmation A-ASSOCIATE.response/confirmation A-RELEASE.request/indication A-RELEASE.response/confirmation A-ABORT.request/indication A-P-ABORT.indication

Cuando un usuario de RTSE invoca el servicio RT-TRANSFER, la transferencia fiable de la APDU se realiza a nivel de presentación 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 tamaño que se habrá negociado en la fase de establecimiento de la asociación (espaciado entre puntos de sincronización). Para poder fraccionar la APDU primero es necesario serializar la información, para lo cual, la máquina de protocolo de RTSE deberá obtener la sintaxis de transferencia y entregar cada fragmento al servicio de presentación. 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 presentación 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 transmisión con puntos de sincronización menor (servicio P-MINOR-SYNC). El número de puntos


39


de sincronización que pueden existir sin confirmar se negocia también en la fase de establecimiento de la asociación (tamaño de la ventana). La utilización de actividades a nivel de presentación 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 presentación 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 aportaría nada respecto a la transmisión de la APDU, pero en cambio introduciría redundancia en la transmisión. En la figura 2.15 se ilustra gráficamente la relación entre la utilización por un usuario de RTSE del servicio RT-TRANSFER para transmitir una APDU, y los servicios de presentación 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 relación con el nivel de presentación

El proceso de serialización de la información aplicando unas reglas de codificación concretas para obtener una sintaxis de transferencia es una función del nivel de presentación. En cambio se ha dicho que la máquina de protocolo de RTSE realiza dicha función cuando tiene que transferir una APDU. Esto vulnera la independencia de los niveles que preconiza ISO en su modelo de interconexión de sistemas abiertos y es una de las incoherencias que presenta el nivel de aplicación. A continuación se muestra una tabla donde aparece el mapeo entre las primitivas de RTSE y las primitivas de presentación, así como también las APDU que las transportan. Primitiva RTSE RT-TRANSFER.request/indication

RT-TRANSFER.indication/confirmation

APDU --RTTR -----

Primitiva Presentación 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 común del nivel de aplicación es ROSE (Remote Operations Service Element), que se utiliza para implementar aplicaciones distribuidas interactivas del tipo petición/respuesta (paradigma cliente/servidor). Una entidad de aplicación invoca la operación 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 común de aplicación ROSE. Los estándares [ROS0189] y [ROS1294] describen el servicio de ROSE y los estándares [ROS0289] y [ROS1394] el protocolo. La respuesta (reply) generada a partir de una solicitud (request) puede ser de tres tipos en función del resultado de la operación 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 operación no se haya podido ejecutar por alguna razón, en ese caso la respuesta será un rechazo (véase la figura 2.16).

AE Invoca operación remota

Invocación

Resultado Rechazo Error

AE Realiza operación remota

Fig 2.16 Modelo funcional para ROSE

Las operaciones remotas se pueden clasificar según dos modos de funcionamiento llamados modo síncrono y modo asíncrono. El modo síncrono consiste en la posibilidad de invocar las operaciones de forma secuencial, de forma que, cuando se lanza una operación remota en modo síncrono, no se puede lanzar la siguiente hasta que no se ha recibido su correspondiente respuesta. En modo asíncrono 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 también se pueden clasificar en cinco tipos o clases en función del modo de operación que utilizan y el tipo de resultado que generan. La operación clase 1 utiliza modo síncrono y genera siempre una respuesta, ya sea resultado o error. La operación clase 2 utiliza modo asíncrono y genera siempre una respuesta. La operación clase 3 utiliza modo asíncrono y sólo genera un error si existe, y si se ejecuta correctamente no genera ninguna respuesta. Las operaciones clase 4 utilizan modo asíncrono y sólo generan un resultado, mientras que las de clase 5, que también utilizan modo asíncrono, no devuelven ninguna respuesta en ningún caso (véase la figura 2.17).


41


Invoca RO

Realiza RO

AE

Clase 1

AE Invocación Respuesta Invocación 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 operación inicial, llamada operación padre, desencadene como respuesta nuevas operaciones llamadas operaciones hijas. Se dice que las operaciones hijas están enlazadas ("linked") con la operación padre (véase la figura 2.18).

AE

ejecuta las operaciones hijas enlazadas

invocación de operación padre

AE

invocación de operación hija

ejecución de operación padre

invocación de operación hija

ejecuta la operación 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 operación remota que deberá ejecutar el usuario de ROSE remoto (véase 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 parámetros del servicio RO-INVOKE son los siguientes: -

Identificador de la operación Clase de la operación Argumento Identificador de la invocación Identificador de la operación enlazada Prioridad

El parámetro "identificador de la operación" identifica la operación que se va a invocar y tiene que ser el mismo para los dos usuarios de ROSE. El argumento "clase de la operación" sirve para saber si se utiliza modo síncrono o asíncrono y el tipo de respuesta esperada (resultado, error o rechazo); su uso permite optimizar la gestión del turno en el caso de que se utilice RTSE. El parámetro "argumento", como su nombre indica, es el argumento de la operación invocada. El "identificador de la invocación" sirve para asociar una respuesta a una invocación cuando se trabaja en modo asíncrono o para el caso de que existan operaciones enlazadas (o hijas). El parámetro "identificador de la operación enlazada", que es opcional, si existe significa que la operación invocada es una operación hija y se utiliza para indicar la operación padre. El parámetro "prioridad" se utiliza para asignar una escala de prioridades a las diferentes transferencias de APDU entre las entidades de aplicación. El servicio RO-INVOKE de ROSE se mapea directamente sobre el servicio P-DATA del nivel de presentación.


43


RO-RESULT El servicio RO-RESULT lo utiliza el usuario de ROSE que ejecuta la operación para devolver el resultado de la operación solicitada en el caso de que ésta se haya ejecutado con éxito. Es un servicio no confirmado (véase 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 parámetros del servicio RO-RESULT son los siguientes: -

Identificador de la operación Resultado Identificador de la invocación Prioridad

Los parámetros de las primitivas del servicio RO-RESULT, "identificador de la operación" e "identificador de la invocación", son los mismos que se han estudiado en la invocación de la operación con el servicio RO-INVOKE. Como su nombre indica, el parámetro "resultado" contiene el resultado de una invocación remota ejecutada con éxito. Finalmente, con el parámetro "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 presentación.

RO-ERROR El servicio RO-ERROR, que es un servicio no confirmado, lo utiliza el usuario de ROSE que ejecuta la operación para indicar al usuario que invoca la operación solicitada que se ha ejecutado con errores (véase la figura 2.21). Los parámetros del servicio RO-RESULT son los siguientes: -

Identificador del error Parámetro del error Identificador de la invocación 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 parámetro "identificador del error" identifica el tipo de error que se ha producido al ejecutar la operación y en el parámetro "parámetro del error" el usuario de ROSE puede incluir información adicional respecto al error. Los parámetros "identificador de la invocación" y "prioridad" son los mismos que se ha estudiado en la invocación de la operación mediante el servicio RO-INVOKE. El servicio RO-ERROR de ROSE se mapea directamente a nivel de presentación 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 operación remota solicitada mediante el servicio RO-INVOKE, al detectar algún tipo de problemas (véase la figura 2.22). También se puede utilizar este servicio para rechazar una respuesta (resultado o error) de una invocación 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 parámetros de las primitivas del servicio RO-REJECT-U son los siguientes: -

Causa del rechazo Identificador de la invocación Prioridad

Los parámetros "identificador de la invocación" y "prioridad" son los mismos que se han visto en la descripción de los otros servicios de ROSE. El parámetro "causa del error" contiene información


45


diferente según 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: ‘invocación duplicada’, ‘operación desconocida’, ‘argumento erróneo’, ‘recursos limitados’, ‘liberación del iniciador de la asociación’, ‘identificador de la operación enlazada desconocido’, ‘respuesta de la operación enlazada no esperada’ y ‘operación hija no esperada’. En el caso de rechazo de una primitiva RO-RESULT.indication anterior, las causas de rechazo son: invocación no desconocida, resultado no esperado y resultado erróneo. Finalmente, si el rechazo corresponde a una primitiva RO-ERROR.indication, las causas de rechazo son: invocación desconocida, error no esperado, error desconocido y parámetro erróneo. El servicio RO-REJECT-U de ROSE se mapea directamente sobre el servicio P-DATA del nivel de presentación.

RO-REJECT-P El servicio RO-REJECT-P lo utiliza el proveedor del servicio ROSE para indicar a sus usuarios que ha detectado algún 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 (véase 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 parámetros de las primitivas del servicio RO-REJECT-P son los siguientes: -

Causa del rechazo Identificador de la invocación Parámetros retornados

Los parámetros de la primitiva RO-REJECT-P.indication, que son todos opcionales, son el identificador de la invocación, la causa del rechazo y un campo de parámetros del rechazo que contiene el parámetro 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 errónea o estructura de la APDU errónea. El servicio RO-REJECT-P de ROSE se mapea directamente a nivel de presentación mediante el servicio P-DATA.


46


2.6.2 Protocolo El protocolo ROSE queda definido por la máquina de protocolo de ROSE (ROPM, Remote Operations Protocol Machine). Se pueden identificar un a serie de elementos de protocolo que son los siguientes: -

Invocación 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 continuación se muestra el mapeo entre las primitivas de servicio de ROSE y el servicio de presentación, 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 presentación P-DATA.request/indication P-DATA.request/indication P-DATA.request/indication P-DATA.request/indication P-DATA.request/indication


3 Especificación y diseño de aplicaciones distribuidas

47

3 Especificación y diseño de aplicaciones distribuidas En este capítulo se describen herramientas para el desarrollo de aplicaciones distribuidas abiertas. En el apartado 3.1 se estudia un modelo arquitectónico 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 estándar de especificación formal independiente de la implementación, llamado ASDC, mediante el cual se puede describir formalmente cualquier aplicación distribuida. En el apartado 3.3 se muestra como realizar una implementación OSI del sistema distribuido así especificado. Para ello, se describe una notación llamada notación-RO porque permite especificar las operaciones remotas que, en OSI, se implementan utilizando ROSE (véase el capítulo 2). El uso de técnicas formales estandarizadas, contribuye no tan solo a la legibilidad de los estándares, sino también, lo que es más importante, facilitan enormemente la automatización del proceso de diseño.

3.1 DOAM (Modelo para aplicaciones distribuidas) El modelo arquitectónico para aplicaciones distribuidas, conocido como el modelo para aplicaciones de oficina distribuida (DOAM, Distributed Office Applications Model) se describe en los estándares [DOA0191] y [DOA0291] y suministra las bases para: -

Especificación del modelo cliente/servidor Modelo abstracto de aplicaciones distribuidas Utilización de los protocolos de comunicación OSI Utilización de ASDC y ROSE Aplicaciones distribuidas múltiples


48

Aplicaciones distribuid as abiertas

3.1.1 Modelo cliente/servidor En una aplicación local el usuario y la aplicación se encuentran en la misma máquina, y el usuario accede a la aplicación a través del interfaz de aplicación (Application Interface) (Fig. 3.1).

Usuario Interfaz de aplicación Cliente Definición de servicio


Servidor

Fig. 3.1 Aplicación local

Cuando se quiere distribuir la aplicación es necesario dividirla en dos partes que se llaman cliente (client) y servidor (server). El proceso cliente será la parte de la aplicación que se quedará en la misma máquina 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 máquina, será el encargado de ejecutar las operaciones solicitadas por el usuario.

Usuario Interfaz de aplicación Cliente

Definición de servicio

Protocolo de acceso


Servidor

Fig 3.2 Aplicación distribuida: modelo cliente/servidor

El interfaz entre el cliente y el servidor es lo que se llama definición del servicio (Service definition). El cliente y el servidor remoto utilizarán para comunicarse los servicios de los siete niveles OSI mediante lo que se llama protocolo de acceso al servicio (Access protocol). La distribución de una


49


aplicación debe siempre hacerse de forma transparente al usuario, es decir, el interfaz de aplicación que utiliza el usuario debe ser el mismo que si la aplicación fuese local (Fig. 3.2). Normalmente, el cliente es poco complejo y reside en la máquina local del usuario; en cambio, los servidores pueden llegar a tener cierta complejidad y suelen residir en máquinas más 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.

Definición 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 más general, es posible pensar en aplicaciones distribuidas en las que el cliente deba tener acceso a más 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 número 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. Supóngase, 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 información que solicita. Si no dispone de ese protocolo de acceso, lo tendrá que hacer indirectamente a través 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 utilización del protocolo del sistema.

3.1.2 Modelo de comunicación cliente/servidor y protocolos de comunicación OSI En este apartado se va a relacionar el modelo DOAM para aplicaciones distribuidas con los protocolos OSI, en concreto con el nivel de aplicación. En la figura 3.4 se muestra cómo realizar la implementación OSI de una aplicación distribuida DOAM, en la que pueden relacionarse todos los conceptos que se han introducido en este capítulo con los que se han descrito en el capítulo anterior, correspondiente al nivel de aplicación. Las dos entidades de aplicación correspondientes al cliente y al servidor que se comunican mediante el protocolo de acceso están compuestas por una serie de ASE comunes, como son ACSE, RTSE (opcional) y ROSE (para implementar las interacciones cliente/servidor), y los ASE específicos que en este caso son asimétricos y están 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 comunicación OSI vendrían representadas respectivamente por la parte del cliente y del servidor que no forman parte de las entidades de aplicación (véase la figura 3.4).

Usuario

Cliente

Servidor

AE

AE UE

UE ASE cliente


Protocolo de accesso

ASE serv. ROSE

ROSE RTSE

RTSE

ACSE

Nivel de presentación e inferiores

ACSE


Fig. 3.4 Modelo DOAM y realización 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 realización OSI para ese tipo de sistemas distribuidos, en la que se pueden identificar dos tipos de servidores elementales, aquéllos que únicamente se comunican con otro servidor elemental, y aquéllos que además también deben establecer comunicación con un cliente. En el caso del primer tipo de servidores elementales, sólo necesitan una entidad de aplicación (EA 2) con sus ASE comunes y específicos; normalmente ésta será una comunicación simétrica mediante el protocolo que hemos llamado protocolo de sistema. El segundo tipo de servidor elemental requiere la utilización de dos contextos de aplicación, que se pueden implementar mediante una o dos entidades de aplicación. En el caso de la figura 3.5 se ha optado por utilizar dos entidades de aplicación (EA 1 y EA 2). Una EA se utiliza para la comunicación con otro servidor elemental (EA 2) mediante el protocolo de sistema y la otra EA (EA 1) sirve para la comunicación con el cliente mediante el protocolo de acceso. Recordemos que ésta última es una relación asimétrica.

Usuario

Cliente


Nivel de presentación y niveles inferiores

Entidad de aplicación Protocolo de 1) acceso ASE (1)

Servidor

Entidad de aplicación 1) ASE (1)


Servidor

Entidad de aplicación Protocolo de 2) sistema ASE (2)

Entidad de aplicación 2) ASE (2)


Fig. 3.5 Modelo DOAM y realización OSI para servidores distribuidos

Uno de los objetos más importantes en aplicaciones distribuidas en un entorno de oficina es el documento. ISO ha estandarizado una serie de operaciones sobre documentos, concretamente aquellas más comunes, con la finalidad de que los diseñadores de este tipo de aplicaciones dispongan de su especificación y la puedan utilizar en sus diseños, lo cual no significa que éstos puedan definir sus propias operaciones. En el estándar se define, para cada operación, los parámetros que utiliza y los resultados que se obtienen. A continuación se listan dichas operaciones normalizadas junto con una breve descripción de cada una de ellas.


52


Operación

Descripción

Listar (List)

Listar los componentes de un objeto

Leer (Read)

Leer determinados atributos de un objeto

Escribir (Write)

Escribir determinados atributos de un objeto

Modificar (Modify)

Cambiar los atributos de un objeto

Copiar (Copy)

Copiar un objeto

Mover (Move)

Mover un objeto

Buscar (Search)

Identificar objetos con características específicas

Crear (Create)

Crear un objeto

Borrar (Delete)

Borrar un objeto

Reservar (Reserve)

Bloquear un objeto para uso posterior

Notificar (Notify)

Informar sobre cambios en un objeto

Abandonar (Abandon)

Abandonar la operación en curso

3.1.3 Aplicaciones distribuidas múltiples El modelo DOAM también contempla la posibilidad de diseñar aplicaciones distribuidas donde un usuario pueda acceder a más de un servicio remoto (o servidor). En este caso se define un sistema tipo cliente/servidor para cada servicio remoto según el modelo DOAM. La adaptación del modelo general DOAM para el caso de aplicaciones distribuidas múltiples se ilustra en la figura 3.6, donde para cada servicio se define un interfaz de aplicación (interfaz de aplicación A, interfaz de aplicación 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 aplicación de usuario consta de todos los clientes más un elemento de usuario que se encargará, por una parte, de interaccionar con el usuario y por otra de gestionar todas los interfaces de aplicación (interfaz de aplicación A, interfaz de aplicación B,..).

Usuario Interfaz de aplicación A

Interfaz de aplicación 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 múltiple


53


3.2 Especificación y diseño de sistemas distribuidos: ASDC Se han estandarizado unas reglas o convenciones para la definición de servicios abstractos conocidas como ASDC (Abstract Service Definition Conventions). El lenguaje de especificación ASDC sirve para especificar formalmente sistemas distribuidos, estandarizados o no, que se pueden utilizar o no en un entorno OSI. El que sea una especificación abstracta significa que es independiente de la implementación y, al ser formal, es posible utilizar herramientas automáticas o semiautomáticas que, a partir de la especificación, nos permitan llegar hasta la implementación. En el estándar [ASD0190] se define el lenguaje formal de especificación ASDC que forma parte de los estándares de la mensajería electrónica. En el lenguaje ASN.1 se pueden utilizar las macros para definir un nuevo lenguaje de especificación. La notación ASDC está basada en la utilizaci ón de macros de ASN.1 La especificación de un sistema distribuido utilizando ASDC consta de dos puntos de vista: -

Visión macroscópica o modelo abstracto: donde se define la arquitectura del sistema, y se muestran los módulos que lo componen, el entorno que definen y cómo se relacionan entre sí.

-

Visión microscópica o servicio abstracto: donde se define la funcionalidad del sistema, así como el nuevo servicio que proporciona.

3.2.1 Visión macroscópica En el modelo abstracto, o visión macroscópica, se define el sistema como un conjunto de módulos llamados objetos abstractos (Abstract Objects) los cuales cooperan a través de canales de comunicación llamados puertos abstractos (Abstract Ports). nombre-objeto OBJECT PORTS

{

{

nombre-puerto-1

[S],

-- puerto asimétrico papel suministrador

nombre-puerto-2

[C],

-- puerto asimétrico papel consumidor

nombre-puerto-3

-- puerto simétrico

............}} ::= identificador-objeto-abstracto

-- es un Object Identifier o un identificador local

Fig. 3.7 Definición 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 especificación de un objeto abstracto en ASDC se utiliza una macro de ASN.1 llamada OBJECT, a través de la que se le adjudica un identificador y se le asocia una lista de puertos abstractos para su acceso. El identificador no es más


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 asimétrico 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 utilización 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 más de un objeto abstracto de este tipo (por defecto el objeto es único). También se enumeran los puertos abstractos asociados a cada objeto componente, el tipo del puerto y, en el caso de puerto asimétrico, 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). Además, 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 sería el caso de puertos abstractos que están 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

nombre-objeto-1 nombre-objeto-2

AS -- objeto abstracto único

RECURRING

-- objeto abstracto múltiple

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 Visión microscópica En la especificación del servicio abstracto, o visión microscópica, se definen dos aspectos: -

El conjunto de funcionalidades o servicios que ofrece un objeto a otro objeto a través de uno o varios puertos abstractos. Estos servicios reciben el nombre de operaciones abstractas (Abstract Operations) y se deben definir mediante la utilización de la macro ABSTRACTOPERATION de ASN.1.

-

Los puertos abstractos a través de los cuales se puede acceder a las operaciones abstractas. Para cada puerto se indica su tipo (simétrico o asimétrico) y la lista de operaciones que se pueden utilizar a través de cada puerto y quién las debe invocar.


55


Un puerto abstracto puede ser de dos formas distintas: -

Asimétrico: cada instanciación 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).

-

Simétrico: todas las instanciaciones del puerto son idénticas, tienen el mismo papel, y pueden actuar indistintamente como consumidor o suministrador.

Objeto entorno Objeto cliente

...

Objeto cliente

Puerto asimétrico Objeto servidor

Operación

Puerto simétrico

Objeto servidor

Fig. 3.9 Representación gráfica de objetos y puertos (simétricos y asimétricos) 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 quién las invoca. Si el puerto es simétrico 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 (véase la figura 3.10). nombre-puerto

PORT

ABSTRACT OPERATIONS

--puerto abstracto simétrico

{lista-operaciones}

--operaciones abstractas definidas

::= identificador-puerto Fig. 3.10 Definición de un puerto abstracto simétrico mediante la macro PORT de ASDC

Si el puerto es asimétrico se deben e numerar qué operaciones deben ser invocadas por el consumidor (CONSUMER INVOKES) y por el suministrador (SUPPLIER INVOKES) (véase la figura 3.11).


56


nombre-puerto

PORT

--puerto abstracto asimétrico

CONSUMER INVOKES {lista-operaciones}

--operaciones invocadas por consumidor

SUPPLIER

--operaciones invocadas por suministrador

INVOKES {lista-operaciones}

::= identificador-puerto Fig. 3.11 Definición de un puerto abstracto asimétrico mediante la macro PORT de ASDC

Cada una de las operaciones abstractas se debe definir mediante la utilización de la macro ABSTRACT-OPERATION de ASN.1. Para cada procedimiento u operación abstracta se pueden indicar los argumentos (ARGUMENT), los resultados (RESULT) y los posibles errores (ERRORS) (véase la figura 3.12). nombre-operación ABSTRACT-OPERATION ARGUMENT

TipoArgumento

RESULT

TipoResultado

ERRORS

{lista-errores}

{

}

Fig. 3.12 Definición de una operación abstracta mediante la macro ABSTRACT-OPERATION de ASDC

El enlace de dos puertos abstractos se llama unión abstracta (Abstract Bind). Dos objetos no se pueden comunicar si previamente no se han unido sus puertos abstractos. Dicha unión debe seguir las siguientes reglas: -

Dos puertos se pueden unir siempre y cuando sean simétricos.

-

Si dos puertos son asimétricos, sólo se pueden unir si tienen distinto papel, es decir, uno es consumidor y el otro suministrador.

La unión abstracta se debe especificar mediante la utilización de la macro ABSTRACT-BIND de ASN.1, en la que se debe indicar a qué puerto abstracto hace referencia dicha unión, y podemos asociar argumentos (ARGUMENT), resultados (RESULT) y/o errores (BIND-ERROR) (véase la figura 3.13). nombre-bind TO

::=

ABSTRACT-BIND

{lista-puertos}

BIND ARGUMENT

TipoArgumento

RESULT

TipoResultado

BIND-ERROR

TipoErrorBind

Fig. 3.13 Definición de una unión abstracta mediante la macro ABSTRACT-BIND de ASDC


57


La ruptura del enlace de dos puertos abstractos se llama liberación de una unión abstracta (Abstract Unbind) y se realiza mediante la utilización de la macro ABSTRACT-UNBIND de ASN.1. Como en el caso de la unión abstracta, es necesario indicar a qué puertos abstractos hace referencia la liberación de la unión abstracta que estamos definiendo, así como los argumentos (ARGUMENT), resultados (RESULT) o errores (UNBIND-ERROR), si es que existen (véase la figura 3.14). nombre-unbind

::=

FROM

ABSTRACT-UNBIND {lista-puertos}

UNBIND ARGUMENT

TipoArgumento

RESULT

TipoResultado

UNBIND-ERROR

TipoErrorUnbind

Fig. 3.14 Definición de la liberación de una unión abstracta mediante la macro ABSTRACT-UNBIND de ASDC

Cada error abstracto (Abstract Error) que aparece en la especificación, es necesario definirlo mediante la macro ABSTRACT-ERROR de ASN.1 , donde es posible asociar parámetros a cada error de forma opcional (véase la figura 3.15). nombre-error

::=

PARAMETER

ABSTRACT-ERROR TipoParametro

Fig. 3.15 Definición 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 especificación 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 notación-RO de ROSE para su implementación OSI, es decir, se definen (véase apartado 3.3): ABSTRACT-OPERATION

MACRO

::=

OPERATION

ABSTRACT-ERROR

MACRO

::=

ERROR

ABSTRACT-BIND

MACRO

::=

BIND

ABSTRACT-UNBIND

MACRO

::=

UNBIND

3.3 Notación-RO (Remote Operations Notation) La notación-RO es un lenguaje de especificación 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


utilización de una serie de macros. A partir de la especificación de un servicio distribuido en notación-RO se pueden utilizar herramientas automáticas o semiautomáticas mediante las cuales es posible llegar hasta la implementación. Así se obtienen dos programas ejecutables correspondientes al que invoca (Invoker o cliente) la operación remota y al que la ejecuta (Performer o servidor). A continuación únicamente es necesario ejecutar dichos programas en dos máquinas con servicios OSI completos (véase la figura 3.16).

Cliente

Notación RO

CompiladorEnlazador

Ejecutable cliente

CompiladorEnlazador

Ejecutable servidor

Compilador Notación-RO

Servidor

Fig. 3.16 Entorno de desarrollo de aplicaciones distribuidas OSI especificadas en notación-RO

Para especificar una aplicación basada en operaciones remotas se han normalizado cuatro macros de ASN.1, que son las siguientes: OPERATION: Para especificar una operación 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 asociación de aplicación previamente a las llamadas remotas. UNBIND: Para liberar una asociación previamente establecida. Con estas cuatro macros se puede definir en qué consiste el nuevo servicio distribuido que se quiere diseñar, pero es necesario también indicar cómo 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 aplicación (ASE) específicos necesarios para implementar dicho servicio (macro APPLICATIONSERVICE-ELEMENT), y con la segunda macro, llamada APPLICATION-CONTEXT, se especifica el contexto de aplicación asociado a dicho nuevo servicio. Las macros normalizadas de ASN.1 para definir ASE específicos y contextos de aplicación son las siguientes:


59


APPLICATION-SERVICE-ELEMENT: Para cada ASE específico del contexto de aplicación APPLICATION-CONTEXT: Para cada contexto de aplicación

3.3.1 Operaciones remotas Para especificar una operación remota es necesario utilizar la macro de ASN.1 OPERATION, mediante la cual se dota a la operación de un identificador que el usuario de ROSE de la entidad invocadora de la operación utiliza como “identificador de operación” cuando quiera que la entidad remota ejecute la operación. 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 operación remota. Si la operación se ha ejecutado con éxito y devuelve resultados, éstos se especifican con la palabra clave RESULT. Es posible que l a operación se ejecute incorrectamente; en cuyo caso los posibles errores generados se especifican con la palabra clave ERRORS. Finalmente, si la operación especificada es la operación padre de una serie de operaciones enlazadas, es necesario utilizar la palabra clave LINKED para listar las operaciones hijas (véase la figura 3.17). nombre-operación OPERATION ARGUMENT

TipoArgumento

RESULT

TipoResultado

ERRORS

{lista-errores}

LINKED

{lista-operaciones-hijas}

::= identificador-operación Fig.3.17 Definición de una operación mediante la macro OPERATION de la notación-RO

3.3.2 Errores Todos los errores que aparezcan en las macros OPERATION de las operaciones remotas se deben especificar con la utilización de la macro ERROR, que permite asociar a cada error un identificador y, opcionalmente, con la palabra clave PARAMETER, una serie de parámetros. 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 (véase la figura 3.18). nombre-error

ERROR

PARAMETER

TipoParametro

::= identificador-error Fig. 3.18 Definición de un error mediante la macro ERROR de la notación-RO


60


El valor de un tipo de dato correspondiente a un error no es más que el identificador que utilizará el usuario de ROSE de una entidad de aplicación para informar al usuario de ROSE homónimo de una situación excepcional que se ha producido al intentar ejecutar una operación remota que éste le ha solicitado con anterioridad.

3.3.3 Operación de establecer una unión (Bind) Para poder invocar una operación remota es necesario establecer previamente una asociación de aplicación. Esta operación se llama establecer una unión o bind y se especifica con la macro BIND. Con esta macro es posible asociar a la operación de establecer una unión un identificador y asociarle argumentos, resultados y errores. Con la palabra reservada ARGUMENT se pueden definir argumentos de entrada asociados con una operación de establecer una unión. Si el establecimiento de la unión 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 (véase la figura 3.19). nombre-establecer-unión BIND ARGUMENT

TipoArgumento

RESULT

TipoResultado

BIND-ERROR

TipoErrorBind

::= identificador-establecer-unión Fig. 3.19 Establecer una unión mediante la macro BIND de la notación-RO

3.3.4 Operación de liberación de la unión (Unbind) La operación de liberar una unión (o unbind) destruye la asociación de aplicación que se ha utilizado para una operación remota. La liberación de la unión 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 (véase la figura 3.20). nombre-liberar-unión UNBIND ARGUMENT

TipoArgumento

RESULT

TipoResultado

UNBIND-ERROR

TipoErrorUnbind

::= identificador-liberar-unión Fig 3.20 Liberar una unión mediante la macro UNBIND de la notación-RO


61


3.3.5 Elementos de servicio de aplicación (ASE) específicos Con la macro APPLICATION-SERVICE-ELEMENT se especifican los ASE específicos dotándolos de un identificador único y se definen sus características particulares. Debe recordarse que el protocolo definido entre dos ASE específicos puede ser simétrico o asimétrico. En el caso de ASE simétricos los dos usuarios indistintamente pueden invocar todas las operaciones remotas. En el caso asimétrico es necesario indicar para cada operación quién la invoca, es decir, si es el consumidor o el proveedor de la operación remota. Para cada ASE específico asimétrico, y mediante la macro APPLICATION-SERVICE-ELEMENT, se indica la lista de operaciones que puede invocar únicamente el consumidor de la operación remota (CONSUMER INVOKES) y las que sólo puede invocar el proveedor de la operación (SUPPLIER INVOKES). En el caso de ASE simétricos las operaciones las pueden invocar indistintamente los dos extremos y se utiliza la palabra reservada OPERATIONS para indicar la lista (véase la figura 3.21). nombre-ase

APPLICATION-SERVICE-ELEMENT

OPERATIONS

{lista-operaciones}

-- operaciones ase simétrico

CONSUMER INVOKES {lista-operaciones}

--operaciones ase asimétrico

SUPPLIER INVOKES

-- operaciones ase asimétrico

{lista-operaciones}

::= identificador-ase Fig.

3.21

Definición

de un

ASE

mediante

la

macro

APPLICATION-SERVICE-ELEMENT de la notación-RO

3.3.6 Contexto de aplicación Un contexto de aplicación (AC) queda definido por las operaciones de establecimiento de una unión (bind), liberación de dicha unión (unbind) y el conjunto de ASE (comunes y específicos) 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 aplicación concreto y se definen sus características. La composición del contexto de aplicación asociado al servicio que se está especificando, consta de la lista de ASE que lo constituyen (APPLICATIONSERVICE-ELEMENT), cómo establecer la unión asociada al servicio (BIND), cómo 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 aplicación (ABSTRACT SYNTAXES). Los ASE simétricos de los que consta el contexto de aplicación se deben listar utilizando la palabra clave OPERATIONS OF. Para los ASE asimétricos es necesario listar por separado aquéllos para los que la entidad iniciadora de la asociación es la consumidora de dichos ASE (INITIATOR CONSUMER OF) y aquéllos para los que


62


la entidad que responde a la iniciación de la asociación es su consumidora (RESPONDER CONSUMER OF) (véase la figura 3.22). nombre-ac nombre-ac APPLICATION APPLICATION-CONTE -CONTEXT XT APPL APPLIC ICAT ATIO IONN-SE SERV RVIC ICEE-ELE ELEME MENT NT

{lista-a {lista-ases ses} }

BIND

TipoBind

UNBIND

TipoUnbind

REMOTE OPERATIONS

{lista-identificadores-ases(ROSE)}

OPERATIONS OF

{lista-ases}

INITIATOR CONSUMER OF

{lista-ases}

RESPONDER CONSUMER OF

{lista-ases}

ABSTRACT SYNTAXES

{lista-as}

::= identificador-ac identificador-ac Fig. 3.22 Definición de un contexto de aplicación mediante la macro APPLICATION-CONTEXT de la notación-RO

3.4 Ejemplo: minimensajería electrónica En este ejemplo se propone diseñar un nuevo servicio (o aplicación) distribuido OSI utilizando la notación ASDC para su especificación y la notación-RO para su posterior implementación con ROSE.

Usuario

...

Usuario

Sistema de mensajería

Administrador

...

Administrador

Fig 3.23 Arquitectura general del miniservicio de mensajería

Se pretende especificar en ASDC una aplicación que modela un miniservicio de mensajería electrónica (la aplicación que se va a especificar no pretende ser un modelo real o estándar, sino que debe tomarse como un simple ejemplo). Con este nuevo servicio, los usuarios de dicha aplicación disponen de la posibilidad de enviar y leer mensajes de otros usuarios del servicio de mensajería.


63


También existen unos usuarios especiales, que son los administradores del sistema que, además de poseer las funcionalidades de un usuario normal, también pueden realizar operaciones de gestión (véase la figura 3.23). Del nuevo servicio de mensajería que se va a diseñar, sólo interesa aquella parte relacionada con la distribución, esto es, el proceso de la aplicación distribuida que utiliza los servicios OSI para intercambiar información con otros sistemas. Cada sistema (ordenador) involucrado en la realización del servicio de mensajería debe poseer una torre de comunicaciones OSI completa (los siete niveles). Las entidades de aplicación necesarias para implementar dicho servicio deben contener los ASE comunes, esto es, ACSE y ROSE (y opcionalmente RTSE), más los ASE específicos 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 continuación, en la figura 3.24, se muestra la estructura de la entidad de aplicación del servicio de mensajería electrónica del ejemplo.

Proceso Aplicación Usuario AE UE ASE

. ..

ASE

ROSE ACSE

Fig. 3.24

Entidad de aplicación del servicio de mensajería

electrónica

3.4.1 Especificación ASDC Se puede realizar una representación gráfica de la arquitectura del servicio de mensajería electrónica donde aparecen todos los objetos abstractos que lo componen y los puertos abstractos que los relacionan ente sí. En realidad se trata de una representación gráfica de la visión macroscópica del servicio, que nos da la misma información que la especificación formal según la notación ASDC. El entorno de mensajería electrónica tendrá un aspecto como el mostrado en la figura 3.25 en términos de objetos y puertos abstractos ASDC.


64


Usuariomensajería

usomensajería

envía recibe

Administradormensajería envía recibe

Entornomensajería

prueba registra adminmensajería

Sistema-mensajería

Fig. 3.25 Representación gráfica del entorno entorno del servicio de mensajería electrónica

El servicio consta de cuatro tipos de objetos abstractos distintos llamados: -

sist sistem emaa-me mens nsaj ajer ería ía usua usuari rioo-me mens nsaj ajer ería ía admin administ istrad rador or-m -men ensaj sajer ería ía ento entorn rnoo-me mens nsaj ajer ería ía

Estos objetos abstractos se comunican entre sí mediante puertos abstractos. Existen dos puertos abstractos distintos llamados “uso-mensajería” y “admin-mensajería”. El puerto “uso-mensajería” lo utiliza un usuario para invocar las operaciones normales de utilización del sistema, y relaciona los objetos “usuario-mensajería” y “admin-mensajería” con el objeto “sistema-mensajería”. El puerto abstracto “uso-mensajería” es asimétrico y tiene los papeles de cliente en los extremos correspondientes a los objetos “usuario-mensajería” y “administrador-mensajería”, y el papel de servidor en el extremo del objeto “sistema-mensajería”. El puerto abstracto “admin-mensajería” lo utiliza el usuario administrador del sistema para realizar las operaciones propias de gestión, y por lo tanto relaciona sólo el objeto “administrador-mensajería” con el objeto “sistema-mensajería”. También es un puerto asimétrico y tiene el papel de cliente en el extremo correspondiente al objeto “administrador-mensajería” “administrador-mensajería” y el papel de servidor en el extremo del objeto “sistema-mensajería”. Las operaciones que se pueden utilizar en el puerto abstracto “uso-mensajería” son enviar un mensaje (“Envía”) y leer un un mensaje (“Recibe”). Estas operaciones las invoca siempre el usuario del servicio (“usuario-mensajería” o “administrador-mensajería”). Para gestión, en el puerto abstracto “admin-mensajería”, 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 descripción gráfica se puede especificar la aplicación de mensajería electrónica utilizando la notación formal ASDC. El diseño se realiza mediante la definición de dos módulos: -

Especificación en ASDC del entorno abstracto, o visión macroscópica Especificación en ASDC del servicio abstracto, o visión microscópica

3.4.1.1 Visión macroscópica EntornoMensajeria DEFINITIONS ::= BEGIN -- Entorno de mensajería

entorno-mensajeria OBJECT ::= id-ot-mensajeria-entorno -- Refinamiento del entorno de mensajería

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 definición

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 Visión microscópica ServicioMensajeria DEFINITIONS ::= BEGIN -- Puertos abstractos

uso-mensajeria PORT CONSUMER INVOKES { Envía, 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

Envía ::= 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 Realización con ROSE: Notación-RO El servicio de mensajería electrónica que se ha especificado en los apartados anteriores mediante la notación ASDC, se va a implementar utilizando ROSE. Para su diseño es necesario utilizar la notación-RO. A continuación se muestra cómo sería la especificación del servicio utilizando la notación-RO. Se puede observar que se implementa con dos contextos de aplicación llamados “usomensajería-AC” y “admin-mensajería-AC”, donde cada uno de ellos consta de uno o varios ASE específicos. El contexto de aplicación “uso-mensajería-AC” lo utilizan los usuarios normales de mensajería y contiene el ASE específico “uso-mensajería-ASE” que utiliza la sintaxis abstracta “usomensajería-AS”. El otro contexto de aplicación, que es “admin-mensajería-AC”, y es utilizado por los administradores de la mensajería y contiene los ASE específicos “admin-mensajería-ASE” y “uso-mensajería-ASE”. Los usuarios administradores utilizan el ASE “admin-mensajería-ASE” para las operaciones de gestión (utilizando la sintaxis abstracta “admin-mensajería-AS”), y el ASE “usomensajería” para las operaciones normales (utilizando la sintaxis abstracta “admin-mensajería-AC”). RealizacionMensajeria DEFINITIONS ::= BEGIN -- Contextos de aplicación

uso-mensajeria-AC APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS

-- para el usuario mensajería

{aCSE}


68


BIND

BindUsoMensajeria

UNBIND UnbindMensajeria REMOTE OPERATIONS

{rOSE}


{uso-mensajeria-ASE}

ABSTRACT SYNTAXES

{uso-mensajeria-AS, aCSE-AS}

::= id-ac-mensajeria-uso admin-mensajeria-AC APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS BIND

-- para el administrador

{aCSE}

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 aplicación

uso-mensajeria-ASE APPLICATION-SERVICE-ELEMENT CONSUMER-INVOKES { envía, 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

envía

Envía ::=

1

--Resto de operaciones: recibe, registra y prueba --Errores

END


69


De la definición de un puerto se desprenden los servicios que puede suministrar dicho puerto. Dichos servicios al final serán realizados por un ASE específico, que define una sintaxis abstracta y pertenece a un contexto de aplicación determinado en el nivel de aplicación. En nuestro ejemplo, el sistema “entorno de mensajería” se implementa con dos puertos, por lo tanto con dos ASE específicos distintos que, combinados, dan lugar a dos contextos de aplicación que se muestran en la figura 3.26. Los servicios (operaciones) disponibles en cada contexto son los siguientes: -

uso-mensajeria-AC: envía y recibe admin-mensajeria-AC: envía, recibe, registra y prueba

Usuario administrador de sistema-mensajería

Sistema-mensajería

UE

UE

usomensajería


adminmensajería

Protocolo entre administradores y sistema-mensajería

usomensajería

ROSE

adminmensajería

ROSE

ACSE

ACSE


Nivel de presentación

Usuario de sistema-mensajería

Sistema-mensajería

UE

UE usomensajería


Protocolo entre usuarios y sistema-mensajería

usomensajería

ROSE

ROSE

ACSE


Fig. 3.26

ACSE


Contextos de aplicación del sistema entorno de

mensajería


70


3.4.3 Refinamiento del sistema de mensajería En una aplicación de mensajería electrónica, se distinguen básicamente dos componentes distintos. Por una parte se tiene el acceso al servicio de mensajería , que incluye los usuarios y administradores de la mensajería 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 mensajería, se vio que teníamos varias clases de objetos, y entre ellos el “sistema-mensajería”. Como objeto abstracto, puede refinarse para definir con más detalle cuál es su composición. Como se puede observar en la figura 3.27, se trata de la misma arquitectura (visión macroscópica) que la definida anteriormente, donde aparecen nuevos objetos llamados “agentes”. Un agente es, en nuestro caso, una entidad que actúa como intermediaria entre el sistema de transferencia y los usuarios (normales o privilegiados) de la mensajería. En cualquier caso, es el proveedor de un puerto de mensajería (“uso-mensajería” o “admin-mensajería”) y el consumidor de un puerto del sistema de transferencia (“uso-transferencia” o “admin-transferencia”). También puede verse al agente como un valor añadido, en cuanto a la funcionalidad al entorno de transferencia, que hace “visible” dicho entorno a los usuarios de la mensajería.

agenteusuario

agenteadministrador entrega

sistemamensajería

transfiere

transfiereprueba

usotransferencia

admintransferencia

sistema-transferencia

Fig. 3.27 Refinamiento del sistema de mensajería

El entorno de mensajería refinado constará, por tanto, de los objetos definidos en el entorno de mensajería original más los nuevos objetos que se obtienen del refinamiento del sistema de mensajería. En la figura 3.28 se puede ver la representación gráfica del entorno de mensajería en la que aparece el refinamiento del sistema de mensajería descrito anteriormente.


71


usuariomensajería

usomensajería

administradormensajería

adminmensajería

entornomensajeria

agenteusuario

usomensajería

agenteusuario agenteadministrador

sistemamensajería sistema-transferencia

adminmensajería

Fig. 3.28 Refinamiento del entorno de mensajería

La definición ASDC del refinamiento del “sistema-mensajería” sería el si guiente: RefinamientoSistemaMensajeria DEFINITIONS ::= BEGIN -- refinamiento sistema-mensajería

sistema-mensajeria-refinamiento REFINE agente-usuario

sistema-mensajeria

AS

RECURRING

uso-mensajeria

[S]

VISIBLE

uso-transferencia

[C]

PAIRED WITH {sistema-transferencia}

agente-administrador RECURRING admin-mensajeria

[S]

VISIBLE

admin-transferencia

[C]

PAIRED WITH {sistema-transferencia}

sistema-transferencia ::= id-ref-mensajeria-sistema -- nuevos objetos abstractos

agente-usuario PORTS

OBJECT {

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 notación para la especificación de servicios y protocolos OSI En la última versión del estándar "ITU-T Recommendation X.880 | ISO/IEC 13712-1 Remote Operations - Concepts, Model and Notation" se describe un nuevo lenguaje de especificación para la definición de servicios abstractos y su implementación basada en la utilización del protocolo de aplicación ROSE. Las componentes del modelo abstracto son las siguientes: -

Objetos abstractos (ROS-OBJECT-CLASS) Contratos abstractos (CONTRACT) Paquetes de conexión (CONNECTION-PACKAGE) Puertos abstractos (OPERATION-PACKAGE) Operaciones abstractas (OPERATION) Errores abstractos (ERROR) Contextos de aplicación (APPLICATION-CONTEXT)

La macro ROS-OBJECT-CLASS define la capacidad de un objeto abstracto de interaccionar con otros objetos a través de asociaciones donde se definen los contextos de esas interacciones en términos de contratos abstractos. Se listan los contratos que soporta un objeto abstracto como entidad que inicia o responde a la asociación o ambos indistintamente. Cuando se utilizan servicios de comunicación OSI, un objeto abstracto representa un proceso de aplicación. 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 especificación 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 asociación y los puertos abstractos que se pueden utilizar durante la vida de la asociación. Se listan los puertos en los que la entidad que inicia la asociación adopta el papel de consumidor, suministrador o ambos (puertos simétricos). Cuando se utilizan protocolos de comunicación OSI un contrato (CONTRACT) se realiza como un contexto de aplicación. nombre-contract

CONTRACT

::= {

CONNECTION

nombre-connection-package


{lista-puertos}

--puertos asimétricos iniciador es consumidor

RESPONDER CONSUMER OF

{lista-puertos}

--puertos asimétricos responde es consumidor

OPERATIONS OF

{lista-puertos}

--puertos simétricos

ID

identificador-contract }

Fig. 3.30 Macro CONTRACT para la especificación de aplicaciones basadas en ROSE

La macro CONNECTION-PACKAGE especifica la parte del contrato relacionada con el establecimiento (Bind) y la liberación (Unbind) de la asociación. Cuando se utilizan los servicios de comunicación OSI esto se realiza utilizando los servicios de ACSE directamente o a través de RTSE. nombre-connection-package BIND

CONNECTION-PACKAGE

::= {

nombre-operación-bind

UNBIND nombre-operación-unbind ID

identificador-connection-package }

Fig. 3.31 Macro CONNECTION-PACKAGE para la especificación 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 asimétricos son aquellos en los que cada instancia asume un papel diferente, es decir, consumidor o suministrador. Por el contrario en un puerto simétrico ambas instanciaciones son idénticas. Cuando se utilizan servicios de comunicación OSI un OPERATIONPACKAGE se realiza mediante un ASE específico. nombre-puerto OPERATION-PACKAGE ::= { CONSUMER INVOKES {lista-operaciones}

--operaciones invocadas por el consumidor

SUPPLIER INVOKES

{lista-operaciones}

--operaciones invocadas por el suministrador

OPERATIONS

{lista-operaciones}

--operaciones invocadas por ambos

ID

identificador-puerto

}

Fig. 3.32 Macro OPERATION-PACKAGE para la especificación 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

::=

OPERATION

ABSTRACT-ERROR

::=

ERROR

nombre-operación OPERATION ::= { ARGUMENT

TipoArgumento

RESULT

TipoResultado

ERRORS

{lista-errores}

INVOKE PRIORITY {lista-operaciones-prioritarias} CODE

identificador-operación

}

Fig. 3.33 Macro OPERATION para la especificación de aplicaciones basadas en ROSE

nombre-error

ERROR

::=

{

PARAMETER

TipoParámetro

CODE

identificador-error }

Fig. 3.34 Macro ERROR para la especificación de aplicaciones basadas en ROSE

La macro APPLICATION-CONTEXT se utiliza para definir los aspectos estáticos relacionados con el contexto de aplicación. Es decir, el contrato válido, los servicios OSI que se van a utilizar para el establecimiento y la liberación de la asociación, la transferencia de información y las sintaxis abstractas. nombre-contexto-aplicación

APPLICATION-CONTEXT

::= {

CONTRACT

nombre-contract

ESTABLISHED BY

establecer-asociación

--acse o rtse

INFORMATION TRANSFER BY

unidad-datos

--pData o transfer-by RTSE

ABSTRACT SYNTAXES

{lista -sintáxis-abstractas}

APPLICATION CONTEXT NAME

identificador-contexto-aplicación }

Fig. 3.35 Macro APPLICATION-CONTEXT para la especificación de aplicaciones basadas en ROSE


4 El correo electrónico

75

4 El correo electrónico 4.1 Introducción Aunque correo electrónico es el término más habitual, se utilizará también el término sistema de mensajería electrónica (SME) y, especialmente en un contexto OSI, el término sistema de gestión de mensajes (MHS, Message Handling System) para referirnos a la aplicación distribuida de manejo e intercambio de mensajes mediante redes de ordenadores. Básicamente, un sistema de mensajería electrónica es un sistema de comunicación utilizado para enviar información (mensajes) de una persona (o lugar) a otra (u otro). Esta comunicación también puede ser de una persona a muchas a la vez. Los mensajes electrónicos pueden incluir texto, gráficos, voz, etc., dependiendo del sistema utilizado. En la mayoría de los casos se trata con texto, aunque cada vez es más habitual el intercambio de mensajes multimedia. Los sistemas de telex y facsímil (o fax), predecesores de los SME, transmiten mensajes de un lugar a otro (punto a punto) requiriendo que las máquinas del remitente y del destinatario estén en línea a la vez, mientras que el correo electrónico no tiene este requerimiento. El correo electrónico, como aplicación OSI, inicialmente fue normalizado por el CCITT e n 1984, con la aprobación de las recomendaciones internacionales conocidas como X.400, que tienen el mérito de ser la primera norma del nivel de aplicación del modelo de referencia OSI que se desarrolló. La normalización fue el resultado de la necesidad de interoperabilidad de los sistemas que iban apareciendo en el mercado.


76


La experiencia adquirida con estas recomendaciones y las primeras implementaciones llevaron al CCITT a desarrollar una nueva versión, aprobada en 1988, que corrige muchas de las limitaciones de la versión del 84. Asimismo, la experiencia también sirvió, como se explica en el capítulo 1, para mejorar globalmente el nivel de aplicación. La versión del 88 se publicó también, aunque con pequeñas diferencias, como un estándar de ISO. Finalmente, después de 1988 se han publicado nuevas versiones del estándar/norma que no cambian demasiado la funcionalidad, pero que corrigen y extienden algunas características. De hecho, está prevista una nueva republicación en 1995. La implantación general de las recomendaciones X.400 está llevando a la posibilidad de un uso más generalizado de los SME, dado que está siendo realmente factible la interconexión de sistemas de mensajería de todo el mundo. Todos los sistemas ya existentes, y los nuevos por desarrollar, podrán conectarse de forma generalizada, utilizando X.400, al menos como interfaz con otros sistemas. Es necesario mencionar en este punto, aunque se tratará con más detalle en el apartado 4.10 que, en paralelo con el correo X.400, se ha ido desarrollando, con mucho éxito en los últimos años, otro sistema de correo electrónico más sencillo, aunque igualmente útil, que se conoce como correo Internet.

4.2 Funcionalidad de los SME En esta sección, se presenta la funcionalidad más habitual ofrecida por los sistemas de correo electrónico. 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 estándar. En concreto, las operaciones ofrecidas más habitualmente por los SME son: -

Operaciones de recepción de mensajes: -

-

Enumerar mensajes: da información sobre mensajes disponibles, normalmente para ser leídos, aunque podrían incluso estar pendientes de envío. Leer: para leer (presentar en pantalla o impresora) un mensaje recibido.

Operaciones de envío de mensajes: -

Componer: para preparar un mensaje completo, que incluye la información que el usuario quiere enviar (texto por ejemplo) y parámetros del mensaje (destinatario, prioridad, etc.). Enviar mensaje: envía un mensaje previamente preparado. Esta operación 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 recepción de mensajes.

Operaciones de gestión: -

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 según un criterio determinado, como puede ser la confidencialidad o el nombre del remitente.

4.3 Arquitectura de los SME

4.3.1 Introducción Una idea básica en los SME es que no es necesario que el originador y el destinatario (o destinatarios) de un mensaje estén en línea al mismo tiempo. Esto es así debido a que los SME se basan en la idea de almacenamiento y reenvío (store-and-forward), lo que significa que los mensajes son colocados en el sistema de mensajería cuando el remitente lo desea, independientemente del destinatario. Después, el sistema se encarga de, paso a paso (esto es, la primera máquina que recibe el mensaje, si no es el destino final, lo almacena para ser reenviado a otra máquina, repitiéndose tal proceso hasta llegar al destino), hacer llegar el mensaje a su destinatario. La arquitectura del sistema de mensajería electrónica que se presenta aquí es la estandarizada en las recomendaciones X.400. De cualquier forma, muchos de los conceptos son también válidos en otros sistemas propietarios y en el correo electrónico Internet. Lo que normalmente se conoce como X.400 es un conjunto de recomendaciones relacionadas entre sí. Los números de las recomendaciones y los estándares correspondientes se detallan en la bibliografía anexa. Las recomendaciones X.400 describen un servicio que permite a sus usuarios el intercambio internacional de mensajes utilizando los servicios telemáticos existentes en cada país. El servicio que se define lo proporciona lo que se llama el sistema de gestión 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 presentación y por elementos de servicio de aplicación (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á más adelante, se estandarizó inicialmente la aplicación llamada de mensajería interpersonal. De todas formas, se puede usar el servicio del MTS para cualquier otra aplicación.

Usuario

Otros servicios telemáticos

Usuario

MHS AU

MTS MTA Usuario

UA MTA

Usuario

MTA

MS

UA

Usuario

UA

Usuario

UA MTA

PDAU

Usuario

Servicio de entrega física

Usuario

Fig 4.1 Arquitectura del MHS

El principio general de funcionamiento es que el usuario originador de un mensaje lo envía al MTS para ser entregado a uno o más 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 función de transferencia de mensajes con la técnica de almacenamiento y reenvío. Entre MTA y MTA es necesario un protocolo OSI (o, más precisamente, un contexto de aplicación), el cual se denomina P1. Tanto el usuario originador como el destinatario de un mensaje están 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 (véase 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 través del MTS. Si el UA y el MTA están en máquinas distintas, se define un protocolo de acceso, llamado P3. - Almacén de mensajes (MS, Message Store): Proporciona almacenamiento de mensajes (recibidos desde el MTS), y permite su envío, recuperación y gestión (a instancias del usuario a través de su agente de usuario). El MS se añadió en 1988 para permitir que la recepción de mensajes sea controlada por el usuario. Cuando hay un MS, el UA accede al MTS a través de un MS (el protocolo de acceso del UA al MS se denomina P7 ). Si, además, el MS y el MTA están separados, también es necesario el protocolo P3, antes mencionado, para el acceso del MS al MTA. En la sección 4.7 se trata el almacén de mensajes con más detalle. -

Unidad de acceso (AU, Access Unit): Proporciona interfaz con otros sistemas y servicios de comunicación (servicios telemáticos y servicio postal). Ejemplos de AU son las unidades de acceso a servicios telemáticos más antiguos como telex o teletex; y la unidad de acceso al servicio postal o de entrega física (PDAU, Physical Delivery Access Unit) que especifica, entre otras cosas, cómo mapear direcciones electrónicas sobre direcciones postales (y viceversa).

4.3.3 Modelo de funcionamiento La figura 4.2, que es una extensión de la figura 4.1, presenta el modelo de funcionamiento del MHS.

MTS originador

MTA

destinatario

envío

entrega

UA

UA

transferencia

originador UA

MTA MS

envíoindirecto

MTA

destinatario MS

envío

UA

entrega MTA

recuperación

Fig. 4.2 Modelo de funcionamiento del MHS

Lo que en la figura 4.1 se llama usuario, puede ser una persona o una aplicación en un ordenador. Un usuario en el SME puede ser originador o remitente (originator), cuando envía 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 través 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 están estandarizadas por las recomendaciones aunque sí, por supuesto, su interacción con el MTS y el MS. La operación de envío (submission) de un mensaje se puede hacer directamente del UA al MTA, o indirectamente a través de un MS. El MTS realiza la operación de entrega (delivery) de mensajes a un UA, directamente, o bien a través de un MS. En este último caso, el MS ya tuvo entrega previamente desde el MTS, y la operación entre UA y MS es de recuperación (retrieval), e iniciada por el UA. Por tanto, el MS actúa de intermediario entre el UA y el MTA. El MTS se encarga de entregar el mensaje a uno o más UA, MS, o AU, según 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 Implementación En el MTS, cada MTA se corresponde con una máquina, remota de cualquier otro MTA, por lo que es necesario un protocolo (P1) para comunicarse entre MTA. Normalmente, los MTA se implementan en máquinas grandes que dan servicio a muchos usuarios, ya que deberían 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 están asociados. En muchos casos, se ofrece un UA a cada usuario de las máquinas 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 máquinas remotas a los MTA, entonces sí hay que implementar P3. En estos casos, podría plantearse un acceso desde una máquina no tan grande, como un PC mono-usuario, en el que residiría 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 almacén de mensajes. Con P7, el UA puede estar perfectamente en una máquina mono-usuario, ya que es el UA quien decide cuándo se reciben los mensajes (recuérdese que el MTA entrega los mensajes al MS, quien los guarda hasta que el UA accede a él para recuperarlos). Normalmente además, cuando hay P7 el MS suele ser local al MTA, por lo que no se implementa P3.


81


Existen por supuesto otras alternativas de implementación, como disponer de un MTA en una red local, y que los UA accedan a él desde otras máquinas de la red con protocolos diferentes a los mencionados.

4.3.5 Estructura de un mensaje Los mensajes que se transfieren a través del MTS tienen una estructura normalizada. Un mensaje, tal como esquematiza la figura 4.3, está dividido, básicamente, en dos partes: - Envoltorio o sobre (envelope): Lleva información relacionada con la transferencia del mensaje. Por tanto, esta información la usa el MTS. -

Contenido (content): Es la información que el UA originador desea entregar a los destinatarios (véase 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 información del sobre. Sin embargo, para que dos agentes de usario puedan intercambiarse mensajes correctamente, deben, lógicamente, 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 sección 4.8 se tratará esta cuestión con más detalle.


82


4.4 Direccionamiento

4.4.1 Direcciones Para poder intercambiar mensajes, se necesita algún 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 distribución (conjuntos de usuarios agrupados)

Las listas de distribución se utilizan para simplificar la distribución 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 quiénes 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) dirección de originador/destinatario o dirección 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 dirección O/R un nombre distintivo más una dirección O/R

La dirección O/R es lo que realmente identifica de forma única a un usuario, o a una lista de distribución, por medio de atributos predefinidos. Por ello, en el caso de disponer de un nombre distintivo será necesario obtener la dirección O/R para poder enviar el mensaje. Esto se consigue accediendo al servicio de directorio (véase el capítulo 6) que, a partir de un nombre distintivo, se puede obtener una dirección O/R. De cualquier forma, para disponer de un nombre distintivo es necesario estar registrado en el servicio de directorio. Los atributos más habituales que forman una dirección O/R son: -

País (C, de Country): Un código normalizado que identifica el país. Por ejemplo, ‘es’ para España.



83

- Dominio de gestión de administración (ADMD): Identifica el ADMD al que se pertenece (véase 4.4.2). El ADMD de Telefónica es ‘mensatex’. - Dominio de gestión privado (PRMD): Identifica un PRMD (véase 4.4.2). Por ejemplo, para el caso de las universidades españolas, todas pertenecen al PRMD ‘iris’. -

Organización (O): Un PRMD se puede estructurar en organizaciones, según su propio criterio. En el caso de las universidades, cada universidad se considera una organización del dominio privado ‘iris’. Un ejemplo podría ser la UPC, cuyo valor para este atributo es ‘upc’.

-

Unidad organizativa (OU): Cada organización puede, a su vez, definir varios niveles más de estructura (podrían ser divisiones, departamentos, secciones, grupos, etc., si existen), los cuales se llaman genéricamente 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 sería OU=‘ac’, para el departamento de Arquitectura de Computadores.

- Nombre personal (PN): Finalmente, en el nivel más bajo de la jerarquía, está el nombre personal, que corresponde con usuarios finales de un dominio (que podrían ser tanto personas, como listas o programas). Es criterio del penúltimo nivel de la jerarquía (una OU, una O, o u n PRMD) decidir cómo se asignan estos nombres. Una forma habitual para identificar usuarios es utilizar nombres, apellidos o combinaciones de ambos. Por tanto, una dirección O/R será una secuencia de algunos de, o todos, los atributos previos que, como puede verse, forman una jerarquía que facilita la asignación de nombres, así como las rutas que deben utilizar los MTA para hacer llegar los mensajes a sus destinos. Por ejemplo, el hipotético usuario José López del departamento de Arquitectura de Computadores de la UPC podría tener una dirección 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 gestión Los usuarios del MHS se organizan según lo que se llama dominio de gestión (MD, Management Domain). Un MD está formado por uno o más MTA y cero o más UA, MS y AU, utilizados por una compañía o institución. Normalmente, un dominio de gestión 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 gestión: - de administración (ADMD) - privados (PRMD)


84


Los dominios de administración corresponden a las compañías (o administraciones) responsables del transporte de datos o comunicaciones en un país. En algunos países habrá una sola posibilidad de ADMD, mientras que en otros, donde no existe un monopolio, habrá varias opciones. Normalmente, los ADMD asignarán PRMD a las compañías o instituciones que deseen disponer de un dominio de mensajería electrónica. La figura 4.4 muestra algunas posibles relaciones entre dominios de gestión.

ADMD 1

ADMD 2 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 País A

País B

Fig. 4.4 Posibles relaciones entre dominios de gestión

Un PRMD puede tener, como ya se ha dicho en la definición, varios MTA. Una forma posible de organizar los MTA es en función de cómo se estructura el dominio. Por ejemplo, se podría decidir que cada organización dentro de un PRMD disponga de un MTA, al igual que cada unidad organizativa, por lo que se consigue una relación entre MTA y atributos en la jerarquía de las direcciones O/R que facilita los algoritmos de direccionamiento. El concepto de dominios de gestión va asociado también a cómo se implementa y proporciona el servicio de correo electrónico en una organización. Las dos al ternativas básicas son:


85


-

Implementar (o comprar el software necesario para hacerlo) un MTA y los UA y MS necesarios en función de máquinas 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 también podría ser un PRMD. Un ejemplo sería el servicio Mensatex, comercializado por una filial de Telefónica.

4.5 Realización OSI

4.5.1 Especificación ASDC Hasta ahora, se ha visto la aplicación de correo electrónico desde un punto de vista de funcionalidad y de arquitectura. Se trata, evidentemente, de una aplicación distribuida, por lo que se puede especificar utilizando ASDC, tal como se explica en el capítulo 3. Por ello, las propias recomendaciones X.400 especifican el sistema de mensajería siguiendo las técnicas de ASDC. También 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 mensajería especificado en ASDC, se debe definir cómo se implementa en un contexto OSI.

MHS Envío

Envío

Entrega Usuario-MTS

Entrega MTS

Administración

Usuario-MTS Administración

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 más importantes son el UA y el MS. El número 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 cómo se agrupen sus funciones. Por razones que quedan más claras después, se ha decidido especificar tres puertos, uno para envío (submission), otro para entrega (delivery) y el último para administración (administration). Ahora se podría 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, fácilmente deducibles. Un segundo paso (figura 4.6) podría consistir en especificar la relación 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 envío-indirecto (submission), recuperación (retrieval) y administración (administration).

Recuperación Envío-indirecto Administración

Usuario-MS

MS

Figura 4.6 Relación entre el MS y el usuario-MS

Finalmente, se debería 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 Envío Administración

P3 MTS abstract-service MTA provider

P1

P1 MTA

Transferencia

MTA Transferencia

Entrega Envío Administración

Fig. 4.7 Modelo refinado del sistema de transferencia de mensajes

4.5.2 Protocolos A la hora de implementar la especificación anterior en OSI, cada puerto corresponderá con un elemento de servicio de aplicación (ASE) específico, y cada enlace entre objetos corresponderá con un contexto de aplicación, lo que normalmente se conoce como protocolo. Por tanto, se especifican los protocolos siguientes: -

protocolo entre usuario del MTS y el MTS (asimétrico o de acceso): P3


87


-

protocolo entre usuario del MS y el MS (asimétrico o de acceso): P7 protocolo entre MTA (simétrico o de sistema): P1

Teniendo en cuenta los puertos mencionados, éstos corresponderán con otros tantos ASE, que son: -

elemento de servicio de envío (submission) de mensajes (MSSE) elemento de servicio de entrega (delivery) de mensajes (MDSE) elemento de servicio de recuperación (retrieval) de mensajes (MRSE) elemento de servicio de administración de mensajes (MASE) elemento de servicio de transferencia de mensajes (MTSE)

Los cuatro primeros ASE son asimétricos, mientras que el último es simétrico. Además de estos ASE, se utilizan algunos de los ASE comunes del nivel de aplicación, como son el ACSE, el ROSE y el RTSE. En las siguientes subsecciones se detalla la estructura de los diferentes protocolos o contextos de aplicación.

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 mayoría) corresponderá a un UA y en otros a un MS. Para realizar este acceso, se necesitan tres ASE específicos, 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


MSSEs MDSEs MASEs

Protocolo P3

ROSE

ROSE

ACSE


ACSE


Fig. 4.8 Protocolo P3


88


Además, se necesitarán el ACSE y el ROSE. Si se desea, en algunos casos se puede utilizar un contexto de aplicación distinto, que incluya además 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 almacén de mensajes (MS), los ASE específicos son el MSSE, el MRSE y el MASE. A diferencia del acceso al MTS, en el acceso al MS, sólo el usuario puede establecer una asociación. El protocolo de acceso al MS se conoce como P7. Asímismo, son además necesarios el ACSE, el ROSE y, opcionalmente, el RTSE. En la figura 4.9 se pueden ver las entidades de aplicaci ón necesarias para el protocolo P7.

Usuario de MS

MS

UE

UE

MSSEc MRSEc MASEc


MSSEs

Protocolo P7

ROSE

ROSE

ACSE


MRSEs MASEs

ACSE



4.5.2.3 Protocolo de transferencia En el protocolo de transferencia entre MTA sólo se utiliza un ASE específico, el MTSE, asociado a puertos de transferencia. Además, se necesitan el RTSE y el ACSE. Cualquier MTA puede establecer una asociación con otro MTA. En la figura 4.10 se pueden ver las entidades de aplicación necesarias para el protocolo P1.


89


MTA

MTA

UE

UE

MTSE Nivel de aplicación

MTSE

Protocolo P1

RTSE

RTSE

ACSE

ACSE




4.5.3 Servicios Hasta ahora, sólo se ha visto la visión macroscópica de la especificación en ASDC del sistema de mensajería. Para completar la especificación, es necesario añadir la visión microscópica, es decir, las operaciones que se realizan a través de cada puerto. En lugar de mostrar estas operaciones como una visión microscópica 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 información, independiente de la aplicación. En el servicio de transferencia de mensajes no se tiene en cuenta la información que manejan los UA. Estos, en general, se agrupan en clases de UA cooperantes para proporcionar una aplicación determinada sobre el servicio de transferencia de mensajes. Por tanto, el contenido de la información 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)

Envíomensaje

MTA

Entregamensaje Tranferenciamensaje

MTS

Usuario-MTS

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 aplicación, como el establecimiento y la liberación de una unión (MTS-Bind y MTS-Unbind), el MTS ofrece las siguientes operaciones, agrupadas por puertos: -

Operac Operacion iones es abstr abstract actas as del del puert puerto o de enví envío: o: -

-

Operac Operacion iones es abstr abstract actas as del del puerto puerto de de entreg entrega: a: -

-

Envío de mensaje mensaje:: Es la operació operación n habitual habitual para enviar un mensaje mensaje.. Envío de sonda (probe): Para comprobar si un mensaje podrá ser enviado. Cancelación Cancelación de de entrega entrega diferida: diferida: Para Para cancelar cancelar una orden orden previa previa de entregar entregar un mensaje mensaje de de forma diferida. Contro Controll de envío envío:: Para Para operac operacion iones es de cont control rol..

Entrega Entrega de mensaje: mensaje: Es la operación operación habitual habitual para para entregar entregar un mensaje. mensaje. Entrega de informe (report): Para entregar un informe de cómo ha ido la transferencia de un mensaje. Contro Controll de entre entrega: ga: Para Para oper operacio aciones nes de de contro control. l.

Operac Operacion iones es abstra abstractas ctas del del puerto puerto de admi adminis nistra tració ción: n: -

Registr Registrar: ar: Para Para opera operacio ciones nes de regi registr stro. o. Cambia Cambiarr creden credencia ciales les:: Para camb cambio io de crede credenci nciales ales..

Las operaciones enumeradas son las que se ofrecen, a través de protocolo P3, a los usuarios de MTS. Pero además, 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: -

tran transf sfer eren enci ciaa de men mensa saje je tran transf sfer eren enci ciaa de de son sonda da tran transf sfer eren enci ciaa de inf infor orme me

4.7 Almacén de mensajes Las recomendaciones X.400 definen el servicio abstracto del MS, la estructura de la información a almacenar y los procedimientos de realización. La figura 4.12 presenta los puertos del MS que define la norma.

P7

UA

Recuperación Envío-indirecto Administración

P3

MS

Entrega Envío Administración

MTS

Figura 4.12 El MS y sus puertos

El objeto almacén de mensajes (MS) consta de seis puertos: recuperación (retrieval) y envíoindirecto (indirect-submission) entre UA y MS, entrega (delivery) y envío (submission) entre MS y MTS, y dos puertos de administración a ambos lados. Por lo que respecta al protocolo de acceso al MS, hay, por tanto, tres puertos (recuperación, envíoindirecto y administración). El único puerto totalmente nuevo es el de recuperación (envío-indirecto es equivalente al de envío visto anteriormente). Las operaciones disponibles en el puerto de recuperación son: - Resumir (Summarize): Para obtener una tabla resumen de los mensajes disponibles en el almacén, como por ejemplo cuántos mensajes hay por leer. - Enumerar (List): (List): Para obtener una lista de mensajes con algunos de sus atributos. La lista de mensajes, al igual que en la operación anterior, se selecciona utilizando una interrogación basada en valores de atributos, como originador, tema, et c.


92


- Leer (Fetch): Para obtener uno o más mensajes enteros seleccionados. Los mensajes se copian del almacén al agente de usuario. - Borrar (Delete): Para borrar mensajes en el almacén. - Registrar en MS (Register-MS): Para cambiar algunas características del usuario en el almacén. - Alertar (Alert). Para alertar de la llegada al almacén de mensajes nuevos. Esta última operación, cuando está disponible, es invocada por el MS, a diferencia de las restantes que son invocadas por el UA. La información almacenada en un MS se estructura en tres categorías: -

mensajes almacenados diarios de correo (entrada y salida) diarios de autocorrelación

4.7.1 Mensajes almacenados El almacén de mensajes proporciona un almacenamiento temporal a los mensajes que llegan a un UA (por el contrario, no se almacenan los mensajes que se envían). El MS contiene mensajes (con su envoltorio y su contenido) y un conjunto de atributos añadidos que forman la descripción del mensaje. Estos atributos son, o bien información especial de almacenamiento, o bien información seleccionada a partir de la ya existente en los mensajes propiamente dichos. Ejemplos de atributos añadidos a la información de un mensaje por el servicio de MS son: -

Número de secuencia: se da automáticamente por orden cronológico 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 información 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 información sobre los mensajes que han llegado a un determinado buzón (almacén de mensajes asociado a un UA). El diario de salida (outlog) guarda información de los mensajes enviados a través del MS. Los objetos de los diarios de correo contienen información seleccionada sobre los mensajes entregados al MS (diario de entrada) y enviados por el usuario (diario de salida), aparte de otros atributos añadidos. Los objetos del diario de entrada contienen información como: -

número de secuencia de MS tiempo de entrega información de entrega (atributos dependientes del tipo de mensaje)

Los objetos del diario de salida contienen: -

número de secuencia de envío (generado automáticamente) tiempo de envío información de envío (atributos dependientes del tipo de mensaje)

4.7.3 Diario de autocorrelación El diario de autocorrelación contiene información detallada sobre mensajes enviados por los usuarios del MS y cualquier devolución (notificaciones y respuestas) relacionadas con esos mensajes.

4.8 Mensajería interpersonal El servicio de mensajería interpersonal (IPMS, InterPersonal Messsaging Service) permite a un usuario comunicarse con otro usuario por medio de una clase específica de UA cooperantes, llamados agentes de usuario interpersonales (IP-UA). Como el IPMS utiliza el servicio de transferencia de mensajes, es una aplicación 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 (véase la figura 4.3 anterior): -

cabecera (heading): información asociada al mensaje


94


- partes de cuerpo (body parts): información o informaciones que el usuario desea comunicar Las recomendaciones X.400 incluyen la definición de la aplicación de gestión de mensajes que se ha llamado mensajería interpersonal, especificando el tipo de contenido de los mensajes y los procedimientos de funcionamiento asociados. Todo ello se conoce como protocolo P2, aunque es más 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 información de control que caracteriza al mensaje y lo segundo la información que se desea comunicar. El cuerpo de un IPM puede contener texto, voz, facsímil, etc., o una combinación de todos o algunos de ellos. Los componentes de la cabecera de un IPM son atributos con información para caracterizar el mensaje. No todos ellos tienen que estar presentes en todos los mensajes. Los atributos más importantes son: -

Identificador de IPM: Para identificar de forma única (usando la dirección O/R del originador del mensaje, el tiempo de creación, etc.) el mensaje.

-

Originador: Dirección O/R de quien envía el mensaje.

-

Usuarios autorizantes: Dirección 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 demás. Es decir, los destinatarios principales y de copia no conocen los destinatarios de copia ci ega.

-

En respuesta a IPM: Identificador del mensaje al cual se responde con éste.

-

Obsoletiza IPM: Identificador del mensaje o mensajes que dejan de tener interés una vez se haya recibido éste.

-

IPM relacionados: Identificadores de mensaje o mensajes relacionados con éste. La relación la decide el originador del mensaje.

-

Tema: Texto con el que el originador indica de qué trata el mensaje.

-

Fecha de expiración: Fecha (día y hora) a partir de la cual el mensaje deja de tener interés.



95

-

Hora de respuesta: Día 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 compañía) que el originador da al mensaje.

-

Auto-reenviado: Para indicar si el mensaje es reenviado automáticamente por el sistema de correo del originador o no.

El cuerpo de un IPM está formado por una o más partes independientes llamadas partes de cuerpo. Cada parte de cuerpo puede ser texto (lo es en la mayoría de los casos), voz, facsímil, videotex, documentos normalizados, formatos acordados bilateralmente, etc., aunque no todas estas posibilidades están totalmente detalladas en las recomendaciones. Asimismo, una parte de cuerpo puede ser un mensaje interpersonal reenviado. Un IPM reenviado consta de: -

tiempo de entrega información de entrega (envoltorio) mensaje interpersonal normal

Además de mensajes interpersonales, también se pueden enviar notificaciones interpersonales, que serán de recepción o de no-recepción.

4.8.2 Definición 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 especificación no implica una implementación 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), recepción (reception) y gestión (management). Entre los objetos usuario e IPMS no hay ningún protocolo, ya que la relación es local. Este refinamiento sirve únicamente para especificar formalmente las operaciones propias del IPMS.


96


IPME Origen

Origen

Recepción

Recepción

Usuario

IPMS Gestión

Usuario Gestión

Fig. 4.13 Entorno IPMS

Las operaciones abstractas de cada uno de los puertos son: -

operaciones abstractas del puerto origen: -

-

operaciones abstractas del puerto recepción: -

-

originar sonda originar mensaje interpersonal originar notificación de recepción

recibir informe recibir mensaje interpersonal recibir notificación de recepción recibir notificación de no-recepción

operaciones abstractas del puerto gestión: -

cambiar auto-borrado (borrado automático de mensajes expirados u obsoletos) cambiar auto-reconocimiento (generación automática de notificaciones de recepción) cambiar auto-reenvío (reenvío automático de mensajes recibidos a determinados usuarios)

El IPMS, a su vez, se refinaría igual que el MHS, pero en este caso se dispondría de IP-UA (InterPersonal User Agent) en vez de UA, y los MS serían específicos de mensajería interpersonal (IP-MS).

4.9 Extensiones a las recomendaciones X.400 Las recomendaciones X.400 de 1988, que incorporan todas las características descritas más otras tan importantes como la seguridad, son las que se implementan actualmente. Sin embargo, el esfuerzo de estandarización está continuando, habiéndose publicado últimamente nuevas versiones y extensiones que tratan de mejorar algunas deficiencias y añadir más capacidades, por ejemplo en el tema de gestión de la mensajería o en nuevos agentes de usuario.



97

4.10 Correo Internet

4.10.1 Introducción El correo Internet es un servicio de mensajería electrónica basado en almacenamiento y reenvío, e independiente de los subsistemas de transmisión. Debido a esta característica, este servicio sólo necesita un canal fiable de datos entre los sistemas de mensajería, 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 estándares si guientes: -

SMTP (Simple Mail Transfer Protocol) o RFC 821: Especifica el protocolo por el cual un sistema de mensajería actuando como emisor puede intercambiar mensajes con otro sistema de mensajería que actúa de receptor. En este estándar se especifican, además 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 través de Internet, e independiente de los subsistemas particulares de transmisión. Es un protocolo muy simple, en el cual la comunicación entre el cliente y el servidor se realiza a través 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 reenvío, la comunicación entre el emisor y el receptor siempre es un diálogo 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 comunicación 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 conexión 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 máquina donde se encuentra el destinatario, el mensaje es introducido dentro del buzón de usuario correspondiente.

Cola correo de salida Conexión TCP Agente de usuario

Mensajes en la cola

Emisor SMTP

Receptor SMTP

Buzones de usuarios

Fig. 4.14 Modelo de comunicación SMTP / RFC 821

Cabe reseñar que el receptor SMTP tanto puede ser el destino final como un destino intermedio más 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 máquina, 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 Comunicación a través de sistema intermedio

4.10.2.2 Direccionamiento Para el envío de un mensaje a un usuario es necesario conocer su dirección electrónica. Este usuario, que se encuentra en una máquina conectada en algún lugar dentro de un dominio, tendrá una dirección electrónica de la forma: usuario@nombre_dominio . La segunda parte de la dirección electrónica es un nombre de dominio tal y como se define en DNS (véase apartado 6.2). Con este tipo de direccionamiento electrónico, el mensaje es enviado a la máquina identificada por la parte de la dirección que se halla a la derecha del signo @ (esto es, nombre_dominio ). El proceso emisor SMTP utiliza el DNS para obtener la dirección física (IP) de la máquina destino. Una vez en



99

esta máquina, el mensaje es entregado al usuario identificado por la parte de la dirección 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 conexión directa con el proceso receptor. Generalmente, a nivel de dominio siempre se dispone de una máquina servidora de correo que es la encargada de centralizar los procesos de transmisión y recepción 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 línea). Cada uno de los comandos está formado por una cadena de caracteres alfanuméricos con un código de comando y en algunos casos un parámetro. El parámetro se separa del código mediante un espacio en blanco. La lista de los comandos permitidos en SMTP es la siguiente: -

Identificación del emisor SMTP. Inicio de transacción de correo. Inicio de una transacción de entrega en el terminal o de correo. Inicio de una transacción de entrega en el terminal y de correo. Identificación de un receptor individual. Envío del mensaje. Aborto de la transacción actual. Inicio de una transacción de entrega en el terminal. Confirmación de identificación de un usuario. Petición de confirmación de una lista de correo. Petición de ayuda. Cierre del canal de transmisión. 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 línea en blanco del mensaje. -

Cabecera: La cabecera es un conjunto de campos estructurados que proporcionan información sobre el mensaje. Cada línea de la cabecera es un campo diferente, excepción hecha de si


100


empieza con un carácter de espacio en blanco, en cuyo caso esa línea es continuación de la anterior. La estructura de cada uno de los campos es de la forma: nombre-campo[: cuerpo-del-campo] Los campos más importantes son: Date : fecha de envío 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 líneas 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: [email protected] Subject: Aquí el tema sobre el que va el mensaje To: [email protected] Message-ID: 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 interconexión llamados pasarelas de correo que permiten a usuarios de sistemas de mensajería X.400 intercambiar mensajes con usuarios de correo Internet. Para conseguirlo, las pasarelas de correo deben realizar un proceso de transformación entre los dos formatos de mensajes que no siempre se puede realizar conservando toda la información que figura en el formato original del mensaje. Como el formato de un mensaje X.400 es más 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 transformación comportará pérdida de información.

4.10.4 Diferencias SMTP - X.400 Algunas de las diferencias más importantes entre SMTP y X.400 son que en SMTP:



-

101

Los mensajes no tienen sobre. No existe almacén de mensajes. Los mensajes sólo pueden ser monocuerpo. La cabecera y el cuerpo sólo pueden contener caracteres US-ASCII. La transferencia es sólo de caracteres de 7 bits. Existen menos facilidades: - No existe confirmación de recepción - Sensibilidad - Fecha de expiración - Mensajes obsoletos ni no válidos - Prioridad - Destinatarios alternativos - Entrega diferida - Fecha límite de entrega - Devolución del contenido, etc.

4.11 MIME

4.11.1 Introducción Los sistemas de correo Internet basados en los estándares 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 estándar [RFC1341] de extensiones multipropósito al correo Internet (MIME, Multipurpose Internet Mail Extensions). MIME mantiene la compatibilidad con los sistemas de correo Internet antiguos basados en los estándares [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 información correspondiente a gráficos, voz, vídeo, etc. Los mensajes MIME pueden ser estructurados, es decir, se pueden generar mensajes con diferentes tipos de información, como texto, gráficos, 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 capítulo, la primera versión 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 líneas de un mensaje, que está limitada a mil caracteres. Este


102


problema también se resuelve en MIME gracias al proceso de codificación/decodificación para la transferencia de mensajes (véase el apartado 4.11.2) . Para que un usuario de correo electrónico pueda enviar y leer mensajes multimedia de forma transparente es necesario normalizar: -

Los procesos de codificación/decodificación para la transferencia de los mensajes Los formatos de los contenidos de los mensajes

4.11.2 Tipos de codificación para la transferencia La mayor parte de los métodos que permiten representar información de texto, imágenes, vídeo, voz, etc., están basados en la utilización de códigos de ocho bits. Dos usuarios de correo MIME pueden intercambiar mensajes utilizando el protocolo SMTP extendido para transferir información de ocho bits (RFC 1426, SMTP Service Extension for 8bit-MIME Transport). Actualmente esta opción es muy poco utilizada debido a que los sistemas de correo MIME están 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 razón 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 (véase la figura 4.16).

Usuario MIME

Contenido mensaje MIME

Codificación 8 bits a 7 bits

SMTP 8 bits (RFC 1426) SMTP 7 bits (RFC 821/822)

Contenido mensaje MIME

Usuario

Decodificación 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 información codificada en ocho bits) se transfiera utilizando el protocolo SMTP (que es un protocolo basado en un código de 7 bits) es necesario utilizar algún método de codificación que permita transportar octetos sobre septetos. Además, es necesario que estos procesos de codificación/decodificación sean normalizados, ya que es la única manera de garantizar tanto la compatibilidad entre los diferentes sistemas de correo como la utilización de los mismos de una forma transparente para el usuario. Los sistemas de correo MIME suelen permitir que los usuarios puedan escoger el método de codificación a aplicar a los mensajes en función del tipo de información que contengan. El tipo de



103

codificación se indica en un campo opcional de la cabecera del mensaje llamado “codificación de transferencia de contenido” (Content-transfer-encoding) que tiene el siguiente formato: Content-transfer-encoding: Content-transfer-encoding: tipo de codificación Los valores permitidos para el tipo de codificación son: -

‘7bi ‘7bit’ t’,, ‘8b ‘8bit’ it’ y ‘bi ‘bina nary ry’’ ‘quo ‘quote tedd-pr prin inta tabl ble’ e’ ‘base64’

En realidad, los tipos de codificación ‘7bit’, ‘8bit’ y ‘binary’ no aplican ningún tipo de codificación. Los dos primeros primeros corresponden a mensajes mensajes de texto codificados respectivamente respectivamente en ASCII de 7 bits y 8 bits, pero con longitudes de línea compatibles con SMTP. En el caso de utilizar el tipo de codificación ‘8bit’ el mensaje puede contener caracteres no US-ASCII. El tipo de codificación ‘binary’ permite utilizar líneas de cualquier longitud, y por lo tanto no necesariamente compatible con SMTP. El tipo de codificación ‘quoted-printable’ se puede considerar una semicodificación o codificación blanda, en el sentido de que únicamente se codifican los caracteres no US-ASCII. Estos caracteres se codifican con la secuencia formada por un carácter de escape (ESC) más un carácter del código original US-ASCII. El resultado de este tipo de codificación para un usuario de correo SMTP es que obtiene un mensaje bastante legible. Finalmente, el tipo ‘base64’ consiste en aplicar una codificación para pasar de un mensaje que contiene 8 bits de información a otro que se pueda transportar con siete bits. En concreto consiste en convertir cada 3 octetos de 8 bits de información (24 bits de información) en 4 octetos con 6 bits de información cada uno (contienen también 24 bits de información). Este tipo de codificación expande la información a transmitir un 33%. A cada uno de los 6 bits obtenidos se le asocia el carácter equivalente utilizando un juego de caracteres de 6 bits (caracteres A-Z, a-z, 0-9, +, /). Si faltan octetos para llegar a un múltiplo de 3, se añaden ‘=‘ al final. El resultado para un usuario no MIME (por ejemplo SMTP) sería un mensaje totalmente il egible. Por ejemplo, al aplicar el tipo de codificación ‘base64’ a la secuencia de octetos ‘ABC’ (US-ASCII 65, 66 y 67), se convierte en la secuencia ‘QUJD’ (que en un código de 64 caracteres corresponde a 16, 20, 9 y 3).

4.11.3 Tipos de contenido contenido de los mensajes Para garantizar la compatibilidad entre los diferentes formatos existentes para representar cada tipo de información, MIME ha estandarizado un conjunto reducido de tipos de contenido diferentes (texto, gráficos, audio, vídeo, 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 información referente al contenido. Este campo llamado “tipo de contenido” (Content-type) tiene el siguiente formato: Content-type: tipo / subtipo [;parámetro] La siguiente tabla incluye los tipos, subtipos y parámetros normalizados en el primer estándar de MIME.

Tabla 4.1 Tipos de contenido de de un mensaje MIME

Tipo text image

Subtipo

Parámetros

text

charset=ISO-8859-[1-9] / US-ASCII

richtext

charset=ISO-8859-[1-9] / US-ASCII

gif jpeg

audio

basic

video

mpeg h261

multipart

message

mixed

boundary

alternative parallel digest

boundary boundary boundary

rfc822 partial external-body

application

octet-stream PostScript ODA

Por ejemplo, un mensaje MIME de texto que utiliza el conjunto de caracteres ISO-8859-1, válido 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 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 información adicional respecto al contenido de los mensajes. Algunos de estos campos son los siguientes: El campo de “descripción del contenido” (Content-description) sirve para asociar alguna i nformación descriptiva a un cuerpo de mensaje. El formato es el siguiente:



105

Content-description: descripción 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 Arquitectura de documentos 5.1 Necesidad de normalización de la arquitectura de documentos

Por medio de los sistemas de comunicación electrónica actualmente en uso, es posible intercambiar documentos. Por ejemplo, el correo electrónico es uno de estos medios de comunicación (véase el capítulo 4). Sin embargo, el contenido de la información que se transmite no tiene por qué estar estructurado como un documento.

Formato local C

Formato local A Formato estándar 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 día, también es un sistema de comunicación electrónica, pero tiene la desventaja de que el documento recibido no se puede reprocesar fácilmente. Si, por ejemplo, se quiere reutilizar en otro documento información recibida por fax, probablemente no habrá más remedio que reescribir su contenido, con el coste que esto supone. Para que el intercambio electrónico 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 gestión y procesado de documentos sólo tiene que preocuparse de conocer el formato estándar, con lo que los usuarios pueden seguir trabajando independientemente del estándar. Esto se ve gráficamente en la figura 5.1. En los últimos años, se ha realizando un gran trabajo de normalización en este campo. Lo primero que se hizo fue definir un modelo para describir cómo 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 codificación de los documentos cuando se intercambian. El estándar ODA se publicó por primera vez en 1989. Actualmente, se han realizando correcciones y extensiones de la norma, republicada en 1994. Posteriormente, se están 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 estándar de representación e intercambio de documentos como ODA. Se pueden enumerar algunos de ellos: - Resuelve el problema de equipos de suministradores diferentes, permitiendo la integración de información procesable generada en sistemas diferentes. - Protege inversiones ya realizadas en equipo de automatización de oficinas. Esto se realiza mediante la utilización de convertidores y la sustitución gradual de los sistemas de procesado y gestión de documentos. - Facilita la transferencia de documentos. Con ODA no hay pérdida de información en cada transferencia. Se puede, además, realizar un intercambio “electrónico” de documentos (X.400, protocolos de transferencia de ficheros, disquetes, ...). - Permite tener un almacenamiento común para todos los documentos. A este almacén podrán acceder sistemas presentes y futuros. - Facilita la “búsqueda” de documentos, pues en un documento ODA se incluye información de gestión 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 extensión aparecida en 1994). - Facilita la producción de formularios y documentos con estructura predefinida, mediante los estilos y las estructuras genéricas. 5.2 Situación del estándar ODA

Las primeras ideas sobre lo que hoy en día es el estándar ODA surgieron a principio de los ochenta y han ido evolucionando, y siguen haciéndolo, hasta ahora. La norma ha sido, y está siendo, desarrollada por un comité conjunto de ISO/IEC e ITU-T, y su primera versión se publicó, como se ha dicho, en 1989. Aquella versión consta de 7 partes, que son: -

Parte 1: Introducción 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 gráficos de puntos. Parte 8: Arquitectura de contenido de gráficos geométricos.

Nótese que no existía la parte 3. Ello es debido a razones del desarrollo original del estándar. También se puede deducir de los títulos de las diferentes partes que un documento ODA incluye cuatro conceptos básicos, como son la estructura (véase apartado 5.3.2), el perfil (véase apartado 5.3.4), el formato de intercambio (véase apartado 5.5) y las arquitecturas de contenido (véase apartado 5.3.3). Después 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 republicación de las 7 partes en 1994. Además, se han desarrollado, o se están desarrollado, otras nuevas partes que tratan otros tantos nuevos conceptos. Estas son: - Parte 10: Especificación formal de ODA (la primera versión se publicó en 1991, y una segunda ha sido publicada en 1995). - Parte 3: Interfaz abstracto para la manipulación de documentos ODA (publicada en 1995). Se trata con más detalle en el capítulo 7, pues tiene mucho que ver con acceso remoto a documentos.


110


- Parte 9: Arquitectura de contenido de audio (publicada en 1995). Especifica cómo poder incluir información audio en documentos ODA. - Parte 11: Estructuras tabulares y layout de tablas (publicada en 1995). Especifica características complejas para tablas. - Parte 12: Identificación de fragmentos de documento (publicada en 1995). Al igual que la parte 3, se explica en el capítulo 7. - Parte 14: Relaciones temporales y estructuras no lineales (a publicar en 1996). Trata la posibilidad de añadir características de hiperdocumentos a los documentos ODA. 5.3 Documentos ODA

El estándar ODA define una representación de documentos con el objetivo de intercambiarlos entre sistemas de procesado de documentos heterogéneos. Permite especificar documentos procesables (es decir, revisables) y/o formateados. Actualmente, ODA permite contenidos representados como caracteres, gráficos o imágenes de puntos (raster), gráficos geométricos y, recientemente publicado en 1995, audio. Información de color es también posible en la versión 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 relación con otros constituyentes. El estándar enumera qué atributos se pueden especificar para cada tipo de constituyente y sus posibles valores. Los tipos de constituyentes más comunes son: el perfil de documento (véase apartado 5.3.4), estilos (véase apartado 5.3.2), porciones de contenido (véase apartado 5.3.3) y componentes (véase apartados 5.3.1 y 5.3.2). 5.3.1 Estructuras lógica y física

En una primera visión, un documento tiene dos estructuras: - Estructura lógica: Subdivide el documento en capítulos, secciones, párrafos, apéndices, etc. - Estructura de aspecto o física (layout): Da su disposición en el medio de representación; es decir, páginas, áreas en páginas, márgenes, separaciones, etc.



111

El modelo de arquitectura de ODA se basa en un enfoque declarativo, es decir, las estructuras (sean lógicas o físicas) no se expresan implícitamente por medio de caracteres de control dentro del contenido del documento, sino que se dan explícitamente por medio de una jerarquía de componentes (un caso particular de constituyentes), formando una estructura en árbol. Además de las relaciones jerárquicas entre componentes, también existen relaciones no jerárquicas, como referencias a notas a pie de página, por ejemplo. Finalmente, se pueden expresar por medio de atributos otras muchas características, como tamaño, dimensiones, alineado, etc. Como se ha dicho, cada una de las dos estructuras, lógica y física, se expresa por medio de una jerarquía 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 lógica son: - Raíz lógica de documento: Primer nivel de la estructura. - Objeto lógico compuesto: No tiene contenido real, sino que contiene otros objetos compuestos o lógicos. Ejemplos serían capítulos o secciones. - Objeto lógico básico: El nivel más bajo de la jerarquía (por ejemplo, un párrafo). Tiene asociadas las porciones de contenido del documento, como texto o imágenes. Análogamente, para la estructura física: - Raíz física de documento: Máximo nivel. - Conjunto de páginas . - Página: Área de dos dimensiones sobre la que se posiciona y representa el contenido de un documento. - Marco (frame): Área rectangular de una página. Su contenido se puede formatear, lo que produce bloques dentro de los marcos. - Bloque: Su contenido es de un solo tipo. Por ejemplo, sólo texto o sólo gráficos. Son los únicos objetos físicos que tienen asociadas porciones de contenido directamente. 5.3.2 Estructuras genérica y específica. Estilos

Los objetos con un conjunto de propiedades comunes se conocen como instancias de una determinada clase de objeto. Un documento puede contener cualquier número de clases de objetos lógicos y/o físicos, que forman su estructura genérica.


112


Las clases de objetos se pueden utilizar para agrupar características de una serie de objetos (factorización) y para describir las relaciones permitidas entre ellos, dando de esta manera una referencia para crear nuevos objetos. Las porciones de contenido (véase apartado 5.3.3) se pueden asociar también con clases de objetos básicos (por ejemplo, contenido a imprimir al principio de cada página, como un logotipo). La estructura real (lógica o física) de un documento concreto se llama estructura específica y consta de un conjunto de objetos enlazados con relaciones de subordinación que forman la estructura en árbol mencionada en 5.3.1. También existe la estructura genérica, que es un conjunto de descripciones de clase de objeto, que constan, básicamente, de reglas de construcción que ayudan a obtener la estructura específica. Otro tipo de constituyentes que puede haber en un documento son los estilos, cuyos atributos se utilizan para dar determinadas características a los objetos con los que están asociados. Para ello, los estilos de documento definen cómo mapear estructuras lógicas sobre estructuras físicas. Hay dos tipos de estilos: - Estilos físicos (layout styles): Están asociados a constituyentes lógicos. Sus atributos dirigen el proceso de creación de la estructura específica física. Un ejemplo de estos atributos es el “offset”. - Estilos de presentación (presentation styles): Están asociados a constituyentes básicos. Sus atributos guían la apariencia del contenido en el medio de presentación; es decir, describen objetos físicos. Un ejemplo de estos atributos es el “espaciado de línea”. 5.3.3 Contenidos

El contenido de un documento, incluido en objetos llamados porciones de contenido, está asociado directamente con sus objetos básicos, es decir, aquéllos sin objetos subordinados (las “hojas” del árbol). Un objeto básico y su contenido deben corresponder a una de las arquitecturas de contenido definidas en el estándar, las cuales se detallan posteriormente. Una porción de contenido se puede asociar a un objeto lógico básico, a un objeto de layout básico, o a ambos. En el último caso, pertenece a la vez a la estructura específica lógica y a la estructura específica de layout. La figura 5.2 muestra la estructura específica de un documento formateadoprocesable muy simple, que consta de una portada y un cuerpo con 3 párrafos. El segundo párrafo se imprime al final de una página 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 están asociados solamente a los


113


objetos básicos de la estructura). Por ahora, en ODA se han definido las siguientes arquitecturas de contenido: - Caracteres (character content architecture). La información de contenido se representa como una cadena de caracteres combinando caracteres gráficos, el carácter “espacio” y funciones de control. Se utiliza la codificación de caracteres definida en el estándar ISO 2022. - Gráficos de puntos, o no estructurados (raster graphics content architecture). En la primera versión de ODA sólo se consideraron gráficos en blanco y negro, pero en la de 1994 ya existe la posibilidad de intercambiar gráficos en color. La codificación de puntos sigue los estándares más habituales, como fax Grupo III y fax Grupo IV (recomendaciones T.4 y T.6), además de simple bitmap. - Gráficos geométricos (geometric graphics content architecture). Sigue las reglas definidas por el estándar CGM (Computer Graphics Metafile). - Audio (audio content architecture). Publicada en 1995, especifica cómo usar, dentro de documentos, los diferentes formatos de codificación de audio.

raíz lógica

cabecera estructura lógica

cuerpo

título

autor

párrafo

párrafo

párrafo

contenido

contenido

contenido

contenido

contenido

contenido

bloque

bloque

bloque

bloque

bloque

bloque estructura de layout

página frontal

página recto

page set de cabecera

página verso

page set del cuerpo raíz de layout

Fig. 5.2 Ejemplo de estructura específica lógica y de layout


114


El estándar ODA puede extenderse fácilmente por medio del interfaz entre la estructura de documento y el contenido de documento. Las arquitecturas de contenido definidas por ahora pueden ser fácilmente ampliadas sin tener que modificar, sólo extender, el estándar actual. Esto es lo que se ha hecho por ejemplo, para añadir 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 específicas y porciones de contenido, se ve como una instancia de una clase de documento descrita en la descripción de clase de documento. Esta consta de tres componentes:

Perfil de documento

Clases de objetos lógicos

Porciones contenido

Porciones contenido

Clases de objetos de layout

Estructura lógica gen érica

Estructura de layout genérica

Estructura lógica esp ecífica

Estructura d e layout e specífica

Porciones contenido Objetos lógicos

Porciones contenido

Estilos de layout

Objetos de layout

Estilos de presentación

Fig. 5.3 Constituyentes de un documento ODA

- Estructura lógica genérica: Es un conjunto de descripciones de clase de objeto lógico, que constan, básicamente, de reglas de construcción que permiten saber cómo calcular los valores de los atributos. Además, pueden existir porciones de contenido genérico, que ayudan a crear contenido predefinido.



115

- Estructura de layout genérica: Similar a lo anterior, pero respecto al layout. - Estilos de documento: Estilos de layout y estilos de presentación (véase apartado 5.3.2). Finalmente, todos los atributos que especifican propiedades de un documento completo están contenidos en un constituyente llamado perfil de documento. Es decir, el perfil de documento es un conjunto de atributos que especifican las características de un documento visto como algo compacto e independiente. Incluye información 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 gestión como “título”, “palabras clave”, “fecha de creación”, “autores”, “referencias a otros documentos”, etc. 5.4 Procesado de documentos ODA

El estándar define tres clases de arquitectura de documento: - Formateado : Esta forma de intercambio sólo permite reproducir el documento tal como se envió. Básicamente, lo que se transmite es la estructura específica de layout y el contenido formateado. - Procesable: Permite que el receptor pueda procesar el documento recibido. En este caso, se transmite la estructura lógica y el contenido procesable. También podría transmitirse la definición 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 reproducción. El modelo de procesado de documentos ODA define tres diferentes procesos que se pueden realizar sobre un documento (véase la figura 5.4): - Edición: Procesado (creación o corrección) de la estructura lógica específica y del contenido. - Layout: Consiste en la creación de una estructura de layout específica, a partir de una estructura lógica, y el formateado del contenido. - Materialización (imaging): Materialización o visualización del documento en un medio de presentación (papel, pantalla, ...). Utiliza los estilos de presentación y la estructura de layout específica.


116


Proceso de edición

Proceso de layout

Documento procesable

Documento formateado Proceso de edición

Proceso de layout

Documento formateado procesable Proceso de materialización

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 información de la descripción 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 aplicación de documentos ODA

El estándar ODA es complejo y, dependiendo del tipo de documento, a veces no son necesarias todas las características del estándar. Para simplificar las aplicaciones ODA, se define el concepto de perfil de aplicación de documento (DAP, Document Application Profile), que es la especificación de un subconjunto de las características disponibles en el estándar 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 están definidos de forma jerárquica, de los cuales



117

FOD011 es el perfil de menor funcionalidad y FOD036 el de mayor funcionalidad. Además, existen dos perfiles para aplicaciones de procesado e intercambio de imágenes 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 también a cualquiera de los que le siguen en esta jerarquía de DAP, así como al estándar 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 están siendo adoptados por el CEN/CENELEC (organismo de normalización europeo responsable de los estándares funcionales), puesto que los DAP son estándares funcionales de ODA. De cualquier forma, los DAP definidos por los diferentes organismos han convergido en una serie de DAP internacionales. A través 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 básico (Basic Character Content), es el DAP de nivel 1. Este perfil soporta documentos tipo carta o informe, generados con sistemas básicos: documentos con estructuras lógica y física simples, y con contenido sólo de caracteres. El perfil FOD011 permite: -

Las 4 estructuras (lógica específica, de layout específica, lógica genérica y de layout genérica) Páginas primera, recto y verso con cabecera, cuerpo y pie de página Páginas con numeración automática y una sola columna de contenido Texto con caracteres de control y con estructura lógica lineal Características de formateado y presentación como tabulaciones, márgenes, separaciones de párrafos, control de líneas viudas y huérfanas, 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 lógica y de layout más complejas, y con contenido de caracteres y gráficos. Este es el perfil más utilizado actualmente. El perfil FOD026 permite: - Todas las características del perfil FOD011 - Multicolumnas periodísticas y sincronizadas - Notas al pie de página


118


- Segmentos numerados formando estructura lógicas en forma de árbol - Gráficos 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 edición de publicaciones (Desktop publishing): documentos con estructuras lógica y de layout aún más complejas, y con contenido de caracteres y gráficos. El perfil FOD036 permite: -

Todas las características del perfil FOD026 Títulos en pasajes y segmentos numerados Frases como agrupación de caracteres Figuras con título y descripción 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 imágenes raster. El perfil FOD112 permite: - Documentos con información de gestión en el perfil - Imágenes 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 página - Tantas páginas, y de tamaño hasta A0, como se desee 5.6.5 FOD126

Este perfil soporta documentos consistentes en imágenes raster, imágenes vectoriales o caracteres. El perfil FOD126 permite: - Todas las características del perfil FOD112 - Imágenes raster, imágenes vectoriales, y caracteres - Anotaciones como revisión a un original


119


5.7 Otros estándares de documentos: SGML

5.7.1 Principios básicos

En épocas anteriores al procesado automático de documentos, los editores de publicaciones utilizaban el marcaje (markup) manual de los manuscritos con una serie de instrucciones específicas, tal como se puede ver en la figura 5.5, que eran utilizadas posteriormente, en el momento de la composición, con el fin de crear el formato y la apariencia final deseados. Se puede apreciar que este tipo de marcaje presenta las siguientes características: - 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 añadir marcaje (markup) específico a los manuscritos electrónicos. Este marcaje ya consistía en instrucciones de procesado, y que también se hallaban separadas del documento en sí, pero en el formato específico del lenguaje del programa utilizado para el formateado del documento. El estándar de lenguaje de marcaje generalizado (SGML, Standard Generalized Markup Language) [SGM0186] [SGM0288] apareció con la intención de normalizar el marcaje de documentos. Por este motivo, SGML se basa en los siguientes principios básicos:


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 técnicas informáticas también puedan ser utilizadas para el procesado de los documentos. SGML es un lenguaje, en el sentido de un lenguaje informático, para la descripción de la estructura de documentos electrónicos y su codificación mediante caracteres ASCII. SGML utiliza marcaje general, independiente del sistema, entorno o aplicación, para la descripción de la estructura de un documento. SGML es un lenguaje flexible que permite la representación de las características de un documento. Como tal lenguaje, no tiene limitaciones en las características que permite representar, sino que son los entornos reales existentes quienes imponen las limitaciones. SGML es principalmente un medio para la definición y descripción de la estructura lógica específica de un documento. Las especificaciones de los estilos, que dan la apariencia visual del documento, también se pueden representar utilizando una sintaxis SGML llamada instancia de especificación de salida de formateado (FOSI, Formatting Output Specification Instance). 5.7.2 Documento SGML

Un documento SGML se puede ver como una jerarquía de elementos formando una estructura lógica específica 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 representación estándar. Todo documento SGML puede estar formado por: - Definición de la estructura lógica genérica a seguir - Definición de los estilos aplicables - Contenido con estilos y con estructura lógica específica Además de todos estos elementos, también se debe tener en cuenta la manera cómo se introduce toda la información dentro del documento. 5.7.3 Marcaje

A un documento SGML es necesario: - Dotarlo de una estructura lógica.



121

- Dotar de formateado al contenido de información. Por este motivo, al contenido de los datos se le añade una información general, independiente del sistema, entorno o aplicación. Esta información se introduce mediante el marcaje, con lo se puede decir que cualquier documento SGML consta de dos tipos de información: datos y marcaje. El marcaje de un trozo de contenido consiste en un marcador inicial (start-tag), de la forma , al inicio y un marcador final (end-tag), de la forma , al final, los cuales definen las características 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 específica 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 lógica. Una vez definido el modelo, éste puede ser utilizado para validar de forma rigurosa la estructura específica 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 definición de tipo de documento (DTD, Document Type Definition). Los DTD son las especificaciones que dan las reglas de cómo estructurar el documento desde el punto de vista lógico. Es decir, un DTD especifica la estructura lógica genérica. Todo documento SGML tiene asociado un DTD, el cual define qué elementos lógicos pueden o deben encontrarse, en qué orden, en qué contexto jerárquico y cuáles son los marcadores a utilizar. Cabe destacar que los DTD no están 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 también se pueden definir formalmente. Estas reglas se agrupan en estilos, los cuales se especifican en formato FOSI, antes mencionado. Una especificación FOSI permite definir las características de los estilos, que son aquellas que dan una apariencia visual al documento, como pueden ser los fuentes, los espaciados de línea, los márgenes, etc. Cualquier documento puede tener asociado una especificación FOSI, la cual define qué estilos pueden encontrarse, sus características, y cuáles son los marcadores a utilizar.


122


5.7.6 Contenido

Todo documento, y por lo tanto también 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 características, tanto desde el punto de vista lógico como desde el punto de vista de apariencia visual. Estas características se aplican al contenido utilizando marcadores, los cuales han de seguir unas reglas que vienen fijadas asociando un DTD y, opcionalmente, una especificación FOSI a cada documento SGML. Debido a esto, el contenido de un documento SGML puede ser de cualquier tipo, y la única restricción 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 especificación FOSI asociada. 5.7.7 Ejemplo de documento SGML

Como ejemplo se puede tomar la siguiente codificación de la estructura lógica específica de un documento utilizando SGML: ... Título de la sección Este es un texto de ejemplo para ver cómo 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 párrafo. ...

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, también se ve que existen dos tipos diferenciados de marcadores: - Los que forman la estructura del documento: ‘paratitle’, ‘parabody’ y ‘para’. El significado lógico de estos marcadores se encuentra en el DTD asociado al documento. - Los que dan características de apariencia visual: ‘times_12’, ‘times_9’, ‘bold’, ‘italics’ y ‘uline’. A su vez, ‘paratitle’, ‘parabody’ y ‘para’ también pueden implicar ciertas características visuales. El significado, desde el punto de vista de aspecto final del documento, de estos marcadores se encuentra en la especificación FOSI asociada al documento. A continuación se presenta un posible aspecto del texto una vez formateado:



123

Título de la sección Este es un texto de ejemplo para ver cómo 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 párrafo.


6 El servicio de directorio

125

6 El servicio de directorio 6.1 El Directorio de OSI

6.1.1 Introducción El Directorio es una aplicación distribuida definida dentro de la arquitectura de sistemas abiertos (OSI) para dar soporte a la asignación de nombres, almacenamiento, búsqueda, catálogo y gestión de información relacionada con objetos OSI. En particular, un objeto OSI puede ser un usuario humano, un proceso de aplicación, un nodo de red, etc. La palabra Directorio siempre aparecerá iniciada con mayúscula cuando nos refiramos al sistema distribuido OSI. Por el contrario, aparecerá iniciada con minúscula cuando nos refiramos al término general de catálogo o guía. Se debe mencionar que las traducciones oficiales existentes al castellano utilizan la palabra Guía para referirse al término inglés Directory. Sin embargo, aquí se opta por el uso del término Directorio. Una de las principales misiones del Directorio es la de proveer mecanismos para construir y manipular nombres amigables (esto es, fáciles 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 información 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 diseñado pensando en los requerimientos de directorio necesarios en las aplicaciones OSI y en los servicios de telecomunicación. 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 número de interrogaciones (lectura de información) al sistema siempre será muy superior al número de actualizaciones (escritura de información). El Directorio aísla a los usuarios de los cambios frecuentes de una red con la introducción de nombres para sus componentes. De esta forma, por ejemplo, una máquina o una entidad de aplicación pueden identificarse mediante un nombre único y permanente que lo independice de una dirección física de red o de una dirección de presentación respectivamente. Al mismo tiempo, el Directorio proporciona una visión más amigable de la red en cuanto los nombres son más manejables por los humanos que las direcciones físicas. El Directorio se encuentra definido en la Recomendación ITU-T X.500 y en el estándar internacional ISO/IEC 9594 [DIR0194 ]. Ambos son documentos técnicamente alineados, esto es, su contenido es idéntico.

6.1.2 Visión general del Directorio El Directorio es un conjunto de sistemas abiertos que cooperan para establecer una base de datos lógica con información 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 información, o parte de ella, almacenada en el Directorio, siempre y cuando tengan permiso para realizar tal acción. 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 información almacenada en el Directorio se denomina de una forma general Base de información del directorio (DIB, Directory Information Base). Esta información se encuentra distribuida a lo


127


largo de los sistemas que forman el Directorio global. En particular, existirán varios agentes de sistema de Directorio (DSA, Directory System Agent) encargados de proporcionar acceso a los usuarios (a través de los DUA) a las diferentes partes del DIB (Fig. 6.2). Los DSA cooperarán entre ellos para poder proporcionar a los usuarios la visión de un Directorio global aunque el usuario acceda al sistema a través de un único punto (normalmente el más próximo a él).

El Directorio DSA

Usuario

DUA

DSA

DSA

DUA

Usuario

DSA

DUA

Usuario

Fig. 6.2 Visión global del Directorio

Los agentes del sistema de Directorio forman diferentes dominios de gestión 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 información. Desde el punto de vista de acceso y cooperación entre los sistemas que forman el Directorio, éste proporciona un conjunto estándar de servicios abstractos y de protocolos a sus usuarios. La especificación abstracta del servicio de Directorio incluye la descripción formal de servicios para la modificación y recuperación de información. Estos servicios son consumidos por los usuarios a través de los DUA. También, y aparte de los servicios propios de usuario, el Directorio incluye servicios y protocolos para la gestión y distribución interna del sistema de Directorio.

6.1.3 La base de información del Directorio (DIB) De forma general, la base de información del Directorio (DIB) está formada por información sobre objetos. Técnicamente, la DIB está compuesta por entradas (entries) de directorio, las cuales consisten en una colección de información sobre un objeto. Cada información 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 más típicos se enumeran en la siguiente tabla.

Tabla 6.1 Diferentes tipos de atributos X.500

Tipo de atributo

Tipo de atributo

businessCategory

presentationAddress

commonName

registeredAddress

countryName

roleOccupant

description facsimileTelephoneNumber

serialNumber stateOrProvinceName

iSDNAddress localityName

streetAddress supportedApplicationContext

objectClass

surname

organizationName

telephoneNumber

physicalDeleiveryOfficeName postalAddress

teletexTerminalNumber telexNumber

postalCode postOfficeBox

title X121Address

preferredDeliveryMethod

Las entradas de la DIB están organizadas jerárquicamente en modo de árbol formando el árbol de información del Directorio (DIT, Directory Information Tree). Cada vértice del DIT representa una entrada para un objeto particular, donde entradas de alto nivel cercanas a la raíz suelen describir objetos como países u organizaciones, mientras que entradas de bajo nivel en el árbol suelen describir objetos como personas o aplicaciones. Existen dos tipos de entradas, aquéllas que contienen la descripción 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 construcción de nombres alternativos para las entradas de objeto. La figura 6.3 muestra la relación entre los conceptos de árbol de información 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

Atributo

tipo

valor(es)

Fig. 6.3 Estructura del DIT y sus componentes

6.1.4 El nombre distintivo (DN) Un nombre distintivo es una construcción lingüística amigable (que significa cercana o fácil 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 información referente a un objeto almacenado en la DIB.

atributo distintivo (RDN)

Entrada

Atributo

atributo

atributo

tipo

valor(es)

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 cuestión) se fija en la creación de la entrada. Formalmente, un RDN está compuesto por una lista de de atributos distintivos, pero en la práctica, los RDN se construyen generalmente con uno sólo. Por simplicidad, se ha considerado el caso más común. Así, un nombre (DN) será la secuencia jerárquica 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.

raíz

C=ES

C=US

L=Los Angeles

O=UPC

OU=CTT

OU=DAC

O=Graphic Services CN=John Jones

CN=Máquina Fax

CN=José Fernández

CN=Laser Printer

CN=Fax Machine

Fig. 6.5 Ejemplo de DIT

La figura 6.5 también muestra ejemplos de algunos tipos de atributos usados (país -C-, organización -O-, unidad organizativa -OU-, localidad -L-, nombre común -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 aplicación “Laser Printer” que en su DN tiene un atributo geográfico de localidad. La persona civil "John Jones" cuyo nombre es: { C=US, L=Los Angeles, CN=John Jones } tiene el mismo atributo geográfico en su nombre. En el caso de una estructuración del DIT siguiendo un esquema puramente organizativo, veáse el ejemplo de "José Fernández", que se trata de una persona afiliada a una unidad organizativa "DAC" dentro de la organización "UPC" situada en España. Su nombre distintivo será entonces:


131


{ C=ES, O=UPC, OU=DAC, CN=José Fernández } Por último, se debe mencionar que la raíz del DIT tiene como nombre distintivo el valor nulo, esto es, una secuencia nula de RDN y se representa como el nombre vacío: {}

6.1.5 Dominios de gestión del Directorio La asignación de nombres conlleva el cumplimiento de un esquema que determina la selección 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 relación jerárquica viene fijada por el DIT. En realidad, la jurisdicción para la asignación 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 asignación de nombres para sus entradas subordinadas (esto es, José Fernández, etc.). Se denomina dominio de gestión del Directorio (DMD, Directory Management Domain) a la porción del DIT que se encuentra bajo la responsabilidad de cierta autoridad. Dentro de un dominio se sigue el esquema para la gestión del espacio de nombres especificado por dicha autoridad.

raíz

ADMD

C=ES

C=US

ADMD

PRMD L=Los Angeles

O=UPC OU=DAC

OU=CCT

O=Graphic Services CN=John Jones

CN=Máquina Fax

CN=José Fernández

CN=Laser Printer

PRMD

PRMD

Fig. 6.6 Ejemplo de dominios de gestión

Dependiendo de las autoridades y su naturaleza, se distinguen dos tipos de dominios de gestión:


132


-

Públicos o administrativos (ADDMD, ADministration Directory Management Domain). Son dominios gestionados por organismos o administraciones públicas. Por ejemplo, las PTT (proveedores públicos de telecomunicaciones) nacionales, que en el caso de España es Telefónica.

-

Privados (PRDMD, PRivate Directory Management Domain). Son dominios gestionados por organizaciones privadas. Por ejemplo, un banco, gran empresa o institución.

La figura 6.6 muestra un ejemplo de estructuración 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 través de DUA (Fig. 6.1). Existen peticiones que permiten la interrogación y la modificación del Directorio. Además, también existen servicios que permiten el establecimiento y la liberación de una unión temporal entre un usuario y el Directorio a través de un punto de acceso al Directorio.

6.1.6.1 Servicios de Interrogación Existen cinco servicios diferentes: servicios de lectura (Read), comparación (Compare), catálogo o listado (List), búsqueda (Search) y abandono (Abandon). A continuación se describe brevemente cada una de las operaciones que realizan los servicios. - Leer (Read): Operación de lectura de algunos o todos los atributos de una entrada específica. -

Comparar (Compare): Operación de comparación de un atributo específico de una entrada específica con un valor aportado en la operación.

- Listar (List): Operación para listar todos los RDN de todas las entradas subordinadas a una entrada específica. - Buscar (Search): Operación que hace al Directorio iniciar una búsqueda de todas las entradas dentro de cierta porción del DIT que satisfacen un filtro. La información retornada para cada entrada puede ser algunos o todos los atributos de cada entrada (como en leer). - Abandonar (Abandon): Operación que hace al Directorio abandonar la petición de interrogación en curso. El Directorio cesará el procesado de la petición en curso y descartará cualquier posible resultado obtenido hasta el momento.



133

6.1.6.2 Servicios de modificación Existen cuatro servicios diferentes, servicios de añadir entrada (add entry), borrar entrada (remove entry), modificar entrada (modify entry) y modificar DN (modify DN). A continuación se describe brevemente cada una de las operaciones que realizan los servicios. - Añadir entrada (add entry): Operación que añade una nueva entrada objeto o alias al DIT. Una nueva entrada sólo se puede añadir a una hoja del DIT, esto es, bajo un DN específico que determine una entrada final (sin subordinados). - Borrar entrada (remove entry): Operación que borra una entrada final (sin subordinados) del DIT. - Modificar entrada (modify entry): Operación que hace al Directorio iniciar una secuencia de cambios sobre una entrada específica. En la operación siempre se realizan todos los cambios o no se realiza ninguno. Los cambios que se pueden realizar son la adición, borrado o cambio de atributos completos o valores de atributos. - Modificar DN (modify DN): Operación para ordenar un cambio de nombre distintivo relativo de una entrada (objeto o alias) específica, o para mover una entrada específica hacia un nuevo punto superior en el DIT. Nótese 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 sólo se ve modificado un DN, el de la propia entrada. Sin embargo, en el caso de que tuviera subordinados, todos los subordinados también se verían modificados.

6.1.6.3 Servicios de establecimiento y liberación de unión 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 través de su DUA inicia un establecimiento de unión (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 vértice del árbol del directorio, esto es, en una entrada específica del DIT. Una vez realizada la unión, el usuario podrá ordenar operaciones que impliquen la entrada asociada al punto de acceso o podrá especificar en la operación otra entrada del DIT. Generalmente, en el proceso de establecimiento de unión se requiere que el usuario incluya algún tipo de credencial para poder realizar su autenticación y un control de acceso posterior. Así, el usuario sólo podrá realizar operaciones en entradas sobre las que tenga c iertos derechos. El usuario libera la unión (unbind) entre DUA y el sistema de Directorio cuando no requiera solicitar más operaciones al Directorio.


134


6.1.6.4 Otros servicios definidos en el Directorio Una de las contribuciones más importantes del Directorio es la definición de un marco de autenticación (authentication framework). Aquí se propone un marco estándar para la implantación de servicios de seguridad utilizando tecnologías de clave pública (autenticación, control de acceso, integridad, confidencialidad, etc.) para la protección de los usuarios y del propio Directorio. Estas recomendaciones también han sido incorporadas a otras aplicaciones OSI y no OSI. Otros servicios, aunque no visibles directamente por el usuario, son los de replicación de la información y gestión de parámetros operacionales entre DSA.

6.1.7 El modelo distribuido del Directorio En la figura 6.2 del apartado 6.1.2 se muestra la visión global o modelo funcional del sistema de Directorio. Básicamente, un agente de sistema de Directorio (DSA) es un proceso de aplicación OSI cuya misión es la de proporcionar acceso al DIB a los usuarios del Directorio a través de los DUA y/o a otros DSA. Un DSA puede utilizar la información 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

raíz

ADMD DSA1

ADMD C=ES

C=US

DSA1

DSA2

O=UPC OU=CCT

DSA1

L=Los Angeles

PRMD OU=DAC

O=Graphic Services CN=John Jones PRMD

CN=Máquina Fax

CN=José Fernández DSA1

CN=Laser Printer PRMD

DSA1

Fig. 6.7 Ejemplo de DIB con distribución 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 porción del DIB es dependiente de la implementación y no está estandarizada (p.e. se pueden utilizar bases de datos relacionales comerciales). Un conjunto de uno o más DSA y cero o más DUA gestionados por una única organización forman un dominio de gestión del Directorio (DMD). La figura 6.7 muestra, de forma conjunta, un ejemplo de modelo organizativo y funcional del sistema de Directorio. Nótese que todos los dominios, incluido la raíz del Directorio, están 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, cómo 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 comunicación con uno o más 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 información 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 información solicitada, ya sea localmente o remotamente interaccionando con otros DSA en nombre del DUA. Cuando un DUA realiza una petición a un DSA, la realización de esa petición puede ocurrir de diferentes formas dependiendo de si la información se encuentra almacenada localmente o si dicha información hay que buscarla en otros DSA.

El Directorio

petición Usuario

DUA

DSA respuesta

Fig. 6.8 Interacción simple


136


- Interacción simple . Es el caso más sencillo y ocurre cuando la información solicitada por el DUA se encuentra en el DSA al cual se realizó la petición. La figura 6.8 muestra este caso.

El Directorio

DSA B

petición Usuario

DSA C

DUA indirección (a A)

petición

DSA A

Fig. 6.9.a Interacción con un nivel de indirección

- Interacción con indirección (referral). En este caso (Fig. 6.9.a), el DUA solicita una información que el DSA (C) al que se realizó la petición 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 información.

El Directorio

i ó n e t i c p 1 )

DSA B

petición Usuario

DUA 2) indirección (a B)

DSA C

p e t ic i ón i n d i r e c ( a c i ó n B )

DSA A

Fig. 6.9.b Interacción con dos niveles de indirección

La figura 6.9.b muestra otro tipo de indirección. Puede ocurrir que el DSA al que se realizó la petición (C) no tenga la información y éste encamine (ver siguiente tipo de interacción) la petición a otro DSA (A). El DSA (A) tampoco tiene la información 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


información. Ahora, el DSA (C) puede optar por realizar la petición directamente al DSA (B) -caso 1)- o responder al DUA con la referencia al DSA (B) -caso 2)-.

- Interacción con encadenamiento simple (uni-chaining). Una petición puede ser encaminada a través de varios DSA hasta que se encuentra la respuesta a la información solicitada (Fig. 6.10).

El Directorio

petición Usuario

DUA

petición DSA

DSA respuesta

respuesta

Fig. 6.10 Interacción con encadenamiento simple

- Interacción con encadenamiento múltiple (multi-chaining). Una petición será encaminada por el DSA asociado al DUA hacia varios DSA en paralelo. La petición es la misma para todos los DSA y puede ocurrir que ninguno, uno o varios DSA respondan con la información solicitada (Fig. 6.11).

El Directorio

ó n i ó c i i c p e t

a t a u e s r e s p

petición Usuario

DUA

DSA

DSA respuesta

p e t i ic c i ó ón r e es p u e s t ta a

DSA

Fig. 6.11 Interacción con encadenamiento múltiple


138


6.1.9 Protocolos Protocolos del Directorio En la versión de 1988 del Directorio existían 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 versión del Directorio (1993) aparecen dos protocolos protocolos más que están relacionados con l a replicación de la información entre DSA (DISP, Directory Information Shadowing Shadowing Protocol) y con la gestión de información operacional entre DSA (DOP, Directory Operational binding management Protocol). Ambos protocolos proporcionan servicios de gestión para DSA y no ofrecen ningún servicio directo al usuario, por lo que no han sido tratados aquí. Cada uno de los protocolos existe dentro de un contexto de aplicación que está formado por elementos de servicio de aplicación que utilizan ROSE (elemento de servicio de operaciones remotas) para llevar a cabo las interacciones. Así, el DAP y el DSP están definidos como un conjunto de operaciones y errores remotos usando la notación RO.

6.2 Servicio de nombres de Internet

6.2.1 Introducción El servicio de nombres de dominio (DNS, Domain Name Service) de Internet es un servicio de nombres que asocia información con objetos. Cualitativamente, el DNS de Internet es equivalente al Directorio de OSI pero teniendo en cuenta los siguientes matices: -

DNS sólo sólo manipula manipula información información sobre sobre máquina máquinass (hosts, (hosts, siguiendo siguiendo la terminología terminología Intern Internet) et) en la red.

-

DNS se se diseñó diseñó con con el objeti objetivo vo principa principall de sustituir sustituir las direcciones direcciones de red red IP por nombres nombres amigables en el uso de las aplicaciones Internet. Así, DNS se utiliza básicamente como un servicio de resolución 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 información 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 más lento que DNS, el cual implementa unos protocolos sumamente sencillos.

6.2.2 Visión 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 ( resolver (término original sin traducir). Cuando una aplicación necesita obtener una dirección física de red a partir de un nombre, ésta invoca al resolver, el cual realiza una interrogación a su servidor de nombres local. La figura 6.12 muestra el acceso a DNS, así como la visión global del sistema.

DNS

Usuario

resolver

servidor nombres

servidor nombres

servidor nombres

resolver

Usuario

servidor nombres

resolver

Usuario

Fig. 6.12 Visión global de DNS

Desde un punto de vista arquitectónico, se puede extraer un paralelismo entre las entidades del Directorio y de DNS. Así, resolvers y servidores de nombres de DNS serían equivalentes a DUA y DSA del Directorio respectivamente. No se debe olvidar tampoco que los servidores de nombres manipulan una base de datos de información sobre máquinas de la red.


140


6.2.3 La base de información de DNS La base de información 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 serían 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 información sobre una dirección IP, un alias, información textual sobre la CPU y el sistema operativo, servidores de correo asociados, etc. Los nodos de DNS están organizados jerárquicamente en forma de árbol. Cada vértice del árbol representa un nodo que contiene información sobre un dominio o una máquina 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 información. Concretamente, se trata de unos ficheros tipo texto donde cada línea 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 también 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 raíz del árbol. El nombre de dominio de un nodo es la lista de etiquetas en el camino desde el nodo hasta la raíz del árbol. Comparando con el Directorio, nodos y nombres de dominios de DNS tendrían su equivalente en RDN y DN del Directorio. Por convenio, las etiquetas sólo pueden tener caracteres imprimibles (sin incluir el punto '.'), en donde mayúsculas y minúsculas indican el mismo carácter. 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 máquina ‘sirius’ del Departamento de Arquitectura de Computadores (AC) dentro de la Universitat Politècnica de Catalunya (UPC) en España (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 máquinas. El nodo final representa siempre una máquina (host). En la asignación de nombres, los nombres de dominios más superiores (llamados top level domains ) ya han sido fijados; como son EDU, ARPA, COM, GOV, ES, US, el resto de países, y otros. Además, la asignación de un nombre de dominio de segundo nivel debe corresponder a la categoría 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 Jerarquía de dominios de Internet

6.2.5 Gestión de dominios DNS DNS define el concepto de zonas (zone). Una zona está formada por un conjunto de máquinas dispuestas jerárquicamente 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 máquina distinta de la zona y sus clientes están jerárquicamente por debajo de estos servidores. Comparando con el Directorio, las zonas serían equivalentes a los dominios de gestión del Directorio. Las zonas generalmente representan fronteras entre autoridades en la administración del espacio de nombres. La figura 6.14 muestra una estructuración en zonas para el espacio de nombres dentro de España y de la Universitat Politècnica de Cat alunya.


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 sólo ofrece servicios de interrogación para obtener información sobre un determinado dominio o máquina utilizando un nombre como índice. DNS no ofrece servicios de modificación de la base de información sino que ésta debe ser modificada localmente por el administrador mediante la edición de los ficheros que contienen los registros RR. En cuanto a los protocolos, DNS es una aplicación 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 número 53.


7 Gestión e intercambio de documentos y ficheros en sistemas distribuidos

143

7 Gestión e intercambio de documentos y ficheros en sistemas distribuidos 7.1 Introducción La gestión y el intercambio de ficheros ha sido siempre un tema importante dentro del software de ordenadores. Cuando se habla de sistemas distribuidos, es básico el poder realizar la gestión 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 más importantes son los documentos, los cuales también pueden necesitar ser gestionados, manipulados e intercambiados en un entorno distribuido. Existen una serie de estándares, tanto OSI como Internet, que definen protocolos para poder realizar dicho intercambio y gestión de documentos y ficheros en sistemas distribuidos. En concreto, este capítulo se inicia con el tema de la manipulación remota de documentos (incluyendo las recomendaciones DTAM, de ITU-T), para seguir con la manipulación remota de almacenes de documentos (basada en el estándar DFR, de ISO), y acabar con la gestión y transferencia de ficheros en general (donde se trata un estándar de ISO, FTAM, y otro de Internet, ftp).

7.2 Manipulación remota de documentos: DTAM-DM Para poder definir una manipulación de documentos en un entorno distribuido abierto, el primer paso es tener una visión común del documento. Esto se soluciona utilizando un estándar que


144


permita definir un documento de forma independiente de como se crea y se procesa. Para eso se ha especificado ODA (véase el capítulo 5). El segundo paso es definir una serie de operaciones estandarizadas sobre los documentos. Esto se especifica en una nueva parte del estándar ODA (la parte 3, publicada en 1995), que se denomina interfaz abstracto para la manipulación de documentos ODA [ODA0395] (véase el apartado 7.2.1). Después, es necesario definir una aplicación distribuida para poder realizar esas operaciones de forma remota. Para esto se ha especificado el servicio y protocolo manipulación confirmada de documento -transferencia y manipulación de documentos (DTAM-DM, Document Transfer And Manipulation - confirmed Document Manipulation) (véase el apartado 7.2.2).

7.2.1 Interfaz abstracto para la manipulación de documentos ODA El interfaz de operaciones utiliza las características estructurales de ODA para identificar fragmentos de documento sobre los que realizar las operaciones. Este es un avance importante respecto a la versión inicial de ODA, que no lo permitía. 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 almacén, Abrir (Open) y Cerrar (Close) un documento seleccionado. Se puede tener más de un documento abierto a la vez.

-

Operaciones de sólo lectura: Traer (Get) uno o varios elementos ODA (fragmentos de documento), y Buscar (Search) una información determinada dentro de un documento.

-

Operaciones básicas de alteración: Crear (Create), Borrar (Delete) y Modificar (Modify) fragmentos, y Copiar (Copy) fragmentos a otro lugar (incluso en otro documento).

-

Operaciones compuestas de alteración: 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 simultáneo al mismo fragmento.


145


-

Operaciones independientes del documento: Empezar (BeginGroup) y Acabar (EndGroup) un grupo de operaciones que a una aplicación pueda interesarle reunir, por ejemplo, para minimizar coste de comunicación 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 identificación de dichos fragmentos, cuya especificación también es una nueva parte del estándar ODA (la parte 12, aprobada en 1995), titulada identificación de fragmentos de documento [ODA1295].

7.2.2 Protocolos DTAM El interfaz abstracto no es un servicio distribuido con su protocolo, sino un conjunto estándar de operaciones de manipulación 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 están los documentos a manipular), se necesita un protocolo de aplicación, que pueda funcionar, preferentemente, sobre los niveles superiores del modelo OSI, y sobre cualquier tipo de red. Una solución a este problema es utilizar el protocolo de manipulación 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, básicamente, definen un protocolo de transferencia interactiva de documentos), especifica un conjunto de operaciones de manipulación de documentos (perfectamente alineado con el interfaz de manipulación ODA), aparte de otras operaciones más concretas de protocolos de comunicación. El conjunto de operaciones proporcionadas por DTAM-DM se presenta en la tabla 7.1.

Tabla 7.1 Operaciones proporcionadas por DTAM-DM

Operación

Descripción

Nivel de documento Enumerar (List)

Enumera los documentos en un almacén (sin estructura)

Abrir (Open)

Abre un documento para su manipulación

Cerrar (Close)

Cierra un documento después de su manipulación

Guardar (Save)

Guarda un documento después de su manipulación


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

Alteración básica 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

Alteración 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

Reserva (o anula la reserva) de un fragmento de documento

(Reserve/Unreserve) Empezar / Acabar Grupo

Indica principio y final de un grupo de operaciones

(BeginGroup / EndGroup)

Las operaciones mencionadas corresponden a un mismo elemento de servicio de aplicación, llamado de manipulación de documentos (DTAM-DM-SE). Como sistema OSI, se puede especificar usando ASDC (véase capítulo 3), donde DTAM-DM es un puerto asimétrico. Para situaciones en las que puede interesar intercambiar un testigo (token) de aplicación para controlar el turno, por ejemplo en una edición 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 simétrico. 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 podría utilizar sobre cualquier tipo conocido de documentos.


147


7.2.3 Perfiles de manipulación de documentos Diferentes implementaciones de aplicaciones para manipulación de documentos pueden no necesitar toda la funcionalidad proporcionada por los estándares o recomendaciones mencionados. Por ello, se están definiendo perfiles (profiles), o estándares funcionales, que especifican subconjuntos implementables de estándares complejos. Tanto para la manipulación remota interactiva de documentos, como para la manipulación de almacenes de documentos basados en DFR (véase el apartado 7.3.2), se están definiendo diversos perfiles que restringen, entre otras cosas, las operaciones a realizar. Para el caso de manipulación interactiva de documentos se han definido tres perfiles (cada uno subconjunto del siguiente) que son perfiles sobre DTAM-DM y el interfaz de manipulación ODA. Se llaman AOD1n, siendo n un número que identifica el perfil (el 1 inicial indica que son con DTAM-DM como protocolo). Los perfiles definidos son: -

Sólo lectura (AOD11): Para leer y buscar fragmentos de documento. Incluye las operaciones Traer y Buscar, aparte de Abrir y Cerrar, y, opcionalmente, Enumerar.

-

Inserción (AOD12): Permite añadir información a un documento. Incluye, además de las operaciones de AOD11, las operaciones Crear, Copiar y, opcionalmente, Reservar (Reserve y Unreserve).

-

Manipulación (AOD13): Permite todas las operaciones de manipulación. Incluye, además de las operaciones de AOD12, las operaciones Borrar y Modificar, siendo las demás (Reemplazar, Mover, ...) opcionales.

Estos perfiles restringen el uso de DTAM-DM y el interfaz de manipulación de ODA, además de especificar cómo combinar ambos. Todos los perfiles empezarán a publicarse en 1996. Los perfiles AOD se pueden combinar con perfiles similares que se están definiendo para DFR, los cuales se introducen en la sección 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 Operación

AOD11

AOD12

AOD13

o

o

o

Nivel de documento Enumerar (List)


148


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

Lectura Buscar (Search) Traer (Get)

Alteración básica Crear (Create) Copiar (Copy) Borrar (Delete) Modificar (Modify)

Alteración compuesta Mover (Move)

o

Reemplazar (Replace)

o

Otras Reservar (Reserve/Unreserve)

o

Empezar / Acabar Grupo

o o

(BeginGroup / EndGroup)

7.3 Manipulación remota de almacenes de documentos: DFR En la sección anterior se ha visto cómo manipular documentos remotamente. Pero existen aplicaciones, quizá más habituales, en las que lo que se quiere manipular es un almacén de documentos, es decir, no interesa qué hay dentro de los documentos, sino los documentos enteros y su situación en el almacén. Como DTAM está pensado para manipular internamente un documento, si una aplicación necesita, además, manipular un almacén completo de documentos, es necesario añadir operaciones a nivel de almacén. En este caso, lo ideal es complementar DTAM con otro protocolo del nivel de aplicación OSI como el de almacenamiento y recuperación 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 características de DTAM.


149


7.3.1 El estándar DFR DFR permite gestionar documentos y otros objetos dentro de almacenes remotos en un sistema distribuido. El modelo de información de DFR describe la estructura jerárquica 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 sólo en la estructura del almacén. Dicho de otra manera, así como DTAM-DM permite manipular dentro de documentos y el objeto máximo que puede manipular es un documento entero, DFR permite manipular dentro del almacén, siendo el documento el objeto mínimo que manipula. Por esta razón, DTAM-DM y DFR son complementarios (véase el apartado 7.4). El modelo de información de DFR define un almacén de documentos como una estructura jerárquica que incluye los siguientes objetos: -

Documento DFR: Una entrada en el almacén 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 almacén que contiene otras entradas. Como mínimo existirá el grupo raíz.

-

Lista de resultados de búsqueda DFR: Una entrada en el almacén que contiene información sobre el resultado de una búsqueda.

-

Referencia DFR: Un objeto que actúa como enlace a otro objeto.

Grupo raíz DFR

Grupo

Documento 1

Documento 2

Referencia

Documento 3

Lista Documento

Fig. 7.1 Ejemplo de estructura de almacén DFR


150


La figura 7.1 muestra un ejemplo de estructura del almacén DFR. Las operaciones definidas en el estándar DFR se describen en la tabla 7.3.

Tabla 7.3 Operaciones definidas en DFR

Operación

Descripción

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 información (atributos o contenido) sobre un objeto

Modificar (Modify)

Modifica la información (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 búsqueda

Buscar (Search)

Busca entradas que satisfagan un determinado criterio de búsqueda

Reservar (Reserve)

Modifica el nivel de reserva de una entrada

Abandonar (Abandon)

Abandona la ejecución de una operación iniciada previamente

7.3.2 Perfiles de DFR Tal como se introdujo en el apartado 7.2.3, los perfiles o estándares funcionales de DFR se están especificando actualmente. Al igual que para el interfaz de manipulación de ODA y DTAM-DM, la estructura de perfiles está aprobada y existen borradores más o menos avanzados de diferentes perfiles, los cuales se publicarán a partir de 1996. Los perfiles DFR se llaman ADFnm, siendo n y m números que identifican ciertas características de los perfiles, y se están 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 recuperación de documentos.

-

ADF2: Es para gestión remota de un almacén de documentos, normalmente combinado con otra aplicación para manipular documentos internamente, como DTAM-DM.

El primer grupo consta de los siguientes perfiles:


151


-

Sólo lectura (ADF11): Permite recuperar documentos almacenados o buscarlos, pero no permite almacenar nueva información o cambiar la ya existente.

-

Archivo (ADF12): Además de las características de ADF11, permite almacenar nuevos documentos, pero no cambiar la información ya existente.

-

Manipulación del almacén de documentos (ADF13): Incluye todas las operaciones de DFR.

El segundo grupo consta de los siguientes perfiles: -

Gestión simple (ADF21): Proporciona una funcionalidad mínima, como enumerar y buscar, para complementar otras aplicaciones de manipulación de documentos.

-

Gestión completa (ADF22): Además de las características de ADF21, permite funciones de manipulación (pero sin las operaciones Leer y Crear), también 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 Operación

ADF11

ADF12

ADF13

ADF21

ADF22

Crear (Create) Borrar (Delete) Copiar (Copy) Mover (Move) Leer (Read) Modificar (Modify) Enumerar (List) Buscar (Search)

o

Reservar (Reserve) Abandonar (Abandon)

o

o

o

o

o


152


7.4 Manipulación y gestión de documentos Existen aplicaciones de manipulación de documentos que necesitan, además de las operaciones de manipulación interna de los documentos, otras operaciones para lo que se podría llamar gestión del almacén de documentos. En algunos casos, podría ser suficiente poder buscar y seleccionar el documento deseado antes de su manipulación, y, en otros casos, podría ser necesario disponer de operaciones más complejas, como mover, copiar o borrar documentos enteros, o incluso grupos de documentos. En este caso, la aplicación DTAM-DM puede complementarse con la aplicación DFR. Para lograr la integración práctica de los dos estándares, y evitar tener que establecer dos asociaciones de aplicación (es decir, tener DTAM-DM y DFR de forma independiente), se ha definido, tras largos años de negociación entre los diferentes grupos de estandarización, una solución muy simple técnicamente que consiste en definir un nuevo contexto de aplicación que incluye los elementos de servicio de aplicación específicos de DTAM-DM y DFR. De esta forma, cuando se quiera disponer de la funcionalidad conjunta de ambos estándares, bastará con establecer una única asociación con el contexto de aplicación definido específicamente para esto tanto en el estándar DFR como en las recomendaciones DTAM-DM.

7.5 Transferencia y gestión de ficheros en OSI (FTAM) La aplicación OSI estandarizada específica para la transferencia y gestión de ficheros distribuidos es FTAM (File Transfer, Access and Management). La primera versión de FTAM data de 1988 y es previa al modelo DOAM.

Usuario FTAM

Almacén real

Cliente FTAM

Entidad de aplicación FTAM

Servidor FTAM

Protocolo de acceso FTAM

Almacén real

Entidad de aplicación FTAM


Figura 7.2 Arquitectura general de FTAM


153


Los estándares [FTA0188], [FTA0288], [FTA0388], [FTA0488] describen el servicio y el protocolo de FTAM correspondiente a la primera versión de 1988. Posteriormente, en 1990, se añadieron nuevas funcionalidades para la gestión del almacén virtual de ficheros, las cuales se describen en el estándar [FTA0590]. Con el objeto de permitir la transferencia de ficheros entre sistemas heterogéneos, FTAM define el concepto de almacén virtual de ficheros (Virtual File Store), de forma que cada sistema de ficheros local, o almacén real, se debe mapear en ese almacén lógico. (véase figura 7.2). Como ya se ha mencionado anteriormente, la aplicación estándar FTAM es previa a la creación del modelo DOAM, por lo que la entidad de aplicación FTAM no tiene ROSE y consta únicamente de un ASE común para la gestión de asociaciones, que es ACSE, más el ASE específico para FTAM que es FTAM-SE (véase figura 7.3). Cliente de FTAM

Servidor de FTAM

UE

UE


FTAMSE

ACSE

ACSE


FTAMSE

Protocolo FTAM


Figura 7.3 Entidad de aplicación de FTAM

7.5.1 El almacén virtual En la versión del 88, el almacén virtual de FTAM no es más que una colección de ficheros que no tienen relación entre sí (así, por ejemplo, no existe el concepto de directorio). En este apartado se describe la visión de un fichero aislado dentro del almacén virtual. Un fichero FTAM consta del contenido más una serie de atributos. Los atributos contienen información acerca del fichero y pueden ser de dos tipos: atributos de fichero y atributos de actividad . Los atributos de fichero (o estáticos) están 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 básicamente incluyen información 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 información respecto al responsable del fichero, fecha y usuario de creación, última lectura y última modificación de contenido y atributos, tamaño estimado y máximo, y disponibilidad inmediata o retardada, etc. Los atributos de seguridad contienen información relacionada con el control de acceso como passwords, limitaciones de acceso concurrente, acciones permitidas, algoritmo de encriptación, etc. Finalmente, el cuarto grupo permite a los usuarios añadir atributos no estándar adecuados para sus aplicaciones. Los atributos de fichero de almacenamiento, seguridad y privados son opcionales y se negocian para cada asociación. Los atributos de actividad (o dinámicos) están ligados a una determinada asociación 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 básicamente información sobre el tipo de contenido del fichero, el acceso solicitado, la identificación del usuario iniciador de la actividad, localización, tipo de procesado y título de las entidades de aplicación. Los atributos de actividad relacionados con el grupo de almacenamiento están relacionados básicamente con el control de la concurrencia y la contabilidad. Finalmente, los atributos de actividad del grupo de seguridad contienen información relacionada con el control de acceso y la calificación legal.

7.5.2 Estructura de los ficheros La estructura de un fichero dentro del almacén 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 mínima de


155


transferencia. La relación entre DU está basada en un modelo jerárquico (véase figura 7.4). Un fichero FTAM es una secuencia de FADU, una FADU se puede ver como una unidad de localización (subárbol). Una FADU consta de un nodo (nodo raíz 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 definición, el nodo raíz 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 estándar define una serie de subestructuras más sencillas que se pueden derivar de la estructura general de un fichero FTAM, y que se corresponden con algunas de las estructuras de ficheros más habituales. Por ejemplo, un fichero no estructurado, como un fichero UNIX, consta de una única FADU con una única DU asociada (véase 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 almacén virtual FTAM es un fichero plano o secuencial, que consta de una FADU de nivel 0 con un nodo raíz sin DU asociada,


156


más una serie de FADU de nivel 1 cada una de las cuales es un nodo terminal con DU asociadas (véase 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 Regímenes de FTAM Cuando una entidad de aplicación establece una asociación para utilizar FTAM, entra en lo que se llama un régimen FTAM . En la fase de establecimiento del régimen FTAM se negocia los servicios (unidades funcionales) que se podrán utilizar mientras dura dicha asociación. A lo largo del progreso de dicho régimen FTAM, es posible utilizar una serie de servicios que se agrupan a su vez en regímenes que deben tener lugar en una determinada secuencia temporal (véase figura 7.7). El régimen FTAM se inicia mediante la utilización 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 régimen FTAM, se puede seleccionar un fichero dentro del almacén virtual sobre el que poder realizar posteriormente una serie de operaciones mediante el régimen de selección de fichero. Dicho régimen se puede iniciar mediante la utilización de los servicios FSELECT, para seleccionar un fichero ya existente, o F-CREATE para seleccionar un fichero nuevo, es decir, crearlo. Para finalizar el régimen de selección 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 régimen de selección de fichero serán sobre el fichero previamente seleccionado siempre y cuando los derechos de acceso así lo permitan. Dentro del régimen de selección de fichero es posible realizar operaciones de gestión 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 continuación, y antes de poder realizar operaciones sobre el contenido del fichero, es necesario establecer el régimen de apertura de fichero , que se inicia con el servicio F-OPEN y finaliza con F-CLOSE. Dentro del régimen 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).

Régimen FTAM Régimen de selección de fichero Régimen de apertura de fichero Régimen 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-INITIALIZE

F-TERMINATE F-U-ABORT F-P-ABORT

Fig. 7.7 Regímenes FTAM (versión 88)

Para poder realizar operaciones de transferencia es necesario establecer primero el régimen 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 régimen de transferencia es F-READ; si, por el contrario, el flujo de DU es de cliente hacia servidor, el servicio es F-WRITE. El régimen de transferencia de datos finaliza mediante la utilización del servicio F-TRANSFER-END. Es posible finalizar el régimen 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


jerárquica del almacén 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 régimen abierto de cada tipo pero dentro de un régimen concreto es posible establecer y terminar tantos regímenes interiores consecutivos del mismo tipo como se desee.

7.5.4 Gestión del almacén virtual Las facilidades relacionadas con la gestión del almacén virtual aparecen en la versión de FTAM de 1990, en la que los ficheros dentro del almacén virtual están relacionados entre sí mediante una estructura de directorios. Dichas operaciones de gestión del almacén virtual se han agrupado en un régimen opcional llamado régimen de selección generalizada que permite la gestión de subalmacenes. Un fichero, desde el punto de vista de las operaciones de gestión del almacén virtual, es una unidad indivisible, que llamada objeto, sobre la que se pueden realizar operaciones como mover de un directorio a otro, etc. Existen además otros tipos de objetos en el almacén virtual como son los directorios y las referencias.

Directorio Fichero Referencia

Fig. 7.8 Almacén virtual FTAM

Los objetos tienen asociados una serie de atributos que no son más que una generalización 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 almacén virtual se identifica mediante una ruta de acceso (pathname) que puede contener varios objetos. Algunos de los atributos genéricos nuevos son la ruta de acceso primaria (primary pathname), que contiene la ruta de acceso completa desde el objeto raíz o el identificador permanente único (unique permanent identifier) que permite asociar un identificador a un objeto en el momento de su creación y que no se puede modificar mientras éste exista. También existen atributos específicos para los objetos de tipo directorio o referencia.



159

Los directorios mantienen una relación de parentesco con otros objetos del almacén de forma que proporcionan una estructura jerárquica al almacén virtual. Las referencias permiten mantener un enlace con otro objeto por lo que permiten que un objeto aparezca en diferentes lugares del almacén sin necesidad de estar físicamente repetido (véase figura 7.8). La figura 7.9 muestra el esquema completo donde figuran todos los regímenes posibles de FTAM, los analizados en la figura 7.7 correspondientes a la primera versión más los nuevos añadidos en la segunda versión de FTAM correspondientes a la gestión del almacén virtual. A continuación se analiza la figura 7.9, de izquierda a derecha, haciendo especial énfasis en los nuevos servicios. El régimen FTAM es básicamente el mismo que el descrito en el apartado anterior. Una vez establecido dicho régimen se puede utilizar el servicio F-LIST para obtener un listado del directorio especificado del almacén virtual. Mediante parámetros 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 régimen 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 almacén con una estructura jerárquica compleja. El prefijo se asigna en la fase de inicialización del régimen FTAM y permite utilizar rutas de acceso mucho más sencillas. El régimen de selección generalizada , que es opcional, empieza con la utilización del servicio FGROUP-SELECT y acaba con el servicio F-GROUP-DESELECT. Una vez establecido dicho régimen es posible utilizar los servicios relacionados con la gestión 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 almacén virtual mediante la utilización 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 régimen de selección de objeto puede inicializarse mediante la utilización 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 régimen de selección de fichero, pero existen nuevos servicios que sólo tienen sentido si previamente se ha establecido un régimen de selección 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 almacén virtual y el servicio F-LINK se utiliza para crear un objeto referencia a fichero. El régimen de selección de objeto se finaliza mediante los servicios F-DESELECT, F-DELETE (ya existentes) y F-UNLINK que sólo tiene sentido utilizar si el objeto seleccionado previamente es una referencia. Los servicios F-DELETE y F-DESELECT actúan 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 más el fichero referenciado por éste; en cambio, si el objeto seleccionado es un directorio, éste sólo se puede borrar si el directorio está vacío.

Régimen FTAM Régimen de selección generalizada Régimen de selección de objeto Régimen de apertura de fichero Régimen 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-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 Regímenes de FTAM



161

Una vez establecido el régimen de selección 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 también 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 generalización 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 almacén cambiando su ruta de acceso; pero, en cambio, si el objeto seleccionado es una referencia a fichero sólo mueve la referencia pero no cambia la ruta de acceso del fichero referenciado. El resto de regímenes 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 están agrupados en unidades funcionales (UF), cada una de las cuales contiene una serie de elementos de servicio. Las UF de FTAM relacionadas con la gestión de ficheros son: -

kernel (obligatoria) lectura escritura gestión de ficheros limitada gestión de ficheros mejorada acceso a fichero grupos recuperación reinicialización

Durante la fase de establecimiento de un régimen FTAM se negocian las UF válidas para dicho régimen. Con el objeto de simplificar dicha negociación el estándar define un conjunto de clases de servicio. Cada clase de servicio contiene el conjunto de UF adecuadas para cada tipo de aplicación donde algunas de dichas UF son opcionales. Las clases de servicio definidas por el estándar FTAM son las siguientes: -

transferencia (T) gestión (G) transferencia más gestión (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 gestión permite la lectura y modificación de atributos de fichero. La clase de transferencia más gestión permite disponer las funcionalidades de las dos clases anteriores. La clase de acceso permite l ocalizar una parte de un fichero dentro del almacén virtual para después realizar sobre ella operaciones como lectura, escritura, borrado, etc. Finalmente la clase no limitada sólo incluye la UF kernel y deja la inclusión de otras UF para la fase de negociación en el establecimiento del régimen de FTAM. En la tabla 7.5 se muestra la relación entre las UF de FTAM, las clases de servicio y los elementos de servicio correspondientes a la primera versión de FTAM. Tabla 7.5 Unidades funcionales, clases de servicio y elementos de servicio de FTAM (versión 88)

UF

Clase de servicio T

Kernel

A

G T&G

M M M

M

Elementos de servicio

NL

M

F-INICIALIZE, F-TERMINATE, F-U-ABORT, F-P-ABORT, F-SELECT y F-DESELECT

Lectura

O M -

O

O

F-READ, F-DATA, F-DATA-END, F-CANCEL, F-TRANSFER-END, F-OPEN y F-CLOSE

Escritura

O M -

O

O

F-WRITE, F-DATA, F-DATA-END, F-CANCEL, F-TRANSFER-END, F-OPEN y F-CLOSE

Acceso a fichero

-

Gestión de ficheros

M -

-

O

F-LOCATE y F-ERASE

O O M

O

O

F-CREATE, F-DELETE y F-READ-ATTRIB

O O M

O

O

F-CHANGE-ATTRIBUTE

Grupos

M O M

M

O

F-BEGIN-GROUP y F-END-GROUP

Recuperación

O O -

O

O

F-RECOVERY, F-CHECK y F-CANCEL

Reinicialización

O O -

O

O

F-RESTART, F-CHECK y F-CANCEL

limitada Gestión de ficheros mejorada

M: obligatorio, O: opcional y -: no disponible.

La gestión del almacén virtual introduce una serie de unidades funcionales adicionales que son: -

gestión limitada del almacén gestión mejorada del almacén manipulación de objetos manipulación de grupos

En la tabla 7.6 se muestra la relación entre las nuevas UF relacionadas con la gestión del almacén virtual, las clases de servicio y los elementos de servicio.


163


Tabla 7.6 Unidades funcionales de FTAM relacionadas con la gestión del almacén virtual

UF

Clase de servicio T

Kernel

A

G T&G

M M M

M

Elementos de servicio

NL

M

F-INICIALIZE, F-TERMINATE, F-U-ABORT, F-P-ABORT, F-SELECT y F-DESELECT

Gestión limitada del

-

O O

O

O

F-CHANGE-PREFIX y F-LIST

Gestión mejorada del -

O O

O

O

F-CREATE-DIRECTORY, F-LINK, F-UNLINK,

almacén almacén

F-READ-LINK-ATTRIBUTE y F-CHANGE-LINK-ATTRIBUTE

Manipulación de

-

O O

O

O

F-MOVE y F-COPY

-

O O

O

O

F-GROUP-SELECT, F-GROUP-DESELECT,

objetos Manipulación de grupos

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 información entre ordenadores. Aparece por la necesidad de compartir ficheros como programas de ordenador o datos de usuario entre diferentes sistemas. Una aplicación de transferencia de ficheros debe garantizar transparencia en el almacenamiento de los datos independientemente del sistema utilizado por los ordenadores que intercambian información y, además, deberá garantizar fiabilidad y eficiencia en la transferencia. En Internet existe un servicio de transferencia de ficheros que garantiza estos requerimientos mediante la implementación 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 Visión 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 través de una red. Este servicio no será un mero proceso de copia transparente de información de un sistema a otro, sino que se deberá realizar un procesado inteligente de la información de forma que los datos que tenían un cierto sentido en un sistema, conserven el mismo significado en el otro sistema. Uno de los ejemplos más claros es el de la transferencia de ficheros entre un sistema bajo DOS a otro sistema bajo UNIX. En el caso de transferencia de información textual, se sabe que un sistema bajo DOS almacena las líneas separándolas por medio de l os caracteres ASCII retorno de carro (CR) y cambio de línea (LF); sin embargo, un sistema bajo UNIX almacena las líneas separándolas por medio de un único carácter ‘LF’. La transferencia transparente de un fichero de texto de un sistema bajo UNIX a otro bajo DOS, o viceversa, lleva a la obtención 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 más popular, también 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 tamaños de palabra. Por este motivo, en una aplicación de transferencia de ficheros se diferencia entre los formatos de almacenamiento y la representación de los datos. La representación siempre es única mientras que el almacenamiento puede variar dependiendo del sistema. Es misión de la aplicación de transferencia el aplicar el procesado necesario a la información para que los datos almacenados en sistemas diferentes tengan una misma representación (Fig. 7.10).

Aplicación de transferencia de ficheros

Sistema de ficheros

Proceso de transferencia de ficheros

Formato de almacenamiento 1

Proceso de transferencia de ficheros

Formato de representación

Sistema de ficheros

Formato de almacenamiento 2

Fig. 7.10 Visión 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 aplicación de transferencia y ésta puede realizarse en ambos sentidos. La fase de transferencia de datos no es suficiente para obtener una aplicación de transferencia final, sino que son necesarios mecanismos de control por medio de los cuales el iniciador de una transferencia pueda programar cómo 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: Intérprete 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

Conexión 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í, existirán dos procesos diferentes de control, uno en el lado del servidor, que se denomina intérprete de protocolo servidor (servidorPI, Protocol Interpreter), y otro en el lado del usuario denominado intérprete 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 intérprete de usuario (usuario-PI), el cual establecerá una conexión de


166


control con el intérprete servidor (servidor-PI). A través de la conexión 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 contraseña) 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 representación de la información a intercambiar, esto es, tipo y estructura de los datos, modo de transmisión, etc. Además, el usuario podrá ejecutar también comandos que le permitirán gestionar el sistema de ficheros del servidor, por ejemplo, cambiar de directorio, crear directorio, borrar directorio, listar un directorio, visualizar el directorio actual, etc. Nótese que un usuario de FTP dispondrá de las mismas facilidades de que dispone para la gestión de un sistema de ficheros local pero aplicadas a un sistema de ficheros remoto. Por supuesto, un usuario sólo 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 sist ema 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 conexión 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 situación 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 conexión de datos entre ellos (Fig. 7.12).

Conexión de control

Servidor FTP (A)

Usuario FTP Usuario PI (C)

Conexión de datos

Conexión de control

Servidor FTP (B)

Fig. 7.12 Transferencia entre dos servidores FTP

Por último, se debe mencionar que FTP es una aplicación Internet que hace uso de los servicios de transporte de TCP para proporcionar la fiabilidad en la transferencia. Además, cada sesión de FTP mantendrá una conexión TCP fija para el control de la transferencia y una conexión TCP temporal para cada transferencia de datos (fichero) ordenada. El número de puerto TCP utilizado


UPC - Aplicaciones Distribuidas Abiertas

Recommend Documents