=Paper=
{{Paper
|id=Vol-210/paper-14
|storemode=property
|title=Engineering a Brokering Framework for Providing Semantic Services to Agents on Lightweight Devices
|pdfUrl=https://ceur-ws.org/Vol-210/paper14.pdf
|volume=Vol-210
|dblpUrl=https://dblp.org/rec/conf/ecai/SpanoudakisM06
}}
==Engineering a Brokering Framework for Providing Semantic Services to Agents on Lightweight Devices==
https://ceur-ws.org/Vol-210/paper14.pdf
Engineering a Brokering Framework for Providing
Semantic Services to Agents on Lightweight Devices
Nikolaos I. Spanoudakis1 and Pavlos Moraitis2
Abstract. This paper describes an approach towards allowing 2 THE BROKERING FRAMEWORK
lightweight nomad devices like mobile phones to access semantic
services that have either been advertised by agents or follow the In order to address our requirements we used the broker agent
semantic web services paradigm. The limitations of lightweight type [6], who can actively interface between the requester and
devices like lack of capability to process XML documents or to provider agents by facilitating the requested service transaction.
deal with complex data types and perform computationally Thus, all communication between requester and provider agents
demanding tasks are overcome by using this approach. Thus, we has to go through the broker. In this process, the requester’s
consider that when a user or agent is in a nomad or mobile identity is unknown to the service provider. Thus, assuming the
context this approach can aid him in searching for and acquiring business role of a service aggregator the broker services his
simple or complex - added value services from the web. 12 customers using providers as resources. The service requesters
are assumed to be aware of the services that they need. In our
system, the role of the broker is to either select the best service
1 INTRODUCTION for the requester, or to redirect the request to the appropriate
broker. The added value of our approach is the service protocol
There is a growing interest on the launching of agents on that allows for anonymous brokering for agents in a nomad
lightweight devices and that comes from many different business context adding, for the first time, the possibility to broker
and research sectors, including the Ambient Intelligence, the subscription services.
infomobility, the collaborative working environments and others. The matchmaking process is a subset of LARKS [11], suited
Lightweight devices pose certain limitations on the available for the nomad device applications domain. In this context, the
resources (CPU speed, memory capacity, storage capacity, etc) requester is assumed to use the same ontology with the broker.
for programs. Services are becoming semantic so that agents can Our process’s novelty lies in the manipulation of the inter-agent
adequately locate and execute them in order to achieve their messages content that is delivered using the LEAP protocol,
goals. Semantic services imply the use of XML, RDF and OWL which poses specific limitations and is in byte code format.
[13] technologies. The use of such technologies requires more Heterogeneous services are wrapped by service provider agents
than what is available on a lightweight device. who advertise and offer services using the application domain
Brokering is the solution to this problem, since the broker can ontology.
always be on a server computer side having access to needed Moreover, brokers can be distributed and each one can
computational and storage resources. The nomad devices residing specialize to a specific domain of services. We follow the notion
agents need access to services that require computational power of broker specialization of Infosleuth [9]. We model this
(for example filtering 100 hotels in order to present to a user the requirement using a broker capability property concept allowing
best 10). Such services are proposed to be offered by server- a broker to define its specialization in terms of service parameters
based provider agents. Important works from the agent constraints and share it with other brokers. The advantages of our
technology domain, but also from that of the semantic web, have approach compared to Infosleuth are a) brokers do not simply
addressed the issue of brokering and matchmaking ([3], [11], exchange their advertisements but define their special capabilities
[7]). However, these works lack the support for agents on the over the provided services in the domain, b) the requester agent
specific context of being resident on nomad, lightweight devices. doesn't have to define a search policy for the broker, and, c)
Our work builds on this previous work and provides a compatibility with FIPA standards.
framework for defining services using the OWL-S [12] paradigm The way to profile the services, the matchmaking process and
and making them available to lightweight devices. We use the the brokering protocol are described in detail in the following
FIPA-ACL [2] standard for defining the agent messages that are paragraphs.
used by our novel interaction protocol. The content of the
messages is encoded using the FIPA-SL [2] language for
lightweight agents. 2.1 Service Profiling
In section 2 we describe our approach in detail and we
conclude with a discussion in section 3. We use italics in order to For service profiling we follow the semantic web trend and thus
type concepts of the ontology that we developed, their properties are compatible to OWL-S. The service profile (SP) defines the
and ACL message performatives. type of the service (e.g. mapping service), describes input and
output parameters, as well as preconditions and post-conditions.
Here we would like to note that in the service parameters
1
Singular Software SA, Greece, email: nspan@singular.gr definition we have defined semantics for declaring a parameter as
2
René Descartes University, Paris, France, optional or mandatory.
email: pavlos@math-info.univ-paris5.fr
2.2 The matchmaking process device uses ontology java beans [1] in order to represent
ontology concepts. These beans are normal Java classes
Having defined the input requests and profiles we can proceed containing properties that cannot be ambiguous, i.e. defined of
to defining the matchmaking process. We need to match a service type Object because the LEAP encoding and decoding process
advertisement to a service request. Two types of matching best needs specific data types to instantiate as properties of concepts.
serve our needs ([7], [11]): a) the exact matching, which demands
that the advertised service has the same semantics and equal
more input/output parameters than the ones requested. The exact
matching is obviously always preferable.
Our matchmaking algorithm gradually filters the repository of http://imagine-
it.eu/ontology#RequestForEService
advertisements until the one best to serve the request is found.
Three types of filters, originally proposed by [11], are used: a) broker@nspan2kp:1099/JADE
Semantic Match (SM) searches the service profile advertisements
(PAs) for a service that matches the request (RP), b) Profile
Match (PM) searches the PAs provided by the SM for input and
http://imagine-it.eu/ontology#
output parameters that match those of the request. PM determines createMap
which PAs are exact or plug-in matches and sorts them
accordingly, and, c) Constraint Match (CM) determines which of
the PAs provided by the SM, match the constraints of a request. http://imagine-it.eu/ontology#
CallParameter
CM is performed to the sorted list provided by PM and either the http://imagine-
first or all PAs that successfully match the constraints are it.eu/ontology#forCountry
http://www.w3.org/2001/XMLSchema#
selected depending on the broker’s policy. string
DE
A special CM is needed before SM (named Pre-CM) so that
the broker agent (BA) can determine if he can serve the request
or it needs to redirect the request to another broker. Thus, broker
http://imagine-it.eu/ontology#
capabilities are described as constraints for parameter values. For CallParameter
querying the PAs repository we use the RDQL (RDF Query http://imagine-it.eu/ontology#
screenSize
Language) of the Jena open source tool [5]. http://imagine-it.eu/ontology#
Thus, according to our matchmaking algorithm, the broker ScreenSize
first applies the pre-CM filter. If he can handle the request, he
200
then sequentially applies the three other filters (SM, PM, CM) to 320
his PA repository.
Technical challenges were related to this matchmaking
process. The first was relevant to the transformation of a LEAP
message to RDF format for filtering. In order to overcome it we
use the LEAP codec for decoding a message at the broker side
and then encode it again with the use of the RDF codec [4] (see
an example in Figure 1). Thus, the request gains the necessary
semantics so as to be processable by Jena. From that point
forward the matchmaking process takes place and whenever the
Figure 1. A Service Request Message (RDF)
response of the service provider is ready, it is encoded at the
broker side with the LEAP codec and sent to the lightweight
We overcame this issue by defining all possible values that a
agent requester.
parameter can have as properties of the CallParameter concept.
Another problem that we had to overcome is that FIPA ACL
The basic properties of the CallParameter in an OWL/RDF
allows for a single ontology to be included in the content of an
setting would be the withName, withType and withValue. In this
ACL message. Thus, it is not possible to use different existing
case, however, we must cater for all possible types defined in our
ontologies when defining the ACL protocols (e.g. import all
ontology concepts. Figure 1 shows an instance of a request
OWL-S namespaces and use their concepts). That is why we
message related to a specific application [8], which is based on
added in our ontology all the concepts that we need in order to
the http://imagine-it.eu/ontology# namespace. The reader can
define a service profile similar to OWL-S. However, these are
observe the hasParameterIn RDF sequence element that is
reusable since the Protégé tool [10] that we used in order to
composed of a list of CallParameter elements that have a name
define our ontology doesn’t associate namespaces to ontologies
(parameter withName), a type (it can be a simple data type such
before deployment.
as string or a complex type like for example the ScreenSize type)
For describing an input/output parameter within a request for a
and a value corresponding to the type.
service we created the CallParameter concept. There, we
For example, for the ScreenSize type (these types are also
encountered another technical challenge related to the fact that
related to application [8]) the relevant property of CallParameter
we used the LEAP codec and thus, we could not add dynamically
that is used is the withScreenSizeValue. Similarly the forCountry
a value concept to a parameter property as we could easily do in
CallParameter is of type string and has the withStringValue
an RDF document. This happens because the agent on the nomad
property. Thus, the CallParameter concept has as many such
properties as the number of the data type concepts defined in our 3 DISCUSSION
ontology. However, for each instance the requester defines the
withName and withType (withType=PropertyType) properties and We used this brokering framework in the context of IST project
the relevant withPropertyTypeValue property. It is obvious that a Im@gine IT in the infomobility sector domain [8]. An Im@gine
designer can define appropriate parameter types related to his IT prototype has been developed and deployed. Two added value
own application. service providers were developed.
This work is meant as an extension of important works in the
brokering domain ([3], [11], [7]), towards offering semantic
2.3 The Service Protocol services to nomad devices. We provide a complete solution for
the nomad devices service provisioning including not only simple
The service provisioning protocol is presented in Figure 2 in the services but also the delegation of complex tasks and subscription
form of a FIPA interaction diagram [2]. services. The solution is composed of a protocol, a service
profiling scheme and the relevant matchmaking process.
Requester Broker Service Provider
As future work we aim to enrich the broker with the capability
to use directly OWL-S services advertisements (along with those
Request Advertise service
received by other agents) where the broker performs the service
protocol. grounding himself.
Inform The SL content of
the request
Request message is the
AgentAction
"RegisterEService" Acknowledgements
Service Protocol. The Matchmaking . Thus, a service
SL content of the provider advertises
Request message is the
Request
his service. We gratefully acknowledge the European Commission
AgentAction
"RequestForEService".
Information Society Technologies (IST) Programme and
Alternative - Option
Inform
specifically the Integrated Project (IP) “Ambient Intelligence
X System of Agents for Knowledge-based and Integrated Services
This is optional in the Confirm
sense that the broker for Mobility Impaired users” (ASK-IT, IST-2003-511298)
Failure
might invoke a simple
service through DMM
project for contributing in the funding of our work.
Refuse X
X
Alternative
Inform Service Protocol. The
REFERENCES
SL content of the Inform
X Confirm [1] Caire, G., Van Aart, C., Bergenti, F., Pels, R. : Creating and Using
or Confirm message is
Failure the Predicate Ontologies in Agent Communication. Workshop on Ontologies and
"FoundServiceResults"
X Refuse Agent Systems at AAMAS 2002
X [2] FIPA, Foundation for Intelligent Physical Agents, www.fipa.org
Option [3] Gomez, M., Abasolo, C., Plaza, E.: Domain-independent ontologies
Cancel
for cooperative information agents. In: Cooperative Information
Cancel
X Agents V. LNAI 2128, Springer-Verlag, 2001, p. 118-129
X [4] JADE, Java Agent Development Environment, http://jade.tilab.com/
[5] Jena, A Semantic Web Framework for Java,
Option Inform http://jena.sourceforge.net/
Inform [6] Klucsh M., Sycara K.: Brokering and Matchmaking for
Coordination of Agent Societies: A Survey. In Omicini et al (editor),
Coordination of Internet Agents, Springer, 2001
[7] Li. L. and Horrocks, I.: A software framework for matchmaking
Figure 2. Service Protocol Definition based on semantic web technology. Int. Journal of Electronic
Commerce, Vol. 8, No 4, 2004
The service protocol can also be used for subscription [8] Moraitis, P., Petraki, E. and Spanoudakis, N.: An Agent-Based
services provisioning. We use the FIPA Request, Inform, Refuse, System for Infomobility Services. In: 3rd European Workshop on
Multi-Agent Systems (EUMAS2005), Brussels, Belgium, December
Failure and Confirm performatives. The important AgentAction
7 - 8, 2005
and Predicate concepts [1] that are used as content in the ACL [9] Nodine, M., Bohrer, W., Hee Hiong Ngu, A.: Semantic Brokering
message are also presented. The participants are the Requester over Dynamic Heterogeneous Data Sources in InfoSleuth. In Proc.
agent type (RE), the Broker agent type (BR) and the service of the International Conference on Data Engineering, Sydney,
provider agent type (SP). In the case of distributed brokering the Australia, March 23-26, 1999
SP is another broker, who considers the broker, who received the [10] Protégé, An Ontology Editor and Knowledge Acquisition System.
original request, as a RE (implementing the relevant part of the http://protege.stanford.edu
same protocol). [11] Sycara, K., Widoff, S., Klusch, M. and Lu, J.: LARKS: Dynamic
Matchmaking Among Heterogeneous Software Agents in
Finally, for the service subscription protocol, the broker
Cyberspace. JAAMAS, 5, 173–203, 2002.
always retains the recent addresses of the communicating agents [12] The OWL Services Coalition (Martin, D. et al.): Bringing Semantics
so as to be able to forward new messages to the latest address of to Web Services: The OWL-S Approach, Proc. of the 1st Int.
the requester agent. This is important since the requester agent is Workshop on Semantic Web Services and Web Process
on a nomad device and usually is assigned a dynamic IP Composition (SWSWPC2004), July 6-9, 2004, San Diego,
whenever he accesses the network. California, USA.
[13] W3C, The World Wide Web Consortium, www.w3c.org