|
|
|
Sponsored Link •
|
Summary
Sun's original marketing message that positioned Jini as a technology for devices backfired in 1999, because at that time many barriers existed that prevented the vision from becoming reality. Seven years later, how many of these barriers remain?
|
Advertisement
|
In January of 1999, Sun announced Jini technology and enthusiastically positioned it as a way for devices to spontaneously find and interact with other nearby devices. I believe this approach to explaining Jini was taken in part because J2EE was successfully being marketed as Java for the enterprise, and they didn't want to confuse that message by talking about Jini in an enterprise context. Additionally, showing devices spontaneously connecting to each other seemed a good way to explain what Jini did. In retrospect, however, this approach was a mistake because everyone got the message that Jini was about devices, and that use case didn't materialize. As a result, most developers seemed to conclude that Jini had failed and didn't give it any further consideration.
Despite its initial device-oriented marketing, Jini did find a home in other kinds of applications, mostly in enterprise settings. Although the applications have been varied, one theme has been constant: Jini has been used in situations where the developers using Jini controlled the entire Jini network. At a minimum, Jini requires a lookup service to be present on the network to enable Jini services to advertise themselves and Jini clients to find them. It was once imagined that such Jini infrastructure might become commonplace in public spaces, facilitating spontaneous networking among devices communicating via standard interfaces. As neither a ubiquitous public infrastructure, nor many standards for Jini service interfaces, emerged, it has made sense to use Jini only if you provided the whole system—clients, services, interfaces, and infrastructure—yourself.
Another common theme among deployed Jini solutions is that Jini has primarily been used to facilitate dynamic networking of software running on servers and, in some cases, desktop computers. This highlights one of the big problems with Sun's original marketing strategy for Jini: Jini runs on J2SE. If you downloaded Jini from Sun in 1999, it required J2SE. If you download the Jini Starter Kit from Sun today, it requires J2SE. Claiming that Jini would be "ubiquitous" on devices within a year, as a Sun executive did during its splashy launch in 1999, ignored the major issue that not only did vast numbers of devices not run Java, those that did ran J2ME, not J2SE.
A few years back at a Jini Community meeting in Boston, however, a fellow named Cameron Roe from a small Canadian company called PsiNaptic showed a tiny chip offering Jini services and ServiceUIs to a nearby PDA over a Bluetooth connection. I found three things amazing in this demo. First, Cameron had found a way around the problem of needing to find a lookup service to offer services in a world without a ubiquitous public Jini infrastructure. The device provided its own lookup service for the purpose of offering its services to the rest of the network. Second, the chip was sending ServiceUIs across the Bluetooth connection to the PDA, which meant that software I wrote was running in the demo, which was cool. Third, not only did the tiny chip offering these services through its own lookup service not run J2SE, it didn't run J2ME or Java of any flavor. This lookup service was written in C.
I had never imagined a Jini lookup service could have been written in C, but it turns out that a lookup service never needs to deserialize the Java objects sent to it. It only needs to store them in serialized form, perform matches on those serialized images, and return them during lookups. The lookup service does need to serialize and send its own ServiceRegistar proxy to clients that request it, but this can be accomplished through minor (though technically tricky) manipulations of a static serialized image, such as inserting the current IP address of the device in the appropriate places. In one innovative engineering gesture, Cameron and his team had lept over two of the major hurdles to that original Jini vision: lack of a public Jini infrastructure and Jini's dependency on J2SE.
To be a client of these services, you still need to be able to deserialize unknown classes. So on the client side, the J2SE requirement still holds. I spoke with Cameron yesterday, and as he put it, "If the device can offer services, it gets you a long way towards the Jini vision. They don't necessarily have to consume services." Cameron described a scenario in which you take your iPod (or PDA or cell phone) into your car, and over a Bluetooth IP connection the device can offer MP3 services to the car. In this case, the car would be running J2SE.
Last week I received a press release that PsiNaptic had put a Jini lookup service on top of J2ME on a Nokia 9500 cell phone. This lookup service (called JMatos) is written in Java. What occurred to me when thinking about PsiNaptic's latest announcement was that many of the problems that blocked Jini's adoption on devices in 1999 have since been removed:
The main hurdle that I see remaining is the chicken and egg problem of if no one else uses Jini on devices, there's no point to me using it, because my devices won't be able to connect to anything else. Nevertheless, I think it makes sense to consider Jini on devices today in contexts where you (or you and your partners) control all parties to an interaction. I've spoken with quite a few people who have deployed Jini in enterprise contexts, and one common theme among all of these conversations was that Jini helped the developers move faster because it solved hard problems inherent in distributed systems design, such as how to discover services on the network, detect failure, and dynamically adjust to compensate for failure and other forms of change. Similar to the way people have deployed Jini in enterprise contexts by providing and managing all Jini clients, services, and infrastructure, if your devices form a closed system, you may be able to use Jini to help deal with the hard problems of building distributed systems.
What do you think of Jini's chances on devices now that times have changed? Is it too late, or could Jini have a second coming in the device space? See Talk Back! below for a link to the discussion for this post.
Here's a zip file containing a wmv video of a demo similar to the one that knocked my socks off in Boston. I believe this version was made for James Gosling, but you can watch it too:
http://www.psinaptic.com/download/CMatosforBluecore2DemonstrationVideoWindows.zip
Jini Community website:
http://www.jini.org/
PsiNaptic's Developer Community site
Have an opinion? Readers have already posted 8 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Bill Venners adds a new entry to his weblog, subscribe to his RSS feed.
 | Bill Venners is president of Artima, Inc., publisher of Artima Developer (www.artima.com). He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Active in the Jini Community since its inception, Bill led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill is also the lead developer and designer of ScalaTest, an open source testing tool for Scala and Java developers, and coauthor with Martin Odersky and Lex Spoon of the book, Programming in Scala. |
|
Sponsored Links
|
Digg
del.icio.us
Reddit