[midPoint] Discussion: future of SOAP in midPoint

[Radovan Semancik]

Hello,

MidPoint had SOAP-based web service interface almost since the 
beginning. However, that was almost 10 years ago. Technology fashion 
trends do not favor SOAP any more. The fashion is not a problem for us - 
just by itself. We value functionality and pragmatism much more than 
fashion trends. That is also the reason that SOAP is still there even 
though it is no longer fashionable.

But the SOAP interface in midPoint becomes a technological burden. SOAP 
was never really the Simple Object Access Protocol. The SOAP world was 
quite a wild combination of protocols, data formats, libraries and 
specifications. Some of the code was quite tightly bound with Java 
platform. But the problem is that this suite is falling into disrepair. 
The development for libraries around XML, XSD, SOAP and all those WS-* 
specs is very slow. Some pieces of this puzzle were not touched in 
years. The SOAP ecosystem is under-maintained.

This is causing a problem for midPoint development. We are trying to 
keep all midPoint components up to date. We are upgrading our 
dependencies, we are trying to support new versions of Java platform and 
databases. Overall, we are trying to keep up with the state of the art. 
Having SOAP in the picture is a problem, as the old libraries often make 
upgrades of other components quite complicated. There are often library 
version conflicts that are difficult to resolve. This situation is known 
as "dependency hell". Everybody that has ever gone through this knows 
that this term is quite appropriate.

This was also the reason behind one of the questions in our survey. The 
survey is still in progress, but we are getting some interesting data 
already. Vast majority of responses is in favor of removing SOAP support 
in midPoint. In fact there is just one response that asks to keep our 
existing SOAP interface. So far so good. But there are few important 
responses that suggest that we should have the possibility to create 
custom SOAP interface in midPoint, e.g. in a form of an overlay project. 
And this is a very valid concern. Therefore I would like to initiate a 
discussion on this topic.

My initial (wishful) thinking was that we can remove Apache CXF from 
midPoint together with all the old Sun XML library baggage. We already 
have our own alternative for JAX-B. And with removal of CXF we can 
pretty much get rid of all the old JAX-* stuff. However, if we still 
need the ability to create custom SOAP interfaces, removing CXF from 
midPoint core will not really solve anything. We will still need to keep 
midPoint dependency versions in check because we will need the ability 
to add CXF in the overlay. Which will be even more painful as it will 
just complicate the testing.

Therefore I would ask those of you that need custom SOAP serverices, 
what are your options? Could you switch to custom REST services instead? 
Or could you use Spring-WS (https://spring.io/projects/spring-ws) 
instead of Apache CXF? Or do you have a different idea? Any thoughts?

This is an important decision and we will need to make it quite soon. 
Therefore any input on this is more than appreciated.
(You can respond to me directly if you do not want to respond to the 
list because you would expose some sensitive data about your environment.)

Thank you.

-- 
Radovan Semancik
Software Architect
evolveum.com