I briefly introduced the MEP client architecture in my previous post. In this post, we will take a closer look at the client architecture and use it as a foundation for the next few blog entries that will focus on the details of the programming model.

30,000ft View

The MEP client SDK, also known as the "Mobile Client Business Object API" or MCBO, is simply a Java ME library that enables bi-directional synchronization of arbitrary data types with the MEP gateway server. The client and gateway perform these synchronizations using the industry standard OMA DS (SyncML) protocol. Application developers can add MCBO to their mobile applications to enable synchronizations with corporate back-end EIS systems (such as Siebel, SAP, or JDBC accessible databases). The following diagram shows an overview of the entire MEP architecture. The top left area shows the main components on the mobile client. The MCBO API is responsible for managing enterprise data stored locally on the device's filesystem (via JSR-75 FileConnection) as well as performing synchronizations with the MEP gateway server (Santiago will be covering the MEP gateway server architecture in more detail).

Device Agnostic

In order to support as many Java enabled mobile devices as possible, MCBO has very minimal requirements: MIDP 2.0 / CLDC 1.1 or CDC 1.1.2. The only other requirement is JSR-75 support for access to the device's filesystem which enables MCBO to provide off-line access to enterprise data stored on the device. That's it! MCBO can take advantage of JSR-120 enabled devices to provide server initiated features via WMA (to be discussed in future blog entries). The following architecture stack shows the relationship between the application code, MCBO, and the underlying Java ME requirements.

Security

MCBO was designed with security in mind and provides a number of first-class features. Application developers can choose any, all, or none of these features to tune their application with the necessary levels of security:

Authentication

There are two layers of user authentication - one at the application layer (optional) and another at the synchronization layer (mandatory). Application authentication provides a login mechanism that prevents unauthorized users from launching the application and gaining access to sensitive information. Every time the application performs a synchronization, the user's MEP gateway credentials are sent to the gateway as part of the OMA DS protocol (syncml:auth-basic over https). This prevents unauthorized users from accessing or corrupting sensitive information in the back end systems.

Data Encryption

Data cached locally on the mobile device's filesystem can be encrypted. The default security manager uses 3DES to protect data at rest on the device, but application developers can replace this with other encryption algorithms (see below). Future versions of MEP will likely provide additional security managers that support AES.

Transport Layer Security

TLS is provided by HTTPS connections between the mobile device and the MEP gateway server.

Data Destruction

MCBO provides the ability for applications to perform complete data destruction under certain circumstances. The application developer may decide to wipe-out all data if the user fails a certain number of login attempts or after a certain amount of time has passed without a successful synchronization.

Lock Out

Application developers can specify a maximum number of login attempts. If a user exceeds the threshold, then they are locked out of the application.

Data Fading

A quiet period can also be specified that allows the application to determine if a device is lost. After the quiet period expires, the application can take protective measures such as data destruction.

Extensible

A 3DES based security manager is shipped with MCBO, but application developers are free to supplant this with their own implementation based on other encryption standards.

A Closer Look at the MCBO API

As I stated earlier, the MCBO api is simply a Java ME library that allows bi-directional synchronizations of arbitrary (user-defined) data types with corporate back-end systems. There are four core concepts behind the MCBO API: BusinessObject, BusinessObjectStorage, SyncManager, and SecurityManager. I'm only going to provide an overview of these classes for now - we will be examining each of these in great detail in subsequent postings.

BusinessObject - the "BO" in MCBO

A business object is just a POJO that defines the data model and serialized form of the corporate data being synchronized. It will typically be derived from the schema of the back-end data store. The serialized form is used to read and write the data to the device's local filesystem. It can be as simple or sophisticated as you like - CSV, XML, etc.

BusinessObjectStorage

This class manages the local cache of business objects stored on the mobile device. It provides the application layer methods to read, write, delete, and enumerate business objects using the serialization methods provided by your business object. You can think of it as a simple data store.

SyncManager

The SyncManager is responsible for authenticating with the MEP gateway server and controlling the actual synchronization process. There are six different kinds of synchronizations that can be performed which are defined in an enum type named SyncType. It also provides access to coarse-grained stats about the last synchronization.

SecurityManager

The SecurityManager is responsible for providing all of the security features described above. MCBO ships with a default implementation based on 3DES, but you can use your own security manager based on whatever security standards you like.

Client Application Development

Application developers are free to choose whatever development environment they like, but I will be using NetBeans 6.1 to develop the sample app in subsequent postings. NetBeans has a Mobility Pack that fully integrates with the Java ME Wireless Toolkit. Using these two platforms together makes it very easy to quickly build deploy and test mobile apps. Since MCBO is just a synchronization library, developers can use their favorite UI toolkit: LCDUI, LWUIT, SVG, etc.

Light Weight - 150k

The raw unoptimized MCBO API jar is about 1.6M. The encryption library bundled with MCBO accounts for over 1M of the 1.6M, but once the library is optimized and obfuscated, MCBO is only about 150k !!!!! The size of complete applications will vary depending on the size and quantity of resources such as graphics and images, but a very basic LCDUI based MIDP 2.0 app with all security features enabled will typically fall into the 190k size range after optimization and obfuscation.

Documentation

You can find much more detailed information in the MEP 1.0 Developer Guide for Client Applications.