We would like to announce our intent to deprecate the FTS3 SOAP API.
The SOAP API was initially in the project mainly to keep backwards compatibility towards the gLite FTS clients, and for quite some time they haven't been supported anymore.
The reasons for this deprecation are:
- It is hard to extend. Any new features may require even the addition of new calls, depending on the original WSDL definitions.
- It runs on the FTS3 core process, which also schedules and runs the transfers. Bugs and inestabilities in a user-facing code can potentially cause a crash on the service.
- Experiments that have migrated fully to FTS3, and using its new features, have done so talking directly to the REST API, so it is a waste of resources to keep two entry points.
We will, of course, keep support for the command line tools, except the configuration ones. They are already partially able to talk REST, and they will become fully REST compliant soon. Additionally, to make things easier, it won't be even be necessary to manually use the switch "--rest". The CLI will be able to figure it out by itself.
- Beginning of 1Q 2016
- Fully implement all the functionality for fts-transfer-* and fts-delegation-init in REST (FTS-286), and remove the need for "--rest"
- Print a warning when SOAP is used, but keep working
- Print a deprecation warning for the SOAP Python bindings (FTS-285, DONE)
- Document alternatives for the fts-config family (FTS-387, DONE)
- Beginning of 3Q 2016
- Remove SOAP support from the new clients
- Remove the SOAP Python bindings
- Q1 2017
- Remove SOAP support from the server side
Please, mind the timing is just a proposal and can be moved.
Actions to be taken by the users and experiments
- If you are using the REST API directly, you don't need to worry
- If you are using the CLI, as soon as FTS-286 is released, switch from port :8443 to :8446 (the CLI will remind you to do so)
- If you are using the gLite clients, move to the FTS3 clients or use the REST interface directly
Actions to be taken by system administrators and users with configuration rights
We intend to stop supporting fts-config and family, since they are seldom used, and only by a handful of people.
Everything you can do with them, you can already achieve using directly REST. We have an equivalence guide between the config CLI and the REST API.
Do not hesitate to let us know if you miss something in the documentation, or if the lack of configuration CLI can cause a big trouble.