Free Trial
See it in action

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

 Questions? Please call +1 240 428 1700 x 107
Online Document Management


HyperMobile for Mobile Carriers and Service Providers

All Encompassing Push Support : SyncML, ActiveSync or Proprietary Protocols

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.

syncml oma ds oma emn imap idle activesync

Many devices require a synchronization server to support multiple protocols in order to provide them with the ability to synchronize both email and PIM information. In this case the HyperMobile server can address each feature by providing the specific protocol required. For instance… many mobile devices use IMAP for email synchronization and do not support SyncML for email but they do support SyncML for contacts, calendar, tasks, and notes.

This architecture allows service providers to simplify the equation in a confusing market with multiple devices, protocols, and configurations; and maximize the addressable market with a single push platform which supports the widest range of standards.  

Mobile devices with embedded clients. In many cases mobile devices have standardized on specific protocols and provided embedded clients. In these cases, HyperMobile does not require additional client software to be installed on the device.

Mobile devices without embedded clients (or with partial support for a protocol). In some cases,  mobile devices are not embedded with clients or their clients do not have support for the entire protocol. Common cases for this scenario are devices that support SyncML but do not have support for email synchronization or OMA EMN. In this case the device may require a client to support the standard protocols required for true push email and synchronization. For these cases HyperMobile provides the required client software.  HyperMobile has an array of clients that it supports (including most J2ME capable devices with its JAVA client).

Mobile devices without embedded or downloadable clients. In some cases a mobile device does not have an embedded client and cannot even support a downloadable client. These devices oftentimes do not even have data capabilities at all. In this case the system can resort to email-to-sms in order to support these devices because almost all devices support SMS.

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.

The engines include:

  • The foundation classes used to represent a message
  • WBXML encoder/decoder
  • The translation of an XML stream into an object tree and an object tree to an  XML representation (Serializer/Deserializer)
  • Message and object validation/compliance classes
  • Protocol sequence definitions
  • Session Handling
  • Device-specific formatting packages
  • Event triggers for plugin modules that have implemented listeners
  • Conflict resolution. HyperMobile resolves conflicts using different resolution strategies (server wins, client wins, and merge) according to the principal’s sync-profile. The user can either set a resolution strategy for the entire sync-profile or set it per section (Calendar, Contacts, etc.)


 activesync implementation

An example of the Activesync protocol engine.

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.



This module can automate custom processes within a carriers network. It can be integrated with web service calls that trigger additional workflows and can be tied into a larger process that includes checks to a billing system or other account management systems. By defining a specific touch-point for provisioning, HyperMobile allows for a simpler deployment within a carrier-grade infrastructure and does not require a complex retro-fit like other mobile synchronization gateways that were originally designed for a single-server implementation.



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.



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.



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. 

Free Trial

Founded in 1998, HyperOffice is a market leader in cloud collaboration and communication software for small and medium sized businesses. We provide the most comprehensive suite of solutions developed over more than 12 years of understanding your growing business needs. HyperOffice's capabilities include customer portal & intranet software, online document management, online project management, shared calendars, contact management software, business email, Outlook sharing and synchronization, push email and mobile collaboration, online database software and web forms and much more - offered as an integrated, easy to use solution accessible over any web connected PC, Mac, or mobile device. HyperOffice is also a viable Microsoft Sharepoint alternative and Microsoft Exchange alternative for growing companies looking for the power of enterprise class messaging and collaboration - but without the associated costs and hassles.
Copyright 2014 HyperOffice. All rights reserved.