EP1194837A2 - Dynamic lookup service in a distributed system - Google Patents
Dynamic lookup service in a distributed systemInfo
- Publication number
- EP1194837A2 EP1194837A2 EP00941355A EP00941355A EP1194837A2 EP 1194837 A2 EP1194837 A2 EP 1194837A2 EP 00941355 A EP00941355 A EP 00941355A EP 00941355 A EP00941355 A EP 00941355A EP 1194837 A2 EP1194837 A2 EP 1194837A2
- Authority
- EP
- European Patent Office
- Prior art keywords
- service
- lookup
- client
- cache
- manager
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L12/2807—Exchanging configuration information on appliance services in a home automation network
- H04L12/2809—Exchanging configuration information on appliance services in a home automation network indicating that an appliance service is present in a home automation network
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
- G06F9/548—Object oriented; Remote method invocation [RMI]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L12/2805—Home Audio Video Interoperability [HAVI] networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/55—Push-based network services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/46—Indexing scheme relating to G06F9/46
- G06F2209/462—Lookup
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5015—Service provider selection
Definitions
- the present invention relates generally to data processing systems and, more particularly, to a dynamic lookup service in a distributed system.
- a lookup service contains an indication of where network services are located within a distributed system comprised of multiple machines, such as computers and related peripheral devices, connected in a network (for example, a local area network, wide area network, or the Internet).
- a "network service” refers to a resource, data, or functionality that is accessible on the network.
- the lookup service typically contains an address used by a client (e.g., a program) to access the service (e.g., a printer).
- Systems consistent with the present invention provide an improved lookup service that allows for the dynamic addition and deletion of services.
- This lookup service allows for the update, i.e., addition and deletion of available services automatically, without user intervention.
- clients of the lookup service may continue using the lookup service and its associated services while the updates occur.
- the lookup service provides a notification mechanism that can be used by clients to receive a notification when the lookup service is updated. By receiving such a notification, clients can avoid attempting to access a service that is no longer available and can make use of new services as soon as they are added to the lookup service.
- a method is provided in a data processing system having a lookup service with associated services. This method receives a request by the lookup service for notification when the lookup service is updated, determines when the lookup service is updated, and generates a notification when it is determined that the lookup service is updated.
- a method is provided in a data processing system having a lookup service with associated services. This method sends a request to the lookup service to be notified when the lookup service is updated and receives an indication that the lookup service has been updated.
- a method is provided in a data processing system having a lookup service with associated services and a client lookup manager with an associated cache. This method transmits an event by the lookup service that identifies a change to one of the associated network services. The client lookup manager receives the event and updates the associated cache to reflect the change.
- a method in a data processing system having a client and lookup service with associated services. This method receives a request from a client for access to a network service, then retrieves a reference from a cache reflecting a particular network service corresponding to the requested network service and transmits the reference to the client.
- a data processing system comprising a memory and a processor is provided.
- the memory includes a lookup service containing indications of services that are available for use, a first client for updating the lookup service, and a second client for utilizing the lookup service while the first client is updating the lookup service.
- the processor runs the lookup service, the first client, and the second client.
- a data processing system containing a memory and a processor
- the memory contains a lookup service with indications of services available for use and a client.
- the lookup service receives requests for notification of when the lookup service is updated, determines when the lookup service is updated, and generates notifications when the lookup service is updated.
- the client sends a request to the lookup service to be notified when the lookup service is updated.
- the processor runs the client and the lookup service.
- a data processing system containing a memory and a processor
- the memory contains a lookup service with references to a plurality of network services available for use, a client, and a client lookup manager with an associated cache stored on the client computer.
- the client lookup manager accesses the lookup service and stores service references in the cache.
- the processor runs the client and the lookup service.
- a computer- readable memory device containing a data structure is provided. This data structure is for accessing a lookup service with associated network services available for use.
- the data structure contains a notify method for use by a client to register with the lookup service to receive a notification from the lookup service when the lookup service is updated.
- Figure 1 depicts a distributed system suitable for practicing methods and systems consistent with the present invention
- Figure 2 depicts a more detailed block diagram of a computer depicted in Fig. 1 ;
- Figures 3 A and 3B depict a flow chart of the steps performed when a client utilizes the lookup service depicted in Fig. 1;
- Figure 4 depicts a flow chart of the steps performed by the lookup service of Fig. 1 when performing event-related processing
- Figure 5 depicts a conference room containing a number of devices consistent with the present invention
- Figure 6 depicts a screen displaying icons representing services available in the conference room of Figure 5;
- Figure 7 depicts a screen displaying the available services provided by a computer in the conference room of Figure 5;
- Figure 8 depicts an alternate embodiment of the computer depicted in Figure 2;
- Figure 9 depicts a flow chart of the steps performed by the client lookup manager of Fig. 8 when populating the cache;
- Figure 10 depicts a flow chart of the steps performed by the filtering algorithm contained within the client lookup manager
- Figure 11 depicts a flow chart of the steps performed by a first query processing algorithm contained within the client lookup manager
- Figure 12 depicts a flow chart of the steps performed by a second query processing algorithm contained within the client lookup manager.
- Figure 13 depicts a flow chart of the steps performed by a notification process contained within the client lookup manager.
- Methods and systems consistent with the present invention provide an improved lookup service that allows for the dynamic addition and deletion of services.
- the addition and deletion of services is performed automatically, without user intervention, and clients of the lookup service may continue using the services while the updates to the lookup service occur.
- clients may register with the lookup service to receive notification of when the lookup service is updated.
- all registered clients receive a notification of the update, enabling the clients to avoid attempting to access a service that is no longer available and to use a service recently added to the lookup service.
- the exemplary distributed system (1) allows users of the system to share services and resources over a network of many devices; (2) provides programmers with tools and programming patterns that allow development of robust, secured distributed systems; and (3) simplifies the task of administering the distributed system.
- the exemplary distributed system utilizes the JavaTM programming environment to allow both code and data to be moved from device to device in a seamless manner. Accordingly, the exemplary distributed system is layered on top of the Java programming environment and exploits the characteristics of this environment, including the security offered by it and the strong typing provided by it.
- the Java programming environment is more clearly described in Jaworski, Java 1.1 Developer's Guide.
- the exemplary distributed system provides the simplicity of access and the power of sharing that can be provided by a single system without giving up the flexibility and personalized response of a personal computer or workstation.
- the exemplary distributed system may contain thousands of devices operated by users who are geographically disperse, but who agree on basic notions of trust, administration, and policy.
- various logical groupings of services provided by one or more devices and each such logical grouping is known as a Djinn.
- a “service” refers to a resource, data, or functionality that can be accessed by a user, program, device, or another service and that can be computational, storage related, communication related, or related to providing access to another user.
- Examples of services provided as part of a Djinn include devices, such as printers, displays, and disks; software, such as applications or utilities; information, such as databases and files; and users of the system.
- Both users and devices may join a Djinn.
- the user or device When joining a Djinn, the user or device adds zero or more services to the Djinn and may access, subject to security constraints, any one of the services it contains.
- devices and users federate into a Djinn to share access to its services.
- the services of the Djinn appear programmatically as objects of the Java programming environment, which may include other objects, software components written in different programming languages, or hardware devices.
- a service has an interface defining the operations that can be requested of that service, and the type of the service determines the interfaces that make up that service.
- Fig. 1 depicts the exemplary distributed system 100 containing a computer 102, a computer 104, and a device 106 interconnected by a network 108.
- the device 106 may be any of a number of devices, such as a printer, fax machine, storage device, input device, computer, or other devices.
- the network 108 may be a local area network, wide area network, or the Internet. Although only two computers and one device are depicted as comprising the exemplary distributed system 100, one skilled in the art will appreciate that the exemplary distributed system 100 may include additional computers or devices.
- Fig.2 depicts the computer 102 in greater detail to show a number of the software components of the exemplary distributed system 100.
- Computer 102 includes a memory 202, a secondary storage device 204, a central processing unit (CPU) 206, an input device 208, and a video display 210.
- the memory 202 includes a lookup service 212, a discovery server 214, and a Java runtime system 216.
- the Java runtime system 216 includes the Java remote method invocation system (RMI) 218 and a Java virtual machine 220.
- the secondary storage device 204 includes a Java space 222.
- the Java runtime system 216 includes the Java Application Programming Interface (API), allowing programs running on top of the Java runtime system to access, in a platform-independent manner, various system functions, including windowing capabilities and networking capabilities of the host operating system. Since the Java API provides a single common API across all operating systems to which the Java runtime system 216 is ported, the programs running on top of a Java runtime system run in a platform-independent manner, regardless of the operating system or hardware configuration of the host platform.
- the Java runtime system 216 is provided as part of the Java software development kit available from Sun Microsystems of Mountain View, CA.
- the Java virtual machine 220 also facilitates platform independence.
- the Java virtual machine 220 acts like an abstract computing machine, receiving instructions from programs in the form of bytecodes and interpreting these bytecodes by dynamically converting them into a form for execution, such as object code, and executing them.
- RMI 218 facilitates remote method invocation by allowing objects executing on one computer or device to invoke methods of an object on another computer or device. Both RMI and the Java virtual machine are also provided as part of the Java software development kit.
- the lookup service 212 defines the services that are available for a particular
- the lookup service 212 contains one object for each service within the Djinn, and each object contains various methods that facilitate access to the corresponding service.
- the lookup service 212 and its access are described in greater detail in co-pending U.S. Patent Application No. 09/044,826, entitled "Method and System for Facilitating Access to a Lookup Service,” which has previously been incorporated by reference.
- the discovery server 214 detects when a new device is added to the exemplary distributed system 100, during a process known as boot and join or discovery, and when such a new device is detected, the discovery server passes a reference to the lookup service 212 to the new device, so that the new device may register its services with the lookup service and become a member of the Djinn. After the device discovers the lookup service 212, the device may access any of the services registered with the lookup service 212. Furthermore, the device may also advertise its own services by registering with the lookup service 212. Once registered, the services provided by the device may be accessed through the lookup service 212, by all other entities that also discover lookup service 212.
- the process of boot and join is described in greater detail in co-pending U.S. Patent Application No.09/044,939, entitled "Apparatus and Method for providing Downloadable Code for Use in Communicating with a Device in a Distributed System," which has previously been incorporated by reference.
- the Java space 222 is an object repository used by programs within the exemplary distributed system 100 to store objects. Programs use the Java space 222 to store objects persistently as well as to make them accessible to other devices within the exemplary distributed system. Java spaces are described in greater detail in co-pending U.S. Patent Application No. 08/971,529, entitled “Database System Employing Polymorphic Entry and Entry Matching,” assigned to a common assignee, filed on November 17, 1997, which is incorporated herein by reference. One skilled in the art will appreciate that the exemplary distributed system 100 may contain many lookup services, discovery servers, and Java spaces.
- a lookup service provides a central registry of services available within a Djinn. This lookup service is the primary mechanism for programs to find services within the Djinn and is the foundation for providing user interfaces through which users and administrators can discover and interact with services of the Djinn.
- the lookup service maintains a flat collection of service items.
- the collection is flat in that the service items do not form a hierarchy.
- Each service item represents an instance of a service available within the Djinn.
- the service item contains a stub (if the service is implemented as a remote object) or a serialized object (if the service is a local object stored in the lookup service) that programs use to access the service, and an extensible collection of attributes that describe the service or provide secondary interfaces to the service.
- a "stub” is code and data that facilitates access to a remote function
- a "serialized object” is an object placed in a serialized form.
- the lookup service provides a set of methods to enable users and administrators to browse the collection and build a variety of user interfaces. Once an appropriate service is found, the user can interact with the service by loading a user interface applet, attached as another attribute on the item.
- a new service is created (e.g., when a new device is added to a Djinn)
- the service registers itself with the lookup service, providing an initial collection of attributes. For example, a printer may include attributes indicating speed (in pages per minute), resolution (in dots per inch), and whether duplex printing is supported.
- the attributes also contain an indicator that the service is new and needs to be configured.
- the administrator locates an attribute that provides an applet for this purpose, and during configuration, the administrator may add new attributes, such as the physical location of the service and a common name for it.
- the lookup service provides an event mechanism that generates notifications as new services are registered, existing services are deleted, or attributes of a service are modified. To use the event mechanism, a client registers to be notified upon the occurrence of a particular event, and when the event occurs, the lookup service notifies the client.
- Programs that need a particular type of service can use the lookup service to find an instance of the service.
- a match may be made based on the specific Java programming language types implemented by the service as well as the specific attributes attached to the service.
- a service encounters a problem that needs administrative attention, like a printer running out of toner, the service can add an attribute that indicates the problem. Administrators (or programs) can then use the event mechanism to receive notification of such problems .
- the attributes of a service item are represented as a set of attribute sets.
- An individual set of attributes may be represented as an instance of a class in the Java programming language, each attribute being a public field of that class. The class provides strong typing of both the set and the individual attributes.
- a service item can contain multiple instances of the same class with different attribute values as well as multiple instances of different classes. For example, an item may have multiple instances of a Name class, each giving the common name of the service in a different language, plus an instance of a Location class, an Owner class, and various service-specific classes.
- the "servicelD” element is a numerical identifier of the service.
- the "service” element is an object representing the service or a stub facilitating access to the service, and the “attributeSets” element contains the array of attributes for the service.
- ServiceTemplate instances of the ServiceTemplate class
- the "serviceTypes" element defines the types of the service.
- An item (item) matches a service template (tmpl) if item.servicelD equals tmpl. servicelD (or if tmpl.servicelD is zero) and item.service is an instance of every type in tmpl. serviceTypes, and item.attributeSets contains at least one matching entry for each entry template in tmpl.attributeSetTemplates. Entry matching uses the following rule: an entry matches an entry template if the class of the entry is the same as, or a superclass of, the class of the template and every non-null field in the template equals the corresponding field of the entry. Every entry can be used to match more than one template. Both serviceTypes and attributeSetTemplates can be null in a service template.
- the ServiceltemFilter interface defines the methods used by an object to apply additional matching criteria when searching for services on a lookup service. This filtering mechanism is particularly useful to entities that wish to extend the capabilities of the standard template matching schema previously discussed. For example, since template matching does not allow one to easily search for services based on a range of attribute values, this additional matching mechanism can be exploited by the entity to ask the managing object to find all registered printer services that have a resolution attribute between 300 and 1200 dpi.
- the "check" method defines the implementation of the additional matching criteria to apply to a Serviceltem object found through standard template matching. This method takes the Serviceltem object as the sole argument, to test against the additional criteria. This method returns true if the input object satisfies the additional criteria, and false otherwise.
- the ServiceMatches class is used for the return value when looking up multiple items.
- the definition of this class follows: public class ServiceMatches ⁇ public Serviceltem[] items; public int totalMatches;
- ServiceTemplate tmpl throws RemoteException
- This interface includes various methods, including the register method, the lookup method (single parameter form), the lookup method (two parameter form), the addAttributes method, the modify Attributes method, the notify method, the getEntryClass method, the getFieldValues method, and the getServiceTypes method.
- the "register” method is used to register a new service and to re-register an existing service. This method is defined so that it can be used in an idempotent fashion. Specifically, if a call results in generation of an exception (in which case the item might or might not have been registered), the caller can simply repeat the call with the same parameters.
- item. ServicelD should be zero; if item.ServicelD does not equal any existing item's service object, then a new unique service id will be assigned and returned. The service id is unique over time with respect to this lookup service. If item.ServicelD does equal an existing item's service object, the existing item is deleted from the lookup service (even if it has different attributes), but that item's service id is reused for the newly registered item.
- item.ServicelD should be set to the same unique service id that was returned by the initial registration. If an item is already registered under the same service id, the existing item is deleted (even if it has different attributes or a different service instance). Note that service object equality is not checked in this case to allow for reasonable evolution of the service (e.g., the serialized form of the stub changes, or the service implements a new interface). When an item is registered, duplicate attribute sets are eliminated in the stored representation of the item. Additionally, the registration is persistent across restarts of the lookup service.
- the single-parameter form of the "lookup" method returns the service object (i.e., Serviceltem.service) from an item matching the template, or null if there is no match. If multiple items match the template, it is arbitrary as to which service object is returned. If the returned object cannot be deserialized, an exception is generated.
- the two-parameter form of the "lookup" method returns at most maxMatches items matching the template, plus the total number of items that match the template. The return value is never null, and the returned items array is only null if maxMatches is zero. For each returned item, if the service object cannot be deserialized, the service field of the item is set to null and no exception is generated. Similarly, if an attribute set cannot be deserialized, that element of the attributeSets array is set to null and no exception is generated.
- the "addAttributes” method adds the specified attribute sets (those that aren't duplicates of existing attribute sets) to all items matching the template. The number of items that were matched is returned. Note that this operation has no effect on existing attribute sets of the matching items, and the operation can be repeated in an idempotent manner.
- the "modify Attributes" method is used to modify existing attribute sets.
- the lengths of tmpl.attributeSetTemplates and attrSets must be equal or an exception is generated.
- the item's attribute sets are modified as follows. For each array index I: if attrSets[t] is null, then every entry that matches tmpl.attributeSetTemplates[t] is deleted; otherwise, for every non-null field in attrSets [I], the value of that field is stored into the corresponding field of every entry that matches tmpl.attributeSettemplates[/].
- the class of attrSetsft] must be the same as, or a superclass of, the class of tmpl.attributeSetTemplates [/], or an exception is generated. If the modification results in duplicate entries within an item, the duplicates are eliminated. The number of items that were matched is returned.
- the "notify” method is used to register for event notification.
- the registration is leased, and the lease expiration request is exact.
- the concept of a lease is described in greater detail in U.S. Patent Application No. 09/044,923, entitled “Method and System for Leasing Storage,” which has previously been incorporated by reference.
- the registration is persistent across restarts of the lookup service until the lease expires or is canceled.
- the event id in the returned EventRegld is unique at least with respect to all other active event registrations at this lookup service with different service templates of transitions.
- TRANSITION_MATCH_NOMATCH an event is sent when the changed item matches the template before the operation, but doesn't match the template after the operation (this includes deletion of the item).
- TRANSITION_NOMATCH_MATCH an event is sent when the changed item doesn't match the template before the operation, (this includes not existing), but does match the template after the operation.
- TRANSITION_MATCH_MATCH an event is sent when the changed item matches the template both before and after the operation.
- the " getEntryClasses" method looks at all items that match the specified template, finds every entry among those items that either doesn't match any entry templates or is a subclass of at least one match entry template, and returns the set of the (most specific) classes of those entries. Duplicate classes are eliminated, and the order of classes within the returned array is arbitrary. Null (not a empty array) is returned if there are no such entries or no matching items. If a returned class cannot be deserialized, that element of the returned array is set to null and no exception is thrown.
- the "getFieldValue” method identifies all items that match the specified template. This method returns the values of the items that match the specified template.
- the "getServiceTypes" method looks at all items that match the specified template, and for every service object, this method finds every type (class or interface) of which the service object is an instance that is neither equal to, nor a superclass of, any of the service types in the template, and returns the set of all such types that start with the specified package prefix. Duplicate types are eliminated, and the order of types within the returned array is arbitrary. Null (not an empty array) is returned if there are no such types. If a returned type cannot be deserialized, that element of the returned array is set to null and no exception is thrown.
- FIGs 3 A and 3B depict a flowchart of the steps performed when a client, a program running on a particular device, makes use of the lookup service 212.
- the device on which the client runs is connected to the Jini distributed system (step 302).
- the client sends a multi-cast packet containing code for communication with the client (step 304).
- the client is performing the discovery protocol as described in further detail in co-pending U.S. Patent Application No.09/044,945, entitled "Apparatus and Method for Providing Downloadable Code for Use in Communication With a Device in a Distributed System," which has previously been incorporated by reference.
- the discovery server 214 receives the packet and uses the code contained in the packet to send a reference to the lookup service to the client (step 306). After the client receives the reference to the lookup service, the client is able to utilize the interface of the lookup service to either add a service, delete a service, access a service, or request notification when the lookup service is updated, as reflected by steps 308-326.
- the client may decide to add a service to the lookup service (step 308). If it decides to add a service, the client adds a service to the lookup service by invoking the register method, which sends to the lookup service either an object representing the service or a stub containing code and data to facilitate access to the service (step 310).
- the stub to the lookup service is described in greater detail in co-pending U.S. Patent Application No.09/044,826, entitled "Method and System for Facilitating Access to a Lookup Service," which has previously been incorporated by reference.
- the client may decide to delete one of its services from the lookup service (step 312). If a client decides to do so, the client deletes the service from the lookup service by canceling the service's lease with the lookup service (step 314). It should be noted that both the addition of a service and the deletion of a service are done dynamically and in a manner that does not prohibit other clients from using the lookup service while the update occurs.
- the client may decide to access a service provided by the lookup service (step 316). If a client decides to access a service provided by the lookup service, the client accesses the service by invoking the lookup method, which retrieves from the lookup service either the object or the stub information for the service, and the client then either invokes methods on the object to use the service or uses the stub information to access the service (step 318).
- the step is described in greater detail in co-pending U.S. Patent Application No.09/044,826, entitled "Method and System for Facilitating Access to a Lookup Service, " which has previously been incorporated by reference.
- the client may also request to be notified when an update occurs to the lookup service (step 320 in Fig. 3B). If a client wishes to be notified, the client invokes the notify method on the lookup service interface to register a callback routine with the lookup service (step 322).
- a "callback routine" is a function that is invoked when the lookup service is updated. Additionally, the notify method allows the client to register an object that will be passed back, via RMI, as a parameter to the callback function.
- the registered callback routine is invoked by the lookup service (step 326).
- the client is notified of the occurrence of the event and can take appropriate action. For example, if a service that the client was currently using has become unavailable, the client may store information so that it no longer uses it.
- Figure 4 depicts a flow chart of the steps performed by the lookup service when performing event-related processing.
- the lookup service receives registrations from a number of clients interested in receiving notifications when particular events occur (step 402).
- the lookup service receives the registrations via invocation of the notification method on the lookup service interface and stores into a table, known as the event table, all of the associated information, such as an indication of the client to be notified, a reference to the callback routine, an object to be passed as a parameter to the callback routine, and an indication of the event in which the client is interested.
- a client may register to be notified upon the occurrence of an event, or the client may register for a third party to be notified.
- the lookup service determines whether an event occurred such that at least one client has registered an interest in the event (step 404). The lookup service makes this determination by identifying when, for example, a new service has been added to the lookup service, an existing service has been deleted from the lookup service, or the attributes of a service have been modified. If such an event has not occurred, the event notification process of the lookup service remains in a wait state. However, if an event has occurred, the lookup service determines all clients registered for notification for this event (step 406). The lookup service makes this determination by accessing the event table. Next, the lookup service invokes the callback routines registered for each client identified in step 406 (step 408). In this step, the event table contains a reference to the callback routine registered by each client, and the lookup service invokes each callback routine, passing the registered objects as parameters, to notify the clients of the occurrence of the event.
- lookup services are generally located on a computer remote from the client, a query to a lookup service typically involves a remote call. Such remote calls are much more costly in terms of processing overhead and failure risk than are local procedure calls.
- FIG. 8 depicts a client computer in accordance with an alternate embodiment of the present invention.
- computer 104 includes a memory 802, secondary storage device 804, CPU 806, input device 808, video display 810, and Java runtime system 316.
- Client computer 104 additionally includes a client 812, a client lookup manager 814 and a cache 815.
- the client lookup manager 814 is implemented by a client lookup manager class comprised of a helper utility class that any client 812 can use to create and populate a cache 815, and with which the client can register for notification of the availability of services of interest.
- a helper utility is a programming component that can be used during construction of Jini services and/or clients. Helper utilities are not remote. In other words, their methods typically do not execute on remote hosts. Consequently, they do not register with a lookup service and they are instantiated locally by devices wishing to employ them.
- the client lookup manager 814 evaluates each of the associated network services and stores references to network services of interest in the local cache 815. As shown in FIG. 9, when the client lookup manager receives a reference to a lookup service (step 900), it extracts the network service (step 910) and evaluates whether the service is of interest to the client (step 920). If the service is of interest, the client lookup manager adds the service to the cache in step 930 and process flows to step 940. If the service is not of interest, process immediately flows to step 940 where the client lookup manager determines whether there are more network services available in the lookup service.
- program execution returns to step 910, where another network service is extracted. If there are not any more network services available, process flows to step 950 where the client lookup manager determines whether there are any remaining undiscovered lookup services. If there are undiscovered lookup services, program execution returns to step 900 and a new lookup service is discovered. In the event that all lookup services have been discovered, then the process of populating the cache is complete and program execution ends.
- the client lookup manager utilizes a complex filtering algorithm to extract any subset of network services desired by a client.
- this process begins in step 1000 with a user inputting the ServiceTemplate and ServiceltemFilter arguments described earlier.
- a null reference input to the template argument is treated as the equivalent of inputting a ServiceTemplate constructed with all null arguments (all wildcards). That is, as shown in step 1030, the cache attempts to discover all services contained in a lookup service. Otherwise, the cache attempts to discover services contained in each lookup service that match the inputted criteria (step 1020).
- the process performs the filtering specified by the ServiceltemFilter argument.
- a null input to the filter argument (step 1040) has the opposite effect in that processing terminates and only template-matching will be employed to find the desired services. Otherwise, additional filtering in accordance with the inputted criteria will be employed (step 1050) and the cache will be populated accordingly.
- the client lookup manager handles all activities related to the cache including accessing, updating and deleting the cache. For example, as shown in FIG. 11 , when the client desires access to a service reference, it transmits a request, via a local event to the client lookup manager (step 1100). In step 1110, the client lookup manager searches the cache to determine whether an instance of the requested service is stored in the cache. If the service is found (step 1120), the client lookup manager returns an instance of the requested service in step 1130 and the process ends. If, the service is not found, the client lookup manager returns a null reference in step 1140, and the process terminates. Depending on the specific implementation of the client lookup manager, the process can either re-institute a new search, wait for a new query request from the client, or re-query the associated lookup services.
- this form of lookup takes as input an integer argument (MaxMatches) that represents the maximum number of matches that should be returned.
- MaxMatches integer arguments that represents the maximum number of matches that should be returned.
- WAIT integer argument
- This method also takes an integer argument (WAIT) that indicates the maximum amount of time the process is to wait before returning the identified service references. This argument prevents the client lookup manager from attempting to discover a requested number of MaxMatches for an infinite period of time.
- step 1210 the method accesses a lookup service.
- step 1220 the method retrieves a service reference from the lookup service and in step 1230, determines whether the retrieved service reference is a qualifying service. If a qualifying service is found, the process proceeds to step 1240 and an array of Serviceltem objects is recorded. Otherwise, the process proceeds to stepl250. After an array of Serviceltem objects is recorded in step 1240, the process then compares the number of identified matches with the MaxMatches value previously input (step 1260).
- the "wait" feature is quite useful to entities that cannot proceed until such a service of interest is found.
- entities wishing to employ this feature must input a positive value to the WAIT argument which represents the number of milliseconds to wait for the desired service or services to be discovered. If a non-positive value is input to this argument, then this method will not wait. It will simply query all available lookup services once, and return the array of identified Serviceltem objects. If WAIT has been invoked and the elapsed time exceeds the WAIT duration, the process continues to step 1270, returns the array of Serviceltem objects found thus far and then the process terminates.
- step 1291 the process continues to step 1291 and the client lookup manager registers with the event mechanism of the discovered lookup services.
- the event mechanism requests the lookup services notify the client lookup manager when one of the lookup service's associated networks services changes.
- the client lookup manager determines whether the new service is a service of interest in step 1292. If the service is of interest, it is recorded in the Serviceltem array (step 1293). Otherwise, execution flows to step 1296 where the process determines whether the elapsed time is less than or equal to the WAIT duration. If it is, the client lookup manager waits to be notified of a new service.
- the client lookup manager returns the array of Serviceltem objects found thus far in step 1295.
- the client lookup manager determines whether the number of ServiceMatches is less than MaxMatches. If it is, execution flows to step 1296 where the process determines whether the elapsed time is less than or equal to the WAIT duration. If the number of ServiceMatches is equal to MaxMatches, then the desired number of services has been found and process flows to step 1295 where the identified array is returned. It should be obvious to those skilled in the art that instead of an array of objects, this process could return an instance of an object without departing from the scope of this process. It should also be obvious to those skilled in the art that instead of returning when the total number of references equals the maxMatches object, this method could instead return once a minimum number of references (minMatches) have been found.
- FIG. 13 shows the steps performed by the client lookup manager when either the cache or the client has requested event notification.
- the lookup service observes a state change in a registered service.
- the lookup service determines, in step 1320, whether the event satisfies matching criteria specified by one of its associated clients. If it does, the lookup service transmits the event notification to the requesting client (step 1330) via a remote event.
- the cache determines whether the reported event necessitates a cache update. More specifically, since the cache may receive multiple events corresponding to the same service, it must first determine whether it has previously been notified of this particular event. For example, a particular service may be registered with more than one lookup service or multiple configurations of the same service can be registered with a lookup service. When a lookup service reports an event to a client, the lookup service has no way of knowing whether the event has previously been reported to the client via another lookup service. If the cache has not previously been notified of this event, the cache is updated in step 1360.
- the process ends (note: if the cache has been previously notified, then the client has also previously been notified).
- the cache has been updated, it next determines whether the client is required to be notified as well (step 1370). If the client requested notification, a notification message is sent via local event to the client in step 1380 and the process terminates.
- This "many-to-one" relationship between the events received by the cache 815 and the events sent by the cache hides from the client 812, the lookup services with which the cache 815 interacts. For many entities that use the cache's event mechanism to interact with the cache's discovered services, knowledge of the number of distinct service references, as well as identification of the lookup services with which those references are registered, is of no interest. Such entities typically are interested only in acquiring a reference — not all references to the services it needs to do its job. For entities which are interested in this additional information, the cache 815 provides methods separate from the event mechanism for obtaining that information.
- the Conference Room Example Described below is an example use of the lookup service 212 with respect to a conference room 500 as depicted in Fig. 5.
- the conference room 500 contains a printer 502, a fax machine 504, a computer 506, a projection screen 508, and a storage device 510, all interconnected by a network 512.
- the computer 506 contains a lookup service 518 that defines all services made available by the conference room Djinn.
- the user enters the conference room 500 with laptop 514. Such a situation occurs when a user with a laptop enters the conference room 500 for a meeting. If the user wishes to make use of the services provided by various devices in the conference room 500, the user must join the Djinn of the conference room.
- the user connects the laptop to the network 512 and runs a program, client 516, to perform the boot and join (or discovery) process, as described above.
- client 516 e.g., a browser
- the client 516 downloads an applet from the lookup service 518 that displays a screen 600, as shown in Fig. 6.
- Fig. 6 depicts screen 600 displaying the available services of the lookup service 518 represented as various icons, including a printer 602, a fax 604, a file system 606, and a projection screen 608.
- the screen 600 also displays an add service button 610.
- the printer icon 602 is selected, the stub code (i.e., service item) for the printer is downloaded to the client so that the client may make use of the printer.
- selection of the fax icon 604, the file system icon 606, or the projection screen icon 608 downloads the appropriate stub information so that the client can use those services.
- the file system icon 606 represents the file system of the computer 506. The user, however, may want to add a service and thus selects the add service button 610.
- a screen 700 is presented to the user as shown in Fig. 7.
- the screen 700 depicts the available services of the laptop 514 which the user may add to the Djinn.
- the available services on the laptop 514 may include a Java space 702, the laptop file system 704, a database 706, and a dictionary 708. The user may select any of these services, which are then automatically added to the lookup service and made available to other users of the Djinn.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Automation & Control Theory (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multimedia (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Multi Processors (AREA)
Abstract
Description
Claims
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13868099P | 1999-06-14 | 1999-06-14 | |
US138680P | 1999-06-14 | ||
US41790899A | 1999-10-13 | 1999-10-13 | |
US417908 | 1999-10-13 | ||
PCT/US2000/016083 WO2000077619A2 (en) | 1999-06-14 | 2000-06-13 | Dynamic lookup service in a distributed system |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1194837A2 true EP1194837A2 (en) | 2002-04-10 |
Family
ID=26836406
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP00941355A Withdrawn EP1194837A2 (en) | 1999-06-14 | 2000-06-13 | Dynamic lookup service in a distributed system |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP1194837A2 (en) |
AU (1) | AU5606900A (en) |
WO (1) | WO2000077619A2 (en) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7085868B2 (en) * | 2001-09-28 | 2006-08-01 | Intel Corporation | Method to minimize interrupt service and power consumption for wireless connectivity devices |
GB2370732B (en) * | 2001-10-17 | 2003-12-10 | Ericsson Telefon Ab L M | Security in communications networks |
-
2000
- 2000-06-13 WO PCT/US2000/016083 patent/WO2000077619A2/en not_active Application Discontinuation
- 2000-06-13 AU AU56069/00A patent/AU5606900A/en not_active Abandoned
- 2000-06-13 EP EP00941355A patent/EP1194837A2/en not_active Withdrawn
Non-Patent Citations (1)
Title |
---|
See references of WO0077619A3 * |
Also Published As
Publication number | Publication date |
---|---|
WO2000077619A3 (en) | 2001-07-05 |
WO2000077619A2 (en) | 2000-12-21 |
AU5606900A (en) | 2001-01-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8713089B2 (en) | Dynamic lookup service in a distributed system | |
US6604127B2 (en) | Dynamic lookup service in distributed system | |
US20010002473A1 (en) | Dynamic lookup service in a distributed system | |
US6598094B1 (en) | Method and apparatus for determining status of remote objects in a distributed system | |
US6463446B1 (en) | Method and apparatus for transporting behavior in an event-based distributed system | |
EP0501610B1 (en) | Object oriented distributed computing system | |
US6134603A (en) | Method and system for deterministic hashes to identify remote methods | |
US20200092235A1 (en) | Method and Apparatus for Composite User Interface Generation | |
US5475819A (en) | Distributed configuration profile for computing system | |
KR101176757B1 (en) | Service discovery and publication | |
US6629154B1 (en) | Method and system for deterministic hashes to identify remote methods | |
WO2007024438A1 (en) | Data change notifications | |
WO2000077618A2 (en) | Lookup discovery service | |
JP2002505553A (en) | Diversity token based control | |
US6931427B2 (en) | Method and apparatus for discovering data services in a distributed computer system | |
JP2002505474A (en) | Method and system for facilitating access to a lookup service | |
EP1194837A2 (en) | Dynamic lookup service in a distributed system | |
EP1064599B1 (en) | Method and apparatus for determining status of remote objects in a distributed system | |
JP2001282561A (en) | Distributed object managing method, storage medium having its program stored theoron and distributed system | |
KR20010034515A (en) | Method and system for facilitating access to a lookup service |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20020111 |
|
AK | Designated contracting states |
Kind code of ref document: A2 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE |
|
AX | Request for extension of the european patent |
Free format text: AL;LT;LV;MK;RO;SI |
|
RIN1 | Information on inventor provided before grant (corrected) |
Inventor name: WOLLRATH, ANN, M. Inventor name: SCHEIFLER, ROBERT, W. Inventor name: ARNOLD, KENNETH, C., R., C. Inventor name: WALDO, JAMES, H. Inventor name: MURPHY, BRIAN, T. Inventor name: PAN, ZANE |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: SUN MICROSYSTEMS, INC. |
|
RBV | Designated contracting states (corrected) |
Designated state(s): DE FR GB |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20070103 |