Anda di halaman 1dari 19

The current issue and full text archive of this journal is available at


A mobile application based on software agents and mobile web services

Zakaria Maamar
Software Agents Research Group@ZU, College of Information Systems, Zayed University, Dubai, UAE
Purpose The aim of the research is to discuss the design and development of a mobile application using two technologies known as software agent (SA) and mobile web services. Design/methodology/approach The objectives were achieved by testing the integration of SAs and mobile web services into mobile applications. The approach suggested in the paper has relied on some modeling techniques such as service chart diagram and addressed some security issues. Findings It was found in the course of the work the necessity of being aware of the limitations of mobile devices, despite all the major developments that are happening. In addition, it was found that it is deemed appropriate to provide some modeling techniques which suit the development of mobile applications. Originality/value The paper discusses the concept of mobile web services. The paper is particularly useful to those who are in the eld of mobile computing. Keywords Mobile communication systems, Computer software, Internet Paper type Research paper

Software agents and mobile web services 311

1. Introduction The advent of the world wide web has changed the way of doing business. Consumers have more opportunities to be aware of the current-market trend before making any purchasing decisions. In addition, there is no need to go to the next library to purchase her favorite magazine. There are several web sites that allow users to submit online orders of products. E-business denotes commonly the business transactions that are carried out over the web. E-business places new challenges not only on support and delivery information technology, but also, on the way business processes have to be developed, deployed, and maintained. With the widespread of the web technology, an increasing number of businesses have decided to deploy web services over the internet (Tsalgatidou and Pilioura, 2002). The advantages of web services have already been demonstrated in multiple projects and highlight their capacity to be composed into high-level business processes (or composite services). For example, a summer holiday composite service requires the collaboration of at least four web services: ight reservation, hotel booking, attraction searching, and user notication. These web services are connected according to a certain ow of control. Flight reservation is rst completed, before both hotel booking
The author would like to thank the referees for their valuable comments and suggestions of improvements. The author also acknowledges the contributions of the following people to SAMOS: Q. H. Mahmoud (Guelph University, Canada), W. Mansoor (Zayed University, UAE), and H. Yahyaoui (Laval University, Canada).
Business Process Management Journal Vol. 12 No. 3, 2006 pp. 311-329 q Emerald Group Publishing Limited 1463-7154 DOI 10.1108/14637150610667980

BPMJ 12,3


and attraction searching are concurrently initiated. Multiple technologies back the success of web services such as Web Services Description Language (WSDL), Universal Description, Discovery and Integration (UDDI), and Simple Object Access Protocol (SOAP) (Curbera et al., 2003). These technologies, respectively, aim at dening, advertising, and binding web services. Besides the web expansion, we witness the progress happening in the eld of wireless technologies. Telecom companies are offering new services and opportunities to customers over mobile devices. Reading emails and sending messages between cell-phones are becoming natural. Surng the web thanks to the Wireless Application Protocol (WAP) is also an evidence of the wireless technology development. The next stage (if we are not already in it) for telecom companies and businesses is to allow users to enact web services from their mobile devices and possibly, to make these web services runnable on these devices. M-services (M for mobile) denote this new type of web services. It is believed that one of the most powerful developments of the new millennium is the increased demand for internet access anytime, anywhere, and for anyone. Indeed, throughput, connectivity, and bandwidth of wireless networks are in constant improvement (Chisalita and Shahmehri, 2001). Several indicators show that the main use of mobile communications is changing. Larger displays, third generation networks (e.g. GPRS: General Packet Radio Service, UMTS: Universal Mobile Telecommunication System), and recent development of communication protocols, are being combined to give a rich user experience of data-centric services. It occurs that mobile users have to postpone their operations because they lack appropriate facilities running on their mobile device (e.g. an application that converts a drawing le into a format that the users device can display). In Software Agents for Mobile Services (SAMOS) project we aim at supporting such users by allowing them to: . search for additional facilities, when needed; . fetch these facilities to their mobile devices; and . conduct these two operations in a transparent way. Various solutions are put forward to handle these points. A solution to point: . consists of devising brokering mechanisms; . consists of using wireless communication channels; and . consists of using software agents (SAs) to make searching for and fetching the facilities transparent to users (Jennings et al., 1998). In this paper, the design of a mobile application based on SAs and M-services is discussed. Section 2 motivates our work on M-services. Section 3 denes web services vs M-services. Section 4 presents SAMOS in terms of architecture, operation, and types of agents. Section 5 discusses M-services composition using service chart diagrams. Section 6 presents the security approach that is adopted for M-services in SAMOS. Section 7 overviews projects related to SAMOS. Finally, Section 8 draws our conclusions.

2. Motivation Besides the new role of the internet as a vehicle of provisioning web services, it is eagerly expected that more web services will be delivered to people who use mobile devices and particularly to those who are most of the time on the move (e.g. sales representatives). It is, also, seen that mobile devices are being enhanced with new advanced computing resources (Ericom, 2001; Elsen et al., 2001) (since 2001 Java-enabled phones are available on the market). Unfortunately, the growth in the development and use of mobile devices is subject to different challenges. For instance, mobile devices are strictly bound to their batteries for operation, which leads to limit their computation performance. There exist several types of mobile devices, varying from cell-phones to personal digital assistants. These devices present several shortcomings that make their use requires specic arrangements. Among these arrangements, services have to be individually tailored to each mobile device. Unfortunately, this contradicts the platform independence principle of designing web services (Benatallah et al., 2003). Therefore, leveraging web services into M-services becomes a necessity. M-services will have to consider the features of the mobile devices on which they will be running. 3. Web services vs M-services Independently of its type (web or mobile), a service is a set of operations to perform according to a certain set of inputs and a certain chronology. Potential users have to know how to trigger a service for execution. However, users do not have to know neither how to operate the service nor how the service operates or is operated. A web service is an accessible application that can be automatically discovered and invoked by other applications and humans as well. An application is a web service if it is (Benatallah et al., 2003): . independent as much as possible from specic platforms and computing paradigms; . developed mainly for inter-organizational situations rather than for intra-organizational situations; and . easily composable (i.e. its composition with other web services does not require the development of complex adapters). Two denitions are associated with an M-service (Maamar et al., 2003a). The weak denition is to remotely trigger a web service for execution from a mobile device. In that case, the web service acts as an M-service. The strong denition is to transfer a web service from its hosting site to a mobile device where its execution occurs. In that case, the web service acts as an M-service that is: . transportable through wireless networks; . composable with other M-services; . adaptable with regard to the computing features[1] of mobile devices; and . runnable on mobile devices. In SAMOS, we only consider the M-services that comply with the strong denition. The M-services that comply with the weak denition are considered in Maamar et al. (2003b). Indeed, the operation of this kind of M-services is WAP-based, i.e. users submitting requests from mobile devices using WAP as a communication middleware.

Software agents and mobile web services 313

BPMJ 12,3


The differences between a web service and an M-service are depicted at two levels. We denote these two levels by communication medium and computation location: (1) At the communication medium level, web services are connected with wired channels to the external environment. Whereas M-services are connected with wireless channels to the external environment. This denitely calls for different communication protocols. (2) At the computation location level, web services are executed in the server side. Whereas M-services are executed in the client side after being transferred from the server side. 4. SAMOS environment In the rest of this paper, the term composite service denotes a list of component M-services. Plus, the terms M-service and service are used in an interchangeable way. 4.1 Architecture of SAMOS Brokering mechanisms and SAs are put forward as potential candidates in the design and development of a system offering services to users of mobile devices. In a nutshell, the salient features of the architecture of SAMOS are: . Use three types of SAs: user-agent, provider-agent, and device-agent. . Deploy a meeting infrastructure (MI) to be headed by a supervisor-agent (Maamar et al., 2001). The MI mainly supports the interactions of type brokering that occur between user-agents and provider-agents. . Use two types of delegates: user-delegate and provider-delegate. They are installed in the MI, acting, respectively, on behalf of user-agents and provider-agents. Delegates are similar to agents but are given a different name for simplicity reason. . Use storage servers in order to save the composite services that will be transferred to mobile devices for execution. These servers are spread across the network and storage-agents are responsible for their management. Figure 1 shows the architecture of SAMOS. It consists of 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. To keep the paper self-contained, certain aspects of the architecture of SAMOS are not detailed. The user part consists of users and user-agents. User-agents accept needs of users, convert them into requests, and submit the requests obtained to user-delegates. On a request basis from user-agents, the supervisor-agent of the MI creates user-delegates that interact with provider-delegates. In the context of summer holiday scenario, examples of users needs could be date of travel and date of return, city of destination, and type of accommodation. In SAMOS, users are offered interfaces ready to be used. Figure 2 shows a snapshot of a mobile service running on a cell-phone. The service provides information to tourists visiting a city for instance Dubai. Upon request of tourists, the service is downloaded into their mobile devices. The provider-part consists of providers, provider-agents, and device-agents. Provider-agents act on behalf of providers of M-services. Through provider-delegates,

Storage-agent1 Wireless connection Wired connection Storage server1 M-services Requests User User-agent User delegate Wireless Interactions Notification Supervisor agent Provider delegate Interactions Provider Bank of m-services Storage serverj M-services Provider-agent Device-agent

Software agents and mobile web services 315

Interactions Meeting infrastructure

Storage serveri

Figure 1. Architecture of SAMOS

Figure 2. Snapshot of tourist mobile-book

BPMJ 12,3


provider-agents advertise their M-services to user-delegates. In addition, provider-agents monitor the behavior of providers when for instance M-services are being released and thus need to be announced to user-delegates. In Figure 1, M-services are gathered into a bank on top of which provider-agents and device-agents are located. Provider-agents create provider-delegates and transfer them to the MI. With regard to device-agents, they support the work of provider-agents. The role of device-agents is to wrap the M-services before they are sent to mobile devices for execution. Wrapping the services is due to the differences that feature mobile devices at different levels such as screen size, processor speed, and storage capacity. The MI part is a software platform on top of which user-delegates and provider-delegates reside and interact in a local and secure environment. In an open environment, initial interactions between consumers of services and providers of services are conducted through third parties, known commonly as brokers. Despite its important role, a broker can easily become a bottleneck. To overcome this problem, consumers and providers have to bypass the broker. In fact, they need a common environment in which they meet and interact face to face. The MI is that environment and constitutes a new approach for setting up brokering mechanisms (Maamar et al., 2001). Instead of introducing brokers between users and providers, it is more appropriate if users and providers can meet in a common and secure place and thus, have direct interactions. The MI approach has already shown its advantages in the research that was conducted in Elkadhi et al. (2001). In this research, different interoperability environments based on the three architectures namely broker, matchmaker, and MI were compared. Three criteria were used for comparing these environments: number of messages exchanged, risk of intercepting the messages exchanged, and safety of the messages exchanged. The comparison has shown that the MI has a great potential to support brokering in distributed systems (Elkadhi et al., 2001). For illustration purposes, we provide some examples on the types of interaction that occur in the MI. If this is the rst time that a user-agent submits a users request, the supervisor-agent creates a user-delegate in the MI to be associated with this user-agent (Table I). For the forthcoming requests, the user-agent interacts directly with the user-delegate (Table II). Table I and II use submit reply and notify performatives that represent some of the interactions between user-agents and supervisor-agent and between user-agents and delegate-agents as well. In Table I, submit performative has

Submit Table I. Interactions user-agent/ supervisor-agent Reply

(Id-submit: id1, from: user-agent1, to: supervisor-agent1, content: request1, device: (brand: brand1, type: type1, screen size: size1)) (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@. . .))

Table II. Interactions user-agent/user-delegate

Submit Notify

(Id-submit: id2, from: user-agent1, to: user-delegate1, content: request2, device: ()) (Id-notify: id1, from: user-delegate1, to: user-agent1 (in-reply-to: id2), content: sequence1/M-service1,2)

ve elds among them device which species the characteristics of the mobile device of the user. The device-agent needs these characteristics in its process of wrapping the M-services. In Table II, submit performative occurs once a user-agent knows the delegate-agent to which it has been associated. The storage part receives the composite services that will be submitted for execution on mobile devices. According to the execution principles of SAMOS and the capabilities of mobile devices as well, M-services are sent to mobile devices one by one (this number can be adjusted based on the computing resources of each mobile device). Several advantages are obtained from the use of storage-servers. First, mobile devices have a limited storage capacity. Second, a user-agent does not have to deal with several providers from which it requests M-services for execution. Its unique point of contact for requesting the M-services is the storage-agent. The same thing applies to device-agents that will be interacting with few storage-agents instead of interacting with several user-agents. Third, security is increased for both users and providers. Storage-servers are independent platforms where security control can be conducted in a safe way. 4.2 SAMOS agents In Figure 1, ve types of agents and two types of delegates are introduced. We recall that delegates are in fact agents, but are differently named for the sake of simplicity. To keep the paper self-contained, the description is limited to certain agents of SAMOS. A user-agent resides in a mobile device. First, the user communicates with his user-agent to arrange requests (Figure 2). After submitting these requests to the user-delegate, the user-agent enters a standby state waiting for notications from its user-delegate. Notications concern the component M-services that satisfy the users requests. Before executing them on the users mobile device, the M-services are put in a storage server. The supervisor-agent of the MI suggests to the user-delegate the storage server to use based on the servers location, for example. To download the M-services one at a time from the storage server to the users mobile 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 a service is received, the service successfully completed is deleted from the mobile device. Finally, the user-agent informs the user about the completion of the requests. If this is the rst time that a user-agent submits requests, the supervisor-agent creates a user-delegate in the MI and assigns it to the user-agent (Table I). For the coming requests, the user-agent directly interacts with the user-delegate (Table II). A provider-agent resides in a provider site, running on top of the resources of this provider. Some of these resources correspond to M-services. Provider-delegates broadcast information on M-services to user-delegates. The provider-agent is in constant interactions with its provider-delegate. Indeed: (1) it communicates to the provider-delegate the negotiation strategy it has to follow with user-delegates; (2) it informs the provider-delegate about the changes of the M-services that were previously announced; (3) it informs the provider-delegate about the new M-services that are going to be offered; and

Software agents and mobile web services 317

BPMJ 12,3

(4) it checks the agreements the delegate-provider has made with user-delegates (it is presumed in SAMOS that agreements are not rejected). The provider-agent forwards the agreements about the use of M-services to its device-agent for action, which is submitting M-services to a storage-agent. A device-agent resides in a provider site. The responsibility of the device-agent is to wrap the M-services according to the features of the mobile devices on which these M-services will be performed. Initially, the M-services are sent to storage servers. The provider-agent has already submitted the contact details on the storage server to the device agent. We recall that the user-delegate has also informed the storage-agent of this storage server about the M-services it will receive. Double-checking the information that user-delegates and provider-delegates submit to storage-agents guarantees a better security to the components of SAMOS. A storage-agent runs on top of a storage server. The purpose of this server is to save the M-services that will be sent to mobile devices for performance. According to the list of M-services it receives from the user-delegate, the storage-agent arranges the composite service as the M-services start arriving from providers. As soon as this composite service is completed, it noties the user-agent in order to get it ready to the reception of M-services. Based on the requests it receives from the user-agent, the storage-agent submits the M-services one at a time (Table III). These M-services are ready for execution. The deletion of M-services from the storage servers as well as from mobile devices follows certain reliability rules. These rules ensure that the M-services to be sent to a mobile device for execution are successfully received and executed. 4.3 SAMOS operation Five stages describe the operation of SAMOS (Figure 3): agentication, identication, correspondence, notication, and realization. The purpose of the agentication stage is to set-up the different infrastructures and agents that constitute SAMOS. User-agents are established at the user level. Provider-agents and device-agents are established at the provider level. Last but not least, the MI and storage servers, including their storage-agent, are deployed. In Figure 3, operations (1.a) and (1.b) illustrate the agentication stage. The purpose of the identication stage is to inform the supervisor-agent of the MI about the existence of users and providers who are interested in the use of SAMOS. At the agentication stage, user-agents and provider-agents are, respectively, installed on top of mobile devices of users and resources of providers. The outcome of the identication stage is the creation of user-delegates and the reception of provider-delegates arriving from provider-sites. Creation and reception operations occur in the MI. Provider-agents inform the supervisor-agent about their readiness to


Request Table III. Interactions user-agent/storage-agent Push

(Id-request: id24, from: user-agent1, to: storage-agent1, sequence: sequence1, M-service: ?M-service1) (Id-push: id1, from: storage-agent1, to: user-agent1 (in-reply-to: id24), already submitted: 3, remained: 2, attachment: M-service1)

Meeting infrastructure User User-agent Supervisor-agent n tio rea 3. Interactions 1.b Creation User-delegate 4.a M-services notifcation Provider-delegate Provider delegate 4.b Contracts notifcation 5. Contracts notification 6. M-services transfer Provider-agent

e .a N



Software agents and mobile web services

2.b Migration


7. M-services transfer for execution

Storage-agent1 Storage server1

Device-agent Provider Bank of m-services

Figure 3. Operation of SAMOS

submit their provider-delegate to the MI. User-agents inform the supervisor-agent about the requests of users. In Figure 3, operations (2.a) and (2.b) illustrate the identication stage. The purpose of the correspondence stage is to enable user-delegates and provider-delegates to get together. In Figure 3, operation (3) illustrates the correspondence stage. User-delegates have requests to satisfy and provider-delegates have services to offer. First, the user-delegate searches for the provider-delegates that have the services it needs. Two approaches are proposed: (1) The user-delegate asks the supervisor-agent to suggest a list of provider-delegates that have the services it needs. (2) The user-delegate requests from the supervisor-agent the contact details of all the provider-delegates that are deployed in the MI. Table IV lists the advantages and disadvantages of both approaches. Independently of the approach of searching for delegate-providers, the user-delegate submits its needs of
Advantages Provider-delegates are targeted in advance Less interaction messages between user-delegates and provider-delegates User-delegates have a wide perception of the MI content More freedom is given to user-delegates Disadvantages Supervisor-agent becomes a bottleneck. Supervisor-agents recommendations might not completely satisfy user-delegates User-delegates have a narrow perception of the MI content More messages needed to discover the offers of provider-delegates

Table IV. Approaches of searching for provider-delegates

BPMJ 12,3


services to provider-delegates selected after interactions. Based on different parameters, such as workload and commitments, provider-delegates answer the user-delegate. At this time of our work on SAMOS, providers do not have services in common. Consequently, there is no need for a user-delegate to look for the best service. Once the user-delegate and provider-delegates agree upon the M-services to use, notications are sent to multiple recipients as it is going to be discussed in the next stage. The purpose of the notication stage is to inform the different agents about the agreements occurring between user-delegates and provider-delegates. In Figure 3, operations (4.a), (4.b), (5), and (6) implement the notication stage. Regarding the user-delegate, it is in charge of the following operations: inform the user-agent about the component M-services it has established to satisfy its users request; and inform the storage-agent about the component services of a composite service it will receive from device-agents. Regarding the provider-delegate, it noties the provider-agent about its agreements with a user-delegate. We recall that provider-agents do not reject agreements. Based on the information it receives from its provider-delegate, the provider-agent passes this information along to the device-agent. This information concerns the M-services that are involved and the storage server that is involved. Among the actions the device-agent undertakes is to submit the M-services to the storage-agent of the storage server. The purpose of the realization stage is to execute the component M-services of a composite service that the user-delegate has designed. User-agent and storage-agent take part to this stage. Before the user-agent asks the storage-agent for the M-services it has, it waits for a notication message from the storage-agent mentioning that the component services are ready for submission. In Figure 3, operation (7) implements the realization stage. In the realization phase, reliability is one of the concerns that have been considered in SAMOS. 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. The storage-agent deletes that service when the user-agent asks for the next M-service. For the last M-service of a composite service, the user-agent sends an acknowledgement message to the storage-agent so this M-service can be deleted. Figure 4 is an example of the way reliability is handled in the realization stage. For illustration purposes, a composite service of three M-services is considered. Interactions between user-agents and storage-agents are illustrated with request and push performatives. In addition, actions that both agents perform are associated with prepare run save and delete performatives. In Figure 4, when the user-agent requests M-service2, it is granted that the execution of M-service1 has been successfully completed. Therefore, the storage-agent deletes M-service1. The opposite occurs with M-service2; it has been requested twice. Fortunately, the storage-agent has not yet deleted M-service2, otherwise the whole composite service in the storage server could have became ineffective. 5. Specication of a composite service of M-services In SAMOS, a composite service of M-services reects the collaboration work of multiple providers. Each provider contributes to the composite service with one to several M-services. This is determined during the interaction session that occurs between

User-agent Actions Interactions Seq.: m-service1,2,3 To-make-ready: seq.1 prepare: request Request: ?M-service1 Push: m-service1 run: M-service1 delete: M-service1 Request: ?M-service2 Push: M-service2 wait: M-service2 Request: ?M-service2 Push: M-service2 run: M-service2 delete: M-service2 Request: ?M-service3 Push: M-service3 run: M-service3 delete: M-service3 Request: ok

Storage-agent Actions prepare: message

Software agents and mobile web services 321

save: M-service1

delete: M-service1 save: M-service2

delete: M-service2 save: M-service3

delete: M-service3

Figure 4. Interaction diagram of the realization phase

user-delegates and provider-delegates in the MI (Figure 1). To specify a composite service of M-services, service chart diagrams are used (Maamar et al., 2003c). Service chart diagrams are based on UML state chart diagrams (Harel and Naamad, 1996). This time, the focus is on the context surrounding the execution of a service rather than on the states that a service takes. Services are represented from ve perspectives (Figure 5). Basically, the state perspective is a state chart diagram. The organization perspective identies both the entity that is in charge of wrapping an M-service before it is added to a composite service, and the entity that is in charge of submitting the M-service for execution. The information perspective identies the data that are exchanged between the M-services of a composite service. Finally, the location
Layer 1 Previous M-services B 2 State1 State2 Statej Statek Data from previous Mservices Data to next M-services M-Service Pro./Dev. agent Storage agent Next M-services E


Figure 5. Service chart diagram of an M-service

BPMJ 12,3

perspective identies the current place of an M-service. An M-service can be in one of the following places: . provider site waiting for selection and integration into a composite service; . storage-server waiting for its turn to be submitted for execution; or . mobile device under execution. No more than one M-service can run on a mobile device (constraint to be relaxed based on the computing resources of mobile devices). Table V reports the details that enrich the service chart diagram of an M-service. These details are associated with layers 1, 2, and 3. Layer 2 is the most interesting as it contains the states that an M-service takes. These states constitute a state chart diagram that will be connected to the state chart diagrams of the M-services of the same composite service. Because a composite service consists of several M-services, the process model underlying that composite service is specied as a state chart diagram whose states are associated with service chart diagrams of the component services, and whose transitions are labeled with events, conditions, and variable assignment operations (Figure 6). According to the location perspective, an M-service (i.e. instance) can be in one of the following places: provider site, storage server, and mobile device. These places affect the shape and content of the service chart diagram of that M-service. For illustration purposes, we only apply the service chart diagram to two places: storage server and mobile device.


Layer 1

Field Previous services Next services Provider-/device-agent Storage-agent States Data from previous services Data for next services Place

Perspective Flow Organization State (normal and ad hoc operation) Information Location

Table V. Fields and perspectives of a state chart diagram

2 3

Service1 chart diagram Service1

Service2 chart diagram Service2 and Service3 Service3 chart diagram

Figure 6. State chart diagram of a composite service

Storage server place (Figure 7): a provider-delegate gives a user-delegate the permission to use an M-service. Next, this M-service is sent from the provider site to a storage server. Mobile device place (Figure 8): a storage-agent submits an M-service for execution to a users mobile device. In Figure 8, bold lines represent the links that exist between the M-services of the same composite service; in label corresponds to the data that are obtained from the predecessors M-services. Meanwhile, out label corresponds to the data that are left to the successors M-services (due for execution after the current M-service is completed). In Figure 8, the dashed line with an arrow represents a wireless transition; an M-service is transferred from a storage server to a mobile device. For illustration purposes on the way a composite service is devised, we suggest the following example. We assume a composite service CS of three component M-services (they are sequentially executed; concurrent execution is also doable but not discussed in the paper). Nine service chart diagrams are designed; three diagrams per M-service.

Software agents and mobile web services 323

M-servicei M-servicei-1/Null Device agenti Preparation M-service selection do/ understand mobile device wrap M-servcice Prepara. success Storage agentk Transfer do/ package M-service send M-service Transfer sucees M-servicei+1/Null

Standby User-agent /if last M-service do/ inform useragent Composite update

Reception do/ check M-service connect to composite service


Storage serverk


Figure 7. Service chart diagram of an M-service in storage-server place

M-servicei Null Null Storage agentk Realization

Preparation success


M-ser vice ar r ival


do/ check M-service install M-service

in Mobile devicex

do/ run M-service request next Mservice

/If last M-service


out 0[out-data=value]n


Figure 8. Service chart diagram of an M-service in mobile-device place

BPMJ 12,3


Figure 9 shows the composite service CS, the M-services that compose that composite service, and the execution chronology. Below each M-service, there are three boxes that constitute the service chart diagrams of that M-service (letter a: service chart diagram in provider site place, letter b: service chart diagram in storage server place, letter c: service chart diagram in mobile device place). Based on the three places, the state chart diagram of the composite service CS combines the service chart diagrams of its component M-services. Table VI helps in understanding how the state chart diagram of CS is obtained: . At time T, the state chart diagram of CS consists of the service chart diagrams of M-service1 (a), M-service2 (a), and M-service3 (a). . At time T 1, the M-services of CS are now identied and their provider-agent and device-agent are asked to transfer them to a specic storage server. The state chart diagram of CS consists of the service chart diagrams of M-service1 (b), M-service2 (b), and M-service3 (b). . At time T 2, CS is now established and its M-services are ready for submission to the users mobile device for execution. Since, the M-services are sent one by one, the state chart diagram of CS consists of the service chart diagrams of M-service1 (c), M-service2 (b), and M-service3 (b). . At time T 3, M-service1 has been executed with success and M-service2 is due for execution. Now, the state chart diagram of CS consists of the service chart diagrams of M-service1 (-), M-service2 (c), and M-service3 (b).

Composite service 1 M-service1 2 M-service2 c a b c a 3 M-service3 b c

Figure 9. State chart diagram of a composite service

Service diagrams

Service diagrams

Service diagrams

a: provider-site place; b: storage-server place; c: mobile-device place

Time T T1 T2 T3 T4 T5

M-service1 Service diagram a b c

State chart diagram - CS M-service2 Service diagram a b b c

M-service3 Service diagram a b b b c

Table VI. State chart diagrams of a composite service

At time T 4, M-service2 has been executed with success and M-service3 is due for execution. Now, the state chart diagram of CS consists of the service chart diagrams of M-service1 (-), M-service2 (-), and M-service3 (c). At time T 5, the execution of CS is completed.

Software agents and mobile web services 325

6. Security in SAMOS In SAMOS, security is addressed from three perspectives: (1) When a provider-delegate enters the MI, its security credentials are checked. The supervisor-agent is in charge of the operation (Security, 2002). (2) When an M-service is transferred from a provider site to a storage server, the storage-agent ensures that the M-service is sent by the right device-agent to the right storage-agent. In addition, the storage-agent has to ensure that the M-service will be sent to the right user-agent before it gets forwarded. (3) When an M-service is sent for execution from a storage-server to the mobile device of user, the M-service has to be checked before it gets installed on the device. In what follows, we focus on Perspective 3. We are designing an access control architecture for SAMOS. We highlight the security strategy that is adopted to prevent malicious M-services from misusing the resources of mobile devices. 6.1 Service-based access control The role-based access control (RBAC) is a well-know strategy for managing the access rights of users in an organisational system (Sandhu et al., 1996). In such a system, users are associated with roles. And, for each role a set of rights are granted. In an open service-oriented environment of mobile users, the RBAC strategy is deemed not appropriate. In fact, the management of roles is not convenient at all. The execution of M-services constitutes a serious threat to mobile devices of users. An M-service can use the local services (e.g. calendar, calculator) of a mobile device to request some sensitive information (e.g. secret code of an m-banking application). Moreover, an M-service can take advantage of the relationship of trust that could exist between the system (i.e. mobile device) and the existing local services in order to request some sensitive information. To handle the aforementioned security situations, we are designing a service-based access control architecture (Figure 10). In this gure, the numbering illustrates the steps that are required to grant a service (whether local or mobile) the right to access

1. Request of access 5. response (yes/no)

5. Action/ response(yes)


Security context

2. Security context check

Monitoring module

3. Rules check

Pattern database

Figure 10. Service-based access control architecture

BPMJ 12,3


the resources of a mobile device. The rationale of monitoring module, security context, and pattern database is explained below. First of all, a service submits a request of access to the monitoring module (1). After receiving the request, the monitoring module checks rst the security context of the resource that is targeted in this request (2). Details on the security context are in Section 6.2. Afterwards, the monitoring module browses the pattern database (3). The objective is to identify any malicious pattern that exists in the database and presents similarities with the execution trace of the current service. A response to grant or deny the request of access is sent back to the service (4). Details on the pattern database are provided in Section 6.3. Finally, the access is performed in case of approval (5). 6.2 Security context specication In Figure 10, the monitoring module decides if a service has the right to access a resource. To make such a decision, the monitoring module relies on a security context that has the following format: S1S2. . .SnR where Si is a service and R is a system resource (e.g. data, le), represents an access request. A resource R has a security context that needs to be checked each time an access request to that resource is initiated. The nal decision to grant an access to a resource R is based on the following algorithm: Get the security context related to the access request to R. If any Si in the security context does not have the right to access R. Then deny access to R. Else call check_rules( ). Check_rules( ) is a function that uses a database of malicious patterns. The function guarantees that the actions performed before granting an access right to the resource R do not constitute a malicious attack. Otherwise, the access request is denied. 6.3 Pattern database Pattern database aims at storing all the potential threats that could occur in an environment of M-services. These threats are identied with patterns. A pattern is based on the execution trace of a service with regard to the sequence of primitive actions that this service implements. Relying on the malicious pattern database, the monitoring module controls both the security context of any access request to a resource and the primitive actions that a service has performed. For illustration purposes, let us assume that a and b are primitive actions. When a service performs action a then action b, the monitoring module checks if ab constitutes a malicious pattern. To that purpose, the monitoring module consults the pattern database. Malicious patterns are detected from traces and data security levels[2]. A malicious pattern is specied by one or several rules. Each rule species why a service is considered malicious. The following example illustrates a specication rule of a malicious pattern. read send is a malicious pattern iff; read: read x;

send: send x; x: secret. The rule states that read send is a malicious pattern if-and-only-if read is an action of reading a secret data x and send is an action of sending the same secret data x through the network. 7. Related work There exist several projects that have studied how mobile devices can change the way of doing business. In HP Laboratories, (Milojicic et al., 2001) worked on delivering internet services to mobile users. This work was titled pervasive services infrastructure (PSI). The PSI vision is any service to any client (anytime, anywhere). The project investigated how ofoading parts of applications to mid-point servers can enable and enhance service execution on a resource-constrained device. In SAMOS, we are interested in the same issues. Furthermore, we consider how to support users in searching for M-services in an open wireless environment. The MI is part of the searching support that SAMOS provides. In Noble et al. (1997), the Odyssey project aimed at providing system support for mobile and adaptive applications. Odyssey dened a platform for adaptive mobile data access on which different applications (e.g. web browser, video player, and speech recognition) can run above. The Odyssey approach is to adjust the quality of accessed data to match available resources. In SAMOS, we consider adaptability at two different levels: (1) M-services are wrapped which means adapted to the features of mobile devices. (2) User-agents request M-services from storage agents according to the resources that are available on the mobile devices. In Ninja (2001), the Ninja project aimed at suggesting new types of robust and scalable distributed internet services. Ninjas 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 architecture considered four elements: bases, units, active proxies, and paths. Similar to a composite service of M-services in SAMOS, a path is an abstraction through which units, services, and active proxies are composed. Proxies are transformational intermediaries put between devices and services to shield them from each other. Ninja proxies are similar to device-agents of SAMOS. Ninja also 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. Comparable to the SDS, the MI in SAMOS has a brokering role. Further, the MI facilitates the direct interactions between providers of services and consumers of services via delegates. The MI avoids bottleneck situations and ensures a better security to bother providers and consumers. The work described in (Elsen et al., 2001) focused on mobile streaming services and the obstacles that impede their widespread. Heterogeneity of access network and device and protection of content as well constitute the main challenges. Currently, a variety of mobile devices with a wide range of display sizes and capabilities are available. Network carriers have also to deal with such a variety of devices. One way to address heterogeneity is to set-up exchange mechanisms that enable terminals and

Software agents and mobile web services 327

BPMJ 12,3


servers to negotiate the capabilities of mobile device mobile network as well as the preferences of users. A proxy component was suggested to implement these mechanisms. Its major task is to adapt the streaming multimedia on the y to the mobile network links continuously changing conditions. In SAMOS, device-agents and storage-agents deal with the heterogeneity of M-services and devices. For the second challenge, controlling what users can do with content is important. Content protection is part of the much broader digital rights management (DRM) concept, which uses techniques such as encryption and conditional access based on usage rules and manage access to multimedia data. In SAMOS, security mechanisms exist at three levels, before delegates get into the MI, when submitting M-services to storage-servers, and nally when submitting M-services for execution. 8. Conclusion We presented the characteristics of SAMOS in terms of architecture, types of agent, operation, and specication technique of composite services. Details on the implementation are found in (Maamar et al., 2002). Three major factors should boost the penetration and expansion of M-services in the market: personalization, time-sensitivity, and location-awareness. We believe that considering mobile devices as computing platforms will become, if it is not already becoming, a reality in the near future. Networks that make these devices reachable are in constant progress, offering more bandwidth and ensuring more reliability and efciency. In addition to higher data rates, new value-added services will be offered to users such as geographical positioning, advertising proling, and mobile payment.
Notes 1. The 3W composite capabilities/preferences proles (CC/PP) working group is developing standards that will enable providers of services to request the capabilities of devices through their prole. 2. Data are labeled with security levels. For instance, data could be public, shared, secret, etc. References Benatallah, B., Sheng, Q.Z. and Dumas, M. (2003), The self-serv environment for web services composition, IEEE Internet Computing, Vol. 7 No. 1. Chisalita, I. and Shahmehri, N. (2001), Issues in image utilization with mobile e-services, Proceedings of the 10th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE2001), Boston, MA, USA. Curbera, F., Khalaf, R., Mukhi, N., Tai, S. and Weerawarana, S. (2003), The next step in web services, Communications of the ACM, Vol. 46 No. 10. Elkadhi, A., Moulin, B. and Maamar, Z. (2001), Vers une Approche dEvaluation de lApport de la Mobilite du Code dans les Environnements Distribues, Journees Francophones en ` Intelligence Articielle Distribuee et Systemes Multiagent (JFIADSMA2001), Montreal, Canada. Elsen, I., Hartung, F., Horn, U., Kampmann, M. and Peters, L. (2001), Streaming technology in 3G mobile communication systems, IEEE Computer magazine, Vol. 34 No. 9. Ericom (2001), Ericom Software, available at:\_mobile.asp (accessed September).

Harel, D. and Naamad, A. (1996), The STATEMATE semantics of statecharts, ACM Transactions on Software Engineering and Methodology, Vol. 5 No. 4. Jennings, N., Sycara, K. and Wooldridge, M. (1998), A roadmap of agent research and development, Autonomous Agents and Multi-Agent Systems, Vol. 1 No. 1. Maamar, Z., Dorion, E. and Daigle, C. (2001), Towards virtual marketplaces for e-commerce, Communications of the ACM, Vol. 44 No. 12. Maamar, Z., Mansoor, W. and Mahmoud, Q. (2002), Software agents in the wireless world application to mobile services, Proceedings of the 1st International Workshop on M-services/Concepts, Approaches, and Tools/Held in Conjunction with the 13th International Symposium on Methodologies for Intelligent Systems (ISMIS2002), Lyan, France. Maamar, Z., Sheng, Q.Z. and Benatallah, B. (2003a), On composite web services provisioning in an environment of xed and mobile computing resources, Information Technology and Management Journal, in press. Maamar, Z., Sheng, Q.Z. and Benatallah, B. (2003b), Selection of web services for composition using location of provider hosts criterion, Ubiquitous Mobile Information and Collaboration Systems Workshop (UMICS2003) held in conjunction with the 15th Conference On Advanced Information Systems Engineering (CAiSE2003), Velden, Austria, June 2003, Velden, Austria, June. Maamar, Z., Benatallah, B. and Mansoor, W. (2003c), Service chart diagrams description & application, Proceedings of The Twelfth International World Wide Web Conference (WWW2003), Budapest, Hungary. Milojicic, D., Messer, A., Bernadat, P., Greenberg, I., Fu, G., Spinczyk, O., Beuche, D. and Schroder-Preikschart, W. (2001), PSI pervasive services infrastructure, HP Technical Report HPL-2001-87, HP Laboratories, Palo Alto, CA. Ninja (2001), The Ninja Project, available at: (accessed September). Noble, D., Satyanarayanan, M., Narayanan, D., Tilton, J.E., Flinn, J. and Walker, K.R. (1997), Agile application-aware adaptation or mobility, Proceedings of the 16th ACM Symposium on Operating Systems Principles, France. Sandhu, R., Coyne, E., Feinstein, H. and Youman, C. (1996), Role-based access control models, IEEE Computer, Vol. 20 No. 2. Security (2002), Security in Mobile Agent Systems, available at: www.informatik.uni-stuttgart. de/ipvr/vs/projekte/mole/security.html (accessed October). Tsalgatidou, A. and Pilioura, T. (2002), An overview of standards and related technology in web services, Distributed and Parallel Databases, Vol. 12 No. 3. Corresponding author Zakaria Maamar can be contacted at:

Software agents and mobile web services 329

To purchase reprints of this article please e-mail: Or visit our web site for further details: