|
+ View the NASA Portal + NASA en Español + Contact NASA |
|
Download
|
Developing a Profile HandlerProfiles describe resources. But where do profiles come from? From profile handlers. Profile handlers are interchangeable components of a profile server that accept queries for profiles and return matching profiles. Profile handlers take a static or a dynamic collection of information and serve an equivalent set of profiles. Developing a new profile handler is as simple as writing a Java class that implements a specific interface or two.
If you're not already familiar with the
IntroductionProfile handlers handle queries for profiles. They're the interchangeable part of a profile server that you can develop for special needs. Profile servers delegate all incoming requests to zero or more profile handlers, as shown in the following class diagram: 
Developing, testing, and deploying a new profile handler involves:
This document describes each of these steps in detail. Writing the Handler ClassWriting the class that handles profile queries and delivers profile results is easily the hardes t part in developing a new kind of profile server. Profile servers' handlers can serve profiles describing static resources, can synthesize profile on the fly to describe resources, and can create profile metadata for resources that change all the time. Understanding the resources you're trying to describe with profiles is the most important thing you can do before beginning to write your profile handler:
Choosing the Handler Interface to ImplementThe OODT Framework provides two handler interfaces (one is an extension of the other):
For nearly all applications, the
The ProfileHandler Interface
The
package jpl.eda.profile.handlers;
import java.util.List;
import jpl.eda.profile.Profile;
import jpl.eda.profile.ProfileException;
import jpl.eda.xmlquery.XMLQuery;
public interface ProfileHandler {
List findProfiles(XMLQuery query) throws ProfileException;
Profile get(String profID) throws ProfileException;
}
The two methods are described in detail below.
The ProfileManager Interface
The
package jpl.eda.profile.handlers;
import java.util.Collection;
import java.util.Iterator;
import jpl.eda.profile.Profile;
import jpl.eda.profile.ProfileException;
import jpl.eda.xmlquery.XMLQuery;
public interface ProfileManager extends ProfileHandler {
void add(Profile profile) throws ProfileException;
void addAll(Collection collection) throws ProfileException;
void clear() throws ProfileException;
boolean contains(Profile profile) throws ProfileException;
boolean containsAll(Collection collection) throws ProfileException;
Collection getAll() throws ProfileException;
boolean isEmpty() throws ProfileException;
Iterator iterator() throws ProfileException;
boolean remove(String profID, String version) throws ProfileException;
boolean remove(String profID) throws ProfileException;
int size() throws ProfileException;
void replace(Profile profile) throws ProfileException;
}
If you choose to implement a profile manager, please see
the API documentation for the
Our First Profile HandlerAlthough not terribly useful, a “ null ” profile handler is a good example to start with because it is small and will make sure your environment is in good working order before proceeding to a real profile handler.
What's a
“
null
”
profile handler? It's one that
serves no profiles. That is, for any query with
Directory Layout
For these examples, we'll work on a kind of Unix system
with a
We'll create a "home" directory for our profile ser
vers
with subdirectories to hold specific components like source
code, jar files, and scripts. We'll call this home
directory by an environment variable,
% mkdir ps % cd ps % setenv PS_HOME `pwd` % mkdir bin classes lib src Source FileOne of the easier parts is the source itself for the ‘ null ’ profile handler. Here it is: import java.util.Collections;
import java.util.List;
import jpl.eda.profile.Profile;
import jpl.eda.profile.handlers.ProfileHandler;
import jpl.eda.xmlquery.XMLQuery;
public class NullHandler implements ProfileHandler {
public List findProfiles(XMLQuery query) {
return Collections.EMPTY_LIST;
}
public Profile get(String id) {
return null;
}
}
Note that for every query, the
This class should be compiled into a file named
Note: Profile handler classes must be public and provide a no-arguments constructor. You should retrieve any initialization settings through the System Properties or by other means specific to your profile handler. Compiling the HandlerCompiling this profile handler requires the following dependent components:
Download the binary distributions of the above two packages
and copy the jar file from each into the
% ls bin classes lib src % ls -l lib total 244 -rw-r--r-- 1 kelly kelly 43879 28 Feb 07:05 edm-query-2.0.2.jar -rw-r--r-- 1 kelly kelly 201453 28 Feb 07:01 grid-profile-3.0.2.jar % javac -extdirs lib -d classes src/NullHandler.java % ls -l classes total 4 -rw-r--r-- 1 kelly kelly 511 28 Feb 07:07 NullHandler.class % jar -cf lib/my-handler.jar -C classes NullHandler.class % jar -tf lib/my-handler.jar META-INF/ META-INF/MANIFEST.MF NullHandler.class
We now have a new jar file,
Starting an RMI RegistryClients access profile servers with an open-ended set of network protocols. We currently have implementations for RMI and CORBA. For this tutorial, we'll use RMI, since it's enormously less complex. Clients of RMI systems first contact an RMI registry and look up a server object's network address. The registry maintains mappings from a server object's name to its network address. When servers start up, they register with the RMI registry so clients can later find them. To start an RMI Registry, you'll need the following components:
Download each component's binary distribution, unpack each
one
, and take collect the jar files into the
% ls -l $PS_HOME/lib total 404 -rw-r--r-- 1 kelly kelly 149503 28 Feb 07:28 edm-commons-2.2.5.jar -rw-r--r-- 1 kelly kelly 43879 28 Feb 07:05 edm-query-2.0.2.jar -rw-r--r-- 1 kelly kelly 201453 28 Feb 07:01 grid-profile-3.0.2.jar -rw-r--r-- 1 kelly kelly 796 28 Feb 07:07 my-handler.jar -rw-r--r-- 1 kelly kelly 8055 28 Feb 07:28 rmi-registry-1.0.0.jar
Now all we need is a convenient script to start the RMI
registry. We'll call it
#!/bin/sh
exec java -Djava.ext.dirs=$PS_HOME/lib \
gov.nasa.jpl.oodt.rmi.RMIRegistry
This script tells the Java virtual machine to find
extension jars in the directory
Go ahead and make this script executable and start the RMI
Registry. In another window (with the appropriate setting of
% chmod 755 $PS_HOME/bin/rmi-reg % $PS_HOME/bin/rmi-reg Mon Feb 28 07:30:13 CST 2005: no objects registered
The RMI Registry is now running. Every two minutes it will
display an update of all registered objects. Naturally, we
don't have any profile service running right now, so it will
say
Starting the Profile Server
With our handler compiled and our RMI registry running,
we're ready t
o start our profile server. As said before,
profile servers delegate to zero or more profile handlers to
actually handle all incoming requests. You tell the profile
server what handlers to instantiate by naming their classes
in a system property. That property is called
Profile server processes require the following components in addition to the ones we've downloaded so far:
Copy these two other jars to the
% ls -l $PS_HOME/lib total 1580 -rw-r--r-- 1 kelly kelly 149503 28 Feb 07:28 edm-commons-2.2.5.jar -rw-r--r-- 1 kelly kelly 43879 28 Feb 07:05 edm-query-2.0.2.jar -rw-r--r-- 1 kelly kelly 201453 28 Feb 07:01 grid-profile-3.0.2.jar -rw-r--r-- 1 kelly kelly 1144107 28 Feb 09:23 jena-1.6.1.jar -rw-r--r-- 1 kelly kelly 796 28 Feb 07:07 my-handler.jar -rw-r--r-- 1 kelly kelly 8055 28 Feb 07:28 rmi-registry-1.0.0.jar -rw-r--r-- 1 kelly kelly 53978 28 Feb 09:20 xmlrpc-1.1.jar
Now, create a second shell script to make starting the
profile server convenient and call it
#!/bin/sh
exec java -Djava.ext.dirs=$PS_HOME/lib \
-Dhandlers=NullHandler \
jpl.eda.ExecServer \
jpl.eda.profile.rmi.ProfileServiceImpl \
urn:eda:rmi:MyProfileService
Make the script executable and start the profile server: % chmod 755 $PS_HOME/bin/ps % $PS_HOME/bin/ps Object context ready; delegating to: [jpl.eda.object.jndi.RMIContext@dec8b3]
The profile server will start, check its
What's in a Name?
The profile server registers itself using a name provided
on the command-line, in this case,
If you're familiar with web standards, you can see that the
name is a Uniform Resource Name (URN), since it starts with
Next comes
Finally is
Or you might prefer to use ISO country codes. Or you might
name them according to the kinds of profiles they serve,
such as
The RMI registry will happily re-assign a name if one's already in use, so when deploying your own profile (and other) servers, be sure to give each one a unique name. Querying the Profile Server
To query a profile server, you use the
Still, we'll make a script, called
#!/bin/sh
if [ $# -ne 1 ]; then
echo "Usage: `basename $0` <query-expression>" 1>&2
exit 1
fi
exec java -Djava.ext.dirs=$PS_HOME/lib \
jpl.eda.profile.ProfileClient \
urn:eda:rmi:MyProfileService \
"$1"
Make this script executable and then run it: % chmod 755 $PS_HOME/bin/pc % $PS_HOME/bin/pc "temperature = 37" Object context ready; delegating to: [jpl.eda.object.jndi.RMIContext@dec8b3] []
Although it may not look spetacular, this is a success!
The two square brackets,
ConclusionThe Null Profile Server made sure our development environment worked from end to end for creating, deploying, and testing a profile handler. Now you're ready to implement a real profile handler:
|
|
+ Freedom of Information Act + NASA Privacy Statement, Disclaimer, and Accessibility Certification
+ Freedom to Manage |
|
Editor: Sean Kelly NASA Official: Dan Crichton Last Published: 07 July 2006 + Contact NASA |
|
|
|||