Lecture Notes for Client-Server Interfaces

1 May 2003 - An Introduction to Jini or How Does My Toaster Get On the Internet?

Outline

• Jini objectives.

• Jini architecture.

• Service interaction in Jini.

• Service implementation in Jini.

• Java's contributions to Jini.

What is 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.

  • JavaSpaces.

• Jini is middleware.

Jini Objectives

• 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.

Jini vs. ONR RPC

• 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.

The Jini Architecture

• 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.
  

Jini Servers

• 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).

The Lookup Service

• 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.

Service Interfaces

• A service interface is the specification of an object that a client uses to invoke server operations.

  • An interface lists the commands understood by the server exporting the interface.

    public interface 
    MyServerInterface extends Remote { 
       public long getTime() throws RemoteException; 
       public long getTimeAt(City) throws RemoteException; 
       public void setTime(long) throws RemoteException; 
       } 
    

• 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.

    • It's a phone and a tv!

• Clients can specify services via interface constraints.

  • Useful with interface hierarchies.

• Sun and friends are working to develop a set of standard-service interfaces.

  • The weak point.

Interfaces and Proxies

• 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.

Jini Client-Server Interactions

• Servers register their services (proxies) with lookup servers.

• Clients query lookup servers and receive proxies.

• Clients select various proxies, invoke them, and receive service.
  

Registering A 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.
  

Finding A Service

• 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.

Using A Service

• 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.
  

Implementing Jini Servers

• 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.

Proxies

• 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).

Protocols

• 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.

Interfaces

• 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.

Leasing

• 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

• 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.

Transactions

• 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.

Where's Java?

• 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.

Points to Remember

• 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.