Since 1999, Sun Microsystems Inc. has been telling the market that Jini, its dynamic network communications architecture, was designed mainly for devices. Now the company is repositioning the technology, saying that it’s also a suitable framework for developing and publishing software services.


read more @ http://www.sdtimes.com/news/049/emb1.htm

Not too familiar with JINI -- what is the basis for comparison for the "driver" example? For example, I know that UDDI deals with strings only, so UDDI isn't going to "compete" with JINI based on this example. UDDI would tell its user where the driver is so that the user can download it. JINI seems to take a request for a driver and return it back to the user which is a totally different thing. BETTER, in my opinion, but different.
So JINI is really extending the "Discovery and Description" aspect to "Discovery, Description, and Acquisition" isn't it? By "Acquisition" I mean that not only will JINI find and describe the resource for the user, but it will also GET IT for your and GIVE IT to you; hence, you acquire it. But this makes the comparison unfair because JINI was designed for this and UDDI wasn't.

There is a similarity between the technologies in the scense that they both support the "Service Oriented Architecture". This means that every software components can become a service and used by various applications etc.
Having said that JINI is tuned to Java based services and Web Services is tuned more to Interoperable Internet services. So i would say that if you are developing a service which will be used mostly in java and you need high performance your best choice is JINI.
Since most services requires both the performance and the interoperability the combination between the two seems to like a more practical approach. In fact we had been working during the past few months on integrating our JINI service with web-services and we will be shipping this release by the end of this month. With this approach we gain the most out of both worlds.

do web services also get downloaded to the calling/searching client like the Jini services or do they execute in the client/server way .. with web service executing at the location where it resides

thanks
jasmeet

Basil McRae writes:

"Not too familiar with JINI -- what is the basis for comparison for the "driver" example? For example, I know that UDDI deals with strings only, so UDDI isn't going to "compete" with JINI based on this example. UDDI would tell its user where the driver is so that the user can download it. JINI seems to take a request for a driver and return it back to the user which is a totally different thing. BETTER, in my opinion, but different."

I read a bunch about Jini last year - enough to grok it architecturally. Jini is pretty cool. The object download is a great trick. Basically you export an object to 'the cloud' where it can be downloaded by remote apps. The idea was that a printer could deploy an object encapsulating it's device driver out into the cloud where a client could download it and 'know' how and where to use it right away. The object would use a standard template and be very small, invoking methods served on the target device.

Jini is thus suited to a generation of smart hardware devices with the invoker serving as a thin client. No need for heavyweight device drivers on the PC, because the device will drive itself, exporting only the interface object. Jini is far more powerful than Web Services in this respect.

I often wondered why Sun limited Jini to hardware though, since there's no resaon why Jini cannot be used the same way in software architectures.

sun made a huge mistake when they targeted jini as a hardware "driver" technology. jini is really a generic "services" framework that was and still is light years ahead of "web services".

"sun made a huge mistake when they targeted jini as a hardware "driver" technology. jini is really a generic "services" framework that was and still is light years ahead of "web services"."

I agree. There is only one problem with Jini, that different vendors have to agree what the format of the object template is for various devices and software services for the *everywhere* model to work. Otherwise the thin clients cannot use the remote objects without explicit installation of the framework which calls the object. They won't know what to look for!

I agree about JINI being state of the art. They also hurt JINI tying it to RMI.

In fact my suggestion to Sun is to make JINI an J2EE app server container, and make all communication via asynchronous calls, expose the JINI api via WSDL.

That's what I'm doing with my bench time....

"They also hurt JINI tying it to RMI."
I completely disagree. RMI is the most fundamental component of the Jini infrastructure, so fundamental it is never even described as a component - it is inherent to Jini. RMI is needed to create mobile code, the core of Jini. RMI was particularly designed to support this task, and is the only widely-adopted protocol that has done so.

Jini services can be described using WSDL and invoked using SOAP/whatever, but using these protocols internally within the Jini network would break all of Jini's promises.

BTW, I think the strongly-typed, well-agreed interfaces are a requirement, not a problem that needs to be avoided. Such interfaces have to be agreed upon anyway, either explicitly or implicitly. No web service architecture can change that.

Gal

Has any one hearde of openwings? Is this still going on? I heard about it last year at JavaOne and hit the sight a few times . It was an interesting Service Based Architecture based on Jini that seemed to me to be a next logical step in Ejb/Services evolution. Is it still kicking?

Absolutely. It was patently obvious from the get go that software services was what it was really about, not doing loading drivers.

It looks like the suits just didn't get it then. Let's hope they're not too late.

I think you will find this software effort interesting:
  http://www.openwings.org
This is a Serviced-Oriented Architecture utilizing Jini technology and Service Oriented Programming (SOP). I hope you find this information useful.

Ah how the times change!

I remember a phone conference with CIBC and Sun to discuss the future of EJB a few years back... The question was asked as to why JINI was being limited to hardware only at that time.

The only answer that we could get out of them was that it was not going to happen and that EJB was wonderful all by itself. :)

Fun, fun, fun...
Greg

I have a small question for the group .. would be correct to expect some kind of linkage by Sun between its Jini/JavaSpaces offering and J2EE ...
Now I know they are meant for different types of solutions .. and different types of problems ... but unless somebody does something to create a hype about it .. no body is going to place the bets on Jini services (read software services)..

Can they not hide it behind the Web Services offering .. and thus give the developers an option of going the UDDI way or the Jini way for showing services ...


and BTW .. where is Mr JavaSpaces heading for .. any real-life implementations ..

jasmeet

Javaspace Implementations - Gigaspaces and TSpaces

are their any projects running , implemented using gigaspaces or tspaces (i believe this is not yet out as a full blown product)

jasmeet