Client Server Development – Problems in Supporting Different Wireless Platform

Agenda

• Introduction– Client Server Architecture– Wireless Platforms

• Main Problems of wireless platform in CS apps– J2ME Particularities– BREW Particularities

• Protocol Design• Case studies

– VivoAgenda– MotoPhoto

• Conclusions

Introduction

Client Server Architecture

• Clients uses services that are provided by a Server application (i.e. clients can by a full desktop app, or a web GUI)

• Server provide service to the clients• CS Protocol defines the “language” that the client must use

to “talk” to the server

Server

Client 1

Client 2

Client N

CS Protocol

Clients

• Client apps can be of 3 main types:– Wireless: apps running inside mobile handsets– Wired: apps running in desktop computers– Web: browser showing HTML pages

Server

Server

• Can also be distributed• Ideally should only offer the service

through the CS Protocol (client independent)

• Offer the same interface to all external clients

Web

Data

Business

DB

DAO Layer

Client Server Protocol

• Define the way to access the Server services• Usually is defined on top of HTTP (S) or TCP (UDP) / IP (SSL)• Can use some kind of RPC (if supported by the client)

– CORBA– RMI– Web Services

• If RPC not supported, can use some proprietary protocol (or some standard one according to the application)

Wireless Platforms - Handsets

- Small displays- Gray scale display- no TCP/IP- WAP- Proprietary OSs- No external app model

- Bigger displays- Color display- sometimes TCP/IP- WAP- Proprietary OSs- External app model

Low Tier Mid Tier High Tier

- Very Bigger displays!- Color display- Cameras-TCP/IP SSL / HTTPS- WAP- “Standard” OSs- External app model- Bluetooth

• Most handsets available in low and Mid tier (high tier is too expensive )

• Low tier usually does not provide an app model (or provide a real bad one )

• Best option is to focus Mid tier

Wireless Platforms – Mid tier Handsets

• BREW – Binary Runtime Environment for Wireless

• Developed by Qualcomm• Proprietary platform• C/C++• Included in Qualcomm

CDMA chipset• Defines full solution for

app provisioning• Current version is 3.0

• J2ME – Java 2 MicroEdition Platform

• Developed by JCP• Focus in different HW not

only handsets• Java • Each handset manuf.

have to buy its VM• MIDP is the widest used

part of J2ME• Current version is 2.0

Network-related Main Problems

MIDP Particularities

• Only HTTP is mandatory– There is no way to guarantee that other protocols will be

supported– It is necessary to check each handset that the app will be

deployed• Different implementation of HTTP

– Nokia handsets has HTTP over WAP stack instead of TCP– Motorola has HTTP over TCP

• J2ME HTTPConnection API does not help the asynchronous connections.– All data usually must be written in the buffer before opening

the connection– This usually impact on the CS protocol if the app wants to

transfer a lot of data , due to heap limitation

MIDP Particularities

HttpConnection) Connector.open(defaultURL, Connector.READ_WRITE); hc.setRequestMethod(HttpConnection.POST); dos = hc.openDataOutputStream(); byte[] request_body = requeststring.getBytes(); for (int i = 0; i < request_body.length; i++) {

dos.writeByte(request_body[i]); } dos.flush(); dos.close(); dis = new DataInputStream(hc.openInputStream()); - Connection Here!!! int ch; len = hc.getLength(); if(len!=-1) {

for(int i = 0;i ;i<len;i++) {if((ch = dis.read())!= -1)

messagebuffer.append((char)ch); }

}

BREW Particularities

• BREW usually supports HTTP and sockets in all Qualcomm chipsets

• BREW 1.0 has a limitation that it allows to transfer only 1KB in a HTTP connection.– This was solved in BREW 2.0

• MIN vs. MDN– CDMA networks has 2 number for each handset!!!

• MDN: Mobile Directory Number• MIN: Mobile Identification Number

– The user knows only the MDN, but the internal handset number is the MIN

– The Server usually has to implement a mapping function

BREW Particularities

• BREW is event based (asynchronous) and does not support Threads. – Asynchronous response arrives in callback function– In event based systems there is usually a watch dog, that

kills the app if it is executing some function for too much time

– Since that the app cannot do long process in the callback• The HTTP connection response is read in a callback function

– The app cannot perform more complex operation in the

callback, such as list all records in the phonebook

Client-Server Protocol Design

Which “low” level protocol to use?

• HTTP is the only protocol that we can guarantee that is available in all platforms

• Client sockets are also supported in almost all handsets• But…

First Choice: HTTP!!!

Which “low” level protocol to use?

Can we use some high level protocol on top of HTTP or socket?

• Web services specified in JCP (JSR 172), but few handsets support it. BREW does not support Web services

• RMI is only in java and is not supported in CLDC/MIDP • CORBA is not in BREW and ins not CLDC/MIDP• Some SOAP solutions only for MIDP

– kSOAP• But if you use this, you will have to implement the same for

BREW, since it is not available

Which “low” level protocol to use?

So, we are back to HTTP

• But… if the app needs to send more than one 1KB in a connection, we must make sure that the App will not be deployed in BREW 1.x handsets.

How to specify your app protocol?

• If you have a XML parser for J2ME and for BREW, use XML. If you don’t you have to define your own language

Case Studies

Vivo Agenda

• Service that shadows the user’s phonebook on a server site– User can add registries in the server side or in the handset and

then synchronize them• All Clients in BREW (no J2ME )

– Motorola V710, C357, C358, V265, V510, V810

MotoPhoto

• Service that provides the user a way to upload photos in a WEB upload photos in a WEB serverserver