Why JINI?

The name of this article is Why JINI, more out of practice than anything. All the same, there is much naturalness and reasonableness to it. Of late, it has become an interesting pastime to survey and unravel new or emerging concepts, and then follow it up with a concise, authentic, and if possible a revealing write-up on it. On completing an article on JMX, and after a survey on keyboard managers and IME for UNICODE typing, I was almost certain that there is not much that that is too tough to be understood, if we are willing. But JINI initially threw me outright. After much introspection and thanks to a masterly written tutorial (a book review it seems) from the net, JINI is much much simpler (and beautiful) in its import than anything (even JMX). Sometimes after reading a nice and revealing article on some topic, I wonder what is there to explain in it by me. This search on JINI has clarified, that unless we have a presumption on what is that we are dealing with, it usually becomes an uphill task to understand something. The benefit of purposefulness largely offsets the risk of false opinions that we might have. Our imagination, and introspection on, what at all could a given idea be, does shorten our search considerably. Most of my delay in JINI's case was due to my inexperience with network protocols, which is so intimately used in JINI, and of course my awe towards this project.

My justification for writing this, in spite of the beautiful article in the reference, is to share that prerequisite hunch that is so essential to go about your way with JINI. More than that, and maybe with a minimalist survey on its API, the main goal is to relate JINI to other ideas that we are already flooded with. Yes, knowledge is making implicit knowledge explicit, and connecting the unknown to as much of known as possible. Learning something is one, and knowing how to learn something is quite another. My stress is more towards the latter.

JINI: In 5 minutes

JINI is a programming model and a minimalist architecture for coding (and conceiving) distributed application. Remember, that the holy grail of programming, is to write our code in as small a module as is possible, and somehow deploy them, without going to each of the client machines for every update. JINI is precisely for this. JINI project's goal is to both aid and promote a way to think about distributed and extendible application, in terms of Java's RMI based code transport (along with data) and the UDP (of TCP/IP suite of net protocols) based multicast mechanism.

Many of us have wondered at the dynamic code transport mechanism of Java, and for what else it could be used. When for the first time I saw, that we could serialize an object (an instance of a class) and send it via a socket connection to another machine, and use it there through an interface that the object implements, I was wonder struck! This model, begs some powerful usage, and JINI is that.

In case first 5 minutes is too little: Second 5 minutes

Another such powerful concept is the UDP multicast. The famous socket programming, has made us to think that whenever we get hold of an IP address, and maybe a port, and if we are sure that the other end is listening, then we can communicate with it. But how are we to communicate, if we don't know who all is listening. One obvious suggestion from UDP is to broadcast our presence, and let the listeners do the worrying of communicating with us. And this is the JINI's second pillar for existence.

There are three key players in JINI. A Client, A Service Registry, and a Service. Here, each can be the other too, (a thumb rule for the elegance of a model is recursiveness). A piece of code in a machine can be either a client or a service or even a Service registry or in fact all three! These roles are only in context with others. Anyway the idea is,

• 1. The (one or many - many for redundancy) Service Registry is started, and listens at some port (4160 - it seems the decimal representation of hexadecimal CAFE-BABE!).

  2. A would-be service discovers these registrars, either by broadcasting (multicast discovery) if it doesn't know who all are there, or by specific request (unicast discovery).

  3. The service then registers its service details and a service proxy (meaning a small pointer to our real service application).

  4. Now a client comes about, discovers the registrar/registry first (like the service provider), and queries it for the service it needs, gets the service proxy that is stored on the restrar, and directly uses it (registrar is no longer needed).

That is all, this is the basic idea. There are few more tricks out there, essentially to answer few basic questions of this model.

• 1. One is, how long should the service be registered? What if the service is removed, without a word? The answer is, that these registrations are time based, a Lease that is acquired by the service with the registrar. This way, the client has to reassure its availability periodically, by renewing the lease.

  2. The second point is, how should the client request for a service? JINI suggest that the client should request for an implementation of an interface that it knows of. Very simple and yet very powerful.

Why do we need JINI?

If all that JINI provide is only a programming model, why does it deserve such product like campaigning? It is a product too. Sun, has hit upon this brainwave to create new standards that all vendors and programmers accept unanimously. Of course the programmers will accept, once they see any simplification of their work, but why should a vendor accept sun's standards? Because there is something in it which cannot be done by the programmer alone. There is an infrastructural requirement in all these standards. In case of JINI, it is the service registry implementation (which too is a service, of course). What sun does is to create a product opportunity for a vendor to implement and sell. The cost a vendor pays in return for this standardization is that that they have to live with open nature of it, and hence rampant competition; only fittest survives. Of course, sun's success with a standard, is only possible if the standard is important and really a value-add, and that is their gamble. And unsaid in all these is, the IT industry's fear and helplessness, with Microsoft's monopoly. Unless, there is a common ground to fight, even to Microsoft, you can't even get a chance. Open-standards are the only way to encourage innovation, and yet avoid vendor-lock-in.

The value proposal from JINI is to allow a much simpler and flexible distributed programming model for the programmers. Is it indispensable? Not so much now, but eventually the headache of maintaining a big application, in a fast changing world, would force people to lookout for one such model. Right now RMI itself, and through EJB, does promise interface-based distributed implementation (you only need the interfaces, the instances are only in the server). But the JINI's goal is much more futuristic. Like it's marketing, it is network plug-n-play model beyond the current n-tier programming. I'm yet to explore JXTA, but my current assumption is that it is mostly in JINI's mould, except for its stress on XML rather than JAVA.

The current unsaid dangers of n-tier model, or any such server-based model is, minimal fault tolerance. If the server fails, you unnecessarily need too much effort or too many costly products to bring about fault tolerance. What JINI is trying is to explore is, how much of the existing infrastructure could be used, with insignificant cost and phenomenal gains. In a way, this introspection into existing system's efficiency, rather than asking for memory and more speed alone, would really be the way to go. It is a way of catching up on quality front, for what we have in quantitative front. Maximize the raw output first, and then optimize it when the going is rough. Current stress on chip's architecture more than the clock pulse alone is a glimpse of this current trend. We are using, what we have earned. A server-based model still projects a monolithic coding culture, however improved it might be form past. JINI, web-services, and JXTA are all the next generation, programming paradigms, where the golden rule, of do little, but do it good is taken to the next level of urgency. Think of all your coding efforts as tiny applications, all by itself, and with clear input output signatures. Whether your IO signatures are in Java, or in XML is not so important, that the IO signature is separate from your implementation is very important.

What JINI is not

JINI is not a content model like ebXML. It is more like HTTP or TCP/IP, a network protocol, or better still a network model. How can the client know what content to ask for? How can a service publish its service? Is it at all possible that a piece of code can receive an object dynamically, query its interface, and use it intelligently? These are not answered by JINI now. Its only concern is two pronged. It extends the model provided by EJB et al, to avoid client level installation, and secondly it even tries to eliminate the client from knowing even the server's address! This is more powerful than you might imagine. JINI claims that once the client discovers the service and has received the service proxy, the lookup service need not even exist; it directly talks with the service in its own lingo. This infrastructure is a true catalyst, which aids the reaction, but does not participate in it.

Currently the client should posses the interface it seeks service for. This has to be together worked out between the service and the client in advance. Of course there are dreams in the JINI community, to standardize the interfaces of some of the key services. The lookup service itself is one such public service, whose interface is published and maintained. But till such time, when more of these public or known services come about in JINI, it is only an easy contract between the various modules of your company, and other companies that you collaborate with. I'm not aware of any ebXML like extensive effort going on in the JINI community for content standardization, except for some essential and basic stuffs like printers, disk stores, etc.

One prevalent accusation on JINI, from non-Java community is its unnecessarily complete dependence on JAVA language (meaning the byte-code). The success for ebXML is its almost nil prerequisite and hence nil vendor dependence. If people have to create standards with Java, it has to be an open base. For now it is not, and hence most of the effort is shifting towards web-services, and JXTA. One key benefit of JINI over either web service model or JXTA is, that here, thanks to java object serialization, RMI etc, not only the data or control instruction move between machines, but also their implementation. The clincher is the simplicity of this whole activity due to the java's programming model. This as well could be the savior of JINI's identity in the face of the stiff competition posed by JXTA and ebXML efforts. Moreover, the current JSRs for ebXML support in Java, might indirectly re-ignite the JINI efforts.

JINI is not for Internet!

Don't worry; the title is only to be catchy. Of course it is true, but with much lesser pessimism. The multicast discovery model for discovering services available in a network, is only possible in smaller networks. Multicasting is very costly in terms of network resource, so not many ISP's will allow their servers to be flooded with such request from every body in the world. With all this acceleration in the number of Internet users, I don't see JINI being an Internet model (in multi-cast sense) ever. All the same, within a network, this is not at all a big problem, and hence JINI is more for single application partitioning, than for an international service web. An international model could only be web-service like, for some time to come (will JXTA, peer-to-peer claim, crack it anytime soon?). Still, an indispensable matching intranet infrastructure is what JINI is. Also remember, if required you can always request a service form a foreign site through HTTP or FTP, nothing stops you. But that will be done only by specific unicast request. You have to know the exact address of such external services.

I even feel that all our direct (unicast) request should itself be encapsulated as a JINI service again, which can be found by UDP broadcasting. This way, we have best of both worlds; our clients are independent still, but can utilize the Internet fully (someone have to maintain this internet lookup service constantly). I cannot ever over stress the freshness that this idea has instilled in the distributed programming advocates. I simply love it; it vindicates many of my earlier searches and hopes.

Epilogue

If JINI was foreseen in Java's ability to move objects around, then there should be something that will come up by JavaScript's (or VBScript) ability to define code itself in runtime. In scripting languages, we can execute code as string in runtime. If a wonder could be a revolution, then all wonders have to be analyzed (HoHum ;). Anyway, most of this functionality of JavaScript is currently realized by JINI, but more is possible. It seems people did try these lines of an application extending itself, but it has too much of a AI like dreaminess to be practicable. Maybe the problem is only of complexity management. Worth pondering more. This could be our initial step towards answering questions like Is it at all possible that a piece of code can receive an object dynamically, query its interface, and use it intelligently?

By the way, I even expect, maybe due to the effect of JXTA's predominance, the proper place for JINI would be as bundled with J2SE itself. It is such a basic stuff, that in future, all application should have it as its spine and spirit. It would be nice to ponder this JINI's loose coupling with JMX's fixed (all pervading) semantics in terms of Attributes, Operation and Events, to get a real and complete distributed architecture of all.

Resources

• 1. Jan Newmarch's Guide to JINI Technologies

  2. This is an absolute masterpiece. A to-the-point and authentic tutorial on JINI. The first article that really clarified many of my doubts. My article here might be useful only till you see this link.

  3. Jini-talk with Jim Waldo (Jini architect) -- Full transcript

  4. An interview that is beyond superlatives. I vacillate between envying these types of people, and counting my blessing that I can understand and envy this kind of deep stuff. The real motive of JINI is explained from the horse's mouth. A must read. In a sense, this article is an argument in favor of JINI's java-centricness.

  5. The Jini vision

  6. If you don't mind a bit of Bill Joy adulation, and a near god-like worship of JINI, this would be THE article to know more about the JINI people. It really does have some scenarios and examples, that are very illuminating. Especially the comparison of motor with microprocessors, and the final Joy's summary is worth knowing.

  7. THE NETWORK REVOLUTION

  8. Coming from sun stable, you can be expecting it to be a marketing hype. But it is really a well-written piece. It focuses on JINI usage scenarios for explaining its architecture. Really the way to go, if you have above link like tutorials too for the hardcore stuff.

  9. Jini: New technology for a networked world

  10. This is part of the Jiniology site, which specializes on JINI article, except this one I haven't read much in it. But supposed to be good source for JINI. I like the byline of this article; "How Jini raises the level of abstraction for distributed systems programming" I think this sums everything.

  11. The JINI home page

  12. Of course you can start tracing from the fountainhead straight. I haven't been much benefited in this route, but I could definitely be wrong, and this ideally should be the best way to start on JINI.