tauZaman DESIGN DECISIONS (Dynamic Loading)

1. 

    Implementations of Calendars (scale and cast methods), Field Value Functions or Irregular Mappings are all distributed. So, the system needs to have the ability to load distributed code from different sites. Since Sun JDK is being used, there are two basic alternatives to follow;

1. Native ClassLoader class might be utilized. In fact, URLClassLoader, which is a subclass of SecureClassLoader (whose super class is ClassLoader) is very convenient to use. The fact that methods of classes and their parameters are known before hand makes things appropriate. Dynamic resolving of classes can be solved using supported classes on client side.

 

2. Java RMI (Remote Method Invocation). It is a Remote Procedure Call (RPC) package built in new versions of JDK. In fact, RPC option also brings a new design issue. Should our system remotely call methods of supporting classes (Calendar classes, Field Value Function classes or Irregular Mapping classes) or should it download them into the system first and then call appropriate    methods? 

 

    As can be seen, this seems to be another lazy vs. eager approach problem. First alternative is a lazy approach, whereas, the latter is an eager one.

 

    First alternative is rather naive way to implement, however it is viable and compact in the sense that it gives exactly what we want (with URLs of classes and isolated components with all their parts combined). And obviously response time to queries is relatively small than using RPC. On the other hand it does not allow remote callings.

 

    Second alternative is rather extensive. RMI can also allow dynamic class loading along with remote calls. It also gives lots of services what we don't want. However, if future extensibility is desired surely RMI is the one to use.

 

    My current idea is to implement the system with ClassLoaders (first alternative) such that porting to RMI implementation is easy. That needs to make parts of ClassLoaders as isolated as possible from parts of system. During this period an RMI study can be carried out simultaneously.

2.

   To prevent writing same code for dynamic loading (exceptions, etc.) in several components and gain benefits from URLClassLoader protected methods, a new class called ClassLoaderMethodCaller(CLMC) is extended from URLClassLoader. There are 3 places that we have to use dynamic loading;

 

1. CalendricSystem and Calendar with irregular mappings.

2. Calendar with regular functions.

3. FVFunction with field value functions.

 

For 1, there will be an instance of CLMC class for every irregular mapping, with this we ensure that, there will be no versioning problem. For example, there may be two different classes containing different versions of same methods. We can not have the choice if we use a single instance of CLMC class with a URL array. But by having an instance of CLMC class for every irregular mapping, we ensure that it contains only one URL, which is PK, and class and method names are for multiplexing purposes.

 

For 2, there will be an instance of CLMC for every Calendar since regular functions are contained in one class, which will be pointed by a URL. Methods' names are same through out all regular functions, which are FieldsToGranule and GranuleToFields. (this constraint may be relaxed easily.)

 

For 3, there will be an instance of CLMC for every FVFunction.