merged (7)

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


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.


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.


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.


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


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


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


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


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


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


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


A-RELEASE.request

A-RELEASE.confirm

A-RELEASE.indication

A-RELEASE.response

Fig 2.5 Primitivas del servicio A-RELEASE de ACSE


A-ABORT.request

A-ABORT.indication

Fig. 2.6 Primitivas del servicio A-ABORT de ACSE


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


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

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


2.4.2 Protocolo

El protocolo ACSE describe la transferencia de 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


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


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


RT-TRANSFER.request

RT-TRANSFER.confirmation

RT-TRANSFER.indication

Fig. 2.9 Primitivas del servicio RT-TRANSFER de RTSE


- 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


RT-TURN-PLEASE.request

RT-TURN-PLEASE.indication

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


y no est pendiente de la 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.


RT-TURN-GIVE.request

RT-TURN-GIVE.indication

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


RT-CLOSE.request

RT-CLOSE.confirmation

RT-CLOSE.indication

RT-CLOSE.response

Fig. 2.12 Primitivas del servicio RT-CLOSE de RTSE


El servicio RT-CLOSE de RTSE se mapea directamente sobre el servicio A-RELEASE de ACSE,que a su vez se mapea sobre el servicio P-RELEASE de 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.


RT-U-ABORT.request

RT-U-ABORT.indication

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


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

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


2.5.2 Protocolo

La 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


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


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


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


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


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


RO-RESULT.request

RO-RESULT.indication

Fig. 2.20 Primitivas del servicio RO-RESULT de ROSE


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


RO-ERROR.request

RO-ERROR.indication

Fig. 2.21 Primitivas del servicio RO-ERROR de ROSE


RO-REJECT-U.request

RO-REJECT-U.indication

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


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


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

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


2.6.2 Protocolo

El protocolo ROSE queda definido por la 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.

Documents

merged (7)