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 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 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 Very Bigger displays! Color display Cameras TCP/IP SSL / HTTPS WAP “ Standard” OSs External app model - Bluetooth Low Tier Mid Tier High 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 server

Client Server Development – Problems in Supporting Different Wireless Platform

  • 1.
    Client Server Development– Problems in Supporting Different Wireless Platform
  • 2.
    Agenda Introduction ClientServer Architecture Wireless Platforms Main Problems of wireless platform in CS apps J2ME Particularities BREW Particularities Protocol Design Case studies VivoAgenda MotoPhoto Conclusions
  • 3.
  • 4.
    Client Server ArchitectureClients 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
  • 5.
    Clients Client appscan be of 3 main types: Wireless: apps running inside mobile handsets Wired: apps running in desktop computers Web: browser showing HTML pages Server
  • 6.
    Server Can alsobe 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
  • 7.
    Client Server ProtocolDefine 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)
  • 8.
    Wireless Platforms -Handsets 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 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 Very Bigger displays! Color display Cameras TCP/IP SSL / HTTPS WAP “ Standard” OSs External app model - Bluetooth Low Tier Mid Tier High Tier
  • 9.
    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
  • 10.
  • 11.
    MIDP Particularities OnlyHTTP 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
  • 12.
    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); } }
  • 13.
    BREW Particularities BREWusually 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 
  • 14.
    BREW Particularities BREWis 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
  • 15.
  • 16.
    Which “low” levelprotocol 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!!!
  • 17.
    Which “low” levelprotocol 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 
  • 18.
    Which “low” levelprotocol 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.
  • 19.
    How to specifyyour 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 
  • 20.
  • 21.
    Vivo Agenda Servicethat 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
  • 22.
    MotoPhoto Service thatprovides the user a way to upload photos in a WEB server