PROCESSING REMOTE MEASUREMENT DATABASES BY THE

MEANS OF MOBILE AGENTS

Steffen Kernchen, Dmytro Rud, Fritz Zbrog, Reiner R. Dumke

Department of Computer Science, Otto-von-Guericke-University of Magdeburg, Magdeburg, Germany

Keywords:

Agent Technology, Measurement Database, Remote Processing.

Abstract:

This paper discusses possible approaches for using mobile agents for accessing and processing of big remote

databases containing measurement data.

There are several reasons that make it inappropriate to dispatch raw data over the network. (a) Those data

may be conﬁdential and therefore need to be anonymized. (b) The amount of the data can be too big. In

this case it could be advisable to generalize the data on the database provider node and to transfer only these

generalization results to the customer. (c) Furthermore, this special information processing can be not in line

with qualiﬁcations of both the database holder and its clients. The usage of agents gives the possibility to

outsource the development and installation of additional software to an external agent provider, which is then

responsible for regular updates of the software considering aspects like new algorithms.

Application scenarios are outlined and certain kinds of service will be described and motivated with examples.

1 INTRODUCTION

Measurement databases can be adopted in many ﬁelds

of human activities. Typical examples are weather

forecasting, software quality assessment, and pro-

duction control. A common trait of measurement

databases is their potential for the organization do-

ing measurements and collecting the data, and also

for third-party users. The database-holding organiza-

tion can proﬁt from giving access to its database.

Therefore the question about mechanisms of such

access arises. Many functional and non-functional as-

pects must be taken into account for development of

these mechanisms e.g. performance, security, format

conversion, data generalization, etc.

In this paper we propose our solution. The idea

is to use mobile agents, which act on the side of the

database on behalf of third-party database users.

To talk about agents and to use them it is neces-

sary to understand what they are. Based on a clas-

sic deﬁnition of agents we deﬁne agents as software

components with certain properties (Wooldridge and

Jennings, 1994). Autonomy, social competencies, re-

activity and pro-activity are indispensable. Additional

properties can be mobility, collaboration and the abil-

ity to learn. Agents that will be described in this

paper will have autonomous characteristics, because

they will be able to perform their tasks without di-

rect supervision of humans or other agents. An im-

portant aspect will be the assurance of applicability in

differentiated environment through interactive adap-

tation mechanisms. Perceiving changes in the envi-

ronment and performing reactions leads to a reactive

agent. This aspect can become important because of

potential changes of the data to be processed. Pro-

activity describes a goal-directed behaviour.

There are several reasons that make it inappropri-

ate to dispatch raw data over the network:

• The data may be conﬁdential and therefore need

to be anonymized.

• The amount of the data can be too big. In this case

it could be advisable to generalize the data on the

database provider node and to transfer only these

generalization results to the customer.

• Furthermore, this special information processing

can be not in line with qualiﬁcations of both the

database holder and its clients.

184

Kernchen S., Rud D., Zbrog F. and R. Dumke R. (2007).

PROCESSING REMOTE MEASUREMENT DATABASES BY THE MEANS OF MOBILE AGENTS.

In Proceedings of the Third International Conference on Web Information Systems and Technologies - Internet Technology, pages 184-188

DOI: 10.5220/0001271601840188

 SciTePress

The usage of agents gives the possibility to out-

source the development and installation of additional

software to an external agent provider, which is then

responsible for regular updates of the software con-

sidering new algorithms etc.

These ideas will be illustrated by a practical ex-

ample. We will introduce an agent-based system for

processing a database containing web service perfor-

mance measurement results.

The rest of the paper is organized as follows: sec-

tion 2 gives a review of available related work, section

3 represents the core of our paper and outlines con-

cepts and potential use cases of integrating agents in

existing distributed software infrastructures. Section

4 presents practical aspects of our implementation and

section 5 is devoted to conclusions and proposals re-

garding subsequent work.

2 RELATED WORK

The following existing approaches resemble our

ideas.

Using agents as mediators for human database ac-

cess is a common idea. They act as proxies to create

queries for database access ((Masuoka and Ohtani,

1999), (Elio et al., 2000)). That is motivated by as-

sumptions like (a) highly complex database design so

it is not possible for the human agent to specify a sin-

gle, simple database query for which there is one sin-

gle answer; (b) vague set of constraints when starting

the search task, (c) multiple search goals, or (d) the

interface is not visual or requires direct manipulation.

The realization of distributed databases is another

important role for agents in this context. While work-

ing towards a certain goal, they may exploit con-

currency, parallelism and distribution to thereby be-

queath those functionalities to databases (Kirchberg,

2006).

Agents themselves include databases. They must

carry a view of their environment to be able to make

decisions what can be seen as a local database. Ob-

taining a durable view over time and across dis-

turbances is essential for agent success. Thereby

multiagent systems form highly distributed databases

(Lockemann and Witte, 2005).

3 PROPOSED APPROACH

3.1 Involved Parties

In our model the following parties exist. The data

holder owns a large data amount that is to be pro-

cessed. On the data holder side there are an interface

for interaction with the agent provider, a service for

conﬁguration of arrived agents and the database men-

tioned above. The functionality necessary for pro-

cessing the database can be obtained from the agent

provider in form of an appropriate agent. Figure 1

shows interaction steps of the components in the ar-

chitecture proposed by the authors. These compo-

nents will be discussed in detail below.

Data holder

DB Agent Provider

Agent

request()

create

registration()

report()/logoff()

report()

accounting()

configuration request()

configuration()

task processing

Agent

Coordinator

Agent Configuration

Service

Figure 1: Interaction ﬂow of involved parties.

3.1.1 Data Holder

The interface of the agent coordinator is dedicated

for interaction with agent providers and their agents.

It initializes the interaction, registers the generated

agents and carries out management tasks. Special on-

tologies could be needed to solve possible interoper-

ability issues. It is important to standardize relevant

vocabulary and message exchange patterns used for

request to agent provider, registration of agents and

accounting process (Gr

utter, 2005). The Web Ontol-

ogy Language (OWL) (W3, 2004) could be appropri-

ate for that purpose.

Providing a uniform database accessing mecha-

nism is the most important task of the agent con-

ﬁguration service, because there might be different

databases and database schemes. This service sup-

plies necessary information about access credentials

and addresses of tables and views which need to be

processed. Furthermore the agent gets in that way a

possible location for storing intermediate results.

3.1.2 Agent Provider

The web service located on the side of the agent

provider takes orders of the clients and instantiates

appropriate agents for autonomous data processing.

PROCESSING REMOTE MEASUREMENT DATABASES BY THE MEANS OF MOBILE AGENTS

185

Other tasks are the accepting of reports and account-

ing. Non-functional properties of both the provider’s

interface and the delivered agents could be described

using special ontologies.

3.1.3 Agent

The agent is the main working component in the pro-

posed architecture. It is instantiated by the agent

provider and should support all requested features

speciﬁed in the clients order. A modular construction

system and a predeﬁned skeleton constitute the foun-

dation of the generation process. After migration the

agent registers itself on the agent coordinator and is

being conﬁgured for database access. Now it is ready

to perform its tasks. Finally it sends reports to the

agent coordinator and the agent provider as a basis

for service accounting.

Security aspects such as safe code distribution and

sandbox-based execution should be respected by im-

plementing the infrastructure. To avoid espionage

network interaction is minimized, because main com-

munication takes place on the data holders side. Fur-

thermore we propose usage of secure transport proto-

cols and authentication mechanisms.

In the two following subsections we will present

possible application scenarios.

3.2 Acquisition of Third-party

Know-how

The example in the introduction can be extended to

several ﬁelds of application. In the scenario presented

here, the large amount of data on the data holder side

needs knowledge and know-how for analysis. These

algorithms can be subject to change or proprietary.

The proposed architecture makes the data holder in-

dependent of procurement and update of monolithic

resource-consuming software products or expensive

in-house development. Time and effort for develop-

ment, optimization and maintenance is outsourced to

specialized providers. In that way service evolution is

simpliﬁed, too.

The further advantages of using agents are mini-

mized network load and increased security no conﬁ-

dential information must be dispatched.

Other possible ﬁelds of application of agents in

this case are knowledge discovery in self-contained

data volumes, automatic tax consultancy or the exten-

sion of the internal knowledge base of the agent or

its providing service in a generalized and anonymized

manner.

3.3 Case Study: Web Services

Measurement Service

In this section we will outline another possible sce-

nario of integrating software agents in a web service-

based distributed infrastructure.

The web service measurement service Wesement,

being operated by the authors of the present paper

as part of their Web Service Trust Center research

project ((Schmietendorf and Dumke, 2005), (Schmie-

tendorf et al., 2004), (Rud, 2005)), is collecting per-

formance statistics of third-party web services. Any

web service provider can use Wesement for long-term

availability, metadata stability and performance mea-

surement of its services at no-cost. Collected statistics

is being persisted in a relational database. The only

available means go generalize the data in the web-

based Wesement frontend is to represent it graphically

in form of per-day or per-month diagrams. That is un-

ambiguously insufﬁcient, because:

• Another presentation form for example a web

service provider, simply wants to get notiﬁed

whether its web services are performing well on

a given day (i.e. to get a boolean value instead

of a PNG image) or to receive a list of services

whose performance in this month has fallen be-

low the preconﬁgured limit.

• Another time granularity some providers may

want to get weekly or yearly reports in addition

to daily or monthly ones.

A possible solution of this problem would be to

change the measurement service frontend itself. But

this way is tied with enormous maintenance effort, be-

cause the frontend will need to be customized almost

every time a new provider comes and registers its ser-

vices. Another possibility for the providers is to get

raw statistics (e.g. in XML format) and process it lo-

cally.

In our opinion, the most appropriate solution is

to use agents, which work on the Wesement’s side

and thus have local access to the statistics database.

Agent technology provides the highest degree of pro-

ductivity, because it is the only possibility for clients

to extend the infrastructure of the server. By this they

are able to remotely perform their tasks in direct ad-

jacency to the possible source of events. Results of

their calculations can be then sent to the correspond-

ing web service providers. It is also advisable that

agents work continuously and keep track of services’

performance changes in “real-time” if a negative trend

is detected, the provider can be notiﬁed early enough.

The next question is, where these agents can be

taken from. Below we outline three possible answers

WEBIST 2007 - International Conference on Web Information Systems and Technologies

186

and discuss their advantages and disadvantages:

• Agents are implemented and provided by the mea-

surement service’s operator, i.e. by us. In this case

we have roughly the same development effort as if

we were changing the Wesement frontend, but the

approach differs instead, we develop some kind of

plug-ins for the backend.

– Advantages: (a) possibility to reuse such agents

for many web service providers; (b) no security

risks and low agents conﬁguration effort.

– Disadvantages: Wesement is a research project,

and we have neither interest nor resources to

develop the agents.

• Agents are implemented and sent to the measure-

ment services side by the web service providers.

– Advantages: the providers have the full control

of how their agents behave.

– Disadvantages: (a) reuse of agents between

many providers is impossible; (b) same as in

previous case, the provider might not have all

necessary resources to develop and manage the

agents.

• Full division of labour a third party works on be-

half of web service providers and deals with de-

velopment and management of agents.

– Advantages: (a) possibility to reuse agents for

many web service providers; (b) possibility for

providers to select agents from many offerings.

– Disadvantages: management efforts.

1.2

Measurement

Service

Web Service

Provider

Agent

Provider

Order 1.1

Figure 2: Agent deployment scenarios.

Figure 2 shows the proposed approach. Interac-

tion steps of the three possible scenarios discussed

above are numbered appropriately.

The described approach can increase ﬂexibility of

the service measurement infrastructure.

4 AGENT-BASED PROCESSING

OF MEASUREMENT

DATABASES

In this chapter we present the most important aspects

regarding the implementation of agents for remote

processing of measurement databases. As aforemen-

tioned we used the database of our existing service

Wesement containing performance statistics of web

services.

For the execution of agents an infrastructure is

needed. We have choosen JADE as a java-based agent

platform to provide normative services like life cycle

management, white pages service, yellow pages ser-

vice and message transport service as deﬁned by the

according FIPA standard for agent platforms. Addi-

tional services are agent-software integration, an on-

tology service and human agent interaction.

Based on this technology we created our multi-

agent system. Therefore we launched one JADE plat-

form with several containers. They are used to logi-

cally separate agents and are often referred as “agent

cities” in literature. In JADE they can be distributed

on several computers. In our case one container re-

sides on the same computer as the database to allow

its remote processing and to guarantee the aforemen-

tioned advantages. The others are distributed.

Entry point for agent creation is the ClientAgent.

It is launched with the JADE platform and presents a

Graphical User Interface (GUI) to the user. The main

objectives of this agent are the selection of an ap-

propriate processing agent type as well as the deﬁni-

tion of required parameters. The ClientAgent is able

to detect available processing agent deﬁnitions and

presents parts of their corresponding GUI’s. Thereby

separation of ClientAgent and processing agent func-

tionalities is guaranteed. Each of the later agents pro-

vides an own GUI component for the deﬁnition of

necessary parameters. Figure 3 visualizes the Client-

Agent with a graphical component of a picture agent.

Figure 3: Sending a PictureAgent for remote processing.

PROCESSING REMOTE MEASUREMENT DATABASES BY THE MEANS OF MOBILE AGENTS

187

Parameters common to all agents are the web ser-

vice ID, the result delivering deﬁnition and the selec-

tion of the processing agent. Therefore these aspects

are integrated into the ClientAgent in addition to a

window component presenting status information and

locations where the results of the processing agents

are locally stored. By the web service ID the data of

the web service to be analyzed can be clearly identi-

ﬁed. Our approach takes beneﬁts from the advantages

of mobile agents. So it is possible to deﬁne result de-

livering by intra-platform communication as well as

by agent migration.

The remote container accommodates an additional

agent with proxy functionalities. It provides database

accessing information for the processing agents and

is intended to be extended by safety mechanisms to

restrict database access to secure agents. All agent

communication acts are ontology-based. Thereby the

possible conversation content is deﬁned and the archi-

tecture is extendible towards the usage of additional

web service measurement services. From a techni-

cal point of view this ontology needs to be mapped to

Java. Classes realize the underlying communication

in the multiagent system.

The presented PictureAgent needs additional pa-

rameters about the time interval to be observed and

a measurement quality boundary. As a result it cre-

ates a graphical visualization presenting performance

statistics of third-party web services.

We exemplary implemented two more processing

agent types. The ObserverAgent periodically (e.g.

weekly, monthly or self-deﬁned) checks the state of

the web service for a predeﬁned time and sends back

alert messages in case of state changes. The XML-

Agent creates XML documents containing the perfor-

mance data of the selected web service. They can be

used for further processing. Its graphical component

is shown in ﬁgure 4.

Figure 4: Sending a XMLAgent for remote processing.

5 CONCLUSIONS AND FURTHER

WORK

We have analyzed possible scenarios of accessing re-

mote measurement databases using mobile agents.

We outlined also different implementation approaches

and discussed their advantages and disadvantages.

Security issues were mentioned too. An example il-

lustrated the effectiveness of the proposed approach.

We plan to continue our research and to extend the

infrastructure functionality for automated interaction

in a web service-oriented manner by the deﬁnition of

appropriated access interfaces. Another aspect of our

further work is the extension towards accessing mul-

tiple databases.

REFERENCES

Elio, R., Haddadi, A., and Singh, A. (2000). Task mo-

dels, intentions, and agent conversation policies. In

Proceedings of the Paciﬁc Rim Conference on AI

(PRICAI-2000), Lecture Notes in Artiﬁcial Intelli-

gence 1886, pages 394–403. Springer Verlag.

utter, R. (2005). Software Agents in Semantic Web. (in

German). Informatik Spektrum, (6):1–11.

Kirchberg, M. (2006). Dbaa/acl - a database agent archi-

tecture and communication language. In Isaas, P.,

McPherson, M., and Bannister, F., editors, Proceed-

ings of the IADIS International Conference e-Society

2006, pages 244–249. IADIS Press.

Lockemann, P. C. and Witte, R. (2005). Agents and

databases: Friends or foes? In Proceedings of the

9th International Database Engineering & Applica-

tion Symposium (IDEAS05), pages 137–147.

Masuoka, R. and Ohtani, T. (1999). Agent description on-

tology. Proposal to the 13th meeting of FIPA. Seoul,

Korea.

Rud, D. (2005). Methods for Quality Assessment of Web

Service Offerings (Diploma thesis, in German). Mas-

ter’s thesis, Otto-von-Guericke-University of Magde-

burg.

Schmietendorf, A. and Dumke, R. (2005). A Measurement

Service for Monitoring the Quality Behaviour of Web

Services offered within the Internet. In Proceedings of

IWSM/MetriKon 2004, pages 381–390. Shaker-Verlag

Aachen.

Schmietendorf, A., Dumke, R., and Reitz, D. (2004). SLA

Management Challenges in the Context of Web-

Service-Based Infrastructures. In Proceedings of

the IEEE International Conference on Web Services

(ICWS 2004), pages 606–613, San Diego, USA.

W3 (2004). OWL Web Ontology Language.

Wooldridge, M. and Jennings, N. R. (1994). Agent The-

ories, Architectures, and Languages: A Survey. In

ECAI Workshop on Agent Theories, Architectures, and

Languages, pages 1–39.

WEBIST 2007 - International Conference on Web Information Systems and Technologies

188