75.

  

A Client-Side RCX Class

In the simplistic client given earlier, there were many steps that will be the same for all clients that can drive the RCX. Just as JoinManager simplifies repetitive code on the server side, we can define a "convenience" class for the RCX that will do the same on the client side. The aim is to supply a class that will make remote RCX programming as easy as local RCX programming.

A class that encapsulates client-side behavior may as well look as much as possible like the local RCXPort class. We define its (public) methods as follows :

 public class JiniRCXPort {     public JiniRCXPort();     public void addRCXListener(RCXListener l);     public boolean write(byte[] bArray);     public byte[] parseString(String str); } 

This class should have some control over how it looks for services by including entry information, group information about locators, and any specific locators it should try. There are a variety of possible constructors, all ending up calling a constructor that looks like this:

 public JiniRCXPort(Entry[] entries,                        java.lang.String[] groups,                        LookupLocator[] locators) 

The class is also concerned with uniqueness issues, as it should not attempt to send the same instructions to an RCX more than once. However, it could send the same instructions to more than one RCX if they match the search criteria. Therefore, this class maintains a list of RCXs and does not add to the list if it has already seen the RCX from another service locator. This requires that a single RCX should be registered using the same ServiceID with all locators, which will be the case because the RCX server uses JoinManager .