Contribuci on a la especificaci on y gesti on integrada de la calidad

UNIVERSIDAD DE VALLADOLID
Dpto. de Teora de la Se~nal, Comunicaciones e Ing. Telematica
Escuela Tecnica Superior de Ingenieros de Telecomunicacion
Proyecto de Tesis Doctoral
Contribucion a la especicacion y
gestion integrada de la calidad de
servicio en aplicaciones de objetos
distribuidos
AUTOR
Juan Ignacio Asensio Perez
Ingeniero de Telecomunicacion
DIRECTOR
Vctor A. Villagra Gonzalez
Dr. Ingeniero de Telecomunicacion
Febrero de 2000
2
Indice General
1 Introduccion
5
2 A mbito de la Tesis: La gestion integrada de la calidad de servicio en
aplicaciones de objetos distribuidos
9
2.1
2.2
2.3
2.4
Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Las aplicaciones de objetos distribuidos . . . . . . . . . . . . . . . . . . . .
El concepto de Gestion Integrada: arquitecturas y evolucion . . . . . . . . .
La gestion integrada y las plataformas de procesamiento distribuido orientado a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Las plataformas de procesamiento distribuido orientado a objetos
como plataformas de gestion integrada . . . . . . . . . . . . . . . . .
2.4.2 La gestion integrada de aplicaciones de objetos distribuidos . . . . .
2.5 La Calidad de Servicio: concepto y arquitecturas . . . . . . . . . . . . . . .
2.6 La Calidad de Servicio en las aplicaciones de objetos distribuidos: QoS en
ODP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Motivaciones de la Tesis Doctoral propuesta
9
9
14
18
18
24
25
30
35
3.1 La especicacion de informacion de la calidad del servicio en aplicaciones
de objetos distribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2 La instrumentacion de mecanismos de monitorizacion de la calidad de servicio en aplicaciones de objetos distribuidos . . . . . . . . . . . . . . . . . . 39
4 Objetivos de la Tesis Doctoral propuesta
43
5 Descripcion de las aportaciones de la tesis doctoral propuesta
45
Referencias
48
3
Indice General
4
Captulo 1
Introduccion
El objetivo de este documento es presentar la motivacion y objetivos de la tesis doctoral
propuesta que aborda el problema de la especicacion y gestion integrada de la calidad
de servicio 1 en aplicaciones soportadas por plataformas de procesamiento distribuido
orientado a objetos.
La tecnologa de las plataformas de procesamiento distribuido orientado a objetos
permite desarrollar aplicaciones distribuidas ocultando la complejidad inherente a la heterogeneidad de los recursos que les dan soporte. Esta tecnologa, que se encuadra dentro
de la mas generica de los denominados servicios \Middleware", se esta revelando tambien como una solucion potente y exible para la integracion de aplicaciones centralizadas
heterogeneas en nuevas aplicaciones distribuidas, lo cual permite una maximizacion del
rendimiento de las inversiones realizadas.
Por otra parte, el caracter competitivo y dinamico que caracteriza el entorno en el que
se ofrecen los servicios basados en las \Tecnologas de la Informacion" hace imprescindible
la utilizacion de unas herramientas adecuadas de gestion integrada que permitan el control
y la vigilancia de todos los recursos involucrados en la provision de dichos servicios con
una adecuada \Calidad de Servicio".
La tesis doctoral propuesta se encuadra dentro de este contexto (ver gura 1.1) e
intenta contribuir a su desarrollo mediante la propuesta de:
Un lenguaje para la especicacion de la informacion relacionada con los aspectos
de Calidad de Servicio que se desean gestionar integradamente en una aplicacion de
objetos distribuidos.
Un conjunto de soluciones genericas, particularizables para diferentes arquitecturas
de gestion integrada y procesamiento distribuido, que faciliten la instrumentacion
de mecanismos de monitorizacion QoS en aplicaciones de objetos distribuidos.
Este documento se estructura de la siguiente manera: en primer lugar se repasa el
estado del arte de las tres disciplinas que constituyen el contexto de la tesis doctoral
propuesta (aplicaciones de objetos distribuidos, gestion integrada y Calidad de Servicio)
posteriormente se identican los puntos concretos en los que la tesis doctoral propuesta
1
QoS o Quality of Service.
5
Captulo 1. Introduccion
GESTIÓN INTEGRADA
Aplic. DE OBJETOS
DISTRIBUIDOS
SNMP
O SI/TMN
DMI
...
QoS
Red
Sistema
Middlew are
Aplicación
...
CO RBA/CCM
JavaRMI/EJB
CO M+/MTS
RM−O DP
...
LA GESTIÓN INTEGRADA Y LAS
Aplic. DE OBJETOS DISTRIBUIDOS
QoS EN APLICACIONES
DE OBJETOS DISTRIBUIDOS
Nuevas Arquitecturas
O DMA
CO RBA
JMX
...
Intero perabilidad
JIDM
CIM
...
Instru mentación
Q o S en O DP
Vocabulario
Arq uitectura
Funciones
Lenguajes
OBJETIVOS DE LA TESIS DOCTORAL PROPUESTA
Facilitar la instrumentación de
mecanismos de monitorización
de QoS es Aplic. de Objetos
Distribuidos y su instrumentación
Facilitar la especificación de
información QoS es aplicaciones
de objetos distribuidos
CONTRIBUCIONES
Lenguaje de
especificación de
información QoS en
aplicaciones genéricas
de objetos distribuidos
Patrones para
instrumentación de
mecanismos de
monitorización de QoS en
aplicaciones genéricas
de objetos distribuidos
CASO DE ESTUDIO
Gestión QoS de aplicación
de intermediación
electrónica (proyecto ABS)
BASADAS EN
Perfiles UML
OCL
RM−ODP
QoS en ODP
Figura 1.1: Contexto de la Tesis Doctoral propuesta
6
Patrones
Software
pretende contribuir (especicacion de informacion de calidad de servicio e instrumentacion
de mecanismos de monitorizacion de esta en aplicaciones de objetos distribuidos) y se
hace un repaso detallado a las principales propuestas existentes relacionadas con ellos por
ultimo se detallan las caractersticas principales de las contribuciones que la tesis doctoral
propuesta pretende aportar.
7
Captulo 1. Introduccion
8
Captulo 2
A mbito de la Tesis: La gestion
integrada de la calidad de servicio
en aplicaciones de objetos
distribuidos
2.1 Introduccion
El proposito de este captulo es introducir, describir, analizar y comparar los tres principales temas que aborda la tesis doctoral propuesta con el doble objetivo de mostrar las
motivaciones que han guiado su desarrollo y poder se~nalar en que contexto se situan sus
aportaciones. Estos tres aspectos son: las aplicaciones de objetos distribuidos (seccion 2.2),
la gestion integrada (seccion 2.3) y la calidad de servicio (seccion 2.5). Para proporcionar
una descripcion completa del ambito de la tesis doctoral propuesta, tambien se describe
cual ha sido, y sigue siendo, la inuencia de las aplicaciones de objetos distribuidos en la
gestion integrada (seccion 2.4) y que particularidades caracterizan la gestion de la calidad
de servicio de este tipo de aplicaciones (seccion 2.6).
2.2 Las aplicaciones de objetos distribuidos
La creciente integracion de la Informatica y las Telecomunicaciones, caracterstica propia de las \Tecnologas de la Informacion", ha trado consigo una rapida proliferacion de
las denominadas aplicaciones distribuidas: aplicaciones que ofrecen servicios basados en
la interoperabilidad de multiples componentes software que se ejecutan en sistemas informaticos interconectados mediante redes de comunicacion. Las aplicaciones distribuidas
ofrecen un importante numero de ventajas con respecto a las aplicaciones centralizadas
\tradicionales": comparticion de recursos, tolerancia a fallos, escalabilidad, etc 118]. El
inconveniente de las aplicaciones distribuidas es que sus desarrolladores tienen que hacer
frente a la heterogeneidad de los recursos de transmision, procesamiento y almacenamiento
de datos en los que se basa el funcionamiento de estas aplicaciones: diferentes tecnologas
de red, protocolos de comunicaciones, sistemas operativos, gestores de bases de datos, etc.
9
Captulo 2. Ambito
de la Tesis: La gestion integrada de la calidad de servicio en
aplicaciones de objetos distribuidos
Para hacer frente a este problema, ha surgido el concepto de \Middleware"
172, 214, 31]. Con el termino \Middleware" se engloba a todo aquel servicio que, en
mayor o menor medida, oculta a los componentes integrantes de las aplicaciones distribuidas la heterogeneidad de los recursos de comunicacion, procesamiento y almacenamiento
que han de utilizar 131]. Los servicios \Middleware" se estan revelando como una solucion adecuada para la integracion de diferentes aplicaciones \monolticas" en entornos
distribuidos.
Los servicios \Middleware" se pueden agrupar en cinco grandes categoras 3] en funcion del tipo de interacciones que se van a producir entre los componentes de las aplicaciones distribuidas a las que van a dar soporte. As pues, se puede hablar de \Middleware"
orientado a mensajes, orientado a objetos, orientado a transacciones, orientado a bases de
datos y orientado a llamada a procedimientos remotos.
A la agrupacion de servicios \Middleware" se le denomina \Plataforma de Procesamiento Distribuido". El interes de la tesis doctoral propuesta se centra en el tipo de
\Plataforma de Procesamiento Distribuido" de mayor importancia en la actualidad: el de
las \Plataformas de Procesamiento Distribuido Orientado a Objetos" (DOP o Distributed
Objects Platforms). Como su propio nombre indica, estas plataformas tienen como objetivo
dar soporte a aplicaciones distribuidas cuyas entidades integrantes son \objetos". Estas
aplicaciones reciben el nombre de \aplicaciones de objetos distribuidos" y disfrutan de
las conocidas ventajas del paradigma de orientacion a objetos: modularidad, reutilizacion,
escalabilidad, etc. 215]
Varias arquitecturas de plataformas de objetos distribuidos compiten actualmente
por hacerse con el papel predominante en el ambito de la tambien denominada DOC
(Distributed Object Computing o Procesamiento de Objetos Distribuidos). Todas ellas se
pueden considerar, en mayor o menor medida, realizaciones concretas del denominado
\Modelo de Referencia para el Procesamiento Distribuido Orientado Abierto" (RM-ODP
o Reference Model for Open Distributed Processing) 145, 139, 138, 144], el conjunto de
estandares que ITU-T e ISO vienen desarrollando desde 1989 y que tratan de reunir
y unicar los principales conceptos empleados en el mundo de los sistemas DOC (los
denominados \sistemas de procesamiento distribuido abierto" segun la terminologa RMODP), de desarrollar un vocabulario comun a partir de estos conceptos e identicar las
funcionalidades imprescindibles en una plataforma de procesamiento distribuido orientado
a objetos \ideal". RM-ODP trata de denir un marco de trabajo estandar de alto nivel
de abstraccion 211] que permita describir y comparar cualquier sistema o plataforma
de procesamiento distribuido de manera similar a como lo intento hacer el modelo de
referencia OSI (Open Systems Interconnection o Interconexion de Sistemas Abiertos) 132]
con las arquitecturas de comunicacion 25]. RM-ODP surgio con el proposito de evitar
que las diferentes iniciativas (ANSA 1 y DCE 2 eran las mas importantes a principios de
Advanced Networked Systems Architecture o Arquitectura de Sistemas de Red Avanzados 240]. ANSA es una arquitectura para el procesamiento distribuido orientado a objetos en entornos heterogeneos
que tiene sus orgenes en el proyecto ISA del antiguo programa ESPRIT II de la Union Europea y que
fue desarrollada, durante los primeros a~nos 90, bajo la supervision de la organizacion APM (Arquitecture
Projects Management o Gestion de Proyectos de Arquitectura). En los ultimos a~nos, APM ha hecho evolucionar ANSA 120] hacia la denominada \Arquitectura Multimedia Interactiva Distribuida" o DIMMA
(Distributed Interactive Multi-Media Architecture) 182], una arquitectura experimental de procesamiento
distribuido dise~nada con el objetivo de dar soporte a aplicaciones con caractersticas multimedia. DIMMA
es compatible con la arquitectura OMA/CORBA (descrita posteriormente).
2
Distributed Computing Environmente o Entorno de Computacion Distribuida 105]. DCE es una arquitectura de procesamiento distribuido desarrollada por OSF (Open Software Foundation o Fundacion
de Software Abierto actualmente integrada en el denominado \Open Group") basada en la agrupacion
1
10
2.2. Las aplicaciones de objetos distribuidos
los a~nos 90) para solventar el problema de la heterogeneidad de recursos de comunicacion
y procesamiento en el desarrollo de aplicaciones distribuidas trajesen consigo un nuevo
problema: el de la heterogeneidad de las plataformas de procesamiento distribuido 249, 23].
Entre las principales contribuciones de RM-ODP, hay que destacar 172]:
La prescripcion de cinco perspectivas en las que dividir la especicacion de un sistema de procesamiento distribuido para, de esa forma, simplicar la descripcion
de sistemas complejos. La gura 2.1 muestra, al relacionarlas con las fases tpicas
del desarrollo software, de que nivel de abstraccion se ocupa cada una de las cinco
perspectivas de RM-ODP 211].
Un conjunto de conceptos generales sobre los que basar la especicacion de sistemas
de procesamiento distribuido desde las cinco perspectivas anteriormente mencionadas.
Un modelo para una infraestructura que proporcione soporte a esos conceptos generales utilizados para la especicacion de sistemas de procesamiento distribuido.
EMPRESA
INFORMACIÓN
ANÁLISIS DE REQUISITOS
COMPUTACIONAL
INGENIERÍA
TECNOLOGÍA
ESPECIFICACIÓN FUNCIONAL
DISEÑO
IMPLEMENTACIÓN
Figura 2.1: Las perspectivas de ODP y su relacion con las fases de desarrollo software
211].
RM-ODP sienta las bases para trabajos posteriores en tres tipos fundamentales de
estandares:
de varias tecnologas que, inicialmente, eran independientes: tomando como base un sistema de \llamada
a procedimiento remoto" o RPC (Remote Procedure Call), DCE incorpora un servicio de directorio, un
servicio de seguridad, un servicio de cheros distribuidos y otros servicios que facilitan la interoperabilidad
entre componentes software distribuidos. DCE no incorpora todos los principios tpicos de la orientacion
a objetos y se le puede considerar \descendiente de la escuela procedimental" 187].
11
Captulo 2. Ambito
de la Tesis: La gestion integrada de la calidad de servicio en
aplicaciones de objetos distribuidos
Realizaciones concretas de las funciones de la infraestructura soporte de sistemas de
procesamiento distribuido identicadas en RM-ODP como, por ejemplo, un Servicio
de Tratante (trading service), un Servicio de Nombres (naming service), etc.
Estandares de lenguajes para las cinco perspectivas desde las que especicar un
sistema de procesamiento distribuido 193, 148].
Modelos de Referencia estandar especcos que particularicen los conceptos de RMODP a un dominio particular de aplicacion de los principios de procesamiento distribuido. Por ejemplo, la arquitectura de TINA-C (Telecommunications Information
Networking Architecture Consortium o Consorcio de Arquitectura de Red de Informacion de Telecomunicaciones) se puede considerar como una implementacion de
los principios y conceptos de RM-ODP particularizados al mundo de los servicios
avanzados de telecomunicacion. TINA-C es un consorcio de operadores de redes
de telecomunicacion, proveedores de equipos de telecomunicacion y fabricantes de
equipos informaticos y software que, desde 1993, viene trabajando en la denicion
de una arquitectura software que, con la mayor independencia posible con respecto a la infraestructura informatica y de telecomunicaciones que la soporte, permita
la introduccion rapida y exible de nuevos servicios avanzados de telecomunicacion
(ademas de permitir la gestion de todos esos servicios y la infraestructura de soporte)
26, 44, 41, 11].
Los principios y conceptos de RM-ODP se han plasmado (en mayor o menor medida)
en tres arquitecturas principales de plataformas DOC:
12
OMA 104] (Object Management Architecture o Arquitectura de Gestion de Objetos) es la arquitectura de procesamiento distribuido de OMG (Object Management
Group o Grupo de Gestion de Objetos), un consorcio de empresas del ambito, fundamentalmente, de la informatica y las comunicaciones creado en 1989 con el objetivo
de desarrollar un estandar de procesamiento distribuido orientado a objetos para
entornos heterogeneos. La arquitectura OMA dene un \Modelo de Objetos" y un
\Modelo de Referencia" 243]. El \Modelo de Referencia" considera que las aplicaciones estan constituidas por Objetos, los cuales se pueden denir como aquellas
entidades encapsuladas cuyos servicios son accesibles por otros objetos a traves de
unas interfaces. Por su parte, el \Modelo de Referencia" describe de que forma se
han de llevar a cabo las interacciones entre objetos distribuidos. El \Modelo de Referencia" de OMA dene un \Intermediario de Peticiones de Objetos" (ORB u Object
Request Broker) que se encarga de soportar las interacciones entre los objetos de
unos \Servicios de Objetos" 84] que facilitan las labores de cualquier tipo de objeto (servicio de nombres, servicio de tratante, etc.) de unas \Facilidades Comunes"
82] utilizadas por aplicaciones nales (gestion de sistemas, almacenamiento de datos, etc.) de unas \Interfaces de Dominio" que son similares a los \Servicios de
Objetos" y \Facilidades Comunes" pero para dominios de aplicacion especcos (telecomunicaciones, comercio electronico, etc.) y de unas \Interfaces de Aplicacion"
que describen los servicios ofrecidos por los objetos que constituyen una aplicacion
concreta. Estos objetos de aplicacion utilizaran los servicios ofrecidos por el resto de
los integrantes del \Modelo de Referencia", servicios que simplican la labor de los
desarrolladores de dichos objetos de aplicacion. La especicacion mas importante
de las desarrolladas por OMG dentro del \Modelo de Referencia" de OMA es la
del ORB: CORBA (Common Object Request Broker o Intermediario Comun para
2.2. Las aplicaciones de objetos distribuidos
Peticiones de Objetos) 95]. CORBA (actualmente en su version 2.3.1) especica,
entre otras cosas, las caractersticas del ORB de OMA, un Lenguaje de Denicion
de Interfaces o IDL (Interface Denition Language) para especicar las interfaces de
cada objeto que compone una aplicacion distribuida, como implementar esas interfaces utilizando diferentes lenguajes de programacion (C, C++, Java, etc.) y como
conseguir interoperabilidad entre diferentes ORBs de OMA empleando, fundamentalmente, el denominado GIOP (Generic Inter-ORB Protocol o Protocolo Inter-ORB
Generico), protocolo que puede ser soportado por, entre otros, TCP/IP, dando lugar
al protocolo IIOP (Internet Inter-ORB Protocol).
DCOM (Distributed Component Object Model o Modelo de Objetos de Componentes
Distribuidos) 35] es un protocolo de nivel de aplicacion que permite la interoperabilidad de componentes COM distribuidos. COM (Component Objeto Model o Modelo
de Objetos de Componentes) es el modelo de componentes de Microsoft (del que se
hablara mas adelante). DCOM esta basado en un conjunto de extensiones al servicio
de \llamada a procedimiento remoto" (RPC o Remote Procedure Call) de DCE.
RMI (Remote Method Invocation o Invocacion Remota de Metodos) es la solucion
propuesta por Sun Microsystems para proporcionar caracterstica de procesamiento
distribuido a su \Plataforma Java". RMI permite que un objeto Java invoque metodos de otro objeto Java soportado por una \maquina virtual Java" de un sistema
diferente. A diferencia de otras arquitecturas de procesamiento distribuido, RMI no
permite la comunicacion entre objetos programados con diferentes lenguajes: unicamente es valido en entornos Java.
La tecnologa DOC es, a su vez, la base para un nuevo paradigma en el desarrollo
de aplicaciones distribuidas que aun esta en proceso de maduracion: el de las aplicaciones
basadas en \Plataformas de Componentes Distribuidos" (DCP, Distributed Component
Platform) 168, 29]. Las DCP surgen con el objetivo de facilitar la distribucion de aplicaciones basadas en el paradigma de Desarrollo Basado en Componentes (Component-based
Development). Los \Componentes Software" son bloques software reutilizables a partir
de los cuales se puede construir una aplicacion. La diferencia con respecto a otros tipo
de modulos software reutilizables radica en que los componentes se pueden modicar en
tiempo de dise~no en forma de ejecutables binarios. En Desarrollo Orientado a Objetos generalmente los objetos unicamente se pueden utilizar en aplicaciones escritas en el mismo
lenguaje de programacion y, en los casos en que es posible, no son facilmente extensibles
para poder ser utilizados en aplicaciones concretas.
Si anteriormente se han descrito las tres principales plataformas DOC que existen en
la actualidad, tambien se puede hablar de tres plataformas DCP fundamentales (justamente, el resultado de aplicar las tres plataformas DOC anteriores a los respectivos modelos
de componentes):
COM/DCOM: como se ha comentado anteriormente, COM es el modelo de componentes de Microsoft y, por tanto, DCOM (que permite la interaccion entre componentes COM distribuidos) se puede considerar como una DCP. Utilizando COM/DCOM,
se pueden integrar componentes desarrollados en diferentes lenguajes de programacion ejecutandose en sistemas con diferentes sistemas operativos 2]). Tambien es
importante mencionar que Microsoft ha desarrollado un modelo para simplicar la
integracion de componentes COM/DCOM en aplicaciones servidoras: el denominado
13
Captulo 2. Ambito
de la Tesis: La gestion integrada de la calidad de servicio en
aplicaciones de objetos distribuidos
MTS (Microsoft Transaction Server o Servidor de Transacciones de Microsoft) 244].
Toda la problematica asociada al desarrollo de software para servidores, queda oculta
por MTS: capacidades multihebra, recuperacion ante fallos, conexion con gestores de
bases de datos, etc. MTS, COM y el Microsoft Message Queue o MSMQ (la solucion
de Microsoft para \Middleware" orientado a mensajes) se agrupan actualmente bajo
el nombre de COM+.
Java RMI/JavaBeans 1] es el modelo de componentes de Java. A diferencia de
COM/DCOM, los componentes JavaBeans han de estar codicados, obligatoriamente, en el lenguaje Java, si bien se benecian de la independencia respecto a sistema
operativo caracterstica de este lenguaje de programacion. Para facilitar el desarrollo
de servidores utilizando JavaBeans, Sun tambien ha desarrollado un modelo denominado Enterprise JavaBeans que es para los JavaBeans lo que MTS es para los
componentes COM. Al amparo de esta tecnologa el ultimo a~no ha sido testigo del
espectacular desarrollo y difusion de los denominados \Servidores de Aplicaciones":
BEA WebLogic Server, OrbixHome de Iona, Component Broker de IBM, etc. son
algunos ejemplos de productos comerciales basados en la especicacion de Enterprise
JavaBeans.
CCM (CORBA Component Model o Modelo de Componentes CORBA) 96] que aun
esta en proceso de aceptacion. De CCM cabe destacar el hecho de que se centra
en la utilizacion de componentes CORBA para el desarrollo de servidores y que
esta bastante en lnea con la especicacion de Enterprise JavaBeans (de hecho, se
pretende que componentes de ambos modelos puedan interoperar).
De todo lo anterior se desprende el papel clave que las tecnologas de las plataformas
de procesamiento distribuido orientado a objetos u orientado a componentes juega en la
actualidad, papel que, previsiblemente, continuaran ejerciendo a corto y medio plazo 161].
2.3 El concepto de Gestion Integrada: arquitecturas y evolucion
En el ambito de los denominados \Sistemas de Informacion" (sistemas basados en la \Tecnologas de la Informacion y las Telecomunicaciones"), el concepto de \gestion" hace referencia al conjunto de tareas dedicadas al control y vigilancia de los recursos involucrados
en el funcionamiento de dichos sistemas 232, 118].
El principal objetivo de la \gestion" es maximizar el aprovechamiento de las inversiones identicando ineciencias y tratando de evitar las situaciones de indisponibilidad
de los sistemas gestionados.
Una adecuada \gestion" (en cuanto a la relacion calidad/coste) es una aspecto basico
en un entorno tan competitivo como es el de los \Sistemas de Informacion", entorno en
el que, ademas, las inversiones conllevan un elevado riesgo debido a lo cambiante de las
tecnologas y el tipo de servicios que se pueden ofrecer con ellas.
La \gestion" de un \Sistema de Informacion" se ha de enfocar desde dos perspectivas
fundamentales:
14
2.3. El concepto de Gestion Integrada: arquitecturas y evolucion
Perspectiva de negocio: se trata de integrar a la \gestion" dentro de la estructura
de costes del negocio que explota los sistemas gestionados. Dicha integracion se realiza asignando unos objetivos (mejora relacion calidad/coste del uso de los sistemas
gestionados) y reservando un presupuesto para el establecimiento de los metodos
de \gestion". El resultado de la \gestion" se ha de plasmar en posibles actuaciones
sobre los sistemas gestionados o sobre los propios mecanismos de \gestion".
Perspectiva tecnica: se plantea el dise~no y desarrollo de los metodos de \gestion"
propuestos por la perspectiva de negocio. Esta perspectiva decide que Herramientas
de gestion se han de utilizar (y de que modo) para alcanzar los objetivos jados
(mejora relacion calidad/coste).
Uno de los ambitos en los que, tradicionalmente, se ha hecho un mayor hincapie a la
hora de disponer de una \gestion" adecuada ha sido el de las redes de telecomunicacion.
La denominada \gestion de red" ha sido (y sigue siendo) una disciplina que ha evolucionado enormemente durante la ultima decada para hacer frente a las caractersticas mas
sobresalientes de este tipo de entorno: la heterogeneidad y la distribucion de los recursos
a gestionar.
Es en el campo de la \gestion de red" donde primero se empleo el concepto de
\gestion integrada": la posibilidad de gestionar diferentes tipos de recursos de red (recursos
de transmision y conmutacion) procedentes de diversos fabricantes utilizando un mismo
conjunto de herramientas de gestion. La \gestion de red integrada" permite disminuir el
riesgo de las inversiones en herramientas de gestion, a la vez que maximizar su rendimiento,
al estar dichas herramientas basadas en estandares.
Dos modelos de gestion de red integrada han sido las predominantes durante la
ultima decada: el modelo de gestion de Internet 39, 232, 12] y el modelo de gestion de
sistemas OSI (Open Systems Interconnection o Interconexion de Sistemas Abiertos, OSISM) 133, 230]. Ambos modelos tambien son conocidos por el nombre de los protocolos de
intercambio de informacion de gestion en los que se basan: SNMP (Simple Network Management Protocol y CMIP (Common Management Informacion Protocol), respectivamente.
El modelo de gestion de Internet fue desarrollado por el IETF (Internet Engineering Task
Force) de Internet mientras que fueron ISO/ITU-T quienes hicieron lo propio con la gestion
de sistemas OSI. Estos modelos de gestion estandarizan diferentes aspectos caractersticos de las herramientas de gestion (comunicaciones, informacion intercambiada, funciones
basicas. . . ) para as poder llevar a cabo una gestion integrada de entornos multivendedor.
Estos modelos estandar de gestion integrada se han utilizado hasta la actualidad,
fundamentalmente, en la gestion de recursos de red.
Ahora bien, la situacion en la actualidad es tal que la \gestion integrada" no puede
limitarse unicamente a los recursos de red. Las organizaciones que ofrecen \Servicios de
Informacion" no dependen unicamente de recursos de transmision y conmutacion (propios
o ajenos) sino tambien de sistemas informaticos y de aplicaciones (software) que, cada vez
en mayor medida, estan distribuidos.
En ese sentido, cabe destacar tambien como un importante referente en el mundo
de la gestion integrada, la arquitectura TMN (Telecommunications Management Network
o Red de la Gestion de las Telecomunicaciones) 142, 223, 75, 224] que dene un marco
arquitectonico cuyos principios guan el desarrollo de sistemas de gestion para redes de
telecomunicacion. Quizas una de sus mayores aportaciones ha sido la de identicar la
15
Captulo 2. Ambito
de la Tesis: La gestion integrada de la calidad de servicio en
aplicaciones de objetos distribuidos
necesidad (ademas de proponer una solucion) de integrar la gestion de los recursos de red
con otro tipo de recursos que pueden formar parte de la organizacion que opera la red
gestionada. En este sentido, TMN propone una serie de niveles de responsabilidad en la
gestion que se ocupen de: los recursos de la red individualmente, la red en su totalidad,
el servicio ofrecido por la red y como se integra la gestion de este servicio con la gestion
de otros servicios utilizados o mantenidos por la empresa que opera la red gestionada. No
obstante, y a pesar de lo ambicioso de este marco arquitectonico, ISO/ITU-T unicamente
proporciona soluciones estandar para la gestion de los elementos de red (justamente el
modelo de gestion OSI).
Los dos modelos de gestion integrada anteriormente mencionados (SNMP, OSI-SM)
tienen en comun, entre otros, dos aspectos de gran importancia:
Estan basadas en el denominado \Paradigma Gestor-Agente", un modelo de interaccion jerarquico-asimetrico entre los componentes de un sistema de gestion, componentes que se pueden clasicar en \gestores" y \agentes". Los \agentes" son las
entidades que ponen a disposicion de los \gestores" la informacion (en forma de
\objetos gestionados") acerca de los recursos que se desea gestionar. Los \gestores"
son las entidades que, en ultimo termino, interactuan con los usuarios del sistema de
gestion y/o implementan la logica de dicho sistema 118]. Este modelo de interaccion
es muy similar al modelo \cliente-servidor".
Estan fundamentalmente orientadas hacia la realizacion de una \gestion centralizada": habitualmente un unico sistema gestor se encarga de interactuar con la totalidad
de los agentes existentes en el entorno a gestionar.
Al amparo de estos estandares de gestion integrada se crearon las denominadas \Plataformas de Gestion Integrada", sistemas que agrupan los principales servicios utilizados
por las aplicaciones de gestion (comunicacion, almacenamiento de datos, tratamiento de
eventos, interfaces gracas, etc.) y que tienen como principal objetivo facilitar la integracion de aplicaciones gestoras de diferentes fabricantes en un mismo sistema de gestion.
Ejemplos de plataformas comerciales son HP OpenView, IBM NetView, CA Unicenter. . .
Los modelos de gestion integrada mencionados y las plataformas de gestion integrada que surgieron con ellos no han alcanzado el objetivo inicial de la gestion integrada:
gestionar cualquier tipo de recurso utilizando el mismo conjunto de herramientas. Ello se
ha debido, fundamentalmente a las siguientes causas:
Los modelos de gestion integrada surgieron con el objeto fundamental de gestionar
recursos de red con lo que su aplicacion a la gestion de otro tipo de recursos (sistemas,
aplicaciones, sistemas \middleware", etc.) no es inmediata.
La falta de un estandar de arquitectura de plataforma de gestion integrada (a pesar
de los esfuerzos en este sentido del antiguo \Network Management Forum", ahora
\Tele-Management Forum"3 ) se ha traducido en una \heterogeneidad de plataformas". Esta heterogeneidad se maniesta de diferentes formas:
{ Una aplicacion de gestion que es soportada por una determinada plataforma,
no puede utilizar los servicios de otra diferentes. Por ello, los desarrolladores
3
16
http://www.tmforum.org
2.3. El concepto de Gestion Integrada: arquitecturas y evolucion
de aplicaciones de gestion deben generar el mismo producto pero en diferentes
versiones (una para cada plataforma de gestion) con el consiguiente incremento
de los costes y, por tanto, del precio. Este problema se ha tratado de solventar,
en parte, con la especicacion de APIs estandar de acceso a los servicios de
plataformas de gestion. Ejemplos de estas APIs son: XMP/XOM y TMN/C++
118] si bien su exito ha sido relativo debido al poco o nulo interes de los fabricantes de plataformas por implementar estas APIs de manera completamente
el a las especicaciones.
{ Las plataformas de gestion integrada actuales son soluciones cerradas que impiden su integracion con servicios de plataformas de otros fabricantes. Este hecho
hace que una inversion en una plataforma de gestion (inversion por lo general
bastante elevada) implique depender unica y exclusivamente de ese fabricante
para la actualizacion y ampliacion de los sistemas de gestion.
Los ultimos cinco a~nos, y por todo lo anteriormente comentado, han sido testigos de
la evolucion del mundo de la gestion integrada en diferentes ambitos. Algunas de las mas
importantes son 4 :
Evolucion de los estandares. Cabe destacar en este punto la aparicion de SNMPv3
38], la version del modelo de gestion de Internet que, con el objetivo de solventar las
deciencias de la version original, incorpora mecanismos de autenticacion, control de
acceso, envo de noticaciones conrmadas, mejoras en el lenguaje de especicacion
de informacion de gestion, etc.
Descentralizacion de los sistemas de gestion. El grupo DISMAN del IETF 5 esta trabajando en el desarrollo de modelos de informacion que permitan que varios gestores
SNMP puedan cooperar para resolver problemas de gestion.
Aplicacion de las Tecnologas Web a la gestion integrada. Las principales iniciativas
en este sentido 125] han sido WBEM (Web-based Enterprise Management o Gestion
de Empresa basada en Web), soportada por Microsoft principalmente, y JMAPI
Java Management API o API Java de Gestion), auspiciada por Sun Microsystems.
Estas dos iniciativas han evolucionado, respectivamente, a la iniciativa CIM Common
Information Modelo o Modelo de Informacion Comun) y a la arquitectura JMX (Java
Management eXtensions o Extensiones Java para Gestion) que seran descritas en la
seccion 2.4.
Gestion integrada de otros tipos de recursos:
{ La gestion de aplicaciones. Hay que destacar:
El modelo de informacion de gestion de aplicaciones del IETF 36].
La interfaz de programacion ARM (Application Response Management o
Gestion de la Respuesta de las Aplicaciones)6 , una iniciativa de HewlettPackard y Tivoli/IBM para poder obtener, de una manera homogenea,
informacion de gestion de aplicaciones.
Para tener una vision global de la evolucion de la gestion integrada en los ultimo a~nos se recomienda
consultar 184, 118].
5
http://www.ietf.org/html.charters/disman-charter.html
6
http://www.cmg.org/regions/cmgarmw/index.html
4
17
Captulo 2. Ambito
de la Tesis: La gestion integrada de la calidad de servicio en
aplicaciones de objetos distribuidos
{ La gestion de ordenadores personales. DMI (Desktop Management Interface o
Interfaz de Gestion de Equipos de Sobremesa) es una especicacion de interfaces
software destinada a proporcionar acceso a la informacion de gestion contenida
en ordenadores personales. El DMI fue desarrollado por el DMTF (Desktop Management Task Force o Grupo de Trabajo de Gestion de Equipos de Sobremesa,
ahora denominado Distributed Management Task Force o Grupo de Trabajo de
Gestion Distribuida7 ).
Aplicacion de las Tecnologas de objetos distribuidos. Este aspecto se trata con
detalle en la siguiente seccion.
2.4 La gestion integrada y las plataformas de procesamiento
distribuido orientado a objetos
Dos aspectos fundamentales hay que considerar cuando se combinan la gestion integrada
y las plataformas de procesamiento distribuido:
La posibilidad de utilizar las plataformas de procesamiento distribuido orientado a
objetos como plataformas de gestion integrada.
Que particularidades presentan las aplicaciones de objetos distribuidos a la hora de
ser gestionadas conjuntamente con otros tipos de recursos.
2.4.1 Las plataformas de procesamiento distribuido orientado a objetos
como plataformas de gestion integrada
La tecnologa de las plataformas de procesamiento distribuido orientado a objetos posee cualidades que la hacen muy buena candidata para la resolucion de los principales
problemas padecidos por las plataformas de gestion integrada \tradicionales":
1. La capacidad de integracion de componentes de aplicaciones distribuidas de manera
transparente se puede aplicar al problema de la integracion de los componentes de
las plataformas de gestion. De esa manera, un determinado componente de una
plataforma de gestion (un servicio de informacion topologica de redes gestionadas,
por ejemplo) puede ser sustituido por un producto de otro fabricante con identica
funcionalidad de manera practicamente inmediata. Ademas, la plataforma de gestion
en s pasara automaticamente a poder ser distribuida 157].
Esta idea ya se ha utilizado en algunas plataformas comerciales pero para poder
alcanzar realmente el objetivo de tener una plataformas de gestion integrada basada en una plataforma de procesamiento distribuido orientado a objetos que sean
realmente modulares, abiertas, etc. es necesario denir una arquitectura que especique que componentes han de tener estas plataformas y cuales han de ser sus
funcionalidades. En este sentido, cabe destacar las siguientes iniciativas:
7
18
http://www.dmtf.org
2.4. La gestion integrada y las plataformas de procesamiento distribuido orientado a
objetos
ODMA (Open Distributed Management Architecture o Arquitectura de Gesti
on
Distribuida Abierta) 147]. ODMA es el reejo del trabajo de ITU-T e ISO para
aplicar los conceptos de RM-ODP al desarrollo de sistemas de gestion (ejemplos
concretos de aplicacion se pueden encontrar en 138, 140]). ODMA (al igual que
sucede con RM-ODP) es una especicacion de un alto grado de abstraccion.
Simplemente dene el vocabulario basico de, en este caso, el dominio de la gestion integrada e identica areas de interes para las que sera conveniente generar
nuevos estandares. Esas ideas, se particularizan a arquitecturas de plataformas
de procesamiento concretas, como OMG/CORBA 136]
OMG Telecom Task Force: este grupo de trabajo esta consensuando la especicacion de servicios CORBA (especicacion que queda reejada en un conjunto
de interfaces CORBA IDL) susceptibles de ser utilizados como servicios integrantes de una plataforma de gestion integrada basada en CORBA: servicio de
gestion de eventos, servicio de gestion de noticaciones, servicio de registro de
incidencias, interoperabilidad entre CORBA y TMN (de la que se hablara posteriormente). Estos nuevos servicios CORBA para la gestion integrada se basan,
en la medida de lo posible, en servicios CORBA de proposito general (el servicio de Noticaciones, por ejemplo, esta basado en el servicio de Eventos de
CORBA, el cual no es especco de aplicaciones de gestion integrada) 205, 73].
2. El acceso a la informacion de gestion mantenida por los recursos gestionados se puede realizar utilizando los mecanismos de comunicacion propios de la plataforma de
procesamiento distribuido (IIOP, RMI, DCOM . . . ). De esa manera se dispondra
de un protocolo de intercambio de informacion de gestion con una API estandar
de acceso a sus servicios 203] (la proporcionada por la arquitectura de plataforma
de procesamiento distribuido utilizada). Ahora bien, para que esto fuera posible, los
recursos gestionados debera ser accedidos utilizando estos mecanismos de comunicacion. Se plantea pues, como integrar la gestion de todos los recursos (de red, sistema,
etc.) que no poseen esta capacidad (unicamente hay que pensar en la gran cantidad
de elementos de red que son gestionables mediante, por ejemplo, SNMP y que no
podra ser gestionados utilizando esta aproximacion).
Dicho de otro modo, el problema de la \heterogeneidad de plataformas de gestion
integrada" se convertira en un problema de \heterogeneidad de arquitecturas de
gestion integrada".
Se plantea por tanto el problema de la \interoperabilidad entre arquitecturas de
gestion" 151, 17, 50], un problema que no es nuevo (existe desde que se llego a la
conclusion de que ni OSI-SM ni el modelo de gestion de Internet iban a convertirse en
la unica solucion de gestion integrada utilizada) pero que se ha visto agravado por la
aparicion de nuevas arquitecturas de gestion integrada procedentes de la aplicacion
de las tecnologas de procesamiento distribuido orientado a objetos en este campo.
Por tanto, mas que hablar del problema de la \heterogeneidad de las arquitecturas
de gestion integrada" habra que poner en primer plano el problema de la \heterogeneidad de las arquitecturas de procesamiento distribuido" (la gura 2.2 muestra
un esquema de esta evolucion en los problemas que afectan a la gestion integrada).
La forma mas sencilla de conseguir la coexistencia de varias arquitecturas de gestion
integrada en un mismo dominio consiste en dar soporte a todas esas arquitecturas
en los sistemas gestores o en los sistemas gestionados dando lugar as a:
\Plataformas de gestion multiarquitectonica": son capaces de interactuar con
agentes de gestion pertenecientes a diferentes arquitecturas de gestion integra19
Captulo 2. Ambito
de la Tesis: La gestion integrada de la calidad de servicio en
aplicaciones de objetos distribuidos
Gestión
Heterogénea
1990
Modelos de
Gestión Integrada
(SNMP,OSI−SM)
Heterogeneidad
de Modelos
de Gestión
Integrada
Heterogeneidad
de Plataformas
Plataformas de Procesamiento
Distribuido
1995
Heterogeneidad
de Plataformas
de Procesamiento
Distribuido
Pasarelas de Gestión
(Interoperabilidad)
Nuevas Arquitecturas
de Gestión Integrada
(JMX,CIM,...)
2000
?
Figura 2.2: Evolucion de los problemas que afectan a la Gestion Integrada
da. Ello supone que las aplicaciones gestoras deberan utilizar diferentes APIs
de la plataforma para manipular o acceder a informacion de gestion en funcion
de la arquitectura del agente.
\Agentes multiarquitectonicos": son agentes que tienen que poner su informacion de gestion a disposicion de gestores de diferentes arquitecturas.
La alternativa ideal (aquella que ocultara la existencia de multiples arquitecturas de
gestion coexistiendo en un mismo dominio) es la basada en las denominadas \pasarelas de gestion": sistemas capaces de presentar a un componente de una arquitectura
de gestion (gestores o agentes) como si perteneciera otra arquitectura diferente.
Las pasarelas de gestion deben hacer frente a un doble problema:
La traducci
on de la informacion de gestion
La traducci
on de las interacciones de gestion
Diferentes propuestas particulares para el desarrollo de pasarelas de gestion se pueden encontrar para diferentes escenarios:
(a) Gestion de sistemas CORBA desde plataformas de gestion OSI 124, 56].
(b) Gestion de sistemas CORBA desde plataformas de gestion SNMP 155, 155, 15].
(c) Gestion de agentes SNMP desde plataformas CORBA 188, 156].
20
2.4. La gestion integrada y las plataformas de procesamiento distribuido orientado a
objetos
(d) Gestion de agentes OSI desde plataformas CORBA 73].
Ahora bien, a la hora de hablar de propuestas de arquitecturas de pasarelas de
gestion por parte de organizaciones de estandarizacion o asociaciones de fabricantes/usuarios, cabe destacar:
IIMC (ISO/CCITT and Internet Management Coexistence o Coexistencia entre
gestion ISO/CCITT e Internet). En 1992, el \Network Management Forum"
(ahora \Telemanagement Forum" puso en marcha la iniciativa IIMC para generar especicaciones que permitieran una traduccion de los modelos de informacion de gestion de SNMP a OSI-SM y viceversa 65, 66] as como una
arquitectura de pasarela entre las dos arquitecturas 64].
JIDM (Joint Inter-Domain Management o Gestion Unicada Inter-Dominio).
Para permitir la interoperabilidad entre las arquitecturas de gestion \tradicionales" y CORBA, el \Open Group" creo el grupo de trabajo JIDM cuyos
resultados fueron adoptados, posteriormente, por OMG. Las dos aportaciones
fundamentales del grupo JIDM han sido 228] :
{ Normalizar la Traduccion de Especicaciones 106] de informacion de gestion. En concreto, se detalla como traducir tipos y estructuras de datos
utilizados en OSI-SM y SNMP a los usados en CORBA.
{ Normalizar la Traduccion de Interacciones entre sistemas basados en diferentes arquitecturas de gestion. En concreto se detalla las interacciones
entre CORBA y OSI-SM 92], y CORBA y SNMP 93].
A partir de estas traducciones, es posible desarrollar pasarelas de gestion entre
sistemas basados en arquitecturas diferentes (como, por ejemplo, en 16]).
El problema de la \heterogeneidad" de las arquitecturas de gestion integrada, se
ha visto incrementado por la aparicion de dos nuevas soluciones para la gestion
integrada, resultado de la evolucion de los trabajos sobre gestion basad en Web
comentados en la seccion 2.3 (evolucion que se muestra en la gura 2.3):
JMX (Java Management Extensions o Extensiones Java para Gestion) 192]
es una especicacion que dene, en torno a Java/RMI , una arquitectura de
gestion integrada, unos patrones de dise~no 72] para instrumentar aplicaciones
gestionada, unas APIs para acceder a servicios de otras arquitecturas de gestion
y una serie de servicios genericos para constituir a las implementaciones de JMX
en autenticas plataformas de gestion.
La gura 2.4 esquematiza la arquitectura JMX. Dicha arquitectura posee tres
niveles. Los dos primeros son los correspondientes al paradigma \tradicional"
gestor-agente. El componente de la arquitectura que hace las veces de agente
recibe el nombre de marco JMX o \framework". Los marcos JMX se caracterizan por poner la informacion de gestion a disposicion de los gestores a traves de
unos \adaptadores de protocolo" (se puede pensar en adaptadores para SNMP,
OSI, HTTP, XML/CIM, etc.). De esa manera se permite que recursos gestionados mantenidos por marcos JMX puedan ser gestionados por gestores de
diferentes arquitecturas de gestion integrada. Dicho de otro modo, JMX apuesta por una interoperabilidad entre arquitecturas de gestion basada en \agentes
multiarquitectonicos".
La parte mas novedosa de JMX es la correspondiente al denominado \nivel
de instrumentacion". Si en los modelos de gestion integrada \tradicionales"
21
Captulo 2. Ambito
de la Tesis: La gestion integrada de la calidad de servicio en
aplicaciones de objetos distribuidos
Sun
Consorcio
WBEM
JMAPI
Jul 96
JMX
Junio 99
Propuesta WBEM
Jul 96
CIM 2.0
Agosto 98
DMTF
1994
CIM 1.0
Abril 97
DMI 1.1
Ene 96
DMI 1.0
Sep 94
1995
1996
1997
WBEM −>
DMTF
1998
CIM 2.2
Junio 99
1999
Figura 2.3: Evolucion de las arquitecturas de gestion integrada basadas en Web hacia
nuevas arquitecturas de gestion integrada basadas en plataformas de procesamiento distribuido orientado a objetos.
Gestor SNMP
Gestor Propietario
Navegador Web
Nivel
Gestor
Gestor JMX
Adaptadores de
Protocolos
Nivel
Agente
Framework
M−Bean
Máquina Virtual Java
Figura 2.4: La arquitectura de JMX 192].
22
Nivel
Instrumentación
Máquina Virtual Java
2.4. La gestion integrada y las plataformas de procesamiento distribuido orientado a
objetos
(SNMP, OSI-SM, etc.) los estandares no jaban como era la comunicacion entre los agentes y los recursos gestionados que mantienen, JMX hace todo lo
contrario: dene unos patrones de dise~no que deben cumplir todos los recursos gestionados que desean ser mantenidos por un marco JMX. Esos recursos
gestionados, que tienen que ser objetos Java, y que se ajustan a ese patron de
dise~no, se denominan M-Beans (Management Beans o Beans de gestion). Lo que
no especica JMX es como estos M-Beans son \empotrados" en aplicaciones
Java susceptibles de ser gestionadas.
Mediante la utilizacion, por parte de los M-Beans, de las APIs proporcionadas
por JMX para acceder a servicios de otras arquitecturas de gestion, se pueden
desarrollar \Pasarelas de Gestion" entre el dominio Java/JMX y otro diferente.
CIM (Common Information Model o Modelo Com
un de Informacion) 63] es
una propuesta del DMTF (Distributed Management Task Force o Grupo de
Trabajo sobre Gestion Distribuida) para la gestion integrada de todo tipo de
recursos. CIM dene un meta-modelo de informacion de gestion orientado a
objetos que se puede considerar, hasta cierto punto, como un superconjunto de
los modelos de informacion de gestion de las arquitecturas de gestion integrada
\tradicionales". CIM, en su version 2.2, incluye:
{ La ya comentada especicacion de un meta-modelo (meta-esquema segun
la terminologa CIM) de informacion de gestion.
{ Unos esquemas (modelos de informacion de gestion) basicos a partir de los
cuales poder denir nueva informacion de gestion. Los esquemas de CIM
se dividen en tres niveles conceptuales:
Modelo N
ucleo: contiene conceptos de gestion aplicables a todos los
ambitos (elemento logico, elemento fsico, sistema, servicio, etc.)
Modelo Com
un: incluye esquemas con informacion de gestion particular de un dominio de gestion concreto (redes, aplicaciones, bases de
datos, etc.) pero con independencia de tecnologas o implementaciones
particulares
Esquemas de extension: incluyen deniciones de informacion de gestion especca de un entorno concreto (esquema para gestion de las
particularidades de una tarjeta de red de un determinado fabricante).
{ Un lenguaje de descripcion de informacion de gestion denominado MOF
(Managed Object Format o Formato de Objetos Gestionados).
{ Unos mecanismos de traduccion de modelos de informacion de otras arquitecturas de gestion integrada a CIM. El objetivo es utilizar CIM como
nexo de union entre todas las arquitecturas de gestion (al menos en lo que
a modelos de informacion de gestion se reere).
CIM no aporta ideas excesivamente novedosas al mundo de la gestion integrada.
Ahora bien, cuenta con la ventaja de basarse en tecnologas de uso comun en
la actualidad (UML, XML, etc.) y de contar con el respaldo de Microsoft. De
hecho, el nuevo sistema operativo de Microsoft, Windows 2000, incorpora en su
distribucion un CIMOM (CIM Object Manager o Gestor de Objetos CIM): una
entidad (una especie de agente de gestion) responsable de poner informacion
de gestion CIM a disposicion de sistemas gestores. El CIMOM obtiene esa
informacion de gestion mediante los denominados \proveedores" (autenticas
pasarelas de gestion que permiten importar al dominio CIM informacion de
gestion procedente de agentes de otras arquitecturas de gestion: SNMP, DMI,
23
Captulo 2. Ambito
de la Tesis: La gestion integrada de la calidad de servicio en
aplicaciones de objetos distribuidos
etc.). Este hecho hace que CIM cuente con un prometedor futuro a medio plazo,
independientemente de su calidad tecnica o caracter novedoso.
No esta clara cual sera la evolucion futura de la gestion integrada. Parece poco
probable que una arquitectura de gestion integrada especca se acabe imponiendo sobre
las demas. As pues, habra que pensar en escenarios en los que diferentes arquitecturas de
gestion tengan que interoperar. De hecho, parece probable 204] que las arquitecturas de
gestion integrada \tradicional" (SNMP, OSI-SM, DMI. . . ) se sigan empleando para gestion
de red (niveles de elemento de red, gestion de elemento de red y red segun la terminologa
TMN), las plataformas de procesamiento distribuido (CORBA, RMI, COM+, etc.) se
apliquen a aspectos de gestion de servicio y tecnologas de gestion basadas en Web (CIM
parece el candidato mas fuerte) se empleen para el acceso por parte de los usuarios a los
sistemas de gestion.
2.4.2 La gestion integrada de aplicaciones de objetos distribuidos
En esta seccion no se trata de como utilizar las aplicaciones de objetos distribuidos para
implementar soluciones de gestion integrada sino todo lo contrario: como las aplicaciones
de objetos distribuidos pueden ser gestionadas de manera integrada. Varias cuestiones hay
que tratar a este respecto:
El paradigma gestor-agente utilizado en gestion de red se caracterizaba, entre otras
cuestiones, por el hecho de que los agentes de gestion ocultaban a los sistemas de
gestion las particularidades de los recursos gestionados. Los estandares de gestion
integrada basados en el paradigma gestor-agente no especicaban como deba ser
la interaccion entre agentes y recursos gestionados. Ahora bien, los recursos a gestionar de una aplicacion de objetos distribuidos son, justamente, los objetos que
las integran. Dichos objetos interactuan con su entorno a traves de unas interfaces
perfectamente denidas y unos mecanismos de comunicacion proporcionados por las
plataformas que las soportan. Dicho de otro modo, todos los recursos a gestionar
de una aplicacion de objetos distribuidos pueden ser accedidos utilizando unos mecanismos estandar. Este hecho hace que el concepto de agente pierda parte de su
utilidad cuando se gestionan este tipo de aplicaciones 203, 17, 117].
Para conseguir que una aplicacion de objetos distribuidos sea gestionable, hay que
permitir que los sistemas de gestion interactuen con los objetos que la componen. Para conseguirlo, los objetos de las aplicaciones a gestionar debe de ofrecer un conjunto
de servicios de gestion a traves de unas \interfaces de gestion" 226, 225]. Estas interfaces de gestion permiten interactuar con el objeto gestionado utilizando los mismos
mecanismos que los empleados para interactuar con la \parte funcional" del objeto
gestionado. Al respecto de las \interfaces de gestion", surgen dos interrogantes de
gran importancia:
{ >Como deben ser estas interfaces de gestion? En principio se puede pensar en
una total libertad en lo referente a su especicacion pero si se desea que la
gestion de las aplicaciones de objetos distribuidos se pueda llevar a cabo desde gestores pertenecientes a arquitecturas de gestion integrada no basadas en
plataformas de procesamiento distribuido o por gestores que utilizan una plataforma de procesamiento distribuido diferente a la utilizada por la aplicacion
24
2.5. La Calidad de Servicio: concepto y arquitecturas
a gestionar, entonces es necesario que las \interfaces de gestion" cumplan los
requisitos impuestos por las pasarelas de gestion. Un ejemplo de ello es el patron de los M-Beans de JMX o las interfaces IDL de gestion para aplicaciones
CORBA promulgadas por JIDM.
>Como interactua la parte funcional de un objeto gestionado con su parte de soporte
a la gestion? Dicho de otro modo, >como se ha de instrumentar 153] un objeto
gestionado de una aplicacion distribuida? Por supuesto, las arquitecturas de gestion
y de procesamiento distribuido no imponen ningun requisito al respecto pero la
forma en que se decida llevar a cabo la instrumentacion puede afectar enormemente
a los desarrolladores de las aplicaciones a gestionar. En la tesis doctoral propuesta
se ilustra una posible manera de llevar a cabo una instrumentacion de gestion en
aplicaciones de objetos distribuidos que es completamente transparente para los
desarrolladores de la parte funcional de la aplicacion.
2.5 La Calidad de Servicio: concepto y arquitecturas
Si bien es posible encontrar en la literatura gran cantidad de deniciones, a menudo enormemente diferentes, del termino calidad de servicio (al que en ocasiones se hara referencia
mediante su acronimo ingles QoS, Quality of Service), en la tesis doctoral propuesta se
entiende que con el termino calidad de servicio (QoS) se hace referencia a to-
dos los aspectos no funcionales de un sistema de los que depende el grado de
satisfaccion del usuario de la funcionalidad del servicio ofrecido. Dos aspectos
sobresalen en esta denicion:
La calidad de servicio hace referencia a aspectos no funcionales de un sistema. Este
hecho, reejado en otras deniciones del termino QoS encontradas en la literatura
70, 220, 88] indica que la calidad de servicio es la caracterstica diferencial entre dos
servicios similares.
La calidad de servicio esta ntimamente ligada a los requisitos del usuario del servicio
bajo estudio. Dichos requisitos van a guiar todos los aspectos relacionados con la
calidad de servicio de todos los tipos de recursos involucrados en la provision del
servicio al usuario 245, 126, 163, 177, 154].
Del mismo modo, algunos aspectos han quedado deliberadamente fuera de la denicion anteriormente propuesta:
Algunos autores 5, 88] restringen la calidad de servicio unicamente a aspectos de
rendimiento del sistema. Sin embargo, en determinados servicios, aspectos de abilidad, calidad de datos, seguridad, etc. 70] son tambien muy importantes a la hora de
cuanticar la calidad de servicio. Por ello la denicion propuesta no se particulariza
a ninguna categora concreta de aspectos no funcionales.
En otros casos 245, 112] las deniciones y el estudio de la calidad de servicio se circunscriben a determinados subconjuntos de los recursos involucrados en la provision
de un determinado servicio: recursos de red (transmision y conmutacion), sistemas
nales, aplicaciones, etc. puesto que los aspectos no funcionales (y los mecanismos y
25
Captulo 2. Ambito
de la Tesis: La gestion integrada de la calidad de servicio en
aplicaciones de objetos distribuidos
tecnicas que involucran) relacionados con cada uno de los tipos de recursos son muy
diferentes y tienen entidad suciente como para ser estudiados por separado (tecnicas de control de admision o de control de congestion en servicios de red, tecnicas
de planicacion los sistemas operativos de los sistemas nales, etc.). La denicion
propuesta no se restringe a un tipo de recursos en concreto y aborda el problema
de la calidad de servicio desde una perspectiva global (la expresion utilizada en
la literatura para hacer referencia a esta perspectiva global es \end-to-end QoS"
79, 198, 127, 129, 46, 47, 48, 154])
Para tratar con todas las cuestiones relacionadas con la calidad de servicio tal y
como se ha descrito anteriormente, se han propuesto multiples \Arquitecturas QoS". La
mayor parte de ellas estan orientadas al control, vigilancia y mantenimiento de la calidad
de servicio en aplicaciones multimedia (distribuidas o no). Este hecho es logico puesto que
es en este tipo de aplicaciones donde esta involucrada una mayor diversidad de recursos
y donde, por tanto, la problematica de la calidad de servicio se tiene que abordar desde
una perspectiva global. En 37, 112] se puede encontrar una descripcion de las propuestas
mas importantes en este sentido.
Al comparar todas esas propuestas de arquitecturas, surge el interrogante de que aspectos debera abordar una arquitecturas de calidad de servicio idea. Para tratar de responder a esa pregunta, se han denido algunos marcos o modelos de referencia QoS. Entre
esos marcos, cabe destacar el de la Universidad de Columbia 37] y el de la Universidad de
Western Ontario 112], ambos fundamentalmente orientados a caracterizar la problematica
de la calidad de servicio en aplicaciones multimedia.
Ahora bien, el marco mas general y mas completo es el que esta siendo desarrollado
por ITU-T e ISO.
Los trabajos de ITU-T e ISO 8 en lo que a la calidad de servicio se reere, se iniciaron
con el objetivo de claricar todo lo concerniente a QoS en las comunicaciones OSI. Sin embargo, pronto se hizo evidente que el problemas de QoS trascenda las comunicaciones OSI
y se intento abordar el problema de la calidad de servicio en otros entornos relacionados
con las Tecnologas de la Informacion y las Comunicaciones. 9
En la recomendacion X.641 de ITU-T 146] (ISO/IEC IS 13236) se proporciona un
marco que dene los principios, conceptos y terminologa QoS basicos sobre los que basar ulteriores trabajos relacionados con la calidad de servicio. ITU-T/OSI arman que
las aportaciones de dicho marco son lo sucientemente genericas como para poder ser
aplicadas a practicamente todos los ambitos de las tecnologas de la informacion y las
comunicaciones.
ISO/ITU-T denen la calidad de servicio de una manera muy generica 10 : calidad de
servicio es el conjunto de requisitos de calidad que afectan al comportamiento colectivo
de uno o mas objetos". En 48] se concreta mas la vision que ITU-T e ISO tienen de la
calidad de servicio:
Los trabajos sobre QoS en ITU-T/ISO eran, inicialmente, responsabilidad del Grupo de trabajo 7 del
sub-comite 21 del comite tecnico conjunto de ISO (ISO/IEC JTC1/SC 21/WG7). Actualmente, el grupo
responsable de la calidad de servicio en ISO/ITU-T es el JTC1/SC7/WG3.
9
El lector interesado en profundizar en el estado de los trabajos de ITU-T e ISO en QoS, puede acudir
a http://www.fokus.gmd.de/research/cc/tip/employees/jdm/private/jdmQoSIG.html.
10
Esta denicion proviene de las normas del modelo de referencia de ODP (Open Distributed Processing,
Procesamiento Distribuido Abierto) 139]).
8
26
2.5. La Calidad de Servicio: concepto y arquitecturas
La calidad de servicio tiene como objetivo garantizar, durante la utilizacion de un
servicio, una calidad contractual a un conjunto de agentes en una comunidad.
Los contratos que reejan esa calidad se denen mediante la especicacion de
{ una serie de requisitos y obligaciones para la comunidad que esta involucrada
en la provision del servicio.
{ un conjunto de polticas a las que los agentes de la comunidad deben ce~nir su
comportamiento durante todas las fases de la provision del servicio.
Los objetivos de la calidad de servicio se consiguen mediante la asignacion de unas
determinadas responsabilidades y papeles a todos y cada uno de los agentes que
componen la comunidad.
Partiendo de esta vision de lo que es la calidad de servicio, la recomendacion X.641
dene un \marco conceptual y funcional" que cubre los siguientes aspectos:
1. Terminologa y Conceptos basicos de calidad de servicio que se resumen en
la tabla 2.1.
2. Denicion de Caractersticas QoS: el concepto de \caracterstica QoS" es fundamental en el marco propuesto en la recomendacion X.641. Si bien cada tipo de
sistema tendra sus propias \caractersticas QoS", el marco propone una serie de caractersticas genericas aplicables, fundamentalmente, a los recursos de comunicacion
y procesamiento. En concreto, dene siete grupos de caractersticas QoS: temporales, de coherencia (temporal y espacial), de capacidad, de integridad, de seguridad,
de robustez y de disponibilidad.
3. Funciones de Gestion QoS: otro aspecto de gran importancia cubierto por 146]
es el de las \funciones de gestion QoS" o QMFs (Quality of Service Management
Functions): una vez que se tiene un vocabulario QoS bien denido, y despues de
conocer las \caractersticas QoS" propias del sistema cuya QoS se quiere gestionar,
hay que averiguar que tareas hay que realizar para satisfacer las necesidades que los
usuarios tiene en relacion a la calidad de servicio. Esas tareas son las denominadas
\funciones de gestion QoS".
146] utiliza tres dimensiones para caracterizar las QMFs:
(a) Los \mecanismos QoS" en los que se basan: cada QMF se basa en uno o varios
\mecanismos QoS" que, a su vez, pueden ser utilizados por mas de una QMF.
Los \mecanismos QoS" se pueden considerar como el soporte de las actividades
mas basicas de gestion QoS.
(b) Las \fases QoS" durante las que se realizan: se consideran tres fases diferentes
en las que pueden actuar las \funciones de gestion QoS":
i. Fase de Prediccion: durante esta fase se trata de predecir cual sera el comportamiento del sistema durante el periodo en que se lleve a cabo una
determinada actividad QoS.
27
Captulo 2. Ambito
de la Tesis: La gestion integrada de la calidad de servicio en
aplicaciones de objetos distribuidos
Caracterstica QoS
Mecanismo QoS
Poltica QoS
Informacion QoS
Contexto QoS
Parametros QoS
Requisito QoS
Medida QoS
Atributo QoS
Control QoS
Averiguacion QoS
Establecimiento QoS
Mantenimiento QoS
Funcion de Gestion QoS
Monitorizacion QoS
Conceptos y deniciones de modelado QoS
Un aspecto cuanticable de QoS que se dene con independencia de los medios
empleados para representarlo o controlarlo
Un mecanismo especco que puede utilizar elementos de protocolo, parametros QoS o contextos QoS, posiblemente de forma conjunta con otros mecanismos QoS, para dar soporte al establecimiento, monitorizacion, mantenimiento, control y averiguacion QoS
Conjunto de reglas que determinan las caractersticas QoS y las funciones de
gestion QoS a utilizar en cada caso
Deniciones orientadas a informacion
Informacion relacionada con la calidad de servicio. Se puede clasica en contextos QoS (cuando es mantenida por una entidad) y en parametros QoS
(cuando es intercambiada entre varias entidades). Tambien se puede clasicar
en requisitos QoS (si expresa un requisitos relacionado con la QoS) y en datos
QoS (en caso contrario)
Informacion QoS que es mantenida, interpolada o extrapolada por una o mas
entidades y que se utiliza en la gestion QoS. A su vez, los contextos QoS se
pueden clasicar en contexto de requisitos y en contexto de datos
Informacion QoS que se intercambia entre entidades como parte de un mecanismo QoS. Se clasican en parametros de requisitos y en parametros de
datos
Informacion QoS que expresa parte o la totalidad de un requisito que hay
que cumplir a la hora de gestionar una o mas caractersticas QoS. Cuando
se intercambia entre entidades, un requisito QoS se expresa en terminos de
parametros QoS
Uno o mas valores observados de una caracterstica QoS
Deniciones relacionadas con las funciones de gestion
Un atributo de un objeto gestionado referente a QoS
Utilizacion de mecanismos QoS para llevar a cabo las modicaciones necesarias para conseguir que una determinada actividad de un sistema alcance el
valor adecuado en las caractersticas QoS deseadas mientras dicha actividad
esta en progreso
Utilizacion de mecanismos QoS para determinar las propiedades del entorno
que esten relacionadas con la QoS
Utilizacion de mecanismos QoS con el proposito de crear las condiciones necesarias para que una determinada actividad del sistema alcance el valor adecuado en el conjunto de caractersticas QoS deseadas, antes de que dicha
actividad comience
Utilizacion de mecanismos QoS para mantener un conjunto de caractersticas QoS de una actividad en los valores requeridos mientras dicha actividad
esta en progreso
Una funcion dedicada especcamente a satisfacer los requisitos QoS del usuario mediante uno o mas mecanismos QoS
Utilizacion de medidas QoS para estimar los valores de un conjunto de caractersticas QoS que estan siendo alcanzados por una determinada actividad
del sistema
Tabla 2.1: Terminologa y conceptos del marco QoS de ISO/ITU-T.
ii. Fase de Establecimiento: durante esta fase, las entidades involucradas en
la provision del servicio, expresan sus \requisitos QoS", negocian dichos
requisitos, acuerdan la calidad de servicio a alcanzar y mantener y jan
las polticas a seguir en caso de que no se pueda alcanzar la calidad de
servicio acordada. Una vez acordada la calidad de servicio, y en caso de
que sea factible, se crean las condiciones (se reservan recursos) para que
dicha calidad de servicio sea posible al entrar en la Fase de Operacion.
iii. Fase de Operacion: durante esta fase se trata de mantener la calidad de
servicio acordada y se llevan a cabo de terminadas acciones si ello no es
posible.
(c) La entidad que las inicia: las QMFs (y, por tanto, los \mecanismos QoS" que
las soportan) puede:
i. Estar siempre operativas
28
2.5. La Calidad de Servicio: concepto y arquitecturas
ii. Ser iniciadas por el usuario del servicio
iii. Ser iniciadas por otras entidades (por ejemplo, por un proveedor de servicios
cuando se detecta una degradacion en la calidad de servicio
4. Mecanismos QoS genericos: para ilustrar las cuestiones anteriores, la recomendacion X.641 dene una serie de \mecanismos QoS" genericos (en el sentido de que
pueden ser aplicados a cualquier \caracterstica QoS". Estos mecanismos se resumen
en la tabla 2.2.
Mecanismos de la Fase de Pre- Obtencion de informacion historica sobre los niveles QoS alcanzados con andiccion
terioridad
Analisis de informacion historica QoS
Prediccion de \caractersticas QoS"
Calculo de perturbaciones potenciales si determinados \requisitos QoS" son
solicitados y alcanzados
Evaluacion de los niveles de los \parametros QoS" que hay que solicitar en la
fase de establecimiento
Comprobacion de que las peticiones de calidad de servicio no entran en conicto con las polticas de control de admision
Mecanismos de la Fase
Negociacion
de Establecimiento
Reserva de recursos
Inicializacion
Mecanismos de la Fase Opera- Monitorizacion QoS
tiva
8 Reserva de Recursos
>>< Control de Admision
de Salida
Mantenimiento (adaptacion) QoS Control
QoS
>> Ajuste
: Sincronizacion
( Prioridad deFiltrado
PDUs
Planicacion dinamica Coherencia temporal y espacial
Planicacion dinamica de PDUs
Tabla 2.2: Mecanismos genericos del marco QoS de ISO/ITU-T.
Si bien la recomendacion X.641 propone un marco QoS totalmente generico, potencialmente aplicable a cualquier ambito, ISO/ITU-T estan trabajando en la particularizacion del marco propuesto a dos areas concretas:
Las comunicaciones segun el \modelo de referencia OSI" (Open System Interconnection, Interconexion de Sistemas Abiertos) 132] que, como fue comentado, era el
objetivo inicial de los trabajos sobre QoS de ISO/ITU-T. Basicamente, el modelo de
QoS en OSI (que se dene dentro de la propia recomendacion X.641) combina los
principios del \marco QoS" con los del \marco de gestion de sistemas OSI" 133] y
propone la utilizacion de dos tipos de entidades para soportar los aspectos QoS en
un sistema que se ajuste a los principios del \modelo de referencia OSI":
1. Entidades QoS de sistema: son las entidades que tienen una vision de la calidad
de servicio del sistema en su conjunto, de manera que controlan y coordinan
la operacion de las entidades Qos de nivel. Estas entidades utilizaran las facilidades del \modelo de gestion de sistemas OSI" para intercambiar informacion
de gestion (en este caso referente a QoS) con otros sistemas e implementaran
las funciones de \control de calidad del sistema", para ajustar el rendimiento
29
Captulo 2. Ambito
de la Tesis: La gestion integrada de la calidad de servicio en
aplicaciones de objetos distribuidos
de las diferentes entidades de protocolo que esten operando en los diferentes
niveles del sistema, y de \control de polticas del sistema", para determinar
que acciones se han de tomar en las diferentes situaciones que puedan surgir
durante las diferentes actividades de gestion QoS.
2. Entidades QoS de nivel: son las entidades que se ocupan de los aspectos de
calidad de servicio que afectan a las entidades de un nivel particular de los
siete de los que se compone el \modelo de referencia OSI". Estas entidades
implementaran las funciones denominadas de \Control de Polticas de Nivel"
(que marca los pasos a seguir a la entidad QoS de nivel en cada situacion) y
de \Control de QoS" que analiza los \requisitos QoS" solicitados por el usuario
del servicio de ese nivel (o del nivel correspondiente en un sistema remoto) y
selecciona las entidades que, a ese nivel, participaran en la comunicacion y que
tiene capacidad para satisfacer dichos requisitos QoS.
El procesamiento distribuido abierto segun el modelo de referencia ODP (Open Distributed Processing, Procesamiento Distribuido Abierto) 145, 139, 138, 144]. En
este caso, ISO e ITU-T estan trabajando en el desarrollo de la recomendacion X.906
(OSI/IEC 10746-6) 136] que combina los conceptos y principios de la recomendacion X.641, el modelo de referencia de ODP y otras iniciativas existentes 174] para
extender los conceptos y la arquitectura denidos en los estandares de ODP con el
objetivo de dar soporte a la especicacion y gestion de \caractersticas QoS". Dicho
trabajo, descrito en la siguiente seccion, esta teniendo una fuerte inuencia en los
intentos de OMG de introducir aspectos de calidad de servicio en su arquitectura
OMA (seccion 2.2) 88].
2.6 La Calidad de Servicio en las aplicaciones de objetos
distribuidos: QoS en ODP
En su estado actual (todava no tiene el caracter de estandar), la recomendacion
X.906 136] cubre las siguientes cuestiones:
1. Conceptos QoS en ODP: los conceptos y la terminologa de la recomendacion
X.641 se ampla con cuestiones especcas aplicables a ODP, un resumen de las
cuales se muestra en la tabla 2.311 .
2. Arquitectura de QoS en ODP: se dan unas pautas para la introduccion de
aspectos QoS en las cinco perspectivas prescritas por 138] para la descripcion
de un sistema de procesamiento distribuido ODP (introducidas en la seccion
2.2).
Si bien en 136] no se arma explcitamente que se este proponiendo una metodologa para la introduccion de aspectos QoS durante el desarrollo de un
sistema ODP, lo cierto es que, implcitamente, s se dan algunas \pautas metodologicas". As por ejemplo:
(a) Se indica como se debe abordar la calidad de servicio en cada una de las
perspectivas:
11
En 136] todos estos conceptos se formalizan utilizando el modelo semantico de Abadi y Lamport, de
la misma forma que se hace en 174].
30
2.6. La Calidad de Servicio en las aplicaciones de objetos distribuidos: QoS en ODP
Relacion QoS
Capacidades QoS
Oferta QoS
Contrato QoS
Composicion de Relaciones
QoS
Denicion de las obligaciones recprocas de un objeto y su entorno. Las relaciones QoS son los elementos basicos para expresar requisitos QoS, capacidades QoS, ofertas QoS y contratos QoS. En una relacion QoS se trata de
reejar tanto lo que un objeto espera de su entorno (expectaciones QoS), en
terminos de calidad de servicio, como lo que dicho objeto se compromete a
ofrecer a los objetos de dicho entorno (obligaciones QoS)
Conjunto de las caractersticas QoS proporcionadas por un objeto
Descripcion de un \anuncio" de QoS. Este concepto es aplicable en escenarios
de negociacion QoS, en los casos en que hay incertidumbre en el conocimiento
de las \capacidades QoS" reales y, por tanto, se tiene que hacer una estimacion
y en las ocasiones en que las capacidades QoS se dividen en subconjuntos y
se dan a conocer mediante ofertas QoS
Descripcion de un acuerdo que dene los conjuntos de capacidades QoS que
determinados objetos han accedido a proporcionar unos a otros y los requisitos QoS que intentaran satisfacer. Los contratos QoS se expresan mediante
conjuntos de relaciones QoS
Conjunto de relaciones QoS en el que el conjunto de obligaciones implica el
conjunto de expectaciones de cada una de las relaciones implicadas
Tabla 2.3: Conceptos QoS en ODP 136].
{ La \perspectiva de empresa" se centra en los \requisitos QoS" de la
totalidad del sistema ODP, los cuales se han de derivar del proposito, ambito y polticas para ese sistema dentro del entorno en el que
desarrolla sus funciones.
{ En las \perspectivas de informacion, computacion e ingeniera" se ha
de tener en cuenta los \requisitos QoS" de los componentes individuales
del sistema ODP los cuales, a su vez, se podran obtener a partir de los
\requisitos QoS" obtenidos en la \perspectiva de empresa"
{ La \perspectiva de tecnologa" se centra, como es obvio, en las \capacidades QoS" de la tecnologa en que se basan los componentes del
sistema ODP.
(b) Se dan algunas indicaciones de como solventar el problema de la introduccion de aspectos QoS en la perspectiva de ingeniera. Se se~nala que, para
ello, es conveniente considerar los objetos de ingeniera bajo estudio como
un sistema ODP en s mismo y aplicar sobre ellos, recursivamente, las cinco
perspectivas ODP introduciendo en ellas las cuestiones QoS.
(c) Se se~nala el hecho de que el tratamiento de la calidad de servicio a nivel
de empresa y a nivel computacional posee bastantes similitudes en ambos
casos. Muchas de las \caractersticas QoS" que aparecen en la perspectiva
de empresa, apareceran en la perspectiva computacional pero a diferente
nivel de detalle.
La tabla 2.4 muestra un resumen de las cuestiones mas importantes que, sobre
QoS, ISO/ITU-T recomiendan introducir en cada una de las perspectiva de un
sistema ODP durante su desarrollo12 .
3. Funciones de Gestion QoS: los trabajos de QoS en ODP renan las fases de
las actividades QoS que se denieron en la recomendacion X.641. En este caso,
se considera que la Gestion QoS se puede aplicar a las siguientes fases de una
actividad:
{ \a priori": los requisitos QoS se tiene en cuenta en el dise~no del sistema.
12
Aunque 136] reconoce tambien la necesidad de detallar la relacion entre las cuestiones QoS de las
diferentes perspectivas, aun no aporta una solucion concreta a este respecto.
31
Captulo 2. Ambito
de la Tesis: La gestion integrada de la calidad de servicio en
aplicaciones de objetos distribuidos
{ Antes de la inicializacion: los requisitos QoS se tienen en cuenta a la hora
de hacer una reserva previa de recursos
{ En el momento de la inicializacion: los requisitos QoS se negocian entre las
entidades participantes en la actividad
{ Durante la actividad: los requisitos QoS pueden cambiar durante el desarrollo de la actividad debido a cambios en los requisitos QoS, perdidas de
rendimiento, etc.
{ Historicamente: despues de que la actividad haya nalizado (analisis de
tendencias, monitorizacion de rendimiento a largo plazo, etc.).
Al igual que suceda en la recomendacion X.641, ISO/ITU-T estan trabajando
en la propuesta de una serie de \mecanismos QoS" genericos sobre los que basar
las \funciones de gestion QoS", mecanismos que quedaran plasmados en 134].
En la literatura se pueden encontrar diversos trabajos referidos a los principales
\mecanismos QoS" propuestos por el marco de QoS en ODP:
{ Negociacion: 207]
{ Control de recursos: 130, 196, 154]
{ Adaptacion: 198, 195, 109, 111, 110, 32]
{ Monitorizacion: este mecanismo es tratado con profundidad en la seccion
3.2.
4. Requisitos para notaciones capaces de expresar informacion QoS: en
136] se reconoce la necesidad de una notacion con la que expresar todas los tipos
de sentencias QoS necesarias para identicar y soportar aspectos de calidad de
servicio en sistemas ODP. Dicha notacion debera ser capaz de:
(a) Representar todos los tipos de valores de las caractersticas QoS: tiempos,
tasas, probabilidades, etc.
(b) Representar combinaciones de componente con ciertas propiedades QoS
(componentes cuyas propiedades QoS se tendran que combinar en serie, en
paralelo, jerarquicamente, etc.).
(c) Representar QoS que este distribuida espacialmente (dos valores QoS obtenidos de diferentes localizaciones que se tienen que comparar)
(d) Representar eventos de diferentes localizaciones que inician determinadas
actividades de medicion (tambien tendra que se capaz de indicar como se
llevan a cabo estas medidas) de tal forma que las medidas obtenidas se
combinen en una unica.
En 136] se propone una posible notacion para representar la informacion QoS en
la perspectiva computacional que se basa en el lenguaje ODL (Object Denition
Language, Lenguaje de Denicion de Objetos) de TINA-C 202]. Esa misma
notacion es la que ISO/ITU-T estan desarrollando como parte del denominado
ITU-ODL 148]. La notacion propuesta permite asociar caractersticas QoS a
interfaces de objetos (interfaces que pueden soportar tanto operaciones como
intercambio de datos multimedia). No obstante, como se reconoce tanto en
136] como en 148], la propuesta de notacion unicamente aporta, de momento,
una sintaxis pero no una semantica (alguna forma de indicar como afectan
los requisitos QoS al comportamiento de los objetos), lo que sera altamente
deseable.
32
2.6. La Calidad de Servicio en las aplicaciones de objetos distribuidos: QoS en ODP
Perspectiva de Empresa
8
>>
>>
>>
>>
>>
>>
><
>>
>>
>>
>>
>>
>>
>:
Requisitos QoS sobre
objetos
Requisitos QoS sobre
interacciones
Requisitos QoS que
afectan al modelo de
informacion
8<
:
8
>>
><
>>
>:
8
><
>:
Disponibilidad
Fiabilidad
Robustez
Capacidad
Requisitos QoS sobre informacion involucrada en interacciones
Requisitos QoS sobre las interacciones
en s
Requisitos QoS referentes a la relacion
de la informacion con el \mundo real"
n
Grado de actualizacion
Precision (granularidad)
8 Temporizacion
>< Capacidad
de error
>: Probabilidad
Seguridad
Precedencia
n Precision
Completitud
Requisitos QoS sobre el formato de la
informacion
Perspectiva de Informacion
(
Informacion sobre la QoS del sistema
Informacion necesaria para el soporte de las actividades QoS
Perspectiva de Computacion
8
>>
>>
>>
>>
>>
>>
>>
>>
>>
><
>>
>>
>>
>>
>>
>>
>>
>>
>>
>:
Requisitos QoS sobre
objetos
Requisitos QoS sobre
interacciones entre objetos
Modelado de Recursos
8
8 Disponibilidad
>>
>
>> Requisitos QoS sobre >< Fiabilidad
Robustez
inter>> comportamiento
>
>: Seguridad
>> no del objeto
Paralelismo
Tiempo de Procesamiento
>>
8 Actualizacion
><
Requisitos QoS sobre < Precision
informacion mante>> las
: Seguridad
Consistencia
>> nida por el objeto
>>
8
>> Requisitos QoS refe- < Fallo
Replicacion
a la transparen>> rentes
Persistencia
:
Transaccion
>: cia respecto a
8> Retardo
< Capacidad
de Error
>: Probabilidad
Seguridad
Precedencia
( Abstraccion de recursos compartidos de procesamiento y comunicacion (pers-
Perspectiva de Ingeniera
Traduccion de requisitos QoS
de la Perspectiva Computacional
pectiva de ingeniera) en la perspectiva computacional para permitir su manipulacion
(
Asignacion de Funciones de Gestion QoS a objetos de ingeniera
Asignacion de Requisitos QoS a objetos de ingeniera
Perspectiva de Tecnologa
Indicacion de las \Capacidades QoS" de las tecnologas empleadas
Tabla 2.4: La Calidad de Servicio en las perspectivas de ODP 136].
33
Captulo 2. Ambito
de la Tesis: La gestion integrada de la calidad de servicio en
aplicaciones de objetos distribuidos
34
Captulo 3
Motivaciones de la Tesis Doctoral
propuesta
Las caractersticas del entorno descrito en el captulo 2 muestran claramente la dicultades que hay que afrontar a la hora de desarrollar aplicaciones de objetos distribuidos cuya
calidad de servicio pueda ser gestionada de manera integrada. Esas dicultades se derivan,
fundamentalmente, de la heterogeneidad de las arquitecturas de gestion integrada y plataformas de procesamiento distribuido y de la ausencia de soluciones concretas normalizadas
para dar soporte a los diferentes aspectos relacionados con la calidad de servicio.
Este hecho trae consigo que soluciones desarrolladas para casos concretos no puedan
ser reutilizadas en contextos diferentes. Por ejemplo, un sistema de negociacion de la
calidad de servicio aplicado a aplicaciones CORBA e integrado en una plataforma de
gestion SNMP, no podra ser utilizado para resolver el mismo problema en un entorno
Java/RMI/JMX.
No obstante, tal y como se ha podido comprobar en el captulo 2, los conceptos que
constituyen la base de las diferentes arquitecturas de gestion integrada, de las diferentes
plataformas de procesamiento distribuido y de las diferentes arquitecturas de calidad de
servicio son bastante similares.
La Tesis Doctoral propuesta se plantea la posibilidad de \extraer" esos conceptos
comunes y aplicarlos, en la medida de los posible, de forma general al desarrollo de aplicaciones distribuidas con calidad de servicio gestionable de forma integrada.
Ahora bien, como se ha podido comprobar en el captulo 2, el ambito en el que
se encuadra la tesis doctoral propuesta y la problematica que motiva su desarrollo son
enormemente amplios. Es por ello por lo que la tesis doctoral propuesta se centra en
dos aspectos muy concretos: el problema de la especicacion de informacion de calidad de
servicio en aplicaciones de objetos distribuidos y el problema de la instrumentacion de estas
aplicaciones para dar soporte a la monitorizacion de la calidad de servicio especicada.
Estas dos cuestiones se abordan con mayor profundidad en las secciones 3.1 y 3.2.
35
Captulo 3. Motivaciones de la Tesis Doctoral propuesta
3.1 La especicacion de informacion de la calidad del servicio en aplicaciones de objetos distribuidos
En la seccion anterior se ha podido comprobar como el marco de QoS en ODP de ISO/ITUT destaca, como aspecto fundamental en la introduccion de aspectos QoS en aplicaciones
de objetos distribuidos, la existencia de un lenguaje adecuado para expresar todos los
posibles tipos de sentencias QoS.
Diversas propuestas se pueden encontrar en la literatura referidas al problema de la
especicacion de la calidad del servicio en aplicaciones de objetos distribuidos.
Dichas propuestas se pueden clasicar en las siguientes categoras:
1. Extensiones de lenguajes computacionales de plataformas de procesamiento distribuido orientado a objetos particulares.
QoS en ITU-ODL 148, 136]
ODL-Q 5, 4]
QIDL 27, 28]
2. Lenguajes independientes de la especicacion funcional de la aplicacion cuya QoS se
desea caracterizar pero que estan ligados a plataformas de procesamiento distribuido
orientado a objetos particulares.
QML 69, 70]
QDL 251, 21, 250, 180, 179, 220, 241]
3. Lenguajes formales particularizados al problema de la especicacion de informacion
QoS en aplicaciones de objetos distribuidos.
QoS en SDL-92 209]
Logica Temporal aplicada a la especicacion de informacion QoS 53]
SDL y Logica Temporal 175]
El primer grupo de lenguajes es el mas sencillo de utilizar pero tiene el inconveniente de que no permiten separar los aspectos de especicacion funcional de la aplicacion
distribuida de las especicacion de aspectos de calidad de servicio.
El segundo grupo separa los aspectos funcionales de los de calidad de servicio pero unicamente se pueden utilizar para aplicaciones soportadas por una arquitectura de
procesamiento distribuido orientada a objetos particular.
El ultimo grupo consigue separar aspectos funcionales de aspectos de calidad de
servicio a la vez que se mueven a un nivel de abstraccion tal que las especicaciones que
con ellos se hagan son potencialmente utilizables en aplicaciones soportadas por diferentes
plataformas de procesamiento distribuido orientado a objetos. Tienen como inconveniente
la complejidad inherente a las tecnicas de descripcion formal.
La tabla 3.1 compara estos lenguajes de especicacion de informacion QoS en funcion
de los siguientes criterios:
36
3.1. La especicacion de informacion de la calidad del servicio en aplicaciones de objetos
distribuidos
1. Soporte de conceptos QoS recogidos en los trabajos de ITU-T/ISO que, como ya se ha
comentado, constituyen el marco QoS de referencia para la tesis doctoral propuesta.
2. Grado de independencia respecto a la especicacion funcional de la aplicacion cuya
QoS se desea especicar. Es deseable un grado de independencia elevado para:
Poder desarrollar los aspectos funcionales de la aplicacion con la mayor independencia posible respecto a las cuestiones relacionadas con la calidad de
servicio.
Poder reutilizar especicaciones de informacion QoS asociandolas a especicaciones de multiples aplicaciones de objetos distribuidos.
3. Nivel de granularidad en las especicaciones de informacion QoS (la informacion
QoS hace referencia a interfaces computacionales, a operaciones de interfaces computacionales, a parametros de operaciones de interfaces computacionales, etc.).
4. Grado de independencia respecto a una arquitectura de procesamiento distribuido
orientado a objetos concreta. Ya se ha comentado el problema de la heterogeneidad
de arquitecturas de procesamiento distribuido que, al menos a medio plazo, va a
caracterizar el mundo de las aplicaciones distribuidas. Es conveniente, pues, tratar
de utilizar en el desarrollo de estas aplicaciones todos los conceptos, lenguajes y
herramientas posibles que no dependan de las particularidades de la arquitectura de
procesamiento distribuido que les va a dar soporte.
5. Propuesta de infraestructura de soporte para las especicaciones de informacion
QoS. La utilidad de las especicaciones de informacion QoS es cuestionable si no
se proporcionan mecanismos para su gestion: monitorizacion, control, negociacion,
adaptacion, etc.
6. Grado de exibilidad de la infraestructura de soporte para las especicaciones de
informacion QoS. Este criterio de comparacion hace referencia a si los mecanismos
de soporte de las especicaciones QoS son especcos de una arquitectura de procesamiento distribuido particular. Se trata de identicar la posibilidad de reutilizar el
dise~no de las infraestructuras propuestas en multiples arquitecturas de procesamiento distribuido orientado a objetos.
7. Nivel de formalidad (no formal, semi-formal, formal) de los lenguajes propuestos.
La conclusion mas importante que se puede extraer de la tabla 3.1 es que la utilizacion de lenguajes formales, independientes de los lenguajes de especicacion de interfaces
computacionales, permite denir informacion QoS sin tener en cuenta particularidades
de la plataforma de procesamiento distribuido orientado a objetos sobre la que se vaya a
ejecutar la aplicacion cuya QoS se quiere gestionar. Ahora bien, el problema asociado a los
lenguajes formales es su dicultad de uso y poca utilizacion en el desarrollo de aplicaciones
de objetos distribuidos 248]. Ademas, en las propuestas analizadas que utilizan lenguajes
de descripcion formal para especicar informacion QoS, dicha informacion QoS esta orientada principalmente hacia aspectos de rendimiento (una sola de las posibles categoras
QoS que pueden caracterizar a una aplicacion de objetos distribuidos).
La tesis doctoral propuesta se plantea el siguiente interrogante:
37
Captulo 3. Motivaciones de la Tesis Doctoral propuesta
Criterios ITU-
ODL
148]
ODL-Q QIDL
4]
27]
Lenguajes
QML
69]
QDL
180]
QoSSLD
209]
TL 53] SDLTL175]
(1)
++
++
+;
+;
+;
++
+;
;;
(2)
;;
;;
;;
++
++
++
++
++
(3)
;;
++
;;
++
++
+;
++
++
(4)
;;
;;
;;
;;
;;
++
++
++
(5)
;;
;;
++
++
++
;;
+;
+;
(6)
;;
;;
;;
;;
;;
;;
+;
+;
(7)
;;
+;
;;
+;
+;
++
++
++
Tabla 3.1: Tabla comparativa de las principales propuestas de lenguajes de especicacion
de informacion QoS en aplicaciones de objetos distribuidos. En ella se muestra el grado
de cumplimiento de los criterios de comparacion anteriormente descritos (++: alto, +;:
medio, ;;:bajo).
Puesto que la utilizacion de lenguajes de especicacion QoS basados en extensiones
de lenguajes de denicion de interfaces computaciones concretos implicaran solventar el problema de la especicacion QoS unicamente a casos particulares (lo cual
no es aconsejable debido al problema ya comentado de la heterogeneidad de las
plataformas de procesamiento distribuido),
Puesto que las tecnicas de especicacion formal solventaran el problema anterior
pero plantearan algunas dicultades de utilizacion (ademas de no existir una tecnica
de descripcion formal claramente mas extendida que las demas),
Puesto que UML 1 (Unied Modeling Language o Lenguaje Unicado de Modelado)
UML \proporciona a los arquitectos de sistemas que trabajen en analisis y dise~no orientado a objetos
un lenguaje para la especicacion, visualizacion, construccion y documentacion de los articios de sistemas
software, as como para el modelado de negocio" 99]. UML se esta utilizando como lenguaje de modelado
para el desarrollo de sistemas orientados a objetos en multitud de dominios. El de los sistemas de gestion
1
38
3.2. La instrumentacion de mecanismos de monitorizacion de la calidad de servicio en
aplicaciones de objetos distribuidos
99, 33, 216, 77] es el lenguaje de modelado mas extendido en la actualidad y se
utiliza como notacion para las fases de analisis y dise~no de multitud de metodologas
de desarrollo de aplicaciones de objetos distribuidos soportadas por diferentes plataformas de procesamiento distribuido (no en vano ha sido adoptado como el lenguaje
para analisis y dise~no orientado a objetos de OMG),
>no sera posible utilizar UML como base para la especicacion de informacion de
calidad del servicio en aplicaciones de objetos distribuidos?
3.2 La instrumentacion de mecanismos de monitorizacion
de la calidad de servicio en aplicaciones de objetos distribuidos
El marco de QoS en ODP identica una serie de mecanismos QoS basicos sobre los que
se apoyan las funciones QoS mas elaboradas. Como ya se comento en la seccion 2.6 no
existen soluciones estandar para implementar esos mecanismos.
De los mecanismos contenidos en el marco de QoS en ODP, el mecanismo de monitorizacion QoS se puede considerar como uno de los mas importantes de los empleados en
la \fase operativa". Los resultados de la monitorizacion del sistema constituyen el punto
de partida para la actuacion de otros mecanismos (adaptacion, negociacion, control de
recursos, etc.).
Cuando se estudian y comparan algunas de las mas importantes contribuciones que
en la literatura se pueden encontrar al respecto de la monitorizacion QoS en aplicaciones
distribuidas se aprecia un tratamiento deciente de dos cuestiones de gran importancia:
Como \extraer" de las aplicaciones de objetos distribuidos la informacion QoS que se
desea monitorizar (o, dicho de otro modo, como \instrumentar" las aplicaciones de
objetos distribuidos para que su QoS pueda ser monitorizada). Esta es una cuestion
que, en mayor o menor medida, afecta al desarrollo de la aplicacion cuya QoS se desea
monitorizar y, por tanto, debe de ser estudiada en profundidad. La meta a alcanzar es
conseguir unos mecanismos de instrumentacion lo mas transparente posible desde la
perspectiva de los desarrolladores de la parte funcional de la aplicacion monitorizada.
Como distribuir, de manera eciente y exible, el procesamiento de los datos de
monitorizacion. En diversas ocasiones puede ser interesante incluir funciones de procesamiento de la informacion de monitorizacion en la propia aplicacion monitorizada
para, de esa forma, reducir el intercambio de datos de monitorizacion entre diferentes componentes del sistema. La introduccion de esas funciones de monitorizacion
en la propia aplicacion monitorizada tambien debe de intentar llevarse a cabo de
la manera mas transparente posible. Las caractersticas propias de las aplicaciones
de objetos distribuidos aportan importantes ventajas en ese sentido: utilizando los
conceptos de ODP, la introduccion de la infraestructura de monitorizacion en el nivel
de ingeniera de la aplicacion a monitorizar, hara que dicha infraestructura fuera
transparente al desarrollador de la parte funcional de la aplicacion, el cual se ocupa
de aspectos de niveles de empresa, informacion y computacion.
integrada es, por ejemplo, uno de ellos 152, 200].
39
Captulo 3. Motivaciones de la Tesis Doctoral propuesta
Siguiendo esta lnea de razonamiento, la tabla 3.2 compara algunas de las propuestas
mas importantes2 que se pueden encontrar en la literatura acerca de la monitorizacion
QoS en sistemas distribuidos en funcion de los siguientes criterios:
1. Algunas de las propuestas analizadas incluyen un \lenguaje de monitorizacion" que
especica como se deben comportar los componentes funcionales que integran la infraestructura de monitorizacion. Este criterio hace referencia a la capacidad expresiva
de esos lenguajes.
2. Posibilidad de distribuir la infraestructura de monitorizacion.
3. Independencia la infraestructura de monitorizacion respecto a la instrumentacion de
la aplicacion monitorizada.
4. Grado de transparencia de la instrumentacion de la aplicacion monitorizada (el desarrollo de la aplicacion monitorizada no se ve afectado por la introduccion de la
instrumentacion de gestion).
5. Grado de exibilidad del tipo de instrumentacion propuesta (capacidad de llevar a
cabo procesamiento de informacion de monitorizacion en las propia instrumentacion
de la aplicacion).
Como se puede apreciar en la tabla 3.2 no hay ninguna iniciativa que trate de manera conjunta las cuestiones anteriormente comentadas (ademas, obviamente, de la propia
funcionalidad de monitorizacion): la instrumentacion de las aplicaciones para generar informacion de monitorizacion y la posibilidad de introducir, en esa misma instrumentacion,
funciones de procesamiento de informacion de monitorizacion.
Ante esta situacion, la tesis doctoral propuesta se plantea los siguientes interrogantes:
>Cual es la mejor forma de obtener informacion de monitorizacion QoS de la aplicacion de objetos distribuidos que se desea monitorizar? O, dicho de otra forma,
>cual es la mejor manera de instrumentar una aplicacion de objetos distribuidos
para poder monitorizar su calidad de servicio?
>No sera posible introducir, sin afectar al desarrollo de la parte funcional de la
aplicacion, funciones de procesamiento de informacion de monitorizacion QoS en
la propia aplicacion monitorizada con el objetivo de maximizar el rendimiento del
sistema de monitorizacion?
Son estos interrogantes, junto con el planteado en la seccion 3.1, los que han motivado
la realizacion de la tesis doctoral propuesta, tesis doctoral que se han planteado una serie
de objetivos, los cuales estan descritos en el siguiente captulo.
2
Algunas de las propuestas mostradas no tratan especcamente con aplicaciones de objetos distribuidos
pero, no obstante, las ideas que desarrollan son aplicables, igualmente, a ese ambito.
40
3.2. La instrumentacion de mecanismos de monitorizacion de la calidad de servicio en
aplicaciones de objetos distribuidos
Criterios GEM
181]
Stirling
212]
Propuestas Descritas
DMS
67]
SoLOMon MOTEL UWO
68]
248]
153]
(1)
++
;;
X
++
++
X
(2)
+;
+;
+;
+;
;;
+;
(3)
X
X
X
++
X
X
(4)
X
X
X
+;
++
X
(5)
;;
+;
+;
+;
;;
X
Tabla 3.2: Tabla comparativa de las principales propuestas de arquitecturas de infraestructura de monitorizacion e instrumentacion QoS en aplicaciones distribuidas. En ella se
muestra el grado de cumplimiento de los criterios de comparacion anteriormente descritos
(++: alto, +;: medio, ;;:bajo, X:aspecto no tratado).
41
Captulo 3. Motivaciones de la Tesis Doctoral propuesta
42
Captulo 4
Objetivos de la Tesis Doctoral
propuesta
Los objetivos concretos de la tesis doctoral propuesta se han de encuadrar dentro un
objetivo global que es el de posibilitar el desarrollo de aplicaciones genericas de objetos
distribuidos con calidad de servicio gestionable de forma integrada.
Ahora bien, la tesis doctoral propuesta, a la vista de las motivaciones descritas en
las secciones 3.1 y 3.2, centra sus esfuerzos en los siguientes objetivos particulares:
Denir un lenguaje de especicacion de informacion de calidad de servicio en aplicaciones de objetos distribuidos con los siguientes requisitos:
{ Permitir la especicacion de sentencias QoS que incluyan los conceptos QoS
{
{
{
{
denidos en los trabajos de ISO/ITU-T sobre QoS en ODP.
Permitir la especicacion de informacion QoS relacionada con cualquier categora de caractersticas QoS (no unicamente caractersticas QoS de rendimiento).
Permitir especicar informacion QoS referida a aspectos de las aplicaciones distribuidas que no sean particulares de las plataformas de procesamiento distribuido que las dan soporte. Dicho de otro modo, el lenguaje que se desea denir
debe ocuparse, utilizando la terminologa ODP, de aspectos computacionales y
de informacion.
Permitir especicar informacion QoS con el mayor nivel de granularidad posible (poder especicar informacion QoS referida a objetos en su totalidad, a
interfaces de esos objetos, a metodos de esas interfaces, etc.)
Permitir la obtencion, a partir de especicaciones de informacion QoS obtenidas con ese lenguaje, de modelos de informacion de gestion pertenecientes a
diferentes arquitecturas de gestion integrada. De esa manera, se facilitara la
integracion de los mecanismos QoS utilizados para soportar las especicaciones
QoS en sistemas de gestion integrada.
En relacion con este objetivo, la tesis doctoral propuesta se plantea el estudio de
la idoneidad de UML como lenguaje de especicacion de informacion QoS con los
anteriores requisitos.
43
Captulo 4. Objetivos de la Tesis Doctoral propuesta
Proponer mecanismos de instrumentacion de aplicaciones de objetos distribuidos que
permitan la monitorizacion de aspectos de calidad de servicio. Dichos mecanismos
han de cumplir los siguientes requisitos:
{ Permitir la obtencion de la informacion basica necesaria para monitorizar la
calidad de servicio proporcionada por una aplicacion de objetos distribuidos
(calidad de servicio que habra sido jada utilizando el correspondiente lenguaje
de especicacion de informacion QoS). La introduccion de esa instrumentacion
en la aplicacion de objetos distribuidos debera llevarse a cabo, en la medida que
sea posible, de forma transparente al desarrollador de los aspectos funcionales
de la aplicacion a instrumentar.
{ Introducir funciones de procesamiento de informacion de monitorizacion QoS
en la propia aplicacion para aumentar la exibilidad, el rendimiento y la escalabilidad de este tipo de mecanismos QoS.
44
No es objetivo de la tesis doctoral propuesta contribuir con un nuevo tipo de sistema
de monitorizacion sino, mas bien, extraer los conceptos y principios de funcionamiento de los ya existentes e identicar y proponer formas de aplicarlos de forma generica,
distribuida (exible) y eciente.
Aplicar los resultados obtenidos por la consecucion de los dos objetivos anteriores a
un caso de estudio real.
Captulo 5
Descripcion de las aportaciones de
la tesis doctoral propuesta
En este captulo se describen las contribuciones de la tesis doctoral propuesta, en relacion
con los objetivos planteados en el captulo 4, justicando algunas sus caracterstica mas
importantes:
Denicion de un lenguaje de especicacion de informacion QoS en aplicaciones de
objetos distribuidos que satisface los requisitos enunciados en el captulo 4.
Para satisfacer el requisito de independencia respecto a arquitecturas de procesamiento distribuido particulares, se ha decidido dise~nar el lenguaje para ser aplicado
sobre modelos de aplicaciones de objetos distribuidos que, en mayor o menor medida, reejen el resultado de analizar dichas aplicaciones desde las perspectivas de
informacion y computacional de ODP (las cuales no tienen en cuenta aspectos particulares de plataformas de procesamiento distribuido subyacente). Es importante
destacar que el objetivo de la tesis doctoral propuesta no es denir una metodologa
completa de desarrollo de aplicaciones de objetos distribuidos con QoS gestionable.
Tampoco se trata de aportar un proceso completo de ingeniera software (un ciclo
de vida). Lo que se intenta es aportar un conjunto de metodos de ingeniera software
(en este caso un lenguaje) que se puedan integrar en metodologas existentes para
tener en cuenta los aspectos de calidad de servicio.
Es por ello que para que el lenguaje de especicacion QoS pueda ser utilizado, se ha
de aplicar a procesos de desarrollo que generen modelos de la aplicacion compatibles
con los conceptos de RM-ODP.
Para alcanzar el objetivo de compromiso entre formalidad y facilidad de uso, se
ha decidido que el lenguaje propuesto este basado en una combinacion de UML
99, 77] y OCL 99, 246]: mediante un \perl UML" 103] se extiende el metamodelo
de este lenguaje para incluir los conceptos de calidad de servicio contenidos en los
trabajos de QoS en ODP (descritos en la seccion 2.4) y mediante OCL se especican
restricciones QoS sobre las especicacion QoS realizadas mediante ese perl UML.
Esta eleccion se debe a que:
{ UML es un lenguaje muy difundido actualmente y se utiliza como notacion en
45
Captulo 5. Descripcion de las aportaciones de la tesis doctoral propuesta
diversas metodologas de desarrollo software. UML 1 posee mecanismos de extension que permiten que se pueda particularizar a dominios especcos (como,
por ejemplo, la especicacion de interfaces CORBA-IDL 101, 97, 98]). En este
caso, se plantea extender UML para utilizarlo como lenguaje de especicacion
de informacion QoS. Esta aproximacion es, de hecho, la que OMG esta planteandose exigir para solicitar contribuciones al problema de la especicacion de
informacion QoS en aplicaciones CORBA 102].
{ OCL es un lenguaje semi-formal 2 que permite expresar restricciones sobre los
elementos de un modelo UML. Si la informacion QoS se especica utilizando
UML, OCL se convierte en el candidato ideal para expresar las restricciones
propias de QoS.
El hecho de que el lenguaje propuesto sea una extension de UML, obliga a que se
utilice sobre modelos computacionales o de informacion de aplicaciones distribuidas
que esten expresados con UML. Este hecho no acarrea excesivas dicultades puesto
que UML puede ser utilizado como lenguaje de perspectivas de ODP 90, 234].
La utilizacion de UML cuenta con otra ventaja importante: a partir de la informacion
QoS especicada, es posible generar modelos de informacion de gestion equivalentes
158] correspondientes a arquitecturas de gestion o de procesamiento distribuido
diferentes de las que dan soporte a la aplicacion monitorizada. Gracias a este hecho,
se facilita la integracion de la infraestructura de monitorizacion en cualquiera de las
arquitecturas de gestion integrada descritas en el captulo 2.
Mecanismos para facilitar el desarrollo de infraestructuras de monitorizacion QoS y
su instrumentacion en las aplicaciones de objetos distribuidos. En concreto, la tesis
doctoral propuesta identica los principales tipos de unidades funcionales que pueden
formar parte de una infraestructura de monitorizacion distribuida y propone extensiones de UML para poder modelar sus interacciones (entre s y con los componentes
de la aplicacion a monitorizar). Si se interpreta que un sistema de monitorizacion es
en s un sistema ODP, se podra armar que los aspectos computacionales de dicho
sistema quedaran reejados dentro del modelo de ingeniera de la aplicacion a monitorizar. De esa forma, y en funcion de con que componentes del modelo de ingeniera
de la aplicacion gestionada interaccionen los objetos computacionales del sistema de
monitorizacion, se decidira como seran las interacciones de estos a nivel de ingeniera.
Obviamente estas interacciones a nivel de ingeniera se pueden llevar a la practica
utilizando plataformas de procesamiento distribuido que no tienen necesariamente
que coincidir con la utilizada para dar soporte a la aplicacion monitorizada.
La tesis doctoral propuesta no tiene como objetivo proponer un nuevo sistema de
monitorizacion de aplicaciones de objetos distribuidos sino proporcionar herramientas con las que instrumentar mecanismos de monitorizacion QoS en ese tipo de
aplicaciones. Estos mecanismos podran ser implementados aprovechando las funcionalidades de los sistemas de monitorizacion ya existentes. Por ello, la tesis doctoral
propuesta proporciona e identica patrones de dise~no que se pueden aplicar para
solventar el problema de la instrumentacion de mecanismos de monitorizacion QoS
en aplicaciones de objetos distribuidos de la forma mas transparente posible a los
desarrolladores de la aplicacion a monitorizar.
UML no es un lenguaje de especicacion formal pero el denominado \Precise Group UML" 59, 159,
57, 58] ha puesto en marcha diversas iniciativas para alcanzar ese objetivo.
2
En 213, 115, 57] se describen iniciativas destinadas a la formalizacion de OCL.
1
46
Todas las contribuciones anteriores se aplican al caso particular de la monitorizacion
QoS de una aplicacion de objetos distribuidos (CORBA) que proporciona un servicio
de intermediacion electronica 13, 14, 18, 242]. Dicha monitorizacion se integra dentro
de un sistema de gestion basado en SNMP 15, 16, 50, 51]
47
Captulo 5. Descripcion de las aportaciones de la tesis doctoral propuesta
48
Referencias
1] JavaBeans Specication v1.01. Sun Microsystems, July 1997.
2] A Detailed Comparison of CORBA, DCOM and Java/RMI. Documento Internet
http://www.execpc.com/ gopalan/misc/compare.html, 1998.
3] Middleware.org. Documento Internet http://www.middleware.org, 2000.
4] J.O. Aagedal. Towards an ODP-compliant Object Denition Language with QoSsupport. In Proceedings of the 5th International workshop on Interactive Distributed
Multimedia Systems and Telecommunication Services (IDMS'98), Oslo, Noruega,
Septiembre 1998.
5] J.O. Aagedal and A.-J. Berre. ODP-based QoS-support in UML. In Proceedings of
the First International Enterprise Distributed Object Computing Workshop (EDOC'97), pages 310{321. Gold Coast, Australia, Octubre 1997.
6] J.O. Aagedal, A.-J. Berre, V. Goebel, and T. Plagemann. Object-Oriented RoleModeling with QoS Support for the ODP Viewpoints. In Joint International Conference on Open Distributed Processing (ICODP) and Distributed Platforms (ICDP),
Ottawa, Canada, 1997.
7] Proyecto ABS. Architecture and System Specication. Informe Tecnico D31, Marzo
1997.
8] Proyecto ABS. Broker System version 2. Informe Tecnico D32, Abril 1998.
9] S.S. Alhir. Extending the Unies Modeling Language (UML). Documento Internet
http://home.earthlink.net/ salhir/ExtendingTheUML.PDF, 1999.
10] E. Anu . The JAVA Sourcebook. John Willey & Sons, 1996.
11] M. Appledorn, R. Kung, and R. Saracco. TMN+IN = TINA. IEEE Communications
Magazine, 31(3):78{85, Marzo 1993.
12] J.I. Asensio, C.A. Iglesias, A. Tardon, and A. Vielba. La Gestion de Red en Internet.
In 54]. 1998.
13] J.I. Asensio, J.I. Moreno, and V.A. Villagra. Modelado del servicio de intermediacion electronica (brokerage) segun el modelo de referencia de ODP: perspectiva de
negocio. In Actas de las Primeras Jornadas de Ingeniera Telematica (JITEL'97),
Bilbao, Espa~na, Septiembre 1997.
49
Referencias
14] J.I. Asensio, J.I. Moreno, V.A. Villagra, J. Redondo, A. Nolle, I. Tothezan, and G.T.
Karetsos. Application of TINA-C Computing and Service Architecture Concepts to
the Development of an Advanced Information Brokerage Service in the context of
EC. In Proceedings of the TINA'97 Conference, Santiago, Chile, Noviembre 1997.
15] J.I. Asensio and V.A. Villagra. A simplied approach to the management of a
CORBA-based electronic brokerage application. In Proceedings of the 5th HP OpenView University Association Plenary Workshop (HPOVUA'98), ENST Bretagne,
Rennes, Francia, Abril 1998.
16] J.I. Asensio, V.A. Villagra, J.E. Lopez de Vergara, and J. Berrocal. Experiences with
the SNMP-based integrated management of a CORBA-based electronic commerce
application. In 227], pages 517{530. 1999.
17] J.I. Asensio, V.A. Villagra, and R. Mompo. Management of distributed information
services: application to the Information Brokerage Service (ABS project). In Proceedings of the 4th HP OpenView University Association Plenary Workshop (HPOVUA'97), ETSI Telecomunicacion. Universidad Politecnica de Madrid, Madrid, Espa~na, Abril 1997.
18] J.I. Asensio, V.A. Villagra, J.I. Moreno, and J. Berrocal. An Approach to Electronic
Brokerage in TINA Environments. In 238], pages 339{350. 1998.
19] C. Aurrecoechea, A. Lazar, and R. Stadler. Opening Network Services for Management. In Proceedings fo the rst IEEE Conference on Open Architectures and Network Programming (OPENARCH'98), San Francisco, California, USA, Abril 1998.
20] S. Baker, V. Cahill, and P. Nixon. Bridging Boundaries: CORBA in perspective.
IEEE Internet Computing, 1(5):52{57, Septiembre/Octubre 1997.
21] D.E. Bakken. Object-Oriented QoS: Some Research Issues. In DARPA QoS Architecture Meeting, 37th IETF Meeting, San Jose, California, USA, Diciembre 1996.
22] B. Ban. Extending CORBA for Multi-Domain Management. In Proceedings of
Distributed Object-Oriented Computing for Telecom (DOCT'96), ObjectWorld'96,
Frankfurt, Alemania, 1996.
23] B. Ban. Open distributed processing: A reference model for distributed processing.
Technical report, Institute of Computer Science, University of Zurich, 1996.
24] B. Ban. Towards a Generic Object-Oriented Model for Multi-Domain Management.
In Proceedings of the 10th European Conference on Object-Oriented Programming
(ECOOP'96), Lonz, Austria, 1996.
25] B. Ban. A generic management model for CORBA, CMIP and SNMP. PhD thesis,
Universidad de Zurich, Diciembre 1997.
26] W.J. Barr, T. Boyd, and Y. Inoue. The TINA initiative. IEEE Communications
Magazine, 31(3):71{76, Marzo 1993.
27] C. Becker and K. Geihs. MAQS - Management for Adaptive QoS-enabled Services.
In Proceedings of the IEEE Workshop on Middleware for Distributed Real-Time
Systems and Services, San Francisco, California, USA, Diciembre 1997.
50
Referencias
28] C. Becker and K. Geihs. Quality of Service - Aspects of Distributed Programs.
In Proceedings of the International Workshop on Aspect-Oriented Programming at
ICSE'98, Kyoto, Japon, 1998.
29] I. Ben-Shaul and G. Kaiser. Coordinating Distributed Components over the Internet.
IEEE Internet Computing, 2(2):83{86, Marzo/Abril 1998.
30] M. Benda. Application on the Global Computer. IEEE Internet Computing, 1(3):74{
77, Mayo/Junio 1997.
31] M. Benda. Middleware: Any Client, Any Server. IEEE Internet Computing, 1(4):94{
96, Julio/Agosto 1997.
32] G. Blair, G. Coulson, N. Davies, P. Robin, and T. Fitzpatrick. Adaptive Middleware for Mobile Multimedia Applications. In Proceedings of the 8th International
Workshop on Network and Operating Systems Support for Digital Audio and Video
(NOSSDAV'97), Mayo 1997.
33] G. Booch, J. Rumbaugh, and I. Jacobson. The Unied Modeling Language User
Guide. Addison-Wesley, 1999.
34] R. Boutaba, K. El Guemhioui, and P. Dini. An Outlook on Intranet Management.
IEEE Communications Magazine, 35(10):92{99, Octubre 1997.
35] N. Brown and C. Kindel. Distributed Component Object Model Protocol DCOM/1.0. Microsoft Corporation. Internet Draft draft-brown-dcom-v1-spec03.txt, Enero 1998.
36] C. Krupczak and J. Saperia. Denition of System-Level Managed Objects for Applications. Internet Request for Comments 2287, Febrero 1998.
37] A. Campbell, C. Aurrecoechea, and L. Hauw. A review of QoS Architectures. ACM
Multimedia Systems Journal, 1996.
38] J. Case, R. Mundy, D. Partain, and B. Stewart. Introduction to Version 3 of the
Internet-standard Network Management Framework. Internet Request for Comments
2570, Abril 1999.
39] J.D. Case, M.S. Fedor, M.L. Scho stall, and R. Davin. A Simple Network Management Protocol. Internet Request for Comments 1157, 1990.
40] R. Chadha and S. Wu. Incorporating Manageability into Distributed Software. In
173], pages 489{501.
41] M. Chapman and S. Montesi. Overall Concepts and Principles of TINA. TINA
Consortium, 1995.
42] D. Curtis. Java, RMI and CORBA. Object Management Group White Paper.
Documento Internet http://www.omg.org/news/wpjava.htm, 1997.
43] L.A. de la Fuente, M. Kawanishi, M. Wakano, T. Walles, and C. Aurrecoechea.
Application of the TINA-C Management Architecture. In 222], pages 424{435.
1995.
44] L.A. de la Fuente, J. Pavon, and N. Singer. Application of TINA-C Architecture to
Management Services. pages 273{284. 1994.
51
Referencias
45] L.A. de la Fuente and T. Walles. Management Architecture version 2.0. TINA
Consortium, Diciembre 1994.
46] J. de Meer. On the Specication of End-to-End QoS Control. In Proceedings of the
5th IFIP International Workshop on Quality of Service (IWQoS'97), Nueva York,
USA, Mayo 1997.
47] J. de Meer. On Inventing QoS to TINA or CORBA-based Systems. Presentacion en
NEC Berlin, Abril 1998.
48] J. de Meer and A. Had. The Enterprise of QoS. Tutorial presentado en el IFIP
International Conference on Distributed Systems Platforms and Open Distributed
Processing (Middelware'98), Septiembre 1998.
49] J. de Meer, A. Rennoch, and A. Puder. Towards a QoS Binding Notation. In
Proceedings of the National FBT'98 Workshop, Cottbus, Alemania, Junio 1998.
50] J.-E. Lopez de Vergara. Dise~no e implementacion de un sistema para la gestion de
una aplicacion distribuida de intermediacion electronica. Proyecto Fin de Carrera,
Departamento de Ingeniera de Sistemas Telematicos. Universidad Politecnica de
Madrid, Septiembre 1998.
51] J.-E. Lopez de Vergara, V.A. Villagra, J.I. Asensio, J.I. Moreno, and J.J. Berrocal.
Experiencias en la gestion de aplicaciones distribuidas. In Actas de las IX Jornadas
de I+D en Telecomunicaciones (TELECOM I+D, Madrid/Barcelona, Noviembre
1999.
52] L. Deri and B. Ban. Static vs. Dynamic CMIP/SNMP Network Management Using
CORBA. In 173], pages 329{337. 1997.
53] F. Dietrich, X. Logean, S. Koppenhofer, and J.-P. Hubaux. Modelling and Testing
Object-Oriented Distributed Systems with Linear-time Temporal Logic. Technical
report, EPFL, Mayo 1998.
54] Y.A. Dimitriadis and F.J. Daz. Introduccion a la Administracion Practica de Sistemas en Internet. Servicio de Publicaciones de la Universidad de Valladolid, 1998.
55] A. Dittrich, S. Rasmussen, and D. O'Sullivan. Co-existence of TMN and CORBA
for Service Management. In Proceedings of ISADS'97, Berlin, Alemania, 1997.
56] C. Doherty and T. Uslander. An enterprise corba application management architecture. Journal of Network and Systems Management, 7(1):127{132, 1999.
57] A. Evans, S. Cook, S. Mellor, J. Warmer, and A. Wills. Advanced Methods and
Tools for a Precise UML (panel paper). In Proceedings of the 2nd International
Conference on UML (UML'99), Fort Collins, Colorado, Estados Unidos, Octubre
1999.
58] A. Evans, R. France, K. Lano, and B. Bumpe. Meta-Modelling Semantics of UML.
In 162], chapter 4. 1999.
59] A. Evans, R. France, K. Lano, and B. Rumpe. The UML as a Formal Modeling
Notation. In 150]. 1998.
60] E. Evans and D. Rogers. Using JAVA Applets and CORBA for Multi-User Distributed Applications. IEEE Internet Computing, 1(3):43{55, Mayo/Junio 1997.
52
Referencias
61] F. Dietrich. Modelling Object-Oriented Communication Services with Temporal Logic. PhD thesis, EPFL, 1999.
62] P. Ferguson and G. Huston. Quality of Service: Delivering QoS on the Internet and
in Corporate Networks. John Wiley & Sons, 1998.
63] Distributed Management Task Force. Common Information Model (CIM) Specication (version 2.2). Junio 1999.
64] Network Management Forum. ISO/CCITT to Internet Management Proxy. Network
Management Forum: Forum 028, 1993.
65] Network Management Forum. Translation of Internet MIBs to ISO/CCITT GDMO
MIBs. Network Management Forum: Forum 026, 1993.
66] Network Management Forum. Translation of ISO/CCITT GDMO MIBs to Internet
MIBs. Network Management Forum: Forum 030, 1993.
67] R. Friedich, J. Martinka, T. Sienknecht, and S. Saunders. Integration of Performance
Measurement and Modeling for Open Distributed Processing. Technical Report
HPL-95-10, HP Laboratories, 1995.
68] S. Frolund, M. Jain, and J. Pruyne. SoLOMon: Monitoring End-User Service Levels.
Technical Report HPL-98-153, HP Laboratories, 1998.
69] S. Frolund and J. Koistinen. QML: A Language for Quality of Service Specication.
Technical Report HPL-98-10, HP Laboratories, 1998.
70] S. Frolund and J. Koistinen. Quality of Service Aware Distributed Object Systems.
Technical Report HPL-98-142, HP Laboratories, 1998.
71] S. Frolund and J. Koistinen. Quality-of-Service Specication in Distributed Object
Systems. Distributed Systems Engineering Journal, 5(4), Diciembre 1998. Tambien
publicado como HP Laboratories Technical Report HPL-98-159.
72] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of
Reusable Object-Oriented Software. Addion-Wesley, 1995.
73] G.H. Genilloud. Towards a Distributed Architecture for Systems Management. PhD
thesis, EPFL, 1996.
74] J. Gil and D.H. Lorenz. Design Patterns and Language Design. Computer, 31(3):118{
120, Marzo 1998.
75] R.H. Glitho and S. Hayes. Telecommunications management network: Vision vs.
reality. IEEE Communications Magazine, 33(3):47{52, Marzo 1995.
76] V. Goebel and T. Plagemann. OMODIS - Object-Oriented Modeling and Database
Support for Distributed Multimedia Systems. In Proceedings of the Norsk Informatikk Konferanse (NIK'96), Alta, Noruega, Noviembre 1996.
77] M. Gogolla. Uml for the impatient. Technical report, Universidad de Bremen, 1998.
Research Report 3/98.
78] G. Goldszmidt and Y. Yemini. Delegated Agents for Network Management. IEEE
Communications Magazine, 36(3):66{70, Marzo 1998.
53
Referencias
79] R. Gopalakrishnan and G.M. Parulkar. E$cient quality of service support in multimedia computer operating systems. Technical Report WUCS-TM-94-04, Department of Computer Science, Washington University, Agosto 1994.
80] M. Grand. Patterns in Java. Volume 1: a catalog of resuable design patterns illustrated with UML. Wiley Computer Publishing, 1999.
81] M. Grand. Patterns in Java. Volume 2. Wiley Computer Publishing, 1999.
82] Object Management Group. CORBA Facilities Architecture. OMG document
formal/98-07-10, Noviembre 1995.
83] Object Management Group. Electronic Commerce DTF Reference Model. OMG
document ec/96-09-03, Septiembre 1996.
84] Object Management Group. CORBAServices: Common Object Services Specication. OMG document formal/98-07-05, Julio 1997.
85] Object Management Group. Meta Object Facility (MOF). OMG document ad/9708-14, Septiembre 1997.
86] Object Management Group. Meta Object Facility (MOF) Appendices. OMG document ad/97-08-15, Septiembre 1997.
87] Object Management Group. Object Constraint Language Specicacion. OMG document ad/97-08-08, Agosto 1997.
88] Object Management Group. Quality of Service (QoS) OMG Green Paper. OMG
document om/07-03-06, 1997.
89] Object Management Group. UML Semantics. OMG document ad/97-08-04, Septiembre 1997.
90] Object Management Group. UML Semantics: Relationship to Reference Model of
Open Distributed Computing. OMG document ad/97-01-08, Enero 1997.
91] Object Management Group. Common Object Request Broker: Arhitecture and Specication. Revision 2.2. OMG document telecom/98-07-01, Febrero 1998.
92] Object Management Group. CORBA/TMN Interworking Final Submission - JIDM
Interaction Translation. OMG document telecom/98-05-02, Mayo 1998.
93] Object Management Group. CORBA/TMN Interworking Final Submission - JIDM
SNMP. OMG document telecom/98-05-03, Mayo 1998.
94] Object Management Group. DSTC/Digital Equipment Revised DCE/CORBA Interworking RFP Submission. OMG document orbos/98-06-01, Mayo 1998.
95] Object Management Group. Common Object Request Broker: Architecture and Specication. Revision 2.3.1. OMG document orbos/99-10-07, Octubre 1999.
96] Object Management Group. CORBA Components. OMG document orbos/99-02-05,
Marzo 1999.
97] Object Management Group. DAC/GDC/Telelogic/UBS Joint Initial Submission to
UML Prole for CORBA RFP. OMG document ad/99-08-01, Agosto 1999.
54
Referencias
98] Object Management Group. DSTC Initial Submission to UML Prole for CORBA
RFP. OMG document ad/99-08-02, Agosto 1999.
99] Object Management Group. OMG Unied Modeling Language Specication version
1.3. OMG document ad/99-06-08, Junio 1999.
100] Object Management Group. Portable Interceptors Request for Proposals. OMG
document orbos/98-09-11, Septiembre 1999.
101] Object Management Group. RFP: UML Prole for CORBA. OMG document
ad/99-03-11, Marzo 1999.
102] Object Management Group. UML Prole for QoS and Fault Tolerance Request for
Proposal Draft 2. OMG document ad/99-08-06, Agosto 1999.
103] Object Management Group. White Paper on the Prole Mechanism. OMG document
ad/99-04-07, Abril 1999.
104] Object Managemet Group. Object Management Architecture Guide. OMG document
ab/97-05-05, Julio 1995.
105] The Open Group. DCE 1.2.2 Documentation. Document number T.151, Noviembre
1997.
106] The Open Group. Inter-Domain Management: Specication Translation. The Open
Group Preliminary Specication P509, Marzo 1997.
107] The Open Group. Distributed Computing for the Extended Enterprise. Discussion
Paper, Julio 1998.
108] A. Gupta, C. Ferris, Y. Wilson, and K. Venkatasubramanian. Implementing Java
Computing: Sun on Architecture and Applications Development. IEEE Internet
Computing, 2(2):60{64, Marzo/Abril 1998.
109] A. Had and G. von Bochmann. An Approach to QoS Management in Distributed
MM Applications: Design and an Implementation. Multimedia Tools and Applications Journal, 1997.
110] A. Had and G. von Bochmann. Quality of Service Adaptation in Distributed
Multimedia Applications. ACM Multimedia Systems Journal, 1997.
111] A. Had, G. von Bochmann, and R. Dssouli. Quality of Service Negotiation with
Present and Future Reservations (NAFUR). Computer Networks and ISDN Systems,
1997.
112] A. Had, G. von Bochmann, and R. Dssouli. Distributed Multimedia Applications
and Quality of Service: a Review. The Electronic Journal on Networks and Distributed Processing, issue 6, Febrero 1998.
113] A. Hamie, F. Civello, J. Howse, and S. Kent. Reections on the Object Constrint
Language. In 150]. 1998.
114] A. Hamie, F. Civello, J. Howse, S. Kent, and R. Mitchell. Reections on the object
constraint language. In 150], page 1998.
115] A. Hamie, J. Howse, and S. Kent. Interpreting the Object Constraint Language. In
Proceedings of the Asia-Pacic Conference in Software Engineering, Enero 1998.
55
Referencias
116] P. Harmon and M. Watson. Understading UML: the Developer's Guide with a Webbased Application in Java. Morgan Kaufmann Publishers, 1998.
117] M. Harssena. Integrating TMN and CORBA. Master's thesis, Universidad de Twente, Holanda, Octubre 1996.
118] H.-G. Hegering, S. Abeck, and B. Neumair. Integrated Management of Networked
Systems. Morgan Kaufmann, 1999.
119] H.-G. Hegering and Y. Yemini, editors. Integrated Network Management III. Proceedings of the third IFIP/IEEE International Symposium on Integrated Netork
Management. San Francisco, California, USA. Abril 1993. Elsevier Science Publishers B.V. (North-Holland), 1993.
120] A. Herbert. ANSA Overview. Architecture Projects Management Ltd. (APM).
Technical Report APM.1535.02, Enero 1996.
121] A. Herbert and M. Faupel. DIMMA Architecture Overview. Architecture Projects
Management Ltd. (APM). Technical Report APM.2065.01, Septiembre 1996.
122] Y. Ho ner. The Management of Monitoring in Object-Based Distributed Systems.
In 119], pages 235{246. 1993.
123] J.W. Hong, M.J. Katchabaw, M.A. Bauer, and H. Lutyya. Distributed Applications
Management Using the OSI Management Framework. In Proceedings of the 12th
International Conference on Computer Communication (ICCC'95), Agosto 1995.
124] J.W. Hong, J.S. Kim, and J.T. Park. A CORBA-based Quality-of-Service Management Framwork for Distributed Multimedia Services and Applications. In Proceedings of the IFIP/IEEE International Workshop on Distributed Systems: Operations
and Management (DSOM'98), Newark, Delaware, USA, Octubre 1998.
125] J.W. Hong, J.-Y. Kong, T.-H. Yun, J.-S. Kim, J.-T. Park, and J.-W. Baek. WebBased Intranet Services and Network Management. IEEE Communications Magazine, 35(10):100{110, Octubre 1997.
126] J.-F. Huard and A.A. Lazar. On End-to-End QoS Mapping. In Proceedings of the
5th IFIP International Workshop on Quality of Service (IWQoS'97), Nueva York,
USA, Mayo 1997.
127] J.-F. Huard and A.A. Lazar. On QoS Mapping in Multimedia Networks. In Proceedings of the 21st IEEE Annual International Computer Software and Application
Conference (COMPSAC'97), Washington, D.C., USA, Agosto 1997.
128] J.-F. Huard and A.A. Lazar. A Programmable Transport Architecture with QoS
Guarantees. IEEE Communications Magazine, 36(10):54{62, Octubre 1998.
129] D. Hull, A. Shankar, K. Nahrstedt, and J.W. Liu. And End-to-End QoS model
and management architecture. In Proceedings of the IEEE Workshop on Middleware for Distributed Real-time Systems and Services, San Francisco, California, USA,
Diciembre 1997.
130] M. Humphrey, S. Brandt, G. Nutt, and T. Berk. The DQM Architecture: Middleware for Application-centered QoS Resource Management. In Proceedings of the
IEEE Workshop on Middleware for Distributed Real-time Systems and Services, San
Francisco, California, USA, Diciembre 1997.
56
Referencias
131] International Middleware Association. A Middleware Taxonomy. Documento Internet http://www.moma-inc.org/education/taxonomy.html.
132] ISO. Information Processing Systems - Open Systems Interconnection - Basic Reference Model. ISO/IEC IS 7498, 1984.
133] ISO. Information Technology - Open Systems Interconnection - Systems Management Overview. ISO/IEC IS 10040, 1992.
134] ISO. Information Technology - Quality of Service - Guide to Methods and Mechanisms - Technical Report Type III. ISO/IEC JTC/SC21, Project JTC1.21.57.
Editor's nal DTR pending approval by ITU-T, Octubre 1997.
135] ISO. Revised Text of ISO/IEC 13244 fpDAM 1, ODMA CORBA Support. ISO/IEC
13244 fDAM 1 / ITU-T Recommendation X. 703 Draft Amnd. 1, Enero 1998.
136] ISO. Working Draft for: Open Distributed Processing - Reference Model - Quality
of Service. ISO/IEC JTC1/SC N 10979 Ed 6.4, Enero 1998.
137] ITU-T. CCITT Specication and Description Language (SDL). ITU-T Recommendation Z.100, Marzo 1993.
138] ITU-T. Information Technology - Open Distributed Processing - Reference Model:
Architecture. ITU-T Recommendation X.903 (ISO/IEC DIS 10746-3), Noviembre
1995.
139] ITU-T. Information Technology - Open Distributed Processing - Reference Model:
Foundations. ITU-T Recommendation X.902 (ISO/IEC DIS 10746-2), Diciembre
1995.
140] ITU-T. Management of the transport Network - Application of the RM-ODP framework. ITU-T Recommendation G.851.1, Noviembre 1996.
141] ITU-T. Management of the transport Network - Enterprise viewpoint for simple
subnetwork connection management. ITU-T Recommendation G.852.1, Noviembre
1996.
142] ITU-T. Principles for a Telecommunication Management Network. ITU-T Recommendation M.3010, Mayo 1996.
143] ITU-T. Information Technology - Open Distributed Processing - Interface Denition
Language. ITU-T Recommendation X.920, Diciembre 1997.
144] ITU-T. Information Technology - Open Distributed Processing - Reference Model:
Architectural Semantics. ITU-T Recommendation X.904 (ISO/IEC DIS 10746-4),
Diciembre 1997.
145] ITU-T. Information Technology - Open Distributed Processing - Reference Model:
Overview. ITU-T Recommendation X.901 (ISO/IEC DIS 10746-1), Diciembre 1997.
146] ITU-T. Information Technology - Quality of Service: Framework. ITU-T Recommendation X.641 (ISO/IEC IS 13236), Diciembre 1997.
147] ITU-T. Information Technology - Open Distributed Management Architecture. ITUT Recommendation X.703 (result form JTC1/SC21/WG7 Berlin meeting, Enero
1998.
57
Referencias
148] ITU-T. Object Denition Language. Draft ITU-T Recommendation Z.130, Octubre
1998.
149] ITU-T. Message Sequence Chart (MSC). ITU-T Pre-Published Recommendation
Z.120, Noviembre 1999.
150] J. Bezivin, P.-A. Muller, editor. The Unied Modeling Language Workshop (UML'98): Beyond the Notation. Proceedings of the First International Workshop on
UML (UML'98), Mulhouse, Francia. Junio 1998. Lecture Notes in Computer Science (1618). 1998.
151] P. Kalyanasundaram and A.S. Sethi. Interoperability issues in heteroteneous network
management. Journal of Network and Systems Management, 2, Junio 1994.
152] M.M. Kande, S. Shahrzade, O. Prnjar, L. Stacks, and M. Wittig. Applying UML to
Design an Inter-Domain Service Management Application: a case study based on the
ACTS Project TRUMPET. In Proceedings of the UML'98 Conference, Mulhouse,
Francia, Junio 1998.
153] M.J. Katchabaw, S.L. Howard, H.L. Lutyya, A.D. Marshall, and M.A. Bauer. Making distributed applications manageable through instrumentation. In Proceedings
of the 2nd International Workshop on Software Engineering for Pararell and Distributed Systemas (PDSE'97), Boston, Massachusetts, USA, Mayo 1997.
154] M.J. Katchabaw, H.L. Lutyya, and M.A. Bauer. A Model for Resource Management
to Support End-to-End Application-Driven Quality of Service. Technical Report 528,
Department of Compurter Science, Universidad de Western Ontario, Julio 1998.
155] A. Keller. Towards CORBA-based Enterprise Management: Managing CORBAbased Systems with SNMP Platforms. In Proceedings of the Second International
Enterprise Distributed Objecto Computing Workshop (EDOC'98), San Diego, CA,
USA, Noviembre 1998.
156] A. Keller. Towards Interoperable Management Architectures: Making SNMP Management Platforms suitable fot CORBA. In Proceedings of the 5th HP OpenView
University Association Plenary Workshop (HPOVUA'98), ENST Bretagne, Rennes,
Francia, Abril 1998.
157] A. Keller. Managing the Management: CORBA-based Instrumentation of Management Systems. In 227], pages 577{590. 1999.
158] A. Keller and B. Neumair. Using ODP as a Framework for CORBA-based Distributed Application Management. In Proceedings of the IFIP/IEEE Joint International
Conference on Open Distributed PRocessing (ICODP) and Distributed Platforms
(ICDP), Toronto, Canada, Mayo 1997.
159] S. Kent, S. Gaito, and N. Ross. A meta-model semantics for structural constraints
on UML. In 162], chapter 9, pages 121{139.
160] B. Khasnabish and R. Saracco. Intranets: Technologies. Services, and Management.
IEEE Communications Magazine, 35(10):84{91, Octubre 1997.
161] D. Kiely. Are Components the Future of Software? Computer, 31(2):10{11, Febrero
1998.
58
Referencias
162] H. Kilov, B. Rumpe, and I. Simmons, editors. Behavioral Specication for business
and systems. Kluwer Academic Plubishers, Norwell, MA, USA, Septiembre 1999.
163] J.-S. Kim, J.W. Hong, and H.-W. Park. Design and Implementation of Quality of
Service (QoS) MIB for Distributed Multimedia Services. In Proceedings of IEEE
GLOBECOM'98, Sydney, Australia, Noviembre 1998.
164] J. Koistinen. Dimensions for Reliability Contracts in Distributed Object Systems.
Technical Report HPL-97-119, HP Laboratories, 1997.
165] J. Koistinen. Worth-Based Multi-Category Quality-of-Service Negotiation in Distributed Object Infrastructures. Technical Report HPL-98-51R1, HP Laboratories,
1998.
166] J.-Y. Kong, J.W. Hong, J.T. Park, and D.-J. Kim. A CORBA-based Management
Framework for Distributed Multimedia Services and Applications. In Proceedings of
IFIP/IEEE International Workshop on Distributed Systems: Operations and Management (DSOM'97), Sydney, Australia, Octubre 1997.
167] T. Kramp and R. Koster. A Service-Centred Approach to QoS-Supporting Middleware. In Proceedings of the IFIP International Conference on Distributed Systems, Platforms and Open Distributed Processing (Middleware'98), Septiembre 1998.
Work-in-Progress Paper.
168] D. Krieger and R.M. Adler. The Emergence of Distributed Component Platforms.
Computer, 31(3):43{53, Marzo 1998.
169] L. Kristiansen, editor. Service Architecture version 5.0. TINA Consortium, Junio
1997.
170] H.J. Kugler, A. Mullery, and N. Niebert, editors. Towards a Pan-European Telecommunication Service Infrastructure. Proceedings of the 2nd International Conference
on Intelligence in Broadband Serivces and Networks (IS&N'94). Aachen, Alemania.
Septiembre 1994. Lecture Notes in Computer Science (851). Springer, 1994.
171] L. Kutvonen. Management of Application Federation. In International IFIP Workshop on Distributed Applications and Interoperable Systems (DAIS'97), Octubre 1997.
172] L. Kutvonen. Architecture for Distributed Systems: Open Distributed Processing
Reference Model. In Proceedings of HeCSE Workshop on emerging Techonolgies in
Distributed Systems, Lammi, Finlandia, Enero 1998.
173] A. Lazar, R. Saracco, and R. Stadler, editors. Integrated Network Management V:
Integrated Management in a Virtual World. Proceedings of the fth IFIP/IEEE
International Symposium on Integrated Netork Management. San Diego, California,
USA. May 1997. Chapman & Hall, 1997.
174] L. Leboucher and E. Najm. A framework for real-time QoS in distributed systems. In
Proceedings of the IEEE Workshop on Middleware for Distributed Real-time Systems
and Services, San Francisco, California, USA, Diciembre 1997.
175] S. Leue. QoS Specication based on SDL/MSC and Temporal Logic. In Proceedings fo the Montreal Workshop on Multimedia Applications and Quality of Service
Verication. Junio 1994.
59
Referencias
176] D. Lewis. A review of approaches to developing service management systems. Journal
of Network and Systems Management, 1998.
177] C. Loftus, E. Sherratt, and P. Demestichas. Engineering for Quality of Service. In
Proceedings of the TINA'97 Conference, Santiago, Chile, Noviembre 1997.
178] X. Logean, F. Dietrich, H. Karamyan, and S. Koppenhofer. Run-time Monitoring
of Distributed Applications. In Proceedings of IFIP International Conference on
Distributed Systems Platforms and Open Distributed Processing (Middleware'98),
Septiembre 1998.
179] J.P. Loyall, D.E. Bakken, R.E. Schantz, J.A. Zinky, D.A. Karr, R. Vanegas, and K.P.
Anderson. QoS Aspect Languages and their Runtime Integration. In Proceedings
of the 4th Workshop on Languages, Compilers and Run-time Systems for Scalable
Computers (LCR'98), Pittsburg, Pennsylvania, USA, Mayo 1998.
180] J.P. Loyall, R.E. Schantz, J.A. Zinky, and D.E. Bakken. Specifying and Measuring
Quality of Service in Distributed Object Systems. In Proceedings of the 1st International Symposium on object-Oriented Real-Time Distributed Computing (ISORC'98), 1998 1998.
181] M. Mansouri-Samani. Monitoring of Distributed Systems. PhD thesis, Imperial
College of Science, Technology and Medicine, Londres, UK, Diciembre 1995.
182] I. Macmillan. An Introduction to DIMMA. Architecture Projects Management Ltd.
(APM). Technical Report APM.1995.02, Septiembre 1997.
183] A. Manjari. Measuring and Analyzing Service Levels: A Scalable Passibe Approach. In Proceedings of the 6th IFIP International Workshop on Quality of Service
(IWQoS'98), Napa, CA, USA, Mayo 1998.
184] J.P. Martin-Flatin, S. Znaty, and J.P. Hubaux. A Survey of Distributed Enterprise
Network and Systems Management Paradigms. Journal of Network and Systems
Management, 7(1), Marzo 1999. Aceptado para publicacion.
185] K. Marzullo, R.Cooper, M.D. Wood, and J.P. Birman. Tools for Distributed Application Management. IEEE Computer, Agosto 1991.
186] Proyecto MAScoTTE. Introduction to MAScOTTE. White Paper, Mayo 1997.
187] J. Mauney. DCE Frequently Asked Questions. The Open Group, Octubre 1998.
188] S. Mazumdar. Inter-Domain Management between CORBA and SNMP: WEBbased Management - CORBA/SNMP Gateway Approach. In Proceedings of the 7th
IFIP/IEEE Workshop on Distributed Systems: Operations and Management (DSOM'96), L' Aquila, Italia, Octubre 1996.
189] C. McFall. An Object Infrastructure for Internet Middleware. IEEE Internet Computing, 2(2):46{51, Marzo/Abril 1998.
190] B. Meyer. The Future of Object Technology. Computer, 31(1):140{141, Enero 1998.
191] Microsoft. The Component Object Model Specication. Octubre 1995.
192] Sun Microsystems. Java Management Extensions. 1999. Draft 2.0.
60
Referencias
193] Z. Milosevic and M. Bearman. Towards a new ODP Enterprise Language. In
Proceedings of the Joint International Conference on Open Distributed Processing
(ICODP) and Distributed Platforms (ICDP), Ottawa, Canada, 1997.
194] A. Mullery, M. Besson, M. Campolargo, R. Gobbi, and R. Reed, editors. Intelligence
in Services and Networks: Technology for Cooperative Competition. 1997.
195] K. Nahrstedt. An Architecture for End-to-End Quality of Service Provision and its
Experimental Validation. PhD thesis, Universidad de Pennsylvania, 1995.
196] K. Nahrstedt. QoS-Aware Resource Management for Distributed Multimedia Applications. Technical Report UIUCDS-R-97-2030, Digital Computer Laboratory,
Universidad de Illinois en Urbana-Champaign, Diciembre 1997.
197] K. Nahrstedt and J. Smith. An Experimental Investigation of Issues in End-to-End
QoS. Technical Report TR-94-08, Distributed Systems Laboratory, Universidad de
Pennsylvania, 1994.
198] K. Nahrstedt and J.M. Smith. The QoS Broker. IEEE Multimedia, 2(1):53{67, 1995.
199] R. Orfali and D. Harkey. Client/Server Programming with JAVA and CORBA. John
Wiley & Sons, 1997.
200] Proyecto EURESCOM P610. Management of Multimedia Services. Technical Report 1, Febrero 1997.
201] Proyecto EURESCOM P610. Management of Multimedia Services: Management
Framework and Methodology. Technical Report 4, Junio 1998.
202] A. Parhar, editor. TINA Object Denition Language Manual. TINA Consortium,
Julio 1996.
203] G. Pavlou. From Protocol-based to Distributed Object-based Management Architectures. In Proceedings of the 4th HP OpenView University Association Plenary
Workshop (HPOVUA'97), ETSI Telecomunicacion. Universidad Politecnica de Madrid, Madrid, Espa~na, Abril 1997.
204] G. Pavlou. A Novel Approach for Mapping the OSI-SM TMN Model to ODP/OMG
CORBA. In 227], pages 67{82. 1999.
205] J. Pavon, J. Tomas, Y. Bardout, and L.-H. Hauw. CORBA for Network and Service
Management in the TINA Framework. IEEE Communications Magazine, 36(3):72{
79, Marzo 1998.
206] T. Plagemann and V. Goebel. Experiences with the Electronic Classroom - QoS
Issues in an Advanced Teaching and Research Facility. In Proceedings of the 5th
IEEE Workshop on Future Trends of Distributed Computing Systems (FTDCS'97),
Tunicia, Tunez, Octubre 1997.
207] T. Plagemann, K.A. Saethre, and V. Goebel. Application Requirements and QoS
Negotiation in Multimedia Systems. In Proceedings of the 2nd Workshop on Protocols
for Multimedia Systems (PROMS'95), Salzburgo, Austria, Octubre 1995.
208] Proyecto PROSPECT. Concepts for CORBA/TMN Interworking. Technical Report
D33A, Mayo 1997.
61
Referencias
209] G. Raeder and S. Mazaher. Quality-of-Service directed targeting based on the ODP
engineering Model. In Proceedings of the IFIP International Conference on Open
Distributed Processing (ICODP'95, Brisbane, Australia, Febrero 1995.
210] L. Raman. OSI Systems and Network Management. IEEE Communications Magazine, 36(3):46{53, Marzo 1998.
211] K. Raymond. Reference Model of Open Distributed Processing: a Tutorial. IFIP
International Conference on Open Distributed Processing (ICODP'93), Berln, Alemania, 1993 1993.
212] D.A. Reed and K.J. Turner. Support Components for Quality of Service in Distributed Environments: Monitoring Service. In Proceedings of the 5th IFIP International
Workshop on Quality of Service (IWQoS'97), pages 303{314, Nueva York, USA,
Mayo 1997.
213] M. Richters and M. Cogolla. On Formalizing the UML object Constraint Language
OCL. In T.-W. Ling, editor, PRoceedings of the 17th International Conference on
Conceptual Modeling (ER'98). Springer, 1998.
214] R. Rock-Evans. Middleware: The Key to Building Successful Distributed Telecommunications Systems. In 238]. 1998. Conference Closing Keynote.
215] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented
Modeling and Design. Prentice-Hall, 1991.
216] J. Rumbaugh, I. Jacobson, and G. Booch. The Unied Modeling Language Reference
Manual. Addison-Wesley, 1999.
217] A. Schade. An Event Framework for CORBA-based Monitoring and Management
System. In Proceedings of the Joint International Conference on Open Distributed
Processing (ICODP) and Distributed Platforms (ICDP), Toronto, Canada, Mayo
1997.
218] A. Schade and P. Trommler. A CORBA-based Model for Distributed Application
Management. In Proceedings of the 7th IFIP/IEEE Workshop on Distributed Systems: Operations and Management (DSOM'96), L' Aquila, Italia, Octubre 1996.
219] A. Schade, P. Trommler, and M. Kaiserswerth. Object Instrumentation for Distributed Applications Management. In Proceedings of the IFIP/IEEE International
Conference on Distributed Platforms (ICDP'96), Dresden, Alemania, 1996.
220] R.E. Schantz. Quality of Service. In P. Dasgupta and J. Urban, editors, Enclyclopedia
of Distributed Computing. Kluwer Academic Publishers, 1998.
221] J. Schonwalder. Network management by delegation - From research prototypes
towards standards. Computer Networks and ISDN Systems, 29:1843{1852, 1997.
222] A.S. Sethi, Y. Raynaud, and F. Faure-Vincent, editors. Integrated Network Management IV. Proceedings of the fourth IFIP/IEEE International Symposium on
Integrated Netork Management. Santa Barbara, California, USA. May 1995. Chapman & Hall, 1995.
223] D.J. Sidor. Managing Telecommunication Networks using TMN Interface Standards.
IEEE Communications Magazine, 33(3):54{60, Marzo 1995.
62
Referencias
224] D.J. Sidor. TMN Standards: Satisfying Today's Needs While Preparing for Tomorrow. IEEE Communications Magazine, 36(3):54{64, 1998.
225] M. Sloman. Management Issues for Distributed Services. In Proceedings of the IEEE
Second International Workshop on Services in Distributed and Networked Environments (SDNE'95), pages 52{59, Whistler, British Columbia, Canada, Junio 1995.
226] M. Sloman, J. Magee, K. Twidle, and J. Kramer. An Architecture for Managing
Distributed Systems. In Proceedings of the 4th IEEE Workshop on Future Trends
of Distributed Computing Systems, Lisboa, Portugal, Septiembre 1993.
227] M. Sloman, S. Mazumdar, and E. Lupu, editors. Integrated Network Management
VI: Distributed Management for the Networked Millenium. Proceedings of the sixth
IFIP/IEEE International Symposium on Integrated Netork Management. Boston,
MA, USA. May 1999. IEEE Publishing, 1999.
228] N. Sokouti and U. Hollberg. Joint Inter-Domain Management: CORBA, CMIP and
SNMP. In 173], pages 153{164. 1997.
229] R.M. Soley. OMG and CORBA: Consensus for Objects. In 238]. 1998. Conference
Closing Keynote.
230] W. Stallings. SNMP, SNMPv2 and CMIP: the Practical Guide to Network Management Standards. Addison-Wesley, 1993.
231] W. Stallings. SNMP and SNMPv2: The Infrastructure for Network Management.
IEEE Communications Magazine, 36(3):37{43, Marzo 1998.
232] W. Stallings. SNMP, SNMPv2, SNMPv3, and RMON1 and 2. Addison-Wesley, 3
edition, 1999.
233] Sun Microsystems.
Java Remote Method Invocation Specication - Revision 1.50/JDK 1.2.
Documento Internet http://java.sun.com/ products/jdk/1.2/docs/guide/rmi/spec/rmiTOC.doc.html, Octubre 1998.
234] MCI Systemhouse. Relationship of the Unied Modeling Language to the Reference
Model of Open Distributed Computing. MCI Systemhouse white paper, Septiembre
1997.
235] Iona Technologies. OrbixManager. White Paper, 1997.
236] J.P. Thompson. Web-Based Enterprise Management Architecture. IEEE Communications Magazine, 36(3):80{86, Marzo 1998.
237] I. Tothezan, E. Athanassiou, P. Alzon, and G.T. Karetsos. Enterprise modelling of
information brokerage and retailer services. In Proceedings of the First International
Enterprise Distributed Object Computing Workshop (EDOC'97), Marriot Resort,
Gold Coast, Australia, Octubre 1997.
238] S. Trigila, A. Mullery, M. Campolargo, H. Vanderstraeten, and M. Mampaey, editors.
Intelligence in Services and Networks: Technology for Ubiquitous Telecom Services.
Proceedings of the 5th International Conference on Intelligence in Services and Networks (IS&N 98). Antwerp, Belgica. Mayo 1998. Lecture Notes in Computer Science
(1430). Springer, 1998.
63
Referencias
239] Fraunhofer Institut Informations und Datenverarbeitung. The CORBA-Assistant:
Monitoring of CORBA-based Applications. White Paper, Junio 1997.
240] R. van der Linden. An Overview of ANSA. Architecture Projects Management Ltd.
(APM). Architectural Report APM.1000.01, Julio 1993.
241] R. Vanegas, J.A. Zinky, J.P. Loyall, D. Karr, R.E. Schantz, and D.E. Bakken. QuO's
Runtime Support for Quality of Service in Distributed Objects. In Proceedings
of the IFIP International Conference on Distributed Systems Platforms and Open
Distributed Processing (Middleware'98), The Lake District, Inglaterra, Septiembre
1998.
242] V. Villagra, J.I. Moreno, J.I. Asensio, and J. Berrocal. El papel de los servicios de
intermediacion en el contexto del comercio electronico. In Actas de las II Jornadas
de Ingeniera Telematica (JITEL'99, Leganes (Madrid), Septiembre 1999.
243] S. Vinoski. CORBA: Integrating Diverse Applications Within Distributed Heterogenous Environments. IEEE Communications Magazine, 35(2):46{55, Febrero 1997.
244] G.R. Voth, C. Kindel, and J. Fujioka. Distributed Application Development for
Three-Tier Architectures: Microsoft on Windows DNA. IEEE Internet Computing,
2(2):41{45, Marzo/Abril 1998.
245] D.G. Waddington, G. Coulson, and D. Hutchison. Spcifying QoS for Multimedia
Communications within Distributed Programming Environments. Proceedings of
the 3rd International COST237 Workshop: Multimedia Telecommunications and Applications. Barcelona, Espa~na. Noviembre 1996. Lecture Notes in Computer Sicence
(1185), pages 104{130. Springer, 1996.
246] J. Warmer and A. Kleppe. The Object Constraint Language. Addison-Wesley, 1999.
247] R. Whitner. Designing Scaleable Applications using CORBA. In 173], pages 503{
513. 1997.
248] X. Logean and F. Dietrich and J.-P. Hubaux. On Applying Formal Techniques to the
Development of Hybryd Services: Challenges and Directions. IEEE Communications
Magazine, Marzo 1999.
249] J.-W. Yi. Contribucion al modelado de funciones de comunicacion para aplicaciones
de procesamiento distribuido abierto. PhD thesis, Departamento de Ingeniera de
Sistemas Telematicos. Universidad Politecnica de Madrid, Madrid, 1996.
250] J.A. Zinky and D.E. Bakken. Architectural Support for Quality of Service for CORBA Objects. Theory and Practice of Object Systems, Abril 1997.
251] J.A. Zinky, D.E. Bakken, and R.E. Schantz. Overview of Quality of Service for
Distributed Objects. In Proceedings of the 5th IEEE Dual Use Conference, Mayo
1995.
64