Your SlideShare is downloading. ×
  • Like
Client Server Development – Problems in Supporting Different Wireless Platform
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Client Server Development – Problems in Supporting Different Wireless Platform

  • 489 views
Published

sun tech days 2005

sun tech days 2005

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
489
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
2
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

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