Mobile Networks and Applications 7, 199–212, 2002 2002 Kluwer Academic Publishers. Manufactured in The Netherlands.

A Service Management Framework for M-CommerceApplications

GARY SHIH and SIMON S.Y. SHIM ∗Department of Computer Engineering, San Jose State University, San Jose, CA 95192, USA

Abstract. Mobile commerce (m-commerce) refers to an ability to conduct wireless commerce transactions using mobile applications inmobile devices. M-commerce applications can range from as simple as an address book synchronization to as complicated as credit cardtransactions. M-commerce is expected to grow dramatically in the near future supporting simple to complex commerce transactions. Eventhough the Wireless Application Protocol (WAP) is designed to facilitate the development of wireless applications, it will not be sufficientto handle complex business transactions that require cooperation of different service applications. In order to handle these complex mobilecommerce transactions efficiently, an intelligent, robust and scalable framework that provides diverse m-commerce services is required.This paper describes in detail such an m-commerce framework based on the Java Intelligent Network Infrastructure (JINI) and WirelessApplications Protocol (WAP).

Keywords: m-commerce, management, WAP, JINI, mobile devices

1. Introduction

In today’s post-PC consumer electronics market, few thingscan compare to the success of mobile hand-held devices. Mo-bile personal devices such as Palm Pilot devices, web-enabledcellular phones, and Personal Data Assistants (PDAs) havebeen the darlings of consumers from businessmen to studentsalike. The decrease in price of the mobile devices due tomarket competitiveness and the established open standard forWireless application development is fueling this hyper growthof m-commerce. According to a recent market study, it is es-timated that there will be 500 million wireless subscribers bythe end of year 2001, and this number is expected to growto more than a billion by 2004 [18]. The competitive wire-less device market has certainly contributed to the decrease ofprices of many wireless devices. With number of devices andusers growing in the past few years, so has the market demandfor additional functionalities on these devices. Riding on thewave of the success of electronic commerce on the WorldWide Web (WWW), the market has definitely been makinga push towards mobile commerce services (m-commerce).There are many wireless services and applications under theumbrella of m-commerce, but generally they are grouped intotwo categories: consumer-based and business-based.1

Consumer-based m-commerce applications refer to nor-mal daily commerce activities that are most likely to be con-ducted by anyone who is a user of a wireless device. Exam-ples include receiving stock prices, finding restaurants, get-ting driving directions, shopping on-line, etc. These are theactivities that people conduct in their daily lives and are partof their lifestyles. An individual can subscribe to a particular

∗ Corresponding author.1 Throughout this paper, m-commerce applications and m-commerce ser-

vices will be used interchangeably since a service is based on an appli-cation.

wireless service provider of financial news and can receiveupdated stock and financial information based on user prefer-ences. A more complex example would be using the cellularphone to purchase merchandises.

Business-based m-commerce refers to business applica-tions that are applied in a corporate or business environmentto facilitate business transactions and to improve productiv-ity within a company [21]. Examples in this category includemobile inventory tracking systems, mobile offices, wirelessdata centers, etc. A commerce scenario in this case is morecomplex than a consumer-based scenario. For example, atraveling businessman in a business meeting can use a cellularphone to receive inventory information and product quotes;thus providing his/her client with real-time quotes of prod-ucts. If a sale is made, the transaction information could besent back to a corporate inventory tracking system and bepropagated through a company’s ERP system. If necessary,the sale information may be forwarded to manager’s com-puter, fax, printer, PDA, or the pager in a corporation head-quarter for an approval. If a sold item results in an inven-tory back order, then the system can automatically trigger apurchasing request to its vendor as depicted in figure 1. Asshown in the above example, the sales activity from a cellu-lar phone client triggers the automatic propagation of vari-ous system interactions that are totally hidden from the user.Hence, m-commerce means not only mobile device commu-nications but also an infrastructure that supports both devicesand enterprise applications. In this paper, we propose a flex-ible framework that autonomously manages not only simpleservices but also complex ones from mobile devices and dis-cuss technical issues related to such a service managementframework.

Notice that in both models, although the complexity of theservice differs from one another, the common theme is thesame in that m-commerce services are personalized. In the

200 SHIH AND SHIM

Figure 1. Business-based m-commerce framework scenario.

case of the consumer-based application, a user subscribes toa wireless service provider and provides user preferences forthe type of news one would like to receive (financial newsor sports news). A service provider then provides the in-formation about that particular area of interest, and nothingelse. This type of service is quite different from our currentdesktop web base model where a user can “surf the web” un-til he/she finds his/her own interest areas. Likewise, in thecase of business-based m-commerce shown above, a backendsystem cannot perform system interactions unless a usernameand a password are provided to an ERP system. The user-name and the password serve two purposes. One is to identifywhether or not the employee has the right level of clearanceto conduct a sales transaction. The second purpose is to iden-tify that the right individual is recorded in an employee per-formance tracking system. Therefore, the transaction is alsoindividualized.

The personalized model of m-commerce could be due tothe inherent physical nature of wireless devices. Mobile de-vices, let it be a Palm Pilot or a cellular phone, are limitedin screen size, memory size and user interaction. WirelessInternet devices usually have the “micro browser” capabilitybuilt in to support WWW activities. However, users simply donot have the luxury of non-interlaced color monitor for view-ing or keyboard for entering data. Therefore, many thingsthat most people use on the Internet today cannot be simplymigrated to the m-commerce model. For example, activitiessuch as writing a long e-mail or reading a detailed expert opin-ion on a particular book are not applicable to the m-commerceuser since there are no keyboard to type and no big screen toread, especially for cellular phone users. Besides the physicalattributes of mobile devices, another reason for the person-alized m-commerce model is due to the nature of wirelessnetworks. Wireless networks are prone to dropping calls orinterference and the bandwidth is usually smaller than wirednetworks [5]. Therefore, m-commerce activities would needto be short, concise, and right to the point. Activities such as“surfing and browsing” the web could be inconvenient sincethe session might be dropped frequently and difficult to re-cover.

With these issues in mind, the personalized model de-scribed above is, therefore, accepted by the industry as themost appropriate model for m-commerce services. How-ever, having agreed on this personalized delivery model does

not mean that everybody would implement it in the sameway. As a result, ever since the first m-commerce applica-tion was developed, different companies have been using theirown proprietary ways to develop wireless applications. Eventhough there was tremendous interest in the industry to pushm-commerce to reality, but there was no common applica-tion standards and guidelines to follow, until the creation ofthe Wireless Application Protocol (WAP) [21] in 1997 by thecollaboration of Nokia, Motorola, Ericsson, and Phone.com.WAP basically provides a communication and applicationprotocol for the development of wireless applications. Its goalis to offer interoperability across different wireless devices,applications, and networks. WAP actually follows the HTTPon TCP/IP model. In the technical overview section, WAPis discussed in detail. Because it follows the HTTP model,its application environment mimics that of HTTP, and pro-vides an easy-to-use user interaction model based on Wire-less Markup Language (WML), which is based on XML [22].In addition, WAP also provides a protocol stack that is lay-ered. Because of its layered design from physical layer topresentation layer, wireless application development industryhas quickly embraced WAP and endorsed it as the answer forrapid developments of m-commerce applications. Our man-agement framework uses WAP as an entry point for mobilecommunications to connect to other services in the backend.

However, WAP alone is not sufficient for handling com-plex m-commerce transactions. In the example of thebusiness-based m-commerce application described above, al-though WAP can be used to facilitate interactions between aWAP enabled phone and an inventory tracking system, it sim-ply has no knowledge of interactions between various back-end ERP systems. In addition, what if different ERP systemsare located in different servers in a distributed networking en-vironment? WAP by itself has no intelligence to find all theseservices and propagate required actions. In other words, WAPmight be a perfect fit for handling simple m-commerce appli-cation, but not for applications that require complex servicepropagations. Therefore, a distributed service managementframework would be needed to manage the “workflow” forthis type of complex m-commerce applications. There areother issues that need to be addressed in the m-commerceframework. First, the management framework should be flex-ible enough to support a large network of devices and ser-vices ranging from simple to complex ones. Second, the ser-

A SERVICE MANAGEMENT FRAMEWORK 201

vices that comprise backend operations of an m-commerceapplication should be able to add themselves to the frame-work in an easy and effective manner. It is important becauseit would provide a “plug and play” environment that is self-manageable and robust. Also, the framework should be ableto provide transaction capabilities to ensure data integrity andsecurity. Hence, our management framework is designed tobe autonomously scalable and provides transaction and work-flow supports.

There are several technologies that can be considered tosupport those issues mentioned above. One of them is theJava Servlet technology [16]. Although it is a dynamic tech-nology for content developments, it is not robust enough forsystem interactions. Second consideration would be usingJava Remote Method Invocation (RMI) [15]. RMI, on onehand, provides a good technology for remote network com-puting, but it is too bare-bone to build an m-commerce frame-work based on it. The third consideration is the Common Ob-ject Request Broker Architecture (CORBA) technology [12].CORBA provides a very robust way and many convenient ser-vices to handle distributed networking, but in its essence, it isa bolted-on technology for connecting objects, and does notencourage having remoteness built into distributed system ob-jects. The fourth technology is Java Intelligent Network In-frastructure (JINI) [9]. JINI provides a distributed networkingenvironment, similar to CORBA, but it encourages develop-ers to build the distributed objects with remoteness in mindvia its usage of RMI. Hence, we chose JINI as the basis ofbuilding our management framework. We discuss the alterna-tive technologies in details to offer a clear understanding ofwhy JINI was chosen for this framework.

2. Technology overview

Since the m-commerce framework proposed in this paperleverages two cutting edge technologies, WAP and JINI, itis important to gain a basic understanding of each of the twotechnologies in order to proceed to the design and the imple-mentation of the proposed work. Since each of the topics canbe a major discussion on its own, this paper will not try tocover all the in-depth details of WAP and JINI, but rather tofocus on the fundamentals and the areas that are pertinent tothe design and the implementation of the framework.

2.1. Wireless Application Protocol (WAP)

As mentioned earlier, acting as the entry point of a user inter-face component, WAP [1,21] will be an integral part of ourm-commerce framework. Like TCP/IP or OSI networkingmodel, WAP is also a layered protocol. The advantage of alayered protocol is that as long as the interface between thelayers in well defined, the actual implementation of the dif-ferent layers can change without affecting the overall networkarchitecture. The different layers are responsible for differentoperations. There are six layers: Application, Session, Trans-action, Security, Transport, and Network. Since we are fo-cusing on the application of the entry point user interface, weare primarily dealing with the application layer, which is theWireless Application Environment (WAE).

The WAE provides the main user interface to the client de-vice and specifies a wireless markup language (WML) whichdefines the presentation of the data, and wireless markupscripting language (WMLS) that provides dynamic user in-terface functions such as computation. WML is based onXML [22]. There are three components in a WAP commu-nication schema (again, we are only concerned about the pre-sentation layer; everything else is taken care of by the proto-col itself):

• The WAP Client. The WAP client communicates withthe WAP Gateway. The request/response presentation isshown in a deck of cards. Each deck would consist of oneor more cards with the syntax of which defined in WMLand WMLS. WML and WML scripts provide many tagsthat allow the users to navigate to other cards in the deckas well as performing various user interface actions.

• The WAP Gateway. The WAP Gateway serves as protocoladapter and provides binary encoding and decoding capa-bilities to minimize network bandwidth.

• The WAP Content Server. It serves as a general web serverthat hosts the requested contents and is responsible forconnecting to any other backend operations.

Based on the protocol specified, the WAP communicationschema is shown in figure 2.

1. The client uses the user interface written in WML/WMLSto input a request.

2. The client request is encoded to minimize network trans-mission load and then is sent the content server.

Figure 2. WAP communication schema.

202 SHIH AND SHIM

3. The WAP gateway intercepts the client request, decodesthe request, runs it through the protocol adapter to trans-form the request into a HTTP compliant request.

4. The request in HTTP form is then sent to the contentserver.

5. The content server processes the request, sends to thebackend services if necessary, and then sends the responseback to the client.

6. The WAP gateway again intercepts the response, runs itthrough the adapter, and encodes it for WAP transmission.

7. The client gets the response in encoded WML/WMLS, de-codes it, and shows the result.

WAP has a Security Layer, which implements the wirelesstransport layer security (WTLS). WTLS is based on the in-dustry known networking security standard, Transport LayerSecurity (TLS), also known as Secure Socket Layer (SS). Thislayer of WAP is important to our framework as it provides asecurity mechanism that ensures data integrity, privacy, au-thentication, can denial of service protection. We do not needto implement our own wireless security schema since this isalready defined as part of WAP.

2.2. Java Intelligent Network Infrastructure (JINI)

Developed by Sun Microsystems, JINI [6,12] is a distrib-uted network environment for device and service connectivity.Technically speaking, there is no concept of hardware or soft-ware in JINI. JINI treats both hardware applications and soft-ware applications just as services. The users of these servicesdo not need to know how one service or another is imple-mented in order to use the service. All the JINI services needto communicate with each other is well-defined interfaces.

JINI addresses the issue of scalability through the conceptof community and federation. A JINI community refers to agroup of similar services join together in cooperating states.For example, the group of cellular phones can join in the “cel-lular client” community. The advantage of a community con-cept is that these phone clients can then share the same re-sources that are pertinent to cellular phone activities. When acommunity needs to interact closely with another community,a federation can be formed between them. For example, the“cellular phone” community can join in a federation with the“database” community and then with the “printer” commu-nity. The cellular phone service can lookup the information inthe address book service, and then prints the results out withthe printer service. The ability for different services to linkto each other on user-defined transactions is the key to howJINI manages the scalability issue in distributed networkingenvironment.

The issue of reliability needs to be properly addressed inthe development of network applications, since a user trans-action might need to go through a sequence of operations thatare executed on different computers. If any of the operationsfails during a transaction or the service is not available at the

time of service transaction (such as power outage), it is criti-cal that the managing platform of these services be reliable tobe able to recover from these potential failures. JINI providesa way for services to self-discover each other and be automati-cally notified when the cooperating services are not available.By using the “Leasing” (see Leasing below for more informa-tion), JINI services are able to constantly upgrade and notifythemselves on changes in the network.

JINI is comprised of five fundamental concepts:

• Discovery and join: the process by which the servicesfind JINI communities on the network and join them. Theproperty of JINI allows the services to self-build commu-nities and federations.

• Lookup: acts as a directory service within each JINI com-munity. It provides mechanisms for potential users tosearch and locate the services that they would like to use.JINI’s lookup service not only can locate services by stringvariable, but it is also powerful enough to find servicesthrough object relationships and inheritance hierarchy.

• Leasing: refers to the constant renewal of the services op-erating on the JINI platform. This is an interesting conceptthat JINI use specifically to address the reliability problemin distributed network environments. Essentially, the ser-vice needs to renew itself with the JINI platform within apredetermined period of time, continuously. If for somereason, the service falls out of the JINI network, it wouldbe dropped by the JINI network without affecting the over-all structure of the network. The user would only see a ser-vice not available message, but no harm is done. Once theservice gets back on line again, it would request the leaserenewal again and become active.

• Remote events: JINI allows objects to notify each otherwhen certain events happen. JINI performs remote eventnotifications asynchronously so that the interested partiesof the events will be automatically notified when eventshappen.

• Transaction: transaction in JINI provides a light-weightand object-oriented version of the two-phase commit pro-tocol. In JINI, the protocol itself is only an interface. Theimplementation of the protocol is up to the transaction par-ticipants.

3. Alternative frameworks

As mentioned before, the JINI-based m-commerce frame-work is not the only framework that can be used for m-com-merce. There are other technology alternatives that can also beimplemented as the framework in a distributed m-commerceenvironment.

3.1. Java Servlets

With the explosion of the Internet, especially web-based ap-plications, Servlets [16], which are written in Java, have been

A SERVICE MANAGEMENT FRAMEWORK 203

a popular choice for serving dynamic contents for web ap-plications. From this perspective, Servlets can certainly beused as a powerful technology to develop dynamic WMLand WMLS contents. In fact, even in our framework, weuse Servlets extensively for communicating with WAP client.However, as mentioned earlier, if m-commerce is only aboutusing WAP client to request and retrieve some informationfrom a server database, Servlets would perfectly be sufficientto handle these transaction and can be used as the foundationof the m-commerce framework. Nevertheless, Servlets do nothave intelligence to propagate and dynamically find the re-quired services. Certainly, specific application logics can bebuilt into a Servlet-based framework and the service sequencecan be stored, but it would not be dynamic enough if a newservice is to be added in the middle of the sequence. It isnot flexible and scalable in this regard as a general managingframework for m-commerce. On the other hand, JINI has theconcept of discovery and lookup built into the infrastructure,services can be discovered and added to the JINI frameworkwithout much effort.

3.2. Remote Method Invocation (RMI)

RMI [15] might seem like an amiable alternative to JINI forthree reasons. One, RMI is used extensively in JINI to imple-ment the remote communications between the different ser-vices. Two, it also has a naming registry for services to reg-ister themselves. Three, RMI does have some type of leasingcapability similar to JINI. However, RMI does not have all theself-managing features that are built in with JINI. For exam-ple, RMI does not have the sense of communities and feder-ations that are essential to the scalability of a distributed net-work. Even though an m-commerce framework can be builton top of the features of RMI to mimic the JINI platform, a lotof work would be required. In essence, the developers wouldneed to implement a custom protocol which might be timeconsuming and less productive.

3.3. CORBA (Common Object Request Broker Architecture)

CORBA [2] can be a competitive alternative to the proposedm-commerce framework. CORBA, governed by the ObjectManagement Group (OMG), provides a middleware platformfor distributed computing. It provides services for objectsto discover each other, communicate with each other, andperform secure transactions. On the application level, anm-commerce framework using CORBA might be able to han-dle what JINI can do. However, there are two reasons whyJINI based platform might be better suited for CORBA form-commerce applications. One, CORBA is technology cre-ated as an “add on” or “bolted on” mechanism on differentlanguages to better manage the chaos in distributed comput-ing by allowing applications written in different languages totalk to each other. JINI, on the other hand, is based on Java,which provides a uniform data format across different plat-forms. Two, the remoteness of CORBA service objects areadd-on interfaces that applications can use to better facilitate

object communications; in other words, as the middleware,CORBA is about building a bridge between objects. JINI,on the other hand, provides remoteness to the developers inthe design stage of the objects, so that remoteness is actuallybuilt within the objects. In other words, JINI is about the ob-jects building a bridge on their own. This nature of built inremoteness is definitely more powerful than a “patched on”remoteness.

Notice that JINI does have its own deficiencies as well.One, the overhead of JINI APIs and JVM can have some neg-ative impact on the performance of the system. Two, CORBAmight be easier to implement on legacy applications since,as mentioned above, its purpose is to connect systems or ob-jects that are already built, although Java’s Java Native Inter-face (JNI) [7] can also be used to connect to legacy applica-tions. However, the JINI architecture itself is flexible enoughto basically treat everything as a service, whether it is a hard-ware device or a software application. JINI has the built ininfrastructure to support different devices and different ser-vices and this type of infrastructure is exactly what we needto build the m-commerce framework.

4. Framework design

4.1. The m-commerce framework

A prototype framework is designed and implemented to sup-port an infrastructure for m-commerce transactions. It givesan improved understanding of the actual system. It also helpsin straightening the ambiguities present in the design require-ments. To prove the effectiveness of the framework evolved,this section describes the design with the following objective:to be able to use the mobile phone devices as the client entrypoint for both simple and complex m-commerce applicationswith each application consisting of a sequence of services thathave “joined” the JINI platform.

Based on the objective, the following four designs are pro-posed as well as our approach in using JINI to achieve thesegoals:

1. Simplicity. It should be easy to use and simple enough tofacilitate new services, either wireless clients or wirelesscontent services. We address this by making the wirelessclient itself also be a service in the framework, and usesJINI’s discovery and join as well as the lookup protocolsto handle dynamic service additions.

2. Scalability. It should be scalable to accommodate a largenumber of users and services as well as many types of mo-bile devices. We address this issue from the perspectiveof JINI community and federations. By default, any ser-vice that joins the JINI platform belongs to at least onecommunity (the one which it joins). Communities that in-teract with each other form a federation that would allowthe sharing of resources.

3. Security. It should address security considerations, espe-cially for commerce/payment transactions. The transmit-ted data itself not only needs to be secured via encryption

204 SHIH AND SHIM

but the integrity of the overall service propagation needsto be maintained. For example: we need to handle situa-tions when one of the backend ERP sub-systems fails, thusmaking the overall sequence of transaction in danger.

4. User experience. Regardless of how complex or how sim-ple the wireless application is, the user interface shouldbe coherent, and the whole sequence of services shouldappear to the user as if he/she is only dealing with oneservice. To have such a quality of service, the frameworkneeds to leverage the ability of JINI to manage these ser-vices in an intelligent and automated manner.

4.2. Architecture

The goals of the proposed system are to be able to demon-strate the significant aspects of the framework to bring out theadvantages of the framework as well as its drawbacks. Thecomponents of it are a wireless service client, a wireless ser-vice, and a service management engine. The overall architec-ture is shown in figure 3 with the explanation of each of thecomponents in the following subsections.

4.2.1. Wireless service clientThe wireless service client component represents an entrypoint of the framework. It consists of a wireless Internet de-vice, a wireless application server, and a service client soft-ware that acts as an interface layer to the management engineas shown in figure 3.

Java Servlets are used to handle WML and WMLS contentrequests and responses and to generate dynamic contents. Itis incorporated as part of the framework. By relieving theresponsibility of content generations to that of servlets, wecan focus on implementation of the m-commerce frameworkwithout worrying about how user interaction interfaces aregenerated. Upon the receipt of a client request, servlets routethe request to a WAP client proxy agent, which in turn, inter-acts with a service management engine. Inputs to the clientproxy agent are types of request, a client ID, and a password.The proxy agent takes these information, packaged it as arequest for the service management engine. This request isprocessed through the various sub-components of the man-agement engine. The service management engine works withwireless service components and returns a proxy for the re-quested service as well as a service propagation scenario fortransactions. Once a client finishes a requested service, thenext service in the operational sequence will be retrieved froma service propagation object that is passed from the first ser-vice to last until all services in the chain are completed. Ofcourse, in order to use JINI services, the WAP client itselfwould also need to join and become a JINI service.

Notice the “Wireless Client Abstraction Layer” in figure 3.This layer denotes the decoupling of the front-end wirelessclients component from the JINI service management com-ponent. This abstraction layer allows our framework to beextended to any wireless device that wishes to join regard-less of their application protocol. Therefore, although WAPis what we are using in this paper, any non-WAP model (such

as PALM VII) can also be used as long as a wireless client isdesigned to interface with the application server (PALM VIIWeb Clip Application Server) on one end and the JINI ser-vice management component on the other. As long as the re-quests and responses are handled correctly by the interfacingagents, the overall interactions can be performed seamlesslywith wireless devices.

4.2.2. Wireless serviceThe wireless services represent a collection of wireless ser-vices that would like to join the framework. Examplesof these services could be address synchronization services,movie ticket purchasing services, etc. These services makethemselves available by joining to the service managementengine, and also provide downloadable proxy objects forother services that wish to use their services. These servicescan be a legacy database, a simple desktop address book ap-plication, or a complex ERP system; and their implementationcan be written in C, C++, or any other computer language.As far as the framework is concerned, the only requirement isthat the service proxy objects need to be Java-based softwarecomponents.

4.2.3. Service management engineThe service management engine represents the portion of ourframework that hosts the JINI services (both core services, aswell as custom services that have joined the our JINI-basedsystem). The services that wish to join our framework wouldregister themselves via the JINI’s discovery and join protocol.The leasing ability of the JINI infrastructure allows servicesto be self manageable and flexible. Besides the services thatjoin the JINI platform, there are seven components in the ser-vice management engine. They are a personalization engine,a database, a security manager, a log manager, a transactionmanager, and a decision rule generator.

4.2.3.1. Personalization engine. A personalization engineis responsible for inputting, retrieving, and executing person-alized data. It captures the user inputs, such as login nameand password, and routes them to the User Info database andthe security manager. When there is a service request from aparticular user, the personalization engine retrieves user val-ues from the database using a phone number as an id. It theninteracts with the security manager and generates a specificoutput (name, id, security clearance level, etc.) for the work-flow engine. It also interacts directly with the workflow en-gine to process a list of actions based on user’s input. If auser requires a special action based on user’s preferences, itexecutes those requests such as an acknowledgement to a cellphone with a transaction identifier of a request.

4.2.3.2. Database. The database provides a data persistencymechanism for all the data in the framework. The personalinformation database stores user-specific data. The securityinformation database stores the clearance level and passwordinformation. The service database stores the names and at-tributes of the services that have joined the framework. The

A SERVICE MANAGEMENT FRAMEWORK 205

Figure 3. Prototype m-commerce architecture.

decision rules database stores the parsed XML data from thedecision generator. The workflow engine also retrieves the de-cision rules data from here. The service propagation databasestores the user specific service propagation scenario. This isalso saved as parsed XML data. Finally, the activity log data-base saves all the activities and transaction information.

4.2.3.3. Security manager. The security manager is a mod-ule that checks for a password and the appropriate securityclearance level for a user. If the password is incorrect, it willreturn a message back to the personalization engine indicat-ing that the password is incorrect. Otherwise, it returns thevalue of the clearance level that the user belongs to back tothe personalization engine. It performs other activities relatedto security verification and management.

4.2.3.4. Log manager. The log manager records all theactivities relating to m-commerce transactions, includingtimestamp information, service unavailability and fault infor-

mation, user login information, transaction information, etc.In other words, it is to monitor and record the status of a trans-action from the beginning of a transaction where the user logsin to the end of the transaction when a user completes a pur-chase request. For example, a status report is automaticallygenerated by the log manager and periodically sent to a printerservice for output.

4.2.3.5. Transaction manager. The transaction manageroversees transactions and make sure that the atomicity of atransaction is enforced. If at any time that a particular ser-vice fails in the transaction sequence, the transaction wouldbe considered incomplete and the whole transaction would beaborted. Its duty includes transaction monitoring, recovery,and load balancing.

4.2.3.6. Decision rules generator. The decision rules gen-erator is a software module that takes XML decision rules,parses, and generates rules for the workflow engine. The

206 SHIH AND SHIM

<?XML version = “1.0”><!DOCTYPE = ServiceType [<!ELEMENT ServiceType(STN, ServiceAction+)><!ELEMENT ServiceAction (SAN, AvailableDecision*)><!ELEMENT STN(#PCDATA)><!ELEMENT SAN(#PCDATA)><!ELEMENTAvailableDecision(#PCDATA)><!ATTLIST ServiceAction sequence CDATA #REQUIRED><!ATTLIST ServiceAction decisionMaking CDATA (yes/no) “no”><!ATTLIST ServiceAction critical CDATA (yes/no) “no” >]>

Figure 4. Decision rule DTD.

decision rules provide information on how a set of servicesshould be conducted and the order of which they should beconducted. XML is chosen to provide data uniformity acrossthe framework. We use XML throughout the framework.Note a user needs to create these decision rules following thespecified DTD. (See the implementation section for an exam-ple.)

A decision rule is created based on the DTD as shown infigure 4. When a new service is added, decision rules must becreated based on this DTD. The XML file can then be savedin the database. As shown in figure 5, each ServiceType musthave at least one ServiceAction that describes what serviceshould be invoked. The ServiceAction has two attributes. The“sequence” attribute determines the operation sequence forthis service in the chain of service propagation. The decision-Making attribute is used for the services that have more thanone possible choices for subsequent actions. For example, anERP service, depending on the requested purchasing amountby an employee, can either automatically approves a purchaserequest, or route it to a current user’s manager. In this case,the actual operational sequence cannot be determined untilrun time; therefore, it is not practical to hard code it in the de-cision rules. However, we want to track the available optionsfor this service because we will need this information at runtime. Therefore, the ServiceAction element has an optionalelement for AvailableDecision. AvailabeDecision is used totrack the available sequence of actions for the ServiceActionelement. The completed decision rules will be then sent toDecision Generator to be parsed and be saved in the database.

4.2.3.7. Workflow engine. Once the decision rules structureis defined, the information can be used in our workflow en-gine. The workflow engine is the “brain” of the framework.It provides and implements the business logic part of the re-quested services by using the particular user’s personalizedinformation from the personalization engine as well as a setof decision rules from the database. In other words, it is re-sponsible for the creation of a service propagation scenario.The immediate output of the workflow engine is an XML fileas shown in figure 7. The syntax is based on the service prop-agation DTD as in figure 6.

The generated service propagation by the workflow engineserves three purposes. One, it provides us with a clear pic-ture as to what service propagation is needed for transactionsand links transactions with an owner. Two, by combininguser/employee information, we would be able to access other

<ServiceType><STN>purchasing</STN><ServiceAction sequence =1 decisionMaking=“no”>

<SAN>StoreService<SAN></ServiceAction><ServiceAction sequence =2 decisionMaking=“yes” critical=“no”>

<SAN>ERPService<SAN><AvailableDecision>3</AvailableDecision><AvailableDecision>4</AvailableDecision></ServiceAction>

<ServiceAction sequence =3 decisionMaking=“no” critical=“no”><SAN>PrinterService<SAN>

</ServiceAction><ServiceAction sequence =4 decisionMaking=“no” critical=“yes”>

<SAN>ManagerWAPClientService<SAN></ServiceAction>

</ServiceType>

Figure 5. Decision rule XML file.

<?XML version = “1.0”><!DOCTYPE = ServiceScenario [<!ELEMENT ServiceScenario(User, TimeStamp, ServiceType)<!ELEMENT UsertTelephoneNum, EmployeeName?)><!ELEMENT TelephoneNum (#PCDATA)><!ELEMENT EmployeeName (#PCDATA)><!ELEMENT TimeStamp(#PCDATA)><!ELEMENT ServiceType(STN, ServiceAction+)><!ELEMENT ServiceAction (SAN, AvailableDecision*)><!ELEMENT STN(#PCDATA)><!ELEMENT SAN(#PCDATA)><!ELEMENTAvailableDecision(#PCDATA)><!ATTLIST ServiceAction sequence CDATA #REQUIRED><!ATTLIST ServiceAction decisionMaking CDATA (yes/no) “no”><!ATTLIST TelephoneNum EmployeelD ID #REQUIRED><!ATTLIST ServiceType Type CDATA #REQUIRED>]>

Figure 6. DTD for service propagation scenario.

<ServiceScenario><User>

<TelephoneNum Employee = 1234567>408-7775555</TelephoneNum>

<EmployeeName>Jowne Good</EmployeeName></User><TimeStamp>12/20/2000 13:45PST</TimeStamp><ServiceType>

<STN>purchasing</STN><ServiceAction sequence =1 decisionMaking=“no”>

<SAN>StoreService<SAN></ServiceAction><ServiceAction sequence =2 decisionMaking=“yes”>

<SAN>ERPService<SAN><AvailableDecision>3</AvailableDecision><AvailableDecision>4</AvailableDecision>

</ServiceAction><ServiceAction sequence =3 decisionMaking=“no”>

<SAN>PrinterService<SAN></ServiceAction><ServiceAction sequence =4 decisionMaking=“no”>

<SAN>ManagerWAPClientService<SAN></ServiceAction>

</ServiceType></ServiceScenario>

Figure 7. XML file for service propagation scenario.

A SERVICE MANAGEMENT FRAMEWORK 207

services without reconfirmation. Three, the file can be savedfor documentation purposes.

A service propagation scenario is passed through a chainof services and involves dynamic creations of serialized Javaobjects. We called this object the service propagation object.Therefore, for the return value back to a WAP client proxy,we would return the “Store Service Proxy Object” (since thisis the first sequence of a “purchasing” service type) and theservice propagation object that we had just created. This Java-based service propagation object is what is passed through achain of services. As a result, the framework would facili-tate the interactions with all the service proxies. Readers maynote that an “AvailableDecisions” element needs to be trackedwithout hard coding the values in it. It is done through trans-forming an XML file into a software object. In this way, wecan utilize any regular programming structure “such as if–else” to find the appropriate services to perform during runtime.

4.3. Scenario walk-through

The design of the framework can be better understood basedon a scenario. The scenario gives us a chance to examine var-ious operations and put us in a proper perspective, using ap-propriate technologies in conformance with the componentsinvolved. As mentioned earlier, this m-commerce frameworkshould be flexible enough to handle non-trivial, multi-serviceactivities. Therefore, in our implementation scenario, we willtry to simulate the use of the mobile phone with a budgetchecking system.

Here is a typical scenario. An employee has a certainamount of budget that he/she can spend and this informationis saved in a ERP budget checking system. When the em-ployee wants to purchase something, the purchase request issubmitted and processed through the ERP system. If the pur-chase amount is within the employee’s budget limit, the sys-tem simply logs the requests and grants the purchase request.However, if the purchase amount exceeds the budget limit,the request will be denied, and the employee would need toget his/her supervisor’s approval for it before any subsequentactions can be taken.

With the proposed m-commerce framework, the above sce-nario can be greatly automated and simplified to improvethe overall system efficiency. Figure 3 shows how an m-commerce framework can be constructed by using the threecomponents described and the interaction among them.

In figure 8, to focus on the service propagation aspects ofthe implementation, the figure does not include the interactionof the discovery and join between services and JINI. In otherwords, the initial setups of the framework including servicelookup are already completed. There are two WAP phoneclients, one representing an employee who makes a purchaserequest, and a manager. Assume that both clients have loggedin successfully.

There are 17 steps involved in using this prototype sce-nario:

1. An employee sends a WML request that contains a username and a password via a Servlet (which is hosted bythe WAP server), requesting a service.

2. The Servlet gets the request and routes it to a WAP ser-vice client proxy object.

3. The WAP client sends user inputs to the personalizationengine.

4. The personalization engine invokes two activities, one torequest the user information from the user info database,and the other to get the security clearance from the secu-rity manager.

5. The security manager gets the user id and the password,performs security clearance, and generates a securitylevel for the employee.

6. If the password from the user is valid, the security infor-mation is sent to the personalization engine. Otherwise,an error message would be sent to the personalization en-gine, which in turn, notifies the user of incorrect pass-word input.

7. The personalization engine combines the user informa-tion retrieved from the database with the security infor-mation into personalized security information and for-wards it to the workflow engine.

8. The workflow engine retrieves decision rules from the de-cision rules database.

9. The workflow engine processes the information and gen-erates a service propagation file, parses it, stores it inthe service propagation database, and then generates theservice propagation Java object. The workflow enginepasses both the store service proxy object and the servicepropagation object back to the WAP service client agent.

10. The employee client gets the store service proxy and usesit to communicate with the store service to browse andpurchase product items. Notice that all activities betweenthe store service and the user interaction go through theJINI WAP service client.

11. Once the employee has finished with browsing and hasidentified the items he/she wants to purchase, a total iscomputed. The WAP service client finds out that ERPsystem service is the next stop for the workflow. It thenlooks up the ERP service and downloads the ERP serviceproxy.

12. The ERP service checks the employee’s level of clear-ance against that in the ERP system and finds the appro-priate budget for the employee. If the purchasing amountexceeds the budget limit of the employee, the ERP ser-vice would download the service proxy of a manager andthen contact the manager via the manager’s client serviceproxy.

208 SHIH AND SHIM

13. Once the manager client proxy gets the message from theERP service that the employee is requesting a purchaseover the budget, the proxy then routes that message viaNokia’s PUSH protocol and notifies the manager aboutthe purchase request. Notice that manager client is also aWAP phone user with its own WAP service client proxy.The manager will then either approve or deny the servicerequest.

14. If the purchasing amount is within the budget limit of theemployee, JINI printer service will be called and a receiptof the purchase would be printed out in a printer.

15. The printer service then notifies the transaction managerthat the whole transaction is completed.

16. The transaction service notifies the log activity managerto log this transaction.

17. The log activity manager saves the transaction into thedatabase.

In the above scenario, the log manager is active all the timeto record the various activities through out the transactions.Besides, printing a receipt for a transaction when the transac-tion is completed, the log manager can also request a periodicoutput from the printer service to check the activity status inthe framework. If any of the services fails during the chain ofservice executions, the transaction manager will try to recoverthe failed service. If a transaction cannot be recovered, a noti-fication of transaction failure is sent back to the user, and thefailed transaction is aborted.

5. Implementation and issues

5.1. WAP service client component

The WAP service client consists of three parts: the WAP en-abled mobile phone, the WAP Server, and the service proxyagent. A simulated Nokia 7110 phone from the Nokia WAPToolkit was used as the client and the Nokia WAP serverversion 1.1 [10,11] is used for the WAP server implementa-tion. The WAP server combines the features of a WAP gate-way and a web content server. Therefore, no separate WAPgateway was needed. The Nokia WAP server also providesa simple PUSH protocol that we also use in our frameworkimplementation to provide notification feedbacks to a user.An issue with a WAP service client was that we had to useWAP 1.1 because the trial version of the WAP server did notsupport WAP 1.2. In addition, we had to use the 7110 sim-ulated phone, and not the blue print phone from the NokiaWAP Toolkit because the Servlet hosting capability of a WAPserver is only available for the 7110.

5.2. Wireless service component

In this implementation, the wireless services consist of theJINI ERP service, the JINI store service, and the JINI printerservice. Because our focus is on how the framework can be

implemented to manage a collection of services, rather thenon how one particular service is implemented, the servicemodules in our implementation are designed to be simple todemonstrate the integration aspect of our framework.

The JINI ERP service is a software module that simulatesa budget checking system. Methods are provided to checkwhether or not the employee who uses the purchasing trans-action has the appropriate budget for his/her purchase order.The inputs for this service are the user id and the purchaseamount. The output is the appropriate sequence of servicepropagation. If the purchase amount is less than the budgetlimit, this service continues to the printer service. However,if the purchase amount is greater than the assigned limit forthe employee, the JINI ERP service would find the managerof the employee, and notify him/her of the purchase request.In this case the ERP service spawns a thread to contact thewireless client proxy of the manager’s mobile device.

The JINI store service is a virtual shopping store with var-ious product listings and prices. This service provides themethods for product selection and the interaction between themobile device user and the store products. It also containsmethods to calculate the final purchase price and to gener-ate the purchase order for the mobile device user. The JINIprinter service is a software wrapper that enables the attachedhost printer to be part of the JINI Federation. The Printerservice acts as the gateway between the JINI world and theprinter device. It provides methods to connect to printer forprinting out hard copies of the purchase orders. The proto-cols for how these services can join the JINI platform andtheir services can be used are discussed in the next section.

5.3. JINI service management engine component

The JINI service management engine uses version 1.0.1 ofthe JINI specification. All the services join the JINI ser-vice management engine via the discovery and join protocol.For any service to be considered as a JINI service, an inter-face first needs to be written for that service. The interfacebasically defines what operations its client is to use. Oncethe interface is defined, a service proxy needs to be written.The service proxy is what gets downloaded to the client thatwishes to use a particular service. The service proxy itselfcan be implemented many ways, but the important thing isthat it needs to implement both the service interface, and thejava.io.serilizable interface. In fact, JINI 1.0.1 specificationrequires every JINI service to implement this interface so thatthe service proxy can be saved to a byte stream, sent to aremote system, can be constructed at the other end. It guaran-tees the remoteness of the service. The service proxy alsoneeds to implement the business logic of the methods thatwere defined in the service interface.

Once the service proxy and the interface is defined, theservice can perform lookup by using the LookupDiscoveryQto create a new LookupDiscovery object which can be usedfor the service discovery and registration for a new service.The discovery and join protocol provides a ServiceRegistra-tion object by which the services can specify what the service

A SERVICE MANAGEMENT FRAMEWORK 209

Figure 8. Prototype scenario walk-through.

210 SHIH AND SHIM

name is as well as how long the leased time should be. Once aservice is registered, the client can perform lookup service tolocate the requested service and download the service proxyinterface. The ServiceRegistration object returns a globallyunique service ID of the service. This ID is captured in thedatabase for later use. The database service, store service,ERP service, the printer service, and WAP service all joinedthe framework using this discovery and join protocol.

As we discussed earlier, the JINI service management en-gine component consists of seven main areas, the databaseservice, the personalization engine, the workflow engine, thesecurity manager, the transaction manager, the log manager,and the decision rules generator. The JINI database serviceis a JINI Wrapper for a JDBC application. A JDBC applica-tion is a Java interface for a traditional Database. The JINIdatabase service client searches the Lookup service for ob-jects that implement the database interface and downloads thedatabase service proxy. The interface includes methods to beused to access the database information. In our prototype im-plementation, this database service stores JINI service infor-mation, activity logs, decision rules, service propagation sce-narios, user personal information, and security information.

The personalization engine, workflow engine, securitymanager, and log manager are parts of the service manage-ment engine. These modules are software modules that im-plement the necessary business logic to help manage the dif-ferent operations and services. The personalization engine isthe entry point for mobile device clients to enter the JINI ser-vice management engine. It is a software module with meth-ods to interact with the client service proxy as well as meth-ods for first checking user id, and then invoking the securityhandler module, and finally, forwarding the user informationto the workflow engine. The personalization engine uses theprogramming interfaces provided by the database service toretrieve information from both the personal information data-base tables as well as the security database table. The work-flow engine provides methods to take all the information fromdifferent business logic software units and consolidate them

into a service propagation object. First, it accepts the outputof the personalization engine, which is a personalized objectthat contains user id and security level. Second, it uses meth-ods to extract information from the decision rules database.Third, based on the inputs from personalization engine andthe decision rules database, the workflow engine generatestwo objects: one, a specific Java serializible service propa-gation object to be sent back to the client service proxy, andtwo, a service propagation scenario to be saved back into theservice propagation database.

The security manager is a software unit to check the secu-rity information of the user. It takes the user id and the pass-word that the user enters and compares those against the in-formation saved in the security database. If the user id and thepassword are correct, the “check” method in the security han-dler would return true to the personalization engine, signalingthe user has logged in successfully. On the other hand, if thepassword is incorrect, the “check” method would return falseto the personalization engine which would prompt the user totry again. The log manager is the module that provides meth-ods to record and log transaction information of the servicepropagation sequence. Every service or sequence of opera-tion would invoke the “Log” method the log activity managerto write the timestamp, the service results and user informa-tion to a log file. The log file would then be saved into thelog activity database after the whole transaction is completed.The decision rules generator provides methods to take a user-defined XML file (based on the DTD described in the designsection of this paper) as the input, parses through the XMLelements, and saves the parsed information into the database.IBM parser API is used for XML parsing in our implemen-tation. The transaction manager in our implementation hasbeen taken care of by the JINI transaction model. The JINItransaction manager keeps a list of transaction participants,which in our implementation, are the services involved in aservice propagation scenario. The JINI transaction managersimply makes sure that all service sequences are completed,or otherwise the purchase transaction is not successful.

Figure 9. WAP and JINI layer interaction.

A SERVICE MANAGEMENT FRAMEWORK 211

The biggest challenge in implementing service manage-ment components was in interactions of a WAP client proxyand a JINI service. As mentioned earlier, the design goal wasto create an abstraction layer between the JINI service engineand the wireless clients. The purpose is to allow our frame-work to be flexible to accommodate any mobile devices aslong as they provide the appropriate service proxy interfaces.In our implementation of the wireless client, since the WAPand WAP server are used, it means that on one hand, our clientproxy would need to deal with the WAP server interface, andon the other hand, route the request from the wireless clientsto the JINI network. The WAP and JINI abstraction layer in-teractions are illustrated in figure 9.

In figure 9, there are two WAP clients each issuingWML/WMLS requests to a WAP Servlet. By receiving therequest in the DoGetQ method of the Servlet, the Servletspawns a thread for each of the request and passes the user re-quest to the newly spawned thread. Each of the thread wouldcreate a new client service proxy object that becomes the in-terface between the WAP Servlet and the personalization en-gine (which is the entry point for the service management en-gine). Notice that after the client service proxy is created theactual user request is sent to port 9999, which the person-alization engine listens to. The actual data communicationprotocol is done via RMI. Once the data is passed to the per-sonalization engine listening on Port 9999, the request wouldbe processed following the necessary protocol described inthe design section of this paper. The WAP clients are totallyabstracted from the JINI-related services and vice versa. Ob-vious, to pass data back to the wireless client, the reverse routewould be taken.

Several improvements could have been made in our im-plementation. For example, we simulated an ERP system butan actual ERP system such as the SAP’s ERP system couldbe included to closely replicate an actual framework. Theother improvement would be adding support for disconnectedservice transactions because mobile devices may are prone todropped calls and lose connections temporarily during servicehandoffs.

6. Conclusion

There is no doubt that the growing number of mobile phoneusers will demand more comprehensive and complicated m-commerce transactions than the applications that only pro-vide data exchange capabilities. Personalized wireless ser-vices may dominate the market of wireless applications. WAPpresents a common standard network protocol stack, whichfacilitates the interoperability of different wireless networksand devices as well as an application environment, whichprovides a guideline for the development of wireless appli-cations. However, in order to manage complex transactionsthat might require sequence of several services executingfrom different network computers, WAP is not sufficient. Anm-commerce management framework is needed to ensure ser-vice integrity and quality. We have proposed a JINI-based

framework that acts as an intelligent service framework toseamlessly connect all services that have joined the JINI com-munity. Leveraging the portable nature of the Java languageand the remoteness nature of RMI, JINI is a dynamic and flex-ible distributed network application infrastructure built withnetwork computing issues in mind. JINI allows the servicesto self-manage themselves, thus ensuring the robustness ofthe framework. The workflow engine and the service propa-gation concepts presented in this paper are essential in routingand implementing the complex m-commerce transactions.

Sun Microsystem is pushing JINI for device connectivity,and the embedded version of Java is readily available. Evenwithout running Java Virtual Machine on a mobile device, wehave shown in this paper that JINI can be the infrastructurefor m-commerce. In fact, phone clients deal only with WMLand WMLS, and the implementation of the Java based JINIplatform is totally abstracted from a phone client. Hence, themanagement framework based on JINI is not only connect-ing mobile devices but also providing commerce transactionservices combined with backend applications. Without suchan infrastructure support, m-commerce cannot realize its fullpotential.

References

[1] C. Arehart and N. Chidambaram, Professional WAP (Wrox Press,2000).

[2] B. Brewin, Mobile Commerce (October 23, 2000) http://www.computerworld.com/cwi/quickstudy/by_keywords/0,1080,NAV47-68-85-98-309,00.html

[3] Cellular Telecommunications Industry Association, CTIA’s semi-annual wireless industry survey, Wow.com (December 1999) http://www.wow-com.com/statsurv/survey

[4] ClickService.com, ClickService.com unleashes a new web portal forwireless Internet, Wow-com (25 February 2000) http://www.wow-com.com/newsline/press_release.cfm?press_id=990

[5] Cyberatlas.internet.com, Mobile commerce frustrating many earlyusers, http://cyberatlas.internet.com/markets/wireless/article/0,,10094_513431,00.html

[6] W. Edward, Core JINI (Sun Mircosystems Press, 1999).[7] I. Fried, As the wireless world turns, CNET News.com,

http://www.canada.cnet.com/news/0-1006-200-3709118.html

[8] D. Haskin, Mobile heavyweights vow common mobile e-commerceframework, http://devices.internet.com/industry/news/2000/04/12/mobile_heavyweights.htm

[9] JINI.org, JINI 1.0.1 specification, http://www.jini.org[10] Nokia Corporation, Nokia WAP Toolkit Developer’s Guide Version 2.0

(June 2000).[11] Nokia Corporation, Nokia WAP Toolkit Designer’s Guide Version 2.0

(June 2000).[12] Object Management Group, CORBA specifications, http://www.

omg.org/technology/documents/formal/index.htm[13] M. Oliphant, The mobile phone meets the Internet, IEEE Spectrum

(August 1999) 20–28.[14] Sharma and Chetan, Wireless Internet Enterprise Applications: A Wiley

Tech Brief (Wiley, 2000).[15] Sun Microsystems, Java remote method invocaton, http://java.

sun.com/j2se/l.3/docs/guide/rmi/[16] Sun Microsystems, Java Servlet technology, http://java.sun.

com/products/servlet/

212 SHIH AND SHIM

[17] Sun Microsystems, Java native interface, http://java.sun.com/products//jdk/l.2/docs/guide/jni/index.html

[18] The Strategies Group, http://www.strategiesgroup.com[19] M. Van Der Heijden and M. Taylor, Understanding WAP: Wireless Ap-

plications, Devices, and Services (Artech House, 2000).[20] U. Varshney, R. Vetter and R. Kalakota, Mobile commerce: A new

frontier, IEEE Computer (October 2000).[21] WAP Forum, WAP 1.1 specification, http://www.wapforum.

org[22] W3C, Extensible Markup Language, http://www.w3.org/XML/

Gary Shih received M.S. from San Jose State Uni-versity in computer engineering and B.S. from CalPoly, San Luis Obispo in industrial engineering. Heis currently working as a software engineer at Fu-jitsu Network Communications. His research inter-ests include mobile commerce, mobile communica-tions, and network management systems.

Simon S.Y. Shim is an Associate Professor in Com-puter Engineering Department at San Jose State Uni-versity. He received B.S. from Rochester Instituteof Technology, M.S. from Rensselaer PolytechnicInstitute, and Ph.D. from University of Minnesota,all in computer science. His expertise includes In-ternet computing, multimedia servers, multimediacommunications and computing, and SAN. He is aco-director of the Internet Technology Laboratorywhich is supported by grants from Intel, Microsoft,

Wytec, and Informix corporation.E-mail: sishim@email.sjsu.edu