Registered: Mar, 2006
Re: After Seven Years, Are Devices Ready for Jini?
Posted: Mar 9, 2006 1:31 PM
- Jini has still nothing to offer when it comes to mobile devices. For Jini to be make a chance in the arena of mobile devices it has to meet the following requirements.
>>PsiNaptic: On the contrary. Jini has everything to offer to mobile devices. Having a small footprint of Jini Networking technology that can reside on the mobile device itself means that a device, user or vehicle can move from environment to environment (home, office, vehicle, other) and either offer or consume a service, peer to peer, on an ad hoc basis, without the need for human configuration and management.
This dynamic discovery and interaction between devices enables any mobile phone to come into proximity of any wired or wireless, intelligent computing device and and interact with it, without having seen it before.
Many leading handheld manufacturers are interested in enabling their devices to interact with other devices locally (device to device without accessing a website or server). Handheld manufacturers want their devices to multi-task and interact with many different types of devices such as a parking meter, vending machines (or any point of sale machine), vehicle telematic platforms or another handheld. With more than 65% (in 2005) of all mobile phones sold in Western Europe being Bluetooth enabled, and half a billion phones expected to be Java enabled by year end 05, consumers will be expecting their phones to be synchronize with more devices than just a headset, PC or PDA's.
There are many challenges to this vision. Having pre-installed software for each service, each device and each model is simply not feasible. PsiNaptic software products JMatos/CMatos ensures that the device gets the right software only when it needs it. This allows a user to consume a service in an ad hoc manner without having to install and maintain specific software on their device. Currently the client software must be specifically written and installed for each type/kind/model of device, limiting its capability. JMatos/CMatos leverages the ability of Java and the JVM to 'write once run anywhere', by providing the actual byte-code required by the client. This byte-code (or Object) is loaded and instantiated on the client and run locally.
In the case of a mobile device interacting with any POS machine, (both are Bluetooth or WiFi enabled) the mobile device may have never "seen" this POS machine before, but the user wants to purchase a soft drink. The POS downloads its driver/attributes/GUI's as a Java Object to the mobile phone. Mobile phone loads and instantiates the object and now has all the information it needs to transact with this particular machine, making a selection and offering payment. When the user walks away from the machine, the byte code is removed, freeing up limited resources on the mobile phone.
As large volumes of Internet content become accessible to mobile devices and, as new mobile-specific content emerges, it will become too overwhelming for users to manage all the available information and services. In the mobile Internet environment, the traditional web-based destination model will not be able to deliver compelling end user information and services. The greatest challenge for the mobile Internet is the management of a pervasive electronic presence to sense and respond to a customer's unique profile i.e. who they are, what they need, and their information and service preferences.
- Jini must be installed on the vast majority of the devices in the market. The value of a network rises exponentially with the number of connected nodes, they say, and the same goes for Jini networks. A single Jini device doesn't make much sense. Take a look at Bluetooth, it took a VERY long time before it became widely used. That was mainly due to the fact that Bluetooth was still a rare technology on most mobile devices. Now that Bluetooth is growing OLD (!) it is available on most new phone models.
>>PsiNaptic: A single device of any kind doesn't make much sense. Proprietary solutions are also loosing their lustre. The trend today is pervasive computing - creating ubiquitous environments based on open standards, such as Java. As with any other technology development, the true potential of this technology can only be realized through effective partnerships and alliances between manufacturers, systems and service providers across the mobile industry.
The issue with Bluetooth however, is trying to define attributes and behaviour for a plethora of devices that have very short life cycles. The benefit of adding JMatos or CMatos to a mobile device is that device interaction can be defined at an API level, and not at a protocol level.
With over a billion Java enabled devices on the market today, and the availability of a LUS (simply a software container where devices register their services to be found by Jini Clients) at less than 100k, any Jini Client (device with a JVM and capable of dynamic class loading) can discover and utilize an endless number of services. Note that the Jini Client in order to consume a service does not need to have J/CMatos running on it.
- Jini networking must work out of the box. Users don't have the patience when it comes to configuring their mobile devices as they do with desktop computers. The Bluetooth consortium learned this the hard way. And there are still many, many users that don't know how to turn on Bluetooth on their phone or how to 'pair' it to another device. If their phone was a Jini client/service provider, how do users have it interact with other services? Can it all be automated?
>>PsiNaptic: The point here is that the ‘users’ should not have to ‘interact’ with the services. Jini or otherwise. The users are interacting with the applications but it’s the applications that are using the services. Take an MP3 device entering a vehicle for example. The user should simply put the device on the sit beside him/her. As he interacts with the vehicle sound system there should simply be a longer list or songs or playlists for him to select from. There should be NO user interactions. No configuration depending on the make and model of the MP3. And yes, this can be automated.
- Jini should offer compelling advantages over existing solutions. Hooking up an iPod to an in-car audio system is a very dated and not compelling example. Bluetooth does that, wifi could do it, ultrwideband (of which wireless USB is an example) could do it. Jini could make use of these protocols, but would it really add something unique?
>>JA: Jini does offer compelling advantages over existing solutions. The example of the iPod and an in-car audio system was given because most people can relate to it. There are many others such as a mobile phone coming into proximity of a vending machine or entering into a vehicle or home. In each case, the mobile phone is able to "discover" and dynamically utilize the services intrinsic to each device/environment. The mobile phone can interact with the vending machine to pay for a ticket or product. In the vehicle, the mobile phone can discover and utilize the vehicles audio system, LCD screen or hands free system. Or enter into the vehicle and customize the vehicle to the users’ preferences such as adjust the seat, radio, telematic services etc. In the home, a mobile phone can wirelessly discover and utilize “home services” such as audio, security, lighting or HVAC system setting the users preferences for a radio station, security, lights or temperature.
However, currently, in order for two devices to interact, both must have pre-installed make, model, revision level specific software. Aside from application software, in the case of Bluetooth enabled devices, you have the added issue of a multitude of lagging Bluetooth profiles. There is for example, no POS Profile.
Managing, maintaining and supporting Bluetooth profiles, to keep up with all the new functions and features of mobile devices, is very challenging and costly. OEM’s can mitigate the development costs and time associated with creating, maintaining and validating/system testing multiple devices and their respective Bluetooth profiles, especially as the device manufacturers integrate new function/features. Because JMatos/CMatos utilize the standard and ubiquitous TCP/IP network stack for communication, application development for Bluetooth devices is significantly simplified. In addition, because JMatos/CMatos can offer an API implementation as Java byte code, the implementation can be downloaded and executed by a Jini client when needed. This simplifies application development for Bluetooth devices and future proofs applications that are no-longer dependent on profile specifications. With JMatos or CMatos and a PAN profile, you might not need any profiles!
JMatos and CMatos software offers a number of benefits for OEMs, application developers, service providers and end users.
Provides a mechanism for enabling a pervasive electronic presence that senses and responds to a customer-unique profile, allowing mobile users to automatically receive context-relevant services in a seamless manner across different networks (WAN, LAN and PAN).
Solves the interoperability and ease-of-use issues that currently exist with Bluetooth and other short-range communications technologies, thus supporting the deployment of compelling PAN services.
Allows applications to run in a seamless manner across mobile devices and other Java-enabled devices (i.e. POS terminals, TV set-top boxes, desktop PCs, etc.).
Enables automatic configuration of applications on mobile devices.
Enables automatic updates to applications on mobile devices. Jini technology can provide a non-proprietary mechanism to allow mobile device applications to integrate seamlessly into service provider and enterprise IT infrastructures.
- The example of Jini running ona a Nokia 9500 is misleading. The 9500 is more a PDA than a phone and runs the J2ME CDC instead of J2ME CLDC. This enables the phone to serialize Java objects. All Java phones (except 1 or 2) run CLDC and are therefore not suitable for Java's mobile code. This will not change over the coming, at least, 8 years. And when it changes, the nature of network connections on mobile phones (where connections are NEVER 'always on') make a great 'out of the box mobile jini experience' rather unlikely.
I think the real showstopper here is the lack of support for mobile code. Mobile code is the true value of Java if you ask me, but it is also something that won't be available on mobile devices in the foreseeable future. Without it, what is left of the Jini vision?
>>PsiNaptic: The example of Jini running on the 9500 is NOT misleading. It is a high end J2ME device – agreed, but it is a J2ME device. This clearly signals a significant milestone in driving Jini to smaller and smaller mobile devices. To call it misleading is ….. misleading. One of the realities in dealing with small, mobile devices, is that there is always a device that is smaller – the next goal if you will. Putting Jini on a Nokia 9500 signals that for the first time Jini is being offered on an industry standard J2ME device. Getting it smaller is only a matter of time.
Being a CDC device does in fact enable a phone to serialize (and marshall) objects, You will however find that the JMatos code released uses none of these features. It does not import java.io.serializable nor java.rmi.MarshalledObject. In anticipation of driving Jini to smaller JVMs, PsiNaptic invested time and effort in JMatos to implement serialization and marshalling, without using those libraries that are not available in smaller CDC and CLDC devices. This means that at least those 2 issues are not going to stop Jini from being driven down to even smaller mobile devices. My prediction is less than a year to have it on a standard CLCD JVM. It is amazing how little you actually need to move byte code around. After all, it’s already implemented in C.
We agree that code mobility is a real and unique value offered by Java and Jini. Not necessarily just the Write-Once-Run-Anywhere model, but the dynamic downloading and instantiation of new objects across the net is just such a mind boggling notion, that once you start to imagine, the possibilities are endless. The way we imagine this world is that you have devices that can offer services, devices that can consume services and devices that can do both. You do of course have devices that can not do anything but we’re getting down to very small (<40Kb memory) devices. When most people think of Jini and/or code mobility they think in terms of downloading code and using it onto their specific device. In this sense, you are correct - code mobility is not supported on most small JVM devices. The reasons are both technical and business (memory management issues and customer control), with the real problem more on the business side than the technical. Yet if you think of the device offering code instead of only consuming it, you come up with a myriad of new pervasive applications. Some of the most powerful are based on the concept of a “ReturnToSender’ design pattern. Simply put, this is the concept that the code delivered knows how to use or talk back to the application on the originating device. For example a mobile phone that is capable of no dynamic class loading whatsoever could still ‘say’ to other more capable devices
Here is code that will get a list of MP3 songs that I have, and to get the file if you want to play that song.
Here is code that will allow you to update my E-Wallet but only after the user Ok’s it.(POS applications)
Here is code that will allow you to read my calendar and give me directions to my next appointment.
Here is code that will allow you to send vehicle diagnostics via SMS to my garage.
Here is code that will allow you to play chess with me.
The list is only limited by your imagination. We think the Jini vision is seeing 20/20 on this one.