Ans : 

Jini is a set of APIs and runtime conventions that facilitate the building and deploying of 
distributed systems. Jini provides "plumbing" that takes care of common but difficult parts of 
distributed systems. 

Jini consists of a programming model and a runtime infrastructure. By defining APIs and 
conventions that support leasing, distributed events, and distributed transactions, the 
programming model helps developers build distributed systems that are reliable, even though the 
underlying network is unreliable. The runtime infrastructure, which consists of network protocols 
and APIs that implement them, makes it easy to add, locate, access, and remove devices and 
services on the network. 

Ans : 

Jini isn't an acronym, so it doesn't stand for anything. Though, as Ken Arnold pointed out, it 
does function as an anti-acronym: "Jini Is Not Initials." It is pronounced the same as the word 
"genie," so it sounds like jee-nee, not jin-nee. 

Ans :  

Jini is intended to be of general use, applicable in a wide range of distributed systems 
environments. In the home, it can help simplify the job of "systems administration" sufficiently 
that non-sophisticated home owners will be able to compose and use a network of consumer devices. 
In the enterprise, it can make it easier for traditional systems administrators to manage a 
dynamic network environment. 

Thus, the home and the enterprise are two major network environments where Jini may make sense, 
but Jini's potential is not limited to these environments. Basically, anywhere where there is a 
network, Jini could potentially provide the plumbing for the distributed systems running on that 
network. For example, networks are emerging in cars, which nowadays contain many embedded 
microprocessors. Were you to plug a new CD player into your car, Jini could, for example, enable 
the user interface for the CD player to come up on your car's dashboard. 

Ans :  

Currently Jini does not work with PersonalJava, because (among other reasons) Jini depends on 1.2 
RMI, and the current release of PersonalJava doesn't support 1.2 RMI. Sun says they expect to 
release later this year a new version of PersonalJava that supports Jini. 

Ans :  

To use a service, clients will in general have a priori knowledge of at least one "known" (or 
"well-known") Java interface that the service object implements. In other words, if a client 
program makes use of, say, a Jini storage service, the programmer of the client will usually know 
about a standard (or, "well-known") interface to storage services when the programmer writes the 
client program. 

Clients will usually specify one or more Java interfaces as part of the search criteria when 
looking for services on a lookup service. This approach means that clients will definitely know 
how to use the services they find, because by definition they know (have a priori knowledge of) 
at least one Java interface through which they can interact with the service. 

Currently, no "well-known" interfaces really exist. These interfaces will likely be defined by 
industry consortiums. For example, various manufacturers of printers have gotten together to 
define a hierarchy of interfaces for printing. As families of "well-known" interfaces come into 
the public domain, they will likely be described and made available at the Jini Community web 
site: 

http://www.jini.org 

Currently, two working groups are forming to define "well-known" interfaces for printing and 
storage services. For information about these and other efforts, visit the Jini Community web 
site. 

Although in the general case, client programs will have a priori knowledge of well-known 
interfaces implemented by the service objects they use, they needn't always. If a service offers 
a user interface (UI) the client can display, and that UI is attached to the service in a 
"standard" way known to the client, the client need not have any a priori knowledge about that 
service. The client need only have a priori knowledge of where the UI might be stored (likely as 
an attribute in the service item). Once the client locates the UI, it can pass a reference to the 
service object to the UI and display it. The user can interact directly with the UI, which 
interacts with the service via the service object. Because the UI knows how to use the service 
object, the client doesn't have to. 

The serviceui project at jini.org is currently working to define a well-known way for UIs to be 
attached to services. To find out more, join the serviceui mailing list at: 

http://developer.jini.org:80/cgi-bin/subscribeform 

(You'll have to log in as a Community member, which requires that you agree to the Sun Community 
Source License terms for Jini.) 

Ans :  

Jini is built on top of RMI, so Jini requires RMI. RMI does not, however, require Jini. RMI, 
which stands for Remote Method Invocation, enables clients to hold references to objects in other 
JVMs, to invoke methods on those remote objects, and to pass objects to and from those methods as 
parameters, return values, and exceptions. RMI's object-passing abilities include a mechanism 
that enables downloading of any required class files across the network to the JVM receiving the 
object. Jini enables the spontanteous networking of clients and services on a network. Jini makes 
extensive use of RMI's ability to send objects across the network. 

Both Jini and RMI involve a kind of directory service. In the case of Jini, the directory is 
called the lookup service. In the case of RMI, it is called the registry. The Jini lookup service 
enables clients to get references to services, which arrive in the local JVM as a reference to a 
local service object that implements a service interface. Similarly, the RMI registry enables 
clients to get references to remote objects, which arrive in the local JVM as a reference to a 
local stub object that implements a remote interface. Despite these similarities, however, 
several significant differences exist between Jini lookup services and RMI registries. 

In general, a client program requires more knowledge about the network to use RMI than Jini, 
because Jini provides a discovery protocol that enables clients to locate nearby lookup services 
without prior knowledge of their locations. RMI, by contrast, requires that a client already know 
where a remote object is installed. In addition, because Jini service providers can also use the 
discovery protocol to locate lookup services, they can make their services available to the local 
area network without prior knowledge of that network. Because of the discovery protocol, Jini is 
able to provide "spontaneous networking" or "plug and work" between devices. Because it lacks a 
discovery protocol, RMI is not quite so spontaneous. 

Another significant difference between RMI and Jini is the difference between a service object 
and a stub object. Although Jini makes use of RMI to send objects around, the service object on 
which the client invokes methods need not be an RMI stub. The Jini service object could be an RMI 
stub, but it's not necessary. A Jini service object can use any network protocal, not just RMI, 
to communicate back to any server, hardware, or whatever may be across the network. 
Alternatively, a Jini service object could fully implement the service locally so that it need 
not do any communication across the network. In the case of RMI, stub objects will always use the 
RMI wire protocol to communicate across the network to the remote object. A designer of each 
service decides which (if any) protocol is used to communicate across the network between a 
service object local to a client and a remote server. This means that Jini effectively raises the 
level of abstraction of distributed systems programming from the network protocol level to the 
object interface level. Clients don't have to worry about protocols, they just talk to object 
interfaces. 

The third significant difference between RMI and Jini is that Jini provides a much more 
expressive way to search for services in a lookup service than RMI provides to search for remote 
objects in a registry. Each remote object is associated in a registry with a character string 
name that is unique within that registry. Jini services are registered with a service identifier 
that is globally unique and permanently maintained by each service, a service object, and any 
number of attribute objects. Clients can look up a service by service identifier, by the Java 
type or types of the service object, and by wildcard and exact matching on the attributes. 
Whereas RMI requires that a client know the name under which a desired remote object was 
registered, Jini enables a client to just look for the type of service desired. The ability to 
search for services by Java type is another feature of Jini that supports spontaneous networking. 
If you enter a LAN environment for the very first time and you want to use a printer, you don't 
have to figure out what name a printer service was registered under; instead, you just look up 
the services that implement a well-known Printer interface. Lookup by type also ensures that Jini 
clients will know how to use whatever it is they get back from their query, because they had to 
know the about the type to do the query in the first place. 

In summary, RMI's aim is to enable invocation of methods on objects in remote JVMs and to enable 
the sending and receiving of objects between JVMs as parameters, return values, and exceptions of 
those remote method calls. Jini's aim is to enable spontaneous networking of clients and services 
that happen to find themselves on a local network. 

Ans :  

CORBA is perhaps more akin to RMI than Jini, but CORBA includes a service called the trader 
service that is somewhat reminiscent of the Jini lookup service. CORBA, which stands for Common 
Object Request Broker Architecture, enables you to invoke methods on remote objects written in 
any programming language. RMI, which stands for Remote Method Invocation, enables you to invoke 
methods on Java objects in remote virtual machines. The objects needn't have been written in the 
Java programming language, but they do need to be running in a Java virtual machine. Thus, they 
most likely were written in some language that was compiled to Java class files, and by far the 
most common language compiled to Java class files is Java. 

CORBA has a naming service that lets you look up a remote object by name and obtain a remote 
reference to it. RMI has a registry server that let you do the same thing: look up a remote 
object by name and obtain a remote reference to it. CORBA departs from RMI, however, in that to 
use the remote reference by invoking methods on a local stub, CORBA requires that the client have 
the definition of the stub locally. (In other words, CORBA requires that the code for the stub 
object be known to the developers that create the client.) RMI, by contrast, can send the class 
files for a stub object across the wire. Because an RMI client can dynamically load the code for 
a stub object, that code need not be known to the developers of the client.) 

CORBA does offer a "dynamic invocation interface" that enables clients to use remote objects 
without the stub definition, but it is more complex to use than just invoking methods on a local 
stub. The difference in complexity is similar to the difference between using a Java object 
through its interface and using the same Java object via the reflection API. 

Another difference between CORBA and RMI is that RMI lets you pass objects by value as well as by 
reference when you invoke a remote method. Up until the CORBA/IIOP 2.2 specification was released 
in 1998, CORBA only allowed you to pass objects by reference. The 2.2 specification added support 
for objects by value, but this functionality yet may not be supported in many CORBA 
implementations. 

A significant difference between CORBA and RMI is that when a subclass object is passed to a 
remote method by value, CORBA will truncate the object to the type declared in the method 
parameter list. For example, if a CORBA remote method expects an Animal and the client passes a 
Dog (a subclass of Animal), the remote object will receive an Animal (a truncated Dog), not a 
Dog. Because RMI can send the class files for the Dog across the network, the RMI remote object 
will receive a Dog. If the remote virtual machine has no idea what a Dog is, it will pull the 
class file for Dog down across the network. 

As mentioned previously, CORBA does include one service that is reminescent of Jini's lookup 
service: the CORBA trader service. Instead of just supplying a name with which a remote object is 
associated, as you do with the CORBA naming service (or the RMI registry), you describe the type 
of remote object you are seeking. Similarly, you can look up a Jini service by type. The Jini 
lookup service offers a bit more flexibility in searching, however, because you can also search 
by a globally unique service ID and by attributes. But the most important difference between the 
CORBA trader service and the Jini lookup service lies in what they return as a result of the 
query. The CORBA trader service returns a remote reference to a matching remote object. The Jini 
lookup service returns a proxy object by value. 

Thus, when you get a remote reference back from the CORBA trader service (assuming you have the 
stub definition), you can talk to the remote object by invoking methods on the local stub. The 
local stub will talk across the network to the remote object via CORBA. When you talk to a Jini 
service object, on the other hand, that service object may not talk across the network at all. It 
may implement the service in its entirety locally in the client's virtual machine. Or, it may 
talk across the network to a server, servers, or some hardware via sockets and streams. Or, the 
service object may actually be an RMI stub that communicates across the network to a remote RMI 
object via the RMI wire protocol. The service object returned by Jini can use any network 
protocol to communicate across the network. It could even use CORBA. 

Ans :  

In general, you can't obtain the IP address of a service from the lookup service. The service 
proxy is never unmarshalled in the lookup service, so it's impossible to inspect the proxy for IP 
addresses. Also, there is no requirement that the entity that registers the service must also be 
the entity that provides the service, so knowing who performed the join in the general case tells 
you nothing. Even after the client retrieves the service proxy, obtaining an IP address is not 
possible in general, because a smart proxy can be designed to completely hide the network 
implementation details from the client. In fact, the proxy can entirely implement the service 
locally, resulting in no IP address. Or, the proxy could contact several different servers at 
various IP addresses simultaneously or at different periods during its lifetime; this means that 
there could, in fact, be many IP addresses. If you are a service provider and want to provide 
clients with your IP address, you must explicitly give them a way to get at it. You could either 
register an attribute with your service that gives the IP address, or your service object could 
implement an interface that includes a method which returns the IP address. 

Ans :  

You can download all of the Jini specifications from: 
http://java.sun.com/products/jini/specs/