Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Issues in Designing Push Based Mobile Application Platform - Rafiul Ahad, Oracle

257 views

Published on

OSGi World Congress 2005

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Issues in Designing Push Based Mobile Application Platform - Rafiul Ahad, Oracle

  1. 1. Issues in Designing Push Based Mobile Application Platform Rafiul Ahad
  2. 2. AgendaAgenda •• Mobile Application ModelsMobile Application Models •• Why PushWhy Push--Based Mobile ApplicationsBased Mobile Applications •• Push Design ChoicesPush Design Choices •• Push Design IssuesPush Design Issues •• An Example ImplementationAn Example Implementation •• Implementing Push on an OSGI PlatformImplementing Push on an OSGI Platform •• Concluding RemarksConcluding Remarks
  3. 3. Mobile Application ModelsMobile Application Models •• Three Models of Mobile ApplicationsThree Models of Mobile Applications –– Online/Pull ModelOnline/Pull Model •• Information accessed from the server when neededInformation accessed from the server when needed –– Offline/Sync ModelOffline/Sync Model •• Information accessed from a local database which isInformation accessed from a local database which is synchronized with the server content using conventionalsynchronized with the server content using conventional synchronization techniquessynchronization techniques –– Push/Online Sync ModelPush/Online Sync Model •• Information accessed from cache on the deviceInformation accessed from cache on the device –– Server pushes new and changed data to the cacheServer pushes new and changed data to the cache –– Client tries to maintain a session and sends new and changed datClient tries to maintain a session and sends new and changed dataa to server when session is available (online sync)to server when session is available (online sync) –– Cache permits Offline use when disconnectedCache permits Offline use when disconnected –– Dirty data in the cache is synched when connection availableDirty data in the cache is synched when connection available
  4. 4. Why PushWhy Push--Based Mobile ApplicationsBased Mobile Applications (Higher ARPU for Operators)(Higher ARPU for Operators) •• Push based mobile email has the highest rate ofPush based mobile email has the highest rate of adoption in enterprise (Frost & Sullivan,2005)adoption in enterprise (Frost & Sullivan,2005) •• Enterprises are beginning to see positive ROI forEnterprises are beginning to see positive ROI for mobile applications and are willing to invest moremobile applications and are willing to invest more –– Spending will triple by 2009 (Strategy Analytics, 2004)Spending will triple by 2009 (Strategy Analytics, 2004) •• Mobile enterprise applications bring higher ARPUMobile enterprise applications bring higher ARPU for operators and wireless service providersfor operators and wireless service providers –– NextelNextel –– Blackberry emailBlackberry email •• Beware of the challengesBeware of the challenges –– Usability, security, costUsability, security, cost
  5. 5. Why PushWhy Push--Based Mobile ApplicationsBased Mobile Applications (Solves Usability Issues)(Solves Usability Issues) •• Usability Issues with Online and Offline ModelsUsability Issues with Online and Offline Models –– Online/Pull ModelOnline/Pull Model •• Having to constantly check for new information and thenHaving to constantly check for new information and then •• Having to wait for it due to long wireless network latency andHaving to wait for it due to long wireless network latency and •• Not being able to use it due to lack of coverageNot being able to use it due to lack of coverage –– Offline/Sync ModelOffline/Sync Model •• Information not up to date andInformation not up to date and •• High overhead of conventional sync prohibits frequent syncHigh overhead of conventional sync prohibits frequent sync •• Push/Online Sync Model Solves the Usability IssuesPush/Online Sync Model Solves the Usability Issues –– No need to poll for information or wait for resultsNo need to poll for information or wait for results –– Latest information as long as connection to server is availableLatest information as long as connection to server is available –– Application still works even if connection to server not availabApplication still works even if connection to server not availablele
  6. 6. Push Design ChoicesPush Design Choices •• Periodic Poll with Offline ApplicationPeriodic Poll with Offline Application –– High overhead (connect, login, sync, logout)High overhead (connect, login, sync, logout) –– May be acceptable for some usersMay be acceptable for some users –– Simple to implement if you already have the offline appSimple to implement if you already have the offline app •• Notify and Online SyncNotify and Online Sync –– If client has data to sendIf client has data to send •• If a session exists then client sends the data to the serverIf a session exists then client sends the data to the server •• Else client flags the data as dirty in the cacheElse client flags the data as dirty in the cache –– If server has data to send it notifies the clientIf server has data to send it notifies the client •• If a session exists then client retrieves the data from the servIf a session exists then client retrieves the data from the serverer •• Else client establishes a new session and sync the cacheElse client establishes a new session and sync the cache •• True PushTrue Push –– If server has data to send, it sends the data to the clientIf server has data to send, it sends the data to the client –– Optionally, if client has data to send, it sends it to the serveOptionally, if client has data to send, it sends it to the serverr
  7. 7. Implementation Choices (Contd.)Implementation Choices (Contd.) •• Notification Protocol ChoicesNotification Protocol Choices –– OMA EMN, OMA DSOMA EMN, OMA DS SyncMLSyncML Server Alerted Notification (SAN),Server Alerted Notification (SAN), IETF SIP Notification, IMAP IDLE, PIETF SIP Notification, IMAP IDLE, P--IMAP S2C Notification,IMAP S2C Notification, Lemonade S2S, SNAP: Smart Notification and Alarm Protocol,Lemonade S2S, SNAP: Smart Notification and Alarm Protocol, Web Service Notification (WSN), HTTP Asynchronous ClientWeb Service Notification (WSN), HTTP Asynchronous Client Notifications, UDP or TCP/IP Notifications,Notifications, UDP or TCP/IP Notifications, MoMMoM andand Asynchronous Queues, Programmatic notifications, WAP PushAsynchronous Queues, Programmatic notifications, WAP Push •• Wireless Bearer ChoicesWireless Bearer Choices –– SMS, GPRS,SMS, GPRS, WiFiWiFi, and others, and others •• Device Management ChoicesDevice Management Choices –– OTA, via desktopOTA, via desktop •• SecuritySecurity –– Device securityDevice security –– Communication security may depend on protocol choiceCommunication security may depend on protocol choice –– Preventing malicious usePreventing malicious use
  8. 8. Push Design IssuesPush Design Issues •• Session EstablishmentSession Establishment –– SMS and UDP/IP do not need session, BUTSMS and UDP/IP do not need session, BUT •• Most Access Point will not permit serverMost Access Point will not permit server--originate UDPoriginate UDP •• ClientClient--originate UDP has short time out and differ amongoriginate UDP has short time out and differ among operatorsoperators –– Need to keep alive via heart beatNeed to keep alive via heart beat –– Power consumption higher for transmit compared to receivePower consumption higher for transmit compared to receive –– Assume that wireless transport session is unreliableAssume that wireless transport session is unreliable •• Power consumption high for TCP/IP session establishmentPower consumption high for TCP/IP session establishment –– Decouple application session from transport sessionDecouple application session from transport session •• LongLong--live application (logical) session neededlive application (logical) session needed •• Resume based on some device IDResume based on some device ID
  9. 9. Push Design Issues (Contd.)Push Design Issues (Contd.) •• Battery LifeBattery Life –– SMS based push has the best battery life, BUTSMS based push has the best battery life, BUT •• It could be expensiveIt could be expensive •• Will not work forWill not work for WiWi--FiFi or Wired networkor Wired network –– IP Push requires client to listen on a port continuouslyIP Push requires client to listen on a port continuously •• Continuous listening consumes battery powerContinuous listening consumes battery power •• Client or server has to send heartbeat to overcome time outClient or server has to send heartbeat to overcome time out •• Client sending heartbeat seems to consume more powerClient sending heartbeat seems to consume more power •• Frequent attempts to establish connection can drain powerFrequent attempts to establish connection can drain power –– Use some back off algorithm to try to reconnectUse some back off algorithm to try to reconnect
  10. 10. Push Design Issues (Contd.)Push Design Issues (Contd.) •• SecuritySecurity –– Server must have a certificateServer must have a certificate –– Client must have a root certificate of serverClient must have a root certificate of server’’s CAs CA –– TLS (or SSL) over TCP/IP must be used at a minimum toTLS (or SSL) over TCP/IP must be used at a minimum to •• Authenticate the server andAuthenticate the server and •• securely provision security parameters such as encryption key, tsecurely provision security parameters such as encryption key, token,etc.oken,etc. –– SMS message must be encrypted using provisioned keysSMS message must be encrypted using provisioned keys –– UDP channel must be securely established using token andUDP channel must be securely established using token and encryptionencryption –– Cache on device must be encryptedCache on device must be encrypted
  11. 11. Push Design Issues (Contd.)Push Design Issues (Contd.) •• CostCost –– Both SMS and GPRS could be expensiveBoth SMS and GPRS could be expensive •• Unless the operator provides the push based serviceUnless the operator provides the push based service –– Should support multiple bearersShould support multiple bearers •• Choose the lowest cost bearers among those availableChoose the lowest cost bearers among those available –– Wired via cradle or USB when in office or homeWired via cradle or USB when in office or home –– WiWi--FiFi when availablewhen available –– GPRS as the last resortGPRS as the last resort
  12. 12. Sample ImplementationSample Implementation Local Cache Notifies changes to push/sync agent and applications Push/Sync Agent sends and receives changes if network is up (Online for fast prop- agation of client changes) Store changes when network is down and sync when it comes up (Offline for continuous availability) Server pushes relevant changes to agent (fast prop- agation of server changes) Receives and update changes from agent Manage software and device configuration Server 1 App 1 App n Push/Sync Agent 1 Push/Sync Agent 1 Server 1 Local Cache API 1 API n Transport API 1 Transport API n Protocol 1 Protocol n OnDevice Oracle Collaboration Suite 10g Push Mail Solution Architecture
  13. 13. Sample ImplementationSample Implementation Inbox Application Command Processor OCS Push Email Server P-IMAP IMAP OCS Mail Server MAPI Message Store Ops OCS Push Windows Mobile® Email Client Notification Processor SMS or encrypted UDP/IP Events Ops Ops Server Message Store P-IMAP Transport Notification Command Processing Service Notification Collection Service Network Monitor Notification Delivery Service Device Management Service Oracle Collaboration Suite 10g Push Mail Solution Implementation for Windows Mobile Client
  14. 14. Implementing Push on OSGI PlatformImplementing Push on OSGI Platform •• Persistence store API with callback on eventsPersistence store API with callback on events –– Application and the Push/Sync agent can be notified of changesApplication and the Push/Sync agent can be notified of changes made by each othermade by each other •• Connection Manager API with callback on eventsConnection Manager API with callback on events –– Push/Sync agent can be notified of connection availabilityPush/Sync agent can be notified of connection availability –– Hierarchy of connections with different cost and batteryHierarchy of connections with different cost and battery consumption characteristicsconsumption characteristics •• SMS notification handler APISMS notification handler API –– Needed as a last resort to notify the client to syncNeeded as a last resort to notify the client to sync •• Device Management APIDevice Management API –– Needed to install/upgrade/remove apps and agentsNeeded to install/upgrade/remove apps and agents
  15. 15. Concluding RemarksConcluding Remarks •• Push/ Online Sync is the most usable modelPush/ Online Sync is the most usable model –– Already proven in enterprise email applicationAlready proven in enterprise email application •• Enterprises seeing positive ROI for mobile appsEnterprises seeing positive ROI for mobile apps –– Spending more on mobile applicationsSpending more on mobile applications •• Usability, security, and cost of solution are issuesUsability, security, and cost of solution are issues –– Push based solution addresses usabilityPush based solution addresses usability –– Short battery life could become an issueShort battery life could become an issue •• Operators can benefit from mobile enterprise appsOperators can benefit from mobile enterprise apps –– Must invest in pushMust invest in push--based mobile solutions nowbased mobile solutions now

×