BlackBerry
Skip Top Navigation
Developers Partners
North America [change region] Products Solutions Purchasing Support
Developers


BlackBerry Developer Journal

Understanding MDS:
A Developer's Perspective

Tyler Lessard, Research In Motion

Some of the key challenges with developing and deploying wireless applications for the enterprise have traditionally been security, connectivity, manageability and extensibility.

How can you build a wireless extension to an existing application that resides behind the corporate firewall?

How do you ensure that it will be highly secure and remotely manageable?

How will that application make an end-to-end connection to the server that hosts the valuable corporate data?

Will this application be extensible to a number of wireless networks and how will it support roaming between countries?

And perhaps, most importantly, how much will it cost, and how long will it take to deploy and validate a solution that meets these requirements?

It is these problems that the BlackBerry Enterprise Server and Mobile Data Service (MDS) are designed to solve. By enabling wireless enterprise applications to be developed and deployed quickly and securely in a manageable fashion.

MDS is a feature of the BlackBerry Enterprise Server that enables applications beyond email and Personal Information Management (PIM) to securely establish http network connections behind the corporate firewall. By using the existing secure connection, the BlackBerry Browser and 3rd party Java applications for BlackBerry, can easily communicate with corporate web and application servers. This eliminates the need to worry about data encryption, connectivity behind the firewall or the underlying wireless network technology or carrier.

Although MDS can be thought of as a "secure pipe" for wireless applications to get behind the firewall, it is much more than that. MDS can play many passive and active roles in managing push- and pull-based connections to and from wireless applications, as well as user management, authentication and data optimization.

This article discusses many of the key features of MDS and its various roles in proxying and managing connections to and from wireless enterprise applications for BlackBerry.

Topics within this section include:


BlackBerry Architecture and MDS Overview

The BlackBerry wireless solution consists of several main components:

  • BlackBerry wireless handhelds
  • Wireless networks
  • BlackBerry Enterprise Server with MDS

BlackBerry Enterprise Server is installed and run behind the corporate firewall. It is integrated with the enterprise email system to enable wireless email and collaboration. BlackBerry Enterprise Server maintains a secure, authenticated connection to all handhelds within that organization via the BlackBerry wireless data center. The BlackBerry wireless data center provides a reliable, consolidated connection point to all wireless networks that BlackBerry operates on, including GSM/GPRS, CDMA, iDEN, Mobitex and DataTAC networks.

Wireless applications for BlackBerry handhelds use the MDS feature of the BlackBerry Enterprise Server to securely establish HTTP connections behind the firewall over the same secure channel as is used for wireless email. As wireless applications are typically deployed on top of an existing email/PIM deployment, this model enables the re-use of the existing BlackBerry infrastructure. MDS also provides the necessary interfaces to enable server side applications to proactively push content to the BlackBerry handheld in a secure and reliable manner.

MDS acts as a secure gateway that can be used by the following types of applications:

  • BlackBerry Browser
  • Custom Java/J2ME Applications developed by Enterprise IT or Systems Integrator (SI)
  • Custom Java/J2ME Applications developed by 3rd party Independent Software Vendors (ISVs)

Conceptually, MDS provides a persistent, bi-directional Virtual Private Network (VPN) connection for the BlackBerry Browser and J2ME applications for BlackBerry.

Value to the Customer

BlackBerry Enterprise Server with MDS provides significant value to enterprise customers that are interested in extending their wireless strategy beyond email and PIM. MDS enables new wireless enterprise applications to be deployed within the enterprise without the need to:

  • Purchase or manage new wireless connections or new pricing plans
  • Worry about security or encryption beyond the firewall
  • Worry about remote connectivity and support for multiple networks (including roaming!)
  • Worry about data security on the handheld itself

Value to the Developer

BlackBerry Enterprise Server with MDS also provides significant value to wireless application developers, enabling quick and inexpensive wireless application development and deployment:

  • Out-of-the-box secure connectivity to the corporate intranet: Inherent security, quicker time to launch, simpler deployment
  • Leverage PUSH technology to improve the value of your solution ... get users addicted to your always-on applications!
  • Network-independence:
    • Develop one application that serves all wireless networks and BlackBerry handhelds
    • Managed roaming: No concerns about connectivity while roaming, no re-connecting and dropping data

What Does MDS Do?

Connectivity

At its core, MDS acts as a proxy server or wireless gateway for applications on the handheld to connect to the wired intranet. In its role as a wireless gateway for handheld applications, MDS provides the following features:

  • Protocol conversion
  • Encryption and compression
  • Queuing and flow control for Push-based connections

The following table details what protocols are used through each stage of transmission:

  BlackBerry Handheld - Wireless Network Wireless Network-MDS (Over Internet, through firewall) At MDS
(Role of MDS)
MDS-Web or Application Server
Pull Request Wireless Protocols BlackBerry/IP (Port 3101 through firewall, Outbound Initiated) Data Decryption Decompression Protocol Conversion DNS/Routing HTTP (GET/POST) or TCP/IP Request
Pull Response Wireless Protocols BlackBerry/IP (Port 3101 through firewall, Outbound Initiated) Data Encryption Conversion Compression Protocol HTTP or TCP/IP Response

  Web/Application Server-MDS At MDS MDS-Wireless Network Wireless Network - BlackBerry Handheld
Push (Server Initiated) HTTP (POST) to MDS Protocol Conversion, Compression, Data Encryption, Queuing and Flow Control BlackBerry Protocols over IP (Port 3101 through firewall, outbound initiated) Wireless Protocols

Data is compressed and encrypted for all communications between the handheld and the MDS.

Also worth noting is the additional queuing and flow control during a push-based connection

If a server-side application initiates a data push to a handheld application, but the handheld is out of coverage, MDS will queue the data in hopes of delivering the data once the user returns to coverage. This is discussed in more detail in the section on Push Management.

What Does MDS Do?

Security and Authentication

As previously discussed, MDS plays a key role in data encryption and security. MDS provides inherent data encryption from the enterprise to the wireless handheld application. MDS also supports additional encryption between MDS and the destination web or application server via HTTPS. As well, MDS provides support for standard enterprise authentication schemes for those situations where the enterprise system requires a username/password authentication.

MDS supports TLS/SSL for HTTPS connections, and Kerberos, HTTP Basic, and NT LAN Manager (NTLM) enterprise authentication. In the case of NTLM or Kerberos authentication, the authentication server is specified in the MDS configuration.

The following table details what security and authentication schemes can be used through all stages of transmission:

  BlackBerry Handheld - Wireless Network Wireless Network - MDS (Over Internet, through firewall) At MDS
(Role of MDS)
MDS-Web or Application Server
Security 3DES encryption 3DES encryption 3DES De/Encryption Optional TLS/SSL De/Encryption TLS/SSL Handshaking
Authentication (User credentials included in payload) (User credentials included in payload) Username/Password submitted as response to challenge Authentication (Kerberos, Basic, NTLM)

What Does MDS Do?

Cache User Information

MDS also acts as a proxy to manage cookies and user credentials on behalf of the handheld applications. Storing frequently used cookies and user information on MDS preserves wireless bandwidth, as this information is not sent unnecessarily over the wireless link.

Cookies

Cookies are generally used for session management during HTTP communication. When server-side applications respond to HTTP requests with cookies, MDS will store the cookie locally on the server. MDS will support all standard cookie directives such as timeouts.

User Information

As discussed in the previous section, MDS supports a variety of authentication schemes. In the situation where authentication is required, MDS will cache user credentials after a user is prompted for a username and password. The next time that user logs into the server and is challenged for a username and password, MDS will automatically authenticate the user with the cached credentials, removing the need for them to re-enter their credentials each time.


Note: This feature can be turned off in the MDS configuration.

PUSH Management: What Does it Do?

Server-side applications can securely push content to handheld applications via MDS. BlackBerry provides the ability to push content to the BlackBerry Browser or to custom Java applications that have been designed to listen for incoming pushes. For more information on building push-based applications, refer to the BlackBerry developer guides.

With regards to MDS, what happens during a push? The following is a step-by-step list of what MDS does after receiving a push request from a server-side application:

  1. MDS receives HTTP POST with data to be pushed
  2. MDS checks the local BlackBerry user database to confirm the existence of the destination user
  3. If the user exists, MDS responds to the server application with an HTTP confirmation (HTTP 200 OK) and closes the connection
  4. MDS now determines the status of the destination handheld to confirm whether it is online or offline
    • If the handheld is in coverage, the data is pushed immediately through the appropriate wireless network
    • If the handheld is out of coverage, the push request is queued within MDS (currently the data is queued in RAM on the server)

Push requests that are queued in MDS are then subject to Flow Control and Timeouts. MDS implements Timeouts to expire stale push requests and to preserve memory space on the server. If the handheld is out of coverage, the initial push requests are subject to Flow Control.

Flow Control:

  • 5 push requests will be queued in MDS for the flow control timeout period (default: 10 minutes)
  • No further requests will be pushed until these 5 are received by the handheld

If more data is pushed to the disconnected handheld while the Flow Control bucket is full, they are subject to a different Timeout.

Time-out:

  • Push requests received while the Flow Control bucket is full (5 requests that have not been delivered) are subject to this timeout
  • These push requests will be discarded after the period specified by the timeout parameter (default: 3 minutes)

Therefore, if the MDS configuration values are left at their default values and 12 requests are pushed to a handheld that is out of coverage, requests 6-12 will be discarded after 3 minutes and requests 1-5 will be discarded after 10 minutes.


Note: Increasing the Flow Control and Timeout parameters will increase the length of time that push requests can be queued. This would have the effect of increasing reliability of pushes, at the expense of RAM usage. Also note that these timeout settings are global for all pushes and all users.

MDS Configuration and Policy Settings

MDS includes a number of configurable parameters that can impact how applications behave. If you are deploying applications that will use MDS as a gateway, it is worth your time to become familiar with these parameters. To follow are some of the key MDS configuration parameters that are relevant to developers or administrators deploying wireless applications for BlackBerry:

Push Listen Port

  • Port that MDS listens on for incoming pushes from server-side applications. Keep in mind that this is configurable, so try not to hard code the destination server port in push applications

FlowControl Timeout and Push Queue Timeout

  • As described above, these parameters defines the expiry time for pushes to a handheld that is out of coverage

Max Payload

  • Maximum response size that MDS will allow for a single request

HTTP Logging

  • Enable / Disable detailed logging of HTTP requests, typically used for debugging only

TLS

  • Specifies whether or not HTTPS connections will be allowed to "untrusted" servers. To become a trusted server for HTTPS connections, the server certificate must be injected into MDS

Description Parameter Default
FlowControl Timeout IPPP.queue.flowcontrol.timeout 10 min.
Push Queue Timeout IPPP.connection.timeout 3 min.
Max Payload IPPP.connection.MaxNumberOfKBytesToSend 128k
HTTP Logging Application.handler.http.logging False
TLS Application.hander.tls.allowUntrustedServer False


Note: These parameters are defined in a text file called "rimpublic.property" which can be found in the /MDS/config/ folder.

BlackBerry Enterprise Server also includes a set of IT Policies that are configurable for each user's handheld. These policies dictate what the handheld and local applications can and cannot do. The following policies are relevant to developers:

  • AllowBrowser:
    Dictates whether or not users can use browser (default: Yes)
     
  • DisallowThirdPartyAppDownloads and AllowRunThirdPartyApps:
    Controls use of Java apps on handheld (default: Allow applications to be loaded and run)
     
  • AllowThirdPartyUseSerialPort:
    Dictates whether or not applications can communicate through the serial or USB port (default: Yes)
     
  • AllowThirdPartyUsePersistentStore:
    Dictates whether or not applications can use the persistent store API to write to flash (default: Yes)
     
  • AllowInternalConnections:
    Dictates whether or not applications can connect via MDS (default: Yes)
     
  • AllowExternalConnections:
    Dictates whether or not applications can connect via public gateways, such as WAP gateways (default: Yes)
     
  • AllowSplitPipeConnections:
    Dictates whether or not a single application can connect via both MDS and an public gateway (such as WAP) (default: Yes)


Top |  Table of Contents |  Journal in PDF Format |  Legal Disclaimer
 
     
 Home | Products | Solutions | Purchasing | Support | Developers | Worldwide | News | About Us | Contact Us | Site Map
 Legal | Copyright © 2008 Research In Motion Limited, unless otherwise noted.