Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
After Seven Years, Are Devices Ready for Jini?

8 replies on 1 page. Most recent reply: May 3, 2007 5:44 AM by Zhi Quan Lee

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 8 replies on 1 page

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

After Seven Years, Are Devices Ready for Jini? (View in Weblogs)

Posted: Mar 3, 2006 8:59 PM

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?

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:

Today devices can offer Jini services via embedded lookup services even if they don't run Java.
Jini clients still generally need to run J2SE, but in many cases this will be practical, for example, in point of sale terminals, PDAs, and car dashboards.
Although Jini in 1999 offered no security beyond Java's inherent security model, Jini now comes with a comprehensive network security model.
Whereas in 1999 Sun licensed Jini under a somewhat complicated SCSL license, which initially required payment to Sun for deployed Jini-enabled devices, the Jini Starter Kit from Sun is now free as in both free speech and free beer. It is available under the Apache 2.0 License, and costs nothing to use.

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.

Resources

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 http://www.psinaptic.com/dev_community.jsp

Berco Beute

Posts: 72
Nickname: berco
Registered: Jan, 2002

Re: After Seven Years, Are Devices Ready for Jini?

Posted: Mar 6, 2006 2:16 AM

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.

- 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.
- 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?
- 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?

None of these requirements are met and so we can still declare Jini dead in the water when it comes to mobile devices.

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?

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: After Seven Years, Are Devices Ready for Jini?

Posted: Mar 6, 2006 8:10 AM

I still see a few hurdles in the way of Jini's broader adoption.

First, how does multicast discovery work in the context of mobile devices? For instance, would a cell phone network forward multicast packets, such as Jini discovery requests? If not, then how would Jini discovery work?

Second, mobile code is not only not well supported in mobile devices, but is also not well understood by most developers. As a result, most developers prefer to invoke networked resources via communication protocols. Jini requires both a communication protocol that places strong demands on the network (the Jini multicast discovery protocol, for instance, requires IP multicast), and mobile code, i.e., the ability to deserialize Java code in the client's VM. Many developers prefer having to deal with just a communication protocol, and one that places less demands on a network infrastructure, e.g., HTTP. Again, this may change as mobile code gains better support on small devices.

Third, I'd like to understand why folks so often confuse the purposes of Jini and those of J2EE. J2EE is a distributed transaction processing architecture, i.e., a Java facade on a transaction processing infrastructure. Jini, on the other hand, is a distributed computing tool for Java. While transaction processing does often become distributed, and while Jini also provides a distributed transaction coordinator, the two technologies are complementary, not competitive.

After several years of involvement in the Jini community, I still hear that one reason for Jini not taking off in the manner of J2EE has to do with Sun promoting J2EE at the expense of Jini. That may be true only in the sense of a finite marketing budget being allocated to J2EE more than towards Jini, but I don't see why, on a technical level, J2EE's popularity somehow disadvantages Jini.

There are many reasons for J2EE's popularity, and this is not the place to discuss those. But among them are excellent tools support, multi-vendor implementations, developer education, etc. Perhaps we in the Jini community should take a page or two from the J2EE playbook, insteading of somehow thinking of J2EE as a threat to Jini.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: After Seven Years, Are Devices Ready for Jini?

Posted: Mar 6, 2006 9:15 AM

> 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.
>
> - 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.
If this were true then nothing would ever emerge to make this kind of spontaneous networking a reality, because it would first have to be installed everywhere. And until it is installed everywhere, by this logic, there is no point to installing it anywhere, because it isn't already installed everywhere. It is the chicken and egg problem I mentioned in my post, and it definitely is a hurdle for any contendor in this space, but despite it there's still the cases in which some person or group controls all parties to the interaction being designed. In that case, they could choose Jini or any other technology that's not ubiquitous, because whatever they choose they can install on everything that will be participating in the interaction -- a closed system.

> - 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?
>
That's a good question. My only guess is that wouldn't Jini offer the same cost/benefits it has offered to people who have used it in enterprise and scientific settings? It solves problems inherent in designing distributed systems so that you don't have to.

> 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.
>
I didn't mention it in the article, but PsiNaptic didn't use the CDC serialization in his implementation. They rolled their own serialization, and said that the reason they did that was because they want to push this down further to CLDC. What they've shown is that CDC (and likely CLDC, and even non-Java) devices can offer a lookup service, and through that lookup service offer their own services to the network and accept registrations from the outside. The little lookup service on the Bluetooth chip doesn't accept registrations because of limited memory resources, but the others they have do. As far as external registrations go, the lookup service doesn't need to deserialize them. It just stores the serialized images, does matches on those images, and returns them on lookups.

Cameron Roe's point is that, even though this isn't the full on Jini vision because these devices can't consume Jini services, they can offer them to devices that can. In other words, today a device could offer its own Jini services, plus a lookup service, to the network--not only with or without serialization support, but also with or without Java.

> 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 would think this kind of unstable networking environment would actually show the benefits of Jini, which makes it easy to deal with that kind of network flakiness.

> 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?

Right now I see it making sense to consider only in closed systems, in which some of the parties to the interaction can handle full-on J2SE and mobile code.

Hamzh Tarajia

Posts: 2
Nickname: croaky
Registered: Mar, 2006

Re: After Seven Years, Are Devices Ready for Jini?

Posted: Mar 7, 2006 5:29 AM

I think because of the over shadow of J2EE, impressive technologies Like Jini have been steered away in the wrong direction, also pushing physical devices aside for the moment, even for normal server enterprise systems using JavaSpaces as an abstraction on top of jini works very impressive. As the convergence of multi channel delivery of TV, Phones, PDA's and the internet the distribution of content and resources across al these medium's as peer 2 peer clients can be achieved quite transparently. Majority of techys; are very use to working with RPC based models and when a technology Like Jini advocates a different trail of thought from the norm... there is suddenly hmmn and hah's in the air. I have used Jini/JavaSpaces in Many projects and it has worked wonders for me, and has enabled me to overcome parallel processing problems and provides a true distributed set of working resource within the network. Yes I do believe there are many improvements that can be made, but fournatley there are companies like GigaSpaces, IncaX, IntaMission and of course the JiniStarter KIT who have provided very reliable and impressive products within the market for Jini/JavaSpaces. I believe the way technology is forming and moving forward there will be large space for Jini even it runs in a very stealth manner under the covers.
Thanks!

Judith Arato

Posts: 1
Nickname: juditha
Registered: Mar, 2006

Re: After Seven Years, Are Devices Ready for Jini?

Posted: Mar 9, 2006 10:31 AM

- 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.

Hamzh Tarajia

Posts: 2
Nickname: croaky
Registered: Mar, 2006

Re: After Seven Years, Are Devices Ready for Jini?

Posted: Mar 9, 2006 11:27 AM

You Go Judith, totally behind you.

Gavin Sallery

Posts: 1
Nickname: gbsallery
Registered: May, 2006

Re: After Seven Years, Are Devices Ready for Jini?

Posted: May 23, 2006 3:27 AM

Slightly off-topic, but the mention of PsiNaptic reminded me: has anyone managed to download the JMatos implementation for TINI recently? I tried the other day, and it gave me a zipped archive of the code for an iPaq :-/

Gavin

Zhi Quan Lee

Posts: 4
Nickname: furryfren
Registered: May, 2007

Re: After Seven Years, Are Devices Ready for Jini?

Posted: May 3, 2007 5:44 AM

Is there a tutorial for JMatos? I've put the NSJMatosPP jar file on my PDA running creme JVM. Running this gives me a simple GUI with a single exit button - nothing else. I'm trying to invoke the service browser on my PDA to look at the services provided on the network. Any pointers?

I watched the CMatos chip video demonstration and I noticed that they have a Jini service browser on the iPAQ. How do I get hold of this?

Flat View: This topic has 8 replies on 1 page

Previous Topic

Next Topic