Client Server Development – Problems in Supporting Different Wireless Platform
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Client Server Development – Problems in Supporting Different Wireless Platform

on

  • 668 views

sun tech days 2005

sun tech days 2005

Statistics

Views

Total Views
668
Views on SlideShare
667
Embed Views
1

Actions

Likes
0
Downloads
1
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Client Server Development – Problems in Supporting Different Wireless Platform Presentation Transcript

  • 1. Client Server Development – Problems in Supporting Different Wireless Platform
  • 2. 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
  • 3. Introduction
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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)
  • 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. Network-related Main Problems
  • 11. 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
  • 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
    • 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 
  • 14. 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
  • 15. Client-Server Protocol Design
  • 16. 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!!!
  • 17. 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 
  • 18. 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.
  • 19. 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 
  • 20. Case Studies
  • 21. 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
  • 22. MotoPhoto
    • Service that provides the user a way to upload photos in a WEB server