Compatibility with Soaplab1

Soaplab2 is not that different from the previous Soaplab. Internally, it is almost fully re-written but the main functionality remains. Still, there are some changes.

Backwards compatibility
What is different

Backwards compatibility

Why do we bother?

Mainly because of the Taverna users. There may be some good workflows that will be still using the Soaplab1 servers, definitely for some time. The backwards compatibility allows the service provider to use the new Soaplab2 code, but still be compatible with these old workflows.

In order to remain backwards compatible, the service provider has to deploy her services using axis1 protocol (details in the deployment guide):

ant axis1deploy

The Soaplab2 distribution includes a workflow example that was successfully used with Soaplab2. It uses EMBOSS and points to a server at http://localhost:8080 (so you can use it to test your Soaplab2 installation if you have also EMBOSS installed).

The only change needed in the workflow was a new name of few sequence parameters (see details below) - but these parameters are not used often so it hopefully do not break too many workflows.

What is different

Here are the changes that do not break anything. Simply speaking, the Soaplab2 interface is a bit richer but if you do not need to use the new richness you do not see any difference:

In the Analysis interface (an interface representing any Soaplab2 service), there is a new method getResultsInfo().
In the same interface, several time-characteristics methods were removed (getCreated(), getStarted(), getEnded(), getElapsed()). The same information is still available in the old method getCharacteristics().
This removal does not mean that you need to change your code if you use the old methods. The Soaplab2 - its axis1 layer - makes these methods for you on-the-fly.
In the same interface, all methods using java.util.Map structure are using now a new, more specific, structure SoaplabMap. Again, your code does not need to be changed, the Soaplab2 in the axis1 mode will provide the old Maps.
In the AnalysisList interface (an interface representing a list of Soaplab2 services provided by your server), there is a new method getAvailableAnalysesWithDescription(). This method allows to get all short descriptions without calling all services individually.
The major (but hidden) change is that Soaplab2 uses also other protocols, by default SOAP/HTTP with the document/literal flavour.

And there are few changes that can break clients code. But we believe that most clients never used these Soaplab corners so not many will be broken. Sorry for any inconvenience if you are the one with the broken heart.

The service metadata DTD has not changed - but the XML files returned by the Analysis.describe() method may have some options missing and some new added. This should affect only those parsing directly the XML file. Those using the getInputSpec(), getResultSpec(), getAnalysisType() methods should not be affected.
The EMBOSS names for so-called associated qualifiers changed. This change definitely affects those programs and workflows that are using parameters such as sbegin and send.
The new names are now created by putting together their old name and the name of the parameter they are associated with. For example, the edit.seqret service had before these input names:
```
feature
firstonly
osformat
sbegin
send
sequence_direct_data
sequence_usa
sformat
slower
snucleotide
sprotein
sreverse
supper
```
Now it has these (the bold font is used to mark the difference):
```
feature
firstonly
osformat_outseq
sbegin_sequence
send_sequence
sequence_direct_data
sequence_usa
sformat_sequence
slower_sequence
snucleotide_sequence
sprotein_sequence
sreverse_sequence
supper_sequence
```
On the second thought, we may add some code that could accept also the old names. Any need for it?

Last modified: Mon Feb 4 17:28:07 2008