Information For Service Providers

In order to add your own services to the registry, you will need to sign up for an account. This will allow you to add and modify services and tests.

What are tests?
Functional test serve two purposes within the EMBRACE registry. First, they allow the registry to monitor your service and provide reasonably up-to-date information to current and potential users about its current status, and its reliability over a long period of time. Second, they act as simple tutorials for potential users on how to use your service, since the source code for the tests is made available for all to see. You can choose whether to put documentation for the service and its tests on the registry, or simply link to your existing information.

Submitting a test
Writing a suitable test script is straightforward. The minimum that’s required is a single file which can be executed as though it were typed at a command line, and which will run to completion with no command line parameters, and without any user interaction. You will need to use the ‘#!’ notation on the first line of your file to tell the registry which language interpreter to use. The script should connect to your service, execute a function, and examine the results to check that they are ‘sensible’ (where ‘sensible’ is entirely dependent on what your service does!). The script then exits with a return value of 0 for ‘Ok’, ‘1’ for ‘Error’ and anything else for ‘Warning’. Your script can write comments to standard-out and standard-error, and these are simply captured and stored along with the log entry for the script’s execution – the server doesn’t try to interpret these in any way at all. Your script will be executed by a test harness, and runs in a virtual machine isolated from the rest of the registry. Scripts are only allowed to make outgoing connections to the rest of the world on specific ports, and have no write access to filestore of any kind. If a script fails, aborts, or crashes in any way, the test harness interprets this as ‘Error’, and writes a log entry for you.

The registry’s virtual server is configured with the following scripting and programming environments:

• Python, with ZSI and SOAPy
• Perl, with XML::Compile and SOAP::Lite
• Java, with Axis 1.4

If you need a different environment setting up, please mail the registry maintainers.

To submit your test to the registry, you will need to upload a zipped version of your script, and tell the registry what the name of the executable file is.

You can include any number of auxiliary files and directories in your test, as long as they are accessible via a single command and without command line parameters. So if your test requires additional modules or classes etc., simply include them in the zip file that you upload, in whatever file structure allows the command to run from the command line. Generally speaking though, the simpler the better; keep in mind that your test script and its associated files also act as a tutorial for new users.

Testing multiple functions

If your service has more than one function, you can choose whether to test these all in one script, or in lots of individual scripts; it’s entirely up to you. All you have to bear in mind is that if you’re testing lots of functions in one go, you can still only return ‘Passed’, ‘Failed’ or ‘Warning’ from your script, and this will be reflected in the overall status of your service. If you think that some functions may be less reliable than others, you may want to consider separating tests out in to individual scripts (this means that a failure of one test will change your service status to ‘Warning’ rather than ‘Error’). Also remember that a long script that tests many functions may be more daunting for a potential user.

Scripts in multiple programming languages

You can of course test the same function in your service from multiple programming languages; in fact we strongly encourage you to so since it provides another level of usability and robustness for your users, and allows you to detect quirks of the various libraries that may otherwise go undetected.