Java APIs Target Mobile Scanners, RFID

Two new JSRs that would help Java support poised-to-explode RFID and remote inventory sectors are under review by the Java Community Process. JSR 256 and 257, spearheaded by Nokia, continue to push J2ME to the forefront of JCP activity, with 8 of the last 11 JSRs based on J2ME/mobile devs. Take a look at how these JSRs could boost mobile IT prospects in 2005.

Tags: Sensor, Communication, JSR, Sensor API, RFID, Contactless Communication, Applications,


Two new JSRs that would help Java support poised-to-explode RFID and remote inventory sectors are under review by the Java Community Process. JSR 256 and 257, spearheaded by Nokia, continue to push J2ME to the forefront of JCP activity, with 8 of the last 11 JSRs based on J2ME/mobile devs.

A summary of both proposals (JSR 256 and 257) follows. The JCP's current schedule calls for an "early draft" of both K2ME JSRs to be issued in Q1 2005.

JSR 256 -- Mobile Sensor API
JSR 256, as described by the JCP, takes up the challenge of "developing a standard way of manipulating sensors for J2ME applications." Led by Nokia, this specification will define unified way to manage sensors and access sensor data. Generic functionality is included in the Mobile Sensor API to serve all sensor types. The application developers will be able to write applications easily without utilizing a number of non-standard and proprietary approaches for communicating with sensors.

JSR 256 reads, in part:
The [proposed] API provides general Sensor API that extends the usability and choice of sensors for J2ME applications. It defines generic sensor functionality optimized for the resource-constrained devices like mobile devices.

A sensor can comprise of many kind of devices from microphone and camera with pattern recognition to heart rate monitor and thermometer. Sensors and the data they provide may differ greatly from each other. The communication model and protocol are usually different for different sensors as well. The application that wishes to utilize sensor data typically performs following operations with a sensor: - Sensor detection (discovery). - Sensor activation and calibration. - Data capture (sampling initiation, data fetch, data processing (including e.g. filtering, calculations)). - Sensor deactivation. From the application point of view, receiving raw data from a sensor is an easy task. However, when it comes to gather data from many sensors at the same time and utilize it, it turns into a complicated, not straightforward job. Device resources, required to handle lots of signals from sensors can hurt the whole system performance seriously. Well-formed sensor API will resolve the situation. It will abstract the configuration procedure and the data format in a standardized manner and help to maintain the system performance.

JSR 257 -- Contactless Communications API [RFID]
JSR 257, as described by the JCP, "looks to fill the [lack] of standardized APIs for contactless communication based for example on RFID, NFC or bar codes in Java applications." As currently proposed, JSR 257 would set the stage for both one-way and bi-directional data capture and data integration from RFID, barcode and other existing and standard approaches. Also, JSR 257 would use MIDP 2's General Connection Framework as the common framework for input/output operations [and] for connecting to external resources.

JSR 257 reads in part:
This specification will define J2ME Optional Packages for contactless communication, one package for bi-directional communication and the other for accessing read-only information. Contactless communication can be used to provide a small amount of information to applications from some other medium, for example, links to some content or identifiers for services etc.

The [proposed J2ME] API is targeted for resource-constrained devices such as mobile phones or consumer electronic devices, and it must be memory-efficient. This JSR will define two optional packages in a way that it is possible for a device to implement either read-only contactless communication (e.g. bar code reading) or bi-directional contactless communication (e.g. NFC) or both of them.

Contactless communication can be based on (e.g., Radio Frequency Identification [RFID], Near Field Communication [NFC] or bar codes. NFC mode can be used for exchanging small amounts of information between two NFC-enabled devices. RFID readers and tags do not need a visual contact but only close proximity between the reader terminal device and the tag. Some RFID tags can be also written and the data contained in them updated. Bar codes can be printed; e.g., in adverts in magazines and newspapers, or on product packaging or for use at points of sale.



back