The Plug and Play infrastructure of Jini technology consists primarily of three sets of protocols: Lookup (Lookup), Discovery (Discovery), and join (join). Lookup service is the basic component of distributed Jini system, and it provides the central registration mechanism of service in distributed Jini system. In a jini system, the preferred way for a program to find a service is through a lookup service, and the lookup service is also the basis for providing administrators and users with a variety of access interfaces.
Finding Service models for services
The lookup service holds a table of services, each of which represents a service available in the system, saving the code needed to access the service and a series of properties that describe the service. For example, the lookup service is like a phone book, and the service in the Jini system is like a user in the phone book, and the information that is stored in the service is the user's phone number. That is, whenever you need to access a service in the Jini system, you must know the "phone number" that is saved in the lookup service. However, the search service has a number of advantages over the phone book, such as: The lookup service holds a dynamic "phone book", and services in the system can actively join and remove their "phone number" from the phone book, and the lookup service fully supports this mechanism. And in the future, we will find more differences in the content.
When the service is registered in the lookup service, a notification event is generated. The system administrator can receive this notification using the event callback mechanism in the lookup service. This helps the system administrator manage and maintain the system. The service also provides a user interface for setting itself, which can be saved to the lookup service as a property of the service. Administrators can easily set up services without being busy looking for a wide variety of drivers and management software.
During the lifetime of a service, if a service encounters problems that require administrator attention, for example, the print service discovers a paper shortage service adds an attribute to indicate the problem. The changed results are saved to the lookup service. At this point, as described above, the administrator uses the event callback mechanism of the lookup service to receive notification of the above issue. With this powerful mechanism, the burden of the system administrator is greatly reduced.
Discovery Protocol and Accession Agreement
After the service in the network starts, how joins in the distributed Jini system, becomes the service in the Jini system, has two important essential steps. The first step must be to find the system in the search service, this process is the discovery process, the use of the Protocol is to discover the protocol. The second step is to register yourself in the lookup service, which is the join process, and the protocol describing the process is the join protocol. A service, after completing these two steps, truly becomes a member of the Jini system. To accurately describe the two protocols, first introduce the terminology used.
Host. A hardware device that owns one or more Java virtual machines and can join the network is called a host group. A set of Jini services. The name of the group is any string that describes the nature of the group.
Discovery entities. The discovery entity is within the same host, is about to start, or is in the process of locating a lookup service, or a collection of objects in one or more collaborative Java languages.
Join entity. The join entity is within the same host, has acquired the lookup service, is in a collection of objects in one or more collaborative Java languages that query services from the lookup service or register themselves into the Jini system. In future articles, the Discovery entity and join entity are called entities for convenience of description.
Services in the Jini system include a wide range of services including pure software services and hardware devices. If a host wants to join the Jini system and become a service in the Jini system, the following conditions are required: First, a Java virtual machine that can run the Jini code, and then a properly configured network protocol stack. The network protocol stack changes as the network protocol is different. This assumes that the network layer of the Protocol is the IP protocol, at this time the following conditions are essential: IP address (IP address or static IP address, or by the host using DHCP protocol to obtain the dynamic IP address) Support for TCP protocols and UDP multicast protocols (both protocols are used during the discovery process). For example, a networked PC with a JDK (Java Development Kit) is a mainframe computer.
Each lookup service has a group associated with it, which makes the service structure in the Jini system more layered. For example, a specific lookup service can belong to a print unit group, and any print service can be registered in the lookup service. Of course, the groups are all predefined. In the discovery process, the discovery entity determines which group it is interested in, the group that it wants to join, and if the lookup service is found to belong to such a group, the discovery entity is added to the lookup service. This avoids the huge structure of the lookup service, allocating responsibility for the services in the organization system to the different lookup services in the system. At present, there is no clear specification for the name of the group, Sun is only hoping that the names of the group best conform to the naming of network domain names, but there is no detailed specification of how to define the name of the group. We believe that in the course of future development, the nomenclature will be perfected with the improvement of the hierarchy of service organization structure in Jini system.
1. Found
There are three protocols used in the Discovery entity and lookup service interactions: Multicast Request Protocol (Multicast requests Protocol), Multicast announcement Protocol (Multicast Announcement Protocol ) and the Unicast Discovery Protocol (Unicast Discovery protocol). The first of these three Protocols is briefly introduced here.
Multicast request protocol. The discovery entity uses this protocol to discover the lookup services that exist in the Jini system. This protocol can be used to design browsers that browse services in the Jini system.
Multicast announcement protocol. The lookup service uses the protocol to publish its own datagram in the system after it has been started or during the recovery of a network crash.
Single point of delivery discovery protocol. This protocol is used to proactively establish point-to-point communication between the discovery entity and the lookup service when one is aware of another's network address and port number.
In the process of discovery, the connection between the discovery entity and the lookup service is based on the socket layer. Both are client side and service side. In the process of communication, it is divided into two stages.
The first phase: the discovery entity and the lookup service each have a single point of delivery server that can be understood as an ordinary Internet server, such as an FTP server in the FTP protocol, The goal is to allow the Discovery entity and lookup service to establish a point-to-point connection to the other. The question now is: How do you get both sides to know each other's server address? The answer to this question will be found in the second phase of the description.
The second phase: At this point the discovery entity and the lookup service do not know each other's network address, but according to the requirements of the Jini system, both parties have added a specific multicast group at the network layer (this group is not the concept of the group in the Jini system, but the group in the Network Protocol), And both sides know the group address of the network group the other party joins. Because the network protocol supports sending UDP packets to all machines in a network group at the same time, by using this feature, both parties send packets to the group to which they belong. The process by which discovery entities send packets is called multicast requests, and the process of sending packets in a lookup service is called multicast broadcast announcements. The respective addresses and other necessary information are saved in the packets sent by both. At the same time, both sides have established a server that listens to UDP packets sent to this group. The service of a server established by the discovery entity is called multicast broadcast Listening service, and the server created in the lookup service is called multicast Broadcast request service. The server decodes the received packets and can know the address of the client side. The protocol used in this phase is the multicast request protocol and Multicast Announcement protocol. At this point, the discovery process is entering the third phase.