‹Kopfzeile›
‹Datum/Uhrzeit›
Klicken Sie, um die Formate des Vorlagentextes zu bearbeiten
Zweite Ebene
Dritte Ebene
Vierte Ebene
Fünfte Ebene
‹Fußzeile›
‹Nr.›
Slide 1
Papadopoulos – WW ERC 2001
2/06/2001
PapadopoulosV2.9
What is Jini Technology?
Jini technology, based on Java technology, enables digital devices to simply connect together.
Jini Technology Enables You to Simply Connect
We’ve talked about what Jini technology is; now let’s take a look at what Jini technology does.
Like all the best ideas, Jini technology is based on a simple concept. Devices should work together. They should simply connect. No drivers to find, no operating system issues, no weird cables and connectors.
Yet Jini technology also introduces some exciting new concepts and capabilities. I’ll mention them briefly now and we’ll look at each of them in greater detail in the next few slides.
Instant On: When you plug a Jini device into the network, it works. Right away. No fuss. Its services and resources are immediately available.
Impromptu community: Jini software lets all devices work together, so you can create your own personal network or community--any time, anywhere. Connect your home appliances so you can control them centrally. Connect your office equipment so people can share resources. Connect to services from the road. Interact with other Jini communities quickly and easily.
Resilient: Jini technology communities adapt very quickly to changes. As users come and go, the community lives on.  And the Jini community is always available, while the Service Age allows the systems to be more tolerant and redundant.
Special delivery: Jini services are available on demand, whenever they are needed.
The Philosophy Behind Jini Technology
The overriding design goal of Jini technology was simplicity. Bill Joy, Jini’s co-inventor and the man who gave us the UNIX® operating system, said “We knew whatever we did had to be technically simple, because it’s hard to write programs, and even harder to write distributed programs. What we wanted was a very simple communications mechanism that would let the distributed system work.” So, on the premise that less is more, Joy and his team created a remarkably small piece of Java code — only 35,000 lines —  that laid down the law for object-oriented communication among devices on a network. The Jini technology team built on the Remote Method Invocation (RMI) technology of the Java platform, extending objects to remote resources, and providing an instant on  facility for access to those resources. Another key design goal was fail-safe network interaction. The design team ensured that Jini communities could restore state to devices after network failures or other problems, and that the networks were resilient — adaptable to change and able to accommodate additions or deletions from the community of services and resources. This design approach also enabled creation of impromptu communities of devices and resources, with unprecedented ability to be distributed. And the concept of community drove every aspect of the design. Jini technology had to be easy to access, easy to use, and inclusive to every type of device and service.   Importantly, Jini technology makes it easy to make older devices current, helping to preserve their investment Existing devices can become Jini community members, while future Jini devices will deliver an ever broadening array of Jini technology-enabled features.
Jini Technology Principles
With an overall design goal of simplicity, it should come as no surprise that Jini technology is based on objects.  Objects allow the network, its applications, and its devices to behave as a distributed system, where access to them is made possible through services. Using the Java Class Hierarchy, Jini technology provides a means to describe devices and the services which access them.  The Jini team built on top of the Remote Method Invocation (RMI) technology of the Java technology platform, extending objects to remote resources, which also provide flexibility in enabling code to be truly mobile. Other design characteristics, including leasing and distributed garbage collection addresses an important Jini technology goal — facilitating self-healing of the network. Specifically,  leasing provides a contract between objects, where each device registers for a certain leased period, and before the lease expires the device must re-negotiate the lease. This way, even if the device is unplugged during the lease period, once the lease expires the device’s registry will be removed automatically.   Automatic garbage collection not only makes the programming task easier, it also dramatically cuts down on bugs. Another important Jini technology principle is that individual devices/services can be very simple, and don’t necessarily require a Java Virtual Machine. While in general, we assume that each Jini-connected device has some memory and processing power, devices without processing power or memory may be connected to a Jini federation.  But those devices are controlled by another piece of hardware and/or software, called a proxy, that presents the device to the Jini system and which itself contains both processing power and memory. This provides an extremely flexible environment that is able to support existing legacy devices. The last important design principle for Jini technology is services on demand. With Jini technology, services are central, and the underlying technology is incidental. Any network resource can be a service, and all services are independent objects, freely distributable on the network.   And services are there and available whenever they are needed.  Let’s take a moment now to explore Jini technology in more detail.
Jini Technology Infrastructure: Discovery & Join
One of the key components of the Jini platform itself is called Discovery, the software that addresses the issue of how devices and software register with the network. When you plug a Jini-enabled device into the network, it drops a Discovery packet onto the network that enables it to be identified by the Jini Lookup service. The Discovery packet enables Jini services to find and join a Jini community, advertise their capabilities to the community of users, find and retrieve any needed software, and work with any device.
Jini Technology Infrastructure: Lookup Service
The Jini Lookup Service is essentially a bulletin board repository for all services available on the network. It constantly searches for Discovery packets and allows those services to register (of Join), enabling the service and its interface to become a part of the overall Jini community. Characteristics uploaded into Lookup Service include all value-added services provided by the device or application, such as drivers, help wizards, attributes, and so on.  The Lookup Service then stores discovered services as an extensible set of Java application objects, including all of the information/attributes of those services. For example, when a printer registers with the Lookup Service, it loads a printer driver or an interface to the driver into the Lookup. Then when someone wants to use that printer, he or she downloads the driver and driver interface from the Lookup onto their client device. The printer might also load other value-added services into the Lookup Service. For example, the printer might offer color printing, or support for PostScript. It might also have help wizards that will run on the client device. Its important to note that service objects are only downloaded as required. Objects in a lookup service may include other lookup services -- thus providing hierarchical lookup. Further, a lookup service may contain objects that encapsulate other naming or directory services, providing a way for bridges to be built between a Jini technology’s Lookup Service and other forms of lookup service.Of course,  references to the Lookup Service may be placed in these other naming and directory services, providing a means for clients of those services to gain access to a Jini technology federation. Lastly, a service is added to the Lookup Service by a pair of protocols called Discovery and Join — first the service locates an appropriate lookup service (by using the Discovery protocol), and then it joins it (by using the Join protocol).  The basic Lookup Service interface provides all that is needed — registration, access, search, and removal functions.
Jini Technology Infrastructure: Moving Code
When services join or leave a Lookup Service, events are signaled, and objects that have registered interest in such events get notifications when new services become available or old services cease to be active. The programming model rests on the ability to move code, which is supported by the base infrastructure. Communication between services is accomplished using Java Remote Method Invocation (RMI). The infrastructure to support communication between services is not itself a service that is discovered and used but is,  rather, a part of the Jini technology infrastructure. RMI provides mechanisms to find, activate, and garbage collect object groups. RMI also provides the infrastructure for multicast, replication, and the mechanisms for basic security and confidentiality. Fundamentally, RMI is a Java-programming-language-enabled extension to traditional remote procedure call mechanisms. RMI allows not only data to be passed from object to object around the network but full objects, including code. Much of the simplicity of the Jini system is enabled by this ability to move code around the network in a form that is encapsulated as an object.
Jini Technology Programming Model: Leasing
To make it extremely simple to access and use services, Sun has developed a “leasing” concept for Jini communities. With Jini technology, objects (services) can negotiate leases with each other, specifying type of service, length of time the service is available, and so on. So in a sense, Leasing provides a loose contract between objects. Each device registers for a certain leased period, and before the lease expires the device must re-negotiate the lease. This way, even if the device is unplugged during the lease period, once the lease expires the device’s registry will be removed automatically. All resources can be shared or non-shared.  Permission is granted or denied via access control software.
Jini Technology Programming Model: Transactions
A series of operations, either within a single service or spanning multiple services, can be wrapped in a transaction. Specifically designed for distributed object conversations,  transaction interfaces supply a service protocol needed to coordinate a two-phase commit. Two-phase commit provides two steps to coordinate the actions of a group of distributed objects. The first step is called the voting phase in which each object “votes” whether it has completed its portion of the task and is ready to commit any changes it made. In the second step, a coordinator issues a commit request to each object. The Jini technology transaction protocol differs from most transaction interfaces in that it does not assume that the transactions occur in a transaction processing system.  Such systems define mechanisms and programming requirements that guarantee the correct implementation of a particular transaction semantics. The Jini technology transaction protocol takes a more traditional object-oriented view, leaving the correct implementation of the desired transaction semantics up to the implementor of the particular objects that are involved in the transaction. The goal of the transaction protocol is to define the interactions that such objects must have to coordinate such groups of operations. The interfaces that define the Jini technology programming model are used by the infrastructure components where appropriate and by the initial Jini technology services. For example, the Lookup Service makes use of the leasing and event interfaces: Leasing insures that services registered continue to be available, and events help administrators discover problems and devices needing configuration. Leasing also supports nested transactions.  The JavaSpaces™ Service — a Jini technology service — utilizes leasing and events, and also supports the two-phase commit protocol. The transaction manager can be used to coordinate the voting phase of a transaction for those objects that support two-phase commit.
Jini Technology Programming Model: Distributed Events
Distributed Events is a particularly important feature of the Java technology programming model.  It is designed to address the peculiarities of handling messaging in a networked environment, including latency and recovery from network failure. Distributed Events extends the Java Technology platform event model to enable it to work in a distributed network.  For example, when services join or leave a Lookup Service, Events are signaled, and objects that have registered interest in such events get notifications when new services become available or old services cease to be active. An object may allow other objects to register interest in events in the object and receive a notification of the occurrence of such an event. This enables distributed event-based programs to be written with a variety of reliability and scalability guarantees.  This event mechanism approach also allows for easy use of event managers and can use many different distributed delivery models such as pushing, pulling, or filter designs.
Distributed Events also uses the Leasing protocol for efficiency and simplified design.
Jini Technology Infrastructure: Distributed Security
Jini technology’s Distributed Security model builds on the Java Virtual Machine.  It is a Remote Method Invocation (RMI) -based security mechanism that adds a twin notion of principal and access control lists.
Jini technology services are accessed on behalf of some entity — the principal — which generally traces back to a particular user of the system. Services themselves may request access to other services based on the identity of the object that implements the service. Whether access to a service is allowed depends on the contents of an access control list that is associated with the object.
Jini Technology Services: JavaSpaces Technology
In today’s distributed applications, there is a relatively high degree of coupling between various network resources. This is undesirable because it makes applications much harder to build and maintain.  This situation is even worse when dealing with multiple languages and platforms. As a result there is enormous complexity embedded in resources such as knowing communication protocols, object models, etc.  JavaSpaces introduces a shared dynamic memory mechanism for Java Virtual Machines on the network. The Java platform creates a homogeneous platform where there previously was a heterogeneous platform. The JavaSpaces technology goes farther to decouple the providers and the requestors of network services. JavaSpaces technology does this by delivering a unified environment for sharing, communicating, and coordinating. JavaSpaces technology acts as a lightweight infrastructure where multiple spaces may co-exist within one network.  It helps federate a network of Java Virtual Machines. JavaSpaces technology provides simple, dynamic object persistence.  Persistence indicates that a collection of data remains intact even if its source is no longer attached to the network. The objects in JavaSpaces for example, remain available to other users even if the source has temporarily disconnected from the network. This feature is critical to keep distributed systems highly available. The JavaSpaces technology is a simple, fast, and unified mechanism for sharing, coordinating, and communicating distributed resources, services, and objects across a network. A JavaSpace system can be thought of as an event-driven distributed cache with behavior transfer capabilities. This technology extends well beyond the base functionality of a simple messaging system. In fact, it facilitates alternative messaging mechanisms, including asynchronous, store and forward, routed, filtered and others. The service interface of JavaSpaces technology provides facilities for writing, finding, reading, removing, and generating/responding to events or objects in the environment.