-
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
sehabla de aplicaciones distribuidas, se estn considerando
aplicaciones que se ejecutan en mquinasseparadas fsicamente. Estas
mquinas, dos o ms, cooperan para alcanzar objetivos determinados.El
intercambio de mensajes (o correo electrnico), la transferencia de
ficheros, la manipulacinremota de documentos, la gestin de
informacin remota, etc, son simples ejemplos de
aplicacionesdistribuidas.
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), queson pblicas, que
especifican qu servicio va a dar la aplicacin y qu protocolo va a
seguir para dardicho servicio. Por supuesto, esto no tiene que
restringir la implementacin de la aplicacin, sinoque, al contrario,
sirve para que implementaciones independientes en sistemas
diferentes se puedaninterconectar gracias a que siguen las reglas
definidas en los estndares.
Por tanto, este libro describe aplicaciones distribuidas
abiertas para intercambiar mensajes, transferirficheros y
documentos, manipular documentos y almacenes de documentos
remotamente, acceder ainformacin sobre mquinas y usuarios, etc.
-
16 Aplicaciones distribuidas abiertas
1.2 OSI e Internet
En el cambiante mundo actual de la comunicacin entre
ordenadores, dos enfoques (dosarquitecturas de comunicacin entre
ordenadores) distintos, aunque no incompatibles, destacan sobrelos
dems. Podemos llamarlos OSI e Internet.
Cuando se habla de OSI (Open Systems Interconnection), o
interconexin de sistemas abiertos, seest haciendo referencia a los
sistemas de comunicacin entre ordenadores basados en la
arquitecturaconocida como OSI (o modelo arquitectnico de referencia
OSI), estandarizado por la OrganizacinInternacional de
Estandarizacin (ISO, International Standards Organization),
juntamente con loque 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
UninInternacional de Telecomunicaciones (ITU-T).
En el modelo OSI, se definen 7 niveles o capas en los que se
estructura la comunicacin entreaplicaciones 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 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 aplicacin.El lector se supone
familiarizado con los conceptos OSI y con las facilidades
proporcionadas por los6 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 modelonacido a partir de la idea de un
servicio y protocolo sin conexin (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), 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 tambinen estas aplicaciones donde se
concentra este libro que, sin llegar a profundizar en todas
lasaplicaciones Internet tan en auge estos das, s trata sobre la
versin 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 rpidamente. Sin embargo, el contenido de este libro
estactualizado de forma que se detalla lo que se est utilizando
actualmente y se comenta lo que seutilizar 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 lodeben ser para cualquier
persona que trabaje en el campo de aplicaciones distribuidas. Los
conceptosde sistemas abiertos (en OSI) o de interconexin (tanto en
Internet como en OSI) estn detrs de estafilosofa. Si queremos
conseguir que sistemas heterogneos puedan comunicarse, deben seguir
ciertasreglas, y estas reglas se deben acordar internacionalmente.
De ah la necesidad de disponer deestndares.
Formalmente, los estndares slo pueden ser publicados por ISO,
organizacin internacionalformada por los organismos de normalizacin
de todos los pases del mundo, como AENOR enEspaa, 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 siemprese trata de armonizar los
intereses de las empresas privadas, las pblicas y los centros
deinvestigacin.
ISO, al igual que sus equivalentes nacionales, est estructurada
en comits que trabajan en diferentestemas. Por lo que a los
contenidos de este libro incumbe, existe un comit conjunto con el
CEI oComit Electrotcnico Internacional (IEC, International
Electrotechnical Committee) llamado JTC1(Joint Technical Committee
1), que trata todos los temas de las llamadas tecnologas de
lainformacin. A su vez, el JTC1 est estructurado en subcomits, 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 estndares de
correo electrnico X.400 (vasecaptulo 4), arquitectura e intercambio
de documentos ODA (vase captulo 5), almacenamiento yrecuperacin de
documentos DFR (vase captulo 7), la notacin para especificar
aplicacionesdistribuidas (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),
sonresponsabilidad 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 (yanteriormente el CCITT) est
capacitado para publicar lo que ellos llaman recomendaciones que,
aefectos 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
telefnicasprincipalmente, 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 unaterminologa propia. ITU-T est
formado por grupos de estudio (SG, Study Group), que tratan
temasdiferentes, como el SG8, que trabaja en intercambio y
manipulacin de documentos (vase captulo6), fax, etc., y el SG7, que
trabaja en temas como correo electrnico (vase captulo 4). Cada SG
seestructura, 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 deISO y grupos de estudio de ITU-T,
existen temas comunes. Para evitar que ambos organismos
-
18 Aplicaciones distribuidas abiertas
produzcan normas divergentes, muchos grupos de trabajo de ISO
han creado equipos de colaboracino 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 estndaresconjuntos 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 eITU-T (basados en comits o
grupos de trabajo que desarrollan los estndares a
aprobarposteriormente por los organismos miembros), ya que el
desarrollo de normas se basa en laimplementacin y prueba de lo que
se propone especificar. Un estndar Internet no se acepta si
noexisten implementaciones probadas.
Debido a la complejidad que pueden tener los estndares de ISO o
recomendaciones de ITU-T, sedefinen lo que se llaman estndares
funcionales o perfiles, que son subconjuntos implementables delos
estndares base. Estos subconjuntos restringen las caractersticas de
los estndares al eliminarcomplejidades innecesarias en aplicaciones
menos exigentes, con lo que se facilita suimplementacin.
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 ITU-T.
En Europa, existe EWOS (European Workshop for Open Systems) que,
a travs de sus grupos deexpertos en diversos temas, desarrolla
perfiles que despus coordina con otros organismos regionalespara
producir estndares funcionales a aprobar por ISO/IEC. EWOS tambin
es responsable de laproduccin 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 ImplementorsWorkshop), en Norteamrica, y AOW
(Asia Oceania Workshop), principalmente en Japn, Corea
yAustralia.
Finalmente, en Europa existe otro organismo oficial de
normalizacin, el Instituto Europeo deEstndares de
Telecomunicaciones (ETSI, European Telecommunications Standards
Institute), quecomo su nombre indica es responsable en Europa del
desarrollo de estndares relacionados con lastelecomunicaciones. 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 quemencionar que existen muchos
menos organismos en el proceso de estandarizacin, y que ademseste
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 eldocumento [RFC1602], y que a
continuacin se cita:
"En general, un estndar de Internet es una especificacin que es
estable y comprensible, estcnicamente competente, tiene mltiples 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 definicin, un estndar de Internet
slo puede generarse si primerose 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 laInternet puede proponer un
borrador de especificacin para ser comentado por los dems. A
estaespecificacin se la conoce como borrador Internet (ID, Internet
Draft). Este documento se pblicaen la Internet por medio de
servidores de informacin (bsicamente ftp, aunque ahora tambinWWW)
para que sea analizado, y comentado pblicamente. Si en el plazo de
seis meses estedocumento 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
deinformacin y desaparece.
Una vez un documento es catalogado como RFC, este puede
permanecer as para siempre o iniciar elproceso para alcanzar el
estado de estndar de Internet. Para llegar a este estado, el
documentodeber pasar por varios niveles de madurez, pudindose
quedar en alguno de ellos. Segn laterminologa 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) yfinalmente estndar de Internet (IS, Internet Standard).
La diferencia bsica entre ellos, segn sedesprende de la definicin
de estndar de Internet antes citada, es que una propuesta de
estndar nonecesita de implementaciones que interoperen, para pasar
a borrador de estndar es necesariodisponer de por lo menos dos
implementaciones independientes, y el grado de estndar slo
sealcanza con implementaciones y bastante experiencia en su
operacin.
Todo el proceso de revisin y aceptacin de especificaciones para
su designacin como RFC oestndar 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 tecnolgicos y la evolucinde
la Internet; ISOC (Internet Society) que entre otras tiene como
actividad la estandarizacin en laInternet; IESG (Internet
Engineering Steering Group) que controla las actividades del IETF;
y elIAB (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),
asignaridentificadores y parmetros nicos a las RFC, estndares,
protocolos, servicios, etc. de la Internet.
-
20 Aplicaciones distribuidas abiertas
Esta ha sido una rpida visin del proceso de estandarizacin en la
Internet (una descripcincompleta puede encontrarse en [RFC-1602]),
pero nos permite resaltar dos caractersticas muyimportantes en el
campo de los sistemas abiertos:
- Una iniciativa no alcanza el nivel de estndar de Internet si
no se demuestra su utilidadprctica 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
Internetno existen perfiles, ya que todo lo que se estandariza debe
estar implementado.
- Todos los documentos (Internet Drafts, RFC, Internet
Standards, etc.) son pblicos y estndisponibles 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 pblico
y adems hayque 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, InternationalFederation for Information
Processing), una organizacin profesional de informticos, desde
sucomit tcnico 6 (TC6, Data Communications) quien empez el trabajo
de normalizacin del correoelectrnico. Para ello cre, a finales de
los 70, un grupo de trabajo (WG6.5) para trabajar en ladefinicin de
un modelo de sistema de gestin de mensajes.
Este trabajo fue seguido por el entonces CCITT que, en 1984,
aprob las primeras recomendacionesinternacionales de mensajera
electrnica. A pesar de que se fueron descubriendo fallos
ylimitaciones, estas recomendaciones del CCITT tienen un mrito
innegable, especialmente teniendoen cuenta que es la primera norma
completamente desarrollada del nivel de aplicacin del modelo
dereferencia OSI.
La experiencia adquirida con estas recomendaciones y las
primeras implementaciones llevaron alCCITT a desarrollar una nueva
versin, aprobada en 1988, que corrige muchas de las limitaciones
dela versin del 84. En este trabajo tambin colabor ISO, lo que dio
lugar a una norma conjunta entreCCITT, Recomendaciones X.400 (MHS)
e ISO, Estndar Internacional MOTIS (Message OrientedText
Interchange Systems).
En los ltimos aos, 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
creacindel ISO/IEC JTC1.
Finalmente, despus de 1988 se han publicado nuevas versiones del
estndar que no cambiandemasiado la funcionalidad, pero que corrigen
y extienden algunas cosas. De hecho, existe una nuevarepublicacin
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 1985por ECMA (European Computer
Manufacturers Association) con el nmero ECMA-101, y el ttuloOpen
Document Architecture.
Seguidamente, ISO decidi que era necesario un estndar
internacional sobre representacin eintercambio de documentos, por
lo que empez a producir su propio estndar. Para ello, se considerla
norma de ECMA como documento de partida. De esta manera, tambin, se
pas de un mbitoeuropeo a uno ms internacional, en el que se debe
destacar la activa participacin 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 nmero 1 de
ISO y la IEC (ISO/IEC JTC1). Actualmente, el grupo de trabajonmero
3 del mencionado subcomit (es decir, ISO/IEC JTC1 SC18/WG3) es
quien tiene la totalresponsabilidad sobre el estndar y sus
extensiones.
La produccin del estndar ODA no es slo debida al trabajo de
ISO/IEC, sino que tambin elCCITT (y despus ITU-T), ha hecho suyo el
compromiso de la estandarizacin del intercambio dedocumentos, 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
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 tena el SC18, quien produjo esta primera
versin.
La versin del estndar publicada por el CCITT era prcticamente
idntica a la de ISO, aunque elCCITT usa una estructura diferente, y
en vez de tener un estndar con varias partes, tiene
variasRecomendaciones que forman una serie. En concreto, el nmero y
ttulo 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 ttulo del estndar est ya unificado, pues ISO decidi, ya en
1990, cambiar la palabra Office porOpen.
Actualmente, el trabajo de extensin del estndar que se est
efectuando, lo realiza un comitformado 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 desdeentonces.
-
22 Aplicaciones distribuidas abiertas
ODA 1994 tiene una nueva parte (aunque slo en la versin de
ISO/IEC, no en la de ITU-T), que esla 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 Nivel de aplicacin
2.1 Introduccin
El objetivo de los primeros captulos de este libro es presentar
los elementos tericos bsicos paraespecificar y disear aplicaciones
en las cuales se procese informacin de una forma distribuida.
Paraello es necesario disponer de una serie de funcionalidades
orientadas a resolver los problemasrelacionados con la distribucin.
Estos recursos los proporcionan los sietes niveles del modelo
deinterconexin de sistemas abiertos (OSI, Open Systems
Interconnection) de ISO.
- Los niveles inferiores del modelo OSI (niveles fsico, enlace,
red y transporte), o nivelesorientados a la comunicacin,
proporcionan los medios necesarios para la transmisin fiablede
datos.
- Los niveles superiores del modelo OSI (niveles sesin,
presentacin y aplicacin), o nivelesorientados a la aplicacin,
proporcionan una serie de servicios para la gestin ysincronizacin
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 necesariospara que una aplicacin pueda
gestionar informacin distribuida, facilitando los medios
adecuadospara acceder al resto de niveles.
En una aplicacin distribuida se pueden distinguir dos partes
diferenciadas: la aplicacinpropiamente dicha y la parte que realiza
el acceso a los recursos de comunicacin. Es este ltimoaspecto el
que diferencia una aplicacin local de su versin distribuida, y es
este aspecto del diseode aplicaciones distribuidas el que se trata
en los primeros captulos de este libro.
-
24 Aplicaciones distribuidas abiertas
2.2 Estructura del nivel de aplicacin
El propsito del nivel de aplicacin es servir como intermediario
entre procesos de aplicacin deusuario que estn utilizando los
recursos OSI para intercambiar informacin (vase la figura 2.1).
Se define un proceso de aplicacin (AP, Application Process) como
un elemento dentro de unsistema abierto que realiza el procesado
distribuido de informacin (es decir, que implicacomunicacin) para
una determinada aplicacin. Los procesos de aplicacin
intercambianinformacin por medio de entidades de aplicacin que
implementan protocolos de aplicacinutilizando servicios de
presentacin.
Una entidad de aplicacin (AE, Application Entity) define los
aspectos concernientes a lacomunicacin de un proceso de aplicacin.
Las entidades de aplicacin intercambian informacinpor medio de
unidades de datos del protocolo de aplicacin (APDU, Application
Protocol DataUnit) (vase la figura 2.2).
En el caso ms general, un proceso de aplicacin puede definir
varios tipos de intercambio deinformacin. Por lo tanto, su
comunicacin tendr varios aspectos que se implementarn
mediantediferentes AE. Para la mayor parte de las aplicaciones
distribuidas es suficiente una nica entidad deaplicacin.
Para que dos entidades de aplicacin puedan cooperar es necesario
establecer previamente unaasociacin de aplicacin o simplemente una
asociacin (Application Association). El concepto deasociacin en el
nivel de aplicacin equivale al concepto de conexin en el resto de
niveles delmodelo OSI. Una asociacin se mapea directamente sobre
una conexin de presentacin. La entidadde 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 (ResponderEntity).
Una entidad de aplicacin consta de un elemento de usuario (UE,
User Element) y un conjunto deelementos de servicio de aplicacin
(ASE, Application Service Element) (vase la figura 2.2).
Proceso Aplicacin
Usuario
Protocolo deaplicacinNivel de
aplicacin
Proceso Aplicacin
Usuario
Nivel de aplicacin
Proveedor del servicio de presentacin
Fig. 2.1 Procesos de aplicacin de usuario y nivel de
aplicacin
-
2 Nivel de aplicacin 25
El elemento de usuario (UE, User Element) representa aquella
parte de la entidad de aplicacin quecoordina los elementos de
servicio de aplicacin (ASE) necesarios para llevar a cabo los
objetivos decomunicacin de dicho proceso de aplicacin. Es decir,
gestiona los diferentes ASE que constituyendicha 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 unaentidad de aplicacin que
proporciona una funcin 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 ms que un conjunto de
funciones que permiten a las AE cooperar para un
determinadopropsito.
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 presentacin. En el nivel de aplicacin no se
puede hablar de un protocolo de aplicacinnico sino de un conjunto
de protocolos de aplicacin, uno para cada par de ASE residentes
enentidades de aplicacin remotas. Algunos ASE son obligatorios, es
decir, siempre deben formar partede cualquier entidad de aplicacin,
mientras que otros son opcionales. En OSI, el usuario del
serviciode presentacin es siempre un ASE.
Se define un contexto de aplicacin (AC, Application Context)
como el conjunto de servicios yprotocolos de aplicacin utilizados
por una entidad de aplicacin en una asociacin. Bsicamenteindica el
conjunto de ASE que componen el proceso de aplicacin definiendo
implcitamente losprotocolos (vase la figura 2.3).
Los ASE que constituyen una entidad de aplicacin pueden ser
iguales en los dos extremos y recibenel nombre de ASE simtricos, o
complementarios y reciben el nombre de ASE asimtricos. En losASE
asimtricos uno tiene el papel de consumidor o cliente y el otro el
papel de suministrador oservidor del servicio (vase el apartado
3.1.1 correspondiente a la arquitectura cliente/servidor).
Proceso Aplicacin
Usuario
Protocolos deaplicacin
Proceso Aplicacin
Usuario
AE
Conexin de presentacin
ASE1
ASEn
... ASE1
ASEn
...
UE
AE
UE
(APDU)
Fig. 2.2 Estructura de una entidad de aplicacin
-
26 Aplicaciones distribuidas abiertas
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 aplicacionesdistribuidas utilizan. Por esta razn se
crey conveniente estandarizarlos y se ofrecen como unrecurso comn
en los entornos de desarrollo de aplicaciones distribuidas. As el
diseador puedeutilizar 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 lasfuncionalidades concretas del sistema
distribuido que se est diseando y son la parte que diferenciaunas
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 entreentidades 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 tipopeticin/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 Aplicacin
Usuario
Protocolo deaplicacin
AE
Proceso Aplicacin
Usuario
Conexin de presentacin
UE
ASE
ROSE
ACSE
RTSE
AE
UE
ASE
ROSE
ACSE
RTSE
ASE ASE
Fig. 2.3 Estructura de un contexto de aplicacin
-
2 Nivel de aplicacin 27
La figura 2.3 ilustra el concepto de contexto de aplicacin. Se
puede observar que existe una relacinentre 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 unaentidad de aplicacin dentro del
entorno OSI. Para conseguirlo se utilizan, a nivel
dedireccionamiento, 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 elestablecimiento de la asociacin donde se
concreta el conjunto de protocolos que se van a utilizar enesa
asociacin.
El ttulo de un proceso de aplicacin (AP-Title, Application
Process Title) identifica un proceso deaplicacin concreto dentro
del entorno OSI.
Un calificador de entidad de aplicacin (AE-Qualifier,
Application Entity Qualifier) identifica unaentidad 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 deaplicacin 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 entidadde 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 deASN.1. A partir de la informacin de
direccionamiento de aplicacin, normalmente el AP-Title, sedebe
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 noestndar, o
normalizado utilizando el servicio de directorio estndar (X.500)
donde, a partir de unnombre distintivo, como AP-Title, es posible
obtener la direccin de presentacin. (vase el captulo5).
2.4 ACSE (Elemento de servicio de control de asociacin)
El elemento de servicio de control de asociacin (ACSE,
Association Control Service Element) es elencargado de suministrar
facilidades para la gestin de asociaciones entre entidades de
aplicacinque se comunican a travs de una conexin de presentacin. El
elemento de servicio comn ACSE es
-
28 Aplicaciones distribuidas abiertas
obligatorio, es decir, debe formar parte de cualquier entidad de
aplicacin. Existe unacorrespondencia uno a uno entre una conexin de
presentacin y una asociacin de aplicacin. Losestndares [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 depresentacin.
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 asociacin y es
un servicio confirmado (Fig.2.4). Mediante los parmetros del
servicio A-ASSOCIATE se especifica, entre otras cosas, elcontexto
de aplicacin, la lista de contextos de presentacin vlidos para cada
ASE y el contexto depresentacin por defecto para una asociacin
determinada.
El servicio A-ASSOCIATE tiene los siguientes parmetros:
- modo: normal o X.410-1984- contexto de aplicacin- ttulo de la
entidad de aplicacin 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
-
2 Nivel de aplicacin 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 quehace
referencia a la opcionalidad.
El parmetro modo selecciona entre un modo de funcionamiento de
ACSE normal, que adems esel valor por defecto, y un modo de
funcionamiento especfico para mensajera electrnica. Con elparmetro
contexto de aplicacin, el iniciador de la asociacin propone un
contexto de aplicacinpara la asociacin que solicita. A continuacin
hay una serie de parmetros donde se identifican lasentidades de
aplicacin que inicia y acepta la asociacin. El ttulo de la entidad
de aplicacinconsta del ttulo del proceso de aplicacin y el
calificador de la entidad de aplicacin. El campo deinformacin de
usuario lo pueden utilizar indistintamente las dos entidades para
incluirinformacin (por ejemplo, credenciales de autenticacin,
etc.). El parmetro resultado contieneinformacin relativa al
resultado de la negociacin del establecimiento de la asociacin:
aceptada,rechazada de forma transitoria o rechazada de forma
permanente. El parmetro diagnstico indicala causa del rechazo de la
asociacin si as lo indica el parmetro resultado; los valores pueden
serno existe razn aparente, contexto de aplicacin no soportado y
ttulo de la entidad de aplicacininiciadora o llamada desconocido.
El resto son parmetros relacionados con los niveles depresentacin 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
A-ASSOCIATE.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 unaasociacin sin prdida de
informacin en trnsito (Fig. 2.5). La liberacin de una asociacin
puedeiniciarla cualquiera de las dos entidades de aplicacin.
-
30 Aplicaciones distribuidas abiertas
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 losvalores normal, urgente o
definido por el usuario, pero si es un parmetro de la primitiva
A-RELEASE.response, los valores posibles son: normal, no finalizada
o definida por el usuario. Elparmetro resultado lo utiliza la
entidad de aplicacin que acepta la asociacin para indicar
laaceptacin 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. Esun servicio no confirmado (Fig.
2.6).
Proveedor ACSEUsuario ACSE Usuario ACSE
A-RELEASE.request
A-RELEASE.confirm
A-RELEASE.indication
A-RELEASE.response
Fig 2.5 Primitivas del servicio A-RELEASE de ACSE
Proveedor ACSEUsuario ACSE Usuario ACSE
A-ABORT.request
A-ABORT.indication
Fig. 2.6 Primitivas del servicio A-ABORT de ACSE
-
2 Nivel de aplicacin 31
Los parmetos de las primitivas del servicio A-ABORT son los
siguientes:
- Origen del aborto: usuario de ACSE o proveedor del servicio
ACSE- Informacin de usuario
El primer parmetro, como su nombre indica, contiene informacin
del origen de la liberacin. Elcampo de informacin de usuario pueden
utilizarlo las entidades de aplicacin para incluirinformacin cuyo
significado depende del contexto de aplicacin.
El servicio A-ABORT se mapea directamente sobre el servicio
P-U-ABORT de presentacin. Unavez generada la primitiva
A-ABORT.request, para el iniciador la asociacin ha sido liberada.
Elproveedor del servicio ACSE puede utilizar el servicio A-ABORT
para liberar una asociacin porproblemas internos del protocolo de
aplicacin.
A-P-ABORT
El servicio A-P-ABORT se utiliza para liberar una asociacin 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 liberacin de la
asociacin anmala,normalmente debida a problemas en los niveles
inferiores. Esta situacin puede originar prdida deinformacin en
trnsito.
El nico parmetro 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 depresentacin.
Proveedor ACSEUsuario ACSE Usuario ACSE
A-P-ABORT.indication A-P-ABORT.indication
Figura 2.7 Primitivas del servicio A-P-ABORT de ACSE
-
32 Aplicaciones distribuidas abiertas
2.4.2 Protocolo
El protocolo ACSE describe la transferencia de informacin entre
entidades de aplicacin para lagestin 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 A-ASSOCIATE-REQUESTAARE A-ASSOCIATE-RESPONSERLRQ
A-RELEASE-REQUESTRLRE A-RELEASE-RESPONSEABRT A-ABORT
La fase de establecimiento de una asociacin utiliza las APDU
AARQ y AARE, la fase de liberacinnormal 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 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
mquina 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 comn RTSE (Reliable Transfer Service
Element) es el encargado desuministrar facilidades para la
transferencia de APDU de gran tamao, garantizando la recepcinntegra
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 elencargado de
manejar el elemento de servicio ACSE para la gestin de
asociaciones, y del nivel de
-
2 Nivel de aplicacin 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 duranteel proceso de transmisin de la
informacin, minimizando el nmero de retransmisiones. De estaforma,
libera al diseador de aplicaciones distribuidas de tener que
preocuparse por la gestin de lasfacilidades que suministra sesin, a
travs de presentacin, 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 mnimo del subconjunto
bsico de actividades de sesin (BAS) accesible a travs del
serviciode 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 yactividades.
Los servicios que suministra RTSE son los siguientes:
Servicio TipoRT-OPEN ConfirmadoRT-TRANSFER Confirmado (Slo
solicitud, indicacin y confirmacin)RT-TURN-PLEASE No
confirmadoRT-TURN-GIVE No confirmadoRT-CLOSE ConfirmadoRT-U-ABORT
No confirmadoRT-P-ABORT No confirmado (Slo indicacin)
RT-OPEN
El servicio RT-OPEN, que es confirmado, utiliza el elemento de
servicio ACSE para establecer unaasociacin, 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
-
34 Aplicaciones distribuidas abiertas
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 deldilogo, que puede ser monlogo, es
decir, que nicamente la entidad que est inicialmente enposesin del
turno puede transmitir APDU, o TWA, donde las dos entidades pueden
hacerloalternativamente siempre y cuando estn en posesin del turno,
el cual puede intercambiarse. Otroparmetro nuevo es el turno
inicial, que lo puede poseer la entidad que inicia o la que
responde laasociacin. El parmetro protocolo de aplicacin slo tiene
sentido en el modo X.410-1984 (vaseel apartado 2.4 relacionado con
ACSE). El parmetro datos de usuario se puede utilizar paraalmacenar
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 aACSE.
RT-TRANSFER
El servicio RT-TRANSFER lo utiliza el usuario de RTSE que est en
posesin del turno paratransmitir APDU de forma fiable mediante una
asociacin de aplicacin. Normalmente, los serviciosconfirmados
constan de cuatro primitivas; en cambio, el servicio RT-TRANSFER
slo tiene tresprimitivas (vase la figura 2.9). La razn es que una
APDU se transmite dentro de una actividad, porlo que la finalizacin
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 (vase el apartado 2.5.2
correspondiente al protocolo RTSE).
Los parmetros del servicio RT-TRANSFER son:
- APDU a transmitir
Proveedor RTSEUsuario RTSE Usuario RTSE
RT-TRANSFER.request
RT-TRANSFER.confirmation
RT-TRANSFER.indication
Fig. 2.9 Primitivas del servicio RT-TRANSFER de RTSE
-
2 Nivel de aplicacin 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 mximoestimado 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 confirmacin con la
primitiva RT-TRANSFER.confirmation. El parmetroresultado contiene
informacin 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 utilizacin de una serie
de servicios de presentacin quehacen posible que la transferencia
de APDU se realice dentro de una actividad (vase 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 deaplicacin 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 asociacinpara liberarla.
El servicio RT-TURN-PLEASE slo tiene un parmetro, que es la
prioridad asociada a la accinpara la que se solicita el turno. Con
esta informacin, el usuario de RTSE remoto puede decidircundo
entrega el turno. La prioridad cero indica la prioridad ms alta y
se reserva para liberar laasociacin.
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 deaplicacin entregar el turno al
usuario de RTSE remoto, siempre y cuando est en posesin del
turno
Proveedor RTSEUsuario RTSE Usuario RTSE
RT-TURN-PLEASE.request
RT-TURN-PLEASE.indication
Fig. 2.10 Primitivas del servicio RT-TURN-PLEASE de RTSE
-
36 Aplicaciones distribuidas abiertas
y no est pendiente de la finalizacin de un servicio de
transferencia de APDU (RT-TRANSFER)(vase la figura 2.11).
El servicio RT-TURN-GIVE no tiene parmetros y se mapea
directamente sobre el servicio depresentacin P-CONTROL-GIVE.
RT-CLOSE
El servicio RT-CLOSE, que es confirmado, permite al usuario de
RTSE liberar de forma ordenadauna asociacin de aplicacin (vase la
figura 2.12). La liberacin slo puede realizarla el usuario deRTSE
de la entidad iniciadora de la asociacin cuando est en posesin del
turno y no tienependiente la finalizacin de una transferencia de
APDU (recepcin de RT-TRANSFER.confirmation). El usuario de RTSE de
la entidad de aplicacin que responde laasociacin no puede rechazar
la liberacin.
Los parmetros de las primitivas del servicio RT-CLOSE son:
- Causa de la liberacin- Informacin de usuario
Estos parmetros nicamente tienen sentido en modo de operacin
normal, ya que en modo X.410-1984 no existen parmetros.
Proveedor RTSEUsuario RTSE Usuario RTSE
RT-TURN-GIVE.request
RT-TURN-GIVE.indication
Fig. 2.11 Primitivas del servicio RT-TURN-GIVE de RTSE
Proveedor RTSEUsuario RTSE Usuario RTSE
RT-CLOSE.request
RT-CLOSE.confirmation
RT-CLOSE.indication
RT-CLOSE.response
Fig. 2.12 Primitivas del servicio RT-CLOSE de RTSE
-
2 Nivel de aplicacin 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 deforma abrupta, y utiliza los
servicios equivalentes de ACSE. El servicio RT-U-ABORT es un
serviciono confirmado (vase la figura 2.13).
El servicio RT-U-ABORT slo tiene un parmetro, que es un campo de
informacin del usuario quese 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 unainiciativa del proveedor del servicio
RTSE y, como en el caso anterior, lo hace utilizando el
servicioequivalente de ACSE A-P-ABORT (vase la figura 2.14). El
proveedor del servicio informa a los dosusuarios de RTSE que le es
imposible mantener la asociacin de aplicacin.
El servicio RT-P-ABORT, que no tiene parmetros, 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.
Proveedor RTSEUsuario RTSE Usuario RTSE
RT-U-ABORT.request
RT-U-ABORT.indication
Fig. 2.13 Primitivas del servicio RT-U-ABORT de RTSE
Proveedor RTSEUsuario RTSE Usuario RTSE
RT-P-ABORT.indication RT-P-ABORT.indication
Fig. 2.14 Primitivas del servicio RT-P-ABORT de RTSE
-
38 Aplicaciones distribuidas abiertas
2.5.2 Protocolo
La mquina 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 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 RT-OPEN-REQUESTRTOAC RT-OPEN-ACCEPTRTORJ
RT-OPEN-REJECTRTTR RT-TRANSFERRTTP RT-TOKEN-PLEASERTAB RT-P-ABORT y
RT-U-ABORT
A continuacin 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 presentacin
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 tamao
que se habr negociado en la fase de establecimiento de laasociacin
(espaciado entre puntos de sincronizacin). Para poder fraccionar la
APDU primero esnecesario serializar la informacin, para lo cual, la
mquina de protocolo de RTSE deber obtener lasintaxis de
transferencia y entregar cada fragmento al servicio de presentacin.
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 presentacin mediante tantas primitivas del servicio P-DATA como
seanecesario. Con el objeto de facilitar las retransmisiones en
caso de problemas, se va marcando latransmisin con puntos de
sincronizacin menor (servicio P-MINOR-SYNC). El nmero de puntos
-
2 Nivel de aplicacin 39
de sincronizacin que pueden existir sin confirmar se negocia
tambin en la fase de establecimientode la asociacin (tamao de la
ventana). La utilizacin de actividades a nivel de
presentacinjustifica 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
presentacin 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 noaportara nada respecto a la transmisin de la APDU, pero
en cambio introducira redundancia en latransmisin. En la figura
2.15 se ilustra grficamente la relacin entre la utilizacin por un
usuariode RTSE del servicio RT-TRANSFER para transmitir una APDU, y
los servicios de presentacinnecesarios para transmitirla dentro de
una actividad.
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 paraobtener una sintaxis de
transferencia es una funcin del nivel de presentacin. En cambio se
ha dichoque 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
desistemas 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 lasprimitivas de presentacin, as como
tambin las APDU que las transportan.
Primitiva RTSE APDU Primitiva
PresentacinRT-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
-
40 Aplicaciones distribuidas abiertas
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 comn del nivel de aplicacin es
ROSE (Remote Operations ServiceElement), que se utiliza para
implementar aplicaciones distribuidas interactivas del
tipopeticin/respuesta (paradigma cliente/servidor). Una entidad de
aplicacin invoca la operacinremota (invoker entity) y la otra la
realiza y genera un resultado (performer entity). El mecanismo
deoperaciones 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 delresultado de la
operacin 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 operacin no se haya
podido ejecutar por alguna razn, en ese caso la respuesta ser un
rechazo(vase la figura 2.16).
Las operaciones remotas se pueden clasificar segn dos modos de
funcionamiento llamados modosncrono y modo asncrono. El modo
sncrono consiste en la posibilidad de invocar las operacionesde
forma secuencial, de forma que, cuando se lanza una operacin remota
en modo sncrono, no sepuede lanzar la siguiente hasta que no se ha
recibido su correspondiente respuesta. En modoasncrono se pueden
lanzar varias operaciones remotas sin necesidad de esperar las
respectivasrespuestas, 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 deoperacin que utilizan y el tipo
de resultado que generan. La operacin clase 1 utiliza modo sncronoy
genera siempre una respuesta, ya sea resultado o error. La operacin
clase 2 utiliza modo asncronoy genera siempre una respuesta. La
operacin clase 3 utiliza modo asncrono y slo genera un error
siexiste, y si se ejecuta correctamente no genera ninguna
respuesta. Las operaciones clase 4 utilizanmodo asncrono y slo
generan un resultado, mientras que las de clase 5, que tambin
utilizan modoasncrono, no devuelven ninguna respuesta en ningn caso
(vase la figura 2.17).
Invocaoperacinremota
AE AEInvocacin
ResultadoRechazo
Error
Realizaoperacin
remota
Fig 2.16 Modelo funcional para ROSE
-
2 Nivel de aplicacin 41
En algunos casos es til disponer de la posibilidad de agrupar
operaciones de forma que unaoperacin inicial, llamada operacin
padre, desencadene como respuesta nuevas operacionesllamadas
operaciones hijas. Se dice que las operaciones hijas estn enlazadas
("linked") con laoperacin padre (vase 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
InvocacinRespuesta
Invocaciones
Respuestas
Invocaciones
Error
Invocaciones
Resultado
Invocaciones
AEInvocacinRespuesta
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 AEinvocacin deoperacin padre
invocacin deoperacin hija
invocacin deoperacin hija
ejecuta la operacin padre
ejecucin de operacin
padre
Fig 2.18 Operaciones remotas enlazadas
-
42 Aplicaciones distribuidas abiertas
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 unaoperacin remota que deber ejecutar
el usuario de ROSE remoto (vase la figura 2.19).
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 queser el mismo para los dos
usuarios de ROSE. El argumento "clase de la operacin" sirve para
saber sise utiliza modo sncrono o asncrono y el tipo de respuesta
esperada (resultado, error o rechazo); suuso 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 dela invocacin" sirve para
asociar una respuesta a una invocacin cuando se trabaja en
modoasncrono o para el caso de que existan operaciones enlazadas (o
hijas). El parmetro "identificadorde la operacin enlazada", que es
opcional, si existe significa que la operacin invocada es
unaoperacin hija y se utiliza para indicar la operacin padre. El
parmetro "prioridad" se utiliza paraasignar una escala de
prioridades a las diferentes transferencias de APDU entre las
entidades deaplicacin.
El servicio RO-INVOKE de ROSE se mapea directamente sobre el
servicio P-DATA del nivel depresentacin.
Proveedor ROSEUsuario ROSE Usuario ROSE
RO-INVOKE.request
RO-INVOKE.indication
Fig. 2.19 Primitivas del servicio RO-INVOKE de ROSE
-
2 Nivel de aplicacin 43
RO-RESULT
El servicio RO-RESULT lo utiliza el usuario de ROSE que ejecuta
la operacin para devolver elresultado de la operacin solicitada en
el caso de que sta se haya ejecutado con xito. Es un serviciono
confirmado (vase la figura 2.20).
Los parmetros del servicio RO-RESULT son los siguientes:
- Identificador de la operacin- Resultado- Identificador de la
invocacin- Prioridad
Los parmetros de las primitivas del servicio RO-RESULT,
"identificador de la operacin" e"identificador de la invocacin",
son los mismos que se han estudiado en la invocacin de laoperacin
con el servicio RO-INVOKE. Como su nombre indica, el parmetro
"resultado" contieneel 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 depresentacin.
RO-ERROR
El servicio RO-ERROR, que es un servicio no confirmado, lo
utiliza el usuario de ROSE que ejecutala operacin para indicar al
usuario que invoca la operacin solicitada que se ha ejecutado
conerrores (vase la figura 2.21).
Los parmetros del servicio RO-RESULT son los siguientes:
- Identificador del error- Parmetro del error- Identificador de
la invocacin- Prioridad
Proveedor ROSEUsuario ROSE Usuario ROSE
RO-RESULT.request
RO-RESULT.indication
Fig. 2.20 Primitivas del servicio RO-RESULT de ROSE
-
44 Aplicaciones distribuidas abiertas
El parmetro "identificador del error" identifica el tipo de
error que se ha producido al ejecutar laoperacin y en el parmetro
"parmetro del error" el usuario de ROSE puede incluir
informacinadicional respecto al error. Los parmetros "identificador
de la invocacin" y "prioridad" son losmismos 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 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
operacin remota solicitada mediante el servicio RO-INVOKE,
aldetectar algn tipo de problemas (vase la figura 2.22). Tambin se
puede utilizar este servicio pararechazar una respuesta (resultado
o error) de una invocacin anterior.
Los parmetros de las primitivas del servicio RO-REJECT-U son los
siguientes:
- Causa del rechazo- Identificador de la invocacin-
Prioridad
Los parmetros "identificador de la invocacin" y "prioridad" son
los mismos que se han visto en ladescripcin de los otros servicios
de ROSE. El parmetro "causa del error" contiene informacin
Proveedor ROSEUsuario ROSE Usuario ROSE
RO-ERROR.request
RO-ERROR.indication
Fig. 2.21 Primitivas del servicio RO-ERROR de ROSE
Proveedor ROSEUsuario ROSE Usuario ROSE
RO-REJECT-U.request
RO-REJECT-U.indication
Fig 2.22 Primitivas del servicio RO-REJECT-U de ROSE
-
2 Nivel de aplicacin 45
diferente segn 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: invocacin duplicada,
operacin desconocida, argumento errneo, recursoslimitados,
liberacin del iniciador de la asociacin, identificador de la
operacin enlazadadesconocido, respuesta de la operacin enlazada no
esperada y operacin hija no esperada. En elcaso 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 rechazocorresponde a una primitiva
RO-ERROR.indication, las causas de rechazo son:
invocacindesconocida, 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 depresentacin.
RO-REJECT-P
El servicio RO-REJECT-P lo utiliza el proveedor del servicio
ROSE para indicar a sus usuarios queha detectado algn tipo de
problema. Es un servicio no confirmado que, al ser iniciado por
elproveedor, nicamente tiene una primitiva que es
RO-REJECT-P.indication (vase la figura 2.23).
Los parmetros de las primitivas del servicio RO-REJECT-P son los
siguientes:
- Causa del rechazo- Identificador de la invocacin- Parmetros
retornados
Los parmetros de la primitiva RO-REJECT-P.indication, que son
todos opcionales, son elidentificador de la invocacin, la causa del
rechazo y un campo de parmetros del rechazo quecontiene el parmetro
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 errnea o estructura de
la APDU errnea.
El servicio RO-REJECT-P de ROSE se mapea directamente a nivel de
presentacin mediante elservicio P-DATA.
Proveedor ROSEUsuario ROSE Usuario ROSE
RO-REJECT-P.indication RO-REJECT-P.indication
Fig. 2.23 Primitivas del servicio RO-REJECT-P de ROSE
-
46 Aplicaciones distribuidas abiertas
2.6.2 Protocolo
El protocolo ROSE queda definido por la mquina de protocolo de
ROSE (ROPM, RemoteOperations Protocol Machine). Se pueden
identificar una serie de elementos de protocolo que son
lossiguientes:
- Invocacin- 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 continuacin se muestra el mapeo entre las primitivas de
servicio de ROSE y el servicio depresentacin, as como las APDU que
se utilizan para transportar dichas primitivas.
Servicio ROSE APDU Servicio
presentacinRO-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
COPY: 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.copy: 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.