3.1 Exact Matching and Its Limitations
One of the most popular applications of Jini is Lookup Service. In the basic lookup operation, the lookup service's primary role is that of Jini's registrar, in which it accepts registrations from services. Each registration is called a service item, and comprises:
The following graph shows how Jini Lookup Service works by presenting the interaction between the client and Jini lookup services.
Basically the client will request services using unicast or multicast discovery protocols. The lookup services must participate in these protocols. The client then supplies a search template that contains the lookup criterion to locate services. The lookup service searches for the service requested by the client, using the match making engine to find the matched items in the store of proxies from services. Below is another diagram describing the interaction between the client and Jini lookup service.
ServiceTemplate allows clients to communicate search criterion, but has many limits. The attributeSetTemplates array has to match the attribute sets of service items exactly. If the template field is a null they do not have to match exactly, because a null can be matched with anything. The following paragraph is from the Jini Lookup Attribute Schema Specification, and gives some insight to what search criteria can be communicated through ServiceTemplate.[8]
No matter how much information it has at its disposal, a client of the lookup service will not always be able to find a single unique match without assistance when it performs a lookup. In many instances we expect that more than one service will match a particular query. According, both the lookup service and the attribute schema are geared toward reducing the number of matches that are returned on a given lookup to a minimum, and not necessarily to just one.
Sending a predicate could need the lookup server to go through some client code. Although the current lookup methods of ServiceRegistrar does not. The main goal of ServiceRegistrar is to provide a set of lookup capabilities to the clients of these lookup services; however, there is always room for improvement upon these searching abilities which can be given by helper services or applied by clients.
Figure cited from [5]
3.2 Service Registrar
Sun provides the Jini source code under the Sun Community Source License(SCSL) and a community has formed around this code. In the license agreement, in short, Sun says that they own anything the community contributes to the code. There has been a case where it was argued that Sun was trying to keep anyone from modifying or handing out the bad versions of the code.
3.3 Low-Resource Client
When the ServiceUI community project first started, in response to a proposal where clients invoked UI factory methods, the following was written by Bob Scheifler of Sun:
Because the JLS allows wide variation in when resolution occurs in a JVM, it seems this style [of placing UI factory methods in the service object] can result in eager download of all of the UI classes, even if none of them are actually ever used. It may be desirable to find a design that can avoid this if possible.[8]
Later it was said that eager downloading was still possible. The following is a response to a proposal where the UI factory methods were moved to attribute sets:
Deserializing the actual factory instance may also cause significant class loading and downloading. Compound this if the service registers with multiple UI entries. And all of this happens even if the client does not use any of the Uis.
You may well respond that this is a general design issue with the lookup service: you can get all of the attributes or none, but you can not selectively choose, and you can not delay unmarshalling of them. I would agree this is an interesting area to mull over. But in the meantime, I think the UI design needs to be targeted at how things work today, and the footprint impact of attributes on clients needs to be considered with some care.[8]
For a certain service, the ServiceUI proposal should offer a way for low-resource clients to find a UI without the client having to download the whole service item. Because Jini has limited memory, some clients may not be able to deserialize the objects in a service item. The ServiceRegistrar does not have many available options for low-resource clients. It is possible that a low-resource client could taper his search by using a single Entry class. Adding two new methods to ServiceRegistrar would be ideal for the low-resource client requirements. This would easily allow resource-poor clients to interact with the lookup service.
3.4 Proposed Methods
To help resource-poor clients there are two methods that can be used which are getServiceIDs() and getEntries().
Here is an example of the get ServiceIDs() method
public ServiceIDMatches getServiceIDs(ServiceTemplate tmpl, int maxMatches) throws java.rmi.RemoteException; By looking at the matching service items the above returns maxMatches ServiceIDs at most from that set and in addition the total number of entries that match. The ServiceIDMatches class is as follows: package net.jini.core.lookup; public class ServiceIDMatches extends java.lang.Object implements java.io.Serializable { public ServiceID[] ids; public int totalMatches; } Here is an example of the getEntries() method: public EntryMatches getEntries(ServiceTemplate tmpl, Entry[] entryTmpl, int maxMatches) throws java.rmi.RemoteException; The above method finds entries that match and out of these entries matches a template which is in the entryTmpl field, and then returns maxMatches entries at most and in addition the total number of entries that are matched. Here is an example of the EntryMatches class: package net.jini.core.lookup; public class EntryMatches extends java.lang.Object implements java.io.Serializable { public Entry[] entries; public int totalMatches; }3.5 Using the Proposed Methods
Resource-poor clients can control how many objects are returned from the lookup service by using the two methods discussed above, getServiceIDs() and getEntries(). These browsers only return information about services that match a template. Lookup() returns a service object, while getServiceTypes(), getEntryClasses, and getFieldValues() all allow clients to simplify their search before calling a service object. A client can find total number of matches and control maximum number of service items returned by using lookup() to return ServiceMatches. The resource-poor client could use this method and state one match, but if they don't receive what they are looking for, they would have to search again and may even get the same result. If the client does receive the same match they should state two matches next time. However, to do this the resource-poor client needs to download the whole service items which may not be possible.