writing a new service



A new service should be a class extending VerySimpleService and implementing one remote-interface. A good example is the photo-service.
The base-class takes care of creating a proxy-object, registring the service, managing the attributes, optaining a unique identifier, authenticating and encrypting the network-comminication and controlling-access to the interface as well as the implementing persistent state.
This is the code of the service. It represents a very minimal function:


public class PhotoService extends VerySimpleService implements PhotoProxyIF
{
private static final boolean debugThis = true;

public PhotoService() throws java.rmi.RemoteException , java.io.IOException
{
if(debugThis)Logger.debug.println("DEBUG: PhotoService starting up...");
init(this, jaugment2.photo.PhotoProxyIF.class);



}

public static class PhotoCameraFactory implements PhotoProxyIF.PhotoCameraFactory
{
private static PhotoProxyIF.PhotoCameraIF cam = null;
public PhotoProxyIF.PhotoCameraIF createCamera()
{
if(cam!=null)
return(cam);
cam = new PhotoCamera();
return(cam);
}
}

public PhotoProxyIF.PhotoCameraFactory getCameraFactory() throws java.rmi.RemoteException
{
return(new PhotoCameraFactory());
}


public String getComment()
{return("takes photos with optional timestamp+position+orientation");};
public String getCreator()
{return("Marcus Wolsc< @gmx.net="">");};
public UIDescriptor getUIDescriptor()
{
if(debugThis)Logger.debug.println("DEBUG: PhotoService.getUIDescriptor() called...");
//TODO: test return(PhotoSwingRepresentation.getUIDescriptor());
return(PhotoDockin.getUIDescriptor());
};


The service-interface if PhotoProxyIF and it defines only the function getCameraFactory().
You see that in the constructor we call init. This call is mandatory. The first argument should nearly always be "this".
The second is the interface. You can also give additional attributes and a first LookupLocator to use. It is a good idea to call loadme() after init(...) if you implemented that function.

The function getUIDescriptor is returns a UIDescriptor for the single, graphical representation of the service or null.
This is the usual case as representations can be atached later and can even be services themself that look for compactible services to atavh themself to.

A service can implement 2 functions loadme() and saveme() where is stores in/loads from a hash-table named persistentState that part of it's state that shall be persistent actoss restarts.
That data is serialized and stored in a file in bin/servicename.dat if the user did not configure another place.

the Logger-class allows to write debug, warning and error-output into a file and/or the console. It will be augmented to support log4j if that is available in the near fututre.

The comment and Creator -strings are inserted into the apropriate attributes in the ServiceEntry.