HyperOffice > Service Providers > Push Email and Mobile Sync > Architecture

	Architecture HyperMobile for Mobile Carriers and Service Providers

HyperMobile is unlike any other push messaging platform in the market in a number of respects. It has implemented a “pluggable”protocol layer which enables it to support every major protocol in the market including standard protocols like SyncML (OMA DS, OMA EMN), Push IMAP, Microsoft ActiveSync or proprietary XML and WSDL protocols. HyperMobile's architecture allows it to quickly evolve in response to new market standards, as well as seamlessly integrate with almost any technological environment, no matter how complex.

Each protocol is implemented within its own layer and they all share a set of standard object libraries used to manage the back-end data. This abstracts the data-access from the protocol-specific implementation allowing for a rapid development of additional protocols.

End-to-end Push Architecture

It is extremely common for other platforms to implement a “Poll-and-Push” architecture (especially so-called “Zero-Footprint” systems) where they use their connectors as polling services that simply poll a back-end resource for changes and then push them to the device when they detect a change. This approach is also used by HyperMobile when the back-end resource does not support a direct notification but, whenever possible, HyperMobile employs an “End-to-End” Push architecture that begins with a push event from the back-end service and immediately results in a push to the device.  This process results in a greatly diminished lag time between the time an item was changed/delivered and the time it was sent to the device.

The HyperOffice messaging and collaboration suite takes full advantage of this capability and has integrated the push notification process into its Mail Delivery Agent (MDA) as well as other areas of its architecture which results in the carrier’s ability to offer a service that surpasses other solutions in terms of responsiveness and reliability. Additionally, the HyperOffice collaboration suite has added “events” within the application when an item is created or modified that also serve to initiate a “push” event if the section that is being affected is activated in the users’ profile.

This tight coupling of two architectures presents service providers with a unique oppurtunity to expand value added services to larger worker productivity solutions that integrate downstream with push messaging.

Core Architecture

The HyperMobile core architecture is implemented in layers, as shown below:

• The Transport Layer - Sends and receives messages using different protocols including HTTP, SMTP, WSDL, IMAP, SMS, MMS, and so on.
• The Application Layer - Implements protocols, mapping, and notification engines and the specific business rules used to fulfill each request.
• The Services Layer - Implements horizontal services, data access, and synchronization services on top of which the transport and application layers are developed

The Transport Layer

The transport layer manages the communications protocols used to communicate with the HyperMobile server. Although the typical mode of communication is HTTP, this layer also implements proxies for IMAP and proprietary socket-based communication. The transport layer is built to allow additional communications protocols in the future.
 

The Application Layer

The application layer consists of several engines, the most important of which are:

Protocol Engines

Each protocol has a separate set of rules and message formats that apply to its own method of synchronization. The protocol engine implements the logic specific to each protocol and maps it to the appropriate shared services in the services layer. Since there is often a wide-array of variability within some of the protocols, these engines often implement device-specific packages in order to load specific templates or message formats to handle the idiosyncrasies of specific devices.

Each protocol typically uses its own Serializers and deserializers to convert XML to a java object and back again. Although many devices use standard message formats, there are quite a few device specific idiosyncrasies. The content of data within a record can differ significantly between devices, models and manufacturers. In order to accommodate these differences, the protocol engine can import specific packages that properly process the devices unique format.

__________________________

Email Engine

The email engine handles a wide array of functionality including:

• Managing proxy sessions to handle IMAP IDLE support while serving as a pass-through for the users’ actual IMAP server.
• Polls external mail servers (when applicable) or uses their IMAP IDLE capabilities to register with them for direct notification.
• Managing the formatting and creation of email messages that can be sent to the various devices
• Serving as a SMTP proxy so that emails can be passed through to the back-end system for sending or sent through the HyperOffice SMTP server when necessary.

Provisioning Managers

The device provisioning managers implement the logic required to provide the correct services back to the device. This component ensures that the device is given the proper Over-the-air provisioning messages supporting the Open Mobile Alliance Device Management (OMA DM) standards as well as proprietary messaging for non-compliant devices. Provisioning managers are responsible for:

• The detection of the device type
• The sending of any required clients, automated provisioning instructions, or SMS instructions to the device
• The automatic creation of the device profile (when required)
• The initial registration of the device within the HyperMobile Push Server
• Registration with any third-party plugins required for the operation of the Sync Service.

__________________________ 

Notification Engine

The notification engine is responsible for the creation and transmission of valid notification messages required for “push” support. The engine chooses the appropriate notification based upon the device type and client type. It is also built on a pluggable framework (like the protocol engines) to make it easier to implement additional “push” mechanisms in the future.

The Services Layer

The services layer consists of several shared services that are necessary to support the variety of protocols implemented in the application layer. These services are typically ones that are shared by all of the protocols in order to ensure a consistent interaction with the back-end services and to provide a single point of communication for all connector services.

Matching Devices to Protocols

Since HyperMobile supports multiple protocols there are often multiple ways to synchronize with a single device and therefore the provisioning process must determine which protocol will deliver the highest degree of functionality to the device. In order to do this, the provisioning system retains a database of all supported devices and their capabilities which is then used to determine the appropriate provisioning method. 

• In the case of devices like the iPhone or Android phones, the only option that can fully support all features is the ActiveSync protocol. These devices are not truly supported by most other synchronization systems because ActiveSync is the only embedded client that is able to handle push email on these devices.
• For many of the J2ME phones, Over-the-air configuration of the SyncML settings for calendar, contacts, and tasks is used in conjunction with the JAVA client for Email support.
  
• For some newer phones that support OMA EMN, over-the-air configuration of the SyncML settings is all that is required
• Devices such like Windows Mobile phones or Nokia phones can oftentimes be supported in many different ways and in these cases the system attempts to use clientless configuration first (using an embedded client) and, if that is not an option for the device, it reverts to a client-based provisioning process.
• IMAP IDLE is typically used as a fall-back mechanism since it oftentimes requires manual configuration by the user.
• Finally, for phones that cannot support any version of push email (such as phones without any data capabilities), the system can resort to “Email-to-SMS” or “Email-to-MMS” to serve as a degraded form of push email.

Email Support

HyperMobile fully supports email synchronization using multiple protocols. While almost all ActiveSync devices support email synchronization, very few SyncML clients support email synchronization (usually just the devices that support OMA EMN which is a small number). Therefore email synchronization is typically separated from the synchronization of calendar, contacts, tasks, and notes. Most devices include email clients that support IMAP and SMTP and a few support IMAP IDLE (Push IMAP). HyperMobile supports methods for email synchronization that can enable virtually any device with an email client (and even some without an email client).

In order to manage the IMAP process in order to support IMAP IDLE (for the push process) HyperMobile contains an IMAP Proxy service that functions as a full-featured IMAP service for the back-end connector’s mail store.
Similarly the SMTP proxy serves the same purpose mapping the SMTP requests into requests that can be passed through the connector to allow the device to send mail.

__________________________ 

Security

HyperMobile implements security at multiple layers of the architecture. Some of the security elements used include:

• Transport layer security (SSL and TLS) for data encryption
• OMA DS authentication standards (Basic and MD5 schemes) for encrypted authentication
• OMA DS Client Authentication (Client gives credentials to the server – server authenticates the client)
• Server Authentication (Server gives credentials to the client – client authenticates the server)
• IMAP Authentication standards
• WS-Security.
  
• For many of the J2ME phones, Over-the-air configuration of the SyncML settings for calendar, contacts, and tasks is used in conjunction with the JAVA client for Email support.

Additionally, security is implemented at the data access layer as well to ensure that only the proper “principal” (a principal is a user + device combination) can access the resources to which it has been granted authority. This provides a granular level of security that can be controlled down to the level of a specific item if that is required. This is a sharp contrast to most other systems which implement a simple layer of basic authentication and SSL and do not establish low-level rules to govern the actual record-level data.

__________________________ 

Scalability

HyperMobile is designed as a carrier-grade platform and was therefore architected for maximum scalability. It uses a stateless request/response communication protocol with “sticky sessions” to allow for a seamless load-balanced architecture that can scale linearly as the user-base grows. Its standard configuration supports full redundancy, system failover, session failover, and it is capable of supporting real-time geographic migration for geo-failover in a disaster recovery scenario.