Working With Control Plugins

If we revisit the diagram on the first page for moment:
basic NTCP diagram

We've now covered the NTCP client in some detail; it's time to look at the control plugin. This is the way NTCP abstracts differences between different control systems. There are several shipped with the distribution that you can use:

Mplugin, for MATLAB
ShoreWestern, for use with their control systems
LabVIEW, for use with any system capable of TCP/IP and ASCII. More info on this at www.mcs.anl.gov/neesgrid/lv-protocol.html
Dummy, for testing and as a skeleton
C plugin, for use with C-language code

Some Basic Information about NTCP and control plugins

Each NTCP instance has one, and only one, control plugin. The plugin can talk to whatever it needs to, so a single control plugin could control more than one piece of equipment. However, as soon as you need two plugins, you need two NTCP instances:
NTCP plugins are in a different CVS package from the server itself, except for one. The C plugin in included with NTCP, and the rest are in the 'nctp_plugins' CVS package.
If you want to develop NTCP plugins, you need to install NTCP and the plugins from CVS; the NEESGrid distribution does not contain the necessary source code.
You need to read and understand the NTCP control plugin API (PDF) completely before starting.
As noted in the development introduction, the plugin is selected at runtime by the contents of server-config.wsdd. We'll look at this first.

Selecting a Plugin to Run

You'll need to edit server-config.wsdd. In this example, we'll change from the dummy plugin to the LabVIEW plugin. As discussed on page two, the default is the dummy. Open server-config.wsdd in a text editor that does not wrap text, and search for 'NTCPServer'. You should see the following:

 <service name="nees/ntcp/NTCPServer" provider="Handler" style="wrapped" use="literal">
  <parameter name="name" value="NTCP Server"/>
  <parameter name="isProfiling" value="false"/>
  <parameter name="operationProviders" value="org.globus.ogsa.impl.ogsi.NotificationSourceProvider"/>
  <parameter name="persistent" value="true"/>
  <parameter name="schemaPath" value="schema/nees/ntcp/ntcp_server_service.wsdl"/>
  <parameter name="baseClassName" value="org.nees.ntcp.server.impl.NtcpServerImpl"/>
  <parameter name="ntcpBackendFactory" value="org.nees.ntcp.server.backend.test.DummyControlFactory"/>
  <parameter name="handlerClass" value="org.globus.ogsa.handlers.RPCURIProvider"/>
  <parameter name="authorization" value="none"/>
  <parameter name="isSecure" value="false"/>
  <parameter name="className" value="org.nees.ntcp.ntcpServer.NtcpServer"/>
  <parameter name="localPolicyPlugin" value="org.nees.ntcp.server.backend.test.DummyLocalPolicyPlugin"/>
  <parameter name="allowedMethods" value="*"/>
 </service>

We're going to do two things: Change the control plugin, and add two parameters required by the LabVIEW plugin. Since the LV plugin initiates the connection to the LabVIEW system, it needs to know the DNS name and TCP port to open. These are contained in lvPort and lvHost. Here's an example replacement service entry:

 <service name="nees/ntcp/NTCPServer" provider="Handler" style="wrapped" use="literal">
  <parameter name="name" value="NTCP Server"/>
  <parameter name="lvHost" value="130.126.240.141"/>
  <parameter name="isProfiling" value="false"/>
  <parameter name="operationProviders" value="org.globus.ogsa.impl.ogsi.NotificationSourceProvider"/>
  <parameter name="persistent" value="true"/>
  <parameter name="lvPort" value="44000"/>
  <parameter name="schemaPath" value="schema/nees/ntcp/ntcp_server_service.wsdl"/>
  <parameter name="baseClassName" value="org.nees.ntcp.server.impl.NtcpServerImpl"/>
  <parameter name="ntcpBackendFactory" value="org.nees.ntcp.plugins.labview.LabviewPluginFactory"/>
  <parameter name="handlerClass" value="org.globus.ogsa.handlers.RPCURIProvider"/>
  <parameter name="isSecure" value="false"/>
  <parameter name="className" value="org.nees.ntcp.ntcpServer.NtcpServer"/>
  <parameter name="localPolicyPlugin" value="org.nees.ntcp.server.backend.test.DummyLocalPolicyPlugin"/>
  <parameter name="allowedMethods" value="*"/>
 </service>

Notes

the 'isSecure' entry must match what's in the NTCP client. Both must be either secure or insecure; you cannot mix the two modes.
lvHost can be numeric, as above, or a normal host name.
lvPort defaults to 44000, if you change it you have to change the port the LabVIEW code is using as well.
Parameter order is not significant.
If you write your own plugin, you can change ntcpBackendFactory to the full name of your class. Of course, your class must be deployed into $OGSA_ROOT, meaning that your jarfile must be in $OGSA_ROOT/lib

Running Multiple NTCP Instances with Different Plugins

If, as is the case with the Mini-MOST, you want to run more than one instance of NTCP on a single machine with different plugins, there's a bit of work to do. The underlying problem is this: There is no way to tell OGSA to use a different server-config.wsdd file.

However, once the container is started, it doesn't re-read the file. Therefore, all we need to do is something like this:

Copy saved-wsdd file to server-config.wsdd
ant startContainer -Dservice.port={first TCP port, e.g. 8090}
sleep 10-30 seconds, depending on how fast the computer is
Repeat, with next saved WSDD file.

Consider this a workaround until we find a better method.

The next page deals with writing your own control plugin; it seemed a logical separation. If you want to learn about control plugins in C instead of Java, please proceed to this page instead.