IBM Workplace Client Technology Micro Edition Version 5.7.1: Application Development and Case Study

Chapter 2. The Case Study: ITSO Car Rentals 23

2.1.3 Design decisions

Look back at Figure 2-1 on page 20 to see how we got to some of the design

points we did. The first thing is that the presentation for this project is a Web

container, or browser. We could have chosen to use a rich user interface and

written core Java J2ME code using, say, the Foundation Profile with a widget

toolkit such as AWT. The reasons for our choosing a browser design are:

1. The eRCP and eSWT runtimes are not yet available in a publicly released

product. They are in the technical preview only stage as we write this book.

2. MIDP, while it has a layout and presentation model, does not have a rich

enough API set for server side data access (JDBC, MQe and so on.

3. The Web container is a simpler UI programming model. The focus of this case

study is using the technology, and is not really concerned with the UI

technologies themselves, especially since the UI runtime picture is not yet

complete.

So we have a Web container presentation, using a number of services for data

access, server communication and data synchronization.

Next, we have decided that offline operation is required, so we need to have data

on the device. This makes us decide which database technology to use. The

WCTME stack supports both Cloudscape as well sd DB2 in this environment.

Because JDBC is the access method, the decision points come down to cost and

size. You will of course need to do your own evaluations, but the significant

differences between Cloudscape and DB2 in this case are that while Cloudscape

is open source and less expensive, it is also a bigger footprint on the device, and

being open source, reliability, scalability, and maintenance could come into

question. DB2 on the other hand, is a more battle-tested product, is backed by

the IBM Corporation and is a much smaller footprint. The trade-off here is it is

more expensive. Note there is no quantitative information in these statements.

They are designed to be generic statements to give you ideas in what to look for

without putting any bias one way or the other into your heads. Also, these are the

larger examples. There are many more differences between the two, so you

should thoroughly evaluate your choices with respect to your requirements and

environment. In the case study, we have chosen DB2 Everyplace (DB2e) on the

device for this example.

Looking at Figure 2-1 on page 20, you can see that DB2e is on the client device,

and a DB2 synchronization server is on the back end. The team decided that

real-time access to live, service-side customer and rental records is not required.

The signal in and around airports can be spotty, and while the car rental records

are updated often, it is not likely that a customer on the airplane already, will

need to have their record updated. A periodic synchronization is all that is

needed. In some instances, daily synchronization is all that is needed. This