Merged

1 Introduccin
15
1 Introduccin
1.1 Aplicaciones distribuidas abiertas?
Las tres palabras que forman el ttulo de este libro pueden tener, si se toman aisladamente,
significados muy variados. Sin embargo, aqu se agrupan con un objetivo muy concreto. Cuando se
habla de aplicaciones distribuidas, se estn considerando aplicaciones que se ejecutan en mquinas
separadas fsicamente. Estas mquinas, dos o ms, cooperan para alcanzar objetivos determinados.
El intercambio de mensajes (o correo electrnico), la transferencia de ficheros, la manipulacin
remota de documentos, la gestin de informacin remota, etc, son simples ejemplos de aplicaciones
distribuidas.
Cuando al conjunto de palabras aplicaciones distribuidas le aadimos el adjetivo abiertas,
estamos resaltando un aspecto importante de stas, la interconectabilidad de sistemas heterogneos.
Una aplicacin distribuida es abierta cuando sigue unas reglas estandarizadas (o normalizadas), que
son pblicas, que especifican qu servicio va a dar la aplicacin y qu protocolo va a seguir para dar
dicho servicio. Por supuesto, esto no tiene que restringir la implementacin de la aplicacin, sino
que, al contrario, sirve para que implementaciones independientes en sistemas diferentes se puedan
interconectar gracias a que siguen las reglas definidas en los estndares.
Por tanto, este libro describe aplicaciones distribuidas abiertas para intercambiar mensajes, transferir
ficheros y documentos, manipular documentos y almacenes de documentos remotamente, acceder a
informacin sobre mquinas y usuarios, etc.
los autores, 1998; Edicions UPC, 1998. Quedan rigurosamente prohibidas, sin la autorizacin escrita de los titulares del "copyright", bajo las sanciones
establecidas en las leyes, la reproduccin total o parcial de esta obra por cualquier medio o procedimiento, comprendidos la reprografa y el tratamiento
informtico, y la distribucin de ejemplares de ella mediante alquiler o prstamo pblicos, as como la exportacin e importacin de ejemplares para su
distribucin y venta fuera del mbito de la Unin Europea.
16
Aplicaciones distribuidas abiertas
1.2 OSI e Internet

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

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

En cuanto al proceso de estandarizacin en Internet, y como caractersticas ms importantes, hay que
mencionar que existen muchos menos organismos en el proceso de estandarizacin, y que adems
este tiene un fuerte carcter prctico.
1 Introduccin
19
La mejor definicin de lo que es un estndar de Internet (IS, Internet Standard) se encuentra en el

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

prctica y existen implementaciones interoperables. Esto no es as en el caso de ISO y ITU-T,
con lo cual es posible tener estndares que nunca se han implementado. Adems, en Internet
no existen perfiles, ya que todo lo que se estandariza debe estar implementado.
Todos los documentos (Internet Drafts, RFC, Internet Standards, etc.) son pblicos y estn
disponibles gratuitamente a toda la comunidad Internet. Esto tampoco es as en el caso de ISO
y ITU-T, ya que sus documentos no se encuentran accesibles a todo el pblico y adems hay
que pagar por ellos, aunque esto est cambiando ltimamente.
1.5 Historia de X.400

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

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

El propsito del nivel de aplicacin es servir como intermediario entre procesos de aplicacin de
usuario que estn utilizando los recursos OSI para intercambiar informacin (vase la figura 2.1).
Proceso
Aplicacin
Usuario
Nivel de
aplicacin
Proceso
Aplicacin
Usuario
Protocolo de
aplicacin
Nivel de
aplicacin
Proveedor del servicio de presentacin
Fig. 2.1 Procesos de aplicacin de usuario y nivel de aplicacin
Se define un proceso de aplicacin (AP, Application Process) como un elemento dentro de un

sistema abierto que realiza el procesado distribuido de informacin (es decir, que implica
comunicacin) para una determinada aplicacin. Los procesos de aplicacin intercambian
informacin por medio de entidades de aplicacin que implementan protocolos de aplicacin
utilizando servicios de presentacin.
Una entidad de aplicacin (AE, Application Entity) define los aspectos concernientes a la
comunicacin de un proceso de aplicacin. Las entidades de aplicacin intercambian informacin
por medio de unidades de datos del protocolo de aplicacin (APDU, Application Protocol Data
Unit) (vase la figura 2.2).
En el caso ms general, un proceso de aplicacin puede definir varios tipos de intercambio de
informacin. Por lo tanto, su comunicacin tendr varios aspectos que se implementarn mediante
diferentes AE. Para la mayor parte de las aplicaciones distribuidas es suficiente una nica entidad de
aplicacin.
Para que dos entidades de aplicacin puedan cooperar es necesario establecer previamente una
asociacin de aplicacin o simplemente una asociacin (Application Association). El concepto de
asociacin en el nivel de aplicacin equivale al concepto de conexin en el resto de niveles del
modelo OSI. Una asociacin se mapea directamente sobre una conexin de presentacin. La entidad
de aplicacin que toma la iniciativa de establecer la asociacin es la entidad que inicia la asociacin
(Initiator Entity) y la que acepta o rechaza la asociacin es la entidad que responde (Responder
Entity).
Una entidad de aplicacin consta de un elemento de usuario (UE, User Element) y un conjunto de
elementos de servicio de aplicacin (ASE, Application Service Element) (vase la figura 2.2).
25
El elemento de usuario (UE, User Element) representa aquella parte de la entidad de aplicacin que
coordina los elementos de servicio de aplicacin (ASE) necesarios para llevar a cabo los objetivos de
comunicacin de dicho proceso de aplicacin. Es decir, gestiona los diferentes ASE que constituyen
dicha AE y adems es el interfaz con el proceso de aplicacin de usuario.
Un elemento de servicio de aplicacin (ASE, Application Service Element) es aquella parte de una
entidad de aplicacin que proporciona una funcin particular en el entorno OSI. Para ello, si es
necesario, puede utilizar los servicios proporcionados por otros ASE o por los niveles inferiores. Un
ASE no es ms que un conjunto de funciones que permiten a las AE cooperar para un determinado
propsito.
Proceso
Aplicacin
Usuario
Proceso
Aplicacin
Usuario
AE
AE
Protocolos de
aplicacin
UE
ASE
1
...
ASE
n
(APDU)
UE
ASE
1
...
ASE
n
Conexin de presentacin
Fig. 2.2 Estructura de una entidad de aplicacin
Un ASE queda definido por un servicio y un protocolo. Por lo tanto, cada ASE genera sus propias
APDUs y define diferentes sintaxis abstractas y de transferencia, con lo que da lugar a diferentes
contextos de presentacin. En el nivel de aplicacin no se puede hablar de un protocolo de aplicacin
nico sino de un conjunto de protocolos de aplicacin, uno para cada par de ASE residentes en
entidades de aplicacin remotas. Algunos ASE son obligatorios, es decir, siempre deben formar parte
de cualquier entidad de aplicacin, mientras que otros son opcionales. En OSI, el usuario del servicio
de presentacin es siempre un ASE.
Se define un contexto de aplicacin (AC, Application Context) como el conjunto de servicios y
protocolos de aplicacin utilizados por una entidad de aplicacin en una asociacin. Bsicamente
indica el conjunto de ASE que componen el proceso de aplicacin definiendo implcitamente los
protocolos (vase la figura 2.3).
Los ASE que constituyen una entidad de aplicacin pueden ser iguales en los dos extremos y reciben
el nombre de ASE simtricos, o complementarios y reciben el nombre de ASE asimtricos. En los
ASE asimtricos uno tiene el papel de consumidor o cliente y el otro el papel de suministrador o
servidor del servicio (vase el apartado 3.1.1 correspondiente a la arquitectura cliente/servidor).
26
Proceso
Aplicacin
Usuario
Proceso
Aplicacin
Usuario
AE
AE
UE
ASE
UE
ASE
Protocolo de
aplicacin
ASE ASE
ROSE
ROSE
RTSE
RTSE
ACSE
ACSE
Conexin de presentacin
Fig. 2.3 Estructura de un contexto de aplicacin
Un elemento de servicio de aplicacin (ASE) puede ser de dos tipos:

-
comn
especfico
Los ASE comunes son aqullos que ofrecen una funcionalidad que la mayor parte de aplicaciones
distribuidas utilizan. Por esta razn se crey conveniente estandarizarlos y se ofrecen como un
recurso comn en los entornos de desarrollo de aplicaciones distribuidas. As el diseador puede
utilizar estos ASEs comunes y concentrarse en el diseo de la aplicacin propiamente dicha.
Los ASE especficos son aquella parte de una entidad de aplicacin que implementan las
funcionalidades concretas del sistema distribuido que se est diseando y son la parte que diferencia
unas aplicaciones de otras.
Se han normalizado varios ASE comunes. Los ms utilizados son:
-
ACSE (Association Control Service Element). Se encarga de la gestin de asociaciones entre

entidades de aplicacin.
RTSE (Reliable Transfer Service Element). Realiza la transferencia fiable y masiva de APDU.
ROSE (Remote Operation Service Element). Se utiliza para implementar interacciones del tipo
peticin/respuesta (paradigma cliente/servidor).
Estos ASE comunes no son los nicos que se han normalizado, pero a lo largo del libro solamente se
va a hacer referencia a estos tres.
27
La figura 2.3 ilustra el concepto de contexto de aplicacin. Se puede observar que existe una relacin
entre los ASE comunes y especficos que constituyen una entidad de aplicacin.
2.3 Direccionamiento en el nivel de aplicacin

Para establecer una asociacin entre dos entidades de aplicacin es necesario poder direccionar una
entidad de aplicacin dentro del entorno OSI. Para conseguirlo se utilizan, a nivel de
direccionamiento, dos informaciones:
-
contexto de aplicacin (AC)

ttulo de la entidad de aplicacin (AE-Title)
El contexto de aplicacin determina el conjunto de protocolos a soportar, pero es en el

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

El elemento de servicio de control de asociacin (ACSE, Association Control Service Element) es el
encargado de suministrar facilidades para la gestin de asociaciones entre entidades de aplicacin
que se comunican a travs de una conexin de presentacin. El elemento de servicio comn ACSE es
28
obligatorio, es decir, debe formar parte de cualquier entidad de aplicacin. Existe una
correspondencia uno a uno entre una conexin de presentacin y una asociacin de aplicacin. Los
estndares [ACS0192] y [ACS0194] definen el servicio de ACSE, y [ACS0288] y [ACS0391]
describen el protocolo.
2.4.1 Servicio
El servicio ACSE asume que se dispone como mnimo de la unidad funcional Kernel de
presentacin.
Los servicios que suministra ACSE son los siguientes:
Servicio
A-ASSOCIATE
A-RELEASE
A-ABORT
A-P-ABORT
Tipo
Confirmado
Confirmado
No confirmado
No confirmado (iniciado por el proveedor)
A-ASSOCIATE
El servicio A-ASSOCIATE sirve para establecer una asociacin y es un servicio confirmado (Fig.
2.4). Mediante los parmetros del servicio A-ASSOCIATE se especifica, entre otras cosas, el
contexto de aplicacin, la lista de contextos de presentacin vlidos para cada ASE y el contexto de
presentacin por defecto para una asociacin determinada.
Usuario ACSE
Proveedor ACSE
Usuario ACSE
A-ASSOCIATE.request
A-ASSOCIATE.indication
A-ASSOCIATE.response
A-ASSOCIATE.confirm
Fig 2.4 Primitivas del servicio A-ASSOCIATE de ACSE
El servicio A-ASSOCIATE tiene los siguientes parmetros:

-
modo: normal o X.410-1984

contexto de aplicacin
ttulo de la entidad de aplicacin iniciadora
29
ttulo de la entidad de aplicacin llamada

ttulo de la entidad de aplicacin que responde (opcional)
informacin de usuario
resultado
diagnstico (slo si se ha rechazado la asociacin)
direccin de la entidad de presentacin iniciadora
direccin de la entidad de presentacin llamada
direccin de la entidad de aplicacin que responde (opcional)
lista de contextos de presentacin: inicial y resultante
contexto de presentacin por defecto: inicial y resultante
calidad de servicio
parmetros relacionados con presentacin y sesin: tokens, puntos de sincronizacin, etc.
Estos parmetros aparecen en las cuatro primitivas del servicio A-ASSOCIATE. De todas formas,
existen algunas pequeas diferencias entre los parmetros de cada una de las primitivas en lo que
hace referencia a la opcionalidad.
El parmetro modo selecciona entre un modo de funcionamiento de ACSE normal, que adems es
el valor por defecto, y un modo de funcionamiento especfico para mensajera electrnica. Con el
parmetro contexto de aplicacin, el iniciador de la asociacin propone un contexto de aplicacin
para la asociacin que solicita. A continuacin hay una serie de parmetros donde se identifican las
entidades de aplicacin que inicia y acepta la asociacin. El ttulo de la entidad de aplicacin
consta del ttulo del proceso de aplicacin y el calificador de la entidad de aplicacin. El campo de
informacin de usuario lo pueden utilizar indistintamente las dos entidades para incluir
informacin (por ejemplo, credenciales de autenticacin, etc.). El parmetro resultado contiene
informacin relativa al resultado de la negociacin del establecimiento de la asociacin: aceptada,
rechazada de forma transitoria o rechazada de forma permanente. El parmetro diagnstico indica
la causa del rechazo de la asociacin si as lo indica el parmetro resultado; los valores pueden ser
no existe razn aparente, contexto de aplicacin no soportado y ttulo de la entidad de aplicacin
iniciadora o llamada desconocido. El resto son parmetros relacionados con los niveles de
presentacin y sesin.
El servicio A-ASSOCIATE se mapea directamente sobre el servicio P-CONNECT de presentacin.
La entidad de aplicacin que ha generado la primitiva A-ASSOCIATE.request antes de recibir AASSOCIATE.confirmation slo puede utilizar el servicio A-ABORT.
A-RELEASE
El servicio A-RELEASE, que es confirmado, es una liberacin ordenada y sirve para finalizar una
asociacin sin prdida de informacin en trnsito (Fig. 2.5). La liberacin de una asociacin puede
iniciarla cualquiera de las dos entidades de aplicacin.
30
Usuario ACSE
Proveedor ACSE
Usuario ACSE
A-RELEASE.request
A-RELEASE.indication
A-RELEASE.response
A-RELEASE.confirm
Fig 2.5 Primitivas del servicio A-RELEASE de ACSE
Los parmetros de las primitivas del servicio A-RELEASE son:

-
Causa de la liberacin
Informacin de usuario
Resultado: afirmativo o negativo
El parmetro causa de la liberacin, si figura en al primitiva A-RELEASE.request, puede tener los

valores normal, urgente o definido por el usuario, pero si es un parmetro de la primitiva ARELEASE.response, los valores posibles son: normal, no finalizada o definida por el usuario. El
parmetro resultado lo utiliza la entidad de aplicacin que acepta la asociacin para indicar la
aceptacin o rechazo de la liberacin de la asociacin.
El servicio A-RELEASE se mapea directamente sobre el servicio P-RELEASE de presentacin.
A-ABORT
El servicio A-ABORT lo utiliza el usuario de ACSE para liberar una asociacin de forma abrupta. Es
un servicio no confirmado (Fig. 2.6).
Usuario ACSE
Proveedor ACSE
Usuario ACSE
A-ABORT.request
A-ABORT.indication
Fig. 2.6 Primitivas del servicio A-ABORT de ACSE
31
Los parmetos de las primitivas del servicio A-ABORT son los siguientes:
-
Origen del aborto: usuario de ACSE o proveedor del servicio ACSE

El primer parmetro, como su nombre indica, contiene informacin del origen de la liberacin. El
campo de informacin de usuario pueden utilizarlo las entidades de aplicacin para incluir
informacin cuyo significado depende del contexto de aplicacin.
El servicio A-ABORT se mapea directamente sobre el servicio P-U-ABORT de presentacin. Una
vez generada la primitiva A-ABORT.request, para el iniciador la asociacin ha sido liberada. El
proveedor del servicio ACSE puede utilizar el servicio A-ABORT para liberar una asociacin por
problemas internos del protocolo de aplicacin.
A-P-ABORT
El servicio A-P-ABORT se utiliza para liberar una asociacin de forma abrupta fruto de una
iniciativa del proveedor del servicio.
El servicio A-P-ABORT es un servicio no confirmado que consta de una sola primitiva A-PABORT.indication, y que inicia el proveedor del servicio ACSE (Fig. 2.7). El proveedor del servicio
ACSE utiliza este servicio para indicar que se ha producido una liberacin de la asociacin anmala,
normalmente debida a problemas en los niveles inferiores. Esta situacin puede originar prdida de
informacin en trnsito.
El nico parmetro de la primitiva de servicio A-P-ABORT.indication es:
-
Causa del aborto iniciado por el proveedor
Usuario ACSE
A-P-ABORT.indication
Proveedor ACSE
Usuario ACSE
Figura 2.7 Primitivas del servicio A-P-ABORT de ACSE
El servicio A-P-ABORT de ACSE se mapea directamente sobre el servicio P-P-ABORT de

presentacin.
32
2.4.2 Protocolo
El protocolo ACSE describe la transferencia de informacin entre entidades de aplicacin para la
gestin de asociaciones, es decir, las unidades de datos de aplicacin (APDU).
El protocolo ACSE consta de los siguientes elementos de protocolo:
-
Establecimiento de una asociacin

Liberacin normal de una asociacin
Liberacin abrupta de una asociacin
Las unidades de datos del protocolo de aplicacin (APDU) de ACSE son las siguientes:
AARQ
AARE
RLRQ
RLRE
ABRT
A-ASSOCIATE-REQUEST
A-ASSOCIATE-RESPONSE
A-RELEASE-REQUEST
A-RELEASE-RESPONSE
A-ABORT
La fase de establecimiento de una asociacin utiliza las APDU AARQ y AARE, la fase de liberacin
normal RLRQ y RLRE, y la fase de liberacin abrupta utiliza la APDU ABRT.
A continuacin se muestra una tabla donde aparecen las primitivas de servicio de ACSE y las
correspondientes APDU que las transportan.
Primitiva ACSE
A-ASSOCIATE.request/indication
A-ASSOCIATE.response/confirmation
A-RELEASE.request/indication
A-RELEASE.response/confirmation
A-ABORT.request/indication
APDU
AARQ
AARE
RLRQ
RLRE
ABRT
---
Para hacerse una idea de la complejidad del protocolo ACSE, la mquina de protocolo de control de
asociaciones consta de ocho estados, del orden de 40 transacciones, 15 eventos entrantes y otros
tantos salientes.
2.5 RTSE (Elemento de servicio de transferencia fiable)

El elemento de servicio comn RTSE (Reliable Transfer Service Element) es el encargado de
suministrar facilidades para la transferencia de APDU de gran tamao, garantizando la recepcin
ntegra y nica de las APDU en el otro extremo. El elemento de servicio RTSE es opcional, es decir,
puede formar parte o no de una entidad de aplicacin. En el caso de que est presente, es el
encargado de manejar el elemento de servicio ACSE para la gestin de asociaciones, y del nivel de
33
presentacin para la transferencia de APDU. El estndar [RTS0189] define el servicio de RTSE, y

[RTS0289] describe el protocolo.
RTSE proporciona un mecanismo independiente de la aplicacin para recuperarse de fallos durante
el proceso de transmisin de la informacin, minimizando el nmero de retransmisiones. De esta
forma, libera al diseador de aplicaciones distribuidas de tener que preocuparse por la gestin de las
facilidades que suministra sesin, a travs de presentacin, para recuperarse de dicho tipo de
problemas.
2.5.1 Servicio
El servicio RTSE utiliza el servicio de ACSE para gestionar asociaciones, y asume que se dispone
como mnimo del subconjunto bsico de actividades de sesin (BAS) accesible a travs del servicio
de presentacin. Recordar que el servicio de sesin BAS consta de las unidades funcionales: kernel,
half-duplex, datos tipificados, datos con capacidad, puntos de sincronizacin menor, excepciones y
actividades.
Los servicios que suministra RTSE son los siguientes:
Servicio
RT-OPEN
RT-TRANSFER
RT-TURN-PLEASE
RT-TURN-GIVE
RT-CLOSE
RT-U-ABORT
RT-P-ABORT
Tipo
Confirmado
Confirmado (Slo solicitud, indicacin y confirmacin)
No confirmado
No confirmado
Confirmado
No confirmado
No confirmado (Slo indicacin)
RT-OPEN
El servicio RT-OPEN, que es confirmado, utiliza el elemento de servicio ACSE para establecer una
asociacin, concretamente mediante el servicio A-ASSOCIATE (Fig. 2.8).
Usuario RTSE
Proveedor RTSE
Usuario RTSE
RT-OPEN.request
RT-OPEN.indication
RT-OPEN.response
RT-OPEN.confirmation
Fig 2.8 Primitivas del servicio RT-OPEN de RTSE
34
El servicio RT-OPEN tiene los siguientes parmetros:

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

Turno inicial
Protocolo de aplicacin
Datos de usuario
Parmetros relacionados con ACSE
Parmetros relacionados con presentacin y sesin
El primero de los parmetros especficos relacionados con el servicio RT-OPEN es el modo del
dilogo, que puede ser monlogo, es decir, que nicamente la entidad que est inicialmente en
posesin del turno puede transmitir APDU, o TWA, donde las dos entidades pueden hacerlo
alternativamente siempre y cuando estn en posesin del turno, el cual puede intercambiarse. Otro
parmetro nuevo es el turno inicial, que lo puede poseer la entidad que inicia o la que responde la
asociacin. El parmetro protocolo de aplicacin slo tiene sentido en el modo X.410-1984 (vase
el apartado 2.4 relacionado con ACSE). El parmetro datos de usuario se puede utilizar para
almacenar informacin relacionada con el proceso de establecimiento de la asociacin de aplicacin.
El resto de parmetros son los mismos que se han descrito en el apartado 2.4.1, correspondiente a
ACSE.
RT-TRANSFER
El servicio RT-TRANSFER lo utiliza el usuario de RTSE que est en posesin del turno para
transmitir APDU de forma fiable mediante una asociacin de aplicacin. Normalmente, los servicios
confirmados constan de cuatro primitivas; en cambio, el servicio RT-TRANSFER slo tiene tres
primitivas (vase la figura 2.9). La razn es que una APDU se transmite dentro de una actividad, por
lo que la finalizacin de la actividad con normalidad significa que la APDU ha sido transferida
correctamente por el proveedor de RTSE. Es el protocolo RTSE el que garantiza que la APDU se ha
transmitido, por lo que el usuario receptor no necesita confirmarlo, ya que lo hace directamente el
proveedor de RTSE (vase el apartado 2.5.2 correspondiente al protocolo RTSE).
Usuario RTSE
Proveedor RTSE
Usuario RTSE
RT-TRANSFER.request
RT-TRANSFER.indication
RT-TRANSFER.confirmation
Fig. 2.9 Primitivas del servicio RT-TRANSFER de RTSE
Los parmetros del servicio RT-TRANSFER son:

-
APDU a transmitir
35
Tiempo mximo de transferencia estimado

Resultado de la transferencia: positivo o negativo
El primer parmetro contiene la APDU que se desea transmitir, el segundo define el tiempo mximo
estimado para la transferencia de la APDU; es decir, el tiempo que transcurre entre que el usuario de
RTSE invoca el servicio RT-TRANSFER con la primitiva RT-TRANSFER.request y el mismo
usuario recibe la confirmacin con la primitiva RT-TRANSFER.confirmation. El parmetro
resultado contiene informacin respecto al xito o fracaso de la transferencia de la APDU. El caso
en que el resultado es negativo significa que el proveedor de RTSE no ha podido entregar la APDU
en el tiempo de transferencia especificado, mientras que si el resultado es positivo, significa que el
proveedor de RTSE ha podido entregar de forma fiable la APDU al usuario de RTSE remoto.
El servicio RT-TRANSFER desencadena la utilizacin de una serie de servicios de presentacin que
hacen posible que la transferencia de APDU se realice dentro de una actividad (vase el apartado
2.5.2, correspondiente al protocolo RTSE).
RT-TURN-PLEASE
El servicio RT-TURN-PLEASE es no confirmado, y lo utiliza el usuario de RTSE de la entidad de
aplicacin que quiere transmitir APDU para conseguir el turno si no lo tiene (vase la figura 2.10).
Tambin lo debe utilizar el usuario de RTSE de la entidad de aplicacin iniciadora de la asociacin
para liberarla.
Usuario RTSE
Proveedor RTSE
Usuario RTSE
RT-TURN-PLEASE.request
RT-TURN-PLEASE.indication
Fig. 2.10 Primitivas del servicio RT-TURN-PLEASE de RTSE
El servicio RT-TURN-PLEASE slo tiene un parmetro, que es la prioridad asociada a la accin

para la que se solicita el turno. Con esta informacin, el usuario de RTSE remoto puede decidir
cundo entrega el turno. La prioridad cero indica la prioridad ms alta y se reserva para liberar la
asociacin.
El servicio RT-TURN-PLEASE se mapea sobre el servicio de presentacin P-TOKEN-PLEASE.
RT-TURN-GIVE
El servicio RT-TURN-GIVE, que es no confirmado, permite a un usuario de RTSE de una entidad de
aplicacin entregar el turno al usuario de RTSE remoto, siempre y cuando est en posesin del turno
36
y no est pendiente de la finalizacin de un servicio de transferencia de APDU (RT-TRANSFER)

(vase la figura 2.11).
Usuario RTSE
Proveedor RTSE
Usuario RTSE
RT-TURN-GIVE.request
RT-TURN-GIVE.indication
Fig. 2.11 Primitivas del servicio RT-TURN-GIVE de RTSE
El servicio RT-TURN-GIVE no tiene parmetros y se mapea directamente sobre el servicio de

presentacin P-CONTROL-GIVE.
RT-CLOSE
El servicio RT-CLOSE, que es confirmado, permite al usuario de RTSE liberar de forma ordenada
una asociacin de aplicacin (vase la figura 2.12). La liberacin slo puede realizarla el usuario de
RTSE de la entidad iniciadora de la asociacin cuando est en posesin del turno y no tiene
pendiente la finalizacin de una transferencia de APDU (recepcin de RTTRANSFER.confirmation). El usuario de RTSE de la entidad de aplicacin que responde la
asociacin no puede rechazar la liberacin.
Usuario RTSE
Proveedor RTSE
Usuario RTSE
RT-CLOSE.request
RT-CLOSE.indication
RT-CLOSE.response
RT-CLOSE.confirmation
Fig. 2.12 Primitivas del servicio RT-CLOSE de RTSE
Los parmetros de las primitivas del servicio RT-CLOSE son:

-
Causa de la liberacin
Estos parmetros nicamente tienen sentido en modo de operacin normal, ya que en modo X.4101984 no existen parmetros.
37
El servicio RT-CLOSE de RTSE se mapea directamente sobre el servicio A-RELEASE de ACSE,

que a su vez se mapea sobre el servicio P-RELEASE de presentacin.
RT-U-ABORT
El servicio RT-U-ABORT lo pueden utilizar los dos usuarios de RTSE para liberar una asociacin de
forma abrupta, y utiliza los servicios equivalentes de ACSE. El servicio RT-U-ABORT es un servicio
no confirmado (vase la figura 2.13).
Usuario RTSE
Proveedor RTSE
Usuario RTSE
RT-U-ABORT.request
RT-U-ABORT.indication
Fig. 2.13 Primitivas del servicio RT-U-ABORT de RTSE
El servicio RT-U-ABORT slo tiene un parmetro, que es un campo de informacin del usuario que
se utiliza para informar sobre el proceso de liberacin abrupta de la asociacin de aplicacin.
El servicio RT-U-ABORT de RTSE se mapea directamente sobre el servicio A-ABORT de ACSE.
RT-P-ABORT
El servicio RT-P-ABORT se utiliza para liberar una asociacin de forma abrupta fruto de una
iniciativa del proveedor del servicio RTSE y, como en el caso anterior, lo hace utilizando el servicio
equivalente de ACSE A-P-ABORT (vase la figura 2.14). El proveedor del servicio informa a los dos
usuarios de RTSE que le es imposible mantener la asociacin de aplicacin.
Usuario RTSE
RT-P-ABORT.indication
Proveedor RTSE
Usuario RTSE
Fig. 2.14 Primitivas del servicio RT-P-ABORT de RTSE
El servicio RT-P-ABORT, que no tiene parmetros, es un servicio no confirmado que consta de una
sola primitiva (RT-P-ABORT.indication) que inicia el proveedor del servicio RTSE.
El servicio RT-P-ABORT de RTSE se mapea directamente sobre el servicio A-P-ABORT de ACSE.
38
2.5.2 Protocolo
La mquina de protocolo de RTSE (RTPM, Reliable Transfer Protocol Machine), proporciona el
servicio RTSE que se ha descrito en el apartado anterior utilizando el elemento de servicio ACSE y
el servicio de presentacin.
El protocolo RTSE consta de los siguientes elementos de protocolo:
-
Establecimiento de una asociacin (que se realiza mediante ACSE)

Transferencia de APDU
Peticin y cesin de turno
Liberacin de una asociacin: ordenada y abrupta (que se realiza mediante ACSE)
Gestin de errores
Las unidades de datos del protocolo de aplicacin (APDU) de RTSE son las siguientes:
RTORQ
RTOAC
RTORJ
RTTR
RTTP
RTAB
RT-OPEN-REQUEST
RT-OPEN-ACCEPT
RT-OPEN-REJECT
RT-TRANSFER
RT-TOKEN-PLEASE
RT-P-ABORT y RT-U-ABORT
A continuacin se muestra una tabla donde se indica el mapeo entre las primitivas de servicio de
RTSE y las primitivas de ACSE, as como las APDU que las transportan.
Primitiva RTSE
RT-OPEN.request/indication
RT-OPEN.response/confirmation
RT-OPEN.response/confirmation
RT-CLOSE.request/indication
RT-CLOSE.response/confirmation
RT-U-ABORT.request/indication
APDU
RTORQ
RTOAC
RTORJ
----RTAB
RTAB
Primitiva ACSE
A-ASSOCIATE.request/indication
A-RELEASE.request/indication
A-RELEASE.response/confirmation
A-ABORT.request/indication
Cuando un usuario de RTSE invoca el servicio RT-TRANSFER, la transferencia fiable de la APDU

se realiza a nivel de presentacin dentro de una actividad (servicios P-ACTIVITY-START y PACTIVITY-END). Para poder transmitir la APDU ser necesario fraccionar la APDU en una serie
de trozos de un determinado tamao que se habr negociado en la fase de establecimiento de la
asociacin (espaciado entre puntos de sincronizacin). Para poder fraccionar la APDU primero es
necesario serializar la informacin, para lo cual, la mquina de protocolo de RTSE deber obtener la
sintaxis de transferencia y entregar cada fragmento al servicio de presentacin. A cada uno de estos
fragmentos de la APDU original as obtenidos se le asigna el tipo OCTECT STRING de ASN.1, y se
entregan al servicio de presentacin mediante tantas primitivas del servicio P-DATA como sea
necesario. Con el objeto de facilitar las retransmisiones en caso de problemas, se va marcando la
transmisin con puntos de sincronizacin menor (servicio P-MINOR-SYNC). El nmero de puntos
39
de sincronizacin que pueden existir sin confirmar se negocia tambin en la fase de establecimiento
de la asociacin (tamao de la ventana). La utilizacin de actividades a nivel de presentacin
justifica que el servicio RT-TRANSFER tenga tres primitivas en vez de cuatro como tienen todos los
servicios confirmados. Efectivamente, el hecho de que la actividad de presentacin acabe
normalmente significa que la APDU se ha transmitido correctamente y se encuentra ntegra en el
proveedor de RTSE remoto. Incluir una primitiva de respuesta a nivel de usuario de RTSE no
aportara nada respecto a la transmisin de la APDU, pero en cambio introducira redundancia en la
transmisin. En la figura 2.15 se ilustra grficamente la relacin entre la utilizacin por un usuario
de RTSE del servicio RT-TRANSFER para transmitir una APDU, y los servicios de presentacin
necesarios para transmitirla dentro de una actividad.
Usuario RTSE
Proveedor
Usuario RTSE
P-ACTIVITY-START .
request
RT-OPEN.request
P-ACTIVITY-START .
indication
P-DATA.request
P-DATA.indication
P-SYNC-MINOR.
request
P-SYNC-MINOR.
indication
P-ACTIVITY-END.
request
P-ACTIVITY-END.
indication
RT-TRANSFER.indication
P-ACTIVITY-END.
response
P-ACTIVITY-END.
confirmation
RT-OPEN.confirmation
Fig. 2.15 Transferencia fiable de una APDU de RTSE y su

relacin con el nivel de presentacin
El proceso de serializacin de la informacin aplicando unas reglas de codificacin concretas para

obtener una sintaxis de transferencia es una funcin del nivel de presentacin. En cambio se ha dicho
que la mquina de protocolo de RTSE realiza dicha funcin cuando tiene que transferir una APDU.
Esto vulnera la independencia de los niveles que preconiza ISO en su modelo de interconexin de
sistemas abiertos y es una de las incoherencias que presenta el nivel de aplicacin.
A continuacin se muestra una tabla donde aparece el mapeo entre las primitivas de RTSE y las
primitivas de presentacin, as como tambin las APDU que las transportan.
Primitiva RTSE
RT-TRANSFER.request/indication
RT-TRANSFER.indication/confirmation
APDU
--RTTR
-----
Primitiva Presentacin
P-ACTIVITY-START.request/indication
P-DATA.request/indication
P-MINOR-SYNCHRONIZE
P-ACTIVITY-END
40
RT-TURN-PLEASE.request/indication
RT-TURN-GIVE.request/indication
RTTP
---
P-TOKEN-PLEASE.request/indication
P-CONTROL-GIVE.request/indication
2.6 ROSE (Elemento de servicio de operaciones remotas)

El tercer elemento de servicio comn del nivel de aplicacin es ROSE (Remote Operations Service
Element), que se utiliza para implementar aplicaciones distribuidas interactivas del tipo
peticin/respuesta (paradigma cliente/servidor). Una entidad de aplicacin invoca la operacin
remota (invoker entity) y la otra la realiza y genera un resultado (performer entity). El mecanismo de
operaciones remotas se implementa utilizando el elemento de servicio comn de aplicacin ROSE.
Los estndares [ROS0189] y [ROS1294] describen el servicio de ROSE y los estndares [ROS0289]
y [ROS1394] el protocolo.
La respuesta (reply) generada a partir de una solicitud (request) puede ser de tres tipos en funcin del
resultado de la operacin remota. As, si se ha ejecutado correctamente, la respuesta ser un
resultado; si se ha ejecutado pero sin xito, la respuesta ser un error; y la ltima posibilidad es que
la operacin no se haya podido ejecutar por alguna razn, en ese caso la respuesta ser un rechazo
(vase la figura 2.16).
AE
Invoca
operacin
remota
Invocacin
Resultado
Rechazo
Error
AE
Realiza
operacin
remota
Fig 2.16 Modelo funcional para ROSE
Las operaciones remotas se pueden clasificar segn dos modos de funcionamiento llamados modo
sncrono y modo asncrono. El modo sncrono consiste en la posibilidad de invocar las operaciones
de forma secuencial, de forma que, cuando se lanza una operacin remota en modo sncrono, no se
puede lanzar la siguiente hasta que no se ha recibido su correspondiente respuesta. En modo
asncrono se pueden lanzar varias operaciones remotas sin necesidad de esperar las respectivas
respuestas, sino que stas van llegando conforme se van produciendo.
Las operaciones remotas tambin se pueden clasificar en cinco tipos o clases en funcin del modo de
operacin que utilizan y el tipo de resultado que generan. La operacin clase 1 utiliza modo sncrono
y genera siempre una respuesta, ya sea resultado o error. La operacin clase 2 utiliza modo asncrono
y genera siempre una respuesta. La operacin clase 3 utiliza modo asncrono y slo genera un error si
existe, y si se ejecuta correctamente no genera ninguna respuesta. Las operaciones clase 4 utilizan
modo asncrono y slo generan un resultado, mientras que las de clase 5, que tambin utilizan modo
asncrono, no devuelven ninguna respuesta en ningn caso (vase la figura 2.17).
41
Invoca RO
Realiza RO
AE
Clase 1
AE
Invocacin
Respuesta
Invocacin
Respuesta
Invocaciones
Clase 2
Respuestas
Invocaciones
Clase 3
Error
Invocaciones
Clase 4
Clase 5
Resultado
Invocaciones
Fig. 2.17 Clases de operaciones remotas de ROSE
En algunos casos es til disponer de la posibilidad de agrupar operaciones de forma que una
operacin inicial, llamada operacin padre, desencadene como respuesta nuevas operaciones
llamadas operaciones hijas. Se dice que las operaciones hijas estn enlazadas ("linked") con la
operacin padre (vase la figura 2.18).
AE
ejecuta las
operaciones hijas
enlazadas
invocacin de
operacin padre
AE
invocacin de
operacin hija
ejecucin de
operacin
padre
invocacin de
operacin hija
ejecuta la
operacin padre
Fig 2.18 Operaciones remotas enlazadas
2.6.1 Servicio
Los servicios que ofrece ROSE son los siguientes:
Servicio
RO-INVOKE
RO-RESULT
Tipo
No confirmado
No confirmado
42
RO-ERROR
RO-REJECT-U
RO-REJECT-P
No confirmado
No confirmado (Iniciado por el usuario)
No confirmado (Iniciado por el proveedor)
RO-INVOKE
El servicio RO-INVOKE, que es no confirmado, lo utiliza un usuario de ROSE para invocar una
operacin remota que deber ejecutar el usuario de ROSE remoto (vase la figura 2.19).
Usuario ROSE
Proveedor ROSE
Usuario ROSE
RO-INVOKE.request
RO-INVOKE.indication
Fig. 2.19 Primitivas del servicio RO-INVOKE de ROSE
Los parmetros del servicio RO-INVOKE son los siguientes:

-
Identificador de la operacin
Clase de la operacin
Argumento
Identificador de la invocacin
Identificador de la operacin enlazada
Prioridad
El parmetro "identificador de la operacin" identifica la operacin que se va a invocar y tiene que

ser el mismo para los dos usuarios de ROSE. El argumento "clase de la operacin" sirve para saber si
se utiliza modo sncrono o asncrono y el tipo de respuesta esperada (resultado, error o rechazo); su
uso permite optimizar la gestin del turno en el caso de que se utilice RTSE. El parmetro
"argumento", como su nombre indica, es el argumento de la operacin invocada. El "identificador de
la invocacin" sirve para asociar una respuesta a una invocacin cuando se trabaja en modo
asncrono o para el caso de que existan operaciones enlazadas (o hijas). El parmetro "identificador
de la operacin enlazada", que es opcional, si existe significa que la operacin invocada es una
operacin hija y se utiliza para indicar la operacin padre. El parmetro "prioridad" se utiliza para
asignar una escala de prioridades a las diferentes transferencias de APDU entre las entidades de
aplicacin.
El servicio RO-INVOKE de ROSE se mapea directamente sobre el servicio P-DATA del nivel de
presentacin.
43
RO-RESULT
El servicio RO-RESULT lo utiliza el usuario de ROSE que ejecuta la operacin para devolver el
resultado de la operacin solicitada en el caso de que sta se haya ejecutado con xito. Es un servicio
no confirmado (vase la figura 2.20).
Usuario ROSE
Proveedor ROSE
Usuario ROSE
RO-RESULT.request
RO-RESULT.indication
Fig. 2.20 Primitivas del servicio RO-RESULT de ROSE
Los parmetros del servicio RO-RESULT son los siguientes:

-
Identificador de la operacin
Resultado
Prioridad
Los parmetros de las primitivas del servicio RO-RESULT, "identificador de la operacin" e

"identificador de la invocacin", son los mismos que se han estudiado en la invocacin de la
operacin con el servicio RO-INVOKE. Como su nombre indica, el parmetro "resultado" contiene
el resultado de una invocacin remota ejecutada con xito. Finalmente, con el parmetro "prioridad"
se asigna prioridad a la transferencia de la correspondiente APDU.
El servicio RO-RESULT de ROSE se mapea directamente sobre el servicio P-DATA del nivel de
presentacin.
RO-ERROR
El servicio RO-ERROR, que es un servicio no confirmado, lo utiliza el usuario de ROSE que ejecuta
la operacin para indicar al usuario que invoca la operacin solicitada que se ha ejecutado con
errores (vase la figura 2.21).
Los parmetros del servicio RO-RESULT son los siguientes:
-
Identificador del error

Parmetro del error
Prioridad
44
Usuario ROSE
Proveedor ROSE
Usuario ROSE
RO-ERROR.request
RO-ERROR.indication
Fig. 2.21 Primitivas del servicio RO-ERROR de ROSE
El parmetro "identificador del error" identifica el tipo de error que se ha producido al ejecutar la
operacin y en el parmetro "parmetro del error" el usuario de ROSE puede incluir informacin
adicional respecto al error. Los parmetros "identificador de la invocacin" y "prioridad" son los
mismos que se ha estudiado en la invocacin de la operacin mediante el servicio RO-INVOKE.
El servicio RO-ERROR de ROSE se mapea directamente a nivel de presentacin mediante el servicio
P-DATA.
RO-REJECT-U
El servicio RO-REJECT-U lo puede utilizar un usuario de ROSE para indicar al otro usuario de
ROSE que no puede ejecutar la operacin remota solicitada mediante el servicio RO-INVOKE, al
detectar algn tipo de problemas (vase la figura 2.22). Tambin se puede utilizar este servicio para
rechazar una respuesta (resultado o error) de una invocacin anterior.
Usuario ROSE
Proveedor ROSE
Usuario ROSE
RO-REJECT-U.request
RO-REJECT-U.indication
Fig 2.22 Primitivas del servicio RO-REJECT-U de ROSE
Los parmetros de las primitivas del servicio RO-REJECT-U son los siguientes:
-
Causa del rechazo

Prioridad
Los parmetros "identificador de la invocacin" y "prioridad" son los mismos que se han visto en la
descripcin de los otros servicios de ROSE. El parmetro "causa del error" contiene informacin
45
diferente segn sea un rechazo a una primitiva RO-INVOKE.indication, RO-RESULT.indication o

RO-ERROR.indication anteriores. Las causas de rechazo de una primitiva RO-INVOKE.indication
son las siguientes: invocacin duplicada, operacin desconocida, argumento errneo, recursos
limitados, liberacin del iniciador de la asociacin, identificador de la operacin enlazada
desconocido, respuesta de la operacin enlazada no esperada y operacin hija no esperada. En el
caso de rechazo de una primitiva RO-RESULT.indication anterior, las causas de rechazo son:
invocacin no desconocida, resultado no esperado y resultado errneo. Finalmente, si el rechazo
corresponde a una primitiva RO-ERROR.indication, las causas de rechazo son: invocacin
desconocida, error no esperado, error desconocido y parmetro errneo.
El servicio RO-REJECT-U de ROSE se mapea directamente sobre el servicio P-DATA del nivel de
presentacin.
RO-REJECT-P
El servicio RO-REJECT-P lo utiliza el proveedor del servicio ROSE para indicar a sus usuarios que
ha detectado algn tipo de problema. Es un servicio no confirmado que, al ser iniciado por el
proveedor, nicamente tiene una primitiva que es RO-REJECT-P.indication (vase la figura 2.23).
Usuario ROSE
RO-REJECT-P.indication
Proveedor ROSE
Usuario ROSE
RO-REJECT-P.indication
Fig. 2.23 Primitivas del servicio RO-REJECT-P de ROSE
Los parmetros de las primitivas del servicio RO-REJECT-P son los siguientes:
-
Causa del rechazo

Parmetros retornados
Los parmetros de la primitiva RO-REJECT-P.indication, que son todos opcionales, son el

identificador de la invocacin, la causa del rechazo y un campo de parmetros del rechazo que
contiene el parmetro de la primitiva rechazada para el caso de que el proveedor de ROSE no haya
podido transferir la APDU correspondiente. La causa del rechazo puede ser: APDU irreconocible,
APDU errnea o estructura de la APDU errnea.
El servicio RO-REJECT-P de ROSE se mapea directamente a nivel de presentacin mediante el
servicio P-DATA.
46
2.6.2 Protocolo
El protocolo ROSE queda definido por la mquina de protocolo de ROSE (ROPM, Remote
Operations Protocol Machine). Se pueden identificar una serie de elementos de protocolo que son los
siguientes:
-
Invocacin
Retorno de resultado
Retorno de error
Rechazo del usuario
Rechazo del proveedor
El protocolo de ROSE define las siguientes APDU:

ROIV
RORS
ROER
RORJ
RO-INVOKE
RO-RESULT
RO-ERROR
RO-REJECT
A continuacin se muestra el mapeo entre las primitivas de servicio de ROSE y el servicio de

presentacin, as como las APDU que se utilizan para transportar dichas primitivas.
Servicio ROSE
RO-INVOKE.request/indication
RO-RESULT.request/indication
RO-ERROR.request/indication
RO-REJECT-U.request/indication
RO-REJECT-P.request/indication
APDU
ROIV
RORS
ROER
RORJ
RORJ
Servicio presentacin

Merged

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Merged

Enviado por

Direitos autorais:

Formatos disponíveis

1 Introduccin

Aplicaciones distribuidas abiertas

1.2 OSI e Internet

1.3 Estandarizacin ISO

Aplicaciones distribuidas abiertas

1.4 Estandarizacin en Internet

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

Aplicaciones distribuidas abiertas

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

1.5 Historia de X.400

1.6 Historia de ODA

Aplicaciones distribuidas abiertas

Aplicaciones distribuidas abiertas

2.2 Estructura del nivel de aplicacin

Proveedor del servicio de presentacin

Fig. 2.1 Procesos de aplicacin de usuario y nivel de aplicacin

Se define un proceso de aplicacin (AP, Application Process) como un elemento dentro de un

Fig. 2.2 Estructura de una entidad de aplicacin

Aplicaciones distribuidas abiertas

Fig. 2.3 Estructura de un contexto de aplicacin

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

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

2.3 Direccionamiento en el nivel de aplicacin

contexto de aplicacin (AC)

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

2.4 ACSE (Elemento de servicio de control de asociacin)

Aplicaciones distribuidas abiertas

Fig 2.4 Primitivas del servicio A-ASSOCIATE de ACSE

El servicio A-ASSOCIATE tiene los siguientes parmetros:

modo: normal o X.410-1984

ttulo de la entidad de aplicacin llamada

Aplicaciones distribuidas abiertas

Fig 2.5 Primitivas del servicio A-RELEASE de ACSE

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

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

Fig. 2.6 Primitivas del servicio A-ABORT de ACSE

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

Causa del aborto iniciado por el proveedor

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

El servicio A-P-ABORT de ACSE se mapea directamente sobre el servicio P-P-ABORT de

Aplicaciones distribuidas abiertas

Establecimiento de una asociacin

2.5 RTSE (Elemento de servicio de transferencia fiable)

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

Fig 2.8 Primitivas del servicio RT-OPEN de RTSE

Aplicaciones distribuidas abiertas

El servicio RT-OPEN tiene los siguientes parmetros:

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

Fig. 2.9 Primitivas del servicio RT-TRANSFER de RTSE

Los parmetros del servicio RT-TRANSFER son:

Tiempo mximo de transferencia estimado

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

El servicio RT-TURN-PLEASE slo tiene un parmetro, que es la prioridad asociada a la accin

Aplicaciones distribuidas abiertas

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

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

El servicio RT-TURN-GIVE no tiene parmetros y se mapea directamente sobre el servicio de

Fig. 2.12 Primitivas del servicio RT-CLOSE de RTSE

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

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

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

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

Aplicaciones distribuidas abiertas