I can give you an example that I heard from somebody else. Lets say you have a report to hand in to a client in miami and you are on your way via plane, you realize you forgot to print out the report so what you do is use your laptop, cell phone or some other device and do a search for avaliable printers in miami you send the document through the network to the printer you chose to print it, it will be printed and you can pick it up and pay for it. ------------------ I wish there was a button on my monitor to turn up the intellegince. Theres a button called 'brightness' but it doesn't work
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
As an alternative view: Jini is an implementation of a complete rethink of the way distributed systems work, with the intention of producing distributed systems which work reliably even if individual systems are added, removed or changed, and which allow sutomatic and flexible "discovery" and use of services provided by the systems in the network. While this can be used for the sort of 'plug my PC into the hotel network and discover what services are available' scenario discussed above, it's actually capable of far more. Traditional distributed systems tend to hard-code a lot of knowledge about the structure and capabilities of the individual systems. Just think about all those CORBA and RMI IDL files and their products, and all the hard-coded machine names or dependencies on the structure of nameservers and all the complete duplicate clusters as the only practical fallback systems and all the driver version and configuration issues ... Jini is different. Jini is dynamic and works without any of these dependencies. When a device or application joins a Jini system it requests information about how the system is arranged, then maybe publishes some services, or asks about some others. When a device or application uses a service, it doesn't get some sort of perpetual connection, but instead gets a "lease" which must be periodically renewed to make sure both partners (the service provider and the service consumer) are still willing and able to carry on. Drivers are not a problem, as the service provider is able to just hand over a serialized object which the client can use to access the service.
<a href="http://www.kedwards.com/jini" target="_blank" rel="nofollow">Keith Edwards</a><br />xerox palo alto research center<br />author of: <a href="http://www.amazon.com/exec/obidos/ASIN/0130894087/keithedwards" target="_blank" rel="nofollow">Core Jini</a><br />Which is also available as <a href="http://www.amazon.com/exec/obidos/ASIN/0130863866/keithedwards" target="_blank" rel="nofollow">A Video Course</a><br />Read an Example Chapter - <a href="http://www.javaranch.com/bunkhouse/samps/Core_Jini_chap3.pdf" target="_blank" rel="nofollow">Chapter 3</a> or <a href="http://www.javaranch.com/bunkhouse/samps/Core_Jini_chap10.pdf" target="_blank" rel="nofollow">Chapter 10</a>.
I looked at other replies at javaranch and found that I could find some basic info at the SUN site, but please keep me in mind for the book, it sounds like a good thing to know if you are interested in programming with RMI. Thanks.
MS,MS,SCJP,SCBCD Seize the day!
Joined: Jan 02, 2001
Originally posted by tracey, currier: As far as trying to set up a simple example using JINI, can you use classes and interfaces like RMI?
Absolutely! In fact, you can even use the RMI stub object for your service as its Jini proxy (see the link to Chapter 3 for more details). RMI is the simplest way to build Jini services and clients. -keith