|
Using the Service Discovery Manager
Version 1.00 May 14, 2004 |
|
LookupCache Events
Example 5 demonstrates the event-driven programming model that the
service discovery manager provides. Essentially, this example
attempts to find a transaction manager service and tries to modify
its Name attribute in order to exercise the
ServiceDiscoveryListener object. The
ServiceDiscoveryListener object receives
notifications (events) whenever a service of interest is added to,
changed in, or removed from the managed set.
Please review the code in the file
LookupCacheEvents.java.
A detailed explanation of that code follows.
The code in Section 1 differs from the previous examples in that the service discovery manager is configured for non-default behavior. In this case, a lookup discovery manager is explicitly created to discover lookup services in a non-public group. This was done in order to prevent this example, which modifies service attributes, from inadvertently modifying services that were not specifically set up for this example.
The code in Section 2 differs from the previous examples in that the
service template searches on both type and
attribute information. In this example, the template will match any
transaction manager service that has a Name attribute,
which is the default behavior of the contributed transaction manager
service implementation in the starter kit.
The code in Section 3 differs from the previous examples in that a
ServiceDiscoveryListener object is created in order to
receive local, normalized ServiceDiscoveryEvents from a
lookup cache. That is, the lookup cache will notify the service
discovery listener whenever a service of interest is added to,
modified in, or removed from the cache.
Note that service discovery listener management is performed through
the addListener and removeListener methods
of the lookup cache.
The code in Section 4 then waits for at least one available service reference via a blocking lookup call.
The code in Section 5 uses the service reference, if one is found, in
order to exercise the event mechanism. First, the service discovery
listener gets a service added event whenever a matching service
reference is discovered. One such event should occur before entering
this section of code. Second, the example code obtains the service's
JoinAdmin object and uses it to change the service's
Name attribute. This should result in a service-changed
event being sent to the service discovery listener (assuming that the
Name attribute has actually changed). Finally, the code
attempts to delete the service's Name attribute, which
should in turn generate a service-removed event because the service
no longer matches the original service template.
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.
The code in Section 7 introduces a service discovery listener implementation class that simply prints out a message whenever an event occurs that indicates that a service was added, changed, or removed.
The code in Sections 8-10 contains convenience methods for obtaining and manipulating a service's attributes.
The example can be run on a UNIX platform by doing the following:
$ cd bin12 (or bin20 for Jini 2.0 environments) $ run_lookup_cache_events.sh
The example can be run on a Windows platform by doing the following:
$ cd bat12 (or bat20 for Jini 2.0 environments) $ run_lookup_cache_events.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_events.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/LookupCacheEvents.jar Creating ServiceDiscoveryManager ... Creating ServiceTemplate for a net.jini.core.transaction.server.TransactionManager instance Creating LookupCache Attempting service lookup for a net.jini.core.transaction.server.TransactionManager instance ServiceAdded called for serviceID: c7d26416-6ba5-4011-b3f1-d826ede368cd Obtained service reference with serviceID: c7d26416-6ba5-4011-b3f1-d826ede368cd Changing service's name attribute ... serviceChanged called for serviceID: c7d26416-6ba5-4011-b3f1-d826ede368cd Deleting service's name attribute ... serviceRemoved called for serviceID: c7d26416-6ba5-4011-b3f1-d826ede368cd
The output above shows that a service-added event is received before
the program enters into Section 5 code (the Section 5 output begins
with "Obtained service reference with serviceID:"). The
example code then changes the service's Name attribute
and a service-changed event occurs as expected. Next, the example
code deletes the service's Name attribute and a
service-removed event is received. [The transaction manager service
will no longer have a Name attribute after this point,
so running Example 5 again will no longer find this service.]
Note that the same output should occur even if the transaction manager service is registered with multiple lookup services (see Section SD.4.1.2 of the JiniTM Service Discovery Utilities Specification for an example case where it might not produce the same output). The service discovery manager handles duplicate events and filters them out so that the service discovery listener only receives unique events representing unique state changes in the service discovery manager's cache.
SDM examples main page