Remote Configuration of Agent-Based Component Systems
Rainer Weinreich and Reinhold Plösch, University of Linz, Austria
|
 |
REFEREED
ARTICLE
PDF Version |
Abstract
The nearly omnipresence of the Internet and the steady increase of wireless computing and mobile devices
require highly dynamic adaptable distributed system architectures. Building such architectures needs a combination
of key concepts from component technology and distributed systems. Mobile agents provide this combination.
We use mobile agents as the building blocks of a component-based system for remote supervision and control of
both hard- and software in a distributed environment. In this paper we concentrate on the configuration of
individual components and component relationships in our system. We identify requirements for remote configuration
of agent-based component systems and discuss architectural and user interface related issues of our approaches.
We use a code-on-demand approach for supporting elaborate user interfaces. We use a generative approach based on
enhanced meta-information for reducing development effort. The presented approaches are applicable for remote
configuration of component-based systems in general and consider additional requirements imposed through the use
of mobile agent technology.
1 INTRODUCTION AND OVERVIEW
Distributed software architectures are
currently increasingly influenced by two major technological movements—the
Internet and pervasive computing (including wireless and mobile systems).
In the last years,
the Internet has mainly been used as the technological basis for
creating the Web, a global hypertext and hypermedia network, enriched
with simple interactive (HTML-based) services, like search engines,
electronic shops, and electronic auctions. Currently, the Internet
and its protocols are more and more becoming the infrastructural
backbone for arbitrary services and systems. Nearly every distributed
application is required to work in an Internet context or is based
on standardized Internet protocols.
The Internet is also changing
application deployment and maintenance. Internet-based deployment comprises
not only the transfer and installation
of software, but all activities from installation until deinstallation
and removal of a software system at a consumer’s site [1]. This
includes tasks like remote activation, deactivation, configuration,
reconfiguration, addition, removal, and update of software. All these
activities are not only performed for whole applications but also for
individual components, and sometimes even at run-time. The result is
the need for highly flexible and adaptable software architectures as
well as the need for remote configuration and management tools.
The
second major technological movement is wireless and mobile computing,
which makes further demands on distributed software architectures.
Examples are adaptation to different environmental conditions, dynamic
service discovery, scalability, robustness and security [2]. Remote
configuration tasks may be performed using a whole range of potentially
different end-user devices with dedicated user interfaces.
Many of
the challenges stated above are addressed by component technology [3][4].
Component models [5] provide standards for component customization,
communication, evolution and composition. Components are the basis
for adaptable software architectures. Mobile agent technology has similar
characteristics as component technology [6]. Nearly all distinguishing
features of component systems that are standardized in general component
models are equally important in mobile agent systems. However, mobile
agent technology additionally emphasizes support for distribution,
heterogeneity, adaptation to different environments, code mobility,
and spontaneous computing. These features are especially important
for the application domains outlined above. In fact, mobile agent platforms
may be viewed as powerful and flexible component environments.
We use
mobile agent technology as the basis for a flexible component system
for remote diagnosis and monitoring of hard- and software resources
in heterogeneous distributed environments. Currently the main usage
areas are process automation systems though the system is not limited
to this domain. A main characteristic of our system is its highly dynamic
structure. Diagnosis and monitoring components may move within the
network to their intended place of action, which is the hard- or software
resource to be monitored or analyzed. This requires support for code
mobility. Other features that are needed and supported by our system
are dynamic service discovery, dynamic services, native-code management,
multi-protocol remote access of various types of components, robustness,
and security (see [7]).
A main feature of our system, which is also
the topic of this paper, is remote configuration and management of
monitoring and diagnosis
components over Internet connections. Since the components of our system
are mobile agents, we will use the terms component and agent interchangeably
in the remainder of this paper. We have experimented with a number
of approaches for remote configuration of individual agents and of
system properties like agent relationships. While most of the explored
techniques apply to remote configuration of components in general,
some are specific to the characteristics of mobile agent systems.
The
remainder of this paper is structured as follows: In Section 2 we describe
requirements and solution options for the configuration
of remote components including requirements that are specific for the
configuration of mobile agents. In Sections 3 and 4 we present approaches
for remote configuration that have been implemented in our system.
The emphasis of this paper is on Section 3, which contains a discussion
of approaches for the configuration of individual agents. Section 4
outlines our approach for configuring system properties and structure.
We describe related work in Section
5. Remote configuration over Internet connections needs security support.
However, a discussion of security options and requirements is beyond
the scope of this paper. A short overview of security support in our
system can be found in [7].
2 CONFIGURATION REQUIREMENTS
In order to discuss typical requirements
and approaches for configuring components and mobile agents, we first
need to present different variants
of system structures for remote configuration over the Internet. In
its simplest form—depicted in Figure 1—the host for remote
configuration is directly connected to a host where the components
to be configured are installed and possibly activated.
Fig 1: A simple
system structure for remote configuration
We call the location where remote configuration tasks are performed
by human operators the administration site. The administration site
may be only one host or a network of hosts, which may all be used for
configuration purposes. The location where the software is installed
and running is called the target site. If the components to be configured
are implementing the middle-tier of a three-tier application model,
the target site might be a single computer with the application server
hosting these components as shown in Figure 1.
A typical agent-based
system, however, is a distributed system where the components to be
configured are distributed to a number of hosts
at the target site (T1, T2, …) as depicted in Figure 2. Configuration
may be performed from different hosts at the administration site (A1,
A2, …), also shown in Figure 2.
Fig 2: Configuring a distributed
system from multiple hosts
Usually company networks are guarded by firewalls and not every
host at the administration site may directly access the Internet. Likewise
only selected hosts at the target site are visible to the Internet.
Communication has to be routed through proxies (P) at the administration
site and through dedicated entry points at the target site as depicted
in Figure 3. In addition, the host acting as proxy in Figure 3 may
also serve as administration server (AS) for centralized management
of configuration tools and component repositories.
Fig 3: System structure
with firewalls in mind
The presented system structures for remote configuration serve as
the basis for the description of requirements on remote configuration
systems in general and on our system in particular. Important requirements
are:
- Dynamic configuration of individual mobile agents and of the
system structure. We need to support the configuration
of both individual mobile agents and general system properties and
structure. System structure is defined through agent communication
relationships. Parts of the structure may be defined through rather
fixed relationships that can be changed manually. For example, our
system allows the configuration of publish/subscriber relationships
between agents. General system properties may be changed by configuring
special agents that are responsible for distributing the information
within the target site (see Section 4).
Dynamic configuration refers to the ability to configure the system
while it is up and running. This requires a highly dynamic system
architecture which allows adding and removing components at run-time – a natural
feature of any agent-based system. However, it also requires special
protocols to change the properties of individual agents. Mobile agents
are active objects encapsulating their own thread of control. It is
not possible to change a certain property at any time and sometimes
it is not possible to change an agent’s properties at all.
This has to be taken into account when designing protocols for updating
agent state at run-time.
- Minimal administration of configuration
tools at administration site: This requirement refers to the administrative
effort that is
involved in managing the configuration tools and repositories at
the administration site. Changes or updates of the tools itself should
require no or only minimal activities at the configuration hosts
(see
A1, A2, … in Figure 3). Pre-installing the configuration
tools at each configuration host is not desirable. Centralized
configuration
can be achieved by loading the tools on demand from a central administration
server (see AS in Figure 3). This requires a dedicated run-time
environment at each host. In the ideal case such an environment
is a standard equipment
of the client host, like web browsers, which are able to host HTML-based
user interfaces. If HTML-based user interfaces are not powerful
enough, additional environments for hosting user interfaces based
on other
technologies have to preinstalled at each configuration host. Examples
are the Java Plug-In [8] and Java Web Start [9] technologies for
Java-based user interfaces. This is still preferable to installing
the application
at each host, since update and other changes of the configuration
tools require no management activity at the client hosts.
- Support for different
types of configuration clients: The rise of mobile and wireless computing
is leading to a large number of different
end-user devices with different display sizes and capabilities. The
system structure at the administration site—as depicted in Figure
3—is also appropriate for supporting different kinds of configuration
clients (A1, A2, … in the figure). An administration server
(AS) could provide different user interfaces depending on the end-user
device
used for configuration. For example, it might provide WML-pages for
a WAP-enabled device [10].
- Loose coupling of tools at administration
site and of components at target site: Certain implementation
decisions might lead to a tight
coupling of the tools at the administration site and of the agents
at the target site. Tight coupling may be the result of using a
platform specific type system for configuration data, since this
presumes that
agents and tools are based on the same platform. For example, if
configuration data is represented as Java objects both tools and
agents need to be
Java-based. Platform independent data formats and type systems
(e.g., based on XML) are more flexible, since tools and target components
may be implemented in any language. However, such type systems
may
not be as expressive as platform-specific ones, confining agent
properties to simpler data types with no associated behavior. In
the case of agent-based
systems one might be tempted to install an agent platform not only
at the hosts of the target site but also at the hosts of the administration
site. However, this also leads to tight coupling of administration
site and target site since it assumes that the configuration tools
are only used for configuring agents of a particular agent platform.
This rules out systems like ours, where one administration site
is used for configuring multiple target sites with possibly different
agent systems installed. We will present our solution to this problem
in Section 3.1. In addition, the notion of migrating an agent to
an
administration host, changing its configuration and sending it
back to the target site is often not feasible. Two problems that
come immediately
into mind are security and agent activity. A firewall aware system
structure as depicted in Figure 3 would need flexible agent platforms
that allow control of message routing. However, agent platforms
usually support peer-to-peer communication as depicted in Figure
2. Also, firewall
settings at the configuration site might not allow an agent entering
the site at his will; most of the time even callbacks are denied.
A further problem is that an agent is an active entity. It is often
not
possible to stop an agent’s activity just for changing some
configuration settings.
- Evolution support: In dynamically adaptable systems components
(mobile agents in our case) are added, removed and replaced by
newer versions
over time. Multiple versions of the same component may exist simultaneously
in the system. This is supported by mobile-agent systems, since
features like code mobility require flexible mechanisms for code
management.
Typically the agent system provides separate name spaces for different
agents and a code loader which makes sure that the code of different
versions of the same agent type can be loaded at the same time
[11]. From the configuration viewpoint we have to make sure that
we are able
to configure an agent at any time during its life time. Even if
some agent code has been removed from the repository at the administration
site or if it has long been replaced by newer versions there may
still
exist some instances of older versions at the target system, which
need to be configured. The most obvious solution to this problem
is to store the user interface code for configuring the properties
of
a particular agent with the agent itself at the target site. If
the agent is to be configured, the user interface code is requested
from
the agent and sent to the tools of the administration site (code
on demand [12]). Otherwise the user interface code is integral part
of
the agent and is transferred along with agent state and code when
the agent is roaming the network at the target site. However, the
solution
of storing user interface code with the agent itself also has drawbacks.
It is a form of tight coupling of the target site with the tools
at the administration site, since the user interface code needs a
special
execution environment at the administration site. In addition,
multiple different end user devices for configuration are not supported.
Still
it may be useful for some kind of remote configuration systems
and we will present a similar approach in Section 3.1. A better solution
is to store a platform independent user interface description with
the agent. This allows device independent user interface generation
at the administration site while maintaining the ability of configuring
each agent in the system. A further enhancement is generating the
user
interface by analyzing the agent itself. We present such an approach
in Section 3.2.
- Minimization of user interface development: Development
of user interfaces for remote configuration is a tedious task and
component (agent) developers should focus on developing the application
logic
instead of providing remote configuration support. In the ideal case,
no user interface needs to be developed at all. One approach for
supporting user interface development tasks is user interface frameworks.
Component
developers just need to adapt general framework classes providing
generic functionality for setting new values, for reverting to old
values and
for performing consistency checks. As stated above this approach
not only involves coding effort but also tightly couples configuration
tools to the platform of the user interface framework. For example,
a Swing-based user interface requires a Java runtime environment
at the administration site. A better approach is to generate the
user
interface
from some
kind of User Interface Specification Language (UISL). This is platform
independent but still the user interface has to be specified. The
most
preferable approach is generating the user interface by analyzing
the agent itself. This approach is based on the availability of meta-data
about components, a distinct feature of each component-based system
(see [5] for the importance of meta-data). By using meta-data the
user
interface can be generated automatically and involves no development
effort at all. Meta-data is usually extracted from component implementation
and interfaces and is stored as part of the component. However, meta-data
provided by component platforms like Java and .NET often lacks important
information that is necessary for generating “well-formed” user
interfaces and for providing sufficient validation of component property
values. In Section 3.2 we present an approach for automatically generating
user interfaces from enhanced agent meta-data.
- Security: Security
is a dominant requirement for Internet-based remote configuration.
Since security is a very broad topic to discuss
in general and very dependent on the specific configuration of
the system and on the organizations involved, we are not able to
discuss
it sufficiently in this paper. As discussed above and illustrated
in Figure 3 security issues may influence the fundamental structure
of
a configuration system and needs to be taken into account from
the beginning. We provide an overview of basic support for authentication
and authorization in our system in [7].
We have outlined and discussed
basic requirements and solutions for remote configuration of dynamic
and adaptable component-based systems.
Most of the presented requirements are typical for remote configuration
of component-based systems in general. Some are imposed through the
use of mobile agent technology. In the next section, we present two
solutions for remote configuration, which have been realized in our
system.
3 CONFIGURATION OF INDIVIDUAL AGENTS
We have implemented two different
approaches for remote configuration of agent properties at run-time.
Both solutions are based on
a central administration server at the administration site (see
Figure
3),
which eases administration of configuration tools as stated
in Section 2b. In addition, the administration server acts as a proxy
for the
configuration hosts, thus supporting network configurations
with
firewalls. In the first approach, agents are configured from
Java-based user interfaces that are loaded on demand from the
target site.
The second approach is a generative approach where user interfaces
are
generated on the fly based on enhanced meta-information about
the agents to be configured. In the following two subsections
we present
both approaches in more detail and refer to the requirements
presented in the previous section.
Remote Configuration Based
on Code on Demand
The code on demand approach supports dynamic configuration
of agent properties (2a), central administration of configuration
tools
(2b) and component evolution (2e). Drawbacks are confinement
to a particular
kind of user interfaces (2c, 2d) and to Java based mobile-agent
systems. Also, user interfaces need to be coded manually
(2f), albeit based
on a user interface framework which is part of our system.
Fig
4: System Structure
The main system structure is equal to the structure
shown in Figure 3 and is presented in more detail in Figure 4. Agents
are installed
and configured from configuration clients at the administration site.
Upon installing an agent, its code, an initial configuration and
its user interface code are transferred to the target site. The user
interface
code is not directly stored as part of the agent code. Instead, it
is stored in a code repository at the target site. In principle,
this would allow to implement the user interface for configuration
based
on other technology than the agent itself. In our system, however,
both user interface and agent are implemented in Java. An agent does
not store its user interface code directly but holds a unique ID
that identifies the user interface code in the repository. If a configuration
request is issued from one of the clients at the administration site,
this ID is requested from the agent and used for identifying and
transferring
the user interface code to the configuration client.
Storing the user
interface for configuring an agent in a repository at the target
site ensures that for each agent that has been installed
at the target site a configuration user interface can be found,
no matter which administration site is used. Administration clients
may even be placed within the target site since, from a logical
perspective,
the user interface that is needed for configuring an agent is always
with the agent. From a technical perspective this solution enables
code sharing. An installation tool might check whether an appropriate
user interface for a newly installed agent is already available
at the target site and assign its unique ID to the agent.
Storing the
user interface code at the gateway server does not raise security
problems, as only properly authenticated users are
allowed
to install or change mobile agents at a target system. Therefore
the issue of malicious target sites tampering with the stored
user interface
code can be omitted.
We should note that we have also experimented
with implementing the user interfaces themselves as agents and thus
using agent
mobility for transferring the user interface to the configuration
clients
at the administration site. This proved not feasible for mainly
two
reasons:
(1) Configuring multiple target sites with different
agent platforms is not possible and (2) agent platforms are
not adaptable to the underlying network infrastructure.
First, we need
to administrate multiple target sites based on different agent platforms
from one administration site.
As pointed
out in
Section 2d representing the user interface as agent would
require an agent
platform at the configuration client. Since target sites
can use different agent platforms, a client would need multiple
agent platforms
for configuring
agents from different target sites. Downloading the agent
platform on demand is no feasible alternative. A common agent platform
standard like FIPA [13] might help. However, standardization
would need
to include the underlying execution platform (e.g., the Java
platform). We have
defined an Agent Platform Abstraction Layer (APAL) specifying
platform-independent abstractions for agent creation, disposal,
communication and migration
(see also [7]). This allows at least platform independent
implementation
and configuration of agents at the administration site and
thus supports
different agent platforms at different target sites (We should
note that the implementation is still confined to Java-based
agent platforms).
The second problem has also already been
addressed in Section 2d and concerns network security based in firewalls.
Corporate
networks
are
usually secured by (multiple layers of) firewalls. Agent
platforms need to be adaptable in terms of message routing
and protocols
to operate in such environments. However, typical agent
systems are
designed for
operating in open environments based on peer-to-peer connections
between agent servers. An additional problem for agent
mobility is that accessing
the administration site from the target site is prohibited
by firewall settings.
We have implemented an adaptable communication
infrastructure, which is used for sending agent properties from the
configuration
clients
in Figure 4 to an agent at one of the agent servers at
the target site. Communication is routed through a proxy
at the
administration
server
and through the host acting as entry point (gateway)
at the target site. Agent properties are not directly updated.
Instead,
the
target agent first caches the configuration data and
updates its properties
only if it reaches a consistent state (2a).
Configuration
data is encoded as Java objects. This might tightly couple user interface
and agent code and imply
that configuration
user interfaces
need to be Java based (see requirement 2d). However,
this is not the case in our system. The target site
can only
be accessed
through
the
gateway host (see Figure 4). Messages from external
sources like configuration clients are routed through an application
server
at the gateway host
which converts the protocol to the native protocol
of
the agent platform at the target site. Since multiple
protocol
converters
for converting
different protocols can be installed, configuration
user interfaces that are not Java-based are possible. For
example, we have
implemented access from clients using HTTP for transport
and XML for data
encoding (see next section) and from CORBA via IIOP.
Conceptually, accessing
the system using other protocols like SOAP is possible.
A Generative
Approach for Configuration UIs
As outlined in Section 2, generative
approaches for configuration user interfaces are beneficial for supporting
different types of
configuration
clients (2c) and for minimizing the effort involved in user interface
development (2f). The approach presented in this section is particularly
interesting for supporting these two requirements. However, other
requirements like 2a, 2b, 2d and 2e are supported as well. The
main idea is to use
enhanced meta-data about an agent for automatically generating
user interfaces and thus to eliminate the need for user interface
development
in the ideal case.
Fig 5: Generic User Interfaces
The basic system structure is similar
to the one presented in the previous section and is shown in Figure
5. The figure also shows the
main system components and the data needed for user interface generation.
In
our system, agents are implemented in Java. Therefore meta-data about
agents, like configurable properties, can be retrieved using
introspection and reflection [16]. Meta-data and property values
are transferred from an agent (A) to the UI-Model Generator as
shown in
Figure 5. The UI-Model Generator automatically generates an XML-based
User Interface Specification (UIS) and transfers it together with
the meta-data and property values to a User Interface Generator
that is
located at the administration server at the administration site.
We call the package consisting of UIS, meta-data about properties,
and
property values Configuration Descriptor (see Figure 5). Property
meta-data and values are not represented as Java objects in the
configuration descriptor, since this would lead to a tight coupling
between the
tools
at the administration site and the components at the target site
(see requirement 2d). Instead, we convert the retrieved meta-data
(property
names and types) as well as property values to a platform independent
representation based on XML.
In principle, meta-data about property
names and types is sufficient for automatically generating the user
interface. However, the meta-data
extracted from agents lacks important information like units
of measurement and allowed ranges for property values. This information
is needed
for presenting and validating property values at the user interface.
We enable an agent developer to provide such information either
using an extended meta-data API or by providing XML-based constraint
specifications
for individual properties, which have to be deployed with the
agent
code. These constraints are sent to the user interface generator
at the administration site as part of the configuration descriptor.
Fig 6: Presentation Hint Example
User interfaces based on constraint-enhanced meta-information are
still rather crude in appearance. For example, field names that are
derived from component properties are not verbose enough and all fields
are just presented as one long list and lack semantic grouping (see
left part of Figure 7). We allow agent developers to enhance the user
interface layout and appearance by providing presentation hints as
shown in Figure 6.
Fig 7: Use Interface without/with presentation hints
Using this information we are able to improve the appearance of the
user interface as shown in Figure 7. The user interface shown in the
right part of Figure 7 has been generated using the presentation hints
presented in Figure 6. The main differences are verbose field labels
and more clearly arranged user interface elements.
Summarizing, meta-data
about properties, constraint specifications and presentation hints
are extracted from an agent and sent to the
user interface model generator at the target site. The model generator
creates an XML-based user interface specification (UIS) which is transferred
to the administration site along with property meta-data and property
values in XML-format. The generated UIS is a hard- and software independent
description of the layout of the agent properties and thus independent
of any specific configuration client (see requirement 2c).
Instead of
providing presentation hints, the complete UIS may be created manually
and stored in a UI repository at the gateway host (see Figure
5). The main advantages of this approach are even more elaborate user
interfaces, albeit the effort for user interface specification is increased,
also.
The configuration descriptor (including the UIS) is transferred
to the user interface generator at the administration site, which finally
generates a client specific user interface. The UI generator uses pluggable
renderers for generating different kinds of user interfaces. The user
interfaces depicted in Figure 7 have been generated using a JFC/Swing
renderer. Renderers for HTML, WML and other kinds of user interfaces
may be provided as well.
4 CONFIGURATION OF SYSTEM PROPERTIES AND STRUCTURE
The previous
section focused on approaches for configuring individual agents. In
this section we outline our approach for configuring system
properties and system structure. System properties are general data
that is useful for all components within the system and data that is
needed by system management tools. Examples are the hosts that are
part of the system, the placement of agent run-time environments (agent
servers), and information about the location of resources needed by
agents. The system structure is defined by agent location and agent
relationships. We support event relationships between agents which
are used for modeling both control and data flow.
In principle, system
properties could be provided by means of one central service at the
target system. Alternatively they could be managed centrally
by special agents at the target system. However, a central location
for managing system properties, regardless of the implementation, suffers
from two well known problems. Such a solution might become a performance
bottleneck and it is not fault-tolerant. We provide different solutions
for managing system properties—depending on the type of properties
to be managed. Rather static properties that are unlikely to change
are replicated throughout the whole system, which allows local access
to these properties from all agents. Other system properties are stored
in a system-specific trading and directory service. The trading service
is fault tolerant using an enhanced multi-master replication mechanism.
Storing information within the directory service may involve remote
access for retrieving properties, but provides sophisticated synchronization
mechanisms for changing and redistributing information within the system.
In
both cases configuring system properties from a client perspective
is achieved by configuring system property agents. Such an agent will
either distribute the information within the system itself or store
it in the system directory using the directory service.
The directory
service is at the same time a trading service that maintains information
about all agents (components) that are installed at the
target site. Therefore, it can be used by configuration tools for determining
which agents are located at a specific host or for retrieving a remote
agent reference for accessing an agent. The trading service itself
is based on agent technology and uses features like mobility for installing
replicating instances at certain nodes within the system.
The environment
is currently used as the basis for a system for remote diagnosis and
monitoring of hard- and software resources in heterogeneous
distributed environments. For setting up a working diagnosis and monitoring
system, different types of agents need to be installed, configured
and connected. The connections between agents make up the system structure.
In our system these connections are event relationships, which can
be changed either manually through configuration tools or automatically
through program logic.
For example, the system provides worker agents
performing measurement tasks, which can be connected to agents for
filtering and condensing
measurement values. These agents can in turn be connected to agents
generating reports or storing the results in a data-base. In the described
scenario, event connections are used for modeling data flow. Worker
agents may also be connected to supervisors, which are used for monitoring
and validating data. Supervisors may in turn be connected to other
agents implementing the necessary actions that are to be performed
in case of problems. In the latter case, event connections are used
for specifying control flow.
Event connections are maintained by an
event service in our system, which also maintains the connection between
agents, if agents change
their location. The event service provides similar functionality as
similar services for other distributed component models (e.g., CORBA
notification service [14]). The API of the event service is similar
to the API provided by the COM+ event service [15]. Like the trading
service the event service is implemented based on agent technology.
Event relationships can be changed dynamically using tools at the administration
site, which are able to access the event service using the flexible
communication infrastructure outlined in Section 3.1 and in [7].
5 RELATED
WORK
In this section we identify approaches that are related to the
work presented in this paper, specifically to our work on the configuration
of individual agents, since this is the emphasis of this paper. We
distinguish framework-oriented approaches (see Section 3.1) and generative
approaches, which are further distinguished in specification-based
and meta-data-based approaches (see Section 3.2).
The emphasis of framework-oriented
approaches is on facilitating the development of complex user interfaces
combined with support for code-on-demand
(see Section 3.1). Examples of application frameworks for user interfaces
are JFace [17] and JFC/Swing [18]. Although general user interface
frameworks ease the construction of user interfaces, there is no explicit
support for configuring distributed and potentially mobile components.
User interfaces can be loaded on demand from remote servers using technologies
like Applets and Java Web Start [9]. However, simple code on demand
technologies are not enough. Configuring remote agents needs a more
elaborate infrastructure for retrieving the user interface of a specific
agent, wherever this agent is located. In addition, agent mobility,
co-existing versions of agents and user interfaces as well as specific
network topologies imposed by security requirements (see Figure 3 in
Section 2) need to be considered. Further, code on demand technologies
imply tight coupling of client and server since the code available
on the server must by executable by the client.
Specification-based
approaches aim at simplifying user interface development by generating
user interfaces from user interface specification languages.
This approach is interesting since it is independent from specific
user interface toolkits and it also enables support for different hardware
devices. The basic idea has been explored some time ago (e.g., [19][20][21][22]).
Newer approaches are based on XML like XForms [24], XUL [25], and PUC
[26][27]. These approaches may be compared to the UIS mentioned in
Section 3.2. However, the UIS is only one building block of a system
for remote configuration of software components and it is not the main
focus of this paper. The main idea of the approach presented in Section
3.2 is the combination of manual and automatic generation of the XML-based
user interface specification and its integration in a remote configuration
infrastructure.
As described in Section 3.2 automatic generation of
user interface specifications is enabled by meta-data about the components
to be configured.
Meta-data-based approaches are particularly interesting for configuring
component-based systems due to the self-descriptive nature of components.
Automatic user interface generation based on meta-information is often
used in user interface builders for configuring local user interface
elements. Typical examples are development environments for Java and
.NET. However, as discussed in Section 3.2 standard meta-data provided
by components is not sufficient for creating well-structured user interfaces.
In
terms of the remote configuration infrastructure our system can be
compared to the Java Management Extension (JMX). JMX [28] is an
approach for remote administration of hardware and software. The components
that are installed for remote administration tasks are called MBeans
(Managed Beans). MBeans may be compared to the agents in our system.
An MBean represents a resource to be managed and may be accessed from
remote clients using connectors and protocol adapters. Protocol adapters
are installed at the target site and may use meta-data provided by
MBeans for generating a configuration user interface. For example,
the reference implementation of Sun Microsystems contains a general
HTML-adapter which uses introspection and dynamically generates an
HTML-based configuration user interface. Additional adapters for other
kinds of user interface technologies can be provided.
Contrary to our
approach, adapters in JMX are confined to the meta-data available in
Java, which leads to less sophisticated automatically
generated user interfaces.
In addition, the complete user interface generator (a special adapter) is located
at the target site. Supporting a new type of configuration client requires
changes at the target site, since a new adapter has to be installed. In our
approach, only a user interface specification is generated at the target site.
The actual user interface is generated at the administration site (see Section
3.2). Only a new renderer has to be provided at the administration server in
order to support a new kind of configuration client. In addition, the effort
that is involved in creating new adapters for new kind of configuration clients
in JMX is higher that in our system, since each adapter has to provide the
entire functionality for meta-data analysis and user interface generation.
In our approach, the functionality of the user interface specification generator
at the target site need not be changed. It suffices to provide a new renderer
for a new client type at the administration server. Finally, in our approach
the coupling between configuration clients and the components at the target
site is weak, as we use platform independent data formats and type systems,
based on XML. In the JMX the coupling between client and server is defined
by the implementation of a specific adaptor.
6 CONCLUSION
We have presented requirements and approaches for configuring
remote and mobile components in a typical real world setting. Currently
we use the system for
configuring mobile agents performing monitoring and supervision tasks in process
automation systems. Many of the presented requirements and solutions are important
and useful for remote configuration of distributed components in general.
The
use of mobile agent technology as the basis for the components at the
target system imposes specific requirements on the configuration system
like support
for dynamically adaptable system structure and agent mobility. In terms of
implementing the configuration system itself, we had to sacrifice seemingly
obvious solutions for configuring remote agents (like migrating the agent and
performing the configuration locally) in favor of other techniques like code
on demand and automatic user interface generation.
REFERENCES
[1] R.S. Hall, D. Heimbigner, A.L. Wolf: “A Cooperative
Approach to Support Software Deployment Using the Software Dock”,
Proceedings of the International Conference on Software Engineering
1999 (ISCE ’99), Los Angeles, California,
USA, 1999.
[2] Kindberg T., Amanda F.: “System Software for Ubiquitous
Computing”,
IEEE Pervasive Computing, Vol. 1, No. 1, January-March 2002.
[3] C. Szyperski:
Component Software – Beyond Object-Oriented Programming,
Addison-Wesley, 1998.
[4] G.T. Heineman, W.T. Councill (eds.): Component-Based
Software Engineering, Addison-Wesley, 2001.
[5] R. Weinreich, J.Sametinger:
"Component Models and Component Services - Concepts and Principles",
in Component-Based Software Engineering (http://www.cbseng.com),
G.T.
Heineman, W.Councill (Ed.), Addison-Wesley 2001.
[6] M.L. Griss: “Software
Agents as Next Generation Software Components”,
in Component-Based Software Engineering, G.T. Heineman, W.Councill
(ed.), Addison-Wesley 2001.
[7] R. Weinreich, R. Plösch: "An Agent-Based Component Platform
for Dynamically Adaptable Distributed Environments", Informatica
Journal, Special Issue on Component Based Software Development, Vol.
25 Nr. 4, November 2001.
[8] Java Plug-In home page, http://java.sun.com/products/plugin/
[9]
Java Web Start Home Page, http://java.sun.com/products/javawebstart/
[10]
Wireless Application Protocol Forum: “Wireless Application Protocol
Architecture Specification, WAP-210-WAPArch-20010712”, July 2001.
[11]
G.P. Picco: "Understanding, Evaluating, Formalizing, and Exploiting
Code Mobility", Ph.D. thesis, Politecnico di Torino, Dipartimento
di Automatica e Informatica, 1998.
[12] A. Fugetta, J.P. Picco, G. Vigna.: “Understanding
Code Mobility”,
IEEE Transactions on Software Engineering, Vol. 24, No. 5, May 1998.
[13]
Foundation for Intelligent Physical Agents (FIPA): Specifications
are available at http://www.fipa.org/repository/index.html.
[14] OMG: "Corba
Notification Service Specification", Version 1.0, Document formal/00-06-20,
http://www.omg.org/
[15] D. S. Platt: "Understanding COM+", Microsoft
Press, 1999.
[16] Sun Microsystems: "Java Core Reflection API and Specification",
Sun Microsystems, 1999.
[17] Object Technology International, web
server of the Eclipse project, http://www.eclipse.org
[18] A. Fowler: “The
Swing Architecture Overview”, see web server
of the Swing Connection, http://java.sun.com/products/jfc/
[19] D.R.
Olsen: “A Programming Language Basis for User Interface Management”,
in Human Factors in Computing Systems, Proceedings SIGHCHI 89, Austin,
April 1989, pp 171-176.
[20] P. Sukaviriya, J.D. Foley, T. Griffith: “A
Second Generation User Interface Design Environment: The Model and
The Runtime Architecture”,
In Human Factors in Computing Systems, Proceedings INTERCHI 93, Amsterdam,
April 1993, pp 375-382.
[21] P. Szekely, P. Luo, R. Neches: “Beyond
Interface Builders: Model-Based Interface Tools”, in Human
Factors in Computing Systems, Proceedings INTERCHI 93, Amsterdam, April 1993,
pp 383-390.
[22] C. Wiecha, W. Bennett, S. Boies, J. Gould, S. Greene: “ITS
- A Tool for Rapidly Developing Interactive Applications”, in
ACM Transactions on Information Systems, Vol. 8, No. 3, July
1990, pp 205-236.
[23] C. Phanouriou, M. Abrams: “Transforming
Command-Line Driven Systems to Web Applications", In Computer
Networks and ISDN Systems 29, 1997, pp 1497-1505.
[24] W3C: XForms 1.0, W3C
working draft, http://www.w3.org/TR/xforms/.
[25] The Mozilla Organization:
XPToolkit Project, http://www.mozilla.org/xpfe/.
[26] B. A.
Myers. "Using Hand-Held Devices and PCs Together," Communications
of the ACM. Volume 44, Issue 11. November, 2001. pp. 34 – 41.
[27]
J. Nichols, B. A. Myers, M. Higgins, J. Hughes, T. K. Harris, R. Rosenfeld,
M. Pignol. "Generating Remote Control Interfaces for Complex Appliances." Submitted
for publication, available at the web server of the Pebbles project,
http://www-2.cs.cmu.edu/~pebbles.
[28] Sun Microsystems: "Java Management
Extensions Instrumentation and Agent Specification", V 1.0, July
2000.
About the authors
|
 |
Rainer Weinreich is an assistant professor
at the Johannes Kepler University of Linz. His research interests
include component-based and distributed software architectures
and mobile agents. He can be reached at rainer.weinreich@jku.at. |
 |
|
Reinhold Plösch is an assistant
professor at the Johannes Kepler University of Linz. His research
interests include reliable components and mobile agents. He can
be reached at reinhold.ploesch@jku.at. |
Cite this article as follows: Rainer Weinreich, Reinhold Plösch: “Remote
Configuration of Agent-Based Component Systems”, in Journal
of Object Technology, vol. 2, no. 6, November-December 2003, pp.
67-84. http://www.jot.fm/issues/issue_2003_11/article1
|
