Section 10.5. Designing for Small Devices

10.5. Designing for Small Devices

For the foreseeable future, the design of services for small devices effectively means designing for a specific device. (For the purpose of this chapter, a small device is one with a small screen of about 150 x 100 pixels, limited processing power, memory often far less than 256kB, and limited data entry support although with a capability to create network connections to facilitate participation in an SOA.) One of the most important points is that the interaction pattern must match the capabilities of the device. Rich interaction patterns for different classes of applications often fail with small devices because of the physical characteristics of the device and also because of additional cost and longer interaction time for the user imposed by these patterns. Because network connectivity might be at a premium, the service implementation itself will usually be as lean as possible to minimize latency.

It is likely that security will be limited to mostly transport security because processing power and available memory might not allow for the encryption and signature of messages as defined in Chapter 9.

Although J2ME MIDP 2.0 supports transport security using HTTPS, there is no support in version 1.0. This means that you must use some other means to prevent passing extensive credentials between server and client. Authentications can be performed in ways such as using the telephone number, using username/password, or using certificates stored in the client. Although using the telephone number might seem like the best scenario, there are a number of reasons to avoid it.

For security reasons, runtime of environments such as J2ME MIDP do not enable access to telephony functionality, including the phone number. Furthermore, unless the delivery path is controlled, the potential for abuse of the telephone number for authentication is very high, both because it is easy to tamper with and because it is basically a public number that can be readily obtained. However, the phone number can be an excellent means of authentication when using SMS-based services, as we discuss at the end of this chapter.

One way or another, this information will be stored persistently at the client. This is mandatory due to the limited data entry support on small devices. A requirement to repeatedly enter a username and password with a clumsy keyboard obstructs usability. Alternatively, it is possible to envisage interaction without the user actually logging in to the system at all. The invocation might be triggered by a unique ID such as a reservation number.

Lightweight Security

Security features often require rather large computational and memory resources. Use only security measures that have little impact on both the device and the user.

Some small devices can use SOAP (or even CORBA) for remote invocations. However, you must carefully consider whether this is a good idea. For example, SOAP requires resources at almost every level of the small device, and a significant amount of processing power and memory is used for XML parsing. In addition, SOAP libraries that are not native to the device must be bundled with the application, which often increases the size of the application beyond what is possible for the target device. When using SOAP, you must also take into account that the specification is still evolving. Because implementations for mobile devices lag back behind the current standard, often by more than a year, it is unlikely that a state-of-the-art small device can properly address state-of-the-art SOAP services in the organization.

Therefore, it is sensible to decouple the service invocation in the device from the actual service using an adapter that resides at a gateway server. This setup enables the client to connect to the service using the least common denominator in technology, usually connecting using HTTP or HTTPS. Ifas with MIDP 1.0only HTTP is available, the server can establish a session that prevents the repeated passing of users' credentials over the wire. The session token (or login token) can be stored in the SOAP header or can be sent using a SOAP parameter. In the authors' experience, moving from lightweight J2ME SOAP implementations, such as kSOAP, to a HTTP-POST style interaction can reduce the client size by approximately 20kB. Given that the footprint allowed by J2ME MIDP Midlet Suites can be as low as 64kB or less, this is effectively a huge reduction in size that in turn creates the opportunity for a of richer and more user-friendly application.

Minimize Resources for Communication

In small devices, use resources for the application rather than the communication. It is better to create a protocol translator on the server side than to withhold functionality from the customer due to resource constraints.

In the check-in example, most users will not be ready to select the seats using a small screen and a hard-to-handle keyboard. Using a small device, it is more likely that the user will check-in right away after the proper flight coupon has been selected. Because interaction using mobile phones is somewhat cumbersome, it might even be possible to check in by simply typing the coupon number for which to perform the check-in and hitting "continue." A typical interaction scenario is shown in Figure 10-11. In this example, this process is achieved by eliminating the need to query the customer service and the caterer. Note that service granularities used by small devices tend to be coarser than services used by Web applications.

Figure 10-11. Typical service interaction using a small device.

As we discussed previously, there are various ways to authenticate the user. In the check-in example, it is hard to board the plane without being the actual ticket holder. Thus, it is possible to check in a single flight coupon based on an ID that is printed on the coupon, as illustrated in Figure 10-12. In such a scenario, only the person holding the physical flight coupon can perform the check-in.

Figure 10-12. Check-in using a mobile device. In this example, the check-in is performed solely using the coupon ID.

An alternative scenario with a richer interaction pattern is shown in Figure 10-13. It uses a Web application to store some conversational state, and in the example, this is leveraged to reduce latency for the actual check-in call. To that end, just after login, it dispatches an asynchronous request to the potentially costly operation that obtains the customer's of preferences.

Figure 10-13. Using a proxy Web application as a service proxy. As with Web applications, the proxy can be used for state aggregation. It can also dispatch some asynchronous calls, such as requesting a certain type of meal, to reduce latency within the actual check-in calls.

When targeting mobile phones, it might also be an option not to actually install the service on the mobile phone. Mobile phone technology supports options such as short message service (SMS) or its succeeding technology, multimedia message service (MMS), that can also be used to connect to a service. To check in, the user can utilize the coupon number on the ticket along with a dedicated telephone number for checking in. An immediate advantage might be that the user can be uniquely identified using his phone number. However, this communication model has certain security restrictions, although it might well be the best option for deploying consumer services such as multiplayer role playing games or dating services (see Figure 10-14).

Figure 10-14. Engaging a service using an SMS proxy. This can provide a cleanyet potentially insecureway to identity the customer.

Due to their coarse-grained structure, services that are used from small devices are an excellent option for other usage scenarios whenever some resources are at a premium. An example is a check-in terminal that needs to function using limited network connectivity.