Jini and Javaspaces

Jini and Javaspaces Oikonomou Vassiliki voikon@teiath.gr Department of Informatics Technological Educational Institute of Athens Symposium of Innovation of Computer Science Curriculum in Higher Education: Retraining of Young teaching staff February 26, 2004 Jini & JavaSpaces

What is Jini ? • New distributed computing technology • Jini is about networks’ ability to change (change is not a rare event - it’s constant) • Jini makes the network an entity that always runs, and may have parts changing as it runs- computers are nowhere - the one computer is everywhere - the system administration is nearly automatic • It follows the telephone network paradigm: an entity, separated from all network-connected pieces, guaranteed to be there all the time Jini & JavaSpaces

What is Jini ? • Jini is about services and their users - services live on the network - clients look for services - clients access services from the network, not from an entity connected on the network • Participant-to-Participant generation • Plug-and-participate (Microsoft Universal Plug-n-Play -UPnP) Jini & JavaSpaces

Vision and goals for Jini • To provide an infrastructure to connect anything, anytime, anywhere • To provide an infrastructure to enable “network plug and work” • To support a service-based architecture by abstracting the hardware/software distinctions • To provide an architecture to handle partial failure Jini & JavaSpaces

Jini on top of Java • Java-technology centered: bytecode everywhere - other languages may be compiled to bytecode • Jini is tightly coupled with Java as an application environment and a programming model • Jini is not coupled with Java as a language. • This means that the service can be implemented in any language: C, C++, or JPython. But to participate in the architecture, it should be subjected to a compiler that can produce Java-compliant byte code. If not, it can be Java wrapped/Java-tized using Java native interface (JNI). In this way, even a legacy application can be Java-wrapped and can be made into a Jini service. To summarize: Jini architecture is not Java language-centric but Java application-centric. Jini & JavaSpaces

Jini on top of Java • Java Serialization • Java RMI • Java Security Jini & JavaSpaces

Jini on top of Java Jini & JavaSpaces

Jini & JavaSpaces

Services • A service is an entity that may be used by a person, a program or another service • A service may be a device, a piece of software or a collection of other services • Groups of Jini services join together in cooperating sets (the communities) • Jini allows creating a federation of servicesFederation is the ability for Jini communities to be linked together, or federated, into larger groups (Jini addresses scalability through federation). Jini & JavaSpaces

Federation • A federation of services is a set of services, currently available on the network, that a client can bring together to help it accomplish some goal. • Federating groups of devices and software components into single distributed system • Members of federation agree on basic notions of trust, administration, identification and policy • Members of federation communicate through a set of Java interfaces (service protocol) and locate each other using a special lookup service • It’s possible to federate Jini systems for larger organizations Jini & JavaSpaces

Services • Services represented by Java Interfaces • Separation of “what the service does” from “how the service is implemented” • Only contract between service provider and service user • Jini.org community effort defines commonly agreed-upon Jini service interface types • Client Finds Service by Interface Jini & JavaSpaces

Service Interfaces • Community driven • Printing • Service UI • Only base types need to be common • Vendors compete in implementation • Vendors can extend the interface • Interfaces can evolve • New apps can use new functionalities • Old apps still work Jini & JavaSpaces

Jini Service Architecture • Service is defined by one or moreJava interfaces • Service has aservice proxy object • Local • RMI stub • Smart proxy • Proxy implements Java interfaces • Clients only know about Java interfaces • Proxy object is downloaded to clients Jini & JavaSpaces

From network protocols to object interfaces From network protocols to object interfaces Jini & JavaSpaces

Devices - gadget revolution • Devices have some memory & processing power (cell phones, smart cards, PDAs …) - They can run Java 2 Micro Edition (J2ME) or Personal Java • Devices with no JVM (very limited or no processing power but a small amount of I/O capability) -Proxies provided for “dumb” devices : Surrogatesolution -A Jini proxy is a machine capable of running a JVM attached to one or more cheap or non-Java devices Jini & JavaSpaces

The Jini System Architecture • Jini infrastructure: • Discovery Protocol • Join Protocol • Lookup Service • Jini services: • JavaSpaces • Transaction Manager • Programming Model • Leasing, Transactions, Distributed Events Jini & JavaSpaces

Jini infrastructure • Discovery Protocol • Join Protocol • Lookup Service Jini & JavaSpaces

A service makes itself available through Jini • When we plug in a service to the network, it gets an IP address (automatically done via DHCP) • The service discovers at least one Lookup Serviceusing - multicast discovery or - unicast discovery • The service registers with each Lookup Service discovered (Join Protocol)- it writes a proxy object that clients can download to use the service Jini & JavaSpaces

Service Requester Requesting Service within Jini Community • Any client (service requester) needing a service joins the community using the discovery protocol. In that process it locates one or more Lookup Services within the community. • After locating a Lookup Service, the client looks for the service in the Lookup Service based on its service type (Java interfaces). • Once the service is found, the client invokes the service, which involves moving the proxy code on to the client. Now the client can perform any operation on the service by calling its methods. • Once the service proxy is downloaded, a service requester, depending upon its requirements, creates, negotiates, or terminates its lease with the service provider Jini & JavaSpaces

Discovery Protocols • The discovery protocols allow three different types of interaction. • Service-initiated requests for lookup services (multicast request protocol ). • Lookup Service-initiated announcements to other services (multicast announcement protocol) . • Direct pairings between Lookup Services and other Jini services (unicast discovery protocol). Jini & JavaSpaces

The Multicast Request Protocol • The multicast request protocol is a service-initiated protocol that is used when a service needs to discover all the Lookup Services that may already exist on a local network. The protocol is implemented using a low-level multicast facility, so it does not require full-fledged Java RMI or CORBA or any other more heavyweight protocol. If, as is usually the case, the multicast request protocol is being run in a standard TCP/IP setting, then multicast UDP datagrams are used as the basis for the protocol. Jini & JavaSpaces

The Multicast Announcement Protocol • The multicast announcement protocol is used by Lookup Services to announce their presence to any interested parties that may be listening and "in range" of the multicast scope of the lookup service. Unlike multicast request, which typically only is used during the start up phase of a service or when the set of groups it wishes to be a member of changes, multicast announcement is used for the duration of the life of a Lookup Service. It will periodically announce its existence to any parties that may care to listen. Jini & JavaSpaces

The Unicast Discovery Protocol • In addition to listening on a multicast address for multicast discovery requests from services, each Lookup Service also listens on a normal, unicast address. This protocol is called the unicast discovery protocol. Any service can connect directly to this address to access the lookup service. In this sense, the protocol isn't so much a "discovery" protocol, as a way to contact an already known lookup service in order to download its service proxy. The client sends a message to the Lookup Service, which replies with its service proxy. • Unicast discovery is based on a URL naming scheme, where lookup services are named using URLs of the form jini://turbodog.parc.xerox.com:4160/foobar. • Unicast discovery protocol • Allows communication with a specific Lookup Service • Used to connect a Lookup Service in WAN Jini & JavaSpaces

The Unicast Discovery Protocol • Unicast discovery is also used during the course of the two multicast protocols. • When multicast request runs, the service proxy is delivered using the lookup service-to-discoverer half of the unicast discovery protocol. • And in multicast announcement, once a discoverer has been made aware of a lookup service, it requests its service proxy using unicast discovery. Jini & JavaSpaces

Lookup Service • Sun supplies a Lookup Service called Reggie as part of the standard Jini distribution • Lookup Service is a repository of Jini services • Lookup Service maintains flat collection of service items • Items contain: • the ServiceID (a globally unique identifier for the service). • the service proxy (or stub) object • an extensible collection of descriptive attributes: type of the service, service location, provider etc. (Attributes allow further discrimination between services of the same type) Jini & JavaSpaces

Lookup Service • For any service registration the Lookup Service returns a ServiceRegistration object which provides lot useful information about registration: - a method to get the related Lease object - a method to get the allotted ServiceID - a set of methods to add/modify/replace with new bunch of attributes Jini & JavaSpaces

Service Attributes Name Location Type Organization Service Item Service Object. The actual service is provided by this object ServiceID A valid ServiceID that represents an existing service item on the lookup. If you have already registered the service and are now attempting to change some attributes of the service, you have to provide the old ServiceID. Null if this is a new ServiceItem to be registered with the lookup service. Service Item Jini & JavaSpaces

Lookup Operation • A client performs a lookup operation by building a Service Template • A template is made of: • service type and/or • attribute sets and/or • ServiceID Jini & JavaSpaces

Service Template Jini & JavaSpaces

Service Proxy • Implementation of the Jini service’s Java interface type • Preserves Service Java interface type • Contains everything that a client needs in order to use the service • GUI • On-the-wire-protocol implementation • Device driver functionality • Proxy object is downloaded to clients Jini & JavaSpaces

Proxy Implementation Form • Local object (Serialized form) • The whole service object is serialized into a proxy (and therefore, calling it a “proxy” is really unfair). This strategy is used when the service is implemented purely in software, and there are no external resources that need to be used. An example might be a language translation service that is completely implemented as in Java code and has no need to talk to any external processes to do its job. • Remote object • RMI stub is serialized into a proxy. In this case, the proxy is a minimal, automatically-generated bit of code that has only the “intelligence” necessary to speak RMI Jini & JavaSpaces

Proxy Implementation Form • Mixed (Smart proxy) • Combination of local object and remote object • The proxy contains local methods as well as calls to remote object • Smart proxy (as opposed to an automatically generated RMI stub) allows more processing to be embedded in the client and it fully hides the details of the communications protocol from him • Smart proxies can be used to provide a Jini interface to legacy (non-Java) services that speak sockets or CORBA or some other protocol, and they can provide access to hardware devices that have their own communications protocols. Jini & JavaSpaces

Jini & JavaSpaces

HTTP server • The proxy passes through one JVM in ``passive'' form and is activated ( brought to life) in the client's JVM. Essentially, a ``snapshot'' of the object's state is taken using serialization, and this snaphot is moved around. An object consists of both code and data, and it cannot be reconstituted from just its data - the code is also required. Where is the code? This is where a distributed Jini application differs from an ordinary one: the code is not likely to be on the client side. If it was required to be on the client side, then Jini would lose almost all of its flexibility because it wouldn't be possible to just add new devices and their code to a network. The class definitions are most likely on the server, or perhaps on the vendor's home Web site. Jini & JavaSpaces

HTTP server • Class definitions must also be downloaded, usually from where the service came from. This could be done using a variety of methods, but most commonly an HTTP or FTP protocol is used. The service specifies the protocol used and also the location of the class files using the java.rmi.server.codebase property. The object's serialized data contains this codebase, which is used by the client to access the class files. • If the codebase specifies an HTTP url, then there must be an HTTP server running at that url, and the class files must be there also. This often means one HTTP server per service, but this isn't required: a set of services could make their class files available from a single HTTP server, and this server could be running on a different machine to the services. Jini & JavaSpaces

Programming model • Distributed Leasing • Distributed Events • Distributed Transactions Jini & JavaSpaces

What & Why Leasing? • Lease is a grant to use a resource for a certain period of time • Handles intrinsic unreliability in a distributed computing • Partial failure, Slow connection • Solves problems of traditional distributed systems • Resources never freed • Services delivered long after the request • Unbounded resource consumption • Provides extra benefits • Resource management Jini & JavaSpaces

Distributed Leasing • Jini uses distributed leasing to help create a self-healing network: it is always reflecting the current status of all the available services without any human administration! • All services are leased based on time • Lease time may be absolute or durational • Leases can be exclusive or they can allow multiple requesting services connect to a given service Jini & JavaSpaces

Lease Operations • Jini provides a simple interface for requesting, renewing and canceling a lease • Leases may be: • Cancelled (explicit cleanup) • Renewed (explicit extension) • Allowed to expire (implicit cleanup) • Obtained and manipulated by third parties Jini & JavaSpaces

Lease times • The shorter the lease times, the more current the network snapshot (a really up-to-date network) and the less likely it’ll be that a client selects a service that’s no longer available. • On the other hand, the shorter the lease times, everybody is spending all of their cycles and bandwidth renewing leases! • So, there is a tradeoff. It really depends on the type of service Jini & JavaSpaces

Characteristics of Leasing • Lease period granted cannot be more than what is requested • Lease granting policy is service specific • Lease duration allocation • Lease renewal • Client behavior when it cannot access leased resource is client implementation specific • A well-behaving client would retry Jini & JavaSpaces

Things that can be Leased • Anything that can be considered as resource • Usage of server resource • Service registrations maintained by Lookup Service • Transactions maintained by Transaction Manager • Event registrations maintained by Event Generator • Persistent storage • File system, JavaSpace Jini & JavaSpaces

Distributed Events • The distributed event model is an extension of the system used in JavaBeans. • An event is a notification system for the services to indicate that an action is to be taken. The distributed event mechanism requires that Jini services register with others to receive notification. The Jini system handles the task of locating the services according to the hierarchy. • The involving objects: event source or generator, event listener, third party objects acting as filters/proxies (event adaptors) Jini & JavaSpaces

Distributed Events • Network delivery is unreliable: messages may be lost. Synchronous methods requiring a reply may not work here • Network delivery is time-dependent: messages may arrive at different times to different listeners. So the state of an object as perceived by a listener at any time may be inconsistent with the state perceived by others. Passing complex object state across the network may be more complex to manage than passing simpler information • A remote listener may have disappeared by the time the event occurs. Listeners have to be allowed to ``time out'', like services do. Jini & JavaSpaces

Distributed Events • Jini makes no assumptions about guarantees of delivery, and does not even assume that events are delivered in order. The Jini event mechanism does not specify how events get from producer to listener - it could be by RMI calls, but may be through an unreliable third party (event adaptors): • Store -and-forward agents (offload generator object) • Notification Filters (offload receivers) • Notification Mailboxes (offline receipt) Jini & JavaSpaces

Jini and Javaspaces