Binary distribution Guide (Soaplab)

Guide to binary distribution users

This chapter is intended for those who are going to use a binary distribution of Soaplab in order to create, deploy and add services.

There is a general introduction for Soaplab service provider (a page where you probably just came from).

The text below often refers to "your applications" or to "your analysis tools". It always means the tools you are going to wrap as Web Services. They can be almost any command-line programs (there may be some limitations for those who have home-made, strange command-line syntax - but even for them there is usually a work around).

This chapter is also for those who explore the Gowlab, a newer Soaplab's sub-project. For Gowlab, you also need to describe an "analysis", even though in this case an "analysis" is actually a remote web resource. Therefore, for Gowlab it may be useful to read directly the Gowlab documentation.

Download & Installation & Running
How to add new analysis tools

Binary distribution Download & Installation & Running

Here are the steps you are going to do:

Download

The binary distribution is available from the main Soaplab distribution site. Take there the latest file analysis-interfaces-YYYY-MM-DD.tar.gz.

The file contains (almost) everything you need for deploying Soaplab services on top of your command-line tools. Why almost? Because it does not have the descriptions of (almost) any analysis tools - you have to write them.

The distribution includes descriptions (metadata) for several simple programs (like helloworld, or perhaps more useful dot tool from Graphviz). They serve as examples how to write your own metadata for other analysis tools.

It also includes some clients - you will use them to test your installation. Actually, as a side-effect of the way how Soaplab is implemented (because it uses some older projects), you get not only SOAP-based clients, but also other interfaces:

ALWeb, a traditional CGI-BIN based access to your applications.
A Web Services interface (soaplab) - this is the one we are talking about now
A CORBA interface (applab), using several standalone Java GUI clients (snapshot 1, snapshot 2, snapshot 3)

All interfaces are accessing your applications via an AppLab server which is CORBA-based (you may again look at the architecture picture in order to refresh what components are involved). You do not need to have or install CORBA - it is included in the package.

The included ORB is ORBacus for Java. If you continue to use this binary distribution, however, you should go to IONA and donwload ORBacus jar files yourself in order to fulfil their license agreement.
Again, their jar files are probably much newer and I have not tested the new ones for years. So perhaps, keep using the jar files from the Soaplab distribution, but fulfill their licensing agreement.

When deploying and using Gowlab, there is no CORBA layer involved.

Installation

Unpack what you downloaded. It creates the analysis-interfaces directory.
Go where you unpacked it. Many parts of this directory will be updated during the next step (by adding the current location). Therefore, do the unpacking in the place where you want to keep it. Also, now is the time to change the name of the top level directory if you wish.
Run the installation script:
perl INSTALL.pl
It is interactive (by the way, it works better if you have installed GNU Readline library). Its main purpose is to update unpacked files to reflect locations of the Tomcat server, and to add paths to the current directory. You can run it more than once without harm (the original files are backed up with the suffix .orig.
The installation script can run also in a non-interactive mode:
perl INSTALL.pl -q
In this case you need first to set some environment variables. Let's go through them now - it gives you feeling what you can expect during the interactive mode:

PROJECT_HOME
A directory where everything has been unpacked.
The installation script actually does not ask for this place, it uses the location of the installation script itself. But sometimes it guesses wrongly - especially when the current directory is strangely mounted. In such case, set this environment variable to make sure where your installation is placed.
JAVA_HOME
Where is your JDK installed.

TOMCAT_HOME
A directory where your Tomcat is installed.

TOMCAT_URL
A URL used to access your Tomcat (e.g. http://localhost:8080)

AXIS_IN_TOMCAT
The installation script copies all Soaplab jar files to the place where Axis can find them. Specify a directory where the Axis jar files are located within your Tomcat server (the default value is usually good enough unless you have a non-standard-named Axis installation). Note that you need to have a write permission to the Tomcat directories.

RESULTS_URL
A URL pointing to the server-side results (you can leave it blank if you do not plan to use this feature):
The results of your applications may be created as HTML pages that can be viewed by any Web Browser (meaning that such results are not moved to the client by SOAP, but the client gets only a URL and he/she opens his/her standard web browser and browses the results there). Such results will be created in the subdirectory (of the current directory) a/_WEB_.
In order to view them, you need to configure your HTTP server to have access to this directory. This step, usually done by creating a symbolic link in the data space of your HTTP server, is NOT done by this installation script. However, the installation needs to know what will be the URL used by your HTTP server to point to this subdirectory. And that's this environment variable about.

MYSQL_URL
A URL (sometimes called a location) of the mySQL Soaplab database. See below details how to create such database. The usage of the local database keeping results from the executed analysis tools is optional.

MYSQL_USER
A user name used by Soaplab to access the mySQL database.

MYSQL_PASSWD
A password used by Soaplab to access the mySQL database. Both user name and password will appear as plain text in the Tomcat/Axis configuration file that defines what services are deployed. For Tomcat, it is usually in a file $TOMCAT_HOME/webapps/axis/WEB-INF/server-config.wsdd. Take care about the file access rights if this password is a sensitive issue.

ADD_TO_PATH
A (colon separated) list with all directories you want to be added to the PATH before any server starts.
You may leave it blank if all your applications are on default paths. What you define here is used when an AppLab server is started (see details about it in a minute, below) - it does not influence the paths known to your Tomcat server (Tomcat always talks to the analysis tools only via AppLab server).

ALWEB_SCRIPTS_URL
A URL of the directory with the AlWeb cgi-bin scripts.
This variable and the following one have nothing to do with Web Services (actually neither with Soaplab). But as already mentioned, together with the Soaplab binary distribution you get also, as a historical side-effect, a CGI-based interface called alweb. If you want to use it, set this and the following environment variables.
The alweb (Perl) scripts and few static pages will be installed in the subdirectories alweb/cgi-bin and alweb/docs. You have to tell your HTTP server how to find them (for example, by making symbolic links from your server data space to alweb/cgi-bin and to alweb/docs here). Note that these links are NOT done by this installation. However, the installation needs to know what will be the URLs used by your HTTP server to point here.

ALWEB_DOCS_URL
A URL of the directory with the alweb static pages.


	Running Applab server

Start AppLab server (skip this when planning to use Gowlab only):
./run-AppLab-server
The AppLab server is a Java application that does all the communication with the underlying analysis tools. It is now almost a legacy application - all the details (which usually you do not need to know, hopefully) are in the AppLab pages. Here I will explain only the most visible or relevant pieces:
- The AppLab server is accessible using a CORBA interface. You do not need to know anything about CORBA - this is just a hidden implementation detail (which may even disappear in the future). The Soaplab server (which is a servlet running in the Tomcat/Axis engine, and which is described below) knows how to interact with the AppLab server.
- Start the AppLab server in a separate window, or start it in the background. At the beginning, there will be a lot of messages (one message per tool). The last one says Factory AppLabFactory activated. which indicates that the server was started successfully.
  Unfortunately, there is no decent way how to stop the server. If the terminal where it was started is still open a simple CTRL-C will kill the server. But normally you need to find server's PID and kill it. Note that the server's command-line looks like java -Dcfg=Server.cfg -mx256m Server Applications.xml.
- During its life time, the AppLab server writes into a log file AppLabServer.log (which is worth to check time to time, or even rotate if it is too big), and it populates subdirectory "a" with the result data. The result data can be removed when they are too old by a cron job (not included in the distribution). Make sure that the user who runs the AppLab server has a write permission to logfile and "a" subdirectory.
- The AppLab server uses its own configuration file Server.cfg. This file was updated during the installation and usually does not need any changes. But it may be useful to look at it if you need to make some site-specific customization (for example to change the port number where the AppLab server is listening - useful when you have more AppLab servers running, perhaps one with the EMBOSS set of tools and one with other tools). It is also worth to check this file if you face some troubles with starting the server - you may find there some inconsistencies.
- How do all the clients (which includes a Soaplab server itself) know where is an AppLab server running?
  By default, the AppLab server - when started - creates files in subdirectories IOR. Then the Soaplab server will use the file IOR/AppLabFactory.ref to communicate with the AppLab server. By default, it assumes that the file is available within the same file system where Soaplab itself is running on - but this does not need to be so. It is easy to run AppLab server on one computer and your Tomcat/Axis/Soaplab on a different one. Read more about it below.
- Last but not least, the AppLab server uses a launcher to invoke the analysis tools. The launcher is actually a set of Perl scripts, all of them located in the run subdirectory. You do not need to do anything with them - I am just mentioning it here because it may be of your interest if you wish to apply some site-specific properties. For example, if you wish to run analysis tools in a queuing system like LSF you will need to change the launcher (and btw, there is already a LSF-based launcher available - see the script run/LSFLauncher for inspiration).
Important note: The AppLab server will make available tools defined in the file metadata/Applications.xml. After a fresh download and unless you changed something this file will have just few testing applications included (such as helloworld). Later in this description you will find how to add your own analysis tools into this file. Remember when you do it, you need always to restart the AppLab server (otherwise it would not recognize the newly added tools.)


	Activate Soaplab server

Activate your Soaplab server (Web Services).
This step can be tricky because it includes many things: moving Soaplab classes into the Tomcat/Axis, creating service descriptors (files *.wsdd), etc. But don't be depressed, there is a Soaplab admin client, AAdmin, that can do everything for you. And there is a script ws/deploy-web-services that knows what has to be done and it uses AAdmin to do it.
Anyway, let me give you some background what is going to happen. It may be useful for those who are using a different servlet engine, or who wish to customize AppLab-Soaplab relationship.
- Soaplab knows which AppLab server to use by checking file IOR/AppLabFactory.ref. By default it uses the following URL to access the file: file:<installation-directory>/IOR/AppLabFactory.ref. However, if you wish to run AppLab server and Tomcat server (which has the Soaplab classes inside) on two different machines, change the URL in ws/deploy-web-services script to something like http://another.hostname/my-applab-ior/AppLabFactory.ref. Make sure that this URL points to the file created by AppLab on the computer where you started AppLab, and that's it.
- Another interesting issue are the derived services.
  Each analysis tool can be accessed as two different Web Services. One uses a loosely defined data types, one is type-strong. You can read more about derived services in the architecture overview .
  The script ws/deploy-web-services will also automatically create, compile and deploy derived services mirroring all your "normal" (loosely-typed) services.
Now, you are ready to activate your Soaplab server:
1. Optionally, you can set a mySQL database to keep the results of your applications even after some of the servers (AppLab or Tomcat) have to be restarted.
  The database can be created with the SQL script ws/soaplabCreate.sql. This script is not a shell script that can be started form your terminal window. You need to source it from the mysql program, after granting proper privileges to the user that was specified during the Soaplab installation. Here is an example how that can be done:
  Let's assume that you wish to use the user name soaplabuser with the password soaplab is for gods. The database is named soaplab (this name is already hard-coded in the ws/soaplabCreate.sql - change it there if you wish a different name). Now you can type:
```
mysql -u root -p
Enter password: <enter mySQL root password>
mysql> grant all on soaplab.* to soaplabuser@"%"
mysql>       identified by "soaplab is for gods";
mysql> grant all on soaplab.* to soaplabuser@localhost
mysql>       identified by "soaplab is for gods";
mysql> source ws/soaplabCreate.sql
mysql> quit
	       
```
  The access to the database is defined during the installation (remember either an interactive or non-interactive mode with environment variables) - and the relevant values (database URL, username and password) are already stored in the ./ws/deploy-web-services script.
2. Restart (or start) your Tomcat server.
  Remember that every time you restart your AppLab server (for whatever reason), you also need to restart your Tomcat server. Vice-versa, it is not true: you can start the AppLab server once and then restart Tomcat as many times as you need.
3. Deploy all Web Services:
  ./ws/deploy-web-services
  This will deploy both AppLab-based analysis (the "real" analysis represented by command-line programs, and internally accessed by an AppLab CORBA server) and Gowlab-based services (representing web resources somewhere in the world).
  You may be more specific and deploy only one group. For AppLab-services, type:
  ./ws/deploy-web-services -a
  For Gowlab-services, type:
  ./ws/deploy-web-services -g
  During the script execution you may be asked to restart your Tomcat once or twice. After, you may check them by a Web browser (e.g. http://localhost:8080/axis, but the exact URL depends on your installation, precisely on the port number where Tomcat is listening, and on the place where Axis is installed within Tomcat).
  This script deploys also derived services that come with the Soaplab binary distribution (and that are here more or less for testing purposes). If you wish, however, to deploy your own services (which is an ultimate goal, of course), the script offers more options. Read about them in the How to add new tools.
  The deployment is a very crucial step - and if it goes wrong it may be for many reasons. Mostly the Tomcat compatibility issue may be the culprit, but perhaps something else. Please post me your problems so I can fill the FAQ pages.
4. The Soaplab server will create and update logfile soaplab.log. Again, make sure that the user who runs the Tomcat server has a write permission to create and update this logfile.

Important note: The just described deployment will make available services whose metadata were distributed (which means only few test services). Later in this description you will find how to add your own analysis tools and how to deploy them. For that you will use almost the same procedure.

Check your installation

Check that everything is okay.
At this moment, you should have an AppLab server running, a Tomcat server running, and possibly a web server configured in order to know about your alweb scripts. Let's check that everything is running and talking to each other:
1. Check AppLab server:
  1. ./corba/run-AppLab-list
    This talks directly to the AppLab server and should return list of available analysis tools (you do not see here, however, any derived services - they are only on the Soaplab level).
  2. ./corba/run-AppLab-GUI
    This is a standalone Java application accessing individual analysis tools. Ignore options for a Naming Service - this distribution does not use neither bring any Naming Service.
  3. And there are other (direct, CORBA-based) clients - just look into subdirectory corba.
2. Check Tomcat server - open in your browser Tomcat's welcome page. The default URL is http://localhost:8080 but you may use something else.
3. Check Axis installation within your Tomcat - open in your browser Axis's welcome page. The default URL is http://localhost:8080/axis (again you may use something else).
  Finally, continue from the welcome page to the list of deployed services. You should see there your services.
4. Check your Soaplab services. There are again many prepared clients in the ws subdirectory (and they have its own descriptions inside the scripts, look there). Try at least these:
  1. ./ws/run-factory-client -a
    or, for Gowlab: ./ws/run-factory-client -a -gowlab
    This is a command-line client that talks to a Soaplab server and prints names of all Web Services available from this server. By default, it contacts a Tomcat server running on the localhost on port 8080 with a default path to Apache Axis within it. This can be changed by options -l, -p, and -e.
  2. The most advanced client, allowing to start and control any deployed service and its underlying analysis tool is ./ws/run-analysis-client. Start it with the -help option first. The testing helloworld service (which is by default included in the distribution, so it should be now deployed) can be invoked by typing:
```
./ws/run-analysis-client -name classic.helloworld -w -r
		     
```
    You should get back three results (a report, a detailed_status, and a greeting in the output result.
    For Gowlab, there are also few testing services in the distribution, including yet another helloworld (notice that the service name is now slightly different):
```
./ws/run-analysis-client -name gowlab.helloworld -w -r
		     
```
5. And finally (but not for Gowlab), if you installed it, try alweb CGI-based web interface. Use the URL you entered during the installation (e.g. http://localhost/alweb/. Unfortunately, alweb works only with Netscape/Mozilla now. If there is a pressure on me I can make the fix a higher priority :-).

Binary distribution How to add new analysis tools

Obviously having a helloworld service running is an achievement but not for long. Soon, you will want to add your own programs and make them available as Web services. The steps you are going to do now are indicated in the left part of the architecture picture, below the sweating face.

Quick summary

Details follow but here are two summarizing examples and the steps you need to do:

You want to add an AppLab-based service BigDeal, an Gowlab-based service BestSite, and to replace all services coming with the standard Soaplab distribution (which are anyway just for testing) by these two new services:

Create metadata/bigdeal.acd and metadata/bestsite.acd files
generator/acd2xml -d -l Applications.xml bigdeal
generator/acd2xml -d -l Gowlab.xml bestsite
run-AppLab-server
ws/deploy-web-services -d

You want to add the same services as above to the existing, previously deployed, services:

Create metadata/bigdeal.acd and metadata/bestsite.acd files
generator/acd2xml -d -l MyApp.xml bigdeal
generator/acd2xml -d -l MyGowlab.xml bestsite
run-AppLab-server MyApp.xml
ws/deploy-web-services -d -j bb-services.jar -A MyApp.xml -G 'Gowlab.xml,MyGowlab.xml'

Describe your application

Each application that is to be put in the Soaplab system must have its description (referred to often as metadata). Both Soaplab and AppLab use metadata in an XML format. You may look at the exact DTD for such format but hopefully you do not need to because of two reasons:

The XML is long and not too human readable.
Many useful things are hidden under tags option or style whose concrete contents is not defined in the DTD anyway.

Therefore, there is another way. There is a nice, human readable and human producible format, called ACD. It comes from the EMBOSS but it is flexible and extensible enough that it can be used also for describing non-emboss applications. In order to use this format, you do not need to have EMBOSS installed at all.

ACD files are used only as source for generating XML files, they are not used in the run-time. The API of Soaplab services includes a request for service metadata - this request returns the XML, not ACD. Therefore, you do not need to be concerned about using a non-widely-known file format.

Before describing the format itself here are some general rules how to use it:

If you are creating an ACD description for a Gowlab service, read also the more specific instruction in the Gowlab documentation.
Create a single ACD file for each application you want to deploy. Name it by the application name (but it does not need to be the same as the executable name) in lowercase with a suffix .acd. For example: helloworld.acd (notice that there is no executable helloworld but the acd file can still be named like that).
Put this file in the metadata subdirectory. This is not mandatory but it is the default place where the XML converter (generator) will look for it, so you will not need to use additional parameters later.
Optionally, you may check if the syntax of your ACD file is correct. The XML converter - when used later - will do it anyway but sometimes you may wish to use EMBOSS-specific program acdc to check it independently. For that, however, you need the EMBOSS installed.

Now it is the time to describe how to create an ACD file (and come back here when you are done):

How to write an ACD file

Convert ACD into XML

The purpose of this step is to convert human readable ACD files describing your applications into XML files used in the run-time.

Let's assume that you have an application bigdeal. Once you create its ACD file bigdeal.acd (and put it in metadata/bigdeal.acd) you can type:

generator/acd2xml -d bigdeal

This will create file bigdeal_al.xml (in metadata/<module-name> directory) (the module-name is taken from the category in the ACD file).

You will also need an XML file listing all applications. Such file is used by script run-AppLab-server. Therefore, type rather:

generator/acd2xml -l Applications.xml -d bigdeal

Now, let's tell the same story again but in more details:

The generator (converter) is configurable by editing its configuration file generator/al.Cfg.pl. All default values are usually good enough so you may not need to change anything there. But it is worth to look there and read comments about individual configurable variables. The file is a Perl script so you should follow the Perl syntax when editing it.
The generator has many command-line options which you can see by typing:
generator/acd2xml -h
Probably, the most important ones are:
-l <filename>
A file to be created by the generator. It will contain a list of all analysis (just for your curiosity, its format is defined in AppLabAdmin.dtd). If no path given, it is created in the metadata subdirectory (unless you changed this in generator/al.Cfg.pl, of course).
The recommended filename is Applications.xml. Why recommended? Because this name is already in the run-AppLab-server script so you would not need to edit that script.
The generator has no option to append to this list file. Therefore, either generate XML files for all your analysis using just one generator's invocation, or read about merging services.

analysis-name-1 [analysis-name-2 ...]
The names of analysis tools whose ACD files ought to be converted into XML files. The names can have mixed cases, and they do not have .acd suffixes. Their corresponding ACD files are found by converting these names into lowercase, adding .acd suffixes to the end, and adding metadata path to the beginning.

-a
If there there are no analysis names present on the command-line this option causes that the names are taken from the file whose name is given in the al.Cfg.pl in the variable APPMENU. Here is an example of such menu file:
```
..
PROG Blast
PROG Cap3
PROG Sim4
PROG ESTFetcher
PROG ESTEnsEMBL
PROG HelloWorld
PROG MySort
PROG Sleep
PROG TestForm
PROG TestList
	      
```
You may actually put more such files (comma- or space- separated) in the APPMENU variable.
Obviously, the file contains names of the analysis tools to be converted. If you wish to keep such file (or files) untouched but still ignore some applications, name them in a comma-separated list in the variable DISABLED_APPS in the generator configuration file.
-m <module-name>
A module name where converted applications belong to.
Soaplab arranges applications into groups (called also categories or modules). Each application can have its module defined already in its ACD file. But if not then this command-line option tells what module name to use. And if given neither here there is a default value in al.Cfg.pl in variable MODULE.

The summary - the generator creates:

An XML file listing all applications to be deployed. By default this is the file metadata/Applications.xml.
For each application, it created an XML file in metadata/<module-name>/<application-name>_al.xml.

Finally, few notes regarding Soaplab's sub-projects - AppLab and Gowlab:

The acd2xml generator does not have any special options to distinguish between these two.
Also the resulting XML file listing all applications is the same (okay, it contains some tags, such as ns_name, that are of no interest for Gowlab).
Therefore, it is up to you to decide which analysis are for AppLab and which are for Gowlab, and to create two different XML lists. For example, assuming that you have three ACD files for Gowlab (echo, emblsrs and aloe), and two for AppLab (helloworld, dot), you type:
```
generator/acd2xml -l Gowlab.xml -d echo emblsrc aloe
generator/acd2xml -l Applications.xml -d helloworld dot
       
```
AppLab will take Applications.xml. Why? Because this name is in run-AppLab-server. Of course, you can change the script, even you can use there more names for more XML list files.
Gowlab will take Gowlab.xml. Why? Because this name is used when you deploy the Gowlab factory/list service. You can change this by setting a different name using the option -G when invoking the deployment script ws/deploy-web-services script.

Deploy your applications

This includes several steps, but none of them is new. You are just going to repeat the steps that were described in the installation section above. The difference is that you are not going to run the INSTALL.pl script again. You need to:

Restart (or start) the AppLab server (skip this when using only Gowlab).
Before restarting AppLab make sure that the script run-AppLab-server uses the same file you created by the generator (by default, it is Applications.xml). This can be achieved either permanently by editing the script, or by invoking it with an additional name (or names) on the command line. For example, assuming that you generated a new list file MyApp.xml, and that you still want to use the services defined in the original Applications.xml file, start the AppLab server by:
run-AppLab-server MyApp.xml

Remember also, that every time you restart AppLab you need also to restart Tomcat.
Activate Soaplab for the new applications.
This is done, as before, by calling:
ws/deploy-web-services
The script deploys those Gowlab services listed in file Gowlab.xml, and those AppLab services that are currently running within an AppLab server. But to do everything for your new services (for example, to generate also derived services) you may need to use additional options:

-d
Create derived services.
Note that you do not need this option for services included by default in the Soaplab distribution - those had been already created.

-j <name.jar>
A filename with classes of derived services.
This filename should have extension .jar and it will be used when the -d option is given. It names the resulting jar file with generated derived services. When this file is created it will be copied to your Tomcat directory. Default name is my.derived.jar. The purpose of this option is to be able to add new and new services many times without overwriting the previous ones.
Note that this jar file will be created from all classes that are currently in the derived directory. So, if you want to create several different jar files, you need first manually removed classes that had been generated there before.

-A <filename>
A filename with a list of AppLab-based services.
This file is expected to be in the metadata directory and its default name is Applications.xml. Use this option if you created your own services and - in the acd2xml generator - you named the list file differently.

-G <filename>
A filename with a list of Gowlab-based services.
This file is expected to be in the metadata directory and its default name is Gowlab.xml. Use this option if you created your own services and - in the acd2xml generator - you named the list file differently.
<filename> can also be a comma-separated list of filenames (without any path) if you have added new services in your own XML file, e.g. -G 'Gowlab.xml,MyGowlab.xml'.

-e <service-endpoint>
A base URL (without service name) to your services.
This URL will be used when generating WSDL files for your services. Use it only if it differs from the Tomcat hostname, port number and Axis path in Tomcat as given during the installation.

If you need a finer-grain approach, you need to read help file for the admin client: ws/run-admin-client -h. The script ws/deploy-web-services is a good place where to look for ideas how to use the admin client.
Also, for deploying more services, I would recommend to use Soaplab CVS module that uses Ant with many (perhaps even too many) tasks dealing with every aspects of deploying (see Ant's projecthelp, or a slightly less overcrowded help).
The recommended way is to use Soaplab CVS module and to build a package with new services using target dist-services:
./build.sh dist-services
Then you can use a merging script to add the newly created package to the existing services.
Check your installation.

Merging services

Above, you have just learned how to add new services to the existing ones. It was done by creating an XML list with the new services (examples above use MyApp.xml name) and adding it on the command line of the script that starts AppLab:

run-AppLab-server MyApp.xml

Also you have learned how to deploy new services to your Tomcat using script ws/deploy-web-services with many command-line options.

It works but there is an easier way - that combines all these steps for you, and even conserve them in a file that can be shared with the others. You just need to use Soaplab CVS copy and create a service set.

Having a file with a service set, you can continue here. The binary distribution has a script ws/add-services that merges new services with already installed ones.

The script is actually a wrapper about a "real-one" script ws/add-services.pl. The wrapper was updated during the installation in order to know your local environment. Usually it is enough to type, for example:

ws/add-services InterProScan-2004-04-20.tar.gz

where the file InterProScan-2004-04-20.tar.gz is a package with services to be added.

After merging services from the new package into the current installation it also deploys new services (meaning it lets your local Tomcat know about them).

Usually you do not need to give the script any options (except perhaps -e and -f), but there are some (see directly in the ws/add-services.pl for more):

-e <services-endpoint>: A URL of services endpoint that will be used in the generated WSDLs; if not given, no WSDLs are generated (assuming that the ones coming with the package are already good enough).
-G <filename>: An XML list of existing Gowlab-based services which new services will be merged into. Use this option only if your existing (not the new ones) services are listed in a different file than Gowlab.xml.
-A <filename>: An XML list of existing Applab-based services which new services will be merged into. Use this option only if your existing (not the new ones) services are listed in a different file than Applications.xml.
-f: It forces to overwrite existing jar file with derived services (if such file already exists in Tomcat). You need to use this option if you try to add the same package again.

Finally, just an almost unimportant note: the merging script will automatically prettify the merged XML application list if it can find program tidy on the path. However, it does not complain if such program does not exist.

Where to go next?

I want services wrapping EMBOSS

I want to use my services - tell me about available clients

Martin Senger

Last modified: Wed Jul 27 11:09:36 2005