merged (9)

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 sehabla de aplicaciones distribuidas, se están considerando aplicaciones que se ejecutan en máquinasseparadas 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ónremota de documentos, la gestión de información remota, etc, son simples ejemplos de aplicacionesdistribuidas.

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), queson públicas, que especifican qué servicio va a dar la aplicación y qué protocolo va a seguir para dardicho servicio. Por supuesto, esto no tiene que restringir la implementación de la aplicación, sinoque, al contrario, sirve para que implementaciones independientes en sistemas diferentes se puedaninterconectar gracias a que siguen las reglas definidas en los estándares.

Por tanto, este libro describe aplicaciones distribuidas abiertas para intercambiar mensajes, transferirficheros y documentos, manipular documentos y almacenes de documentos remotamente, acceder ainformación sobre máquinas y usuarios, etc.

16 Aplicaciones distribuidas abiertas

1.2 OSI e Internet

En el cambiante mundo actual de la comunicación entre ordenadores, dos enfoques (dosarquitecturas de comunicación entre ordenadores) distintos, aunque no incompatibles, destacan sobrelos demás. Podemos llamarlos OSI e Internet.

Cuando se habla de OSI (Open Systems Interconnection), o interconexión de sistemas abiertos, seestá haciendo referencia a los sistemas de comunicación entre ordenadores basados en la arquitecturaconocida como OSI (o modelo arquitectónico de referencia OSI), estandarizado por la OrganizaciónInternacional de Estandarización (ISO, International Standards Organization), juntamente con loque 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ónInternacional de Telecomunicaciones (ITU-T).

En el modelo OSI, se definen 7 niveles o capas en los que se estructura la comunicación entreaplicaciones 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 nivelintermedio, el nivel 4 o de transporte, el encargado de independizar la red del ordenador, donderesiden 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 los6 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 modelonacido a partir de la idea de un servicio y protocolo sin conexión (connectionless-oriented) parainterconectar redes, al cual se llamó IP (Internet Protocol). Sobre IP se diseñó el protocolo detransporte TCP (Transmission Control Protocol). Aunque estos protocolos (TCP/IP) se originaron enun 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énen estas aplicaciones donde se concentra este libro que, sin llegar a profundizar en todas lasaplicaciones Internet tan en auge estos días, sí trata sobre la versión Internet de algunas aplicacioneshabituales en un entorno OSI.

Las aplicaciones distribuidas es una disciplina que está cambiando a gran velocidad, por lo que secorre 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 seutilizará 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 lodeben ser para cualquier persona que trabaje en el campo de aplicaciones distribuidas. Los conceptosde sistemas abiertos (en OSI) o de interconexión (tanto en Internet como en OSI) están detrás de estafilosofía. Si queremos conseguir que sistemas heterogéneos puedan comunicarse, deben seguir ciertasreglas, y estas reglas se deben acordar internacionalmente. De ahí la necesidad de disponer deestándares.

Formalmente, los estándares sólo pueden ser publicados por ISO, organización internacionalformada por los organismos de normalización de todos los países del mundo, como AENOR enEspañ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 siemprese trata de armonizar los intereses de las empresas privadas, las públicas y los centros deinvestigación.

ISO, al igual que sus equivalentes nacionales, está estructurada en comités que trabajan en diferentestemas. Por lo que a los contenidos de este libro incumbe, existe un comité conjunto con el CEI oComité Electrotécnico Internacional (IEC, International Electrotechnical Committee) llamado JTC1(Joint Technical Committee 1), que trata todos los temas de las llamadas tecnologías de lainformación. A su vez, el JTC1 está estructurado en subcomités, como el SC18 que trata, en susdistintos grupos de trabajo (WG, Working Group), documentos y protocolos asociados. Ha sido y esresponsabilidad del JTC1 SC18 el desarrollo de los estándares de correo electrónico X.400 (véasecapítulo 4), arquitectura e intercambio de documentos ODA (véase capítulo 5), almacenamiento yrecuperación de documentos DFR (véase capítulo 7), la notación para especificar aplicacionesdistribuidas (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), sonresponsabilidad 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 (yanteriormente el CCITT) está capacitado para publicar lo que ellos llaman recomendaciones que, aefectos 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ónicasprincipalmente, 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 unaterminología propia. ITU-T está formado por grupos de estudio (SG, Study Group), que tratan temasdiferentes, como el SG8, que trabaja en intercambio y manipulación de documentos (véase capítulo6), fax, etc., y el SG7, que trabaja en temas como correo electrónico (véase capítulo 4). Cada SG seestructura, 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 deISO y grupos de estudio de ITU-T, existen temas comunes. Para evitar que ambos organismos


produzcan normas divergentes, muchos grupos de trabajo de ISO han creado equipos de colaboracióno 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ándaresconjuntos 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 eITU-T (basados en comités o grupos de trabajo que desarrollan los estándares a aprobarposteriormente por los organismos miembros), ya que el desarrollo de normas se basa en laimplementación y prueba de lo que se propone especificar. Un estándar Internet no se acepta si noexisten implementaciones probadas.

Debido a la complejidad que pueden tener los estándares de ISO o recomendaciones de ITU-T, sedefinen lo que se llaman estándares funcionales o perfiles, que son subconjuntos implementables delos estándares base. Estos subconjuntos restringen las características de los estándares al eliminarcomplejidades innecesarias en aplicaciones menos exigentes, con lo que se facilita suimplementació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 ITU-T.

En Europa, existe EWOS (European Workshop for Open Systems) que, a través de sus grupos deexpertos en diversos temas, desarrolla perfiles que después coordina con otros organismos regionalespara producir estándares funcionales a aprobar por ISO/IEC. EWOS también es responsable de laproducció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 ImplementorsWorkshop), en Norteamérica, y AOW (Asia Oceania Workshop), principalmente en Japón, Corea yAustralia.

Finalmente, en Europa existe otro organismo oficial de normalización, el Instituto Europeo deEstándares de Telecomunicaciones (ETSI, European Telecommunications Standards Institute), quecomo su nombre indica es responsable en Europa del desarrollo de estándares relacionados con lastelecomunicaciones. 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 quemencionar que existen muchos menos organismos en el proceso de estandarización, y que ademáseste 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 eldocumento [RFC1602], y que a continuación se cita:

"En general, un estándar de Internet es una especificación que es estable y comprensible, estécnicamente competente, tiene múltiples e independientes implementaciones que interoperancon bastante experiencia demostrable, posee un importante soporte y es reconocido como útilpor 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 primerose 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 laInternet puede proponer un borrador de especificación para ser comentado por los demás. A estaespecificación se la conoce como borrador Internet (ID, Internet Draft). Este documento se públicaen la Internet por medio de servidores de información (básicamente ftp, aunque ahora tambiénWWW) para que sea analizado, y comentado públicamente. Si en el plazo de seis meses estedocumento 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 deinformación y desaparece.

Una vez un documento es catalogado como RFC, este puede permanecer así para siempre o iniciar elproceso para alcanzar el estado de estándar de Internet. Para llegar a este estado, el documentodeberá pasar por varios niveles de madurez, pudiéndose quedar en alguno de ellos. Según laterminologí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) yfinalmente estándar de Internet (IS, Internet Standard). La diferencia básica entre ellos, según sedesprende de la definición de estándar de Internet antes citada, es que una propuesta de estándar nonecesita de implementaciones que interoperen, para pasar a borrador de estándar es necesariodisponer de por lo menos dos implementaciones independientes, y el grado de estándar sólo sealcanza 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 oestándar de Internet se lleva a cabo mediante un proceso en el que participa toda la comunidad deInternet 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ónde la Internet; ISOC (Internet Society) que entre otras tiene como actividad la estandarización en laInternet; IESG (Internet Engineering Steering Group) que controla las actividades del IETF; y elIAB (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), asignaridentificadores y parámetros únicos a las RFC, estándares, protocolos, servicios, etc. de la Internet.


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

- Una iniciativa no alcanza el nivel de estándar de Internet si no se demuestra su utilidadprá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 Internetno existen perfiles, ya que todo lo que se estandariza debe estar implementado.

- Todos los documentos (Internet Drafts, RFC, Internet Standards, etc.) son públicos y estándisponibles gratuitamente a toda la comunidad Internet. Esto tampoco es así en el caso de ISOy ITU-T, ya que sus documentos no se encuentran accesibles a todo el público y además hayque 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, InternationalFederation for Information Processing), una organización profesional de informáticos, desde sucomité técnico 6 (TC6, Data Communications) quien empezó el trabajo de normalización del correoelectrónico. Para ello creó, a finales de los 70, un grupo de trabajo (WG6.5) para trabajar en ladefinició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 recomendacionesinternacionales de mensajería electrónica. A pesar de que se fueron descubriendo fallos ylimitaciones, estas recomendaciones del CCITT tienen un mérito innegable, especialmente teniendoen cuenta que es la primera norma completamente desarrollada del nivel de aplicación del modelo dereferencia OSI.

La experiencia adquirida con estas recomendaciones y las primeras implementaciones llevaron alCCITT a desarrollar una nueva versión, aprobada en 1988, que corrige muchas de las limitaciones dela versión del 84. En este trabajo también colaboró ISO, lo que dio lugar a una norma conjunta entreCCITT, Recomendaciones X.400 (MHS) e ISO, Estándar Internacional MOTIS (Message OrientedText Interchange Systems).

En los últimos años, se ha unificado el nombre (MHS, Message Handling System), aparte de haberocurrido los cambios administrativos mencionados, como el paso de CCITT a ITU-T, y la creacióndel ISO/IEC JTC1.

Finalmente, después de 1988 se han publicado nuevas versiones del estándar que no cambiandemasiado la funcionalidad, pero que corrigen y extienden algunas cosas. De hecho, existe una nuevarepublicació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 1985por ECMA (European Computer Manufacturers Association) con el número ECMA-101, y el títuloOpen Document Architecture.

Seguidamente, ISO decidió que era necesario un estándar internacional sobre representación eintercambio 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 ámbitoeuropeo a uno más internacional, en el que se debe destacar la activa participación de empresasamericanas y japonesas.

La tarea se encargó inicialmente a dos grupos de trabajo del subcomité 18 (SC18) de lo que es ahorael comité conjunto número 1 de ISO y la IEC (ISO/IEC JTC1). Actualmente, el grupo de trabajonúmero 3 del mencionado subcomité (es decir, ISO/IEC JTC1 SC18/WG3) es quien tiene la totalresponsabilidad 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 elCCITT (y después ITU-T), ha hecho suyo el compromiso de la estandarización del intercambio dedocumentos, 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 DocumentArchitecture (ODA) and Interchange Format (ODIF). Conviene mencionar aquí que el uso inicial dela palabra Office en vez de Open fue debido a las restricciones a sistemas de oficina queoriginalmente 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 elCCITT usa una estructura diferente, y en vez de tener un estándar con varias partes, tiene variasRecomendaciones que forman una serie. En concreto, el número y título dado por el CCITT eraCCITT T.410 Series of Recommendations: Open Document Architecture (ODA) and InterchangeFormat (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 porOpen.

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 desdeentonces.


ODA 1994 tiene una nueva parte (aunque sólo en la versión de ISO/IEC, no en la de ITU-T), que esla 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 paraespecificar y diseñar aplicaciones en las cuales se procese información de una forma distribuida. Paraello es necesario disponer de una serie de funcionalidades orientadas a resolver los problemasrelacionados con la distribución. Estos recursos los proporcionan los sietes niveles del modelo deinterconexión de sistemas abiertos (OSI, Open Systems Interconnection) de ISO.

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

- Los niveles superiores del modelo OSI (niveles sesión, presentación y aplicación), o nivelesorientados a la aplicación, proporcionan una serie de servicios para la gestión ysincronizació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 necesariospara que una aplicación pueda gestionar información distribuida, facilitando los medios adecuadospara acceder al resto de niveles.

En una aplicación distribuida se pueden distinguir dos partes diferenciadas: la aplicaciónpropiamente dicha y la parte que realiza el acceso a los recursos de comunicación. Es este últimoaspecto el que diferencia una aplicación local de su versión distribuida, y es este aspecto del diseñode aplicaciones distribuidas el que se trata en los primeros capítulos de este libro.


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 deusuario que están utilizando los recursos OSI para intercambiar información (véase la figura 2.1).

Se define un proceso de aplicación (AP, Application Process) como un elemento dentro de unsistema abierto que realiza el procesado distribuido de información (es decir, que implicacomunicación) para una determinada aplicación. Los procesos de aplicación intercambianinformación por medio de entidades de aplicación que implementan protocolos de aplicaciónutilizando servicios de presentación.

Una entidad de aplicación (AE, Application Entity) define los aspectos concernientes a lacomunicación de un proceso de aplicación. Las entidades de aplicación intercambian informaciónpor medio de unidades de datos del protocolo de aplicación (APDU, Application Protocol DataUnit) (véase la figura 2.2).

En el caso más general, un proceso de aplicación puede definir varios tipos de intercambio deinformación. Por lo tanto, su comunicación tendrá varios aspectos que se implementarán mediantediferentes AE. Para la mayor parte de las aplicaciones distribuidas es suficiente una única entidad deaplicación.

Para que dos entidades de aplicación puedan cooperar es necesario establecer previamente unaasociación de aplicación o simplemente una asociación (Application Association). El concepto deasociación en el nivel de aplicación equivale al concepto de conexión en el resto de niveles delmodelo OSI. Una asociación se mapea directamente sobre una conexión de presentación. La entidadde 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 (ResponderEntity).

Una entidad de aplicación consta de un elemento de usuario (UE, User Element) y un conjunto deelementos de servicio de aplicación (ASE, Application Service Element) (véase la figura 2.2).

Proceso Aplicación

Usuario

Protocolo deaplicaciónNivel de

aplicación

Proceso Aplicación

Usuario

Nivel de aplicación

Proveedor del servicio de presentación

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


El elemento de usuario (UE, User Element) representa aquella parte de la entidad de aplicación quecoordina los elementos de servicio de aplicación (ASE) necesarios para llevar a cabo los objetivos decomunicación de dicho proceso de aplicación. Es decir, gestiona los diferentes ASE que constituyendicha 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 unaentidad de aplicación que proporciona una función particular en el entorno OSI. Para ello, si esnecesario, puede utilizar los servicios proporcionados por otros ASE o por los niveles inferiores. UnASE no es más que un conjunto de funciones que permiten a las AE cooperar para un determinadopropósito.

Un ASE queda definido por un servicio y un protocolo. Por lo tanto, cada ASE genera sus propiasAPDUs y define diferentes sintaxis abstractas y de transferencia, con lo que da lugar a diferentescontextos 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 enentidades de aplicación remotas. Algunos ASE son obligatorios, es decir, siempre deben formar partede cualquier entidad de aplicación, mientras que otros son opcionales. En OSI, el usuario del serviciode presentación es siempre un ASE.

Se define un contexto de aplicación (AC, Application Context) como el conjunto de servicios yprotocolos de aplicación utilizados por una entidad de aplicación en una asociación. Básicamenteindica el conjunto de ASE que componen el proceso de aplicación definiendo implícitamente losprotocolos (véase la figura 2.3).

Los ASE que constituyen una entidad de aplicación pueden ser iguales en los dos extremos y recibenel nombre de ASE simétricos, o complementarios y reciben el nombre de ASE asimétricos. En losASE asimétricos uno tiene el papel de consumidor o cliente y el otro el papel de suministrador oservidor del servicio (véase el apartado 3.1.1 correspondiente a la arquitectura cliente/servidor).

Proceso Aplicación

Usuario

Protocolos deaplicación

Proceso Aplicación

Usuario

AE

Conexión de presentación

ASE1

ASEn

... ASE1

ASEn

...

UE

AE

UE

(APDU)

Fig. 2.2 Estructura de una entidad 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 aplicacionesdistribuidas utilizan. Por esta razón se creyó conveniente estandarizarlos y se ofrecen como unrecurso común en los entornos de desarrollo de aplicaciones distribuidas. Así el diseñador puedeutilizar estos ASEs comunes y concentrarse en el diseño de la aplicación propiamente dicha.

Los ASE específicos son aquella parte de una entidad de aplicación que implementan lasfuncionalidades concretas del sistema distribuido que se está diseñando y son la parte que diferenciaunas 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 entreentidades 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 tipopetición/respuesta (paradigma cliente/servidor).

Estos ASE comunes no son los únicos que se han normalizado, pero a lo largo del libro solamente seva a hacer referencia a estos tres.

Proceso Aplicación

Usuario

Protocolo deaplicación

AE

Proceso Aplicación

Usuario


UE

ASE

ROSE

ACSE

RTSE

AE

UE

ASE

ROSE

ACSE

RTSE

ASE ASE

Fig. 2.3 Estructura de un contexto de aplicación


La figura 2.3 ilustra el concepto de contexto de aplicación. Se puede observar que existe una relaciónentre 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 unaentidad de aplicación dentro del entorno OSI. Para conseguirlo se utilizan, a nivel dedireccionamiento, 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 elestablecimiento de la asociación donde se concreta el conjunto de protocolos que se van a utilizar enesa asociación.

El título de un proceso de aplicación (AP-Title, Application Process Title) identifica un proceso deaplicación concreto dentro del entorno OSI.

Un calificador de entidad de aplicación (AE-Qualifier, Application Entity Qualifier) identifica unaentidad 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 deaplicació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 entidadde 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 deASN.1. A partir de la información de direccionamiento de aplicación, normalmente el AP-Title, sedebe 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 noestándar, o normalizado utilizando el servicio de directorio estándar (X.500) donde, a partir de unnombre distintivo, como AP-Title, es posible obtener la dirección de presentación. (véase el capítulo5).

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 elencargado de suministrar facilidades para la gestión de asociaciones entre entidades de aplicaciónque se comunican a través de una conexión de presentación. El elemento de servicio común ACSE es


obligatorio, es decir, debe formar parte de cualquier entidad de aplicación. Existe unacorrespondencia uno a uno entre una conexión de presentación y una asociación de aplicación. Losestá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 depresentación.

Los servicios que suministra ACSE son los siguientes:

Servicio TipoA-ASSOCIATE ConfirmadoA-RELEASE ConfirmadoA-ABORT No confirmadoA-P-ABORT 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, elcontexto de aplicación, la lista de contextos de presentación válidos para cada ASE y el contexto depresentación por defecto para una asociación determinada.

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

Proveedor ACSEUsuario ACSE Usuario ACSE

A-ASSOCIATE.request

A-ASSOCIATE.confirm

A-ASSOCIATE.indication

A-ASSOCIATE.response

Fig 2.4 Primitivas del servicio A-ASSOCIATE de ACSE


- 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 quehace referencia a la opcionalidad.

El parámetro “modo” selecciona entre un modo de funcionamiento de ACSE normal, que además esel valor por defecto, y un modo de funcionamiento específico para mensajería electrónica. Con elparámetro “contexto de aplicación”, el iniciador de la asociación propone un contexto de aplicaciónpara la asociación que solicita. A continuación hay una serie de parámetros donde se identifican lasentidades 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 incluirinformación (por ejemplo, credenciales de autenticación, etc.). El parámetro “resultado” contieneinformació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” indicala 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óniniciadora o llamada desconocido’. El resto son parámetros relacionados con los niveles depresentació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 A-ASSOCIATE.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 unaasociación sin pérdida de información en tránsito (Fig. 2.5). La liberación de una asociación puedeiniciarla cualquiera de las dos entidades de aplicación.


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 losvalores ‘normal’, ‘urgente’ o ‘definido por el usuario’, pero si es un parámetro de la primitiva A-RELEASE.response, los valores posibles son: ‘normal’, ‘no finalizada’ o ‘definida por el usuario’. Elparámetro “resultado” lo utiliza la entidad de aplicación que acepta la asociación para indicar laaceptació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. Esun servicio no confirmado (Fig. 2.6).


A-RELEASE.request

A-RELEASE.confirm

A-RELEASE.indication

A-RELEASE.response

Fig 2.5 Primitivas del servicio A-RELEASE de ACSE


A-ABORT.request

A-ABORT.indication

Fig. 2.6 Primitivas del servicio A-ABORT de ACSE


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. Elcampo de “información de usuario” pueden utilizarlo las entidades de aplicación para incluirinformació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. Unavez generada la primitiva A-ABORT.request, para el iniciador la asociación ha sido liberada. Elproveedor del servicio ACSE puede utilizar el servicio A-ABORT para liberar una asociación porproblemas 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 unainiciativa del proveedor del servicio.

El servicio A-P-ABORT es un servicio no confirmado que consta de una sola primitiva A-P-ABORT.indication, y que inicia el proveedor del servicio ACSE (Fig. 2.7). El proveedor del servicioACSE 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 deinformació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

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


A-P-ABORT.indication A-P-ABORT.indication

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


2.4.2 Protocolo

El protocolo ACSE describe la transferencia de información entre entidades de aplicación para lagestió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 A-ASSOCIATE-REQUESTAARE A-ASSOCIATE-RESPONSERLRQ A-RELEASE-REQUESTRLRE A-RELEASE-RESPONSEABRT A-ABORT

La fase de establecimiento de una asociación utiliza las APDU AARQ y AARE, la fase de liberaciónnormal 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 lascorrespondientes APDU que las transportan.

Primitiva ACSE APDUA-ASSOCIATE.request/indication AARQA-ASSOCIATE.response/confirmation AAREA-RELEASE.request/indication RLRQA-RELEASE.response/confirmation RLREA-ABORT.request/indication ABRTA-P-ABORT.indication ---

Para hacerse una idea de la complejidad del protocolo ACSE, la máquina de protocolo de control deasociaciones consta de ocho estados, del orden de 40 transacciones, 15 eventos entrantes y otrostantos salientes.

2.5 RTSE (Elemento de servicio de transferencia fiable)

El elemento de servicio común RTSE (Reliable Transfer Service Element) es el encargado desuministrar 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 elencargado de manejar el elemento de servicio ACSE para la gestión de asociaciones, y del nivel de


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 duranteel proceso de transmisión de la información, minimizando el número de retransmisiones. De estaforma, libera al diseñador de aplicaciones distribuidas de tener que preocuparse por la gestión de lasfacilidades que suministra sesión, a través de presentación, para recuperarse de dicho tipo deproblemas.

2.5.1 Servicio

El servicio RTSE utiliza el servicio de ACSE para gestionar asociaciones, y asume que se disponecomo mínimo del subconjunto básico de actividades de sesión (BAS) accesible a través del serviciode 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 yactividades.

Los servicios que suministra RTSE son los siguientes:

Servicio TipoRT-OPEN ConfirmadoRT-TRANSFER Confirmado (Sólo solicitud, indicación y confirmación)RT-TURN-PLEASE No confirmadoRT-TURN-GIVE No confirmadoRT-CLOSE ConfirmadoRT-U-ABORT No confirmadoRT-P-ABORT No confirmado (Sólo indicación)

RT-OPEN

El servicio RT-OPEN, que es confirmado, utiliza el elemento de servicio ACSE para establecer unaasociación, concretamente mediante el servicio A-ASSOCIATE (Fig. 2.8).

Proveedor RTSEUsuario RTSE Usuario RTSE

RT-OPEN.request

RT-OPEN.confirmation

RT-OPEN.indication

RT-OPEN.response

Fig 2.8 Primitivas del servicio RT-OPEN de RTSE


El servicio RT-OPEN tiene los siguientes 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 deldiálogo”, que puede ser monólogo, es decir, que únicamente la entidad que está inicialmente enposesión del turno puede transmitir APDU, o TWA, donde las dos entidades pueden hacerloalternativamente siempre y cuando estén en posesión del turno, el cual puede intercambiarse. Otroparámetro nuevo es el “turno inicial”, que lo puede poseer la entidad que inicia o la que responde laasociación. El parámetro “protocolo de aplicación” sólo tiene sentido en el modo X.410-1984 (véaseel apartado 2.4 relacionado con ACSE). El parámetro “datos de usuario” se puede utilizar paraalmacenar 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 aACSE.

RT-TRANSFER

El servicio RT-TRANSFER lo utiliza el usuario de RTSE que está en posesión del turno paratransmitir APDU de forma fiable mediante una asociación de aplicación. Normalmente, los serviciosconfirmados constan de cuatro primitivas; en cambio, el servicio RT-TRANSFER sólo tiene tresprimitivas (véase la figura 2.9). La razón es que una APDU se transmite dentro de una actividad, porlo que la finalización de la actividad con normalidad significa que la APDU ha sido transferidacorrectamente por el proveedor de RTSE. Es el protocolo RTSE el que garantiza que la APDU se hatransmitido, por lo que el usuario receptor no necesita confirmarlo, ya que lo hace directamente elproveedor de RTSE (véase el apartado 2.5.2 correspondiente al protocolo RTSE).

Los parámetros del servicio RT-TRANSFER son:

- APDU a transmitir


RT-TRANSFER.request

RT-TRANSFER.confirmation

RT-TRANSFER.indication

Fig. 2.9 Primitivas del servicio RT-TRANSFER de RTSE


- 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áximoestimado para la transferencia de la APDU; es decir, el tiempo que transcurre entre que el usuario deRTSE invoca el servicio RT-TRANSFER con la primitiva RT-TRANSFER.request y el mismousuario 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 casoen que el resultado es negativo significa que el proveedor de RTSE no ha podido entregar la APDUen el tiempo de transferencia especificado, mientras que si el resultado es positivo, significa que elproveedor 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 quehacen posible que la transferencia de APDU se realice dentro de una actividad (véase el apartado2.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 deaplicació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ónpara liberarla.

El servicio RT-TURN-PLEASE sólo tiene un parámetro, que es la prioridad asociada a la acciónpara la que se solicita el turno. Con esta información, el usuario de RTSE remoto puede decidircuándo entrega el turno. La prioridad cero indica la prioridad más alta y se reserva para liberar laasociació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 deaplicación entregar el turno al usuario de RTSE remoto, siempre y cuando esté en posesión del turno


RT-TURN-PLEASE.request

RT-TURN-PLEASE.indication

Fig. 2.10 Primitivas del servicio RT-TURN-PLEASE de RTSE


y no esté pendiente de la finalización de un servicio de transferencia de APDU (RT-TRANSFER)(véase la figura 2.11).

El servicio RT-TURN-GIVE no tiene parámetros y se mapea directamente sobre el servicio depresentación P-CONTROL-GIVE.

RT-CLOSE

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

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.410-1984 no existen parámetros.


RT-TURN-GIVE.request

RT-TURN-GIVE.indication

Fig. 2.11 Primitivas del servicio RT-TURN-GIVE de RTSE


RT-CLOSE.request

RT-CLOSE.confirmation

RT-CLOSE.indication

RT-CLOSE.response

Fig. 2.12 Primitivas del servicio RT-CLOSE de RTSE


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 deforma abrupta, y utiliza los servicios equivalentes de ACSE. El servicio RT-U-ABORT es un serviciono confirmado (véase la figura 2.13).

El servicio RT-U-ABORT sólo tiene un parámetro, que es un campo de información del usuario quese 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 unainiciativa del proveedor del servicio RTSE y, como en el caso anterior, lo hace utilizando el servicioequivalente de ACSE A-P-ABORT (véase la figura 2.14). El proveedor del servicio informa a los dosusuarios de RTSE que le es imposible mantener la asociación de aplicación.

El servicio RT-P-ABORT, que no tiene parámetros, es un servicio no confirmado que consta de unasola 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.


RT-U-ABORT.request

RT-U-ABORT.indication

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


RT-P-ABORT.indication RT-P-ABORT.indication

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


2.5.2 Protocolo

La máquina de protocolo de RTSE (RTPM, Reliable Transfer Protocol Machine), proporciona elservicio RTSE que se ha descrito en el apartado anterior utilizando el elemento de servicio ACSE yel 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 RT-OPEN-REQUESTRTOAC RT-OPEN-ACCEPTRTORJ RT-OPEN-REJECTRTTR RT-TRANSFERRTTP RT-TOKEN-PLEASERTAB RT-P-ABORT y RT-U-ABORT

A continuación se muestra una tabla donde se indica el mapeo entre las primitivas de servicio deRTSE y las primitivas de ACSE, así como las APDU que las transportan.

Primitiva RTSE APDU Primitiva ACSERT-OPEN.request/indication RTORQ A-ASSOCIATE.request/indicationRT-OPEN.response/confirmation RTOAC A-ASSOCIATE.response/confirmationRT-OPEN.response/confirmation RTORJ A-ASSOCIATE.response/confirmationRT-CLOSE.request/indication --- A-RELEASE.request/indicationRT-CLOSE.response/confirmation --- A-RELEASE.response/confirmationRT-U-ABORT.request/indication RTAB A-ABORT.request/indicationRT-P-ABORT.indication RTAB A-P-ABORT.indication

Cuando un usuario de RTSE invoca el servicio RT-TRANSFER, la transferencia fiable de la APDUse realiza a nivel de presentación dentro de una actividad (servicios P-ACTIVITY-START y P-ACTIVITY-END). Para poder transmitir la APDU será necesario fraccionar la APDU en una seriede trozos de un determinado tamaño que se habrá negociado en la fase de establecimiento de laasociación (espaciado entre puntos de sincronización). Para poder fraccionar la APDU primero esnecesario serializar la información, para lo cual, la máquina de protocolo de RTSE deberá obtener lasintaxis de transferencia y entregar cada fragmento al servicio de presentación. A cada uno de estosfragmentos de la APDU original así obtenidos se le asigna el tipo OCTECT STRING de ASN.1, y seentregan al servicio de presentación mediante tantas primitivas del servicio P-DATA como seanecesario. Con el objeto de facilitar las retransmisiones en caso de problemas, se va marcando latransmisión con puntos de sincronización menor (servicio P-MINOR-SYNC). El número de puntos


de sincronización que pueden existir sin confirmar se negocia también en la fase de establecimientode la asociación (tamaño de la ventana). La utilización de actividades a nivel de presentaciónjustifica que el servicio RT-TRANSFER tenga tres primitivas en vez de cuatro como tienen todos losservicios confirmados. Efectivamente, el hecho de que la actividad de presentación acabenormalmente significa que la APDU se ha transmitido correctamente y se encuentra íntegra en elproveedor de RTSE remoto. Incluir una primitiva de respuesta a nivel de usuario de RTSE noaportaría nada respecto a la transmisión de la APDU, pero en cambio introduciría redundancia en latransmisión. En la figura 2.15 se ilustra gráficamente la relación entre la utilización por un usuariode RTSE del servicio RT-TRANSFER para transmitir una APDU, y los servicios de presentaciónnecesarios para transmitirla dentro de una actividad.

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 paraobtener una sintaxis de transferencia es una función del nivel de presentación. En cambio se ha dichoque 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 desistemas 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 lasprimitivas de presentación, así como también las APDU que las transportan.

Primitiva RTSE APDU Primitiva PresentaciónRT-TRANSFER.request/indication --- P-ACTIVITY-START.request/indication

RTTR P-DATA.request/indication--- P-MINOR-SYNCHRONIZE

RT-TRANSFER.indication/confirmation --- P-ACTIVITY-END

ProveedorUsuario RTSE Usuario RTSE

RT-OPEN.request

RT-OPEN.confirmation

RT-TRANSFER.indication

P-ACTIVITY-START .request

P-DATA.request

P-SYNC-MINOR.request

P-ACTIVITY-END.request

P-ACTIVITY-START .indication

P-DATA.indication

P-SYNC-MINOR.indication

P-ACTIVITY-END.indication

P-ACTIVITY-END.response

P-ACTIVITY-END.confirmation


RT-TURN-PLEASE.request/indication RTTP P-TOKEN-PLEASE.request/indicationRT-TURN-GIVE.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 ServiceElement), que se utiliza para implementar aplicaciones distribuidas interactivas del tipopetición/respuesta (paradigma cliente/servidor). Una entidad de aplicación invoca la operaciónremota (invoker entity) y la otra la realiza y genera un resultado (performer entity). El mecanismo deoperaciones 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 delresultado de la operación remota. Así, si se ha ejecutado correctamente, la respuesta será unresultado; si se ha ejecutado pero sin éxito, la respuesta será un error; y la última posibilidad es quela 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).

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

Invocaoperaciónremota

AE AEInvocación

ResultadoRechazo

Error

Realizaoperación

remota

Fig 2.16 Modelo funcional para ROSE


En algunos casos es útil disponer de la posibilidad de agrupar operaciones de forma que unaoperación inicial, llamada operación padre, desencadene como respuesta nuevas operacionesllamadas operaciones hijas. Se dice que las operaciones hijas están enlazadas ("linked") con laoperación padre (véase la figura 2.18).

2.6.1 Servicio

Los servicios que ofrece ROSE son los siguientes:

Servicio TipoRO-INVOKE No confirmadoRO-RESULT No confirmado

AE

InvocaciónRespuesta

Invocaciones

Respuestas

Invocaciones

Error

Invocaciones

Resultado

Invocaciones

AEInvocaciónRespuesta

Clase 1

Clase 2

Clase 3

Clase 4

Clase 5

Invoca RO Realiza RO

Fig. 2.17 Clases de operaciones remotas de ROSE

ejecuta las operaciones hijas

enlazadas

AE AEinvocación deoperación padre

invocación deoperación hija

invocación deoperación hija

ejecuta la operación padre

ejecución de operación

padre

Fig 2.18 Operaciones remotas enlazadas


RO-ERROR No confirmadoRO-REJECT-U No confirmado (Iniciado por el usuario)RO-REJECT-P No confirmado (Iniciado por el proveedor)

RO-INVOKE

El servicio RO-INVOKE, que es no confirmado, lo utiliza un usuario de ROSE para invocar unaoperación remota que deberá ejecutar el usuario de ROSE remoto (véase la figura 2.19).

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 queser el mismo para los dos usuarios de ROSE. El argumento "clase de la operación" sirve para saber sise utiliza modo síncrono o asíncrono y el tipo de respuesta esperada (resultado, error o rechazo); suuso 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 dela invocación" sirve para asociar una respuesta a una invocación cuando se trabaja en modoasíncrono o para el caso de que existan operaciones enlazadas (o hijas). El parámetro "identificadorde la operación enlazada", que es opcional, si existe significa que la operación invocada es unaoperación hija y se utiliza para indicar la operación padre. El parámetro "prioridad" se utiliza paraasignar una escala de prioridades a las diferentes transferencias de APDU entre las entidades deaplicación.

El servicio RO-INVOKE de ROSE se mapea directamente sobre el servicio P-DATA del nivel depresentación.

Proveedor ROSEUsuario ROSE Usuario ROSE

RO-INVOKE.request

RO-INVOKE.indication

Fig. 2.19 Primitivas del servicio RO-INVOKE de ROSE


RO-RESULT

El servicio RO-RESULT lo utiliza el usuario de ROSE que ejecuta la operación para devolver elresultado de la operación solicitada en el caso de que ésta se haya ejecutado con éxito. Es un serviciono confirmado (véase la figura 2.20).

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 laoperación con el servicio RO-INVOKE. Como su nombre indica, el parámetro "resultado" contieneel 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 depresentación.

RO-ERROR

El servicio RO-ERROR, que es un servicio no confirmado, lo utiliza el usuario de ROSE que ejecutala operación para indicar al usuario que invoca la operación solicitada que se ha ejecutado conerrores (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


RO-RESULT.request

RO-RESULT.indication

Fig. 2.20 Primitivas del servicio RO-RESULT de ROSE


El parámetro "identificador del error" identifica el tipo de error que se ha producido al ejecutar laoperación y en el parámetro "parámetro del error" el usuario de ROSE puede incluir informaciónadicional respecto al error. Los parámetros "identificador de la invocación" y "prioridad" son losmismos 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 servicioP-DATA.

RO-REJECT-U

El servicio RO-REJECT-U lo puede utilizar un usuario de ROSE para indicar al otro usuario deROSE que no puede ejecutar la operación remota solicitada mediante el servicio RO-INVOKE, aldetectar algún tipo de problemas (véase la figura 2.22). También se puede utilizar este servicio pararechazar una respuesta (resultado o error) de una invocación anterior.

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 ladescripción de los otros servicios de ROSE. El parámetro "causa del error" contiene información


RO-ERROR.request

RO-ERROR.indication

Fig. 2.21 Primitivas del servicio RO-ERROR de ROSE


RO-REJECT-U.request

RO-REJECT-U.indication

Fig 2.22 Primitivas del servicio RO-REJECT-U de ROSE


diferente según sea un rechazo a una primitiva RO-INVOKE.indication, RO-RESULT.indication oRO-ERROR.indication anteriores. Las causas de rechazo de una primitiva RO-INVOKE.indicationson las siguientes: ‘invocación duplicada’, ‘operación desconocida’, ‘argumento erróneo’, ‘recursoslimitados’, ‘liberación del iniciador de la asociación’, ‘identificador de la operación enlazadadesconocido’, ‘respuesta de la operación enlazada no esperada’ y ‘operación hija no esperada’. En elcaso 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 rechazocorresponde a una primitiva RO-ERROR.indication, las causas de rechazo son: invocacióndesconocida, 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 depresentación.

RO-REJECT-P

El servicio RO-REJECT-P lo utiliza el proveedor del servicio ROSE para indicar a sus usuarios queha detectado algún tipo de problema. Es un servicio no confirmado que, al ser iniciado por elproveedor, únicamente tiene una primitiva que es RO-REJECT-P.indication (véase la figura 2.23).

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 elidentificador de la invocación, la causa del rechazo y un campo de parámetros del rechazo quecontiene el parámetro de la primitiva rechazada para el caso de que el proveedor de ROSE no hayapodido 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 elservicio P-DATA.


RO-REJECT-P.indication RO-REJECT-P.indication

Fig. 2.23 Primitivas del servicio RO-REJECT-P de ROSE


2.6.2 Protocolo

El protocolo ROSE queda definido por la máquina de protocolo de ROSE (ROPM, RemoteOperations Protocol Machine). Se pueden identificar una serie de elementos de protocolo que son lossiguientes:

- Invocación- Retorno de resultado- Retorno de error- Rechazo del usuario- Rechazo del proveedor

El protocolo de ROSE define las siguientes APDU:

ROIV RO-INVOKERORS RO-RESULTROER RO-ERRORRORJ RO-REJECT

A continuación se muestra el mapeo entre las primitivas de servicio de ROSE y el servicio depresentación, así como las APDU que se utilizan para transportar dichas primitivas.

Servicio ROSE APDU Servicio presentaciónRO-INVOKE.request/indication ROIV P-DATA.request/indicationRO-RESULT.request/indication RORS P-DATA.request/indicationRO-ERROR.request/indication ROER P-DATA.request/indicationRO-REJECT-U.request/indication RORJ P-DATA.request/indicationRO-REJECT-P.request/indication RORJ 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. Enel apartado 3.1 se estudia un modelo arquitectónico y funcional mediante el cual se puede modelaruna gran parte de sistemas distribuidos. Este modelo, llamado DOAM, se corresponde con la llamadaarquitectura cliente/servidor. En el apartado 3.2 se describe un lenguaje estándar de especificaciónformal independiente de la implementación, llamado ASDC, mediante el cual se puede describirformalmente cualquier aplicación distribuida. En el apartado 3.3 se muestra como realizar unaimplementación OSI del sistema distribuido así especificado. Para ello, se describe una notaciónllamada notación-RO porque permite especificar las operaciones remotas que, en OSI, seimplementan 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 aplicacionesde 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


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 usuarioaccede a la aplicación a través del interfaz de aplicación (Application Interface) (Fig. 3.1).

Usuario

Cliente

Servidor

Definición de servicio

Interfaz de aplicación


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 lamisma máquina que el usuario y será el encargado de convertir las llamadas locales del usuario enllamadas remotas al servidor. El proceso servidor, que normalmente residirá en otra máquina, será elencargado de ejecutar las operaciones solicitadas por el usuario.

Usuario

Cliente

Servidor

Definición de servicio

Interfaz de aplicación

Nivel de aplicaciónProtocolo de acceso

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 OSImediante lo que se llama protocolo de acceso al servicio (Access protocol). La distribución de una


aplicación debe siempre hacerse de forma transparente al usuario, es decir, el interfaz de aplicaciónque 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, losservidores pueden llegar a tener cierta complejidad y suelen residir en máquinas más potentes. En elcaso de aplicaciones distribuidas complejas, el servidor no tiene por qué ser único, sino que puede sera su vez un servidor distribuido formado por una serie de servidores componentes que cooperan entresí con el objeto de proporcionar un servicio global a sus usuarios. Por tanto puede refinarse el modeloanterior para el servidor tal y como se muestra en la figura 3.3, en la que puede observarse elservidor global o sistema servidor compuesto de una serie de servidores elementales o simplementeservidores que se comunican entre sí gracias al protocolo de sistema, para suministrar los serviciossolicitados por el cliente, que accede al sistema servidor por medio del protocolo de acceso. Losservidores componentes no tienen que ser necesariamente iguales.

Cliente

Servidor

Servidor

Servidor

Definición del servicio

2)

2)

1)3)

3)

3)

1) Protocolo de acceso2) Protocolo de acceso (opcional)3) Protocolo de sistema (si es necesario)

Sistema servidor

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 teneracceso a más de un servidor componente y no únicamente al servidor elemental mediante el queaccede normalmente al sistema servidor. En este caso, aparece la necesidad de un nuevo protocolo deacceso, normalmente opcional, que aparece en la figura 3.3 con el número 2. Los otros dosprotocolos corresponden al protocolo de acceso del cliente al sistema servidor del que ya se hahablado anteriormente, y al protocolo entre los servidores componentes, que se ha llamado protocolode sistema.

Supóngase, por ejemplo, que el servidor mantiene una base de datos distribuida. Si existe elprotocolo de acceso 2, el cliente podrá acceder directamente al servidor componente que tiene lainformación que solicita. Si no dispone de ese protocolo de acceso, lo tendrá que hacerindirectamente a través del protocolo de acceso 1, y será el servidor componente al que tiene acceso,


el encargado de tramitar la solicitud hasta el servidor adecuado mediante la utilización del protocolodel 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 losprotocolos OSI, en concreto con el nivel de aplicación. En la figura 3.4 se muestra cómo realizar laimplementación OSI de una aplicación distribuida DOAM, en la que pueden relacionarse todos losconceptos 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 medianteel 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 queen este caso son asimétricos y están representados por los elementos de servicio del cliente (ASE delcliente) y del servidor (ASE del servidor). La parte del cliente y del servidor que no requiere unacomunicación OSI vendrían representadas respectivamente por la parte del cliente y del servidor queno forman parte de las entidades de aplicación (véase la figura 3.4).

AE


UE

ASEcliente

ROSE

ACSE

RTSE

AE

UE

ASEserv.

ROSE

ACSE

RTSE

Usuario

Cliente Servidor

Protocolo deaccessoNivel de

aplicación

Nivel de presentación e inferiores

Fig. 3.4 Modelo DOAM y realización OSI


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 sepueden identificar dos tipos de servidores elementales, aquéllos que únicamente se comunican conotro servidor elemental, y aquéllos que además también deben establecer comunicación con uncliente. 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étricamediante el protocolo que hemos llamado protocolo de sistema. El segundo tipo de servidorelemental requiere la utilización de dos contextos de aplicación, que se pueden implementarmediante una o dos entidades de aplicación. En el caso de la figura 3.5 se ha optado por utilizar dosentidades de aplicación (EA 1 y EA 2). Una EA se utiliza para la comunicación con otro servidorelemental (EA 2) mediante el protocolo de sistema y la otra EA (EA 1) sirve para la comunicacióncon el cliente mediante el protocolo de acceso. Recordemos que ésta última es una relaciónasimétrica.

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 eldocumento. ISO ha estandarizado una serie de operaciones sobre documentos, concretamenteaquellas más comunes, con la finalidad de que los diseñadores de este tipo de aplicaciones dispongande su especificación y la puedan utilizar en sus diseños, lo cual no significa que éstos puedan definirsus propias operaciones. En el estándar se define, para cada operación, los parámetros que utiliza ylos resultados que se obtienen. A continuación se listan dichas operaciones normalizadas junto conuna breve descripción de cada una de ellas.

Usuario

Cliente Servidor Servidor

Entidad de aplicación

1)

ASE (1)


1)

ASE (1)


2)

ASE (2)


2)

ASE (2)

Conexión de presentación Conexión de presentación


Nivel de presentación y niveles inferiores

Protocolo deProtocolo de

sistemaacceso


Operación DescripciónListar (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 unusuario pueda acceder a más de un servicio remoto (o servidor). En este caso se define un sistematipo cliente/servidor para cada servicio remoto según el modelo DOAM. La adaptación del modelogeneral DOAM para el caso de aplicaciones distribuidas múltiples se ilustra en la figura 3.6, dondepara cada servicio se define un interfaz de aplicación (interfaz de aplicación A, interfaz de aplicaciónB,..), 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 deaplicación de usuario consta de todos los clientes más un elemento de usuario que se encargará, poruna 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

Cliente A

Servidor A

Interfaz deaplicación B

Protocolo de acceso A

Cliente B

Servidor B

Protocolo de acceso B

Interfaz deaplicación A

Fig. 3.6 Modelo DOAM para aplicaciones distribuidas múltiple


3.2 Especificación y diseño de sistemas distribuidos: ASDC

Se han estandarizado unas reglas o convenciones para la definición de servicios abstractosconocidas como ASDC (Abstract Service Definition Conventions). El lenguaje de especificaciónASDC sirve para especificar formalmente sistemas distribuidos, estandarizados o no, que se puedenutilizar o no en un entorno OSI. El que sea una especificación abstracta significa que esindependiente de la implementación y, al ser formal, es posible utilizar herramientas automáticas osemiautomáticas que, a partir de la especificación, nos permitan llegar hasta la implementación. Enel estándar [ASD0190] se define el lenguaje formal de especificación ASDC que forma parte de losestá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 semuestran 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ódulosllamados objetos abstractos (Abstract Objects) los cuales cooperan a través de canales decomunicació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 otrosobjetos por medio de uno o varios puertos abstractos. Para la especificación de un objeto abstracto enASDC se utiliza una macro de ASN.1 llamada OBJECT, a través de la que se le adjudica unidentificador y se le asocia una lista de puertos abstractos para su acceso. El identificador no es más


que un tipo de dato Object Identifier de ASN.1 mediante el cual se le adjudica un identificador únicoen el entorno OSI. Para cada puerto abstracto asimétrico se debe indicar el papel, que puede serconsumidor ([C]) o suministrador ([S]). En la figura 3.7 se muestra la sintaxis del uso de la macroOBJECT 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 esterefinamiento, llamado refinamiento abstracto, aparecen los objetos abstractos que lo componen ymediante la palabra reservada RECURRING se indica si puede existir más de un objeto abstracto deeste tipo (por defecto el objeto es único). También se enumeran los puertos abstractos asociados acada 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 lalista de objetos abstractos relacionados con él mediante dicho puerto (PAIRED WITH). Además, si sequiere que un puerto abstracto sea visible desde el exterior del objeto que se está refinando, se indicacon la palabra reservada VISIBLE. Es decir, éste sería el caso de puertos abstractos que están en lafrontera de dos sistemas. En la figura 3.8 se muestra la sintaxis del uso de la macro REFINE deASDC para refinar un objeto abstracto en sus objetos componentes.

nombre-del-refinamientoREFINE objeto-a-refinar AS

nombre-objeto-1 -- objeto abstracto único

nombre-objeto-2 RECURRING -- objeto abstracto múltiple

nombre-objeto-3

puerto-abstracto papelPAIRED 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 ovarios puertos abstractos. Estos servicios reciben el nombre de operaciones abstractas(Abstract Operations) y se deben definir mediante la utilización de la macro ABSTRACT-OPERATION 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 sepueden utilizar a través de cada puerto y quién las debe invocar.


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 osuministrador. 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 puedenactuar indistintamente como consumidor o suministrador.

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 dotade un identificador (que es un Object Identifier de ASN.1) y se enumera las operaciones abstractasque se pueden utilizar y quién las invoca.

Si el puerto es simétrico se indica mediante la palabra reservada ABSTRACT OPERATIONS y seenumeran las operaciones abstractas que se pueden utilizar en ese puerto, que pueden ser invocadasindistintamente por los dos extremos (véase la figura 3.10).

nombre-puerto PORT --puerto abstracto simétrico

ABSTRACT OPERATIONS {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 enumerar qué operaciones deben ser invocadas por el consumidor(CONSUMER INVOKES) y por el suministrador (SUPPLIER INVOKES) (véase la figura 3.11).

Objetoservidor

Objetocliente

Objetoservidor

Objeto entorno

Puertoasimétrico

Operación

Puertosimétrico

Objetocliente

. . .


nombre-puerto PORT --puerto abstracto asimétrico

CONSUMER INVOKES {lista-operaciones} --operaciones invocadas por consumidor

SUPPLIER INVOKES{lista-operaciones} --operaciones invocadas por suministrador

::= 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 macroABSTRACT-OPERATION de ASN.1. Para cada procedimiento u operación abstracta se puedenindicar los argumentos (ARGUMENT), los resultados (RESULT) y los posibles errores (ERRORS)(véase la figura 3.12).

nombre-operaciónABSTRACT-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 sepueden comunicar si previamente no se han unido sus puertos abstractos. Dicha unión debe seguirlas 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 esconsumidor y el otro suministrador.

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

nombre-bind ::= ABSTRACT-BIND

TO {lista-puertos}

BIND



BIND-ERROR TipoErrorBind

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


La ruptura del enlace de dos puertos abstractos se llama liberación de una unión abstracta (AbstractUnbind) y se realiza mediante la utilización de la macro ABSTRACT-UNBIND de ASN.1. Como enel caso de la unión abstracta, es necesario indicar a qué puertos abstractos hace referencia laliberació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 ::= ABSTRACT-UNBIND

FROM {lista-puertos}

UNBIND



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 definirlomediante la macro ABSTRACT-ERROR de ASN.1, donde es posible asociar parámetros a cada errorde forma opcional (véase la figura 3.15).

nombre-error ::= ABSTRACT-ERROR

PARAMETER 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 laespecificación ASDC, de operaciones (ABSTRACT-OPERATION), errores (ABSTRACT-ERROR),uniones (ABSTRACT-BIND) y liberaciones de uniones (ABSTRACT-UNBIND) abstractas son lasmismas que las utilizadas en la notación-RO de ROSE para su implementación OSI, es decir, sedefinen (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 paraimplementar las operaciones remotas. Este lenguaje deriva de ASN.1 y se ha generado a partir de la


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

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 deASN.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 quierediseñar, pero es necesario también indicar cómo identificarlo en el entorno OSI. Para esto se hancreado dos macros de ASN.1 adicionales que sirven para especificar los elementos de servicio deaplicación (ASE) específicos necesarios para implementar dicho servicio (macro APPLICATION-SERVICE-ELEMENT), y con la segunda macro, llamada APPLICATION-CONTEXT, se especificael contexto de aplicación asociado a dicho nuevo servicio. Las macros normalizadas de ASN.1 paradefinir ASE específicos y contextos de aplicación son las siguientes:

Notación RO

Compilador-Enlazador

CompiladorNotación-RO

Cliente

Servidor

Compilador-Enlazador

Ejecutablecliente

Ejecutableservidor


APPLICATION-SERVICE-ELEMENT: Para cada ASE específico del contexto de aplicaciónAPPLICATION-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 entidadinvocadora de la operación utiliza como “identificador de operación” cuando quiera que la entidadremota ejecute la operación. Este identificador puede tener un ámbito de validez local o global. Eneste último caso es necesario que sea del tipo OBJECT IDENTIFIER de ASN.1. Mediante la palabraclave ARGUMENT se pueden especificar los tipos de datos correspondientes a los argumentos de laoperación remota. Si la operación se ha ejecutado con éxito y devuelve resultados, éstos seespecifican con la palabra clave RESULT. Es posible que la operación se ejecute incorrectamente; encuyo caso los posibles errores generados se especifican con la palabra clave ERRORS. Finalmente, sila operación especificada es la operación padre de una serie de operaciones enlazadas, es necesarioutilizar la palabra clave LINKED para listar las operaciones hijas (véase la figura 3.17).

nombre-operaciónOPERATION


3.3.2 Errores

Todos los errores que aparezcan en las macros OPERATION de las operaciones remotas se debenespecificar con la utilización de la macro ERROR, que permite asociar a cada error un identificadory, opcionalmente, con la palabra clave PARAMETER, una serie de parámetros. Si el error tiene unavalidez local, es suficiente que el identificador asociado sea un entero, pero si debe tener una validezglobal 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


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.3 Operación de establecer una unión (Bind)

Para poder invocar una operación remota es necesario establecer previamente una asociación deaplicació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 asociarleargumentos, resultados y errores. Con la palabra reservada ARGUMENT se pueden definirargumentos de entrada asociados con una operación de establecer una unión. Si el establecimiento dela unión se ha resuelto con éxito, la palabra clave RESULT especifica el tipo del resultado y, en casocontrario, los errores asociados se pueden especificar mediante la palabra reservada BIND-ERROR.Estos tres últimos campos son opcionales (véase la figura 3.19).

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 utilizadopara una operación remota. La liberación de la unión se especifica mediante la macro UNBIND quetiene una sintaxis muy parecida a la macro BIND del apartado anterior. La única diferencia encuanto a sintaxis es que la palabra reservada para indicar los errores es en este caso UNBIND-ERROR (véase la figura 3.20).

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

nombre-establecer-uniónBIND



BIND-ERROR TipoErrorBind

::= identificador-establecer-unión

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

nombre-liberar-uniónUNBIND



UNBIND-ERROR TipoErrorUnbind

::= identificador-liberar-unión

Fig 3.20 Liberar una unión mediante la macro UNBIND de la notación-RO


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ándolosde un identificador único y se definen sus características particulares. Debe recordarse que elprotocolo definido entre dos ASE específicos puede ser simétrico o asimétrico. En el caso de ASEsimétricos los dos usuarios indistintamente pueden invocar todas las operaciones remotas. En el casoasimétrico es necesario indicar para cada operación quién la invoca, es decir, si es el consumidor o elproveedor 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 (SUPPLIERINVOKES). En el caso de ASE simétricos las operaciones las pueden invocar indistintamente los dosextremos y se utiliza la palabra reservada OPERATIONS para indicar la lista (véase la figura 3.21).

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 locomponen, utilizando cada uno de estos ASE sintaxis abstractas distintas.

Con la macro APPLICATION-CONTEXT se identifica de forma única un contexto de aplicaciónconcreto y se definen sus características. La composición del contexto de aplicación asociado alservicio que se está especificando, consta de la lista de ASE que lo constituyen (APPLICATION-SERVICE-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 ASEconstitutivos del contexto de aplicación (ABSTRACT SYNTAXES). Los ASE simétricos de los queconsta el contexto de aplicación se deben listar utilizando la palabra clave OPERATIONS OF. Paralos ASE asimétricos es necesario listar por separado aquéllos para los que la entidad iniciadora de laasociación es la consumidora de dichos ASE (INITIATOR CONSUMER OF) y aquéllos para los que

nombre-ase APPLICATION-SERVICE-ELEMENT

OPERATIONS {lista-operaciones} -- operaciones ase simétrico

CONSUMER INVOKES {lista-operaciones} --operaciones ase asimétrico

SUPPLIER INVOKES {lista-operaciones} -- operaciones ase asimétrico

::= identificador-ase


la entidad que responde a la iniciación de la asociación es su consumidora (RESPONDERCONSUMER OF) (véase la figura 3.22).

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 lanotación ASDC para su especificación y la notación-RO para su posterior implementación conROSE.

Usuario

Sistema demensajería

Usuario

AdministradorAdministrador

...

...

Fig 3.23 Arquitectura general del miniservicio de mensajería

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

nombre-ac APPLICATION-CONTEXT

APPLICATION-SERVICE-ELEMENT {lista-ases}

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


También existen unos usuarios especiales, que son los administradores del sistema que, además deposeer 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 ladistribución, esto es, el proceso de la aplicación distribuida que utiliza los servicios OSI paraintercambiar información con otros sistemas. Cada sistema (ordenador) involucrado en la realizacióndel 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 ASEcomunes, esto es, ACSE y ROSE (y opcionalmente RTSE), más los ASE específicos necesarios paraimplementar el nuevo servicio. La arquitectura de comunicaciones OSI puede estar presente en elkernel del sistema operativo o como un proceso de usuario. A continuación, en la figura 3.24, semuestra la estructura de la entidad de aplicación del servicio de mensajería electrónica del ejemplo.

Proceso Aplicación

Usuario

AE

UE

ASE

ACSE

ROSE

... ASE

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ónicadonde aparecen todos los objetos abstractos que lo componen y los puertos abstractos que losrelacionan ente sí. En realidad se trata de una representación gráfica de la visión macroscópica delservicio, que nos da la misma información que la especificación formal según la notación ASDC. Elentorno de mensajería electrónica tendrá un aspecto como el mostrado en la figura 3.25 en términosde objetos y puertos abstractos ASDC.


Usuario-mensajería

envíarecibe

envíarecibe prueba

registra

Sistema-mensajería

uso-mensajería

admin-mensajería

Administrador-mensajería

Entorno-mensajería

Fig. 3.25 Representación gráfica del entorno del servicio de

mensajería electrónica

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

- sistema-mensajería- usuario-mensajería- administrador-mensajería- entorno-mensajería

Estos objetos abstractos se comunican entre sí mediante puertos abstractos. Existen dos puertosabstractos distintos llamados “uso-mensajería” y “admin-mensajería”. El puerto “uso-mensajería” loutiliza un usuario para invocar las operaciones normales de utilización del sistema, y relaciona losobjetos “usuario-mensajería” y “admin-mensajería” con el objeto “sistema-mensajería”. El puertoabstracto “uso-mensajería” es asimétrico y tiene los papeles de cliente en los extremoscorrespondientes a los objetos “usuario-mensajería” y “administrador-mensajería”, y el papel deservidor en el extremo del objeto “sistema-mensajería”. El puerto abstracto “admin-mensajería” loutiliza el usuario administrador del sistema para realizar las operaciones propias de gestión, y por lotanto 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” 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 unmensaje (“Envía”) y leer un mensaje (“Recibe”). Estas operaciones las invoca siempre el usuario delservicio (“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 elusuario administrador.


A partir de la descripción gráfica se puede especificar la aplicación de mensajería electrónicautilizando 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-mensajeriaRECURRING

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 ] }


::= 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


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 lanotación ASDC, se va a implementar utilizando ROSE. Para su diseño es necesario utilizar lanotación-RO. A continuación se muestra cómo sería la especificación del servicio utilizando lanotación-RO. Se puede observar que se implementa con dos contextos de aplicación llamados “uso-mensajería-AC” y “admin-mensajería-AC”, donde cada uno de ellos consta de uno o varios ASEespecíficos. El contexto de aplicación “uso-mensajería-AC” lo utilizan los usuarios normales demensajería y contiene el ASE específico “uso-mensajería-ASE” que utiliza la sintaxis abstracta “uso-mensajería-AS”. El otro contexto de aplicación, que es “admin-mensajería-AC”, y es utilizado porlos 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” paralas operaciones de gestión (utilizando la sintaxis abstracta “admin-mensajería-AS”), y el ASE “uso-mensajerí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 -- para el usuario mensajería

APPLICATION SERVICE ELEMENTS {aCSE}


BIND BindUsoMensajeria

UNBIND UnbindMensajeria

REMOTE OPERATIONS {rOSE}

INITIATOR CONSUMER OF {uso-mensajeria-ASE}

ABSTRACT SYNTAXES {uso-mensajeria-AS, aCSE-AS}

::= id-ac-mensajeria-uso

admin-mensajeria-AC APPLICATION-CONTEXT -- para el administrador

APPLICATION SERVICE ELEMENTS {aCSE}

BIND BindAdminMensajeria

UNBIND UnbindMensajeria

REMOTE OPERATIONS {rOSE}

INITIATOR CONSUMER OF {admin-mensajeria-ASE, uso-mensajeria-ASE}

ABSTRACT SYNTAXES {admin-mensajeria-AS, aCSE-AS, uso-mensajeria-AS}

::= id-ac-mensajeria-admin

-- Elementos de servicio de 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


De la definición de un puerto se desprenden los servicios que puede suministrar dicho puerto. Dichosservicios al final serán realizados por un ASE específico, que define una sintaxis abstracta ypertenece 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 tantocon dos ASE específicos distintos que, combinados, dan lugar a dos contextos de aplicación que semuestran en la figura 3.26. Los servicios (operaciones) disponibles en cada contexto son lossiguientes:

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

UE

uso-mensajería

ROSE

ACSE

admin-mensajería

UE

uso-mensajería

ROSE

ACSE

admin-mensajería

Protocolo entre administradores ysistema-mensajería


Nivel deaplicación

Nivel depresentación

Usuario administrador de sistema-mensajería Sistema-mensajería

UE

uso-mensajería

ROSE

ACSE

Protocolo entre usuarios y

sistema-mensajería


Nivel deaplicación


Usuario desistema-mensajería Sistema-mensajería

UE

uso-mensajería

ROSE

ACSE

Fig. 3.26 Contextos de aplicación del sistema entorno de

mensajería


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 administradoresde la mensajería antes mencionados, y que se encargan de manipular los mensajes. Y el otrocomponente es el sistema de transferencia de mensajes, encargado de transferir los mensajes de unusuario 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 sucomposición. Como se puede observar en la figura 3.27, se trata de la misma arquitectura (visiónmacroscópica) que la definida anteriormente, donde aparecen nuevos objetos llamados “agentes”. Unagente es, en nuestro caso, una entidad que actúa como intermediaria entre el sistema detransferencia y los usuarios (normales o privilegiados) de la mensajería. En cualquier caso, es elproveedor de un puerto de mensajería (“uso-mensajería” o “admin-mensajería”) y el consumidor deun puerto del sistema de transferencia (“uso-transferencia” o “admin-transferencia”). También puedeverse al agente como un valor añadido, en cuanto a la funcionalidad al entorno de transferencia, quehace “visible” dicho entorno a los usuarios de la mensajería.

agente-usuario

entrega transfiere-prueba

sistema-transferencia

admin-transferencia

agente-administrador

sistema-mensajería uso-

transferencia

transfiere

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 demensajería original más los nuevos objetos que se obtienen del refinamiento del sistema demensajería. En la figura 3.28 se puede ver la representación gráfica del entorno de mensajería en laque aparece el refinamiento del sistema de mensajería descrito anteriormente.


usuario-mensajería uso-

mensajería

admin-mensajería

administrador-mensajería

entorno-mensajeria


agente-administradorsistema-

mensajería

uso-mensajería

admin-mensajería

agente-usuario

agente-usuario

Fig. 3.28 Refinamiento del entorno de mensajería

La definición ASDC del refinamiento del “sistema-mensajería” sería el siguiente:

RefinamientoSistemaMensajeria DEFINITIONS ::=

BEGIN

-- refinamiento sistema-mensajería

sistema-mensajeria-refinamientoREFINE sistema-mensajeria AS

agente-usuario RECURRING

uso-mensajeria [S] VISIBLE

uso-transferencia [C] PAIRED WITH {sistema-transferencia}

agente-administradorRECURRING

admin-mensajeria [S] VISIBLE

admin-transferencia [C] PAIRED WITH {sistema-transferencia}


::= id-ref-mensajeria-sistema

-- nuevos objetos abstractos

agente-usuario OBJECT

PORTS {

uso-mensajeria [S] ,

uso-transferencia [C] }

::= id-ot-agente-usuario

agente-administrador OBJECT

PORTS {


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 RemoteOperations - Concepts, Model and Notation" se describe un nuevo lenguaje de especificación para ladefinición de servicios abstractos y su implementación basada en la utilización del protocolo deaplicació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 conotros objetos a través de asociaciones donde se definen los contextos de esas interacciones entérminos de contratos abstractos. Se listan los contratos que soporta un objeto abstracto como entidadque inicia o responde a la asociación o ambos indistintamente. Cuando se utilizan servicios decomunicació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


La macro CONTRACT define el contexto en el que los objetos pueden interaccionar. Se incluyecomo se establece y libera la asociación y los puertos abstractos que se pueden utilizar durante la vidade la asociación. Se listan los puertos en los que la entidad que inicia la asociación adopta el papel deconsumidor, suministrador o ambos (puertos simétricos). Cuando se utilizan protocolos decomunicación OSI un contrato (CONTRACT) se realiza como un contexto de aplicación.

nombre-contract CONTRACT ::= {

CONNECTION nombre-connection-package

INITIATOR CONSUMER OF {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 elestablecimiento (Bind) y la liberación (Unbind) de la asociación. Cuando se utilizan los servicios decomunicación OSI esto se realiza utilizando los servicios de ACSE directamente o a través de RTSE.

nombre-connection-package CONNECTION-PACKAGE ::= {

BIND 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 definenmediante la macro OPERATION-PACKAGE. Para cada puerto se definen las operaciones que cadaobjeto puede invocar asumiendo el papel de consumidor, suministrador y las que pueden invocarasumiendo ambos papeles. Los puertos asimétricos son aquellos en los que cada instancia asume unpapel diferente, es decir, consumidor o suministrador. Por el contrario en un puerto simétrico ambasinstanciaciones son idénticas. Cuando se utilizan servicios de comunicación OSI un OPERATION-PACKAGE se realiza mediante un ASE específico.

nombre-puertoOPERATION-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


Las macros OPERATION y ERROR son iguales que las macros ABSTRACT-OPERATION yABSTRACT-ERROR de ROSE. De hecho se definen de la forma siguiente:

ABSTRACT-OPERATION ::= OPERATION

ABSTRACT-ERROR ::= ERROR

nombre-operaciónOPERATION ::= {



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 conel contexto de aplicación. Es decir, el contrato válido, los servicios OSI que se van a utilizar para elestablecimiento y la liberación de la asociación, la transferencia de información y las sintaxisabstractas.

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 demensajería electrónica (SME) y, especialmente en un contexto OSI, el término sistema de gestión demensajes (MHS, Message Handling System) para referirnos a la aplicación distribuida de manejo eintercambio de mensajes mediante redes de ordenadores.

Básicamente, un sistema de mensajería electrónica es un sistema de comunicación utilizado paraenviar información (mensajes) de una persona (o lugar) a otra (u otro). Esta comunicación tambiénpuede ser de una persona a muchas a la vez.

Los mensajes electrónicos pueden incluir texto, gráficos, voz, etc., dependiendo del sistemautilizado. En la mayoría de los casos se trata con texto, aunque cada vez es más habitual elintercambio de mensajes multimedia.

Los sistemas de telex y facsímil (o fax), predecesores de los SME, transmiten mensajes de un lugar aotro (punto a punto) requiriendo que las máquinas del remitente y del destinatario estén en línea a lavez, mientras que el correo electrónico no tiene este requerimiento.

El correo electrónico, como aplicación OSI, inicialmente fue normalizado por el CCITT en 1984, conla aprobación de las recomendaciones internacionales conocidas como X.400, que tienen el mérito deser la primera norma del nivel de aplicación del modelo de referencia OSI que se desarrolló. Lanormalización fue el resultado de la necesidad de interoperabilidad de los sistemas que ibanapareciendo en el mercado.


La experiencia adquirida con estas recomendaciones y las primeras implementaciones llevaron alCCITT a desarrollar una nueva versión, aprobada en 1988, que corrige muchas de las limitaciones dela versión del 84. Asimismo, la experiencia también sirvió, como se explica en el capítulo 1, paramejorar globalmente el nivel de aplicación. La versión del 88 se publicó también, aunque conpequeñas diferencias, como un estándar de ISO.

Finalmente, después de 1988 se han publicado nuevas versiones del estándar/norma que no cambiandemasiado 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ásgeneralizado de los SME, dado que está siendo realmente factible la interconexión de sistemas demensajería de todo el mundo. Todos los sistemas ya existentes, y los nuevos por desarrollar, podránconectarse 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, enparalelo con el correo X.400, se ha ido desarrollando, con mucho éxito en los últimos años, otrosistema de correo electrónico más sencillo, aunque igualmente útil, que se conoce como correoInternet.

4.2 Funcionalidad de los SME

En esta sección, se presenta la funcionalidad más habitual ofrecida por los sistemas de correoelectrónico. En principio, la funcionalidad ofrecida al usuario es independiente de la funcionalidadde los protocolos y servicios implementados. Por ello, las operaciones que se van a presentar sonposibles 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 serleí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 usuarioquiere enviar (texto por ejemplo) y parámetros del mensaje (destinatario, prioridad, etc.).

- Enviar mensaje: envía un mensaje previamente preparado. Esta operación puede estarincluida en la anterior (Componer).

- Reenviar mensaje: permite reenviar un mensaje ya recibido a otro destinatario diferente.- Contestar: para enviar respuestas a mensajes recibidos.


- 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 (odestinatarios) de un mensaje estén en línea al mismo tiempo. Esto es así debido a que los SME sebasan en la idea de almacenamiento y reenvío (store-and-forward), lo que significa que los mensajesson colocados en el sistema de mensajería cuando el remitente lo desea, independientemente deldestinatario. Después, el sistema se encarga de, paso a paso (esto es, la primera máquina que recibeel mensaje, si no es el destino final, lo almacena para ser reenviado a otra máquina, repitiéndose talproceso 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 lasrecomendaciones X.400. De cualquier forma, muchos de los conceptos son también válidos en otrossistemas propietarios y en el correo electrónico Internet.

Lo que normalmente se conoce como X.400 es un conjunto de recomendaciones relacionadas entresí. Los números de las recomendaciones y los estándares correspondientes se detallan en labibliografía anexa.

Las recomendaciones X.400 describen un servicio que permite a sus usuarios el intercambiointernacional de mensajes utilizando los servicios telemáticos existentes en cada país. El servicio quese define lo proporciona lo que se llama el sistema de gestión de mensajes (MHS, Message HandlingSystem).

Como se siguen los principios del modelo de referencia OSI, el MHS usa los servicios ofrecidos porel nivel de presentación y por elementos de servicio de aplicación (ASE) comunes. Por tanto, sepuede construir un MHS en cualquier entorno OSI.


4.3.2 La arquitectura

La arquitectura del MHS está esquematizada en la figura 4.1. Dentro del MHS, se puede encontrar elservicio 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 definirdiferentes aplicaciones para diferentes formatos de los contenidos de los mensajes. Como se verá másadelante, se estandarizó inicialmente la aplicación llamada de mensajería interpersonal. De todasformas, se puede usar el servicio del MTS para cualquier otra aplicación.

MTA

MTA

MTA

MTA

MS UA

UA

PDAU

AU

UA

UA

Usuario

Servicio de entrega física

Otros servicios telemáticos

MHS

MTS

Usuario

Usuario

Usuario

UsuarioUsuario

UsuarioUsuario

Fig 4.1 Arquitectura del MHS

El principio general de funcionamiento es que el usuario originador de un mensaje lo envía al MTSpara 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 demensajes con la técnica de almacenamiento y reenvío. Entre MTA y MTA es necesario un protocoloOSI (o, más precisamente, un contexto de aplicación), el cual se denomina P1. Tanto el usuariooriginador 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, quepueden ser de los siguientes tipos (véase la figura 4.1):


- Agente de usuario (UA, User Agent): Ayuda al usuario final (normalmente una persona) aacceder al MHS. Debe conocer el formato de los mensajes que enviará y recibirá a través delMTS. 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 usuarioa través de su agente de usuario). El MS se añadió en 1988 para permitir que la recepción demensajes sea controlada por el usuario. Cuando hay un MS, el UA accede al MTS a través deun MS (el protocolo de acceso del UA al MS se denomina P7). Si, además, el MS y el MTAestán separados, también es necesario el protocolo P3, antes mencionado, para el acceso delMS 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 decomunicación (servicios telemáticos y servicio postal). Ejemplos de AU son las unidades deacceso a servicios telemáticos más antiguos como telex o teletex; y la unidad de acceso alservicio 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 (yviceversa).

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.

MTA

MTA

MTA

MTA

MS UA

UAUA

UA

MTS

MS

envío

envío-indirecto

envío

transferencia

entrega

entregarecuperación

originador

originador destinatario

destinatario

Fig. 4.2 Modelo de funcionamiento del MHS

Lo que en la figura 4.1 se llama usuario, puede ser una persona o una aplicación en un ordenador.Un usuario en el SME puede ser originador o remitente (originator), cuando envía un mensaje, odestinatario (recipient) cuando lo recibe.


Como ya se ha mencionado, las entidades agente de usuario (UA) son las que sirven para que elusuario pueda preparar mensajes y enviarlos a otro usuario a través del sistema de transferencia demensajes (MTS). Es decir, el UA interacciona con el usuario para ayudarle a preparar los mensajes, ycon el MTS y el MS para enviarlos o recibirlos. Las funciones del UA que son locales a él no estánestandarizadas 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, oindirectamente a través de un MS.

El MTS realiza la operación de entrega (delivery) de mensajes a un UA, directamente, o bien através de un MS. En este último caso, el MS ya tuvo entrega previamente desde el MTS, y laoperación entre UA y MS es de recuperación (retrieval), e iniciada por el UA. Por tanto, el MS actúade 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 elUA originador del mensaje.

Finalmente, se puede ver en la figura 4.1 que, en el MTS, los MTA se encargan, cooperando unoscon otros, de transmitir y retransmitir (es decir, transferir) mensajes para entregarlos a sudestinatario.

4.3.4 Implementación

En el MTS, cada MTA se corresponde con una máquina, remota de cualquier otro MTA, por lo quees necesario un protocolo (P1) para comunicarse entre MTA. Normalmente, los MTA seimplementan en máquinas grandes que dan servicio a muchos usuarios, ya que deberían estardisponibles 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ánasociados. En muchos casos, se ofrece un UA a cada usuario de las máquinas grandes en las queresiden 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í hayque 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 requiereque el UA esté preparado para que le entreguen mensajes (no es el UA quien los pide), por lo quemuchas veces no es viable implementarlo desde un PC. Esta es una de las razones por las que seintrodujo 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 quiendecide cuándo se reciben los mensajes (recuérdese que el MTA entrega los mensajes al MS, quien losguarda hasta que el UA accede a él para recuperarlos). Normalmente además, cuando hay P7 el MSsuele ser local al MTA, por lo que no se implementa P3.


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

4.3.5 Estructura de un mensaje

Los mensajes que se transfieren a través del MTS tienen una estructura normalizada. Un mensaje, talcomo esquematiza la figura 4.3, está dividido, básicamente, en dos partes:

- Envoltorio o sobre (envelope): Lleva información relacionada con la transferencia delmensaje. Por tanto, esta información la usa el MTS.

- Contenido (content): Es la información que el UA originador desea entregar a losdestinatarios (véase el apartado 4.8.1).

sobre

cabecera

cuerpo

contenido

parte de cuerpo 1

parte de cuerpo 2

parte de cuerpo 3

Fig. 4.3 Estructura de un mensaje

El MTS transfiere los mensajes independientemente de lo que contienen, utilizando únicamente lainformación del sobre. Sin embargo, para que dos agentes de usario puedan intercambiarse mensajescorrectamente, deben, lógicamente, poder interpretar el contenido. Por ello, como ya se hamencionado, 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.


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 deusuarios. El MTS es el que se encarga de distribuir los mensajes, ya que la lista identifica un MTAdestino donde se conoce quiénes son los miembros de la lista que, a su vez, puede incluir otras listasanidadas.

Tanto los usuarios como las listas se identifican por lo que se llama nombre deoriginador/destinatario o nombre O/R (Originator/Recipient name u O/R name). Dos elementospueden 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 dedistribución, por medio de atributos predefinidos. Por ello, en el caso de disponer de un nombredistintivo será necesario obtener la dirección O/R para poder enviar el mensaje. Esto se consigueaccediendo al servicio de directorio (véase el capítulo 6) que, a partir de un nombre distintivo, sepuede obtener una dirección O/R. De cualquier forma, para disponer de un nombre distintivo esnecesario 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’ paraEspaña.


- 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 elcaso de las universidades españolas, todas pertenecen al PRMD ‘iris’.

- Organización (O): Un PRMD se puede estructurar en organizaciones, según su propiocriterio. En el caso de las universidades, cada universidad se considera una organización deldominio 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 deestructura (podrían ser divisiones, departamentos, secciones, grupos, etc., si existen), loscuales 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. Unejemplo 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 nombrepersonal, 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 unPRMD) decidir cómo se asignan estos nombres. Una forma habitual para identificar usuarioses 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 quedeben 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 dela 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, ManagementDomain). Un MD está formado por uno o más MTA y cero o más UA, MS y AU, utilizados por unacompañía o institución. Normalmente, un dominio de gestión estará a su vez estructurado enorganizaciones y, posiblemente, en unidades organizativas, tal como se mencionó en el apartadoanterior.

Hay dos tipos de dominios de gestión:

- de administración (ADMD)- privados (PRMD)


Los dominios de administración corresponden a las compañías (o administraciones) responsables deltransporte de datos o comunicaciones en un país. En algunos países habrá una sola posibilidad deADMD, 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 demensajería electrónica.

La figura 4.4 muestra algunas 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 deorganizar los MTA es en función de cómo se estructura el dominio. Por ejemplo, se podría decidirque cada organización dentro de un PRMD disponga de un MTA, al igual que cada unidadorganizativa, por lo que se consigue una relación entre MTA y atributos en la jerarquía de lasdirecciones 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 elservicio de correo electrónico en una organización. Las dos alternativas básicas son:

PRMD 1

MTA

MS

UAUA

ADMD 1

UA

MTA

MTA

ADMD 2

MTA

UA

UA

PRMD 2

MTA

MS

ADMD 3

UA

MTA

MTA

MSUA

MS

PRMD 3

UA

UA

UA

País BPaís A

MTA

UAUA

UA

MTA

UAUA

Fig. 4.4 Posibles relaciones entre dominios de gestión


- Implementar (o comprar el software necesario para hacerlo) un MTA y los UA y MSnecesarios 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, quenormalmente será un ADMD, aunque también podría ser un PRMD. Un ejemplo sería elservicio 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 funcionalidady de arquitectura. Se trata, evidentemente, de una aplicación distribuida, por lo que se puedeespecificar utilizando ASDC, tal como se explica en el capítulo 3. Por ello, las propiasrecomendaciones 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 lasrecomendaciones 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 seimplementa en un contexto OSI.

MTS Usuario-MTS

Envío

Entrega

Administración

MHS

Usuario-MTS

Envío

Entrega

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 objetosque acceden a él, como en la figura 4.5. Estos objetos pueden ser de varios tipos, pero los másimportantes son el UA y el MS. El número de puertos que habrá entre el MTS y sus usuarios (en estecaso, tanto el UA como el MS se pueden considerar usuario-MTS) depende de cómo se agrupen susfunciones. Por razones que quedan más claras después, se ha decidido especificar tres puertos, unopara 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


embargo, no se detallan las especificaciones ASDC para no alargar innecesariamente el texto y porser, 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 (esdecir, el UA). En este caso, se definen otra vez tres puertos, aunque no son exactamente los mismosque antes. En concreto, los puertos son de envío-indirecto (submission), recuperación (retrieval) yadministración (administration).

RecuperaciónEnvío-indirectoAdministración MSUsuario-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 puertosal exterior, como se acaba de mencionar. Entre MTA, solamente se especifica un puerto, llamado detransferencia (transfer).

MTSabstract-service

provider

EntregaEnvío

Administración

P3

MTA MTA

MTS

MTA

Transferencia Transferencia

P1 EntregaEnvíoAdministración

P3

P1

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 unelemento de servicio de aplicación (ASE) específico, y cada enlace entre objetos corresponderá conun 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


- 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 elACSE, el ROSE y el RTSE.

En las siguientes subsecciones se detalla la estructura de los diferentes protocolos o contextos deaplicació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 ASEespecí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.

UE

MSSEc

ROSE

ACSE

MDSEc MASEc

UE

MSSEs

ROSE

ACSE

MDSEs MASEsProtocolo P3


Nivel deaplicación


Usuario de MTA MTA

Fig. 4.8 Protocolo P3


Además, se necesitarán el ACSE y el ROSE. Si se desea, en algunos casos se puede utilizar uncontexto 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 alMTS 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íficosson el MSSE, el MRSE y el MASE. A diferencia del acceso al MTS, en el acceso al MS, sólo elusuario puede establecer una asociación.

El protocolo de acceso al MS se conoce como P7. Asímismo, son además necesarios el ACSE, elROSE y, opcionalmente, el RTSE.

En la figura 4.9 se pueden ver las entidades de aplicación necesarias para el protocolo P7.

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 apuertos 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.

UE

MSSEc

ROSE

ACSE

MRSEc MASEc

UE

MSSEs

ROSE

ACSE

MRSEs MASEsProtocolo P7


Nivel deaplicación


Usuario de MS MS



4.5.3 Servicios

Hasta ahora, sólo se ha visto la visión macroscópica de la especificación en ASDC del sistema demensajería. Para completar la especificación, es necesario añadir la visión microscópica, es decir, lasoperaciones que se realizan a través de cada puerto.

En lugar de mostrar estas operaciones como una visión microscópica ASDC, las operaciones sedetallan 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óndeterminada sobre el servicio de transferencia de mensajes. Por tanto, el contenido de la informacióntransferida 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 no-entrega. Es decir, indicar al UA (o usuario del MTS en general) originador del mensaje si éste hasido entregado a sus destinatarios o no. Esto se detalla en la figura 4.11.

UE

MTSE

ACSE

RTSE

UE

MTSE

ACSE

RTSE

Protocolo P1


Nivel deaplicación


MTA MTA



En cuanto al servicio, aparte de las operaciones habituales en todo contexto de aplicación, como elestablecimiento y la liberación de una unión (MTS-Bind y MTS-Unbind), el MTS ofrece lassiguientes operaciones, agrupadas por puertos:

- Operaciones abstractas del puerto de envío:

- Envío de mensaje: Es la operación habitual para enviar un mensaje.- Envío de sonda (probe): Para comprobar si un mensaje podrá ser enviado.- Cancelación de entrega diferida: Para cancelar una orden previa de entregar un mensaje de

forma diferida.- Control de envío: Para operaciones de control.

- Operaciones abstractas del puerto de entrega:

- Entrega de mensaje: Es la operación habitual para entregar un mensaje.- Entrega de informe (report): Para entregar un informe de cómo ha ido la transferencia de

un mensaje.- Control de entrega: Para operaciones de control.

- Operaciones abstractas del puerto de administración:

- Registrar: Para operaciones de registro.- Cambiar credenciales: Para cambio de credenciales.

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 nuevopuerto (transferencia).

MTA

Usuario-MTS

MTA

MTA

MTA

Usuario-MTS

Usuario-MTS

Entrega-mensaje

Transferencia-informe

Tranferencia-mensaje

Envío-mensaje

Entrega-informe(no-entrega)

(no-entrega)

MTS Destinatarios

Originador

Fig. 4.11 Notificaciones en el MTS


Las operaciones del puerto de transferencia son:

- transferencia de mensaje- transferencia de sonda- transferencia de informe

4.7 Almacén de mensajes

Las recomendaciones X.400 definen el servicio abstracto del MS, la estructura de la información aalmacenar y los procedimientos de realización.

La figura 4.12 presenta los puertos del MS que define la norma.

El objeto almacén de mensajes (MS) consta de seis puertos: recuperación (retrieval) y envío-indirecto (indirect-submission) entre UA y MS, entrega (delivery) y envío (submission) entre MS yMTS, 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ío-indirecto y administración). El único puerto totalmente nuevo es el de recuperación (envío-indirectoes 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 elalmacén, como por ejemplo cuántos mensajes hay por leer.

- Enumerar (List): Para obtener una lista de mensajes con algunos de sus atributos. La lista demensajes, al igual que en la operación anterior, se selecciona utilizando una interrogaciónbasada en valores de atributos, como originador, tema, etc.

RecuperaciónEnvío-indirectoAdministración

EntregaEnvíoAdministraciónMSUA MTS

P3P7

Figura 4.12 El MS y sus puertos


- Leer (Fetch): Para obtener uno o más mensajes enteros seleccionados. Los mensajes se copiandel 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 elalmacén.

- Alertar (Alert). Para alertar de la llegada al almacén de mensajes nuevos. Esta últimaoperación, cuando está disponible, es invocada por el MS, a diferencia de las restantes que soninvocadas 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 unUA (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 queforman la descripción del mensaje. Estos atributos son, o bien información especial dealmacenamiento, o bien información seleccionada a partir de la ya existente en los mensajespropiamente 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 laentrada y salida de correo hacia y desde un MS asociado a un agente de usuario.


El diario de entrada (inlog) guarda información sobre los mensajes que han llegado a undeterminado 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 mensajesentregados al MS (diario de entrada) y enviados por el usuario (diario de salida), aparte de otrosatributos 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 usuariosdel 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 unusuario comunicarse con otro usuario por medio de una clase específica de UA cooperantes, llamadosagentes de usuario interpersonales (IP-UA). Como el IPMS utiliza el servicio de transferencia demensajes, es una aplicación concreta (un formato concreto de mensajes) sobre el MTS. Aunqueexisten actualmente otros formatos estandarizados, éste es el primero que se normalizó (a la vez queel 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 constade (véase la figura 4.3 anterior):

- cabecera (heading): información asociada al mensaje


- 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 hallamado mensajería interpersonal, especificando el tipo de contenido de los mensajes y losprocedimientos de funcionamiento asociados. Todo ello se conoce como protocolo P2, aunque es másun formato que un protocolo.

El contenido de un mensaje interpersonal (IPM) está compuesto por una cabecera y una o variaspartes de cuerpo. Lo primero es la información de control que caracteriza al mensaje y lo segundo lainformación que se desea comunicar. El cuerpo de un IPM puede contener texto, voz, facsímil, etc., ouna combinación de todos o algunos de ellos.

Los componentes de la cabecera de un IPM son atributos con información para caracterizar elmensaje. No todos ellos tienen que estar presentes en todos los mensajes. Los atributos másimportantes son:

- Identificador de IPM: Para identificar de forma única (usando la dirección O/R del originadordel 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 eloriginador.

- 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. Lacopia es exactamente igual al mensaje, pero el originador indica con este atributo que elmensaje no está dirigido principalmente a esa o esas direcciones.

- Destinatarios de copia ciega: Direcciones O/R de destinatarios ocultados a los demás. Esdecir, los destinatarios principales y de copia no conocen los destinatarios de copia ciega.

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

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

- IPM relacionados: Identificadores de mensaje o mensajes relacionados con éste. La relación ladecide 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.


- Hora de respuesta: Día y hora antes de la cual el originador solicita una respuesta al contenidodel mensaje.

- Destinatarios de respuesta: Direcciones O/R de quien o quienes quiere el originador quereciban 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 lacompañía) que el originador da al mensaje.

- Auto-reenviado: Para indicar si el mensaje es reenviado automáticamente por el sistema decorreo 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 estasposibilidades están totalmente detalladas en las recomendaciones. Asimismo, una parte de cuerpopuede 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, queserá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 estaespecificació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. Esterefinamiento sirve únicamente para especificar formalmente las operaciones propias del IPMS.


IPMS Usuario

Origen

Recepción

Gestión

IPME

Usuario

Origen

Recepción

Gestión

Las operaciones abstractas de cada uno de los puertos son:

- operaciones abstractas del puerto origen:

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

- operaciones abstractas del puerto 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 tanimportantes como la seguridad, son las que se implementan actualmente. Sin embargo, el esfuerzo deestandarización está continuando, habiéndose publicado últimamente nuevas versiones y extensionesque tratan de mejorar algunas deficiencias y añadir más capacidades, por ejemplo en el tema degestión de la mensajería o en nuevos agentes de usuario.

Fig. 4.13 Entorno IPMS


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, eindependiente de los subsistemas de transmisión. Debido a esta característica, este servicio sólonecesita un canal fiable de datos entre los sistemas de mensajería, con lo que puede ser cubierto pordiferentes tipos de redes.

Para el correo Internet, al igual que en el caso de MHS, es necesario definir el modelo funcional delsistema, los servicios que proporciona y su protocolo. Estas especificaciones funcionales y de serviciose hallan en los dos estándares siguientes:

- SMTP (Simple Mail Transfer Protocol) o RFC 821: Especifica el protocolo por el cual unsistema de mensajería actuando como emisor puede intercambiar mensajes con otro sistemade mensajería que actúa de receptor. En este estándar se especifican, además del protocolo, elmodelo funcional del sistema y los servicios proporcionados por el mismo. SMTP se describeen el documento RFC 821 [RFC821].

- RFC 822 (Standard for the format of ARPA Internet text messages): Especifica el formato delos documentos que pueden ser enviados utilizando el protocolo SMTP. Este formato sedescribe 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 deInternet, e independiente de los subsistemas particulares de transmisión. Es un protocolo muysimple, en el cual la comunicación entre el cliente y el servidor se realiza a través de comandos detexto 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, lacomunicación entre el emisor y el receptor siempre es un diálogo alternativo controlado por elemisor. Esto es, cuando el emisor invoca un comando, antes de invocar otro comando siempre debeesperar 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 unagente 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


SMTP, que son enviados hacia el receptor SMTP. A su vez, las respuestas a estos comandos sonenviadas del receptor SMTP hacia el emisor SMTP. Una vez los mensajes llegan al receptor SMTPde la máquina donde se encuentra el destinatario, el mensaje es introducido dentro del buzón deusuario correspondiente.

Cabe reseñar que el receptor SMTP tanto puede ser el destino final como un destino intermedio máscercano al destino final, tal y como se puede ver en la figura 4.15. En el caso en el cual el sistemareceptor es un destino intermedio, el mensaje recibido es introducido de nuevo en la cola de correo desalida de la misma máquina, para ser enviado a otro receptor.

Mensajes en la cola

Agentede usuario

Emisor SMTP

Cola correode salida

Buzonesde usuarios

ReceptorSMTP

ReceptorSMTP

Mensajes en la cola

Emisor SMTP


Sistema emisor Sistema intermedio Sistema receptor

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á unadirección electrónica de la forma: usuario@nombre_dominio. La segunda parte de la direcciónelectró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 laparte de la dirección que se halla a la derecha del signo @ (esto es, nombre_dominio). El procesoemisor SMTP utiliza el DNS para obtener la dirección física (IP) de la máquina destino. Una vez en

Mensajes en la cola

Agentede usuario

Emisor SMTP


Buzonesde usuarios

ReceptorSMTP

Conexión TCP

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


esta máquina, el mensaje es entregado al usuario identificado por la parte de la dirección que se hallaa la izquierda del signo @ (esto es, usuario).

Por último, se debe mencionar que el proceso emisor SMTP no siempre puede establecer unaconexión directa con el proceso receptor. Generalmente, a nivel de dominio siempre se dispone deuna máquina servidora de correo que es la encargada de centralizar los procesos de transmisión yrecepció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 puedenser intercambiados entre el emisor SMTP y el receptor SMTP. Estos comandos son cadenas decaracteres 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ódigode comando y en algunos casos un parámetro. El parámetro se separa del código mediante un espacioen 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, defineun mensaje como una serie de campos de cabecera y, opcionalmente, un cuerpo separado de loscampos de cabecera por la primera línea en blanco del mensaje.

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


empieza con un carácter de espacio en blanco, en cuyo caso esa línea es continuación de laanterior.

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íoFrom : originadorTo : destinatarioSubject : temaSender : emisorCc : destinatario de la copiaMessage-id : identificador del mensajeReply-to : destinatario de la respuestaIn-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 EDTFrom: [email protected]: Aquí el tema sobre el que va el mensajeTo: [email protected]: <some.string@SHOST>

Antes de la primera linea en blanco aparecen loscampos de cabecera. A partir de la primera linea enblanco empieza el cuerpo del mensaje.

Existen unos dispositivos de interconexión llamados pasarelas de correo que permiten a usuarios desistemas de mensajería X.400 intercambiar mensajes con usuarios de correo Internet. Paraconseguirlo, las pasarelas de correo deben realizar un proceso de transformación entre los dosformatos de mensajes que no siempre se puede realizar conservando toda la información que figuraen el formato original del mensaje. Como el formato de un mensaje X.400 es más complejo que el deun mensaje RFC-822, será en el caso de que un usuario de X.400 desee enviar un mensaje a unusuario 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:


- 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 transferenciaSMTP) y RFC 822 (formato del mensaje) ven el cuerpo de un mensaje como un texto US-ASCII, loque limita mucho las posibilidades de dichos sistemas de correo. La comunidad Internet, conscientedel 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 MailExtensions). MIME mantiene la compatibilidad con los sistemas de correo Internet antiguos basadosen los estándares [RFC821] y [RFC822].

Los usuarios de correo MIME pueden, por una parte, enriquecer el juego de caracteres de losmensajes de texto que se intercambian y, por otra, incluir en sus mensajes informacióncorrespondiente a gráficos, voz, vídeo, etc. Los mensajes MIME pueden ser estructurados, es decir, sepueden generar mensajes con diferentes tipos de información, como texto, gráficos, tablas, etc. Estoes posible gracias al concepto de partes de cuerpo de un mensaje que se introduce por primera vez enlos sistemas de correo Internet. Como se ha descrito en el apartado 4.8 de este capítulo, la primeraversión de los sistemas de correo OSI (X.400-84) ya contempla la posibilidad de utilizar diferentestipos de contenido en un mensaje, así como estructurar el cuerpo de un mensaje en partes, cada unade ellas con un tipo de contenido diferente.

Ya se han mencionado algunas de las limitaciones del correo Internet basados en RFC 821 y 822como son los mensajes monocuerpo de texto US-ASCII o la transferencia a siete bits, pero existe otroinconveniente que es la longitud de las líneas de un mensaje, que está limitada a mil caracteres. Este


problema también se resuelve en MIME gracias al proceso de codificación/decodificación para latransferencia de mensajes (véase el apartado 4.11.2) .

Para que un usuario de correo electrónico pueda enviar y leer mensajes multimedia de formatransparente 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 puedenintercambiar mensajes utilizando el protocolo SMTP extendido para transferir información de ochobits (RFC 1426, SMTP Service Extension for 8bit-MIME Transport). Actualmente esta opción esmuy poco utilizada debido a que los sistemas de correo MIME están poco extendidos y lo normal esque los usuarios de MIME deban intercambiar mensajes con usuarios de SMTP que utilizan unprotocolo de transferencia de siete bits. Esta es la razón por la que los sistemas MIME actualmentesoportan los dos tipos de protocolos de transferencia, garantizando de esta forma una graninteroperatividad entre la comunidad de usuarios de correo Internet (véase la figura 4.16).

Codificación 8 bits a 7 bits

ContenidomensajeMIME

SMTP 8 bits(RFC 1426)

SMTP 7 bits(RFC 821/822)

UsuarioMIME

Usuario

Agente de usuario MIME

ContenidomensajeMIME

Decodificación 7 bits a 8 bits

Internet

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 transfierautilizando el protocolo SMTP (que es un protocolo basado en un código de 7 bits) es necesarioutilizar algún método de codificación que permita transportar octetos sobre septetos. Además, esnecesario que estos procesos de codificación/decodificación sean normalizados, ya que es la únicamanera de garantizar tanto la compatibilidad entre los diferentes sistemas de correo como lautilizació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 decodificación a aplicar a los mensajes en función del tipo de información que contengan. El tipo de


codificación se indica en un campo opcional de la cabecera del mensaje llamado “codificación detransferencia de contenido” (Content-transfer-encoding) que tiene el siguiente formato:

Content-transfer-encoding: tipo de codificación

Los valores permitidos para el tipo de codificación son:

- ‘7bit’, ‘8bit’ y ‘binary’- ‘quoted-printable’- ‘base64’

En realidad, los tipos de codificación ‘7bit’, ‘8bit’ y ‘binary’ no aplican ningún tipo de codificación.Los dos primeros corresponden a mensajes de texto codificados respectivamente en ASCII de 7 bits y8 bits, pero con longitudes de línea compatibles con SMTP. En el caso de utilizar el tipo decodificació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 compatiblecon SMTP.

El tipo de codificación ‘quoted-printable’ se puede considerar una semicodificación o codificaciónblanda, en el sentido de que únicamente se codifican los caracteres no US-ASCII. Estos caracteres secodifican con la secuencia formada por un carácter de escape (ESC) más un carácter del códigooriginal US-ASCII. El resultado de este tipo de codificación para un usuario de correo SMTP es queobtiene un mensaje bastante legible.

Finalmente, el tipo ‘base64’ consiste en aplicar una codificación para pasar de un mensaje quecontiene 8 bits de información a otro que se pueda transportar con siete bits. En concreto consiste enconvertir cada 3 octetos de 8 bits de información (24 bits de información) en 4 octetos con 6 bits deinformación cada uno (contienen también 24 bits de información). Este tipo de codificación expandela información a transmitir un 33%. A cada uno de los 6 bits obtenidos se le asocia el carácterequivalente utilizando un juego de caracteres de 6 bits (caracteres A-Z, a-z, 0-9, +, /). Si faltanoctetos 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 ilegible.

Por ejemplo, al aplicar el tipo de codificación ‘base64’ a la secuencia de octetos ‘ABC’ (US-ASCII65, 66 y 67), se convierte en la secuencia ‘QUJD’ (que en un código de 64 caracteres corresponde a16, 20, 9 y 3).

4.11.3 Tipos de contenido de los mensajes

Para garantizar la compatibilidad entre los diferentes formatos existentes para representar cada tipode 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 formatosconcretos.


Para indicar el tipo de contenido de un mensaje, MIME utiliza un nuevo campo de la cabecera coninformación referente al contenido. Este campo llamado “tipo de contenido” (Content-type) tiene elsiguiente formato:

Content-type: tipo / subtipo [;parámetro]

La siguiente tabla incluye los tipos, subtipos y parámetros normalizados en el primer estándar deMIME.

Tabla 4.1 Tipos de contenido de un mensaje MIME

Tipo Subtipo Parámetros

text text

richtext

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

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

image gif

jpeg

audio basic

video mpeg

h261

multipart mixed

alternativeparalleldigest

boundary

boundaryboundaryboundary

message rfc822

partialexternal-body

application octet-stream

PostScriptODA

Por ejemplo, un mensaje MIME de texto que utiliza el conjunto de caracteres ISO-8859-1, válidopara la mayor parte de las lenguas de Europa occidental, dispone de un campo en la cabecera delmensaje que indica el tipo de contenido cuyo valor es el siguiente:

Content-type: text/plain; charset=ISO-8859-1

El tipo de contenido por defecto corresponde a un mensaje RFC 822. Existen otros camposopcionales que se pueden utilizar en la cabecera de un mensaje MIME para indicar informaciónadicional 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 informacióndescriptiva a un cuerpo de mensaje. El formato es el siguiente:


Content-description: descripción

El campo de “identificador del contenido” sirve para dotar a cada una de las partes del cuerpo de unmensaje 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. Elformato es el siguiente:

Content-length:longitud

5 Arquitectura de documentos 107

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 intercambiardocumentos. Por ejemplo, el correo electrónico es uno de estos medios de comunicación (véase elcapítulo 4). Sin embargo, el contenido de la información que se transmite no tiene por qué estarestructurado como un documento.

Formato estándarde intercambio

Formato local CFormato local A

Formato local DFormato local B

Fig. 5.1 Arquitectura general para el intercambio de documentos


Asimismo, el fax, tan ampliamente extendido hoy en día, también es un sistema de comunicaciónelectró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, probablementeno 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, serequiere un formato de intercambio estandarizado. Si se dispone de dicho formato, cada sistema degestión y procesado de documentos sólo tiene que preocuparse de conocer el formato estándar, con loque los usuarios pueden seguir trabajando independientemente del estándar. Esto se ve gráficamenteen la figura 5.1.

En los últimos años, se ha realizando un gran trabajo de normalización en este campo. Lo primeroque 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 llevaasociado un formato de intercambio de documentos (ODIF, Open Document Interchange Format), elcual 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 yextensiones de la norma, republicada en 1994. Posteriormente, se están realizando nuevasextensiones, 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 dedocumentos como ODA. Se pueden enumerar algunos de ellos:

- Resuelve el problema de equipos de suministradores diferentes, permitiendo la integración deinformación procesable generada en sistemas diferentes.

- Protege inversiones ya realizadas en equipo de automatización de oficinas. Esto se realizamediante la utilización de convertidores y la sustitución gradual de los sistemas de procesadoy gestión de documentos.

- Facilita la transferencia de documentos. Con ODA no hay pérdida de información en cadatransferencia. 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ánacceder sistemas presentes y futuros.

- Facilita la “búsqueda” de documentos, pues en un documento ODA se incluye información degestión y estructura, aparte del contenido.


- Posibilita el control del uso del documento, puesto que se definen documentos procesables,formateados y formateado-procesables. Asimismo, se pueden definir mecanismos de seguridadbasados 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 losestilos 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 yhan 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 suprimera 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 incluyecuatro conceptos básicos, como son la estructura (véase apartado 5.3.2), el perfil (véase apartado5.3.4), el formato de intercambio (véase apartado 5.5) y las arquitecturas de contenido (véaseapartado 5.3.3).

Después de 1989 se ha seguido trabajando en mejorar diversos aspectos (fruto, entre otras cosas, deldesarrollo de prototipos que validan los conceptos ODA), que han llevado a una republicación de las7 partes en 1994.

Además, se han desarrollado, o se están desarrollado, otras nuevas partes que tratan otros tantosnuevos conceptos. Estas son:

- Parte 10: Especificación formal de ODA (la primera versión se publicó en 1991, y unasegunda ha sido publicada en 1995).

- Parte 3: Interfaz abstracto para la manipulación de documentos ODA (publicada en 1995). Setrata con más detalle en el capítulo 7, pues tiene mucho que ver con acceso remoto adocumentos.


- Parte 9: Arquitectura de contenido de audio (publicada en 1995). Especifica cómo poderincluir información audio en documentos ODA.

- Parte 11: Estructuras tabulares y layout de tablas (publicada en 1995). Especificacaracterísticas complejas para tablas.

- Parte 12: Identificación de fragmentos de documento (publicada en 1995). Al igual que laparte 3, se explica en el capítulo 7.

- Parte 14: Relaciones temporales y estructuras no lineales (a publicar en 1996). Trata laposibilidad 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 entresistemas de procesado de documentos heterogéneos. Permite especificar documentos procesables (esdecir, 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 estambié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. Losatributos de un constituyente representan propiedades de ese constituyente o una relación con otrosconstituyentes. El estándar enumera qué atributos se pueden especificar para cada tipo deconstituyente 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éaseapartados 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; esdecir, páginas, áreas en páginas, márgenes, separaciones, etc.


El modelo de arquitectura de ODA se basa en un enfoque declarativo, es decir, las estructuras (seanlógicas o físicas) no se expresan implícitamente por medio de caracteres de control dentro delcontenido 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 relacionesjerárquicas entre componentes, también existen relaciones no jerárquicas, como referencias a notas apie de página, por ejemplo. Finalmente, se pueden expresar por medio de atributos otras muchascaracterí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 unajerarquía de componentes. Estos componentes pueden ser objetos o clases de objeto. Los objetospueden 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 compuestoso 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). Tieneasociadas 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 undocumento.

- Marco (frame): Área rectangular de una página. Su contenido se puede formatear, lo queproduce 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 determinadaclase de objeto. Un documento puede contener cualquier número de clases de objetos lógicos y/ofísicos, que forman su estructura genérica.


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 unareferencia para crear nuevos objetos. Las porciones de contenido (véase apartado 5.3.3) se puedenasociar también con clases de objetos básicos (por ejemplo, contenido a imprimir al principio de cadapágina, como un logotipo).

La estructura real (lógica o física) de un documento concreto se llama estructura específica y constade 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, queconstan, 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 seutilizan para dar determinadas características a los objetos con los que están asociados. Para ello, losestilos 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 elproceso 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. Susatributos guían la apariencia del contenido en el medio de presentación; es decir, describenobjetos 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á asociadodirectamente 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 contenidodefinidas 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 aambos. En el último caso, pertenece a la vez a la estructura específica lógica y a la estructuraespecífica de layout. La figura 5.2 muestra la estructura específica de un documento formateado-procesable muy simple, que consta de una portada y un cuerpo con 3 párrafos. El segundo párrafo seimprime 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 noforman parte de las estructuras de documento, sino que la arquitectura de documento proporciona uninterfaz uniforme entre la estructura y el contenido (los contenidos están asociados solamente a los


objetos básicos de la estructura). Por ahora, en ODA se han definido las siguientes arquitecturas decontenido:

- Caracteres (character content architecture). La información de contenido se representa comouna cadena de caracteres combinando caracteres gráficos, el carácter “espacio” y funciones decontrol. 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 primeraversión de ODA sólo se consideraron gráficos en blanco y negro, pero en la de 1994 ya existela posibilidad de intercambiar gráficos en color. La codificación de puntos sigue losestá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 porel estándar CGM (Computer Graphics Metafile).

- Audio (audio content architecture). Publicada en 1995, especifica cómo usar, dentro dedocumentos, los diferentes formatos de codificación de audio.

contenido contenido contenidocontenidocontenidocontenido

bloque bloque bloque bloque bloque bloque

página versopágina rectopágina frontal

page setdel cuerpo

page setde cabecera

autortítulo párrafo párrafo párrafo

cuerpocabecera

raíz lógica

estructura lógica

estructura de layout

raíz de layout

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


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

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

Clases de objetos lógicos

Porciones contenido

Estructura lógica genérica

Clases de objetos de

layoutPorciones contenido

Estructura de layout genérica

Objetos lógicos

Estructura lógica específica

Objetos de layout

Porciones contenido

Estructura de layout específica

Porciones contenido

Estilos de layout

Estilos de presentación

Perfil de documento

Fig. 5.3 Constituyentes de un documento ODA


- 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áncontenidos en un constituyente llamado perfil de documento. Es decir, el perfil de documento es unconjunto de atributos que especifican las características de un documento visto como algo compacto eindependiente. 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óncomo “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 seenvió. Básicamente, lo que se transmite es la estructura específica de layout y el contenidoformateado.

- Procesable: Permite que el receptor pueda procesar el documento recibido. En este caso, setransmite la estructura lógica y el contenido procesable. También podría transmitirse ladefinición de clase de documento. Por tanto, para reproducir el documento, deberá generarsepreviamente el layout.

- Formateado-procesable: Ahora se transmiten todos los componentes de un documento, lo quepermitirá su procesado y reproducción.

El modelo de procesado de documentos ODA define tres diferentes procesos que se pueden realizarsobre 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 unaestructura lógica, y el formateado del contenido.

- Materialización (imaging): Materialización o visualización del documento en un medio depresentación (papel, pantalla, ...). Utiliza los estilos de presentación y la estructura de layoutespecífica.


Documento formateado

Documento procesable

Documento formateado procesable

Proceso de edición

Proceso de layout

Proceso de materialización

Proceso de layoutProceso de edició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), esdecir, la manera en que se ha de generar una cadena de bits para que exprese la información de ladescripción de un documento de acuerdo con ODA.

ODIF es un conjunto de definiciones ASN.1 correspondientes a todos los constituyentes ODA, deacuerdo con las reglas ASN.1 de ISO 8824. Se utiliza la sintaxis de transferencia de ISO 8825 paracodificar y decodificar estructuras de datos, siguiendo las definiciones de ODIF, en y desde unasecuencia 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 todaslas características del estándar. Para simplificar las aplicaciones ODA, se define el concepto de perfilde aplicación de documento (DAP, Document Application Profile), que es la especificación de unsubconjunto de las características disponibles en el estándar ODA, adecuadas para un conjunto deaplicaciones determinado.

Los tres perfiles aprobados para aplicaciones de procesado e intercambio de documentos sonFOD011, FOD026 y FOD036. Estos perfiles están definidos de forma jerárquica, de los cuales


FOD011 es el perfil de menor funcionalidad y FOD036 el de mayor funcionalidad. Además, existendos perfiles para aplicaciones de procesado e intercambio de imágenes de gran formato. Estosperfiles son el FOD112 y el FOD126.

Por lo dicho anteriormente sobre compatibilidad, un documento que es conforme a uno de estos DAPlo 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 devista 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 losDAP son estándares funcionales de ODA.

De cualquier forma, los DAP definidos por los diferentes organismos han convergido en una serie deDAP internacionales. A través de PAGODA (Profile Alignment Group for ODA), un grupo formadopor todos los workshops continentales, se han definido lo que se llaman ISP (InternationalStandardized Profiles), que han sido adoptados y aprobados por ISO en 1992. Estos ISP contienen losDAP 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 perfilsoporta documentos tipo carta o informe, generados con sistemas básicos: documentos conestructuras 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 soportadocumentos generados con procesadores de texto: documentos con estructuras lógica y de layout máscomplejas, y con contenido de caracteres y gráficos. Este es el perfil más utilizado actualmente. Elperfil FOD026 permite:

- Todas las características del perfil FOD011- Multicolumnas periodísticas y sincronizadas- Notas al pie de página


- 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 soportadocumentos, generados con sistemas de edición de publicaciones (Desktop publishing): documentoscon estructuras lógica y de layout aún más complejas, y con contenido de caracteres y gráficos. Elperfil 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. Elperfil FOD126 permite:

- Todas las características del perfil FOD112- Imágenes raster, imágenes vectoriales, y caracteres- Anotaciones como revisión a un original


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 utilizabanel marcaje (markup) manual de los manuscritos con una serie de instrucciones específicas, tal comose 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.

2 cm

2 cm2,5 cm

2,5 cmnegrita/20 pt.

cursiva

2,5 cm

4 cm 8 cm

4 cm

subrayado

Fig. 5.5 Documento con marcaje manual

Los primeros sistemas computerizados utilizaron esta idea de añadir marcaje (markup) específico alos manuscritos electrónicos. Este marcaje ya consistía en instrucciones de procesado, y que tambiénse hallaban separadas del documento en sí, pero en el formato específico del lenguaje del programautilizado 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:


- SGML describe la estructura de un documento así como atributos de formateado, pero noespecifica el procesado concreto a realizar sobre el mismo.

- SGML es riguroso, es decir, cada tipo de documento puede ser definido de manera formal, yde modo que las técnicas informáticas también puedan ser utilizadas para el procesado de losdocumentos.

SGML es un lenguaje, en el sentido de un lenguaje informático, para la descripción de la estructurade documentos electrónicos y su codificación mediante caracteres ASCII. SGML utiliza marcajegeneral, independiente del sistema, entorno o aplicación, para la descripción de la estructura de undocumento.

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 sonlos 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íficade 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 desalida 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ógicaespecífica en forma de árbol a partir de un nodo principal, el cual da forma al documento. En losextremos del árbol, se encuentra el contenido, que puede ser de cualquier tipo, incluso sinrepresentació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 todala información dentro del documento.

5.7.3 Marcaje

A un documento SGML es necesario:

- Dotarlo de una estructura lógica.


- 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 delsistema, entorno o aplicación. Esta información se introduce mediante el marcaje, con lo se puededecir 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<tag_inicio>, al inicio y un marcador final (end-tag), de la forma </tag_final>, al final, los cualesdefinen las características de la parte del documento SGML que se encuentra entre ambosmarcadores.

5.7.4 Estructura

Dentro de un documento, el marcaje describe su estructura específica y los atributos para suformateado, pero no el proceso a aplicar sobre él. Debido a esto, para cada tipo de documento se debedefinir de manera formal el modelo que tiene que seguir su estructura lógica. Una vez definido elmodelo, éste puede ser utilizado para validar de forma rigurosa la estructura específica de undocumento.

Para cada tipo de documento SGML, las reglas que definen las estructuras permitidas en undocumento 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 elpunto de vista lógico. Es decir, un DTD especifica la estructura lógica genérica. Todo documentoSGML tiene asociado un DTD, el cual define qué elementos lógicos pueden o deben encontrarse, enqué 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 cadatipo de documento a utilizar.

5.7.5 Estilos

Para cada tipo de documento SGML, las reglas para el formateado del contenido también se puedendefinir 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 danuna apariencia visual al documento, como pueden ser los fuentes, los espaciados de línea, losmárgenes, etc. Cualquier documento puede tener asociado una especificación FOSI, la cual definequé estilos pueden encontrarse, sus características, y cuáles son los marcadores a utilizar.


5.7.6 Contenido

Todo documento, y por lo tanto también un documento SGML, tiene un contenido. En un documentoSGML, tal y como se ha descrito anteriormente, a este contenido se le puede asociar una serie decaracterí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 unasreglas que vienen fijadas asociando un DTD y, opcionalmente, una especificación FOSI a cadadocumento SGML.

Debido a esto, el contenido de un documento SGML puede ser de cualquier tipo, y la únicarestricción que existe es la que le fije su DTD asociado. Lo mismo sucede con los atributos deformateado, que pueden ser de cualquier tipo, pero que en un documento SGML vienen restringidospor 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 undocumento utilizando SGML:

...

<times_9><para>

<paratitle><times_12><bold>Título de la sección</bold></times_12><paratitle>

<parabody>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 <bold>negrita</bold>,

<italics>cursiva</italics> o <uline>subrayado</uline> utilizando marcadores iniciales y finales.

</parabody></para><para><parabody>

Este es otro párrafo.

</parabody></para></times_9>

...

En este fragmento de documento SGML se puede apreciar el contenido, así como la existencia yformato de los marcadores iniciales y los marcadores finales, todos ellos en texto US-ASCII. A suvez, también se ve que existen dos tipos diferenciados de marcadores:

- Los que forman la estructura del documento: ‘paratitle’, ‘parabody’ y ‘para’. El significadoló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 ciertascaracterí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:


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.

merged (9)

Documents