|
Using the Service Discovery Manager
Version 1.00 May 14, 2004 |
|
LookupCache Filters
Example 6 demonstrates the filtering capabilities that the service
discovery manager provides by attempting to find an
UnreliableService instance within specific
location attribute ranges.
Please review the code in the file
LookupCacheFilters.java.
A detailed explanation of that code follows.
The code in Sections 1-2 is basically the same as the last example
except that a default service discovery manager that searches in the
public group is created and the
ServiceTemplate created in the Section 2 code matches
instances of UnreliableService.
The code in Section 3 differs from the previous examples in that it
creates a BuildingFilter, which the service discovery
manager uses to screen discovered service instances that match the
template. In this case, BuildingFilter (shown in Section
7) returns true for service instances that have a
building attribute value that is greater than or equal
to two. Otherwise it returns false. Service references
that satisfy this filter are placed in the cache's managed set.
Note that this client-side filtering enables applications to introduce customized matching semantics in addition to the entry-matching semantics already provided by the lookup service. In this example, the filter is providing simple range-matching semantics, which are not supported by the lookup service. In general, though, the filter's matching semantics can be made arbitrarily complex.
The code in Section 4 then waits for at least one available service reference via a blocking lookup call. This blocking lookup request reuses the cache's filter so that the application waits until either a service that matches the cache's criteria is discovered or the time-out expires.
The code in Section 5 then attempts to select a cached service
reference that satisfies a second level of filtering. A
FloorFilter (shown in Section 8) is created to accept
service instances that have a floor attribute value
greater than or equal to one. This filter is then passed into the
lookup method, which in turn is used by the service
discovery manager to filter the cached set of service references.
Therefore, any service matches returned by the lookup
method satisfy both filter conditions (building >= 2 and floor
>= 1).
The code in Section 6, just like all of the previous examples, calls
the service discovery manager's terminate method to
release any obtained resources.
This example requires the "unreliable service". To start this service on a UNIX platform, do the following:
$ cd bin12 (or bin20 for Jini 2.0 environments) $ start_unreliable_service.sh
The service may be started on a Windows platform by doing the following:
$ cd bat12 (or bat20 for Jini 2.0 environments) $ start_unreliable_service.bat
The example can be run on a UNIX platform by doing the following:
$ run_lookup_cache_filters.sh
The example can be run on a Windows platform by doing the following:
$ run_lookup_cache_filters.bat
Assuming there is at least one publicly available lookup service and one publicly available transaction manager service, you should see output similar to the following:
$ run_lookup_cache_filters.sh + hostname CODEBASEHOST=pion + . JINI_HOME.sh EXJINIHOME=/files/jini1_2_1 + java -Djava.security.policy=../policy/policy.all -Djava.rmi.server.codebase=http://pion:8081/sdm-dl.jar -jar ../lib12/LookupCacheFilters.jar Creating ServiceDiscoveryManager ... Creating ServiceTemplate for a com.sun.jini.example.sdm.ex1.UnreliableService instance Creating LookupCache Attempting service lookup for a com.sun.jini.example.sdm.ex1.UnreliableService instance Obtained at least one service reference for building #2 (or greater). Attempting to find service on floor #1 (or greater) ServiceID b16a4cdf-f4bd-4be5-88c8-af35d263c6db is in: net.jini.lookup.entry.Location(floor=2,room=2,building=2)SDM examples main page