You are on page 1of 23

UNIVERSIDAD NACIONAL DE UCAYALI

FACULTAD DE INGENIERÍA DE SISTEMAS Y DE INGENIERÍA CIVIL Escuela Académica Profesional de Ingeniería de Sistemas
PROYECTO EUROPEO “ABROSE“ COMERCIO ELECTRONICO ING. ERICK GUITTON LOZANO ARENAS DA CRUZ, ELFER JOANN HUANIO REATEGUI, PIERO JOSELIN MORENO PANDURO, CAROLINA BALDEON MARINO, JORGE RODRIGO TAPIA SHUÑA, PAULO CESAR

TEMA CURSO DOCENTE ALUMNOS

: : : :

PUCALLPA – PERÚ 2013

Introducción El Comercio Electrónico está principalmente basado en un intercambio de información eficiente y preciso entre las diferentes entidades implicadas en la transacción (típicamente cliente y proveedor), usando la infraestructura de comunicaciones existente. Gracias a las facilidades de comunicación

proporcionadas por Internet y las redes intranet en general, la cantidad de información disponible es muy grande y además, se va incrementando continuamente (de manera análoga, también es habitual el aumento de la cantidad de información demandada).Así, es necesario algún tipo de funcionalidad o mecanismo que permita a los clientes y a los servidores intercambiar información de manera fluida y precisa, tratando de minimizar el tiempo que normalmente se emplea en encontrar información verdaderamente útil y que suele ser bastante alto.

es la búsqueda y posterior entrega de la información. utiliza un esquema de peticiones basado en una aproximación del lenguaje natural. La idea básica. Así. específicamente requerida por los usuarios. que no obligan a tener que realizar la mencionada navegación. de manera que los usuarios puedan obtener conocimientos unos de otros y aprovecharse mutuamente del proceso de refinamiento del mecanismo de aprendizaje anteriormente mencionado. de cara a que los usuarios puedan seleccionar la información que desean de una manera mucho más cómoda. Evidentemente el mayor problema con el que se enfrenta. sin embargo. Hay. consiste en utilizar filtros sintácticos colaborativos. Entonces se le provee de un conjunto de información con el formato atributo/valor. permitiendo que ambas partes se comuniquen de forma sencilla. es la de crear conjuntos de conocimientos comunes. por el que puede ir buscando hasta que encuentra lo que necesite. Los usuarios pueden ir mejorando sus perfiles continuamente. aproximaciones más flexibles y transparentes basadas en el uso de recomendaciones personales (perfiles de usuario). que en ocasiones. Dicho servicio de brokerage. hasta que finalmente localiza los datos deseados.Servicio de Brokerage El servicio de brokerage (implementado por un broker de información). de manera genérica. suele habilitar al usuario. basándose en las evaluaciones que ellos mismos hacen de la información recibida. . también puede llegar a ser un poco tediosa y concretamente vamos a distinguir dos tipos de sistemas:  El primer modelo.  La segunda opción. constituye una herramienta que ayuda tremendamente a potenciar la simetría de la tarea de intermediación. la navegación a través de una clasificación o índice por contenidos. el mecanismo de búsqueda va refinándose progresivamente. en el contexto del comercio electrónico.

distribución. 1. como ya se ha dicho. plataforma de intermediación. podemos ver esbozadas las distintas tareas que constituyen la plataforma: intermediación (brokerage).Figura 1 . estaría considerado como parte integrante de lo que se denomina. . trata de englobar el conjunto de tareas que. seguridad. se supone deben regir toda transacción que tenga la forma de la del comercio electrónico.Plataforma de intermediación en el marco del comercio electrónico Intermediación Un servicio de brokerage del estilo del que acabamos de introducir. En la Fig. contabilidad. están orientadas a disminuir las distancias entre la oferta y la demanda desde el punto de vista comercial. Dicha plataforma. Todas ellas. facturación y conectividad.

Utilización de agentes cooperativos para optimizar la tarea de intermediación. Utilización de Java y CORBA como los lenguajes de implementación del sistema Aplicación de Java. CORBA y SNMP para la implementación de la plataforma de gestión del servicio. Interfaces graficas para la navegación.El proyecto ABROSE (Agent Base Brokerage Services in Electronic Commerce) es un servicio de intermediación para comercio electrónico basado en tecnologías de agentes. La tecnología de agentes permite que el intermediario vaya aprendiendo de manera transparente las preferencias del usuario y pueda configurar la lista de proveedores afines de una forma más precisa. que recoge los resultados obtenidos en el proyecto ABS (Architecture for Information Brokerage Service) Principales objetivos de ABROSE son los siguientes:       Incorporación de un sistema multiagente para representación de la base de conocimientos. es un servicio de intermediación accesible por INTERNET mediante el cual el usuario puede realizar peticiones al intermediario o navegar por la base de datos de conocimientos. Las interacciones entre los diferentes dominios y el intermediario se basan en la utilización de tecnología de agentes. Evaluar la incidencia de la tecnología de agentes en el dominio de los intermediarios de información y de las aplicaciones comerciales en general. Funcionalidad Desde el punto de vista funcional el sistema ABROSE. registro y propagación de ofertas. Los dominios de usuario y proveedor se . La utilización de agentes en el sistema de intermediación de ABROSE. petición de resultados.

que serían directamente presentadas en el navegador.comunican con el intermediario mediante un tipo especifico de agentes llamados agentes de comunicación. . se agrupan para un determinado tipo de especialización bajo el control de un agente de mediación) El modelo de negocio y el de información de ABROSE están basados en los del proyecto ABS. En el dominio del intermediario lo9s agentes que representan a los usuarios y los proveedores. en ABROSE lo que se hace es una búsqueda exhaustiva de proveedores afines a la petición y es el mismo usuario el que debe realizar el acceso. Figura 2. llamados agentes de transacción. Interfaz grafica de peticiones Frente a una posible opción de implementación en la que el broker sería el encargado de consultar a los distintos proveedores y devolver las respuestas.

que asume toda la funcionalidad de visualización de información hacia el usuario final (navegación. se hará mención a los distintos módulos que constituyen el sistema. resultados. que posteriormente se comentarán en detalle. en función de que el sistema lo esté utilizando un usuario o un proveedor. La Fig. si lo que se quiere hacer es una oferta o una petición. A la derecha aparecerían los proveedores que ofrece el broker como respuesta (o los usuarios interesados en la oferta si el cliente del sistema es un proveedor). En lo que resta de apartado. se trata de la interfaz que permite al cliente realizar peticiones al bróker). etc. que hemos comentado. aumentando la precisión a la hora de configurar la lista de proveedores afines. Dicha descripción posibilitará una comprensión mucho más precisa del funcionamiento del sistema. Arquitectura La arquitectura del sistema está basada en dos dominios bien diferenciados: el dominio del broker. Por cuestiones de simplicidad. . existente entre ellos. peticiones. haciendo una división por dominios.). se han omitido algunos puntos referentes a comunicaciones y gestión. El menú ‘Mode’ permitiría seleccionar.La tecnología de agentes permitirá que el broker vaya aprendiendo de manera transparente las preferencias del usuario. que tiene la doble misión de brokerage y gestión del sistema y el dominio del usuario. 2 ofrece el aspecto de una de las interfaces gráficas del sistema ABROSE (concretamente. La descripción de dicha petición se escribiría en lenguaje natural en los campos de texto de la izquierda de la interfaz.

Esquema arquitectural del sistema ABROSE Dominio del Usuario  Asistente de Conexión (CA): es el bloque que ayuda al usuario a registrarse y conectarse al sistema. .  Asistente de Gestión de Agentes (AMA): coordina las comunicaciones entre los diferentes módulos del dominio del usuario. así como la comunicación con el dominio del broker. con el objetivo de mejorar el conocimiento del usuario que tiene el broker (perfil del usuario).  Asistente de navegación (NA): permite que el usuario (proveedor de contenidos o cliente) navegue por el espacio de conocimientos del broker y seleccione los dominios y criterios relevantes para sus peticiones.Figura 3.  Espía (Spy): se encarga de obtener información de las diferentes peticiones que haga el usuario. lo cual irá facilitando progresivamente el proceso de adquisición de información precisa.

El perfil del usuario. se analiza con un poco más de detalle en el siguiente sub apartado .  Sistema Multi-Agente (MAS): en el dominio del broker. facilitando el acceso a los parámetros de gestión que tenga cada uno. estando todos los TAs agrupados por conocimientos y controlados por el módulo MA(agente de mediación). Se creará al iniciarse el sistema y deberá ser mantenido mientras se mantenga el servicio. Se encarga además del arranque del sistema (su labor se explicará más profundamente en el apartado de gestión). cuando un proveedor hace una oferta y se localizan los correspondientes agentes de usuario. Muestra el estado de cada bloque. Front End (FE): es el punto de acceso a la información que posee el proveedor. Cada agente va asociado a un módulo TA (agente de transacción). la información necesaria para permitir el acceso del usuario (login y contraseña). El conocimiento del sistema estará basado en una red de conocimientos (BN). basada en conocimiento específico del MA y/o del TA.  Terminal del Operador (OT): ayuda al operador del sistema a realizar la gestión y administración del servicio que provee ABROSE. se localizará a los correspondientes agentes del proveedor. Dominio del Broker  Gestor de Acceso del Usuario (UAM): la función principal de este bloque es la de mantener los perfiles de los usuarios y verificar el acceso a ABROSE. El usuario obtendrá una referencia para conectarse al FE como respuesta a sus peticiones. El caso simétrico también es posible. formada por el conocimiento de todos estos agentes internos. tendrá por lo tanto. La arquitectura de los bloques que constituyen el MAS. Cada vez que se hace una petición. los agentes representan tanto a los clientes como a los proveedores.  Gestor del Broker (BM): monitoriza la interacción entre los diferentes módulos del sistema. como mínimo.

 Agentes de conocimiento. almacenando conocimiento sobre él y tratando de conseguir información de otros TAs. contienen información sobre sí mismos y sobre otros agentes situados en su mismo nivel. en función de la necesidad o no de un conocimiento global (BN global). Además. 4):  Agente de mediación (MA). El BA de un TA o un MA constituye la BN ( Belief Network) del agente. Los BAs son términos unidos a otros términos mediante enlaces con un determinado peso de unión. coordinando las comunicaciones entre dicho dominio y el usuario al que están asociados. así como eliminar los TAs pertenecientes a clientes dados de baja. Así. nivel medio: representan al usuario en el dominio del broker. Esta información es la que organiza la sociedad de agentes. El MA deberá controlar la creación de TAs asociados a nuevos usuarios.  Agente de transacción (TA). el MA va aprendiendo progresivamente de las transacciones que se hacen en el sistema.MAS (Multi-Agent System) Se trata de una arquitectura en tres niveles. Por eso. cada TA contendrá y mantendrá dos redes de conocimiento. El MA puede añadirse o eliminarse del sistema. El TA es el punto de entrada al dominio del broker. nivel inferior: tanto MAs como TAs. estará formado por agentes cooperativos en un nivel inferior (ver Fig. su base de conocimientos. una que contiene conocimientos sobre el propio usuario y otra con conocimiento del resto de TAs. un agente de un determinado nivel. . Dicha BN está actualizándose continuamente para adaptarse a los conocimientos adquiridos durante las diferentes peticiones (además la BN del MA será un agregado de las diferentes BN de los TAs). estando formado cada nivel por agentes que se comunican entre sí. nivel superior: controlan el ciclo de vida de cada TA y encapsulan todo el conocimiento por ellos adquirido. marcados por el mismo patrón.

Figura 5.Figura 4. en el del broker y entre ambos dominios. pues son los responsables de poner en contacto al cliente y al servidor. Esquema arquitectural del MAS Comunicaciones en ABROSE Este apartado explica la arquitectura e implementación de las comunicaciones en ABROSE.Esquema de comunicaciones en ABROSE . presentando dos nuevos módulos UCOMMS y BCOMMS que constituyen la base de dicha arquitectura. A lo largo del apartado se irá presentando progresivamente la arquitectura de comunicaciones en el dominio del usuario.

haciendo uso también de las referencias de objetos Java. Una vez que se conoce la referencia del objeto destino. se comunica con el resto de los bloques del dominio. UAM. MA). es un applet (lanzado desde la página web de acceso a ABROSE). todos estos módulos usan sus respectivas referencias de objetos Java.Dominio del usuario En términos generales. AMA.. aunque en este caso no se usa ninguna interfaz gráfica. Posteriormente se cargan el resto de los módulos en ventanas independientes. El módulo UCOMMS. las comunicaciones se harán utilizando dichas referencias para ejecutar los correspondientes métodos. Inicialmente se lanza el BM. . Es decir. Como se ha mencionado. será el encargado de unir el dominio del broker con el dominio del usuario. consistirá en un browser (Netscape) cuya máquina virtual ejecutará los diferentes módulos (CA. hace el papel simétrico del UCOMMS en el dominio del broker. que es el módulo responsable de inicializar el resto de los módulos y de repartir las referencias de unos y otros. se hacen igualmente utilizando la referencia Java. si es que incorporan una interfaz gráfica (como el CA o el AMA) o en threads independientes si no es así (UCOMMS). Lo primero en ejecutarse. responsable de comunicar el dominio del usuario con el dominio del broker.) que serán obtenidos del servidor de web mediante HTTP.. Dominio del broker Las comunicaciones se hacen en los mismos términos que en el dominio del usuario. Cada módulo se implementa con un thread independiente (BM. Las comunicaciones con el resto de los módulos del broker. por lo que lo único necesario para habilitar las comunicaciones es un método que permita intercambiar dichas referencias. Para comunicarse entre sí. según se explicará en el apartado 3. BCOMMS.. El módulo BCOMMS. la comunicación entre dos módulos es tan sencilla como ejecutar el método deseado en el objeto en cuestión.3.

. Como se puede ver en la Fig. por lo que las comunicaciones se pueden gestionar de una manera mucho más sencilla. se invocará un método en el UCOMMS y este módulo se encargará de comunicar con el BCOMMS. con lo que la invocación de un método sobre una referencia Java es prácticamente inmediata. en vez de las llamadas a través de referencias Java que es como se hace en nuestro caso. los únicos módulos que tienen que utilizar CORBA. que a su vez entregará la petición al módulo adecuado dentro del dominio del broker Comparativa Otra posibilidad. Además los módulos del broker se comunicarían entre sí utilizando llamadas CORBA. recepción y envío de datos. es que todos los módulos del broker se ejecutan sobre la misma máquina virtual.Comunicaciones cliente-servidor (inter-dominio) Las comunicaciones entre ambos dominios se han implementado utilizando CORBA. con dos módulos (uno por dominio). responsables de enviar y recibir datos del otro dominio. Cada módulo del dominio del broker constituiría un objeto CORBA y cada módulo del cliente accedería por su cuenta al módulo del broker correspondiente. son UCOMMS y BCOMMS. control de errores. El resto de los módulos se desvincula por completo de la complejidad que implica el entorno de comunicaciones (conexiones. Con el esquema utilizado en ABROSE. De esta forma UCOMMS y BCOMMS son los dos únicos módulos que hablan CORBA entre sí. se ha optado por un enfoque centralizado. consistiría en que cada módulo fuese responsable de sus comunicaciones con el resto de los módulos [5].) y sólo precisarán una invocación Java en el UCOMMS o BCOMMS para acceder al otro dominio. Otra ventaja de este modelo. etc. como ya se ha dicho. Cuando el usuario necesite enviar alguna petición al broker. 5.

como ya se ha dicho. un mayor peso sobre las del esquema distribuido. puesto que se tiene la certeza de que al menos la interconexión de módulos se hace de una manera homogénea. en este caso. Además el esquema de ABROSE. mientras que de otra forma el consumo de recursos sería mayor. es crear un nuevo módulo UCOMMS. exige definir previamente las correspondientes interfaces en IDL. permite aprovecharse de las ventajas que ofrece CORBA en cuanto a distribución de objetos se refiere. hay que destacar que ABROSE no exige un alto grado de distribución. Sin embargo. sólo exige la ejecución de una máquina virtual en el broker (lo cual constituye uno de los motivos de la citada mayor velocidad de ejecución). De este intercambio. pero facilita tremendamente la integración del sistema. Por último. posibilitando que cada uno de los módulos pueda estar ejecutándose en una máquina diferente.El otro esquema comentado. también tiene sus ventajas. Dicho módulo contactará con el BCOMMS del broker pasándole su referencia CORBA (y obteniendo a la vez la propia referencia del broker) y a partir de ese momento ambos dominios quedan en comunicación. mientras que . Además. Esto puede suponer un mayor trabajo en la etapa de diseño. sin embargo. una de las primeras cosas que se hacen. la utilización de CORBA se traduce en una disminución de la velocidad de ejecución con respecto al esquema de ABROSE. quedando especificado ya desde el principio qué métodos y con qué atributos se pueden ejecutar desde el resto de los módulos. puede deducirse que únicamente habrá una instancia del BCOMMS ejecutándose a la vez en el broker. por lo que las ventajas del modelo centralizado tienen. Multiusuario Cuando un usuario se conecta al sistema. El hecho de que prácticamente todos los módulos (salvo los del dominio del usuario entre sí) se comuniquen utilizando CORBA. este modelo de comunicación de módulos.

pasa por crear un thread Java independiente. Para devolver la respuesta al usuario. La solución a este problema. ya ni siquiera hace falta pasar por el BCOMMS. bloquean al módulo llamante hasta que no termine la ejecución del método invocado). En vez de hacer la petición al módulo del broker correspondiente él mismo (las peticiones CORBA pueden hacerse no bloqueantes. Desde el momento en que se podemos plantea tener el varios usuarios de conectados al a él simultáneamente. que se dedique a recibir llamadas del UCOMMS y a reenviarlas convenientemente a un módulo que las trate o que reciba invocaciones del broker para enviar respuestas al cliente. Es precisamente el mencionado thread creado por dicho módulo. que son las que nos incumben ahora. cada vez que el BCOMMS recibe una llamada del cliente. es este thread el que queda bloqueado. liberando al BCOMMS que vuelve a estar libre para seguir recibiendo peticiones. crea un thread que se encarga de hacer la verdadera petición. el proceso sería el siguiente:   Cuando el UCOMMS recibe una petición del usuario.  Así. pero las peticiones Java. el que recibe la respuesta (que normalmente será el atributo que devuelve el método Java invocado) y se la envía directamente al UCOMMS (con lo que el BCOMMS no precisa ser sobrecargado con una petición más). se la transmite al BCOMMS.puede haber varias instancias de UCOMMS (una por cada usuario conectado). De esta manera. haciendo que no sea únicamente un módulo puente. . problema mantener BCOMMS permanentemente desbloqueado y listo para recibir peticiones de clientes o respuestas del broker. Esto incrementa considerablemente la complejidad del BCOMMS.

existen los llamados métodos oneway. por la introducción de Java como medio de comunicación entre bloques. Todas las llamadas Java son por definición bloqueantes. suele venir como el atributo que devuelve un determinado método invocado (en cuyo caso. que una vez hecha la petición. En CORBA sin embargo. presentan la posibilidad de transmisión asíncrona de información desde el servidor hacia el cliente. . no bloquean al llamante y son precisamente los que se utilizan para implementar callbacks. la respuesta a una petición. no termine la ejecución del mismo. podríamos considerar que el cliente recibe la respuesta tan pronto como se acaba de ejecutar el método en el servidor). sin embargo. Si la petición se prevé que puede tardar mucho tiempo en ser procesada. Generalmente.Figura 6. es interesante que dicha respuesta venga de una manera asíncrona. desde el punto de vista del usuario. que obviamente no pueden devolver nada (de otra forma obligarían a bloquear al llamante en espera de que acabe de procesarse el valor del atributo a devolver). es decir no liberan al llamante hasta que el módulo que incorpora el método invocado. conviene no tener bloqueado al cliente en espera de que acabe la ejecución de un método y resulta más eficiente. quede desbloqueado y sea el servidor el que envíe la respuesta por sí solo cuando esté lista. como ya se ha mencionado. Detalle de comunicación entre bloques Callbacks Los callbacks. viene generado. El problema en nuestro caso. En ocasiones.

es . porque la idea es precisamente que tan pronto se hace la invocación CORBA. Sin embargo. En principio para hacer esto. podemos comentar un detalle que hay que solventar en el cliente (concretamente en el UCOMMS) y así podremos acabar detallando las comunicaciones UCOMMS-BCOMMS. Por ejemplo en el caso del login. no hacía falta ningún mecanismo del estilo de los threads auxiliares que se ha comentado para el BCOMMS. Cuando se acabe de procesar esa petición se devuelve un valor en la petición CORBA bloqueante y luego se devuelve un valor en la petición Java bloqueante. desde el momento en que el BCOMMS no puede quedar bloqueado. ahora tenemos el caso contrario: queremos que el cliente se quede bloqueado. en las que conviene esperar para confirmar que la operación se realizó con éxito (típico método que devuelve un boolean). bastaría con que el UCOMMS no desviase la petición a un thread. con lo que se acabaría el bloqueo del UCOMMS y además el valor retornado no sería válido. es una invocación Java (bloqueante) típicamente del AMA o del CA hacia el UCOMMS. no pueden usarse invocaciones CORBA bloqueantes. Sin embargo. Hecha esta introducción a los callbacks. lo que en definitiva tiene lugar. Hay también otras circunstancias como la modificación. En definitiva. se genera un thread y se acaba el método invocado. se usa en el UCOMMS un artificio de threads semejante al que se utiliza en el BCOMMS. Cuando el usuario quiere hacer una petición. creación o eliminación de un usuario. sino que se encargase él mismo de procesarla haciendo una llamada CORBA bloqueante al BCOMMS. Para no dejar bloqueada la interfaz gráfica. conviene bloquear el terminal hasta saber si el acceso es o no válido.En el caso de haber usado CORBA para comunicar los módulos del broker (siguiendo el esquema de comunicaciones distribuido que se ha contrapuesto al centralizado de ABROSE). Esto nos va a llevar a que todas las invocaciones CORBA deban ser oneway. hay ocasiones en las que sí es necesario bloquear la interfaz en espera del resultado de la petición. de cara a no dejarlo bloqueado.

decir. Gestión Introducción Básicamente podemos dividir en dos subsistemas diferentes todo el esquema de bloques: Figura 7. lo cual exige otro tipo de solución al problema del bloqueo del cliente. pararlo. bloqueando así la llamada del AMA o del CA. Esquema de bloques del sistema de gestión  El Terminal del Operador (OT) y otras aplicaciones de gestión. La solución adoptada es mantener al UCOMMS en espera tras hacer la petición CORBA. no bloqueantes. hasta que llegue el callback del broker. que permitirán al operador interactuar con el sistema realizando múltiples acciones (iniciar el sistema. acceder a las diferentes . En ese momento. realizar una monitorización gráfica de los diferentes módulos. grabar su estado. se permite la terminación del método Java invocado y el terminal queda desbloqueado.

permiten gestionar el entorno hardware en el que se ejecuta el sistema. almacenar y parar el sistema. Los agentes del sistema y de red. 8) y actuar de puente entre el terminal del operador y el sistema. En definitiva.variables de gestión. el BM utiliza diferentes threads que interaccionan entre sí:   Principal: mantiene al resto de las threads y además se encarga de iniciar.  Ping: se encarga de acceder periódicamente a una variable de gestión de estado ubicada en cada componente. que incluye la información a gestionar del componente y además tiene la . mientras que el agente extensible permite al operador monitorizar el sistema entero utilizando únicamente una interfaz ocultando la presencia de numerosos agentes. parar y almacenar el sistema. gestionar el sistema completo. enviando notificaciones periódicas al OT. Para hacer todo esto. BM Como puede apreciarse en la figura el BM es el módulo responsable de la gestión del sistema.  Gestor de información: se encarga de recibir la correspondiente petición de gestión (get o set) vía CORBA. Si son referentes a start. recibiendo peticiones sobre las variables a gestionar y enviando las notificaciones relevantes de cada módulo. stop o save. acceder a ficheros de registro y obtener notificaciones de los distintos módulos. las convierte en traps SNMP y se las reenvía al OT. monitorizar el status de cada componente (ver Fig.  Manejador de gestión: cada componente tiene un manejador de gestión. de localizar el componente hacia el que va dirigida dicha petición (mirando en una tabla de configuración que mantiene el BM). Está encargado de iniciar. Gestor de notificaciones: recibe las notificaciones de cada módulo. de trasladar la petición al módulo adecuado utilizando referencias Java y de devolver el valor obtenido.

Interfaz gráfica de gestión. con el status de cada componente .interfaz mediante la cual el gestor de información accede a las variables a gestionar. determina qué es exactamente lo que se va a gestionar. Figura 8. incorpora además la tabla de configuración donde se almacenan las referencias al resto de los módulos (y que utiliza el gestor de información para reenviar peticiones). La existencia o no de una variable de gestión. El manejador del BM. implicará la posibilidad o no de gestionar una determinada característica del sistema. Información gestionada La información gestionada almacenada en un sistema.

tienen algunas variables adicionales: . . stop. parar y almacenar (start. save y dos tablas: la ya mencionada de configuración. almacenando también qué método se utilizó en cada acceso.El BM tiene variables para configurar el tiempo entre muestreos del status de cada componente (polling). Se han definido traps para iniciar. save) el sistema. Tanto el BM como el BCOMMS. se ha definido la siguiente información en la MIB (Management Information Base) de ABROSE:    Cada componente tiene una variable de status. prestaciones y seguridad (FCAPS). variables para llevar a cabo el start. Para ello.La idea inicial en ABROSE. anotaciones. que aporta información sobre el estado del módulo. Funcionalidad de gestión Se han implementado dos diferentes maneras de gestionar el sistema. es poder gestionar los cinco puntos definidos por el OSI MN (Open System Interconnection Managing System): fallos. configuración.El BCOMMS contabiliza el número de veces que los diferentes UCOMMS acceden al broker. También incorpora información del tiempo que se tardó en ejecutar cada método. . sin limitación de protocolos. ubicación del fichero de registro de notificaciones. de cara a poder utilizar cualquier plataforma de gestión. con todos los componentes y su estado y otra tabla con las notificaciones almacenadas durante el último arranque del sistema. stop. debido a su importante labor de interfaz al sistema de gestión y al broker respectivamente.

que se estará ejecutando en un puerto UDP bien conocido. acceder a ficheros de registro y obtener notificaciones de los distintos subsistemas. permitiendo iniciar el sistema. almacenar su estado. 7. La idea es acceder directamente utilizando CORBA a la interfaz de gestión del BM. el OT accede al agente extensible. pues utiliza el esquema presentado en la Fig. pararlo. Es la aplicación que permite gestionar por completo el sistema. permitiendo únicamente iniciar. gracias a un traductor de SNMP específicamente diseñado. resulta sin embargo de gran utilidad en entornos de prueba. Para conseguir esto.Figura 9. OT Es mucho más potente que la aplicación anterior. Este esquema tan simple. acceder a las diferentes variables de gestión. Aplicación de gestión CallSystem CallSystem Es una aplicación que supone una funcionalidad mínima del sistema de gestión. . 9 en vez del de la Fig. estén activos. este esquema exige que tanto el agente extensible. aunque no puede utilizarse para gestionar el sistema en un entorno real. monitorizar gráficamente los módulos. Este consultará la MIB y reenviará la petición hacia el agente correspondiente o hacia la interfaz CORBA del BM. como los diferentes agentes para manejar la red o el sistema. parar o almacenar el estado del sistema. A diferencia del CallSystem.

El hecho de utilizar Java como medio de comunicación de módulos dentro de cada dominio. se utiliza una aplicación que. . Para facilitar la labor de desarrollo. permite arrancar el sistema completo. iniciar o parar el sistema.Conclusiones Las principales conclusiones extraídas con respecto a comunicaciones. minimizando las tareas de gestión realizables. pero obliga a suplir la versatilidad que ofrece CORBA a la hora de realizar callbacks. Desde el punto de vista de gestión. ya han sido convenientemente verificadas y validadas en el prototipo implementado para la versión de ABROSE. al tener que pasar por un módulo intermedio antes de llevar a cabo la comunicación. que permite utilizar una vistosa interfaz gráfica para monitorizar el status de cada componente. Como todo sistema centralizado. lo que se ha planteado es un modelo donde coexisten diferentes tecnologías: Java para gestionar internamente el sistema. implica cierta pérdida de flexibilidad y un pequeño retardo adicional. Tanto la arquitectura de comunicaciones como la plataforma de gestión presentadas. con un código un poco más elaborado. etc. así como pararlo y salvar su estado. liberando al resto de la necesidad de tener en cuenta la arquitectura de comunicaciones. Por otro lado. lo cual sí justificaría la utilización de CORBA en las comunicaciones internas de los dominios. están relacionadas con la elección de un esquema centralizado de comunicaciones entre dominios y la utilización de Java dentro de los dominios. CORBA como protocolo de comunicación del sistema con el exterior y SNMP como protocolo de conexión entre el gestor y los diferentes agentes. El esquema centralizado. permite concentrar la complejidad inherente a todo sistema que exija cierta conectividad. posibilita una mayor rapidez que si se usase CORBA. el entorno de aplicación no pretende ser excesivamente distribuido ni heterogéneo. únicamente en dos módulos. visualizar las diferentes variables de gestión. El modelo completo de gestión incorpora un plataforma sobre Tcl-Tk.