With the clamshell they fetch files from offices & email questions. Using the cell .... A client only needs to know the interface to the proxy code in order to access it.
Enhancing Jini’s Lookup Service using XML-based Service Templates Morten Baun Møller, Bo Nørregaard Jørgensen The Maersk Mc-Kinney Moller Institute for Production Technology, University of Southern Denmark, Odense Campus, DK-5230 Odense M, Denmark. {baun,bnj}@mip.sdu.dk
Abstract. In this paper we present an extension to Jini’s lookup service. The existing lookup service has certain limitations when it comes to searching for specific services. We introduce more advanced service descriptors and a lookup service that enables flexible searching for specific services. Our proposal makes it easy to incorporate non-functional requirements, such as quality-of-service. This means that services can publish themselves with a descriptor describing their guarantees for the service they deliver. Clients will then be able to fill out a descriptor containing requirements (expectations). When the client asks a lookup service for matches based on the descriptor, only services fulfilling the requirements will be returned. The advanced searching in Jini is done client-side, while we have moved it to the lookup services. This way even small devices with limited memory and computation power will be able to perform advanced searches and easier be able to find a match. The implementation utilize XML as storage format.
1. Introduction In a world where computer networks are very common and indispensable, there is a demand for easily configurable, distributed systems. Systems that do not require drivers. Systems to which you easily can add new services (i.e. devices or software) to expand the network. Systems where services can easily search for other services in order to access and use their functionality. At the same time, we would like to be able to specify aspects like quality-of-service for services. Especially, we would like to specify requirements and deliveries (guarantees) for services. This way clients with certain requirements will be able to search for and find the services that deliver the wanted features. Our intention is to build on top of Jini by extending the existing lookup service and by introducing new conventions and data structures. In this paper we are going to take a look at Jini and the extensions we have made to reach our goal, in particular. But first, let us take a look at the following excerpt from [7], which is a scenario describing the vision of the Jini architecture from Sun Microsystems. ”Picture this: Three strangers from three companies--on the road to jointly bid a job. Among them they have a laptop, a project disk drive with data & applications, a PDA, a cell phone, and a clamshell pager--and their presentation is not ready. Their hotel suite has a small network: scattered net jacks, a couple of infrared & short-range RF transceivers, and though they never worked together before, they have snapped into an impromptu working community. The suite has an Internet gateway & low-resolution printer. The TV, the VCR, and the set-top box are connected to the same network. As they work they use all the services in the room, including those on each other’s devices. Plug in the disk & PDA, turn on the laptop & TV--total setup time: 2 minutes. While one of them edits the presentation, the others watch it unfold, mirrored on the TV. From time to time one of them takes the laptop to another hotel room to concentrate on a
section while the others keep working, running simulations from the project disk on the gateway & viewing results on the TV. Sometimes one of them prints a slide or graph to proof. With the clamshell they fetch files from offices & email questions. Using the cell phone as a remote, they order room service through the TV & check their flights. When they’re done, they need a high-resolution set of overheads. From the pager they reserve the hotel’s high-res color printer for 15 minutes--it’s in a small room down the hall. Using the suite key programmed by the reservation service to open the room, one of them goes into the printer room, loads foils bought from online room service, and phones into the suite's network to start printing.”
Jini is the key for realizing this vision. Based on top of Java and Java RMI technology, Jini is capable of connecting (federating) groups of devices and software components anywhere and making their services available to each other. In Jini, the most important concept is that of a service. A service may be a computation, storage, a communication channel to another user, a software filter, a hardware device, or another user. In the scenario above, lots of services are recognized, e.g. a printer, a reservation service, a project disk drive, services for controlling the data flow for cell phones and pagers, and many more. Groups of Jini services join together in cooperating sets. In Jini, these groups of services are called communities; all services in a community are aware of each other and able to use each other. Lookup services ensure this. A typical community is the size of a workgroup (10 to 100 people), but communities can be hierarchical connected, so that the entire network of communities can be arbitrarily large. Services are essential in Jini, but in order to make it possible for Jini-aware clients (either services or applications) to search for and use other services, one or more lookup services should be up running on the network. A lookup service serves as a repository of services. Each registered service is stored with a set of attributes describing the service. By using the lookup service, clients can search for services that implement a certain interface or have certain attribute values stored with them. The interfaces cover functional aspects, while the attributes mostly cover non-functional aspects. For a printer service, attributes like resolution and chromaticity could be useful to base a search on. Unfortunately, Jini’s attribute search is quite limited, and only searching for an exact match is possible. A client has no way of specifying that it would like to get a list of all printer services supporting a resolution larger than or equal to 600 dpi. It will have to download all available printer services and do the search itself and pick out a printer that matches the requirements. This might not be a big problem for computers with sufficient memory and processing power. But imagine if you have a digital camera, from which you would like to select a network printer to print out the picture you just took. The camera would need extra memory to make sure that enough printer services could be downloaded for conducting the search. Furthermore, the developers of the camera software would have to write some extra code to implement the search routine. The extension we propose deals with the problems stated above by introducing more advanced search templates. At the same time, these templates are structured in a way that supports various non-functional requirements, e.g. image resolution and non-functional aspects like security, reliability, and quality-of-service. It is possible to define a descriptor with information for an object and even for each public method in an object, if this is needed. When objects publish their services at a lookup service they can do so together with a deliveries descriptors, while objects searching for services state their requirements in a requirements descriptor. This way, the lookup service can compare the two types of descriptors and only return the services that fulfil the requirements. The same descriptor data structure is used for both requirements and deliveries. To help service developers, we have created a set of tools for creating and handling the descriptors we introduce in our extension.
Throughout this paper we will be looking at a simple – but still very illustrative – example to present our approach. The example incorporates registering and finding very specific printers. This paper is organized as follows. Section 2 gives an overview of the Jini architecture and the Jini Print Service API. Section 3 describes our extension to Jini - the concepts and the implementation. Again we will take a look at the Jini Print Service API and suggest an alternative way of expressing attributes based on our extensions. In section 4 we will take a look at the tools we have implemented to support these concepts. Finally, section 5 concludes.
2. Overview of Jini In this section we will take a closer look at some of the mechanisms in Jini. As mentioned in section 1, services and lookup services are essential in Jini. Services that wish to make themselves available to other Jini-aware entities (i.e. applications or services) should register with one or more lookup services via the Jini join protocol. But first, references to lookup services should be obtained via the discovery protocols. 2.1. The Discovery Protocols Jini has three discovery protocols suited for different ways of getting in touch with lookup services. • • •
The Multicast Request Protocol is used when a client for the first time wants to find the “nearby” lookup services. The Multicast Announcement Protocol is used by lookup services to announce their presence. The Unicast Discovery Protocol is used when a client already knows the name of the particular lookup service it wishes to talk to.
As a result of the discovery process, the client doing the discovery gets one or more references to the desired lookup services. These references can then be used to access the lookup services. This is relevant, when a service wishes to advertise its facilities or when a client wishes to do lookup to find services with certain facilities. The references being returned are references to objects implementing the lookup interface net.jini.core.lookup.ServiceRegistrar, which has methods for registering and looking up services. 2.2. Lookup After discovering one or more lookup services, it is time to access them. In order to do lookup, a lookup service implementation must be running on the machine, so that services can register themselves, and clients can look up registered services. Jini is released with a lookup service implementation called reggie. As we will take a look at later on, we have extended this implementation to gain the functionality needed for our extension. 2.3. Services joining a lookup service When a service first joins a lookup service, it receives a unique service ID. As long as the service exists, it should hold on to this ID. This way clients can use the service ID as a search criterion to find the same service again. As mentioned earlier, a lookup service serves as a repository of services, which can be accessed by applications or other services. The lookup service stores instances of the net.jini.core.lookup.ServiceItem class (cf. Figure 1).
public class ServiceItem implements Serializable { public ServiceItem(ServiceID serviceID, Object service, Entry[] attributeSets) {...} public ServiceID serviceID; public Object service; public Entry[] attributeSets; }
Figure 1. The ServiceItem class The constructor assigns each parameter to the corresponding field, while the serviceID field contains the service’s unique ServiceID. The service field contains a serializable Java object called the service proxy. This service proxy can contain anything the service wants to publish to clients. When a client finds a service item it wants to use, it copies the proxy object to its Java Virtual Machine, and calls can now be made on the proxy object to use the service, cf. Figure 2. This way, clients can use services and devices without installing any explicit drivers or software. Furthermore, the clients do not have to understand how the proxy is implemented and how it connects to the device or process being accessed via that particular proxy. This is one of the big advantages of Jini. A client only needs to know the interface to the proxy code in order to access it. The published proxy objects are specifically designed to the device (or software) they give access to. A printer publishes a proxy that controls that particular printer. A digital camera publishes a proxy that understands how to communicate with that camera. Client
Lookup service asking for a service
Client
Lookup service returning a service proxy
Service proxy
Service proxy
Client
Service communicating with service via proxy
Service proxy
Figure 2. How a client gets a service proxy and communicates with the service. Note, that the lookup service actually returns a ServiceItem object containing the service proxy, a service ID, and service attributes The attributeSets field in a ServiceItem object contains a list of attribute sets. These attribute sets provide extra information about the service, and a client can search for services with certain attribute values.
Attributes Attributes are Java objects implementing the net.jini.core.entry.Entry interface. This interface is a subinterface of java.io.Serializable, but does not introduce any new methods. It is simply a marker interface for Jini attribute entries attached to service proxies. Only certain data fields in a Jini entry can be used for searching. When serializing an entry for storage “in lookup services”, Jini ignores all methods of the object, all primitive data fields, and all static, transient, non-public, or final data fields. Each useable data field is serialized separately and independently from one another. This means that two references to the same object results in two serialized copies of that object. This is different from normal serialization, and is introduced in Jini to speed up the comparison when searching for services with certain characteristics. The comparison is based on bit stream matching, i.e. the serialized bit stream of each entry in a ServiceItem is compared directly to the bit stream in the ServiceTemplate holding the template on which the search is based. Java beans and applets can also be attached in an attribute set. The clients using a service including an applet of course have to know where to find it. Registering a service Registering a service with a lookup service is easily done by using the ServiceRegistrar method register(). This method takes two arguments, a ServiceItem object that holds the service and the attributes being published and a long setting the lease duration. Jini uses leasing to avoid problems with lookup services containing useless references to services that are not available anymore, and services that hang or have crashed, e.g. due to programming bugs. When a service registers itself with a lookup service, it specifies a lease duration, which can be negotiated. If the lease is not renewed before it expires, the service will be removed from the lookup service. Crashed services and services with programming bugs will not be able to renew their leases and will eventually be removed from the lookup service. This ensures that only stable code will stay in a Jini community. A system administrator will never have to spend hours removing inactive code and cleaning up the system. Searching for specific services Searching for specific services is done by putting information in one or more of the fields in a net.jini.core.lookup.ServiceTemplate object and then calling one of the two lookup() methods in ServiceRegistrar. The first method takes as argument a reference to a ServiceTemplate object and returns one match, or null if none are found. The second method additionally takes an integer specifying the maximum amount of matches one wishes to get back in the returned net.jini.core.lookup. ServiceMatches object. The ServiceTemplate class is shown in Figure 3. public class ServiceTemplate implements Serializable { public ServiceTemplate(ServiceID serviceID, Class[] serviceTypes, Entry[] attributeSetTemplates) {...} public ServiceID serviceID; public Class[] serviceTypes; public Entry[] attributeSetTemplates; }
Figure 3. The ServiceTemplate class The item matching in a lookup service is done according to the following principle. A service item (item) matches a service template (template) if:
• • •
item.serviceID equals template.serviceID (or if template. serviceID is null), and item.service is an instance of every type in template.serviceTypes, and item.attributeSets contains at least one matching entry for each entry template in template.attributeSetTemplates.
As mentioned earlier, ServiceItems matching a certain ServiceTemplate are returned in an instance of the ServiceMatches class (cf. Figure 4). public class ServiceMatches implements Serializable { public ServiceMatches(ServiceItem[] items, int totalMatches) {...} public ServiceItem[] items; public int totalMatches; }
Figure 4. The ServiceMatches class Event notifications In Jini it is possible to get an event from a lookup service, when changes happen in it, e.g. a new service is registered or attributes in existing services change. The method notify() in ServiceRegistrar is used, when one wants to register for an event notification. No drivers, but common interfaces Even though there is no need for drivers in Jini, a client still needs to know at least one of the interfaces that the service implements in order to access the service code. Introducing standardized APIs for common devices like printers, scanners, and digital cameras, provides easy access to those devices. A client downloads the proxy for any printer and will know exactly how to check out what features are supported and how to use them. A standardized printer interface ensures that clients can access any printer regardless the brand and the printer specifications. The interface is always the same. Hence, finding all printer services in a certain community is very easy. A client searches for services that implement the printer interface, possibly combined with a set of attributes, if printers with specific features (e.g. a desired resolution or chromaticity) are wanted. Zero or more matches will be returned in a ServiceMatches object. The same applies to scanner services. If they implement a standardized scanner interface, clients can easily search for and use all available scanners knowing nothing but the interface. Currently, a Jini Print Service API [6] is under development. 2.4. The Jini Print Service API The Jini Printing Working Group has released an API for controlling printers [6]. This API defines various classes for a print service, for print jobs, and defining all the attributes that can be used when searching for printers with certain characteristics. The attributes are located in the package javax.print.attribute.standard. Attributes such as Chromaticity, ColorSupported, CopiesSupported, PrinterResolution and many more especially have our interest. Our attribute structure should be able to handle these in a more flexible way, when a user wants to find a printer with one or more specified features. As mentioned earlier, in Jini it is not possible to search for printers having a resolution larger than or equal to e.g. 600 dpi. The Jini Printing Working Group has introduced an attribute called MinimumPrinterResolution, but because of Jini’s simple comparison, the client will have to download all printers and compare its MinimumPrinterResolution to the supported printer resolutions in order to get one that matches.
3. Extending Jini In this section we present our proposal for a Jini extension that increases the functionality in the lookup service implementation. The extension should fulfil the following four requirements. •
• • •
We would like to incorporate descriptors for some functional and especially nonfunctional aspects in Jini. It should be possible to use descriptors for a whole object and/or for any public method in an object. This way one can control requirements and deliveries down to each method in an object. Security, reliability, and real-time are examples of non-functional requirements used in industrial settings. Searching for specific services should be easier and more flexible. For instance, it should not be necessary to download all services implementing a printer interface, just to find a printer that supports resolutions higher than 600 dpi. We would like to support client applications running on devices with limited memory capacity and computation power. We still want to have all of Jini’s functionality and to support services with Jini’s attribute templates as well as services with our templates. This can be accomplished by extending Jini’s existing classes and conventions. We want to simplify application development without changing the basic philosophy of Jini.
3.1. The reason for extending Jini Basically, in Jini searching for services with certain attribute values is too simple for some purposes. And introducing non-functional requirements in Jini, such as quality-ofservice, calls for an extension of the attribute templates and the existing lookup service. Furthermore, we recognize the need to support small devices, so that they can perform advanced searches easier. 3.2. Non-functional requirements There is a need to incorporate non-functional requirements in distributed systems. A need to add information to the functional level, i.e. to object calls and method calls. Lookup service
ServiceItem Client ask for service that fulfils the requirements descriptor
Deliveries descriptor
Requirements descriptor
Service proxy
...
Figure 5. Client asking a lookup service for services fulfilling the requirements stated in the requirements descriptor. Only services with matching deliveries descriptors are returned
Jini services can register themselves together with a deliveries descriptor at one or more lookup services. The deliveries descriptor contains an attribute structure describing the services delivered. It is possible to describe information for the entire service and/or for each method in it. Clients can now hand over a requirements descriptor to a lookup service and ask to get the services fulfilling the requirements (the client’s expectations), cf. Figure 5. 3.3. The descriptor We introduce the descriptor, a data structure based on the hierarchical structure presented in [1]. We have six classes: Descriptor, AspectContainer, Aspect, Feature, Quality, and Measure. The Descriptor, which in a serialized form is our descriptor, holds a hashtable containing AspectContainer objects for each method in the class implementing the Jini service. As hash key we use a concatenation of the class name, the name of the method, and its parameter types. However, if an aspect is meant to cover the entire object, only the class name is used. This way one can decide what methods to put requirements or deliveries on, or if a setting for the entire object should be used. An AspectContainer object holds a collection of Aspect objects for one method. The remaining objects are connected as shown in Figure 6. Aspect
1..*
Feature
1..*
Quality
0..*
Measure
Figure 6. The structure for aspects located in descriptors So a descriptor for an object contains Aspect collections. One collection can cover either the entire object or one public method in it. Therefore, it is possible to assign different aspects to different methods. This is really useful, if e.g. some methods require security aspects, while others require real-time aspects. Printer (Aspect) Chromaticity (Feature) Monochrome (Quality) Color (Quality) PrinterResolution (Feature) MinimumPrinterResolutionDPI (Quality) CrossFeedResolution (Measure) integer, lessThanOrEqualTo FeedResolution (Measure) integer, lessThanOrEqualTo MaximumPrinterResolutionDPI (Quality) CrossFeedResolution (Measure) integer, largerThanOrEqualTo FeedResolution (Measure) integer, largerThanOrEqualTo ...
Figure 7. An example of how our data structure can be used to represent features from the Jini Print Service API To demonstrate the way a descriptor can be put together, let us give an example for a printer service containing a few features, cf. Figure 7. We construct a descriptor with one printer aspect. An Aspect object can hold one or more Feature objects. In the example, we have two features, Chromaticity and PrinterResolution. A Feature object can hold one or more Quality objects. For Chromaticity in the example, we have two qualities, Monochrome and Color. A Quality object can hold zero or more Measure objects. The Measure object is the last object in the hierarchy and is holding a value object and an equality indicator. The value object implements the interface java.lang.
Comparable, which means that it can hold any object that implements this interface, e.g. Java’s Integer, Double, or String. The interface defines a method compareTo() which is used in the comparison code in Measure. The equality indicator has five valid values, LESS_THAN, LARGER_THAN, EQUAL_TO, LESS_THAN_OR_EQUAL_TO, and LARGER_THAN_OR_EQUAL_TO. This indicator is used to set whether the value object should be e.g. less than, equal to, or larger than the object being compared to it. As one can see in Figure 7, FeedResolution has been set to LESS_THAN_OR_EQUAL_TO, indicating that it will only match descriptors with Printer aspects, where the “PrinterResolution\MinimumPrinterReso lutionDPI\FeedResolution” equality is set to LARGER_THAN_OR_EQUAL_TO. If we have a printer that delivers a minimum feed resolution on 300 dpi, other service descriptors will only match this particular printer, if their “MinimumPrinterResolutionDPI\FeedResolution” is at least 300, and the equality is set to LARGER_THAN_OR_EQUAL_TO. This is more flexible than Jini’s search, where only exact matches are possible. In other words, if a client would like to find a printer with a 600 dpi minimum resolution, it would have to download all printer services and check them one by one to find a match. In Figure 9 you can see the entire hierarchy for chromaticity and resolution. We have made a descriptor based on the Jini Print Service API. This descriptor covers the features in the API and allows the client to make more flexible searches to find a printer with characteristics like chromaticity, supported colours, compression, copies supported, binding, cover, media, multiple document handling, orientation, printer resolution, and print quality. 3.4. The extension In order to get the wanted functionality, we have added our own code to the reggie source code. Furthermore, we have expanded the service item conventions. Let us briefly summarize some of the lookup concepts. As we described earlier, services, that wish to make themselves available in a Jini community, join lookup services. Finding (discovering) and joining a lookup service can be done via the helper class com.sun.jini.lookup.JoinManager. In the lookup service, the service information is stored in ServiceItems. A ServiceItem contains a service object, the service’s service ID, and a set of attributes. An application or service can search for services by filling out a ServiceTemplate and ask a lookup service to find the ServiceItems that match the template. Searching can be based on one or more of the fields in the ServiceItem. The set of attributes in a ServiceItem is a list of objects, each implementing the Entry marker interface. We have extended the reggie lookup service, so that an application or a service with certain requirements easily can search for services that deliver the wanted quality-of-service for certain features. So, what is the easiest way to get our aspect container integrated with Jini? The attribute integration in Jini is very open to extension. Remember, objects in attribute sets should implement the Entry interface and make sure that all their object references are declared public. An attribute object can hold any object, including a Descriptor object. We have built descriptor comparison code into our lookup service, but at the same time Jini’s original attribute comparison is supported. In order to tell the new lookup service that a service’s attribute contains an Descriptor, we have copied Jini’s approach and introduced a marker interface called DEntry, which extends the Entry marker interface. This way, the lookup service does not have to check every object in an attribute set to see if it contains a Descriptor. As another convention, one should place the Descriptor first in the attribute, so that searching for it can be done as fast as possible. The DEntry object
should also be the first object in the attribute set in a ServiceTemplate or ServiceItem object. In Figure 8 one can see an attribute example showing the difference between Jini and our extension. Example of an attribute using Jini: class X implements Entry { public SomeType varA = new SomeType(); public SomeOtherType varB = new SomeOtherType(); } Example of an attribute using our extension: class X implements DEntry { public Descriptor deliveries = new Descriptor(...); public SomeType varA = new SomeType(); public SomeOtherType varB = new SomeOtherType(); }
Figure 8. Example of attributes using Jini and our extension So how do we compare Aspect objects and this way test if a set of requirements actually match a set of deliveries? Two Aspect hierarchies can easily be compared by calling the equals() method on one Aspect object and passing another Aspect object as argument. Each of the objects Feature, Quality, and Measure has an equals() method which is called through the hierarchy. 3.5. What have we gained? It is possible to perform advanced searches using the hierarchical structure and to incorporate non-functional requirements, such as quality-of-service. It is possible for even small devices to perform advanced searches. Jini does a fast bit stream comparison of the MarshalledObjects. Our advanced search routine of course is slower, but we claim that our improved functionality makes up for this. Furthermore, it is fairly simple to deal with slow lookup services by upgrading the machines. In Jini, advanched searching is done client-side. The client asks the lookup service to return a number of e.g. printer services, i.e. services implementing a printer interface. The client will now have to search through them all and find the one it needs. This task can be difficult to perform for a small device with limited memory and computation power. The device will only be able to hold a few services to look through and this way risking no match at all. The device may also have to accept that the matching will take time depending on its computation power. By moving the advanced searching to the lookup service, we have ensured that small devices will be able to find a match reasonably fast. We claim that the lookup service with our extension will not be much slower. Furthermore, if you have a machine with a lookup service containing many services and therefore can expect a need for more computation power, you probably already made sure that the machine is big enough for this purpose. It is important to emphasize that we have not changed the basic Jini philosophy. Our extension supports the original Jini functionality and does not conflict with the existing system.
4. Development Environment In this section we will take a brief look at the tools and helper class supporting the creation and editing of templates, service requirements, and service deliveries. All tools are implemented in Java.
4.1. The Descriptor Tool The DescriptorTool program allows the user to create and edit templates as well as descriptors. These can be saved in two different formats: XML and a compact descriptor object format. Our extended lookup service uses the descriptors for storing the advanced attribute structure we introduced earlier. XML is used as intermediate format. The user can save and load templates and descriptors specified in this standardized format. The ability to validate descriptors against template files, makes XML an obvious choice. We use the XML Document Type Definition format (DTD) for our templates, and for descriptors we use plain XML based on the DTD file information. The program has three different modes: Template mode, requirements mode, and deliveries mode. Each mode has its own folder (cf. Figure 9) and works independently of the others.
Figure 9. Example of template for printer aspects. A, F, Q, and M stand for Aspect, Feature, Quality, and Measure respectively
type CDATA #FIXED "integer" equality (largerThan | largerThanOrEqualTo | equalTo | lessThanOrEqualTo | lessThan) "lessThanOrEqualTo" >
Figure 10. The XML DTD for the descriptor in Figure 9 In the template mode, the user defines the template hierarchy of aspects, features, qualities, and measures. An example is shown in the left-hand tree list in Figure 9. When clicking on a node in the left-hand tree, the right-hand area shows the properties of that node, and the user can edit the fields that are editable. In the example in Figure 9, one of the FeedResolution nodes has been selected and its properties are now visible in the righthand area. The template hierarchy can be saved to an XML DTD file. In Figure 10 is shown an example of DTD code for the hierarchy in Figure 9. In the requirements and deliveries mode, saved XML DTD files can be loaded and used to build new descriptors. Existing descriptors can be loaded and edited, as well. 4.2. The ValueSetter helper class The ValueSetter class gives easy access to the different nodes in the descriptor tree. Instead of manually searching through aspect, feature, and quality nodes to access or change a value in a measure node, the ValueSetter allows the user to go directly to the desired measure node. Of course, the ValueSetter class is only needed, if a descriptor has to be changed dynamically. This depends on the application, but many applications and devices might want to change one or more settings dynamically in a descriptor. Instead of creating a new descriptor, an existing one can be edited using the ValueSetter class. Imagine a client searching for a 1200 dpi printer but without luck. He can now change the descriptor handed to the lookup service to reduce the minimum resolution requirement to 600 dpi. If he had started searching for printers with minimum 600 dpi resolution, he might have missed a 1200 dpi printer, if one was available. Instead, he should do the searching and then reduce his requirements, if no match is available. This also works the other way around. If a printer runs out of A3 paper, it can update its descriptor, so that clients wanting to print out A3 copies do not find the printer till it has been loaded with A3 paper again. Of course, the printer descriptor should still have a SupportedPaperFormats feature, so that clients can see that this printer may be used to print out A3 copies in the future. When ValueSetter is used, clients relying on a descriptor being changed are notified, if they have registered for event notification. This works the same way as for ordinary Jini notification.
5. Conclusion In this paper we presented an extension to Jini that makes searching for services more flexible. By introducing a hierarchical data structure we also support non-functional descriptors for use in service templates and search templates in lookup services. A descriptor can describe deliveries or requirements for a Jini service. This means that a service registering itself with a lookup service can be stored together with a deliveries descriptor. Services searching for other services have certain requirements stated in a requirements descriptor. The lookup service will now make sure that only services fulfilling the specified requirements will be returned. We extended the existing Jini lookup service to get the functionality we wanted. We also extended the conventions for attribute sets. In our implementation it was important to keep Jini’s existing functionality, so that ordinary services still can access the lookup service without any problems. Our comparison routine is slower than Jini’s bit stream comparison, but we claim that our improved search functionality makes up for this. A functionality that also supports
small devices with limited memory capacity and computation power. In Jini, advanched searching is done client-side. A client asks a lookup service to return a number of e.g. printer services. The client will then have to search through them itself to find the one it needs. Small devices might not have sufficient memory to hold enough printer services to find a match. It might also take too much time to perform the comparison. We have solved these problems by moving the comparison into the lookup service. Of course, this makes the lookup service a bit slower. If it should happen to get too slow, this can be solved by upgrading the machine on which it is located. We have implemented tools that will help service developers create and handle the descriptors we introduced. These tools use XML as storage format. It is important to emphasize that we have not changed the basic Jini philosophy. Our extension supports the original Jini functionality and does not conflict with the existing system.
References [1] B. N. Jørgensen, E. Truyen, F. Matthijs, W. Joosen, “Customization of Object Request Brokers by Application Specific Policies”, In Proceedings of Middleware 2000, New York, USA, LNCS Springer, vol. 1795, pp. 144-164, April 2000. [2] W. Keith Edwards, “Core Jini”, The Sun Microsystems Press series, 1999. [3] Sun Microsystems, “Jini Architecture Specification”, version 1.0.1, November 1999. [4] Sun Microsystems, “Jini Discovery and Join Specification”, version 1.0.1, November 1999. [5] Sun Microsystems, “Jini Lookup Service Specification”, version 1.0.1, November 1999. [6] The Jini Printing Working Group, “Jini Print Service API”, draft standard version 1.0, 23 May 2000 (available at http://developer.jini.org/exchange/users/jpgwg/) [7] Sun Microsystems, “Jini Technology Executive Overview”, revision 1.0, January 1999 (available at http://www.sun.com/jini/overview/index.html)
