=Paper=
{{Paper
|id=Vol-61/paper-3
|storemode=property
|title=Software Agents in the Wireless World - Application to Mobile Services -
|pdfUrl=https://ceur-ws.org/Vol-61/paper3.pdf
|volume=Vol-61
|dblpUrl=https://dblp.org/rec/conf/mservices/MaamarMM02
}}
==Software Agents in the Wireless World - Application to Mobile Services -==
https://ceur-ws.org/Vol-61/paper3.pdf
Software Agents in the Wireless World
- Application to Mobile Services -
Zakaria Maamar , Wathiq Mansoor , and Qusay H. Mahmoud'
Software Agents Research Group ' WITLab
@ZU
College of Information Systems School of Computing Science
Zayed University Simon Fraser University
Dubai, United Arab Emirates Vancouver, Canada
zakaria.maamar,wathiq.mansoor@zu.ac.ae qmahmoud@cs.sfu.ca
Abstract The paper discusses mobile services, denoted by m-services,
in the wireless world. M-services are viewed as an extension to the e-
services paradigm. The wireless world has its own features that make it
dierent from the wired world. For instance, new communication means
need to be used, new user-friendly services need to be suggested, and
new types of computing resources need to be involved. The paper also
discusses the use of software agents in addressing the following issues:
how are m-services discovered in an open wireless environment? How are
m-services combined together? And how are m-services made executable
on wireless devices?
1 Introduction
According to [3], the Internet is going through several major changes. Indeed,
the Internet is becoming a vehicle of services rather than just a repository of
information. Currently, several organizations are making their services accessible
over the web. Usually, e-services denote this kind of services. Besides the new role
of the Internet, we expect that more and more e-services will be oered to people
who use wireless devices to conduct their operations. Further, we expect that
more and more wireless devices will be enhanced with new advanced computing
resources, which will enable them in the near future to become mobile o ces. We
are all witnessing the tremendous growth in the development and use of wireless
devices across the world. Unfortunately, this growth is accompanied with its set
of problems. For example, wireless devices are strictly bound to their batteries
for operation. In order to support wireless devices-oriented users1 , we aim at
working on a new generation of e-services that will be specially designed and
developed to t wireless devices. M-services denote this new generation of e-
services.
There exist several types of wireless devices, varying from mobile phones to
Personal Digital Assistants (PDAs). These devices present several shortcomings
that make their use requires speci c arrangements. For instance, the services to
1
Users who use wireless devices to carry out operations.
be oered need to be tailored to each device individually. Unfortunately, this
goes against the e-services platform independence principle. Thus, leveraging
e-services into m-services is a necessity. M-services will have to consider the
characteristics of the wireless devices on which they will be running. In fact, we
advocate that m-services will be fetched on-demand from provider sites to users'
wireless devices.
Having pre-installed services on users' wireless devices is an option that could
be considered. However, this option would have worked for a small number of
users where looking for the lowest common denominator between them is fea-
sible. In an open environment with dierent users and needs, looking for the
common denominator is not trivial. Therefore, on-demand delivery of services
to wireless devices is more appropriate than pre-installing services. Enabling
the downloading of dynamically composed services is among the approaches to
follow for systems designed to the wireless world.
Section 2 motivates our work on m-services. Section 3 de nes mobile com-
puting and e-services. Section 4 presents our system of m-services. Section 5
describes our system implementation. Section 6 presents related work. Section 7
concludes the paper. It is made clear at that level that issues such as negotiation
and coordination, while important, do not fall in the scope of this paper.
2 Motivating scenario
To motivate our work, we consider the following ctive scenario. A sales repre-
sentative working for a software company; it is based in country X but serves
customers from over the world. Since the representative is most of the time on
the move visiting customers, he is equipped with a PDA, which provides basic
o ce tools. Moreover, the representative uses the PDA to record the deals he
made with customers. It may happen that in preparation for an important meet-
ing, the representative has to carry out speci c operations such as simulating
the consequences of this meeting on the company stock shares. Unfortunately,
before he leaves his o ce this time he did not download the appropriate software
applications into his PDA. Consequently, he decides to proceed as follows. First,
he sends a "wireless" request to the company server. According to the workload
of the server, one of the following situations occurs.
Server not "busy" - it accepts the request and processes it. To this end, the
representative has to send "wirelessly" the required data. Later on, the server
transmits "wirelessly" results to the representative's PDA. If the representative
has known before that the server was not busy, he could have attached the
required data to the request he submitted in the rst time. Unfortunately, this
is di cult to predict.
Server "busy" - it suggests two alternatives to the representative. The rst
one is to put his request in a waiting list. The second one is to send the required
applications to his PDA for execution. These applications transfer has to follow
speci c rules, as we will discuss it.
In our work, we are interested in situation Server "busy" - second alternative,
where a wireless device will be acting as a computing platform to the applications
to be received from the server. We consider these applications as m-services.
3 Background
Mobile Computing refers to systems in which computational components, either
hardware or software, change locations in a physical environment. Moving from a
location to another is due to several reasons: component miniaturization, wireless
networks, and mobile-code programming languages. Kinds of mobile work are
as follows [15]: hardware mobility, software mobility, and combined mobility. A
code that is downloaded from a web site to a user's mobile phone combines both
hardware and software mobility.
E-service is an application component provided by an organization in order
to be assembled and re-used in a distributed, Internet-based environment [12].
A component is considered as an e-service if it is: 1) independent as much as
possible from speci c platforms and computing paradigms; 2) developed mainly
for inter-organizational situations rather than for intra-organizational situations
only; and 3) easily composable with other e-services.
4 System of m-services
4.1 M-services
The rationale of designing and developing m-services2 is to oer new opportuni-
ties to wireless devices-oriented users. It happens that these users postpone their
operations because they lack appropriate facilities on their devices. Therefore,
it becomes important to support such users by allowing them: 1) to search for
additional facilities, when needed, 2) to fetch these facilities to their wireless
devices, and 3) to conduct the operations 1) and 2) in a transparent way. A so-
lution to 1) consists of creating brokering mechanisms. A solution to 2) consists
of using wireless communication mechanisms. Finally, a solution to 3) consists
of using Software Agents (SAs) [6].
We consider an application component as an m-service if it is: transportable
through wireless networks; exible in term of composition with other m-services;
adaptable according to the wireless devices' computing characteristics; and exe-
cutable on wireless devices.
4.2 Architecture
In our work, brokering mechanisms and SAs are considered in the design and
development of a system oering m-services to wireless devices-oriented users.
This system's features are:
2
We'll be using m-service and service in an interchange way.
Develop three types of SAs: user-agent, provider-agent, and device-agent.
The rst type is associated with users of m-services. The second and third
types are associated with providers of m-services.
Create a software platform, called Meeting Infrastructure (MI), that will be
headed by a supervisor-agent. This MI has a brokering role [10].
Develop two types of delegates: provider-delegate and user-delegate. Dele-
gates interact respectively on behalf of user-agents and provider-agents in
the MI.
Develop storage servers that save the sequence of m-services to be sent to
wireless devices for execution. Storage servers are spread across networks
and storage-agents are responsible of them.
Figure 1 illustrates the architecture of our system. It is decomposed into four
parts: user, provider, MI, and storage. The MI and storage parts are linked to
the user part in a wireless way. Meanwhile, the MI and storage parts are linked
to the provider-part in a wired way.
Storage-agent1
Wireless connection
Wired connection
Storage
server1
M-services Notification M-services
Requests
User Provider-agent
Supervisor
User-agent Device-agent
agent
User Provider
delegate delegate
Wireless
Interactions Interactions Interactions
Provider
Meeting infrastructure Bank of
m-services
Storage Storage
serveri serverj
Figure1. Architecture of m-services system
The user part consists of users and user-agents. User-agents act on behalf
of users; they accept their needs, convert them into requests, and submit them
to user-delegates. The MI supervisor creates user-delegates. To satisfy users'
requests, user-delegates interact with provider-delegates.
The provider-part consists of providers, provider-agents, and device-agents.
Provider-agents act on behalf of providers of m-services; they advertise their m-
services to user-delegates, through provider-delegates. In addition, they monitor
the behavior of providers in case of new m-services are oered, and thus need
to be announced. In Figure 1, m-services are gathered into a bank on which
provider-agents and device-agents are located. Provider-agents create provider-
delegates. In the provider-part, device-agents support provider-agents' work. The
role of device-agents is to wrap m-services before they are sent to users' wire-
less devices for execution. The rationale of having device-agents is to consider
the dierences that exist between wireless devices, e.g. screen dimension and
processor speed.
The MI part is a software platform on which user-delegates and provider-
delegates interact in a local and secure environment [9]. In an open environment,
most of the interactions between requesters of services and providers of services
are conducted through third parties, known as brokers. Despite its important
role, a broker could easily become a bottleneck. To overcome this problem, re-
questers and providers may have to bypass the broker. They need a common
environment in which they meet and interact directly. The MI plays the role
of this environment. In our system, the MI supervisor-agent has several respon-
sibilities, among them: it monitors the interactions that occur within the MI;
it makes the MI a safe environment; and it directs user-delegates towards the
provider-delegates that interest them.
The storage part receives the sequence of m-services that will be sent to users
for execution. According to our system execution's principles, m-services are sent
to a user's wireless device one by one. Several advantages are obtained from the
use of storage-servers. A user-agent does not have to deal with several providers.
Its point of contact for getting the m-services is the storage-agent. The same
thing applies to device-agents that will be interacting with few storage-agents
instead of several user-agents. Security is increased for both users and providers.
Storage-servers are independent platforms where security control are conducted.
4.3 Software agents
User-oriented components User-agent resides in a wireless device. First,
the user communicates with his user-agent to arrange requests. After submit-
ting them to the user-delegate, the user-agent goes into a standby mode and
waits for noti cations from its delegate. Noti cations concern the sequence of
m-services that satis es the user's requests. Before executing them on user's de-
vice, m-services are put in a storage server. The MI supervisor-agent suggests to
user-delegate the storage server to be used considering for example the server's
location. To download the m-services one at a time from the storage server to
the user's wireless device, the user-agent communicates with the storage-agent.
The user-agent keeps track of the execution of an m-service, before it asks the
storage-agent to submit the next m-service. When it is received, the executed ser-
vice is deleted from the wireless device platform. Finally, the user-agent informs
the user about the completed requests.
If this is the rst time that a user-agent submits requests, the supervisor-
agent creates a user-delegate in the MI to be associated with that user-agent
(cf. Table 1). For the next requests, the user-agent interacts directly with the
user-delegate (cf. Table 2). Table 1 and Table 2 use "submit", "reply", and
"notify" performatives illustrating the interactions that take place between user-
agents and supervisor-agent and between user-agents and delegate-agents. In
Table 1, "submit" performative has ve elds among them "Device"; it speci es
the characteristics of the wireless device the user is using. The device-agent
considers these characteristics in its process of wrapping m-services. In Table 2,
"submit" performative occurs once a user-agent knows the delegate-agent to
which it has been associated.
Table1. Interactions user-agent/supervisor-agent
Submit(Id-submit: id1 , From: user-agent1 , To: supervisor-agent1 , Content:
request1 , Device: (Brand: brand1 , Type: type1 , Screen dim.: dim1 ))
Reply(Id-reply: id1 , From: supervisor-agent1 , To: user-agent1 (In-reply-to: id1 ),
Delegate: (Id: user-delegate1 , Contact: user-delegate1 @...), Storage-server: (Id:
storage-agent1 , Contact: storage-agent1 @...))
Table2. Interactions user-agent/user-delegate
Submit(Id-submit: id2 , From: user-agent1 , To: user-delegate1 , Content: request2 ,
Device: ())
Notify(Id-notify: id1 , From: user-delegate1 , To: user-agent1 (In-reply-to: id2 ),
Content: sequence1 /m-service1;2 )
User-delegate resides in the MI, acting on behalf of user-agent. The user-
delegate receives the user's requests from the user-agent (cf. Table 2). After-
wards, it interacts with provider-delegates. The purpose is to match user's re-
quests with providers' m-services. In case there is a match (we assume that there
is always a match), the user-delegate designs the sequence of m-services to be
included in satisfying the user's requests. Information about this sequence is
sent to the storage-agent (cf. Table 3). The purpose is to make the storage-agent
ready to receive m-services from device-agents. Furthermore, the user-delegate
noti es the user-agent about the sequence of m-services it has established (cf. Ta-
ble 2). In Table 3, two relevant elds of "to-get-ready" performative are impor-
tant. "Destination" eld corresponds to the user-agent for which the sequence of
m-services has been designed. "M-services" eld corresponds to the m-services
the device-agent has to submit. To set up a sequence, the storage-agent knows
the m-service that comes before and after the m-services to be submitted by a
device-agent. Instead of creating a user-delegate on a wireless-device platform
and shipping it to the MI, we suggested to undertake this operation in the MI
for two main reasons: even if we expect a big improvement in wireless devices'
resources, those resources have to be used in a "rationale" way; and the wireless
connection that transfers the user-delegate is avoided.
Provider-oriented components Provider-agent resides in provider's site, run-
ning on top of its resources. A part of these resources correspond to m-services.
Table3. Interactions user-delegate/storage-agent
To-get-ready(Id-to-get-ready: id4 , From: user-delegate1 , To: storage-agent1 , Se-
quence: sequence1 , Destination: user-agent1 @..., M-services: (From: device-agenti ,
Before: 0[m-serviceh ]1, Id: 1[m-servicei ]n, After: 0[m-servicej ]1))
Provider-delegates broadcast m-services to user-agents, through user-delegates.
The provider-agent is in constant interactions with its provider-delegate (cf. Ta-
ble 4). For instance: it communicates to the provider-delegate the negotiation
strategy it has to follow with user-delegates.
Table4. Interactions provider-agent/provider-delegate
Submit(Id-submit: id6 , From: provider-agent1 , To: provider-delegate1 , Content:
strategy6 /m-service6 , Device: ())
Inform(Id-inform: id1 , From: provider-delegate1 , To: provider-agent1 , Agreement:
(Sequence: sequence1 , With: user-agent1 , Service: 1[Id: m-servicei ]n), Storage-
server: (Id: storage-agent1 , Contact: storage-agent1 @...), Device: (Brand: brand1 ,
Type: type1 , Screen dim.: dim1 ))
Device-agent resides in provider's site. Its responsibility is to wrap m-services
according to the devices to which they will be sent for execution. Initially, these
m-services are sent to storage servers. The provider-agent has already submitted
the contact details of the storage-server to the device agent. We recall that
the user-delegate has informed the storage-agent of that storage server about
the m-services it will receive (cf. Table 3). Double-checking the information that
user-delegates and provider-delegates forward to a storage-agent guarantees more
security to our system.
Provider-delegate resides in the MI; it acts on behalf of provider-agent. In our
system, the provider-delegate is responsible for interacting with user-delegates,
regarding the m-services it oers. In addition, it interacts with its provider-
agent for noti cation purposes. Noti cations are then forwarded to device-agent
for consideration. We recall that the provider-agent creates a provider-delegate
and transfers it to the MI.
MI-oriented components Supervisor-agent resides in the MI and has sev-
eral responsibilities: it supervises the operations that occur in the MI; it medi-
ates in case of con icts between user-delegates and provider-delegates; it sets-up
user-delegates and assigns them to user-agents (cf. Table 1); it checks provider-
delegates identity when they arrive from provider sites; and it suggests to user-
delegates the storage server to be used.
User-delegate and provider-delegate are explained above.
Storage-oriented components Storage-agent resides on top of storage server.
The purpose of such a server is to save the m-services to be sent to wireless
devices for execution. According to the information on the sequence of m-services
it has received from the user-delegate (cf. Table 3, "before" and "after" elds),
the user-delegate arranges the sequence as the m-services start arriving from
providers. As soon as this sequence is completed, it informs the user-agent in
order to get prepared (cf. Table 5).
Table5. Interactions device-agent/user-agent
Get-prepared(Id-get-prepared: id7 , From: storage-agent1 , To: user-agent1 , Se-
quence: sequence1 , Status: ready)
Based on the requests it receives from user-agent, the storage-agent pushes
the m-services one at a time (cf. Table 6). These m-services are ready for execu-
tion. The deletion of m-services from the storage-servers as well as from wireless
devices follows speci c reliability rules (cf. Figure 3).
Table6. Interactions user-agent/storage-agent
Request(Id-request: id24 , From: user-agent1 , To: storage-agent1 , Sequence:
sequence1 , M-service: ?m-service1 )
Push(Id-push: id1 , From: storage-agent1 , To: user-agent1 (In-reply-to: id24 ), Al-
ready submitted: 3, Remained: 2, Attachment: m-service1 )
4.4 Operating mode
The operating mode of our system consists of ve stages: agenti cation, identi-
cation, correspondence, noti cation, and realization (cf. Figure 2).
Agenti cation stage purpose is to set up the dierent infrastructures and
agents that constitute our system. User-agents are established at the user level.
Provider-agents and device-agents are established at the provider level. Last but
not least, the meeting infrastructure and storage servers, including their storage-
agents, are created.
Identi cation stage purpose is to inform the MI supervisor-agent about the
existence of users and providers who are interested in our system. At the agen-
ti cation stage, user-agents and provider-agents are respectively installed on top
of users' wireless devices and providers' resources. The outcome of the identi-
cation stage is the creation of user-delegates and the reception of provider-
delegates coming from provider-sites. Creation and reception occur in the MI.
Provider-agents inform the supervisor-agent about their readiness to submit
their provider-delegates to the MI. User-agents inform the supervisor-agent
about the users' requests they would like to submit.
Meeting infrastructure
User Supervisor-agent
User-agent ion
eat
Cr
2.a
2.b Migration
eds
Ne
1.a 3. Interactions
1.b Creation
User-delegate Provider-delegate Provider
delegate Provider-agent
4.a M-services
4.b Contracts
7. M-services notifcation
notifcation
transfer for
5. Contracts
execution
notification
6. M-services
Storage-agent1 transfer
Storage
server1 Device-agent
Provider
Bank of
m-services
Figure2. Operating of m-services system
Correspondence stage purpose is to enable user-delegates and provider-
delegates to get together. User-delegates have requests to satisfy and provider-
delegates have services to oer. First, a user-delegate searches for the provider-
delegates that have the services it needs. Two approaches exist (cf. Table 7
and Table 8): a/ The user-delegate asks the supervisor-agent to suggest a
list of provider-delegates that have the services it needs. Here, the supervisor-
agent plays the role of a recommender. b/ The user-delegate requests from the
supervisor-agent the contact details of all the provider-delegates that exist in
the MI. Table 8 lists the advantages and disadvantages of both approaches.
Table7. Interactions user-delegate/supervisor-agent
Ask-for(Id-ask-for: id32 , From: user-delegate11 , To: supervisor-agent1 , Content:
1[servicei ,?provideri ]n)
Recommend(Id-recommend: id1 , From: supervisor-agent1 , To: user-delegate11
(In-reply-to: id32 ), Content: a/ Provider-delegate1;4 b/ Provider-delegates)
Independently of the approach of searching for delegate-providers, the user-
delegate submits its needs of services to selected provider-delegates after in-
teractions. Based on dierent parameters, such as workload and commitments,
provider-delegates answer the user-delegate. At this stage of our work, we as-
sume that providers do not have services in common. Consequently, there is no
need for a user-delegate to look for the best service (negotiation for a service
is 1 user with 1 provider)3 . Once the user-delegate and provider-delegates agree
3
This is not a shortcoming of our system. It is part of our current work to consider
1:N negotiation.
Table8. Advantages and disadvantages of searching for provider-delegates approaches
Advantages Disadvantages
a/ a/
Provider-delegates are targeted in advance. Supervisor-agent becomes a bottleneck.
Less interaction messages between user- Supervisor-agent's recommendations could
delegates and provider-delegates. not satisfy completely user-delegates.
User-delegates have a narrow perception of
the MI content.
b/ b/
User-delegates have a wide perception of More messages to discover what provider-
the MI content. delegates oer.
More freedom is given to user-delegates.
upon the m-services to use, noti cations are sent to dierent recipients. This will
be explained in the noti cation stage.
Noti cation stage purpose is to inform dierent agents about user-delegates'
and provider-delegates' agreements.
Regarding the user-delegate, it is in charge of the following operations: in-
forms the user-agent about the sequence of m-services it has established to satisfy
its user's request (cf. Table 2); and informs the storage-agent about the sequence
of services it will receive from dierent device-agents (cf. Table 3).
Regarding the provider-delegate, it noti es the provider-agent about its
agreements with a user-delegate (cf. Table 4). We recall that provider-agents
do not reject any agreements.
Based on the information it has received from its provider-delegate, the
provider-agent forwards them to the device-agent. This information concerns
the m-services that are involved and the storage-server that is used. Among the
actions the device-agent undertakes we cite submitting the m-services to the
storage-agent of the storage-server.
Realization stage purpose is to execute the sequence of m-services that the
user-delegate has designed. User-agent and storage-agent are the participants
of this stage. We recall that the user-delegate has already informed the storage-
agent about the m-services it will receive from device-agents (cf. Table 3). Before
the user-agent starts asking the storage-agent for the m-services it has, it waits
for a noti cation message from the storage-agent mentioning that the sequence
is ready to be submitted for execution.
In the realization phase, reliability aspect has been taken into account. Our
approach considers a storage-server as a back up server for the m-services. When
a storage-agent sends an m-service to a user-agent, the storage-agent keeps a copy
of this service at its level. It deletes it when the user-agent asks for the m-service
that follows the one it has received. For the last m-service of a sequence, the
user-agent sends an acknowledgement message to the storage-agent so it deletes
that m-service (cf. Figure 3).
User-agent Storage-agent
Interactions
Actions Sequence: m-service1,2,3 Actions
prepare: message
To-make-ready: seq.1
prepare: request
Request: ?m-service
1
save: m-service1
Push: m-service1
run: m-service1
delete: m-service1 Request: ?m-service
2
delete: m-service1
save: m-service2
Push: m-service2
wait: m-service2
Request: ?m-service
2
Push: m-service2
run: m-service2
delete: m-service2 Request: ?m-service
3
delete: m-service2
save: m-service3
Push: m-service3
run: m-service3
delete: m-service3 Request: ok
delete: m-service3
Figure3. Interaction diagram of realization phase
5 Implementation
An implementation of the MI has already been undertaken in [9]. The proto-
type uses SUN's JavaSpaces technology [5] to implement a repository that holds
providers' m-services advertisement. JavaSpaces is an implementation of Linda
[8] that provides a simple, fast, and a uni ed mechanism for sharing, coordinat-
ing, and communicating distributed resources, services, and objects across the
network.
The MI is implemented as a set of three modules. The rst module is the man-
agement and installation, which is responsible for receiving delegates from their
original systems and installing them. All the security operations are undertaken
in this module. The second module is the interaction module that supports the
communications that take place between user-delegates and provider-delegates.
Finally, the third module is the advertisement and consulting module, which
is supported by JavaSpaces, deals with advertising services and identifying the
services that are required for satisfying speci c needs. In addition, the advertise-
ment and consulting module supports the subscription process to user-delegates.
For instance, if a user-delegates is interested in a speci c event, then it can be
noti ed when this event occurs. JavaSpaces provides this noti cation operation.
Provider-agents and their delegates and user-delegates are implemented us-
ing Voyager [14]. Regarding the user-agent, it is mainly an interface-agent that
feeds the user-delegate with requests. This agent is implemented using J2ME [4],
which is a Java edition that runs on wireless handheld devices with constrained
resources. A snapshot of the user-agent prototype is shown in Figure 4.
At this stage of our implementation, we simulate the situation where a user
can enter the m-services he requires. In this example, the user is requesting a
stock m-service that can be used to simulate stock operations. Once the stock
Figure4. User-agent screen mockup
m-service has been downloaded the user will be noti ed, as shown in Figure 4,
so that she can start using it as shown in Figure 5.
Figure5. M-service execution screen mockup
6 Related work
There exist several projects that study how wireless devices could change our
way of doing business [1,10,11,13]. In HP Laboratories, [10] worked on delivering
Internet services to wireless users. This work was conducted under the project
for Pervasive Services Infrastructure (PSI). The vision is "any service to
any client (anytime, anywhere)". The project investigated how o oading parts
of applications to mid-point servers can enable and enhance service execution on
a resource-constrained device. In our work, we are interested in the same issues.
Furthermore, we are interested in supporting users in their search for m-services
in an open environment. In [11] the Odyssey project provides system support
for mobile and adaptive applications. It de nes a platform for adaptive mobile
data access on which dierent applications, such as a web browser, a video
player, and a speech recognition, could run on top. The Odyssey's approach
is to adjust the quality of accessed data to match available resources. In our
system, we considered adaptability at two dierent levels: m-services are wrapped
according to the wireless devices' characteristics; and user-agents request m-
services from storage agents according to the resources that are available on
their users' devices.
Another related project to our work is Ninja [13]. It aimed at suggesting new
types of robust and scalable distributed Internet services. Ninja's objective is to
meet the requirements of an emerging class of extremely heterogeneous devices
that would access these services in a transparent way. In Ninja, the proposed
architecture considered four elements: bases, units, active proxies, and paths.
Comparable to our sequence of m-services, a path is an abstraction through
which units, services, and active proxies are composed. Proxies are transforma-
tional intermediaries put between devices and services to shield them from each
other. Ninja proxies are similar to our device-agents. In addition, Ninja suggested
a Service Discovery Service (SDS) for two reasons: enable services to announce
their presence and enable users and programs to locate these announced services.
Similar to the SDS, the MI has a brokering role. Moreover, the MI facilitates the
direct interactions between providers and users. In fact, the MI avoids bottleneck
situations and ensures a better security.
7 Conclusion
In this paper, we presented our work on m-services. M-services are considered
as an extension to e-services. Users are more and more relying on their wire-
less devices to complete their daily operations. Therefore, new facilities should
be provided. Our work aims at achieving "anywhere and anytime" paradigm.
This paradigm could be summarized by [2] who stated "How to make a set of
heterogeneous services implemented and provided by dierent providers available
for roaming users as an integrated package, with the same "look and feel" across
dierent networks, and from dierent terminals".
Several aspects are still under investigation, among them security [7] and
scalability. Our suggestion for security consists of enhancing the storage-agent
with security mechanisms that could be generic; in the sense that these mech-
anisms will be applied to all m-services despite their origin (i.e. device-agent)
and destination (i.e. user-agent). Speci c security procedures that answer each
user's priorities should be done at the wireless device level. Since the resources
on wireless devices should be used in a rationale way, our future work is based on
trust between user-agents and storage-agents. For instance, if a user-agent had
the opportunity to deal with the same storage-agent several times and based on
its previous experiences, the user-agent could entrust to this storage-agent its
speci c security procedures.
Regarding scalability, the architecture of the m-services system we suggested
in Figure 1 is highly scalable. The system can be extended, at a reasonable cost,
as the demand for the m-services it provides increases. This can be achieved by
adding more meeting infrastructures to a wireless carrier network. The bank of
m-services and the storage-servers can be replicated across the network. This
allows us to avoid the performance bottleneck that would arise if a single MI has
to handle all client requests.
References
1. S. Case, N. Azarmi, M. Thint, and T. Ohtani. Enhancing e-communities with
agent-based systems. IEEE Computer, July 2001.
2. L. Esmahi, R. Impey, and R. Liscano. An architecture for providing mobile inte-
grated services for roaming users. In Proceedings Proceedings of MICON, Ottawa,
2000.
3. M.C. Fauvet, M. Dumas, B. Benatallah, and H. Paik. Peer-to-peer traced execution
of composite services. In Proceedings of the International Workshop on Technologies
for E-Services (TES'2001) held in conjunction with VLDB'2001, Italy, 2001.
4. J2ME. http://java.sun.com/j2me, Visited Nov. 2001.
5. JavaSpaces. http://java.sun.com/products/javaspacesl, Visited Nov. 2001.
6. N. Jennings, K. Sycara, and M. Wooldridge. A roadmap of agent research and
development. Autonomous Agents and Multi-Agent Systems, 1(1), 1998.
7. S. Key Miller. Facing the challenge of wireless security. IEEE Computer, July
2001.
8. Linda. http://www.cs.yale.edu/Linda/linda.html, Visited Nov. 2001.
9. Z. Maamar, E. Dorion, and C. Daigle. Towards virtual marketplaces for e-
commerce. Communications of the ACM, 44(12), December 2001.
10. D. Milojicic, A. Messer, p. Bernadat, I. Greenberg, G. Fu, O. Spinczyk, D. Beuche,
and w. Schroder-Preikschart. - pervasive services infrastructure. Technical re-
port, HP Technical Report HPL-2001-87, HP Laboratories Palo Alto, 2001.
11. B.D. Noble, M. Satyanarayanan, D. Narayanan, J.E. Tilton, J. Flinn, and K.R.
Walker. Agile application-aware adaptation or mobility. In Proceedings of the 16th
ACM Symposium on Operating Systems Principles, France, 1997.
12. B. Pernici and M. Mecella. Designing components for e-services. In Proceedings of
the VLDB Workshop on Technologies for E-Services (VLDB-TES 2000), Egypt,
2000.
13. The Ninja project. http://ninja.cs.berkeley.edu, Visited September 2001.
14. Voyager. http://www.objectspace.com/products/voyager, Visited Nov. 2001.
15. A. I. Wand and L. Chunnian. Process support for mobile work across heteroge-
neous systems. Technical report, Department of Information Science, Norwegian
University of Science and Technology, Norway, 2001.