Skip to main content

Sun Java System Mobile Enterprise Platform 1.0 is Available!

Posted by ryan_shoemaker on July 15, 2008 at 12:08 PM PDT

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!

Related Topics >>

Comments

Thanks Ryan. When the MEP admin triggers the clients to sync, it is done using a SMS and is read by the MIDP 2.0 Push Registry on the handset. Can it also be done using OMA requests.

Yes, the business objects (data records) are stored on the mobile device as files using JSR-75 FileConnection. Normally, end users will initiate the sync from a JavaME application. When this happens, the MEP client sync library reads the business objects from the device's filesystem and transfers them to the MEP gateway sync server using SyncML. There is also a facility that allows an MEP admin to remotely trigger clients to sync.

The data synchronization is supported through SyncML and HTTP(s). Does this mean that the framework supports a set of files which are used as the data for the purpose of J2ME applications. Also these files can be synced using a) SyncML and an independent Sync request which syncs the file objects b) J2ME application and HTTP(s) which reads the files using PIM API and tries to sync the contents Also, does it also mean that the J2ME application can respond / participate in the Sync requests.

relying on SMS for server initialized sync/push is hardly something impressive... SMS can take upto 48 hours and leaves you with 0 control of delivery.

I'm not entirely sure what you mean by "0 control of delivery" - please elaborate. Relying on the MIDP 2.0 Push Registry to implement the server initiated features of MEP is the only way I'm aware of being able to trigger a response from the MIDlet when it isn't running. Since all of the client devices for a particular MEP deployment will be running on the same mobile carrier network, pushing via SMS is the most reliable, if not the only, way for for the server to truly initiate a response from the client without requiring the client to do anything. The only other technique I can think of requires the clients to periodically wake up and connect to the server to supply other addressing information (ie IP address) that the server can use if and when it needs to initiate a response from the MIDlet client.