...
- One WSDL rule them all
- MTOMize only "blue" operations
- MTOMize all MTOMizable operations
- New WSDLs and endpoints for MTOMized version of API
- Routing
Visualization
1.a
& 1.b
...
2.
...
3.
Pros:
- 1.a
- The easiest solution
- The smallest set of operations in the API.
- No need for new endpoints/wsdls
- 1.b
- Consistent (all MTOM operation has "MTOM" in name)
- Still easy
- No need for new endpoints/wsdls
- 2.
- 100% guarantee of backward compatibility
- This method is the best practise, when doing non-backward compatible changes to WS API
- 3.
- The WS endpoints remain the same and can handle all versions of API based on the particular namespace (now the namespace inside the SOAP messages is http://www.fedora.info/definitions/1/0/types/
. I suggest something like http://www.fedora.info/definitions/2011/7/29/types/ (W3C convetion)). - will not break "low lvl clients" i.e. clients that are not generated from wsdl like curl, because the endpoint is still the same and if such "low lvl client" wants to start use new version of WS the only change for him is to change the structure of SOAP by changing the namespace. In the Java/.NET world this is a minor advantage, but if the client is written in, say, bash, it may help.
- The WS endpoints remain the same and can handle all versions of API based on the particular namespace (now the namespace inside the SOAP messages is http://www.fedora.info/definitions/1/0/types/
Cons:
- 1.a
- It is not transparent for the client when calling, say, ingest() whether the request is MTOMized or not, since the server-side can handle both. This will hold also for method ingestMTOM() from solution 1b).
- Not consistent in that sense that not all methods which use MTOM have "MTOM" suffix in their name.
- 1.b
- More operations
- Risk of duplicated code in project
- 2.
- 4x wsdl (2x API-A + 2x API-M) + 4x endpoint
- 3.
- 4x wsdl (2x API-A + 2x API-M) + 6x endpoint