-<li> 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 \r
- recompiled for different platforms include it under binaries/src.\r
- Edit binaries/src setexecutableflag.sh and compilebin.sh scripts accordingly. </li>\r
-<li> Make sure that all the dependencies of the software being installed are satisfied. \r
- If there are other binaries they should be included as well. Keep the dependent \r
- binaries in subfolder for the main executable. Update compilebin and setexecflag </li>\r
- scripts accordingly.<li> Make sure that the new executable </li>\r
- does not have any hard links to its dependencies, e.g. is able to run from \r
- any installation folder and does not contain any hard coded paths. \r
- <li> Describe executable in conf/Exectuable.properties file. The lowercase name of the \r
- wrapper should be included in the name of the property for example Clustal \r
- properties all include clustal as a part of the name e.g. local.clustalw.bin.\r
- The same property for Mafft will be called local.mafft.bin. For more help please refer to the Executable.properties file. </li>\r
- <li> Describe the executable supported parameters in the <ExecutableName>Parameters.xml, presets in the <ExecutableName>Presets.xml and the execution limits in the <ExecutableName>Limit.xml. By convention these files are stored in conf/settings. All of these are optional. If the \r
- executable does not support parameters you do not have to mention the \r
- XXXParameter.xml file in the Executable.properties file at all. The same is true for \r
- Presets and Limits. </li>\r
-<li> Create a Java wrapper class for your executable. Create it within runner \r
- source directory. Examples of other wrappers can be found in compbio.runner.msa \r
- or compbio.runner.disorder packages. Wrapper should extend SkeletalExecutable<T> \r
- implements PipedExecutable<T> if you need to pass the input or collect the \r
- results from the standard in/out. Please see Mafft code as example. Wrapper \r
- should expend SkeletalExecutable<T> if input/output can be set as a parameter \r
- for an executable. Please see ClustalW code as example. </li>\r
-<li> Create a testcase suit for your wrapper and run the test cases. </li>\r
-<li> Create parser for the output files of your executable. Suggested location \r
- compbio.data.sequence.SequenceUtil </li>\r
-<li> Test the parser</li>\r
-<li> Decide which web services interfaces your executable is going to match. \r
- For example if the executable output can be represented as <br />\r
- SequenceAnnotation then SequenceAnnotation interface might be appropriate. \r
- For multiple sequence alignment an Msa interface should be used. </li>\r
-<li> If you find a web interface that matches your returning data type, then \r
- implement a web service which confirms to it within a webservices source folder. </li>\r
-<li> Register web service in WEB-INF/ web.xml and sun-jaxws.xml</li>\r
-<li> Add generated wsdl to wsbuild.xml ant script to generate the stubs.</li>\r
-<li> Run build-server task in wsbuild file. Watch for errors. If the task fails <br />\r
- that means that JAXB cannot serialize some of your new data structures. Add <br />\r
- appropriate annotations to your data types.\r
- Also check that <br />\r
- - you do not have interfaces to serialize. JAXB cannot serialize them.<br />\r
- - you have a default no args constructor (can be private if you do not need it)<br />\r
- - JAXB cannot serialize a Map, use custom data structure instead!<br />\r
- - Enum cannot be serialized as its abstract class (do not confuse with enum <br />\r
- which is fine)<br />\r
- - Fields serialization leave a little more space for manoeuvre, so use it. If <br />\r
- you do then you can accept and return interfaces, e.g. List, Map; abstract <br />\r
- classes etc, from your methods. <br />\r
- <br />\r
- If you have the data on the server side, but nothing is coming through to the <br />\r
- client, this is a JAXB serialization problem. They tend to be very silent and <br />\r
- thus hard to debug. Check your data structure can be serialized! </li>\r
-<li>Modify the client to work with your new web service. Update Services \r
- enumeration to include new service and ensure that all the methods of this \r
- enumeration take into account the new service. Update the client help text \r
- (client_help.txt) and insert it into the Constraints class. </li>\r
-<li> Test the web service with the client </li>\r
-<li> Test on the cluster.</li>\r
+ <li> \r
+ <p>Add a new executable which you'd like to wrap as a JABAWS web service to the binaries folder. \r
+ If it has the source code and can be recompiled for different platforms include it under \r
+ <span class="hightlight">binaries/src</span>. Edit <span class="hightlight">setexecutableflag.sh</span> \r
+ and <span class="hightlight">compilebin.sh</span> scripts in <span class="hightlight">binaries/src</span> \r
+ accordingly.</p>\r
+ </li><li>\r
+ <p>Make sure that all the dependencies of the software being installed are satisfied. \r
+ If there are other binaries they should be included as well. Keep the dependent \r
+ binaries in a subfolder for the main executable. Update \r
+ <span class="hightlight">compilebin.sh</span> and <span class="hightlight">setexecflag.sh</span> scripts accordingly.</p>\r
+ </li><li>\r
+ <p>Make sure that the new executable does not have any hard links to its dependencies, e.g. is able to run from \r
+ any installation folder and does not contain any hard coded paths.</p>\r
+ </li><li>\r
+ <p>Describe executable in <span class="hightlight">conf/Exectuable.properties</span> file. The lowercase name of the wrapper should be included \r
+ in the name of the property for example Clustal properties all include clustal as a part of the name e.g. local.clustalw.bin.\r
+ The same property for MAFFT will be called local.mafft.bin. For more help please refer to the Executable.properties file.</p>\r
+ </li><li>\r
+ <p>Describe the executable supported parameters in the \r
+ <span class="hightlight"><ExecutableName>Parameters.xml</span>, presets in the \r
+ <span class="hightlight"><ExecutableName>Presets.xml</span> and the execution limits in the \r
+ <span class="hightlight"><ExecutableName>Limit.xml</span>. By convention these files are stored \r
+ in <span class="hightlight">conf/settings</span>. All of these are optional. If the executable \r
+ does not support parameters you do not have to mention the <span class="hightlight">XXXParameter.xml</span> file \r
+ in the <span class="hightlight">Executable.properties</span> file at all. The same is true for \r
+ Presets and Limits.</p>\r
+ </li><li>\r
+ <p>Create a Java wrapper class for your executable. Create it within <span class="hightlight">runner</span> source directory. \r
+ Examples of other wrappers can be found in <span class="hightlight">compbio.runner.msa</span> or \r
+ in other <span class="hightlight">compbio.runner.*</span> packages. Wrapper should extend \r
+ <span class="hightlight">SkeletalExecutable<T></span> and implement \r
+ <span class="hightlight">PipedExecutable<T></span> \r
+ if you need to pass the input or collect the results from the standard in/out. Please see Mafft \r
+ code as example. Wrapper should expend <span class="hightlight">SkeletalExecutable<T></span> \r
+ if input/output can be set as a parameter for an executable. Please see the ClustalW code as example.</p>\r
+ </li><li>\r
+ <p>Create a testcase suit for your wrapper in <span class="hightlight">testsrc</span> and run the test cases.</p>\r
+ </li><li>\r
+ <p>Create parser for the output files of your executable. Suggested location \r
+ compbio.data.sequence.SequenceUtil . </p>\r
+ </li><li>\r
+ <p>Test the parser.</p>\r
+ </li><li>\r
+ <p>Decide which web services interfaces your executable is going to match. For example \r
+ if the executable output can be represented as SequenceAnnotation then SequenceAnnotation \r
+ interface might be appropriate. For multiple sequence alignment an Msa interface should be used.</p>\r
+ </li><li>\r
+ <p>If you find a web interface that matches your returning data type, then \r
+ implement a web service which confirms to it within a webservices source folder. </p>\r
+ </li><li> \r
+ <p>Register web service in <span class="hightlight">WEB-INF/web.xml</span> \r
+ and <span class="hightlight">WEB-INF/sun-jaxws.xml</span> .</p>\r
+ </li><li> \r
+ <p>Add generated wsdl to wsbuild.xml ant script to generate the stubs.</p>\r
+ </li><li>\r
+ <p>Run build-server task in wsbuild file. Watch for errors. If the task fails that means \r
+ that JAXB cannot serialize some of your new data structures. Add appropriate annotations to your data types.\r
+ Also check that: </p>\r
+ <ul>\r
+ <li>you do not have interfaces to serialize, since JAXB cannot serialize them</li>\r
+ <li>you have a default no args constructor (can be private if you do not need it)</li>\r
+ <li>JAXB cannot serialize Java Map class, use a custom data structure instead</li>\r
+ <li>Enum cannot be serialized as its abstract class (do not confuse with enum which is fine)</li>\r
+ <li> Fields serialization leaves a little more space for manoeuvre. \r
+ If you do this then you may accept<br/> and return interfaces, e.g. List, Map; abstract classes etc, from your methods\r
+ </li>\r
+ </ul>\r
+ <p>If you have the data on the server side, but nothing is coming through to the \r
+ client, this is a JAXB serialization problem. They tend to be very silent and \r
+ thus hard to debug. Check your data structure can be serialized!</p>\r
+ </li><li>\r
+ <p>Modify the client to work with your new web service. Update Services \r
+ enumeration to include new service and ensure that all the methods of this \r
+ enumeration take into account the new service. Update the client help text \r
+ (client_help.txt) and insert it into the Constraints class.</p>\r
+ </li><li>\r
+ <p>Test the web service with the client.</p>\r
+ </li><li> \r
+ <p>Test on the cluster.</p>\r
+ </li>\r