%----%>
<%--<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>--%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>
<%@ taglib uri="http://displaytag.sf.net" prefix="dt" %>
This page is for anyone who wants to add a new webservice into the JABAWS framework.
Data Model JavaDoc - read this if your are coding against JABA Web Services
Complete JavaDoc - for developers who want to use JABAWS framework and use Engines and Executables directly
Publicly available Git repository: http://source.jalview.org/gitweb/?p=jabaws.git;a=summary
Another publicly available JABAWS repository, containing the code for each JABAWS public release, is located at jabaws.googlecode.com
The repositories contain a complete JABAWS Eclipse project.
Of course if you want to make a modification to the source code you would need to
generate distributives yourself. To do that, first generate JAX-WS artifacts using
Each source folder depends on the upper folders for compilation. For example, the datamodel is the top level folder so it has no other dependencies on other JABAWS code. The Engine level depends on the datamodel to compile etc. The web services folder is the bottom layer and depends on all the other source code.
So the JABAWS project is split into 4 layers. From bottom-up the first layer consists from the value classes used by all other layers of the hierarchy, in particular web services. So, to be able to use JABAWS one needs to have these classes. At the same time classes on this layer does not have any dependencies on the layers above.
The second layer contains code for execution of the wrappers, which are the abstraction describing native executables. JABAWS can execute tasks locally that is on the same machine as JVM and on the cluster. Thus currently code on this layer contain two engines. This layer depends on the layer underneath, the data model layer, but is completely independent from the code above.
The third layer consists of the wrappers for the native executables and classes to handle their configuration. It depends on the engines and the data model, but know nothing about the web services.
Finally, the upper layer contains the web services, that depend on all the layers below.
The layer isolation is archived though specially designed compilation task which is executed sequentially in several stages so that the first layer compiles before any other layers, second layer compiles after that and process continies before all the code is compiled. Any violation of the layer boundaries results in the compilation failure. Use Ant "Compile" or "Complile_with_debug" tasks to perform the staged compilation.
A client package contains only classes from data model layer and a simple web services client. Framework package is for anyone who want to use JABAWS framework for controlling native executables in local or cluster environments. Framework exclude the web services layer. Server package contains all the code.
JABAWS uses TestNG framework for testing. The test results for the JABAWS
package offered for download can be found at:
Test Results
JABAWS uses TestNG
for testing. There is a TestNG plugin available for Eclipse
which has functionality similar to JUnit. However, no plugins are
necessary to run the test cases, as testng jar is supplied
with JABAWS together with an ant tasks to run the test cases.
The best way to ensure that JABAWS framework is completely functional on your system is to run all test cases. Test cases tests all aspects of JABAWS functionality. Consequently, one need to have non windows operation system and support of the cluster to be able to run all tests. If your system does not support cluster, then you could run all test excluding those that depends on the cluster.
Several testing groups are supported:
To run the tests you need to download all sources from repository. Once you have done that, enter into the command line mode, change directory to the project directory and type:
ant -f build.xml <test group name>
Make sure you have Apache Ant installed and path to ant executable is defined in your path environmental variable. Replace test group name with the one of the names given in the list above to run required group of tests e.g for running cluster only tests use the following command:
ant -f build.xml Run_cluster_dependent_test
If you work under Linux you could use a simple script from the root folder of repository called
A handy feature of TestNG is its ability to re-run failed tests. Failed test
ant file is stored in
ant -f build.xml Rerun_failed_tests
CustomTest runs the test defined in the project root directory file called
For cluster execution make sure that the property LD_LIBRARY_PATH defined in build.xml points to cluster engine LD libraries directory in your local system.
There are a number of ant tasks aimed for preparing distributives for download. Currently a few types of JABAWS packages are offered:
Corresponding build task names are:
The easiest way to build all distributives is to call
If you made any changes to the data model and would like to generate a complete JABAWS distro make sure you have rebuilt jaxws artifact as described below.
Server side artifacts should be rebuild whenever the data model, meta model or MSA
interface were changed.
To do that run build-server task from wsbuild.xml ant build file. WSDL files will
be generated in
Add a new executable which you'd like to wrap as a JABAWS web service to the binaries folder.
If it has the source code and can be recompiled for different platforms include it under
Make sure that all the dependencies of the software being installed are satisfied.
If there are other binaries they should be included as well. Keep the dependent
binaries in a subfolder for the main executable. Update
Make sure that the new executable does not have any hard links to its dependencies, e.g. is able to run from any installation folder and does not contain any hard coded paths.
Describe executable in
Describe the executable supported parameters in the
Create a Java wrapper class for your executable. Create it within
Create a testcase suit for your wrapper in
Create parser for the output files of your executable. Suggested location compbio.data.sequence.SequenceUtil .
Test the parser.
Decide which web services interfaces your executable is going to match. For example if the executable output can be represented as SequenceAnnotation then SequenceAnnotation interface might be appropriate. For multiple sequence alignment an Msa interface should be used.
If you find a web interface that matches your returning data type, then implement a web service which confirms to it within a webservices source folder.
Register web service in
Add generated wsdl to wsbuild.xml ant script to generate the stubs.
Run build-server task in wsbuild file. Watch for errors. If the task fails that means that JAXB cannot serialize some of your new data structures. Add appropriate annotations to your data types. Also check that:
If you have the data on the server side, but nothing is coming through to the client, this is a JAXB serialization problem. They tend to be very silent and thus hard to debug. Check your data structure can be serialized!
Modify the client to work with your new web service. Update Services enumeration to include new service and ensure that all the methods of this enumeration take into account the new service. Update the client help text (client_help.txt) and insert it into the Constraints class.
Test the web service with the client.
Test on the cluster.