Mobile Service Development and Deployment with
Remotely Launched Service-oriented Mobile Agents
Hervé Paulino
Departamento de Informática, Faculdade de Ciências e Tecnologia, Universidade Nova de Lisboa
Portugal
Email: [email protected]
Abstract—The execution of the client side of a mobile service
is a task greatly conditioned by the limited resources available to
perform computation and communication. Moving these operations to other computing elements reduces the energy spent by
the device in the actual computing of the final result. This allows
for a more efficient management of the device’s energy, increasing
its autonomy. In this paper, we use put to use the features of the
M OB programming language to efficiently develop mobile device
specific applications, namely the ability to remotely launch mobile
agents, strong mobility and a service-oriented resource discovery
model.
I. I NTRODUCTION AND M OTIVATION
The development and subsequent deployment of the client
side of a mobile service is a task greatly conditioned by the
limited resources available to perform computation and communication. Nonetheless, this kind of devices are increasingly
populating the Internet, and establishing themselves as one of
the main driving forces for the current research on distributed
programming paradigms. The aim of this research is to find
adequate abstractions to program the specificity of these kind
of devices, and of the networks they integrate.
In our point of view, from this research two paradigms that
are particularly interesting have emerged: Mobile Agents and
Service-Oriented Computing.
Mobile agents are computations that have the ability to
travel through a network, by halting their execution, saving
their state, and then restoring it in a new host. Mobile agent
based applications move towards the resources they need and
interact with them locally. This constitutes an alternative to
the remote sessions of the usual communication paradigms
(e.g. client-server), which is a major advantage when in the
presence of devices that communicate through expensive cellular networks. Among the most popular mobile agent platforms
are Aglets [1], Mole [2] and Voyager [3].
Service-oriented computing builds on the concepts of
object-oriented and component-based programming, and the
client-server paradigm. Services are described in a platform
independent way by contracts (service interfaces), which are
negotiated between the components that compose the application. Service providers are accessed much in the way that
objects are in object-oriented languages. Actual communication is based on the client-server paradigm. However, a
component is not tied to a single server and there are no clientserver hierarchies between the components that provide and
require services. Among the most popular systems to develop
service-oriented based systems are the .NET [4], Jini [5] and
Openwings [6] platforms.
In [7] we presented M OB, a language that combines both the
mobile agent and the service-oriented paradigms in a seamless
way. M OB applications are modelled as agents (components)
that provide and require services. These agents feature a
strong mobility model, meaning that the whole application is
moved to the new host, and transparently restarted in the next
instruction.
In this paper, we discuss how the features of the M OB
language can be put to good use in the development and
deployment of applications for mobile devices. The burden
of hosting a dedicated run-time system in order to deploy
mobile agents is a major handicap in the application of mobile
agents to the mobile service field. Systems, such as the ones
presented in [8] and [9], have discussed alternatives based on
remote agents running in the wired network. It is however
not clear how this is managed and how it scales to handle a
large number of services and clients. Here, we propose a model
where the user remotely launches an agent in the network. The
model allows for the advantages of disconnected execution,
provided by the mobile agent paradigm, while eliminating the
need to host the agent’s run-time system. It is our opinion,
that the conjunction of this concept with the mobile agent and
service-oriented paradigms provides a useful contribution to
mobile service development.
The remainder of the paper begins by explaining, in the
next two sections, the advantages of remote launching, and of
combining mobility with a service-oriented resource discovery
model. Section IV presents the essential of the M OB programming language. It is not a contribution of this paper, rather
a summary of the language’s features. Section V presents
an example of how M OB can be used to develop mobile
services. Section VI compares M OB to some of the work in
the area. Finally, in section VII, we present some conclusions
and guidelines for the future.
II. S TRONG M OBILITY AND R EMOTE L AUNCHING
By definition, a mobile agent is a program that has the
ability to carry its state from host to host. This is a particularly
interesting model when the underlying architecture is a mobile
device with energy restrictions. By moving communication
and computation to other computing elements, we are in fact
reducing the energy required by the device in the overall
computation of the result. The migration also eliminates issues such as service hand-offs, loss of connectivity and low
bandwidth. Moreover, it reduces connection time, which must
usually be paid.
Thus, once an agent is launched into the network the
communication link may be disconnected (figure 1 (a)). The
agent will then pursuit its journey visiting the sites hosting
the resources it requires (figure 1 (b)). Further communication
with the mobile device is only needed to check if the agent
has completed its journey, and to retrieve the results, if any
(figure 1 (c)).
agent
agent
Disconnected
(a)
fact, a protocol that tags the message as an agent and ensures
the reliability of the transfer is used.
III. C OMBINING M OBILITY AND S ERVICE - ORIENTED
R ESOURCE D ISCOVERY
It is our belief that combining mobile agents with a serviceoriented resource discovery model in a programming language provides a useful tool for high-level programming of
applications for distributed environments, and in particular
for mobile services. Agents are modelled as providing and
requiring services provided by other agents.
Common mobile agent development APIs require programs
to know the location of the resources, be it coded at compiletime or at run-time. With such APIs, the operational flow of
a program that wants to access services S1 to Sn located,
respectively, at hosts h1 to hn is:
(b)
move to host h1 and interact with service S1
move to host h2 and interact with service S2
...
move to host hn and interact with service Sn
agent
(c)
Figure 1.
Disconnected execution
In terms of program development, mobile agents are also
interesting since they almost entirely abstract the use of
the network. In theory, network-awareness is limited to the
migration primitive. However, the truth is that most languages
impose access restrictions to the computation’s run-time state
(e.g. Java), and without this knowledge only a weaker form of
mobility can be achieved. This mobility model, known as weak
mobility, simply moves the agent’s data and code, burdening
the programmer with the need of implementing receiver code,
to define the agent’s behavior on arrival.
M OB features the strong mobility of multi-threaded agents,
while running on top of an untampered Java Virtual Machine
(JVM). As will be clear in section IV-B, migrating a M OB
agent is to move its run-time system to the target host. This
requires a layer of services (M OB-hosts) that handle agent
mobility and execution. This layer also provides a mechanism
to launch new agent run-time systems, given the agent’s code.
Thus, as illustrated in figure 2, a device willing to spawn a
new agent to the network simply needs to access this layer,
and send it the code of the agent to execute.
User’s
device
New
agent
Code of
the agent
Mob host
Figure 2.
Mob host
Remote launching
We denote this concept as remote launching. The user’s
device only needs to host a thin client to parse the agent’s code
and send it across the network to the desired M OB-host. In
A resilient agent requires code to overcome the possible absence of each host, and search for alternatives. The inclusion of
service-orientation removes this burden from the programmer.
The movement of the agent towards the resources is modelled
in terms of services, rather than hosts:
find an instance of service S1 and interact with it
find an instance of service S2 and interact with it
...
find an instance of service Sn and interact with it
which leaves the handling of alternatives to the resource
discovery mechanism.
IV. M OB IN A N UTSHELL
In this section, we give a general overview of the main constructs, compiler and run-time system of the M OB programming language. Once more, this section is not a contribution
of this article, but rather a summary of the work presented in
[7]. A even more in-depth description of M OB may be found
in [10].
A. The Language
We begin with a light overview of the language’s main
constructs. M OB is thus a service-oriented mobile agent programming language, whose main abstractions are agents and
services. Agents are objects with an associated run-time that
may provide services to other agents and, simultaneously,
require services provided by other agents.
A M OB network (figure 3) is composed of a set of agents
running in the boundary of hosts (M OB-hosts) and a name
service that keeps the whereabouts of the agents and the
information about the services they provide.
Following an object-oriented approach, agents are abstracted
in classes defined by the agent construct, while instances are
created with the new construct. These begin their execution
network
agents
name
service
agent
host
host
agents
agent
host
host
Figure 3.
A M OB network.
in the same host as their father (figure 4 (b)). A program is
launched in the network by encapsulating its code in an agent
placed in a host specified by the user (figure 4 (a)). This allows
for the remote launching mechanism described in section II.
Note that these agents are stationary [10].
Definitions for common objects are given by the class construct, and instances are created also with the new construct.
new
agent
user
new
agent
agent
(a)
(b)
Figure 4.
Launching new agents.
The initial behavior of an agent is defined by its main
method. However, M OB agents were designed as daemons
and their execution must be explicitly terminated by the
exit instruction. This means that the agent’s execution does
not terminate with the conclusion of the main method. A
simple service provider, with no initial behavior, may omit
the method’s definition.
As service providers, agents must be able to handle multiple
incoming requests. To cope with this demand M OB agents
are multi-threaded. Threads can be explicitly created by an
agent, through the fork instruction, or implicitly created,
e.g. in a remote method invocation. Synchronization with the
parent thread can be achieved with the join method. Sets of
synchronized methods can also be defined, and used along
with the wait/notify instructions with usual semantics [11].
Before migration
During migration
go(h’); P
host h
host h
host h’
a primitive go (similar to the one found in Telescript [12]).
Since a strong migration model is used, the movement of an
agent involves moving its code, data and execution state to
the target host. On arrival the execution resumes transparently
at the exact point where it was interrupted (P in figure 5).
An agent always carries the closure for its code, thus enabling
disconnected autonomous execution.
The interface for services is defined by the service construct. The interface is the contract for the service, the base
for all service-oriented programming in M OB. By providing
and requiring services, agents become the components of a
service-oriented architecture.
name
service
agent b
(3) binding
Figure 6.
(1) request: implementation of service S
(2) reply: agent b
x = bind(S)
agent a
Binding to agents.
To access a service, an agent must get a binding for an agent
that provides that service (figure 6). The binding is obtained
dynamically through the primitive bind that asks the name
service for an agent that provides the required service (step 1).
The name service returns a binding for a running agent that
provides the service (step 2). Once the binding is obtained,
interaction through method invocation can happen (much like
Java RMI) (step 3).
Method invocation in objects can only be done from within
the agent that owns them. All objects are encapsulated within
agents and thus, invoking a method in an object located in
the address space of some other agent is not possible, unless
the target agent’s interface provides some means to access the
object. Methods of the agent itself can of course be invoked
both from within the agent, and from other remote agents.
This is after all how services are provided.
A method invocation in a remote agent always spawns a new
thread (at the remote agent) that executes the corresponding
code. The calling thread suspends until the result is available.
All remote method calls are made by value, except for agents.
Using call by value on agents would, in practice, define
another form of agent migration.
host h’
B. The Compiler and Run-time System
After Migration
P
host h
Figure 5.
host h’
Migrating agents.
M OB delegates agent migration in the programmer using
The compiler generates code written in an intermediate language called MIL (Multi-threaded Intermediate Language [13]), which is compiled just-in-time by the run-time
system before being executed.
Checking that the interface of a service is correctly implemented is, by default, done at compile time. The compiler
infers the type of the service and matches it with the one
registered in the network. If the agent implements a service
yet not registered, the interface provided becomes the de
facto interface for that service. This type-checking operation
requires a connection to the network name service. To enable
disconnected compilation is it possible to postpone the operation to the beginning of the execution.
The run-time system is divided into two layers. The top
layer is the host layer mentioned in section II and is implemented as a service that must run on every M OB-enabled host
in a network. This layer is responsible for managing agents
within a host and supporting their mobility.
The second layer is the agent layer that performs the actual
execution of the agents. It is based on the MIL virtual machine
[14], which executes on top of the JVM. This approach enables
us to keep the platform independence provided by the JVM,
whilst having the ability to move computations, by having
complete control over the agent’s run-time state.
V. M OBILE S ERVICE D EVELOPMENT WITH M OB
In this section, we discuss the use of M OB in the mobile
service context. We have chosen a simple ticket selling service,
to illustrate the programming of both endpoints of the clientserver interaction.
We begin by implementing, in listing 1, the service provider.
Throughout this example we assume the existence of a number
of network services of which we do not provide an implementation. These are: (1) TicketServiceDirectory, that provides
a directory service to discovery which events have tickets for
sale (method listEvents), and which are the providers that
hold those tickets (method ticketsFor); (2) SMSService, that
provides a SMS messaging service (method send), and; (3)
PaymentService, that provides a payment facility, ensuring
the proper payment of a service (method pay).
Service TicketService (lines 1 and 2) defines the interface
of the ticket selling service, while agent TicketAgent (lines 19
to 46) provides an implementation. The methods defined by
TicketService are: listEvents (implemented in line 23), to list
all the events for which the service has tickets1 ; reserve (lines
25 to 27), to reserve a ticket for a pre-determined amount of
time; confirm (lines 29 to 38), to confirm the purchase of a
previously reserved ticket; purchase (lines 40 to 43), to allow
for the conjunction of the reserve and confirm operations in a
single step, and, finally; getHost (line 45), to obtain the host
where the service is running.
In this implementation, the agent also features a user-defined
attribute (ticketAccount) to define the provider’s account
information, and a private attribute (events) to hold the events
for which tickets are available. The later is a map, indexed by
the name of the event, that contains elements of type Event
(lines 10 to 17). These gather all the information related to a
given event, and all the actions that can be performed upon
it. For instance, reserve (line 11) returns an element of type
Reservation (lines 3 to 8) with the reservation’s information,
including the one required to perform the payment.
On the client side, we use remote launching. We do not
embed the client in some application running in the device.
1 An hierarchical approach can be followed by grouping the events into
topics.
As stated before, this eliminates the need for a M OB-enabled
device. In our approach, we decouple the search from the
interface provided by the device to the user. The later defines
its preferences regarding the event and the ticket to search and,
once it terminates, the M OB program to initiate the search is
launched.
Listing 1.
An implementation of service TicketService
1 service T i c k e t S e r v i c e { l i s t E v e n t s , reserve , c o n f i r m ,
2
purchase , getHost }
3 class R e s e r v a t i o n ( number ,
4 getNumber ( ) { . . . }
5 getEvent ( ) { . . . }
6 getPaymentInfo ( ) { . . . }
7 ...
8 }
event , paymentInfo , . . . ) {
/ / The number of the reservation
/ / The associated event
/ / Info required to perform the payment
10 class Event ( ) {
11 r e s e r v e ( p r e f e r e n c e s ) { . . . }
12 c o n f i r m ( r e s e r v a t i o n ) { . . . }
13 withdraw ( r e s e r v a t i o n ) { . . . }
14 i s S o l d O u t ( ) { . . . }
15 a v a i l a b l e ( ) { . . . }
16 . . .
17 }
//
//
//
//
//
Perform a reservation
Confirm the reservation
Withdraw the reservation
Is the event sold out?
Tickets available
19 agent T i c k e t A g e n t ( t i c k e t A c c o u n t ) provides T i c k e t S e r v i c e
20
requires PaymentService {
21 events = {}; / / An initially empty map to hold the events for which
/ / tickets are available
23 l i s t E v e n t s ( ) { r e t u r n events ; }
25
26
27
r e s e r v e ( event , p r e f e r e n c e s ) {
r e t u r n events [ event ] . r e s e r v e ( p r e f e r e n c e s ) ;
}
29
30
31
32
33
34
35
36
37
38
confirm ( reservation ) {
payment = bind ( PaymentService ) ;
i f ( payment . pay ( r e s e r v a t i o n . getPaymentInfo ( ) ,
ticketAccount ) )
return r e s e r v a t i o n . confirm ( ) ;
else {
r e s e r v a t i o n . withdraw ( ) ;
return null ;
}
}
40
41
42
43
purchase ( event , p r e f e r e n c e s ) {
r e s e r v a t i o n = r e s e r v e ( event , p r e f e r e n c e s ) ;
return confirm ( r e s e r v a t i o n ) ;
}
45 getHost ( ) { r e t u r n host ( ) ; }
46 }
This program (listing 2) begins by binding to a implementation of service TicketServiceDirectory (lines 21 and 22), and
by launching the agent, instance of TicketReserver, that will
perform the search. Remember that programs are stationary.
Agent TicketReserver features attributes ticketHolders,
the list of agents with tickets for the event; event, the name
of the event; preferences, the user’s preferences; home, the
host to where the agent must migrate once the search is over,
and; phone, the telephone number used to notify the user that
search has terminated. This operation is done by the means
of a SMS message. For that purpose, the agent must require
service SMSService.
Regarding the implementation (lines 4 to 19), the agent
visits each element in ticketHolders, migrating to their location, and trying to reserve a ticket constrained by the user’s
preferences. Once a ticket is found, or all the providers in the
list have been visited, a SMS message with the result is sent
to the user’s telephone (lines 16 or 17) number and the agent
returns home (line 18). Many ways may be used to deliver
the reservation’s information to the user. Here, for the sake of
simplicity, we chose to concatenate it at the end of the SMS
message (line 16).
Listing 2.
1
2
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
The client: first approach
agent T i c k e t R e s e r v e r ( t i c k e t H o l d e r s , event , p r e f e r e n c e s ,
home , phone ) requires SMSService {
main ( ) {
done = f a l s e ;
res = null ;
for ( t i c k e t S e r v i c e in t i c k e t H o l d e r s ) {
go ( t i c k e t S e r v i c e . getHost ( ) ) ;
res = t i c k e t S e r v i c e . reserve ( preferences ) ;
i f ( res != null ) {
done == t r u e ;
break ;
}
}
sms = bind ( SMSService ) ;
i f ( done ) sms . send ( phone , ” T i c k e t found : ” ˆ r e s ) ;
else sms . send ( phone , ” No t i c k e t a v a i l a b l e ” ) ;
go ( home ) ;
}
}
requires T i c k e t S e r v i c e D i r e c t o r y
t d i r e c t o r y = bind ( T i c k e t S e r v i c e D i r e c t o r y ) ;
new T i c k e t R e s e r v e r ( t d i r e c t o r y . t i c k e t s F o r ( $1 ) , $1 , $2 ,
host ( ) , $3 ) ;
The creation of the agent in line 23 uses the arguments
passed to the program, in this particular case, by the interface
application. $i denotes the ith argument: $1 is the name of
the event, $2, the preferences regarding the ticket, and $3, the
user’s telephone number.
Note that, the value assigned to the home attribute of
TicketReserver is the result of the host command that
returns the name of the current host. This means that, when
it terminates, the agent returns to the host from which it was
launched.
VI. R ELATED W ORK
In [8] the authors propose an agent-based mobile services
framework. The agents act as gateways to the mobile services,
handling all the communication. The agent is created by
service provider, which means that in order to access multiple
providers, the device must communicate with distinct agents,
thus disrupting disconnected execution. In our model, a single
agent may interact with multiple providers, of the same or
distinct services.
In [9] the authors propose a system based on mobile agents
that uses the CC/PP standard [15] to retrieve of information
about the user’s mobile device, and to use it in the customization of the access to mobile services. The use of mobile
agents is also done to handle a single request submission.
Furthermore, user’s must register themselves in the system in
order to have access to a pre-determined set of services. Our
approach in more broad. Access to services depend only of
the software installed in the device.
VII. C ONCLUSIONS AND F UTURE W ORK
In this paper, we discussed how the features of the M OB
language can be used in the development and deployment
of mobile services. Regarding the development, we argued
that the use of strong mobility along with a service-oriented
resource discovery model provides a simple and expressive
programming tool, reducing network-awareness to the migration primitive.
When it comes to the deployment, we explained the advantages of the use of mobile agents in the mobile device
setting, and introduced the concept of remote launching, that
allows for the use of the language’s capabilities without the
burden of its run-time. The only requirement is some kind of
communication protocol to be able to send the agent to the
network, and to read its results. Although, these can be easily
sent by SMS or Email. We also emphasized the fact that strong
mobility in M OB does not disrupt portability, since the M OB
run-time runs on top of an unmodified JVM.
Although we think that M OB provides a good framework for
the development of distributed applications, and in particular,
mobile services, it lacks the support of the large amount of
APIs available for languages such as Java and C#. Current
work focuses on the application of the M OB programming
model to a mainstream language, such as Java. For that
purpose, mechanisms to migrate a JVM are currently under
study.
R EFERENCES
[1] D. B. Lange and M. Oshima, Programming and Deploying Java Mobile
Agents with Aglets. Addison-Wesley, 1998.
[2] M. Straber, J. Baumann, and F. Hohl, “Mole - A Java Based Mobile
Agent System,” in Special Issues in Object Oriented Programming,
M. M., Ed., 1997, pp. 301–308.
[3] G. Glass, “Overview of Voyager: ObjectSpace’s Product Family for
State-of-the-art Distributed Computing,” CTO ObjectSpace, Tech. Rep.,
1999.
[4] D. Platt, Introducing Microsoft .NET, 3rd Edition. Microsoft Press,
2003.
[5] J. Waldo, “The Jini Architecture for Network-Centric Computing.”
Commun. ACM, vol. 42, no. 7, pp. 76–82, 1999.
[6] Openwings, “Openwings: A Service-Oriented Component Architecture
for Self-Forming, Self-Healing, Network-Centric Systems (Rev 2.0),”
2001.
[7] H. Paulino and L. Lopes, “A Mobile Agent Service-Oriented Scripting
Language Encoded on a Process Calculus,” in Proceedings of the Joint
Modular Languages Conference 2006 (JMLC 2006). Springer-Verlag,
2006, pp. 383–402.
[8] M. Adacal and A. B. Benner, “Mobile web services: A new agent-based
framework,” IEEE Internet Computing, vol. 10, no. 3, pp. 58–65, 2006.
[9] Q. Mahmoud and Z. Wang, “Customizing and delivering mobile services
using software agents and cc/pp,” in IEEE Consumer Communications
and Networking Conference (CCNC 2006). IEEE Computer Society,
2006, pp. 1114–1118.
[10] H. Paulino, “An Infrastructure for Mobile Service-Oriented Computing
Encoded on a Process Calculus,” Ph.D. dissertation, Universidade de
Nova de Lisboa, 2006.
[11] J. Gosling, B. Joy, G. Steele, and G. Bracha, The Java(TM) Language
Specification (3rd Edition). Addison-Wesley Professional, 2005.
[12] J. E. White, Telescript Technology: Scenes from the Electronic Marketplace., General Magic White Paper, 1995.
[13] V. T. Vasconcelos and F. Martins, “A multithreaded typed assembly
language,” in Proceedings of TV06 - Multithreading in Hardware and
Software: Formal Approaches to Design and Verification, 2006.
[14] H. Paulino, P. Marques, L. Lopes, V. Vasconcelos, and F. Silva, “A
Multi-Threaded Asynchronous Language,” in 7th International Conference on Parallel Computing Technologies (PaCT’03), ser. Lecture Notes
in Computer Science, vol. 2763. Springer-Verlag, 2003, pp. 316–323.
[15] W3C CC/PP Information Page, http://www.w3.org/Mobile/CCPP/.