Bruno Ghisi's Blog

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

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

Comments

• The subject of a very wonderful and distinct
  I thank you for continuing excellence
  Thank you

  =========================================================================

  ليبيا
  شباب ليبيا
  libya
  منتديات
  منتديات ليبية
  غرائب وحقائق
  أحاديث شريفة
  برامج اسلامية للجوال
  مفاتيح الديجيتل
  الشيرنج
  الرسيفرات
  كتب إسلامية
  خلفيات للموبيل
  الشعر الشعبي
  الصحة والطب
  طب اسنان
  كتب طب اسنان مجانية
  برامج طبية
  تعلم الإنكليزية
  اللغة الفرنسية
  طب الإعشاب
  الخواطرالادبية
  الازياء والمكياج
  تعليم الطبخ
  الاثاث الحديث
  مقاطع كرة قدم
  المصارعه الحرة
  اهداف كوره
  الفوتوشوب
  اروع البرامج
  الدوري الليبي
  خلفيات رياضية
  المصارعة
  كورة عربية
  كرة قدم عالمية
  الدوري الإيطالي
  الدوري الاسباني
  الدوري الإنجليزي
  صور المشاهير
  انواع الحلويات
  افلام كوميدية
  احدث الافلام
  افلام
  التقنية
  تحميل افلام
  برامج
  اخر برامج الجوال
  kaspersky
  أفلام كرتون عربية
  برامج برامج كمبيوتر
  برامج حماية
  برامج اختراق
  برامج صوت
  برامج تحميل برامج احدث البرامج
  محادثة
  خلفيات الطبيعة
  برامج مبايل للتحميل
  اخبار الفن
  احدث الافلام للتحميل
  تحميل افلام رعب
  ترجمةأفلام
  الكامات
  برامج جوال
  برامج محاسبة
  برامج
  kasper
  games
  برامج
  برامج
  انترنت
  برامج صوتية
  شبكات الحاسوب
  خلفيات للويندوز
  تطويرالمواقع
  العاب
  العاب الفيديو
  games
  شفرات
  برامج مسنجر
  خلفيات شاشة
  صور ترحيبيه
  الفوتوشوب
  خلفيات طبيعة
  تطويرالمواقع
  الفوتوشوب
  مقاطع البلوتوت
  مسجات ليبية
  خلفيات
  الفلاش
  التصميم الثلاثي
  برامج الجوال
  العاب الجوال
  فيديو كليب
  مسجات
  ترددات ستالايت
  نغمات
  

  Posted by: libyan on May 30, 2008 at 01:42 PM

• Hi Gregory, I got your point!

  Let me explain my view... optional packages were a good way to make Java ME technology grows in a kind. While devices were so different, they had to create a way of make them compatible with the market growing (better devices with more stuff, with less, expensive, cheap ones, ... for all kinds!) , as well as providing a technology evolution with new JSRs. But, as you know, this context of differences brings a lot of problems, it is so difficult for developers create an application that runs in a lot of devices.
  The idea of MSA is standarize things, so it will reduce some of its problems and Java ME will get strong! It was mostly created because of the market demmand as well (we have to improve our applications and make they run in everywhere! Mobility is the future!), making an interest intersection between consumers, operators, manufacturers and developers.
  MSA also defines a configuration (CDC or CLDC) and a profile (MIDP 2.1 and, for example, any later version that is compatible, like MIDP 3.0) in the bottom. So in the top, we will get all the JSRs that will help us during the development. All that ones that will make things easier with less worry! But do not forget, MSA will keep evolving with new releases, always growing!
  MIDP is a fundamental component of MSA. MIDP is something indepedent, probably it will be able to run in other small devices, after mobile starts running CDC. That is why I think it is more interesting to have an independent specification in order to standarize stuff, like MSA. Imagine MSA like an application environment, where devices will come with a label MSA-compliant! Take a look in a JavaOne session about MSA, it is a cool pdf!

  I liked your comment! Really good point! We have to discuss for the best of Java ME!

  All the best!
  Bruno

  Posted by: brunogh on May 26, 2007 at 04:39 PM

• To be honest, I'm not entirely sure why the people who are standardizing MSA didn't simply mandate MSA as the 100% requirement for MIDP3.0. While I like the idea of optional APIs, the seeming flood of optional APIs makes life very difficult for application developers. I think that now is the time for us to pick a core set of functionality for MIDP3.0 that makes our lives easier and make them absolutely required in order to be MIDP3.0 compliant. Sometimes I wonder if the people who choose to make some of these things optional actually write code for the JavaME platform.

  Posted by: gregorypierce on May 25, 2007 at 04:27 PM

• In my opinion Java ME future depends of initiatives like MSA, today is very hard to implement professional systems in Java ME due to the differences between each mobile phone java support. And of course, with the JSR 82 support, Marge can be everywhere!
  

  Posted by: phmichels on May 24, 2007 at 07:33 PM

• You are! ;-)

  I want a mobile device in the top of the JSR 238 floor in that first MSA structure tower!

  Posted by: anielson on May 24, 2007 at 07:12 PM

• We hope industry makes it devices MSA compliant.

  Posted by: lucastorri on May 22, 2007 at 08:57 PM

This work is licensed under a Creative Commons License.