Execution patterns

The abstract term ‘model’, can apply to any function that returns an output for a given input, therefore allowing models to be developed in any language. Languages commonly used to imple- ment models range from those which compile to machine code (C, Fortran), those which compile to bytecode (Java), and interpreted languages (MATLAB and R). Additionally, a model can be developed with a standard interface, ensuring that all conforming models can be executed in the same way. The choice of language, means of interaction (graphical or command-line interface), and adoption of a standard interface will strongly influence how a model can be executed by a Web service interface. This section discusses execution patterns for compiled and interpreted language models, and those conforming to a standard interface.

Compiled language models

When communicating with a compiled language model, we rely on the model to be written in a manner that is suitable for automated execution. As we are only dealing with request-response Web service interaction, the model must not require any additional decisions to be made during runtime. Inputs must therefore be supplied either as execution parameters, files readable by the model, or through another source, such as a database. Outputs must be returned through standard system output, files on disk, or saved to other data sources. The major role of the Web service interface for such models is handling input and output data, ensuring that this is done such a manner to successfully execute the model and return the correct outputs.

This pattern for process to model communication immediately excludes models which are only accessible through a GUI application. While it may be technically feasible to script mouse movement and key presses in order to automate GUI model execution, there are several impracti- calities to this approach. As key presses are only sent to the window with focus, subsequent key presses will be sent to the wrong window if focus is lost during communication, therefore caus-

ing the process to fail. Unless export options are provided, capturing output and messages from the GUI is infeasible, and can involve screen capture combined with optical character recogni- tion (OCR). Creating scripted sequences for mouse movement and key presses typically requires specialist, platform-specific, software. The use of such software adds a layer of complexity to model communication, and involves a great deal of additional implementation effort.

If source code is available for the model, it may be possible to remove the GUI to enable automated execution of the model. However, source code may be difficult to acquire for many models, and especially those where development has been inactive for a prolonged period of time. Even once source code is obtained, the code must be understood sufficiently for the necessary modifications to be performed without harming the model itself. The difficulties involved in source code modification are accelerated in cases where the code is undocumented, or if the GUI is tightly coupled to the model.

Interpreted language models

For interpreted language models, the Web service interface must communicate with the software interpreter, rather than any compiled executables. This communication could be as simple as exe- cuting a command line interpreter on the model code, specifying inputs as arguments, and parsing the data from standard output. In a service scenario, and especially one where uncertainty analysis is performed through multiple model evaluations, the overhead of starting the interpreter for each mode evaluation may be significant. This overhead increases when the interpreter initialises an environment, such as those of a numerical nature seen in MATLAB and R.

Program execution restrictions set by operating systems can make specifying high-dimensional model inputs as command line arguments impossible. Consequently, it may be more appropriate for interpreted language models to be programmed with support for file-based inputs and outputs, or handling of data from other sources. For such models, the Web service interface will be similar to those developed for compiled language models, and possess the main responsibility of handling input and output files. However, unless a model already provides support for file-based input and output, execution in this manner will require changes to the model code.

It is more common for models executable in numerical environments to simply be functions that are called, passing existing variables as parameters. For such models, the Web service inter- face must employ a mechanism to communicate with the environment directly, enabling the inter- face to assign values to variables, call the desired model function, and retrieve output variables.

To eliminate the overhead introduced by initialising the environment for each model execution, it may be preferable to instead start the environment prior to model evaluation, which the service interface can then communicate with.

Standard modelling interfaces

While SOAP/WSDL and OGC Web Services (OWS) aim to provide interoperability between Web services, modelling interfaces, such as Open Modelling Interface (OpenMI), seek to do the same for models (Gregersen et al., 2007). These interfaces can be adopted in either compiled or inter- preted languages, and ensure that all models, inputs, and outputs can be described in the same manner, enabling data exchange between multidisciplinary models and software components. Us- ing a modelling interface, a model developer must implement the defined methods to conform to the specification. For OpenMI, a library has been developed in C# and Java, containing a set of interfaces and classes to support this, and shares many similarities to the AbstractProcess class in the processing service framework. An implementing model class can then be compiled, if required, to form components usable by software. OpenMI develop Pipistrelle, a GUI based application for creating compositions of OpenMI components.

Modelling interfaces and the Model Web concept share much in common, as they both aim to achieve interoperability between models. However, many modelling interfaces, including OpenMI, are only designed for local models, therefore provide fewer opportunities for discovery, sharing, and use compared to the Model Web. Instead of considering OpenMI as an alternative to access- ing models through Web services, it can be integrated into Web service components, reducing the amount of communication implementation, as all models can be guaranteed to behave in the same way.