Common Base Classes

There are a few base plugin classes and interfaces in the hec2.plugin package. These classes provide basic functionality for plugins.
Required Interfaces:
For a plugin to work in the WAT at least one of the following needs to be implemented:

SimplePlugin

The base interface for plugins.

WatPlugin

Interface for full participation in the WAT.

ComputablePlugin

Interface for plugins that participate in computes.

DisplayablePlugin

Interface for plugins that interact with the map window and have actions.


Optional plugin Interfaces:
The following interfaces provide additional optional functionality for a plugin:

BackgroundImportPlugin

Interface for plugins that perform their import process in a background thread.

ClientServerPlugin

Interface for client/server plugins to return information to the WAT client about the status of the server.

CreatablePlugin

Interface for plugins that can create new ModelAlternatives from inside the WAT.

DynamicLinkagePlugin

Interface for plugins that support dynamic model linkages.

IndependentComputablePlugin

Interface for plugins that don't participate in the simulation compute, but can compute independently.

NonInteractiveImportablePlugin

Interface for plugins that can import their data without interaction with the user.

OutputPlugin

Interface for plugins that support Output Variables.

RestartableComputePlugin

Interface for plugins that can restart themselves during a compute if an error occurs.

SaveProjectAsPlugin

Interface for plugins that need to perform their own save-as when the WAT study is saved-as.

SelfContainedPlugin

Interface for plugins that have no underlying native model. Allows for actions that would be normally be performed by that native model.


plugin Type Interfaces:
The following interfaces define special plugins that perform specific operations during the compute process:

HydrologicEventPlugin

Interface for plugins that can generate the EventTimeWindows during the FRA Compute.

TimeWindowIntervalPlugin

Interface for plugins that fill in the EventList RuntimeWindows during a Non-FRA compute.


Classes:
The following are some of the classes that plugins can extend to help fill out functionality:

AbstractPlugin

Base class for most plugins.

AbstractComputablePlugin

Base class for plugins that compute.

AbstractJavaClientPlugin

Client-side class for plugins (like ResSim) that start their Java application in a separate JVM. Handles starting/restarting the server.

AbstractSimpleJavaPluginServer

Server-side class for plugins (like ResSim) that start their Java applications in a separate JVM.

AbstractJavaServerPlugin

RMI Interface for the AbstractSimpleJavaPluginServer.


Figure 1 Base plugin classes



Figure 2 Base Server-side classes

plugin Interfaces

There are three main plugin interfaces that a plugin must implement one of: SimplePlugin, WatPlugin, or DisplayableWatPlugin. The ClientServerPlugin interface should be implemented for plugins that are client-server.
A plugin only needs to implement one of SimplePlugin, WatPlugin, or DisplayableWatPlugin depending on the level of integration desired. A plugin can implement many interfaces to exploit different functions made available to control HEC-WAT. For a complete list of all plugin interfaces, and description of the purpose of their methods and descriptions of any parameters, please refer to the plugin API appendix.
If the model exists and needs to run as a separate process from HEC-WAT, the best way is through the client-server architecture. To achieve this, the plugin must implement hec2.wat.plugin.ClientServerPlugin. The ClientServerPlugin interface allows HEC-WAT to interrogate the plugin for the status of the server part of the plugin.

SimpleWatPlugin

Interface for the simplest plugins, which are only to be used as tools by the WAT.

WatPlugin

Interface for plugins that participate in the compute process. This extends SimpleWatPlugin.

DisplayableWatPlugin

Interface for plugins to display information on the MapSchematic, and provide actions for the various menus. This extends WatPlugin.

ClientServerPlugin

Interface for client/server plugins to return information to the WAT client about the status of the server.



Figure 3 WAT plugin Interfaces

SimplePlugin

A plugin must implement the interface hec2.wat.client.SimpleWatPlugin. This interface defines the basic functionality that a plugin must support such as creating a project, opening a project, or getting a list of model alternatives. This is an empty marker interface and all its methods come from hec2.plugin.SimplePlugin.

WatPlugin

plugins inserted into a WAT Simulation compute must implement hec2.wat.plugin.WatPlugin, which extends hec2.wat.plugin.SimpleWatPlugin and defines methods used by the Simulation process.

DisplayableWatPlugin

plugins that need to display information on the map schematic should implement the interface hec2.wat.client.DisplayableWatPlugin. The DisplayableWatPlugin interface defines additional functionality that a plugin must support to be displayed on a map schematic. This may include returning a list of elements to display, displaying an editor for an item, or displaying output for one or more element.
The hec2.wat.client.DisplayableWatPlugin interface extends hec2.wat.client.WatPlugin.
The four HEC programs will all be DisplayableWatplugins since they all have graphics elements.

Java Program plugin

Some of the Java-based programs (i.e. ResSim, and FIA) all share a common client-side plugin and RMI interface for the server side. As the server side is unique to each program that the client only needs to implement a couple of methods. Since the server-side component of the plugins will all be implemented using the same RMI interface, the client side can be based on the same base class, with the only difference being the server that they launch.

Self-Contained plugins

The Hydrologic Sampling and Fragility Curve plugins are written completely in the plugin and do not rely on the client-server design of the other plugins. To support this, new classes were added to the plugin framework. The new classes were written to make it easier for other plugins to be written by factoring common code into a few classes.

Base Classes

The class hec2.wat.plugin.AbstractSelfContainedPlugin is the base class for plugins that handle everything themselves (not the existing model that they are wrapping). The class signature looks like:
public abstract class AbstractSelfContainedPlugin<E extends SelfContainedPluginAlt> extends AbstractComputablePlugin implements DisplayableWatPlugin, SelfContainedPlugin
A plugin that extends AbstractSelfContainedPlugin will have a constructor similar to this:
public class FragilityCurvePlugin extends AbstractSelfContainedPlugin <FragilityCurveAlt> implements CreatableWatPlugin