A Web Services-based System for Ad-hoc Mobile Application Integration Robert Steele University of Technology, Sydney PO Box 123 Broadway NSW 2007 Australia 61-2-9514-7872
[email protected] Abstract As mobile devices become more powerful and common there will a greater capacity and need for more complex interactions between mobile device-resident software and other server-based software. This can be termed mobile application integration. Mobile computing introduces new opportunities and challenges for application integration. Some of the challenges include small device size, limited bandwidth, limited processing power and lack of integration protocol support. Ad-hoc networks are those that can be formed temporarily while particular devices are in the vicinity of each other and ad-hoc mobile application integration refers to the temporary integration of software modules across devices while such a network exists. This case poses even greater challenges for integration such as dynamically changing combinations of platforms to be integrated across and a requirement for integration to occur dynamically. This paper proposes a novel Web Servicesbased system that allows such dynamic and temporary integration to occur in ad-hoc mobile networks.
Keywords Web Services, mobile, wireless, enterprise application integration, SOAP, pervasive computing, ad-hoc networks
1. Introduction Currently many mobile devices have relatively low processing capabilities, low memory, restricted user interfaces and have access to limited bandwidth. Accordingly, the software on many of these devices is small and has limited functionality. However as hardware advances occur and higher bandwidth communication is made available, mobile device software will become more complex. In addition there will be a greater demand for complex communication between software on different devices and with the rest of the world’s land-based systems. Complex machine-to-machine interactions in this case would require mobile application integration. Furthermore new technologies such as Bluetooth [3] are providing a new capability for networks – namely adhoc networking. Such networking involves the dynamic and
temporary creation of a network while wireless devices that can communicate with each other are near each other. Complex machine-to-machine interaction between different mobile devices and with non-mobile devices that make up such a temporary network is particularly challenging to achieve. This ad-hoc mobile application integration will require communication to be enabled dynamically, need to work across a large number of platform combinations and will have a large potential for semantic mismatch between communicating software. XML (eXtensible Markup Language) Web Services have a number of characteristics that are well-suited to addressing these problems. Namely they provide a completely platform independent format for representing a programmatic interface, they provide a mechanism for service discovery that has some semantic power and fundamentally they represent a mechanism for distributed communication. Web Services are often characterized in simple terms (not entirely accurately) as providing a way of doing remote procedure calls over HTTP. In particular they use the Simple Object Access Protocol (SOAP) [7] to pass parameter values and return values across the wire in an XML format. This paper proposes a Web Services-based system for achieving ad-hoc mobile application integration. This system addresses the problem of allowing a mobile device to autonomously gather information about its surrounds via discovering and accessing standard XML-based services available in its vicinity. The structure of the paper is as follows. Section 2 provides a background to existing work. Section 3 outlines the advantages and disadvantages of using Web Services in addressing this mobile computing problem. Section 4 sets out the proposed system and Section 5 provides the conclusion.
2. Background There is emerging work being done in this area by academic researchers and by industry. This section will provide a brief summary of this work and indicate how the work in this paper relates to it.
2.1 Web Services Standards SOAP provides the basic messaging format for Web Services-based communication. Just as other distributed programming technologies provide a language independent wire format, so do Web Services – XML. This is obviously a textual format as opposed to the binary formats used by such technologies as CORBA and Java RMI. Web Services Description Language (WSDL) [11] provides the standard for describing services. Universal Description, Discovery, Integration (UDDI) [9] provides the ability to do service discovery. It provides a standard for a registry of available services containing WSDL descriptions and other descriptive information. It provides mechanisms for searching for services in the registry. Private UDDI registries are smaller registries conforming to the UDDI standard but not globally accessible. Business Process Execution Language for Web Services (BPEL4WS) [6] provides a further XML format for describing how to compose services together i.e. it allows the describing of workflows.
2.2 Mobile Computing Technologies such as Bluetooth enable what are called Wireless Personal Area Networks (WPANs). Bluetooth has a range of between 10 to 100 meters and allows ad-hoc networking. 802.11 (Wi-fi) has a range of around 100 to 150 meters and can also support ad-hoc networking. Substantial research into the network layer issues of ad-hoc networking has been carried out [4]. This paper will instead concentrate on the application software layer. Mobile communication standards such as these above make use of access points. Access points allow mobile devices to wirelessly connect to local networks or the Internet. IBM, Nokia and Microsoft [8] have only recently begun to make available software and development kits to enable mobile devices to act as Web Service clients. This illustrates that there is currently a lack of technological support for hosting Web Services on mobile devices even though this is a likely future development. The following are seen as three types of mobile integration architectures [12]: • Wireless Portal Network. In this scenario there does not need to be the capability of hosting Web Services client code at the mobile device but rather communication happens for example via a WAP gateway. A request is embedded in a WML message and when the portal/ gateway receives this message it is translated into a SOAP request. Once the response from the “real” Web Service is received by the portal it translates the result back into WML and sends the result back to the mobile device. Advantages are low setup effort and minimal processing at the mobile device.
Disadvantages are that it requires a central authority with control over user data, there is a central point of failure and message-level security protocols can not be supported. • Wireless Extended Internet. This is the case assumed for the system proposed here. This scenario allows the mobile device to act as a real SOAP Web Service client. All communication is XML-over-HTTP and a TCP/IP connection can be set-up from the mobile device. • Peer-to-Peer. In this scenario a mobile device can itself host a Web Service. This scenario while interesting will not be addressed in this paper.
2.3 Service Composition Service composition refers to putting together calls to a number of services so as to achieve some larger task. This could for instance involve passing the value returned from one service as an input parameter to another service call. Composition can be done either statically or dynamically. One of the critical issues in this area is service discovery [4, 5]. In particular many service discovery systems such as JINI [1], UPnP [10] amongst others use syntactic matching to discover a service. This obviously has important limitations to being able to discover services that may be needed to be used in a composition. For example one service might be FlightTimeRequest and another FlightScheduleRequest. Such services may carry out exactly the same function but a composition system that matches on a syntactic basis may not be able to determine this.
3. Advantages and Disadvantages of Web Services for Mobile Application Integration 3.1 Advantages The following characteristics of mobile devices make Web Services a well-suited technology. • Heterogeneity. There are a very large range of mobile device and access point platform combinations. Web Services are particularly well-suited to providing an interface that is platform independent. • Low Processing Power. Mobile devices may have very low processing power. Web Services allow for an application to be located at a non-mobile server, processing to be done there and for results to be retrieved to the mobile device and simply displayed there. • Low memory. The low memory capacity of mobile devices makes the storage of a large number of programs on devices potentially not possible. Web Services once again allow for applications to be instead resident on a remote server. These can then be called on a per-needs basis alleviating the need for an extensive software library on the device itself.
• Ability to compose custom services. It may be possible to link interface triggers such as buttons to very specific services provided from remote servers.
3.2 Disadvantages The following characteristics of XML are negatives for its use in mobile computing.
being aware if services are available. Interactions between the mobile device and the server now involves further Web Service calls (as set out in Section 4.2) either in response to a direct user input or carried out autonomously. Figure 2 shows the communication process for a mobile device coming in range of an access point/ server.
• Need to process XML. Due to the very limited processing power of mobile devices this itself can pose a problem. • Verboseness of XML. XML and SOAP are far more verbose than some formats used. Their verboseness is particularly a problem over mobile networks where bandwidth can be limited. • Lack of mature standards. Some of the Web Services standards lack maturity and various other needed domain-specific standards do not yet exist. This paper will address one such area of standardization. • Support for transactions. The protocols are still emerging in this area.
4. Proposed System Based on the analysis above, Web Services appear to provide a powerful mechanism for mobile application integration particularly in light of their strong platform and vendor independence. In particular they provide a comparatively strong basis for implementing ad-hoc mobile application integration. Below the proposed system is outlined. The basic client-related architecture is shown in Figure 1. When a Bluetooth or Wi-fi enabled device enters an area within range of a corresponding wireless access point/ server it will make a request to a standard “well-known” bootstrap service (named BasicServiceListRequest) at the access point to get a summary of what services are available. The nature of this summary is as described in Section 4.1 below. The access point/ server would be hosting a private UDDI registry as a back-end to satisfy such a request and to store descriptions of all services offered from this access point. Once this information has been retrieved the mobile device will be able to determine what information it can obtain either preemptively or in response to a direct request by the mobile device user. The mobile device in fact can be configured to display a new set of icons to represent the types of standard services now available from the network in the vicinity of this access point. For example, icons for Entertainment, Food, Shopping etc. might now be displayed and an alert given to the user to indicate that new services have been detected in the area. For user initiated interactions, it is important that this happens: there is no point in a user searching for a type of service that is not available in this particular area or not
Figure 1. Mobile devices communicate with server at wireless access point when in range.
4.1 Standards The base layer of standards is provided by SOAP, WSDL, UDDI and BPEL4WS. However a key part of the proposed system is a set of standards for standard local services that would be used to describe what is available at many different locations. These will take the form of WSDL descriptions. There is not scope in this paper to exhaustively identify these standards only to indicate their broad nature. In designing the standards firstly a set of broad human-centric “service types/categories” would need to be identified. These should be identified from the perspective of the needs of a roaming mobile device user. These broad categories might be such things as: Entertainment, Traffic Information, Food, Warnings etc. To identify the exact set of standard operations/ services to be available in each particular category a more extensive process would need to be followed. Factors to be considered would be: • Which set of services, for common use-cases minimizes the number of service calls required, mobile device processing required and the amount of network traffic. • Identification of a set of services that are simple but are also adequately expressive. The set of standard services decided upon would have corresponding WSDL documents created for them along with documentation. Example operations (methods) for the Food category might include such things as FoodProviderList where a food type is an input parameter, ProviderDistance where a given shop name is an input parameter, and ProviderDirections where once again shop name in an input parameter.
The reason Web Services are well-suited to this system is that for example a Mac or Windows 2000 server could equally well host a FoodProviderList service that would have the same interface on both. Likewise an identical call to FoodProviderList could be generated by a Nokia phone, a Palm Pilot m105, a Windows CE based device or a laptop. The server would experience the request in a way independent of what mobile device generated it. The mobile device would be unaffected by what platform the server in a particular location ran on. 1. BasicServiceListRequest
2. BasicServiceListResponse 3. Display basic services found 4. FoodProviderListRequest( hamburger) (opitionally) e.g. (user initiated or automated) Food, Entertainment, Warnings 5. FoodProviderListResponse ( [Hungry Jacks, Joe’s Burgers]) 6. Potentially further requests are made e.g. to retrieve provider locations (either user initiated or automated)
Figure 2. The mobile device carries out a dialogue with server via standard XML Web Service requests.
4.2 Client agent Whereas the client can be fairly “unintelligent” there is also obviously strong potential benefits in having an intelligent agent on the mobile device that learns based on the user’s past activities what services to call and when. This is a complex area for further research but will only be addressed briefly here. On the simplest, but still fairly complex level this agent will need to be able to determine what services to call to satisfy direct user enquiries (from a fixed and limited set of options). For instance the mobile device software may offer the ability to select a desired food type. The client will then construct a service call to the appropriate food related service and return the result to the user. In this scenario the benefits of using XML Web Services are not particularly pronounced. This is because the food search interaction is something that could have been fairly similarly achieved by a WML-based search form and a browser or microbrowser. Another case justifies the use of XML Web Services more strongly. The agent may be aware of the user’s preferences e.g. for a particular type of food and the user may have potentially pre-indicated that they are actively looking for such an item. In this case whenever the moving user passes into a new locale and a new Food service category is detected the agent can query the corresponding services to determine if the sought food is known of. If it is, the user can be notified. If it is not then the user will not be interrupted and the client will continue to check for it at
future locales. If Web Services were not being used and instead a WML microbrowser approach, this “behind the scenes” searching would not be possible as a search would have to be initiated by a user action and the results manually examined by the user to determine if the desired item had been found. Via the use of XML in this case the returned food results can be machine-processed to determine without user intervention whether a match has been found. A further more complex case is where automated service composition is required to satisfy a user’s direct or implicit request. In this scenario the use of Web Services becomes more strongly justified again. That is if multiple service requests are required then if the device had only a microbrowser then this would involve the user making a number of page requests, possibly accumulating and having to note information in the process of satisfying their information need. This may well be bandwidth inefficient but will certainly be relatively inconvenient for the mobile device user. Automating the process of going to multiple WML-based pages and extracting information could not be done with simply a microbrowser. This is a scenario where Web Services would offer significant advantages. The problem of automated service composition in general and service composition in ad-hoc mobile networks has received some attention [5]. This paper introduces the novel approach of basing this on Web Services standards and Web Services description and discovery technologies. Automated composition requires service discovery. Service discovery in this case will be carried out by making use of Universal, Description, Discovery and Intergration (UDDI) instead of using other technologies such as Jini and UPnP. This has the advantage that the service descriptions are richer via the WSDL description and the service information and categorization that will be stored in the UDDI registry. Determination of how to compose services together will also make use of Web Services standards. In particular the WSDL description will incorporate use of BPEL4WS. This standard provides new tags with which to augment WSDL service descriptions so as to describe how a particular service can be called in composition with others. This information can be used by the agent to realize what other services need to be found, called and how to compose these calls together.
4.3 Servers Service servers will be associated with wireless access points such as Bluetooth or Wi-fi access points. These servers will typically be a shared broker for multiple shops/ organizations in the area. The server will need to have several components.
• Private UDDI Registry. The repository of service descriptions and how to access services will be stored in the private UDDI registry. This will act as a backend to the “bootstrap” services. • Service implementations. Many of the service implementations will reside at this server and will be able to be called by mobile devices from this location. These implementation will typically access a backend database containing information provided by shops and other organizations. The UDDI registry could also list services available on the broader Internet. • Content provider interface. When a service server is shared by multiple businesses there will need to be a way for these businesses to access it remotely and upload their information. This interface could be provided as a Web interface, a Web Service interface or both. The Web interface would provide a data entry template for businesses to enter information about their products or services for instance. The Web Services interface would provide a set of operations to populate records with the same information. The Web Service interface would allow businesses to integrate and automate the updating of information at the server.
5. Conclusion In conclusion this paper proposes a novel system for ad-hoc mobile application integration. This is an integration problem with significant difficulties. This paper adds some weight to identifying the appropriateness of adopting Web Services for such a system. The proposed system would allow standard information services to be accessed as a user passes into the vicinity of any number of wireless access points and for these services to be uniformly available to any mobile device regardless of its type and platform. The system allows for both retrieval of information in response to a user request or for an autonomous dialogue between the mobile device and the local services.
6. References [1] Arnold, K., Wollrath, A., O’Sullivan, A., Scheifler, R., Waldo, J. The Jini Specification. Addison-Wesley, Reading, MA, USA, 1999.
[2] Benatallah, B., Dumas, M., Sheng, M., Ngu, A. Declarative Composition and Peer-to-Peer Provisioning of Web Services. IEEE International Conference on Data Engineering, IEEE Society, San Jose, California, Feb 2002.
[3] Bluetooth Specification. http://www.bluetooth.com/pdf/Bluetooth_11_Specifica tions_Book.pdf, February, 2001. [4] Chakraborty, D. Service Composition in Ad-hoc
Nearby businesses
Environments. Technical Report TR-CS-01-20, PhD Dissertation Proposal, University of Maryland, Baltimore County, 2001.
[5] Chen, H., Joshi, A., Finin, T. Dynamic Service Discovery for Data retrieved from businesses
Mobile Computing: Intelligent Agents meet Jini in the Aether. Baltzer Science Journal on Cluster Computing, 2001. Services available to mobile devices
Private UDDI registry
[6] Cubera, F., Goland, Y., Klein, J., Leymann, F., Roller, D., Weerawarana, S. Business Process Execution Language for Web Services (BPEL4WS), 1.0. http://www106.ibm.com/developerworks/library/ws-bpel/, July, 2002.
[7] SOAP 1.1 Technical Report, http://www.w3.org/TR/SOAP/, W3C, 2000.
Figure 3. Nearby businesses submit information to the server via a Web Service and/or Web interface.
The relationship between these parts of the system is shown in Figure 3. There are a number of reasons for having a shared access point/ server. Firstly it will reduce the cost for the businesses as they will not all need to purchases an access point. Secondly, it will lower communications overheard for in-range mobile devices. The disadvantages include such issues as businesses not having physical access to the server and a high communications load on the access point.
[8] Taft, D. IBM Delivers Mobile Web Services Toolkit. http://www.eweek.com/article2/0,3959,709560,00.asp, November, 2002.
[9] UDDI.org: Universal Description, Discovery and Integration for the Web. http://www.uddi.org. [10] UPnP White Paper. http://upnp.org/resources.htm. [11] Web Services Description Language (WSDL) 1.1. http://www.w3.org/TR/wsdl. [12] Yuan, M.J., Long, Ju. Java Readies Itself for Wireless Web Services. http://www.javaworld.com/javaworld/jw-062002/jw-0621-wireless.html, June, 2002.
