Using the Service Discovery Manager
Version 1.00 – May 14, 2004
Example logo
SDM examples main page
prev | next

Example 5: Using 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.

Dissecting the Example

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.

Running the Example

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
prev | next
Copyright 2004 Sun Microsystems, Inc. All Rights Reserved.