In its core Jini is a communication middleware for
distributed systems. For this it facilitates the following services
- Service Discovery and Registration:
-
A new client in the network tries to discover one or several
Lookup Services and registers its services there.
For this the client broadcasts to a known port in the
network to which all Lookup Services listen. The Lookup Services
will each send a Service Proxy of itself to the client.
Using this proxy of the Lookup Service, the client can
register its own services by sending its own Service Proxy
and a description of itself.
-
Service Lookup:
-
A client wanting to use a service uses the Lookup Service
to search for an appropriate service (query language: key-value
pairs). It will receive a Service Proxy for that service
from the Lookup Service which it then uses to access the
intended service.
-
Event Handling:
-
Client can subscribe to events sent by other clients. They
can also add objects to hooks in the event pipeline which
can manipulate passing events (e.g. filter or queue them).
-
Error Handling:
-
Jini has unified the handling of all kinds of network and
service errors with the concept of a lease. Each
time a client requests (exclusive) access to a service it is only
granted a lease, which must be renewed periodically . If it fails
to do so or if the renewal is not granted (decision of the
service), the client looses access. This scheme is also used to
remove Lookup Service entries of services which are no longer
reachable, so a client will always get a halfway up-to-date picture
of the available services.
-
Transactions:
-
In principle Jini has something called transactions, but, uh,
the only thing you get there are some interfaces and
some warm words.
Jini is heavily based on the concept of the already mentioned
Service Proxies, which are Java objects send to a client to
act as a stub which communicates with the real
service (the specification suggest a RMI stub, but a stub can use
any communication method it wants). This results in a nice, unified
programming paradigm (get the proxy of the service, than call the
methods) where each service brings its own 'drivers' (namely
the Service Proxies). On the downside it also results in the need to
run Java anywhere, since each service has to become active to be
entered into a registry. Due to this the usage of Jini in the home
networking area is somewhat hampered, since you either need a JVM
in each device you want to control (including the light bulb ;-) .
Alternatively one has to add adapters to the devices, run a
JVM on the adapters and let the devices be controlled by the adapters
by other means (e.g. switching off power).
Jini has a second problem since it is still in the phase of
defining standardized services (e.g. for printing or
controlling the VCR) while other approaches (e.g. HAVi) already
have that standards. But Jini can not only used for home
networking/embedded devices but also just for plain communication
within distributed software systems, where none of the two
mentioned problems holds.
Other approaches to similar problems are: CORBA, UpnP, HAVi