Ryan Shoemaker's Blog

Ryan Shoemaker is a Staff Engineer at Sun Microsystems, Inc. In his 11 years with Sun, he has worked on a variety of Java Enterprise and Java Web & XML technologies including JMS, JAXB, JWSDP, and WSIT. He is currently a contributing member of the Mobile Enterprise Platform (MEP) team leading the implementation of the mobile client SDK. He is also an active member of Java.net where he participates and hosts many projects in addition to being one of the Java Web & XML Community leaders.

Developing MEP Client Applications - Part 1

In Part 1, we will focus on the fundamentals of the API: creating a SyncManager, initiating a sync, and examining the sync results. In part 2, we will study the security features provided in the client API.

MusicDB Sample App

Data Model

Implementing A BusinessObject

1. extend com.sun.mep.client.api.BusinessObject
2. implement getters/setters for your bean properties
3. implement the serializer and deserializer methods

The class definition and bean properties look like this:

 public class Album extends BusinessObject {

     private static final String DEFAULT_VALUE = "$$default$$";

     String artist;

     Date datePublished;

     int rating;

     ...

Each business object must have a unique name which is stored in the 'name' field of the BusinessObject base-class. Since the business objects are stored on the mobile device's filesystem, there is a restriction that the name must be a unique identifier that can be used as a file name. In order to differentiate between different kinds of business objects, you must also assign a unique extension. For the "Album" business object type, we've choosen ".alb" by implementing the getExtension() method like this:

     public String getExtension() {
         return ".alb";
     }

The combination of the unique name of each instance of Album and the extension will determine the name of the object stored on the mobile device's filesystem.

Implementing the getters and setters for the bean properties is as simple as:

     public String getArtist() {
         return artist;
     }

     public void setArtist(String artist) {
         this.artist = artist;
     }

     public Date getDatePublished() {
         return datePublished;
     }

     public void setDatePublished(Date datePublished) {
         this.datePublished = datePublished;
     }

     public int getRating() {
         return rating;
     }

     public void setRating(int rating) {
         this.rating = rating;
     }

The business object's name field is immutable - once you set the object's name, you can not change it.

All business objects must provide the ability to serialize and deserialized to a byte array. The actual format used for serialization is open ended, but must be part of the contract between the connector and the mobile client application. For music albums, serialization is implemented using DataOutputStream and DataInputStream:

     public byte[] serialize() throws IOException {
         ByteArrayOutputStream out = new ByteArrayOutputStream();
         DataOutputStream dOut = new DataOutputStream(out);

         dOut.writeUTF(getName());
         dOut.writeUTF(artist != null ? artist : DEFAULT_VALUE);
         dOut.writeUTF(datePublished != null ? 
              getSimplifiedDate(datePublished) : DEFAULT_VALUE);
         dOut.writeUTF(Integer.toString(rating));
         dOut.flush();
        
         return out.toByteArray();
     }

     public void deserialize(byte[] array) throws IOException {
         ByteArrayInputStream in = new ByteArrayInputStream(array);
         DataInputStream dIn = new DataInputStream(in);

         albumName = dIn.readUTF();
         artist = dIn.readUTF();
         if (artist.equals(DEFAULT_VALUE)) {
             artist = null;
         }
        
         DateStringParser dateParser = new Iso8601Converter();
         String date = dIn.readUTF();
         Calendar c = dateParser.stringToCalendar(date, TimeZone.getDefault());
         datePublished = date.equals(DEFAULT_VALUE) ? null : c.getTime();
        
         rating = Integer.parseInt(dIn.readUTF());
     }

You can see that there is a special token 'DEFAULT_VALUE' which is used to determine when Album fields are not set. There is also some helper code for parsing the date format.

Reading and Writing Business Objects

 public class BusinessObjectStorage {
     public Vector listBusinessObjectNames() {...}
     public void readBusinessObject(BusinessObject result) {...}
     public void writeBusinessObject(BusinessObject obj) {...}
     public void deleteBusinessObject(BusinessObject obj) {...}
     public void deleteBusinessObject(String name) {...}
     public boolean deleteAllBusinessObjects() {...}
 }

     // Get the name of the selected album from the UI and read the BO
     selectedAlbum = getAlbumsForm().getString(getAlbumsForm().getSelectedIndex());
     Album a = new Album(selectedAlbum.substring(0, selectedAlbum.length()-4));
     boStorage.readBusinessObject(a);

     // Get album details from UI, create a new Album, and store it 
     DateStringParser dateParser = new Iso8601Converter();
            
     Album a = new Album();
     a.setArtist(getArtistField().getString());
     a.setName(getNameField().getString());
     final String dateString = getDateField().getString();
     if(dateString != null && dateString.length() > 0) {
         Calendar c = dateParser.stringToCalendar(dateString,TimeZone.getDefault());
         // calendar details omitted
         a.setDatePublished(c != null ? c.getTime() : null);
     }
     a.setRating(Integer.parseInt(getRatingField().getString()));

     boStorage.writeBusinessObject(a);

SyncManager

     SyncManager syncMgr = new SyncManager(".alb");
     BusinessObjectStorage boStorage = syncMgr.getBusinessObjectStorage();
     ...
     // get the url, user, & pass from the UI and store them
     syncMgr.setCredentials(
         getUserName().getString(),
         getPassword().getString(),
         getSyncServer().getString());

Performing a Synchronization

     syncMgr.sync(SyncType.FAST_SYNC);

Looking at the SyncResults

     SyncResults results = syncMgr.getSyncResults();
     Form f = getResultsForm();
     f.deleteAll();
     f.append(new StringItem("ElapsedTime: ", getElapsedTime()));
     f.append(new StringItem(null, null));
     f.append(new StringItem("CLIENT -> SERVER:", null));
     f.append(new StringItem("Added   :", String.valueOf(results.getClientAdditions())));
     f.append(new StringItem("Updated :", String.valueOf(results.getClientUpdates())));
     f.append(new StringItem("Deleted :", String.valueOf(results.getClientDeletions())));
     f.append(new StringItem("SERVER -> CLIENT", null));
     f.append(new StringItem("Added   :", String.valueOf(results.getServerAdditions())));
     f.append(new StringItem("Updated :", String.valueOf(results.getServerUpdates())));
     f.append(new StringItem("Deleted :", String.valueOf(results.getServerDeletions())));

A Closer Look at the MCBO API

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.

JavaOne 08 MEP Slides Available

The JavaOne 2008 MEP slides provide a very good technical overview of the platform and its many features - Take a look! Unfortunately, the session wasn't recorded, so there's no audio or video to accompany the slides.

The presentation covers the platform's features and overall architecture including the client and connector programming models, security model, provisioning, and much more. During the presentation, we had a live demo on stage of a secure client (running on a BlackBerry 8830 and a Palm Treo 700P) that performed synchronizations through our mobile carrier's network, over the internet, and through Sun's firewall to a MySQL database running in Colorado.

Sun Java System Mobile Enterprise Platform 1.0 is Available!

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.

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!

August 2008

Search this blog:

Categories

Archives

August 2008
July 2008
September 2007
April 2007
April 2006

Recent Entries

Developing MEP Client Applications - Part 1

A Closer Look at the MCBO API

JavaOne 08 MEP Slides Available

This work is licensed under a Creative Commons License.