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

Chapter 2. The Case Study: ITSO Car Rentals 35

MQe messaging

In stand-alone mode the messages are faked.

To send and receive messages with a real MQe message, a server-side

implementation must be created and running. The steps to create and start a

MQe server are described in Chapter 5, “Messaging” on page 109.

Use the config panel to set the host and port of the MQe server, and the unique

name of the local device queue name.

Web services

The application always uses a local Web service to manage flight information.

The local Web service client bundle is used to query this local Web service and

to format the information for displaying in the application.

In stand-alone mode, a server for flight status is not available. In this case, the

local Web service will conjure up flight status data.

To use a real Web service, it must be running when the client side stub is

created, at development time. This stub is then used at runtime to query flight

information from the server side web service.

Appendix C, “Sample server-side Web Service” on page 375 describes the

creating and running of a server-side Web service.

Use the config panel to set the Web services host and port.

Device Management

In stand-alone mode a device management update is simulated for

demonstration purposes. To perform a real device update you can set up a

WebSphere Everyplace Server as described in Chapter 11, “Device

management” on page 317. Other alternatives are using the Tivoli® Device

Manager or WebSphere Everyplace Device Manager (WEDM).

Use the config panel to set the host address string for the Device Manager

server.

2.3 Running the sample application with live servers

DB2 and DB2e synchronization

When the client application is running on the device, local DB2e tables provide

all the persistent storage needs for the application. Communication with the

36 WCTME: Application Development and Case Study

DB2e sync server is only done when the application's Sync button is selected.

The sync server must be running.

Only a small subset of the information the server contains should be synced

down to the device. Ideally this would be only the customers and contracts for

today at your location. The application would only display customers who:

򐂰 Expect to arrive in the near future

򐂰 Should have arrived in the resent past

For example, if our small rental company database server had 100,000 pending

contracts all over the country for 65,000 customers, you would not expect to sync

all of that all the time. Filters on the server would sync only the content

appropriate for the device client. For example:

򐂰 Sync only the contracts for your airport location and for today. This could be,

125 records, for example.

򐂰 Sync only the customers for those contracts, 125 unless someone has

multiple reservations. Because each customer’s photo is 10,000 bytes or

less, the first sync of the day would take longer than a sync that updates

status only.

򐂰 The application would filter that data down even more by displaying only

customers arriving within the next hour (10) and those that should have

arrived in the last two hours(20).

Note: The application does indicate known flight delays, but does not take any

further action on that information.

Since this application is just a demonstration, we do not handle every real

use-case. For the purposes of our simple sample application, we do not include

airport, date or time in our database tables. This makes the demonstration

repeatable with out any unnecessary complications.

See Figure 2-4 on page 27 for how to configure the database server settings that

the client uses.

MQe Server

When showing this example application, the MQe server does not need to be

running because the message will be queued. MQe messages are only queued

up to be sent to the server when a customer is marked as arrived, but real-time

responses with updated vehicle location information will happen only if the MQe

server is up and functioning.

There can be a short delay in the delivery of MQe messages, so it will be

necessary to refresh the screen once the message arrives.