13.07.2015 Views

JDJ 10-1.indd - sys-con.com's archive of magazines - SYS-CON Media

JDJ 10-1.indd - sys-con.com's archive of magazines - SYS-CON Media

JDJ 10-1.indd - sys-con.com's archive of magazines - SYS-CON Media

SHOW MORE
SHOW LESS
  • No tags were found...

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

FeatureJAVA TECHNOLOGYToys or tools?FORTHEWIRELESS INDUSTRYby David Parsons, Ilan Kirsh,and Mark CranshawDavid Parsons is asenior lecturer ininformation <strong>sys</strong>tems atMassey University, Auckland,and a knowledge engineerfor S<strong>of</strong>tware EducationAssociates, Wellington.Until last year he wasthe director <strong>of</strong> emergingtechnologies at Valtech,London, and prior tothat, principal technologistat BEA Systems.d.p.parsons@massey.ac.nzThe Java Technology for the Wireless Industry specification(JTWI) encompasses a standard set <strong>of</strong> J2MEAPIs for mobile device development that is beingwidely adopted by mobile telephone service providers,making it an important platform for Java developers.Its core component, the Mobile Information DevicePr<strong>of</strong>ile (MIDP), provides a number <strong>of</strong> specialized librariesfor multimedia and games development; however,its underlying subset <strong>of</strong> general purpose Java classes isstrictly limited. In addition, support for persistence viathe Record Management System is relatively poor. Thisraises an important question: Is JTWI a realistic applicationdevelopment tool or is it only good for games andother s<strong>of</strong>tware trivia?In this article, we try to answer this question by exploringthe viability <strong>of</strong> MIDP as a tool for nontrivial applicationdevelopment. An enterprise application that includesmobile components might reasonably expect to devolvesome <strong>of</strong> its business processes and data management tomobile devices. Our chosen example, which <strong>con</strong>siders both<strong>of</strong> these aspects, is a proposed implementation <strong>of</strong> the JavaData Objects (JDO) specification. This includes a number <strong>of</strong>interesting features that highlight the <strong>con</strong>straints <strong>of</strong> workingwith J2ME APIs for limited devices. We describe the issuesaround the development <strong>of</strong> such an implementation andthe limitations that MIDP imposes, suggest some usefulworkarounds and architectural options, and finally drawsome <strong>con</strong>clusions about the usefulness <strong>of</strong> JTWI as a set <strong>of</strong>APIs for serious application development.IntroductionHandheld computers, such as the Pocket PC and the Palm,can support reasonably complete Java Application ProgrammingInterface (API) sets that can be used to develop seriousenterprise applications. However, smaller devices, such asmobile telephones, only support Java APIs that have beensignificantly reduced to work within the <strong>con</strong>fines <strong>of</strong> limitedhardware. There is no support for the types <strong>of</strong> persistencemechanisms that we have come to expect on larger Java platforms.The question we address in this article is whether themobile telephone is a viable platform yet for serious businessor scientific applications that need to store and process datalocally and that expect the services <strong>of</strong> a reasonably rich set <strong>of</strong>Java APIs.To date, we have seen <strong>con</strong>siderable development inareas such as mobile games development, but more seriousbusiness and scientific applications will need to be developedif JTWI is to be a useful component <strong>of</strong> enterprises<strong>of</strong>tware <strong>sys</strong>tems. Since such <strong>sys</strong>tems are likely to require<strong>con</strong>siderable support for persistence, we focus on the JDOspecification and examine some potential issues that arisewhen attempting to implement this specification usingMIDP. We extrapolate from this analysis to assess the generalusefulness <strong>of</strong> MIDP as a general purpose applicationprogramming platform. We also look at how MIDP devicesfit into larger distributed architectures that can mitigatethe limitations <strong>of</strong> mobile telephones as Java applicationplatforms.The Java 2 Micro Edition (J2ME)To cater to a wide range <strong>of</strong> small devices and applicationrequirements, the J2ME architecture (see Figure 1) providesmultiple <strong>con</strong>figuration and pr<strong>of</strong>ile layers that overlaythe specialized Java Virtual Machine (JVM) and operating<strong>sys</strong>tem. Configurations define the minimum set <strong>of</strong> availableJVM features and class libraries for a specific category<strong>of</strong> device and are hardware focused; pr<strong>of</strong>iles define the set<strong>of</strong> APIs available for a particular market category <strong>of</strong> devicesand are s<strong>of</strong>tware focused.J2ME <strong>con</strong>figurations specify the minimum requirementsfor memory, Java language features, JVM support, andruntime libraries. There are two standard J2ME <strong>con</strong>figurations:the Connected Device Configuration (CDC) and theConnected Limited Device Configuration (CLDC). For thesmallest portable devices, such as mobile telephones, thestandard <strong>con</strong>figuration is the CLDC. This <strong>con</strong>figurationrequires a very small virtual machine, such as Sun’s KVM(Kilobyte Virtual Machine) or CLDC HotSpot Implementation,with footprints <strong>of</strong> only about 50–80K. These virtualmachines don’t have to comply with the full JVM specification,nor do they have to support the complete Java languagespecification. API support is limited to a selection<strong>of</strong> classes from a few packages from the Java 2 StandardEdition (J2SE), plus the Generic Connection Framework(GCF), comprising a hierarchy <strong>of</strong> <strong>con</strong>nection interfaces(and the Connector factory class) that are intended toprovide a generic way <strong>of</strong> expressing operations on <strong>con</strong>nectionsregardless <strong>of</strong> the actual protocol.30 January 2005www.<strong>SYS</strong>-<strong>CON</strong>.com/<strong>JDJ</strong>

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!