Programming Java 2 Micro Edition for Symbian OS 2004 (779882), страница 75
Текст из файла (страница 75)
Some popular choices are OMA Wireless Village, IETF SIP andIETF XMPP, which are all standard protocols. There are also proprietaryprotocols such as AOL, Yahoo and MSN. The selection of protocolstacks (which all run over TCP/IP) is implementation-specific: a mobilephone which is to be used with specific ISP services should provide theappropriate protocol stacks.JSR 229Payment API (JSR 229) enables application developers to initiate mobilepayment transactions in MIDlets. It defines a generic API to initiate payment transactions and the syntax to describe the associated provisioninginformation. This enables different payment instruments to be supported,such as operator charging, stored value accounts, or third-party paymentservices. Transactions can take place over a variety of transports, such asSMS or the Internet, though the JSR assumes a secure channel is available.JSR 211Content Handler API (JSR 211) will allow MIDlets to handle actions ona URI based on the MIME type or scheme.
So, for instance, clicking ona specialist audio file in a browser starts up the appropriately registeredMIDlet decoder. Further, an application can use the URI and/or MIMEtype to invoke another application. This will allow the applications to runsequentially, passing parameters and returning results.8.6.3 Symbian-Specific ExtensionsFigure 8.14 listed a number of potential Symbian specific extensions: telephony, persistence, ‘‘Send as’’ and common clipboard. Synchronizationused to be on this list, but fortunately Siemens initiated JSR 230, the Datasync APIs! Ideally all these APIs should be defined by standard JSRs.418THE MARKET, THE OPPORTUNITIES AND SYMBIAN’S PLANSWe have already discussed the need for persistence or database access.This could either be straight SQL, i.e.
a subset of JDBC, or an object store.Telephony APIs are needed to provide access to telephony-relatedfeatures (we are not discussing APIs needed to create a telephony client:that was the purpose of JTAPI). The functionality would include:• access to IMEI and IMSI numbers, which uniquely identify a mobilephone; this is especially useful for games and DRM – currently thebest a game can do is use the Wireless Messaging APIs to obtain thephone number• reacting to telephony events, e.g. to detect ringing events, call pickup,call termination and, importantly, caller id; this enables a MIDlet toidentify a caller and display a relevant contact card or other relatedinformation• providing information such as signal strength, battery level and powerstatus, IR and Bluetooth status• launching the mobile phone’s telephony application: this should notrequire a separate API as it should be achievable either from the userinterface using a TextBox or TextField with a PHONENUMBERconstraint, or programmatically using platformRequest().A ”Send as” menu option is provided in many Symbian OS applications, e.g.
Word, and is used to send the document via IR, Bluetooth,email, SMS, etc. The ”Send as” API would provide a MIDlet with thesame functionality and is part of making MIDlets first class citizens.The common clipboard API continues the theme of making MIDletsfirst class citizens. As the name suggests, it allows MIDlets to copy data toand from the system clipboard, in the same manner as native applications.8.7 Java and Digital Rights ManagementIncreasingly, suppliers of content such as games, videos, audio, othermultimedia material and applications in general, are keen to preventillegal use of the content or to control its use.
Digital Rights Management (DRM) is about how rights of use can be associated with content.Such rights could prevent a MIDlet suite being passed on to anothermobile phone, allow the game to be played only until a certain date,or allow a piece of music to be played only a set number of times. Seewww.openmobilealliance.org/tech/release.html for the specification, orwww.openmobilealliance.org/docs/DRM%20Short%20Paper%20DEC%202003 %20.pdf for a top level description.JAVA AND DIGITAL RIGHTS MANAGEMENT419The first phase, OMA DRM Version 1.0, is moderately easy to breakand is intended for low value content (simpler games and applications,or ringtones).
It consists of three options:• forward lock, which prevents content from being forwarded toother phonesThe content is downloaded within a wrapper and the wrapper has aMIME type which indicates that this content should not be forwarded(the wrapper header includes the MIME type of the content, forinstance, a video clip). It is then up to the platform to decide how tohandle this content to prevent forwarding, for instance by ensuringthat it is not installed in a user-accessible location or by encrypting itwith a hidden key.• combined delivery, which is similar to forward lock, except that thewrapper includes a rights objectThe rights object defines in detail how the content can be used, forexample the number of hours for which a game can be played, orhow many times a music track can be listened to. Again how this isimplemented is down to the platform.• separate delivery, in which content and the rights object are sentseparately.The content is encrypted into a DRM Content Format (DCF) file using aContent Encryption Key (CEK) – a symmetric key using the AdvancedEncryption Standard (AES) – and can then be downloaded over aninsecure channel such as the Internet.
However the rights object mustbe downloaded over a secure channel, for instance SMS, because itcontains the CEK (a bit like whispering a password in someone’s ear).The CEK is then used to decrypt the DCF file.MIDlet suites already come with JAD and JAR files, so that separatedelivery, for instance, would work like this:1. The user clicks on a URL in a browser, which, as for an unprotectedMIDlet suite, initiates the JAD download.2. The user decides whether to download the application based on theinformation from the JAD (cost, size, required support, etc.) as theywould for an unprotected suite.3. The JAD, rather than pointing to a JAR file, points to the DCF filecontaining the JAR, which is then downloaded by the platform’sDCF recognizer.4.
Meanwhile, WAP push is used to send the rights object to the phone,where it is used by the installer to decrypt the DCF file, extract theJAR file and install the MIDlet suite.420THE MARKET, THE OPPORTUNITIES AND SYMBIAN’S PLANSThe second phase of OMA DRM should be finalized by the middleof 2004. It will offer more security, making it suitable for higher valuecontent. It will encrypt both the rights object and the content encryptionkey with the phone’s public key, binding them to the phone. Both thecontent and the rights object will protected against tampering through theuse of hash keys.Symbian provides APIs for the OMA DRM Version 1 specification.Content publishing tools for use with the Nokia 6600 and Sony EricssonP800 and P900 are available from the respective manufacturer’s website.8.8 The Java Verified ProgramThe Java Verified program (www.javaverified.com) is intended to testthe basic functionality of a MIDlet: does it start, does it stop and exitgracefully, does it hog bandwidth or other resources? It does not checkconformance with corporate branding, nor does a pass or fail depend onwhether or not the MIDlet is socially acceptable, though unacceptablecontent will not be allowed to use the Java logo.The members of the program are Sun, Motorola, Nokia, Siemensand Sony Ericsson.
Sun host a portal where developers can registerinformation about the MIDlet they want verified. The program will notgenerate revenue, indeed the only transactions are between the developerand the test house (the website provides details of test houses and pricing).Most of the verification can be carried out by the test house and this iswhere most of the work has to be done. However, the last 10 % iscarrier-specific, e.g.
the type of download server, billing wrapper, or anyDRM implementation.The scope of the program is currently limited: it is for untrustedMIDlets only and is aimed at the service provider, operator, or aggregatorwho wants to provision the MIDlet. The provider receives the MIDletencrypted and uses a public key supplied by the program to decrypt itbefore publishing it. The provider is thus assured that the MIDlet has beenthrough the Java Verified program, that the author is who he claims to beand that the MIDlet has not been tampered with since testing.The end-user downloads the unencrypted MIDlet to a mobile phoneand may have no knowledge that the MIDlet has been through theprogram.
This is in contrast to the Symbian signing program for nativeapplications, which delivers signed MIDlets to the mobile phone.It is to be hoped that in the near future the program will create aPublic Key Infrastructure (PKI) that will be agreed by all parties: operators,mobile phone manufacturers and developers. This will provide a signingmechanism so that developers can create trusted, signed, MIDlets thatcan offer more interesting services.TRENDS IN TECHNOLOGY4218.9 Beyond Advanced Consumer ServicesWe’ve talked about services mainly in the context of a client running ona mobile phone talking to back-end services (JSR 172 will be importantin delivering such services).
However there is potentially a bigger opportunity for what might be called ‘‘ubiquitous services’’, where services areprovided by many small embedded devices such as home appliances,drinks machines, teller services, even light switches. The service mightbe executed on the device, or loaded onto the mobile phone and run asa MIDlet. There is also no reason why mobile phones themselves cannothost and share services.To achieve these ubiquitous services we need an infrastructure thatcovers:• service registration: the ability to register a service for discovery byother devices, mobile or otherwise• service discovery: this could be by the user searching through abrowser type interface, or by an application searching for a particulartype of service• remote service access: this can be achieved by JSR 172 and SOAP(though SOAP may require too much bandwidth for wireless networks)• service lifecycle: existing technologies are probably adequate forservice start up (e.g.
push technology from Bluetooth, WAP or MIDP),however, many services will be transient and should be deleted afteruse; this would have to handled by the system AMS, perhaps inresponse to a message• transfer of executable content: once a service has been discovered, itcan be transferred as a MIDlet using OTA-type protocols and executedon the mobile phone.OSGi provides a partial answer (see, for instance, Mobile OperationalManagement (JSR 232)). However, this is a very heavyweight option andis only applicable to CDC.
The Bluetooth discussion in Section 8.6.2.1gives an idea of how we can enable ubiquitous services today or in thenear future.8.10 Trends in TechnologyTo end this chapter (and the book), let us gaze into a crystal ball, startingwith the technology:• CPU power will continue to increase in accordance with Moore’s law• combinations of software and hardware acceleration will remove thegap between Java and native performance422THE MARKET, THE OPPORTUNITIES AND SYMBIAN’S PLANS• network bandwidth will improve, though not so dramatically• network connections will always be available, reducing latency• costs for persistent storage will continue to tumble and access speedswill increase dramatically as new memory technologies, such asFerroelectric RAM, Magnetic RAM and Ovonic memory, replaceNOR and NAND flash• the resolution of screen displays will continue to improve, through adecrease in dot pitch as screen sizes will be limited by overall mobilephone ergonomics.There will also be market changes:• ”smart houses” will become a reality: climate control, entertainmentand security systems will be controlled by a variety of devices,including mobile phones• digital consumer goods will converge.Today, video cameras can take still images and digital cameras can recordvideo, and quite often both include MP3 players.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
