[midPoint] Discussion: future of SOAP in midPoint
radovan.semancik at evolveum.com
Thu Oct 24 15:13:22 UTC 2019
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.)
More information about the midPoint