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 axis1deployThe 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.
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.
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 supperNow 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_sequenceOn the second thought, we may add some code that could accept also the old names. Any need for it?