14 posts

The GlassFish Mobility Platform team has been working on many new features since the 1.1 release back in February 2009, one of which is adding support for MCBO on the Java SE platform.  This will allow the development of desktop synchronization clients that are much more powerful than their mobile Java ME siblings.

What's the Difference Between the Java ME and Java SE MCBO Libraries?

Not much!  The two versions of the MCBO library are almost identical.  The only exception is that there is no support for SMS related features in the Java SE library.  Other than that, the APIs and behavior are the same in both libraries - you only have to learn a single programming model in order to write sync clients for either platform.


If you are interested in trying out these new features and providing feedback, please contact us at mep-feedback@sun.com and we can provide an early access release of the Mobility Platform for a limited evaluation period.

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). client_arch2.gif

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. client_arch.gif


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:
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.
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. 


    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.


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.


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.


You can find much more detailed information in the MEP 1.0 Developer Guide for Client Applications.
I've spent the last year working on a new product at Sun called the Mobile Enterprise Platform (MEP), which enables mobile access to enterprise data.  Using MEP, you can easily develop mobile applications capable of  synchronizing data between Java enabled mobile devices and corporate back-end EIS systems such as Siebel and SAP or traditional relational JDBC databases.  The platform is built upon proven open standards such as OMA DS (SyncML), Java ME (MIDP 2.0 / CLDC 1.1 / CDC 1.1.2), and Java EE and runs on Sun's GlassFish Open Source Application Server. We announced our beta at JavaOne 08 and I'm pleased to say that the 1.0 release is now available!  Please take a minute to read our official MEP product announcement - it contains a very nice overview of the platform and all of its features.  You can also jump directly to the MEP product page and download it now! We are just beginning a series of blogs covering all of the features of MEP in great detail.  Since Santiago has already provided some detail about the powerful deployment options of MEP, I'll give you a taste of what the mobile client SDK looks like. The Java ME client SDK is a 100% Java library that allows bi-directional synchronization of data with the MEP gateway.  It is based on MIDP 2.0, CLDC 1.1, CDC 1.1.2, OMA DS 1.1.2/1.2 and has many attractive features including: a pure Java OMA DS implementation, on-device data encryption, authentication, lock-out, data destruction, data fading, and many more.  All of these features are exposed to the mobile application developer through an easy-to-use API called the Mobile Client Business Object API (MCBO).  A "Business Object" is simply an abstraction of the enterprise data you're dealing with - it might be a Customer, PurchaseOrder, or Product. The following stack diagram shows the architecture of a typical MEP client application.  client_arch.gif The client programming model is pretty simple.  All you need to do is implement the data model for your business objects (simple POJOs that encapsulate your enterprise data) and a serializer to store and retrieve the data on the device!  I'll be covering this and much more in the near future, so stay tuned! The MEP team will be posting a series of blogs focusing on specific features of the platform.  You can expect to see technical deep-dives on mobile client application development, connector development, installation, administration, provisioning, security, etc.  These posts will be aggregated on the Sun Enterprise Mobility Blog, so subscribe now!

Filter Blog

By date: