This chapter is from the book
This chapter is from the book
This chapter is from the book
System Components
The Jini system comprises three components: (1) the infrastructure, (2) a programming model, and (3) services (see Figure 2–6).
)
Figure 2-6 Jini components' detail.
Infrastructure Component
The Infrastructure component is a core part of the architecture and its goal is to provide mechanisms for devices, services, and users to discover, join, and detach from the network. The Infrastructure component is composed of the following subcomponents:
Discovery and join protocol, which defines the way that services discover, become part of, and advertise services to the other members of the federation.
Remote method invocation (RMI), the distributed architecture environment that enables service proxies to be downloaded.
Distributed security model, which provides the concept of security within the network. The distributed security model is an extension of Java's security model for distributed systems.
Lookup service, which serves as a repository of services and helps network members to find each other within the Jini community. Entries in the repository are Java-compliant byte-code objects, which can be written in Java or wrapped by Java.
Programming Model Component
The programming model is based on the Java application platform and its ability to move code between nodes. The programming model defines a set of interfaces, which taken together become the distributed extension of the Java programming model to form the Jini programming model. The programming model supports the following interfaces:
Lease interface, which extends the Java programming model by adding time to the notion of holding a reference. This approach provides a renewable, duration-based model for allocating and freeing the resource references.
Event notification interface, which extends the popular JavaBeans component event delegation model. This model allows an event to be handled by third-party objects and recognizes that the delivery of the distributed notification may be delayed.
Transaction interface, which allows the system to handle object-oriented transaction handling. The interface does not define the actual mechanisms involved in the transaction but provides rules for the objects involved in the transaction. This approach provides freedom in choosing the preferred mechanics and individual object implementation.
Services Component
The services component represents an important concept within Jini architecture, and it denotes the entities that have come together to form the Jini community. The entities could be hardware, software, or a combination of hardware and software. The services are identified as Java objects within the system. Each service has an interface, which defines the operations that can be requested of that service. The interface also reflects the service type. A service is a composite entity and can be composed of other subservices. In fact, the lookup service—one of the subcomponents of the core Jini infrastructure—is implemented as a Jini service. Other constituents that form a part of Jini architecture and implemented as Jini services are:
JavaSpaces service, which provides an optional distributed persistence mechanism for the objects within a Jini community
Transaction manager service, which provides distributed transactions for the distributed objects
Interaction and Interdependence between Components
As stated above, although the system has three parts, each part has a specific role in the overall architecture and they work in tandem to achieve the overall system objective (see Figure 2–7). Both infrastructure and service components rely heavily on the programming model. For example, the lookup service makes use of leasing and event interfaces: JavaSpaces utilizes leasing, event, and transaction interfaces. In short, any component within the Jini system has to adopt the programming model recommended.
)
Figure 2-7 Component dependence:UML class diagram.
Theoretically, any service component is not forced to implement the programming model interfaces, but that is required for interaction with the infrastructure. For example, whether or not a service implements a leased service when it registers with a lookup service, it is leased. In scenarios where a service requester just invokes the service provider's method without sharing any resources or maintaining session information, leasing can be optional. An example of valid Jini service that does not use leasing and transaction is Jiro's log service. (Jiro technology provides tools and technology to reduce interop-erability issues between storage systems, management software, and network devices.) Thus, the combination of infrastructure, services, and a programming model makes this architecture more reliable, dependable, and dynamic and helps to overcome the known issues with distributed computing.