Building and Running the Service Discovery Manager Examples
Version 1.00 – May 14, 2004
Example logo
SDM examples main page
next

Support for Both Platforms

These Service Discovery Manager (SDM) examples are structured such that they may be run with either v1.2.1 or v2.0 of the Jini(TM) Network Technology Starter Kit (starter kit). There are no differences in the source code between the two examples. Only the build process and steps to run the examples differ.

There are two parallel directories, ex1 and ex2, that contain the source code for these examples. The directory ex1 holds the source that is to be built with the older, v1.2.1, version of the starter kit. The directory ex2 holds the source that is to be built with the newer, v2.0, version of the starter kit. The source code is identical except for a difference in package names. However, the Ant build scripts (build.xml) are different. Comparing these build scripts is an excellent way to understand the differences in build strategies for the two starter kit releases.

Building the code in the ex1 directory will produce JAR files in the lib12 directory; building the code in the ex2 directory will produce JAR files in the lib20 directory. The script files used to run these examples are described in the next section.

Please examine each build.xml file and update the property jini.home to point to your starter kit installation directory.

Running the Examples

The Service Discovery Manager helps Jini technology-based programs find other services. In order for these examples to work, there will need to be services for these examples to find! There are two Jini services that will be found with these examples: a Transaction Manager (specifically, Mahalo, the implementation of a transaction manager contributed by the Jini development team), and an "unreliable service" bundled with these examples. The following sections describe how to run these examples from either UNIX or Microsoft Windows platform with either starter kit version.

Running the Examples with starter kit v1.2.1

There are four directories filled with scripts and batch files to be used with these examples. They are:

This section will describe how to start the appropriate services so these SDM examples will work with an environment based on the v1.2.1 starter kit. The discussion below will use the UNIX commands. The steps for successfully running under Windows are similar except they will use batch files from the bat12 directory. Also, Windows users will need to use .bat file extension on Windows batch files instead of the .sh extension found on the UNIX script files.

Here are the steps for starting the appropriate services before running the examples. All of these steps assume you are in the bin12 directory (or the bat12 directory if you are running under Microsoft Windows). It is best to run each of these commands in separate windows or shells.

  1. Update the JINI_HOME.sh files
    Some scripts in this directory are used to start services bundled with the starter kit. The location of the starter kit must be specified so these scripts will work. The JINI_HOME.sh script specifies the location of the starter kit. This location is utilized by the other scripts as necessary. Update this script to point to the top of the starter kit tree.
  2. Start RMID
    Clients use the SDM to find services. The first service the SDM must find is a lookup service from which all other services might be sought. Reggie is an implementation of a lookup service that was contributed by the Jini development team. Reggie is an activatable service in the v1.2.1 version of the starter kit so we will need to start an RMID activation daemon. As it turns out, one of the other services we need to start, Mahalo, is also activatable. RMID will manage that service as well. To start RMID, run this:
    $ start_rmid.sh
  3. Start a code server for the starter kit-based services codebase
    Services such as Reggie and Mahalo have proxies and will require clients of those services to fetch the code for those proxies from their codebase. A code server should be started to service the lib directory of the starter kit where the various -dl.jar files for these services are located. A script is provided to do this. To start this code server, run this:
    $ jini_codeserver.sh
  4. Start a code server for the examples codebase
    There are two services (other than the lookup service) that will be sought by our clients: a transaction manager (in this case, Mahalo), and an "unreliable service" of our own making. The unreliable service will need to furnish a codebase so it can provide its proxy to others. The lib12 directory has an UnreliableService-dl.jar file for this purpose. We must, therefore, start a code server to service this directory. A script is provided to do this. To start this code server, run this:
    $ app_codeserver.sh
  5. Start a lookup service for the public group
    Most of the examples assume that the services they seek can be found in the public group. To start the lookup service for the public group, run this:
    $ start_reggie.sh
    Note that Reggie is an activatable service so the script that registers Reggie with the RMID daemon will exit.
  6. Start a transaction manager in the public group
    Like Reggie, the transaction manager contributed by the Jini team is activatable. To start this service, which will be registered in the public group, run this:
    $ start_mahalo.sh
  7. Start a service browser
    This step is not strictly necessary but can aid in your understanding of these examples. The service browser provides a means of finding lookup services and inspecting those lookup services to see what services are registered with them. See the starter kit for more information regarding the service browser. To start a browser, run this:
    $ start_browser.sh

There are now enough services running that you should be able to execute the following examples:

One example,

will require starting a second lookup service and a second transaction manager in a new group (named "LookupCacheEvents"). These additional steps are necessary to run Example 5:

Please read the Example 5 description carefully. The reason we create a separate group (with its own lookup service and transaction service) is because the example makes changes to the transaction service (and we wouldn't want to mistakenly change somebody elses transaction service by accident). The example, once run, changes the transaction service's registration in a way that makes it difficult to find the service again. This means that the example will work the first time but not the second or subsequent times unless you restart the transaction manager service.

Running the Examples with starter kit version 2.0

Two important Jini-based services, Reggie and Mahalo, are built as activatable services in the v1.2.1 starter kit. Jini v2.0 introduced new versions of these services which may be run in a transient configuration.

Here are the steps for starting the appropriate services before running the examples. All of these steps assume you are in the bin20 directory (or the bat20 directory if you are running under Microsoft Windows). It is best to run all of these commands in separate windows or shells.

  1. Populate the lib20 directory
    The Ant build.xml script will copy the jsk-platform.jar and jsk-resources.jar files into the lib20 directory as part of the build process. However, these files are not shipped with the other pre-built libraries. If you wish to run these examples from the pre-built libraries, you must copy the jsk-platform.jar and jsk-resources.jar files from the starter kit distribution into the lib20 directory prior to using the examples.
  2. Update the JINI_HOME.sh files
    Some scripts in this directory are used to start services bundled with the starter kit. The location of the starter kit must be specified so these scripts will work. The JINI_HOME.sh script specifies the location of the starter kit. This location is utilized by the other scripts as necessary. Update this script to point to the top of the starter kit tree.
  3. Start a code server for the starter kit-based services codebase
    Services such as Reggie and Mahalo have proxies and will require clients of those services to fetch the code for those proxies from their codebase. A code server should be started to service the lib directory of the starter kit where the various -dl.jar files for these services are located. A script is provided to do this. To start this code server, run this:
    $ jini_codeserver.sh
  4. Start a code server for the examples codebase
    There are two services (other than the lookup service) which will be sought by our clients: a transaction manager (in this case, Mahalo) and an "unreliable service" of our own making. The unreliable service will need to provide a codebase so it can provide its proxy to others. The lib20 directory has a UnreliableService-dl.jar file for this purpose. We must therefore start a code server to service this directory. A script is provided to do this. To start this code server, run this:
    $ app_codeserver.sh
  5. Start a lookup service for the public group
    Most of the examples assume that the services they seek can be found in the public group. (There is one example that assumes another group which will be discussed later.) To start the lookup service for the public group, run this:
    $ start_reggie.sh
  6. Start a transaction manager in the public group
    To start this service which will be registered in the public group, run this:
    $ start_mahalo.sh
  7. Start a service browser
    This step is not strictly necessary but can aid in your understanding of these examples. The service browser provides a means of finding lookup services and inspecting those lookup services to see what services are registered with them. There is significant documentation within the starter kit on the service browser which is worth reading. To start a browser, run this:
    $ start_browser.sh

There are now enough services running that you should be able to run the following examples:

One example,

will require starting a second lookup service and a second transaction manager in a new group (named "LookupCacheEvents"). The following steps are necessary to run Example 5:

Please read the Example 5 description carefully. The reason we create a separate group (with its own lookup service and transaction service) is because the example makes changes to the transaction service (and we wouldn't want to mistakenly change somebody elses transaction service by accident). The example, once run, changes the transaction service's registration in a way that makes it difficult to find the service again. So, the example will work the first time and not the second or subsequent times unless you restart the transaction manager service.

SDM examples main page
next
Copyright 2004 Sun Microsystems, Inc. All Rights Reserved.