- Jini objectives.
- Jini architecture.
- Service interaction in Jini.
- Service implementation in Jini.
- Java's contributions to Jini.
- An architecture for distributed computing.
- It generalizes client-server systems.
- A set of services supporting the architecture.
- Service look-up, request-reply transactions.
- A set of abstractions supporting the services.
- Service discovery, proxies, interfaces.
- A basis for higher-level, distributed computing architectures.
- Jini is middleware.
- Jini supports dynamic, lightweight, and autonomous behavior.
- Client and servers come and go at arbitrary times.
- Clients and servers can quickly react to changes.
- Spontaneous, plug-and-play networking.
- Jini extracts minimal and proportional costs.
- Costs include design, implementation, and execution.
- Clients play for free, servers pay.
- The costs should be cheap, so paying's not a burden.
- Clients and servers have authority and control.
- Little or nothing centralized.
- Minimal system administration.
- The Jini secret: what about security?
- Describe behaviors, not implementations; Jini is undogmatic.
- Of course, a lot of things behave as does Java.
- Dynamic
- "Portmapping" is network wide rather than host specific.
- Failed service entries are removed automatically.
- Cheap and proportional.
- Clients aren't compiled for servers.
- Java provides many of the facilities.
- Transport protocol, if any, is server determined.
- Autonomy.
- Client and server independence; stubs not required.
- Generalized client-server interactions.
- Clients and servers around the Great Cloud.
- Clients, servers and the Cloud form a named community or djinn.
- A client or server can belong to several communities.
- A group of connected communities is a federation.
- No central authority; no single point of failure.
- A Jini service is anything that implements an interface.
- The interface is the set of methods to which a server responds.
- A Jini server may be hardware or software or both.
- The software need not be Java.
- Everything in Jini is a server.
- A server may call interface routines (be a client).
- A client may implement an interface (be a server).
- Jini defines the lookup service to help clients meet servers.
- Servers register their interfaces with lookup servers.
- Clients query lookup servers for service interfaces.
- A community may have several lookup servers.
- A service may register with any subset of available lookup servers.
- A client may query any subset of available lookup servers.
- A lookup server may belong to several communities.
- This is how communities are federated.
- The lookup server implements the lookup interface defined by Jini.
- Sun provides the
reggie
lookup server.
- A service interface is the specification of an object that a client uses
to invoke server operations.
- Service interfaces can use the full Java.
- Subclassing interfaces to provide more specific services.
- Color printers derived from printers.
- Interfaces can be combined to form new services.
- Clients can specify services via interface constraints.
- Useful with interface hierarchies.
- Sun and friends are working to develop a set of standard-service
interfaces.
- A proxy is an implementation of a service-interface object.
- It need not implement the whole service, though.
- Proxies are mobile code; they get shipped from server to client.
- This relies on Java's remote method invocation (RMI) capability.
- RMI is fancy (or object-oriented) RPC.
- The client dynamically loads the proxy and invokes its member functions.
- This relies on Java's secure class-loading feature.
- The interaction between proxy and server is completely under server
control.
- Servers register their services (proxies) with lookup servers.
- Clients query lookup servers and receive proxies.
- Clients select various proxies, invoke them, and receive service.
- A service finds its community's lookup servers.
- Each lookup server replies with a registration proxy.
- The server invokes the registration proxy to register its proxy with each
replying lookup server.
- A client discovers and contacts lookup servers.
- Each lookup server replies.
- The client queries each responding lookup server for services.
- Each queried lookup server replies with appropriate proxies.
- The client chooses among the resulting proxies.
- A client's proxy is a server-related object.
- The client calls the procedures implemented in the proxy.
- This may or may not involve client-server communication.
- A service is anything that offers a proxy implementing an interface.
- Services can be by hardware, software, or both.
- Hardware can be proxied by other software.
- Servers need not be Java, but proxies must be Java byte-code.
- Clients run a JVM, but need not use Java.
- A proxy is a Java object implemented in byte-code.
- They are strongly typed via interfaces.
- The execute anywhere there's a JVM.
- They are close to the client, not the server
- Proxies need not be generated by Java.
- They must be type-correct, however.
- Servers need not be Java.
- But they're usually wrapped in Java and accessed via the Java Native
Interface (JNI).
- Java does not specify client-server network communication, or even
require it.
- The server is responsible for proxy communication.
- Loading code in the client can avoid any communication.
- The server can optimize any communication required.
- Servers can implement adaptive protocols.
- The client isn't anywhere in any of this.
- Java does specify the discovery protocol used to find lookup servers.
- Using interfaces makes service versioning easy and safe.
- Externally visible service changes result in a new interface.
- The new interface is a child of an older interface.
- Ancestor service interfaces provide previous versions.
- Descendent service interfaces provide newer versions.
- The Java type system makes sure the proper version is used.
- Jini uses leases to recover state associated with lost servers.
- Servers must periodically re-register proxies.
- Proxies not re-registered are removed from the lookup servers.
- Client proxies handle lost servers.
- Redundant servers allow for alternate connections.
- Discovery solves the boot-strapping problem.
- Lookup servers periodically announce their presence.
- This involves multicast in the community.
- Clients and servers can multicast for lookup servers.
- Point-to-point discovery is also supported.
- It's required for intra-federation discovery.
- Discovery is protocol independent.
- It's been implemented over TCP/IP and IIOP.
- A client can be carrying on several simultaneous server interactions.
- Dealing with partial failure is hard.
- Detecting them, handling them, recovering from them.
- A transaction is an abstraction designed to make partial failures easy to
handle.
- The
mahalo
server provides multi-server transactions.
- Jini doesn't require Java (mostly).
- JVMs and byte-code provide a host-independent execution environment for
proxies.
- Interfaces, subtype polymorphism, and type safety make changes easy and
secure.
- Serialization allows for shipping around proxies.
- Remote method invocation (RMI) and dynamic loading make client-side
interactions natural.
- The Java Native Interface (JNI) allow non-Java clients and servers.
- Jini is a distributed architecture based on mobile objects.
- The Jini architecture supports spontaneous networking.
- Spontaneous networking is dynamic, decentralized and lightweight.
- Java provides many of the base-level abstractions exploited by Jini.
- Host-independent bytecode interpreters, serialization, dynamic and
secure object loading, RMI.
- The abstractions are essential; Java isn't (Microsoft hopes).
- Jini provides its own, higher-level abstractions.
- Lookup, leasing, transactions.
This page last modified on 8 May 2003.