Skip to main content

Thanks MSA! ...No more OBEX (Bluetooth) Self-Made Implementations!

Posted by brunogh on May 21, 2007 at 9:24 PM PDT

Fragmentation in Java mobile environment is something well known by developers. It is caused most of because the variety that exists between devices characteristics and its implementations.

Trying to help in this way, in middle of 2003, the JTWI (Java Technology for Wireless Industry) was launched, defined by the JSR 185. The objective of JTWI was trying to make things more standardized and compatible, specifying technologies that must be included in all JTWI-compliant devices. But since that, the number of mobiles have increased a lot, as well as the number of JSRs. So, in the end of last year, the final release of MSA (Mobile Service Architecture) was published, in order to advance one more step in this natural evolution.

MSA is for CLDC and it is defined by the JSR 248 (take a look in MSA Advanced, defined by JSR 249, if you want to know about CDC). It can be compared as a kind of JTWI evolution, made in order to maximize the number of applications that can run on a handset, because it will make available a set of JSRs (familiar, updated and new ones). MSA specifies two plataforms that a MSA-compliant device can support: MSA or MSA subset, the subset was made for devices with less power. The both contains mandatory and conditionally mandatory JSRs. The mandatories should always be implemented in MSA-compliant devices, although the conditional mandatories would depends on the availability of the technology in the respective device such as, for example, Bluetooth (for JSR 82) and, maybe, GPS (for JSR 179).

The figure below shows the MSA structure:

MSA helps the set of its JSRs, because it makes some clarifications on them (reducing ambiguities, so manufacturers will make less misunderstood too!). In addition, it obligates an umbrella of APIs and technologies, so this can minimize the fragmentation problem as well and then, consequently, helps the whole mobile technology! But you are probably thinking that we are almost in the end of this entry and you have not understood why the name OBEX (Object exchange) is in the title, let me explain (I swear it will be the last paragraph)!

The JSR 82 (Java APIs for Bluetooth) is divided in two main packages: the core Bluetooth API and the APIs for OBEX. OBEX is a communication protocol based on request/response - to simplify, try to imagine something more elaborated, like HTTP - that allows to exchange objects, such as files, images, calendar entries (vCalendar), business cards (vCard), among other things. It can runs over Infrared, TCP or RFCOMM, which the last type is used for Bluetooth. The fact is that there are still a lot of devices with Bluetooth that did not implement the OBEX package, because it used to be optional in JSR 82. In these past conditions, if you would like to make an application that uses OBEX and runs in a lot of devices, you certainly would implement it by yourself using RFCOMM, manipulating bit by bit or trying to find an open source implementation to use. So, a directly benefit of MSA in JSR 82 - if the device supports the Bluetooth wireless technology, because this JSR is conditional mandatory in MSA - is that it will be mandatory to implement OBEX package as well. Got it? That means that you will be able to easily build applications that exchange cards, send images to printings, among other ones that use complex communication stuff, without having to care about low level implementations! Java ME plataform is so cool! We are growing! ;)

See you,

Bruno Ghisi

Related Topics >>