In this section we overview the current status of mobile Web Services, which requires low bandwidth and efficient message processing compared to conventional and wired distributed computing.
2.1 Overview
Lately, Web Services on mobile devices are becoming more feasible because of technological progress in both mobile devices and Web Service. On the other hand, the performance of the mobile device is greatly improved by faster processor, larger equipped memory, and enhanced user display, and connection to the network has become easier through a widely available packet-switched 2.5G or 2.75G networks as well as through the third generation networks, which are in an early developmental stage in US. Meanwhile, the Web Service technology is getting popular as a tool to connect heterogeneous applications. Flexibility and universality, originating from the use of XML based SOAP and the ubiquitous HTTP, help integrate disparate resources over various computing environments. We expect a synergy between these two sides, creating faster and better connections. But, as described in the previous section, mobile computing is still bound by hardware and network limitations despite innovations.
These constraints – both physical and programming limitations – make it hard to adapt conventional Web Service frameworks like Apache Axis and Microsoft .NET to the mobile environment. We propose a novel Web Service communication framework providing efficient message exchange to overcome these constraints. Our discussion is
particularly focused on mobile computing environment in this dissertation, but the approach may be more general.
2.2 Offloading Computation Using the Java Servlet API
An early model of the mobile Web Services was based on a computation off-loading scheme, called the wireless portal network architecture [66] as shown in Figure 3.2. Since it is simple to implement as a proxy to mobile applications, many experiments are done using the Java Servlet API [24]. A servlet is a Java object which uses the functionality provided by a Java platform that receives HTTP requests and generates responses. Servlets are the Java counterpart to dynamic web contents technologies, such as Common Gateway Interface (CGI) and Active Server Pages (ASP). Yet, as we have mentioned, despite extensive experimentation, there still exists an API gap between wired computing and mobile computing. By using a servlet as a gateway (or a proxy), mobile application developers can build a thin Web Service client on a mobile device. The thin client makes a request with only core data. The gateway converts the data to a valid SOAP request and
delivers it to the ultimate receiver. The problem with mobile devices is that they can only run thin client applications that are not Web Service capable, which means that offloaded functionalities reside on the server where the servlet is running. This ad hoc scheme is easy to implement, so there are many projects which had followed the scheme. But this approach loses an important Web Service characteristic – interoperability. Because they are tailored to the proxy interface, ad-hoc client applications are not interoperable with other conventional Web Service participants.
2.3 kSOAP and J2ME Web Services
Recently mobile specific SOAP APIs have become available, allowing one to design a traditional Web Service architecture with mobile devices. There are two major products in the community: the first is the kSOAP [14], and the other is a specification defined by the Java Community: J2ME Web Services (JSR172) [73].
Because it provides a tiny footprint (about 40kb) and an easy-to-use SOAP library there are many mobile Web Service implementations using the kSOAP library, which is the product of an open source project, Enhydra22, led by Stefan Haustein. kSOAP is an XML-RPC based SOAP implementation. Its functionality is provided by the HttpConnection class and its call() method. Unlike traditional APIs, kSOAP and kXML together offer an efficient Web Services programming environment for the mobile device. In our own HHFR design, we use kSOAP and kXML to build a negotiation message and to parse an XML schema.
The slimmed-down library of J2ME left out essential packages for Web Services, like the Java API for XML Parsing (JAXP). The Java Specification Request 172 (JSR 172) covers the two components that are needed to implement Web services on mobile devices, but which are missing in the standard J2ME library: remote service invocation and XML parsing. JSR 172 supports SAX (Simple API for XML) 2.0 based JAXP 1.2. It also supports major Web Services specifications, including SOAP 1.1, WSDL 1.1, XML 1.1, and XML Schema. It doesn’t include UDDI (Universal Description, Discovery, and Integration) because the specification focuses on how to consume remote services, not how to provide them. In other words the Web Service API on J2ME is a client-oriented API with a JAX-RPC style runtime environment.
Both APIs provide us enough features to implement Web services on the mobile devices, but the mobile environment still does not function equivalently to the conventional computing environment. The APIs of kSOAP and JSR 172 still inherit the performance limitations of conventional Web Services. So the use of the libraries is limited to lightweight applications.