We are now experiencing a drive toward a commodity “Network Operating System”, the next step in technology assisted computing environments. The knowledge that we have driven a huge amount of cost out of the hardware puzzle through a market move to commodity x86 based systems, but what is really next, it's gotta be the Operating System, and the software to manage a cluster of systems, what I'm calling the NOS.

So I talk about the need for a Network Operating System, what do I mean... we'll let's look at what kernels typically do: Process Provisioning (in isolation) and Management, System Resource Management, Inter-process communication enablement, Fault Management and Recovery (abstraction for user level processes).

Some in the Jini community like Gigaspaces (where my good friend Dennis Reedy has just taken a leadership role), Paremus, Intamission, and even open source projects from the community itself like Project Rio and even these tutorials on JavaSpace based worker patterns attrib. Tom White

are working on workflow scheduling & distribution models, and more dynamic resource management techniques. By and large these companies have been relatively successful, but still lack the excitement that I think that they deserve. Causes of the lack of excitement/broad adotpion can be traced back to a couple of things (misconceptions and misgivings):

Misconception #1: “Jini, isn't that a technology to connect networks of devices”
Yes, sure, but what is it about networks of devices that are shared in a global computing grid... Peter Deutsch's fallacies, and a intrinsic knowledge that the network will change, participants in the network will change/fail, and that the environment must tolerate these failures in a consistent and graceful way.

Misconception #2: “Jini is reliant on RMI/JRMP as it's protocol and RMI/JRMP has problems in big networks, across firewalls, etc...”
I'm first going to point you at this article by an esteemed colleague, Dr. Jim Waldo, basically any Java system can use RMI/JRMP for Remote (to the current VM) Method Invocation, but, and a big BUT, Jini uses proxies & proxy code to interface between services, and the interface/protocol that the proxy exposes is up to the developer. Sure, it's easy to allow the proxies to rely on RMI, but it's not required. I've seen proxies that leverage JXTA, I've seen CORBA bindings using IIOP, and of course there is a cottage industry in over HTTP/SOAP and WS interfaces across the Jini community. Besides there are existing capabilities that enable tunneling of core Jini services across firewalls and networks: Lincoln Tunnel.

Misgiving #1: “Jini is a technology that Sun has abandoned?”
Hunh Scooby. Okay so Jini hasn't become a mainline infrastructure, yet, but it's darn sure getting there. Jini is the core backplane for our RFID event manager (graci Larry Mitchell), it's been furthermore re-released under the Apache License v2.0, we continue to actively support a large community of developers, and there's more that I cannot talk about ;).

Misgiving #2: “Most of the companies with commercial projects are small, and require substantial changes to existing infrastructure to implement”
Yes, BUT the value of re-factoring the problem impacts the scalability, availability, developer productivity and other aspects of the core - I hate this term - middleware infrastructure for segments of the system. Most companies that I have consulted with are incrementally phasing in Jini, and others like Orbitz are moving business critical functions.

So what is it specific to Jini that get's me going?

Lookup and Discovery

• allows for decentralized lookup, and ability to provide federations of federations in order to help with “local maters” and provide for “best fit” resource management and scheduling.
• Leasing Models match very cleanly with resource management
• cancellation of Leases aligns well with both prioritization, graceful degradation, contention and distributed partial failure

Distributed Transaction support

• most people today rely on Message Oriented Middleware (MOMS) to provide reliable workflow despite the penalties paid for normalization, bussing, queuing, etc... obviously new breeds of MOMS are emerging with peer messaging, but still these mechanisms rely on the message or infrastructure to cleanup when there are problems rather than the calling service - where the failure recovery models are more appropriately managed.

JavaSpaces

• when we do need a shared memory space for optimal information distribution (as many Highly Parallel Application Grids do) JavaSpaces provides a very simple distributed worker model (see Tom White's article above).
• Javaspaces furthermore scale extremely well, and the pattern is quite fault tolerant

I just want to wrap up with an interesting and yet older article by Peter Coffee on the need for distributed control within IT.

Mark my words, Jini's day will come!

Permalink
Trackback: http://blogs.sun.com/dhushon/entry/jini_and_the_nos