Description of a YODA plugin
This document describes how one would go about writing a
plugin for the YODA architecture and how YODA interprets the plugin.
YODA plugins have two basic components: The components to be used by the
client applications on the possibly thousands of nodes, and the components to be
used by the server to handle the workunit scheduling. Now, all classes to be
used by these components must be packaged into two jar files: One for the client,
and one for the Server.
You may want to download the jar file containing the core interfaces required by the problem plugins of the YODA system. This should provide a much clearer picture of the sytem. It is also recommended that you read the javadocs for the plugin's main interfaces. A plugin supplier must follow very strict conventions, interfaces and standards if the plugin is to work approriately with YODA. Unlike other distributed systems, YODA is designed to accept plugins directly over a web-based interface, validate them to the best of its ability, and integrate the plugin with itself during runtime. Hence, without a human being to integrate the plugin within YODA, the plugin must be carefully designed to prevent errors and problems which may invariably cause the YODA webserver to crash.
The Client Side:
These client jar file must contain a class that implements the interface
'org.sarovar.yoda.ProblemSolver'. This interface allows the client application
to communicate with the actual problem solver and execute it sucessfully. The client
side must also provide an xml file describing the problem in brief for the user
so that he/she may be able to see what problem they are contributing to. More importantly,
this XML file is also expected to contain the name of the class that implements the
said interface. This allows the client to extract that class and execute it. The jar file
may, and most probably will, contain other classes required by this class. You may view the DTD for the Client XML file and its
associated HTML documentation for more details.
The Server Side:
The server side is slightly more tricky. It should also have all its requisite classes
packaged in a jar file. However, the server's xml file contains, in addition to the
standard name and description, the names of THREE classes. These MUST BE DISTINCT classes
so that they can be properly synchronized by the server. These each of these class must
implement exactly one of the three interfaces, viz., org.sarovar.yoda.WorkUnitGenerator,
org.sarovar.yoda.WorkUnitSolutionMerger, and org.sarovar.yoda.WorkUnitVerifier.
Also, the server side must be provided with two files containing appropriate initial
values based on the problem. One of these files is a file provided to the WorkUnitGenerator's
getNextWorkUnit method. This file must contain the entire state required to generate
the next work unit for the problem. The getNextWorkUnit method must be able to execute
ONLY with the contents of this file and generate the next work unit appropriately.
The other file is the one provided to WorkUnitSolutionMerger's mergeSolution method.
This file must, at the end of execution of the entire problem, contain the final solution to the problem. It will be the sole file returned to the scientist submitting the problem. It must also contain ALL the state required to merge all solutions. The mergeSolution method must be able to
use only this file to store/merge all WorkUnitSolutions and provide a final
soltuion back to this file when the execution is finally completed. It is possible that the
scientist may be allowed, through the web-based YODA interface, to view the contents of this
file from time to time.
You may view the DTD for the Server XML and its associated HTML documentation for more details.
Please view our sample plugin for more details and the actual source code and structure of a plugin.