WiCom, a wireless communication API for the provisioning
                  of mobile computing over a GSM network

       ...
Introduction

While the development of sophisticated distributed applications is still a challenge, several
industrial sta...
Serv1   Serv2

                                                             JINI
                                         ...
is shown below [Fig. 2]. When the RMISocketFactory is set it loads the proper
implementation of the ConnectionFactory for ...
CLIENT                                                                  SERVER
                     Application           ...
3    Open issues

Since WiCom is still under development, the continuous data transmission feature in case of
channel fail...
(Stearns, 1997)
    Stearns, B. (1997).
    Integrating native code and java programs.
    Technical report, SUN,
    http...
Upcoming SlideShare
Loading in...5
×

1903_0.doc

219

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
219
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

1903_0.doc

  1. 1. WiCom, a wireless communication API for the provisioning of mobile computing over a GSM network Davide Carboni, Gavino Paddeu, Stefano Sanna dcarboni@crs4.it, gavino@crs4.it, gerda@crs4.it CRS4 Center for Advanced Studies, Research and Development in Sardinia VI Strada OVEST Z.I. Macchiareddu 09010 UTA (CA) - Italy tel +39 0702796303, fax +39 0702796216 http://www.crs4.it/ Abstract This paper describes WiCom, a package of Java APIs and services within the PASSION Project. The principal aim of PASSION is to develop a complete system allowing the remote consultation of multimedia documentation by maintenance operators. In this context, WiCom provides a framework for managing wireless connections over GSM network, accessing the telephony capabilities of the underlying operating system and hardware, by introducing a robust and intelligent layer in the RMI stack.
  2. 2. Introduction While the development of sophisticated distributed applications is still a challenge, several industrial standards (CORBA, DCOM, RMI …) are offering programmers a level of abstraction similar to the Object Oriented Programming paradigm. Initially conceived to enable the development of intranet and internet applications, these frameworks are built with the assumption of robust and fast network connections between the components, which actually lack in the context of a mobile environment. Since the aim of the PASSION project is to enable mobile operators to access information in a distributed wireless environment, we have faced the problem of offering an identical level of abstraction to the PASSION developers, in order to hide the fact that they actually work in a wireless context. As a solution to this problem, we have developed WiCom, a package of Java APIs for managing wireless connections, accessing the telephony capabilities of the underlying system and introducing a robust and intelligent layer in the RMI stack. After a brief description of PASSION, we will present the two main parts of WiCom: an abstract layer which allows the applications to use RMI (Sun, 1998) over a wireless network in a transparent manner, and the native layer which implements the abstract part for the Epoc32 OS and a GSM bearer. The automatic connection management performed by WiCom aims to economise the duration of the connection and to handle I/O exceptions caused by channel faults. Wireless communications within the PASSION framework 1.1 PASSION PASSION is the acronym for Portable ASSistant for Interacting Operators Network and it is one of the ESPRIT 4 (ESPRIT 1998) programme projects in the “IT for Mobility Work Area”. The partners involved are the following: Alcatel Alsthom recherche (F) (prime contractor), CRS4 (I), Matla Terminals (E), Robotiker (E), Softeco Sismat (I), HFRG - University College Cork (IRL), RINA (I),SISTEPLANT (E), SiESA (E). The overall goal of the PASSION project is to enhance the mobility and the access of maintenance operators to an ubiquitous and transparent information system, in order to help in managing operations like detecting and fixing the disruption which may occur in a widely geographically distributed system. Examples of such systems include large transportation networks like energy, telecommunication, railway or highway; sets of equipment located in various distant places like ships, cars, bus fleets or even photocopiers. PASSION is based on leading technologies like the Microsoft Windows NT, Linux and Epoc32 operating systems, the Oracle and Versant DBMSs, the Java programming language, the JINI and CORBA (OMG, 1998) distributed environments. 1.2 PASSION architecture The aim of PASSION is to develop a complete system allowing the remote consultation of multimedia documents by maintenance operators. The global system architecture is made of two different parts: the ‘nomadic’ part, to be provided to the On-The-Field Operators (OTFOs), that is a Personal Digital Assistant (PDA) with its associated software; and the Centralised Operation Base (COB), to be used by a maintenance supervisor, which mainly manages the base of multimedia documents, the maintenance support services, and the requests/updates coming from the operators. These two parts are interconnected through a wireless communication network [Fig. 1]. 2
  3. 3. Serv1 Serv2 JINI Kiosk Serv3 lookup Serv4 Serv N PAS S ION inte rnal RMI RMI OODB Renderer service service Renderer HM I service service HM I COB us e r PDA us e r Fig.: PASSION architecture. The kiosk of services is available through the Jini look-up while the peer-to-peer interaction between the objects is obtained using the Java Remote Method Invocation protocol. 1.3 Communications issues inside PASSION The architecture of PASSION is based upon Java's standard Remote Method Invocation, which relies on "wired" connections between hosts. Neither Java network API nor RMI extensions have the control of the wireless physical channel. The PASSION communication channel is a standard GSM circuit. This choice introduces some problems like connection costs and dial-out management. Since it is better for developers to disregard wireless specific topics during the design of their applications, the WiCom module tries to provide an abstraction for each topic described above. 2 The WIreless COMmunication package 2.1 Introduction to WiCom WiCom (Wireless Communication package) consists of two layers. The first one is the abstract layer where a connection model is given together with its connection factory. This layer provides the API which sets the WiComRMISocketFactory as RMI socket factory. Java applications can invoke remote methods from a PDA assuming that a connection has been set up or will be set up when needed. The design of this layer has been made taking into account the possibility to reuse it with bearers different than GSM. Thus a factory design pattern (Gamma et al.,1994) is the best choice, the WiComConnection is provided by a ConnectionFactory, they are both abstract classes and during the run time their native implementation is loaded by the JVM. The second part of WiCom consists of platform-dependent layer. This part consists in a Java package and a native library. In the actual implementation the connections are obtained as PPP interfaces over a GSM circuit and the operating system is Epoc32. If a connection is dropped, the WiCom module automatically tries to establish a new physical connection between client and server. Moreover, WiCom can optimise the use of the GSM channel hanging-up the call during silent phases of the logical connection and setting a new call when needed. The Epoc32 operating system is provided with a JVM and a telephony server. A dynamic view of the WiCom behaviour 3
  4. 4. is shown below [Fig. 2]. When the RMISocketFactory is set it loads the proper implementation of the ConnectionFactory for the underlying operating system. Now the application can use RMI in a transparent manner disregarding all the matters related to dial-up and GSM hardware. In the diagram below is assumed that the connection has still to be created and activated. RMI : WiComRMISocketFactory : Conn ect io n : WiCom : WiCom Factory Connection Socket 1: createSocket() 2: getConnection() 3: creat e() 4: setActive() 5: wait() 6: activactionEnd() 7: notify() 8: ref to WiComConnection 9 : new WiComS ocket() 10: ref to WiComSocket 11: ref to WiComSocket Fig. 2: Sequence diagram of WiCom classes 2.2 The WiCom classes The WiCom socket layer is an extension of the transport layer of the Java RMI stack [Fig. 3]. In this way WiCom is able to provide the above RMI layer with ad-hoc input and output streams specialized in handling connection failures to ensure a continuous data transmission and also capable to separate the physical connection from the logical one. 4
  5. 5. CLIENT SERVER Application Application Stub Skel Remote reference Remote reference WiCom Layer WiCom Layer Socket Layer Socket Layer IP IP Datalink (PPP) Datalink (PPP) Physical (GSM circuit) Physical (GSM circuit) Fig. 3: RMI stack with the WiCom layer A set of Java classes is provided to extend the socket layer inside the RMI stack. These classes are: • WiComRMISocketFactory A replacement of standard RMISocketFactory. WiComRMISocketFactory provides customized Socket and ServerSocket specialized for WiCom goals. • WiComSocket, WiComServerSocket Extensions of Socket and ServerSocket. • WiComInputStream, WiComOutputStream Extensions of InputStream and OutputStream. These classes implement mechanisms to handle wireless connection exceptions like buffering and data transmission recovery from the last interruption point. 2.3 WiCom under the hood WiCom is designed as an extension of the RMI socket factory. Nevertheless, its structure is generic and portable to operating systems other than Epoc by simply changing the native parts of the package. The Epoc32 operating system release 5 supports Java 1.1.4 and also provides a software development kit useful to write and test native C++ code. The client-server and object- oriented structure of Epoc DLL (Symbian, 1999) allows through the use of the JNI to write Java classes able to set-up a new call, to be notified about GSM events and to take over existing calls Implementation of the EpocConnection WiComConnection abstract class d) p o w u n ( ( ) pe rs os g( r) Internal WiCom class which provides native NetworkInterface methods SDu Pe tit rs S) aa( os t rl) g( o tO r) p ( Interface to Dial service provided by Epoc to NetDial users' applications. Fig. 4: Interaction between Java objects and native parts 5
  6. 6. 3 Open issues Since WiCom is still under development, the continuous data transmission feature in case of channel failure is still to be tested in all possible conditions. We know that today’s market leader technology is GSM but emerging technologies like GPRS (Cai et al.,1997) and UMTS are quickly growing. Therefore we must take into account this evolution to design WiCom as “upgradable” as possible to the new standards. Last but not least, some GSM services are currently available only by native serial communications, but since one of the WiCom objectives is the portability we plan to base serial I/O on Sun’s standard JavaComm API which is not yet available under Epoc. Acknowledgements The authors would like to thank Enrico Stara for his precious support during RMI specific issues development and Paola Mastromarino for providing general guidelines related to wireless topics. Bibliography (Arnold et al., 1999) Arnold, K., Wollrath, A., O'Sullivan, B., Scheifler, R., and Waldo, J. (1999). The Jini Specification, Addison-Wesley. ISBN 0201616343. (Beck et al., 1999) Beck, J., Gefflaut, A., and Islam, N. (1999). Moca: a service framework for mobile computing devices. In ACM international workshop on Data engineering for wireless and mobile access. (Cai et al.,1997) Cai, J., Goodman, J. D. (1997), General Packet Radio Service in GSM. In IEEE Communications Magazine , October 1997, pages 122-131. (ESPRIT, 1998) ESPRIT (1998). The EU information technologies programme. (ETSI, 1996) ETSI, 1996 GSM 07.07: Digital cellular telecommunications system (Phase 2+); AT command set for GSM Mobile Equipment (ME); version 5.4.0; Nov 1997, http://www.cordis.lu/esprit/ (Haahr et al., 1999) Haahr, M., Cunningham, R., and Cahill, V. (1999). Supporting corba applications in a mobile environment. In International Conference on Mobile Computing and Networking, pages 36-47. (OMG, 1998) Object Management Group (1998) The Common Object Request Broker: Architecture and Specification Object Management Group, February 1998, http://www.omg.org/library/ 6
  7. 7. (Stearns, 1997) Stearns, B. (1997). Integrating native code and java programs. Technical report, SUN, http://java.sun.com/docs/books/tutorial/native1.1/index.html (Sun, 1998) Sun (1998). Java Remote Method Invocation Specification, 1.2 edition. (Symbian, 1999) Symbian (1999) Epoc technical papers, http://www.symbian.com/epoc/papers/papers.html (Gamma et al., 1999) Gamma, E., Helm, R., Johnson, R., Vlissides, J., (1994) Design Patterns, Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN 0-201-63361-2 7

×