Sun has released an interesting conversation with Jim Waldo, in which he discusses the status of Jini, misconceptions that the community has, the role of connected devices, Moore's law with respect to distributed computing, unreliable messaging systems, and the appropriate role of standards bodies.

Excerpt

Q. What are the biggest misconceptions that developers have about Jini network technology?

A. "Probably the biggest misconception is that it is concerned primarily with devices. This was, unfortunately, the original marketing message used for Jini technology, so this misconception is to a large extent our own fault. It was one of those cases where an illustration of what Jini technology could do -- attach a device and it's found and used, detach the device and it disappears -- was mistakenly thought of as all that the technology could do.

The message about devices hid the fact that Jini software is really a general service-oriented architecture. Jini technology is really about advertising, finding, and using services on a network. Services are advertised by what they do, their Java technology interface, rather than what they are called, and the code needed to access the service can be dynamically downloaded from the service itself so that the client of the service need only know the Java interface. Devices are one way to implement a service, but there are lots of others, including software services.

Another common misconception is the belief that Jini technology is based on a proprietary network protocol, and so can't be used with XML, or CORBA, or SOAP, or some other communications mechanism. This misconception is somewhat more troubling, because it suggests that some people are missing what I think is the essential innovation on top of which Jini software is built.

Most distributed systems are built on top of a wire protocol -- this is what allows communication to happen. The service knows what bits to put on the wire, and the client knows how to interpret those bits and respond. Both the client and the service are built with the code that knows how to take what is understood within the process that is doing the communication and translate that to the wire protocol, and to take the bits transmitted over the wire and translate them into something that can be understood by the receiving process.

Jini software changes this by leveraging the Java environment's ability to move objects, including the code for that object, from one place to another. So when a client finds a Jini service that the client wants to use, the client receives an implementation of the interface that identifies the service from the service itself. That implementation is responsible for the communication between the client and the service -- the client makes the calls that are defined in the interface, and the implementation of the interface is responsible for packing this up and transmitting it on the wire in such a way that the service can understand. So the service can use XML and SOAP, or CORBA, or even a protocol that it has invented especially for itself for the communication. The client doesn't have to know or care. In fact, different instances of services that implement the same interface can use very different communication mechanisms. Rather than using a proprietary protocol, Jini technology lets services use the protocol that is right for them."

Read Jini Network Technology Fulfilling its Promise: A Conversation with Jim Waldo

NOTE: Cambridge, MA is hosting the Seventh Jini Community Meeting March 23-25, 2004.

I just had to be the first post, this being Jini and all that.

This pretty much backs up my personal and our company experience too, I taught Jini for Learning Tree last week and of those that knew what it was, most of them thought it was a technology for printers, fax machines and mobile phones to work together over bluetooth in hotels. This was the marketing of 1998/9 something when Jini first came out and mobile phones were much simpler than they are now.

Jini is probably the most important technology in the Java suite for distributed computing and clustering technologies. A lot of existing software clusters actually use Jini and some have simply re-invented the wheel without realising it. Jini is not an alternative to WebService, RMI, SOAP, CORBA etc. can can actually use all of these technologies as well as provide alternatives for some existing pitfalls in these technologies.

Sun would do well to implement Jini into their new J2EE app server and re-market it as a serious technology. This is yet another seriously sexy technology that Sun's failing to market. Instead they're playing ball with MS and messing around with XML based WebServices when they should be pushing SOA using Binding technologies and Jini.

Some recent Jini in the news...
Is Sun's Jini ready to leave the bottle?
Jini may be ready to leave the bottle

-John-

I do agree that Jini/Javaspace is one of the most powerful yet simple middleware technology. Too bad it didn't catch as it deserved. I have the feeling that people are still way too much focused on a synchronous vision of middleware and architecture. As john says, Jini could be one of the best infrastructure for SOA : it could work quite well with WS* stuffs as they have in fact quite similar objectives (jini being much simpler). Loose coupling induced by Jini can really give you high ROI but yet decision is still much influenced by marketing and this is a domain Jini/Javaspace is seriously lacking.

peace.

As john says, Jini could be one of the best infrastructure for SOA : it could work quite well with WS* stuffs as they have in fact quite similar objectives (jini being much simpler).

My understanding is that Jini targets a Java universe. But distributed services are better with language neutrality. Can Java afford to tackle SOA without the collaboration of the greater community?

As john says, Jini could be one of the best infrastructure for SOA : it could work quite well with WS* stuffs as they have in fact quite similar objectives (jini being much simpler).My understanding is that Jini targets a Java universe. But distributed services are better with language neutrality. Can Java afford to tackle SOA without the collaboration of the greater community?

From what I am reading - they can and are. Check out the abstracts from the upcoming conference. I've seen things other places too. http://www.jini.org/meetings/seventh/J7abstracts.html

Check out the abstracts from the upcoming conference. I've seen things other places too. http://www.jini.org/meetings/seventh/J7abstracts.html

I agree that Jini is amazing SOA fabric, and I've felt this way for years (since CRUDlets). But the Global Grid Forum appears to be settling on WS-Resource. Even Java vendors such as BEA are inventing WS-Discovery. And the hyperlink you gave has some discouraging remarks:

"...technical challenges in integrating Java in general and Jini in particular into the .NET world..."

"...clearly conflicts with Jini's design principles..."

"...a crucial distinction deeply embedded in the design..."

I agree that Jini is amazing SOA fabric, and I've felt this way for years (since CRUDlets). But the Global Grid Forum appears to be settling on WS-Resource. Even Java vendors such as BEA are inventing WS-Discovery. And the hyperlink you gave has some discouraging remarks:"...technical challenges in integrating Java in general and Jini in particular into the .NET world...""...clearly conflicts with Jini's design principles...""...a crucial distinction deeply embedded in the design..."

For an increasing number of folks, living in Java centric world is not much of a sacrifice to get the benifits that Jini offers.

Web Services has been totally over-hyped (much more so than Jini ever was). The rapidly escalating complexity (for little return in functionality) is depressing. Just because it's popular doesn't mean it's right.

Jini's time has come.

When we use J2EE without a lot of patterns like command/façade/dao, so everybody is using this patterns.


* Who is using Jini and J2EE together to have a SOA app?
* What I will gain with Jini/J2EE working together?
* Do this archictecture do a good job?
* How about the performance?
* How do you integrate with webservices?

I too, have looked many times at the Jini/Javaspaces technology, but every time I' been stopped by the complexity of it all. I truly believe that a great part of the reason Jini/Javaspaces haven't taken off, is due to it's complexity in getting an example up and running.
Javaspaces relies on Jini relies on RMI relies on etc. Various security policy files, etc. There's too many things that need to be started. Too many things that can go wrong.

Sadly I have to agree and it's something Sun's Jini group should urgently address. It's a bit like having a J2EE app server and having to start up the various services manually one by one.

If you download and try out GigaSpaces' Jini implementation they have a nice "double click" start up script for everything. You also have an excellent set of examples that pretty much work out of the box. I installed GigaSpaces and ran the Ray-Tracing demo on 14 machines in about 30 minutes last week while teaching Jini for Learning Tree. My "students" also made the same comments as you about OutRigger. Having said that I have to say that of all the various technologies taught that week (RMI, JDBC, CORBA, JMS, Jini etc.) they loved Jini. I had a half day spare (they were quick programmers) and they chose to spend that on Jini.

Please don't be put off by the startup complexity, if you need help just email me, John dot Davies at C24 dot (remove this) biz.

-John-

[I don't work for them, just fortunate to be on their restricted
beta program]

The Maji framework (http://www.majitek.com/whitepapers/Majitek%20Maji%20Technical%20Introduction%20August%202003.pdf)
looks like it will solve many of the problems
developers have when they approach Jini for the first time.
Maji provides an IDE (and moving rapidly towards something along the
theme of https://www.theserverside.com/news/thread.tss?thread_id=23873)
and simple but powerful component model for Jini among a number of other
things.

Highly recommend reading the whitepaper linked above...lots of new terminology
but well worth the investment...I believe a public beta will begin in a
couple of months

John,

I tried GigaSpaces last fall, and was able to get a space up and running, and do a write/read within 15 minutes. Now that's how easy it's should be. Unfortunately, I can't sell the idea to other developers when the RI (and any other open-source implementation) is so hard to grasp. Part of the problem seems to be that the services Javaspaces rely on (Jini, RMI) are also not very well understood by the average Java developer, including myself. The learning curve is steep and requires you to learn about the dependencies as well.

John,I tried GigaSpaces last fall, and was able to get a space up and running, and do a write/read within 15 minutes. Now that's how easy it's should be. Unfortunately, I can't sell the idea to other developers when the RI (and any other open-source implementation) is so hard to grasp. Part of the problem seems to be that the services Javaspaces rely on (Jini, RMI) are also not very well understood by the average Java developer, including myself. The learning curve is steep and requires you to learn about the dependencies as well.

I can understand, I teach this stuff quite regularly in my "spare" time and I'm very much aware of the gap between the "average" Java developer and full RMI/Jini. By the way if you think Jini is hard to grasp should take a look at the way EJBs work, you've still got the RMI but there are even more layers to get through. There are very good reasons for the architecture and the result is powerful but the learning curve is also very steep.

Dion has talked me into writing a whitepaper about Jini in the real world, a case study. I think the best way to do it would be to first introduce Jini, what it is and some of the main components like JavaSpaces. The obvious way to start would be with an open-source implementation like OutRigger and probably Blitz. This will have to include the background on sockets, CORBA, RMI and probably WebServices.

It's going to take me a few weeks because I'm rather bogged down "real" work but you should see it here around mid-April. If you're lucky enough to be going to the Symposium I'll be talking about all this stuff on the 8th May in Las Vegas.

Hopefully by the middle of May I'll have you fluent in RMI and Jini.

-John-
CTO C24

My two main issues with Jini are:
1. It deeply encroached into Java technology stack. Yes, it can be "modified" to use WS* or other protocols to become presumable less Java-centric but this quickly gets unmanageably complex and looses Jini’s greatest appeal which is elegant and simple distributed model.
2. Second point is that Jini is too low on the stack, so to speak. I can't see it is being seriously used beyond container vendors (J2EE app servers providers, etc) where it is actually primarily used right now. This is rather smallish crowd comparing to more higher functional level such as J2EE app server itself or specific middleware providers such JMS vendors, JTA vendors, etc. JavaSpaces does not help much at all...

I think Jini will rest in history as one of those elegant marvels that everybody liked but the one that never really caught up for one or another
reasons.

Regards,
Nikita.
xTier - Service Oriented Middleware

My two main issues with Jini are:1. It deeply encroached into Java technology stack. Yes, it can be "modified" to use WS* or other protocols to become presumable less Java-centric but this quickly gets unmanageably complex and looses Jini’s greatest appeal which is elegant and simple distributed mode

This is one of the fundamental misconceptions with Jini - to use ProductX, you have to *modify* Jini to ProductX's model. Not at all - let's take WS, you build all the stubs, set up your WSDL, and you have a class that call's that WS. With Jini, you create an interface to the operations you want to call, you build a serializable class around it, and you publish it into the Lookup Service, then any java client, can download the proxy and invoke your WS through this proxy. Also the small java app that is maintaining the proxy in the LUS (not the actual webservice) can lease resources, clean up the LUS automatically, if the WS becomes unavailable, automatically republish the proxy when the WS comes on-line again. You can replace 'WS' with any protocol, or distributed programming model you want. If you wish, in some ways you can think of Jini as a SOA publishing toolkit.

We're looking at binding non-java clients to use Jini services in our infrastructure, so this reduces the 'java-centric' view of Jini even more. Yes you must have Java somewhere, but not everywhere. We're also using Jini for our distributed transactions across multiple datasources.

Jini gives you the dynamic networking, the capabilities to use it as the basis of SOA, alright you have to write the actual services, etc., but it's really not that hard.

I'm doing the 'Jini and Javaspaces as an Enterprise Backbone' talk at the community meeting, so 'allegedly' I know about these things.

Second point is that Jini is too low on the stack, so to speak. I can't see it is being seriously used beyond container vendors (J2EE app servers providers, etc) where it is actually primarily used right now. This is rather smallish crowd comparing to more higher functional level such as J2EE app server itself or specific middleware providers such JMS vendors, JTA vendors, etc. JavaSpaces does not help much at all...

We did have J2EE but, we've built all of the Java pieces of our enterprise architecture using Jini. Jini has never seen us wrong in the areas it addresses, and I do not regret choosing it over J2EE

I think Jini will rest in history as one of those elegant marvels that everybody liked but the one that never really caught up for one or anotherreasons.

We shall see, it really could go either way, SOA is big, CFO's want better returns out of existing investments, and J2EE vendors still want you to buy their next product with support - there's a lot of factors here, economic as well as technical

Calum

This is one of the fundamental misconceptions with Jini - to use ProductX, you have to *modify* Jini to ProductX's model. Not at all - let's take WS, you build all the stubs, set up your WSDL, and you have a class that call's that WS. With Jini, you create an interface to the operations you want to call, you build a serializable class around it, and you publish it into the Lookup Service, then any java client, can download the proxy and invoke your WS through this proxy. Also the small java app that is maintaining the proxy in the LUS (not the actual webservice) can lease resources, clean up the LUS automatically, if the WS becomes unavailable, automatically republish the proxy when the WS comes on-line again. You can replace 'WS' with any protocol, or distributed programming model you want. If you wish, in some ways you can think of Jini as a SOA publishing toolkit. We're looking at binding non-java clients to use Jini services in our infrastructure, so this reduces the 'java-centric' view of Jini even more. Yes you must have Java somewhere, but not everywhere. We're also using Jini for our distributed transactions across multiple datasources.Jini gives you the dynamic networking, the capabilities to use it as the basis of SOA, alright you have to write the actual services, etc., but it's really not that hard.I'm doing the 'Jini and Javaspaces as an Enterprise Backbone' talk at the community meeting, so 'allegedly' I know about these things.

Hi Calum,
I kind of see your point, partially. I specifically put word "modified" in quotes, by the way, so you misunderstood my point. But I am failing to see why you are referring to WS (as in Web Services) in your reply. In fact, WS is usually referencing SAOP/WSDL/UDDI combination for implementing services. Jini doesn’t provide WS in that sense what so ever. It’s rather a framework on top of RMI with much more functionality but one has to go a long route to really get Jini off the Java, even adopting a non-RMI protocol is a big development challenge, let alone a fully non-Java Jini implementation – hence the 1st point in my original post.

Regards,
Nikita.
xTier - Service Oriented Middleware

I can't see it [Jini] is being seriously used beyond container vendors (J2EE app servers providers, etc) where it is actually primarily used right now. This is rather smallish crowd comparing to more higher functional level such as J2EE app server itself or specific middleware providers such JMS vendors, JTA vendors, etc.

FWIW, WebLogic has publicized a tuple space service since at least its acquisition years ago by BEA, and perhaps even before that.

How does Jini relate to JXTA?

How does Jini relate to JXTA?

Significant duplication of features, especially discovery. JXTA's relay peers are indispensible in some cases, so Sun has adjusted Jini to optionally use JXTA as its transport layer. JXTA is also language neutral, which I hope encourages the Python and C++ communities to consider it or its recent rivals, WS-Resource and WS-Discovery.

JXTA is a primarily a network level protocol
Jini is primarily an application/object level protocol that is independent of network protocols

So Jini can absolutely use all of those features of JXTA that you mentioned, just as it can also group multicast via any number of the java group multicast implementations out there, or any of the WS-* protocols.

It seems that many people see the Java centric nature of Jini (which incidentally is a bit of a misconception anyway) as a disadvantage.
I actually see this as a *big* advantage.

Object serialisation, secure network class loading and OO semantics gives me *so* much more than 'angle bracket' network protocols - Jini is much more than simple RPC. The primary difference of course is that Jini acknowledges distribution whereas most of the XML based standards I have seen don't *really*, so the standards bodies and vendors keep on building more and more specs to dig themselves out of an ever deepening hole

How does Jini relate to JXTA?

Oops. I forgot to mention that JXTA is Message Oriented Middleware, whereas Jini is merely RPC. MOM lends itself to a variety of enhancements such as pipelining, relaying, and multicasting. It would be hard to do these with Jini RPC.

How does Jini relate to JXTA?

Oops. I forgot to mention that JXTA is Message Oriented Middleware, whereas Jini is merely RPC.Jini uses the Java RMI model for its remote method calls. What those methods do is completely up to you. You an send messages, or you can request work and get responses. It's a software based system that is not restricted to any particular application!