Yes, it is a custom service performing all those steps. It is not Java. It is a FLOW service.
There will always be a “new” and “better” markup language. Don’t be too concerned about that. Use a format for your config files that makes sense for your environment/team. Properties are fine. JSON is fine. XML is fine. .ini files are fine. Storing in a DB is fine. For any of them the concept is the same: store the settings in a file/table(s), load them into an IS document to be used. From a service perspective that uses the config in the IS document, it does not know nor care what the underlying storage format is.
Again, lot’s of things to criticize about XML. Age and “retro” should not be one of them. 
The primary suggestion I have regarding external libraries – be very conservative. Don’t try to use wM IS the same way you would code/use JBoss, WLS, WAS, etc. The run-time environment is Java but this is not a Java development platform. One can “drop down” to Java to create focused utility methods but it is not intended for “significant” Java development. Do that elsewhere if it is needed. Don’t try to load all the typical libraries used when creating typical Java apps. If you keep trying to use wM IS in the same way you do Java app development, you’re going to be disappointed and frustrated.
Review the About page in IS Administrator. You may be pleasantly surprised that the library you want to use is already present. Here is a short list of ours from 10.5 (trimmed to show just the significant part of the end of the path):
common/lib/ext/commons-beanutils.jar
common/lib/ext/commons-codec.jar
common/lib/ext/commons-collections.jar
common/lib/ext/commons-digester.jar
common/lib/ext/commons-discovery.jar
common/lib/ext/commons-fileupload.jar
common/lib/ext/commons-httpclient.jar
common/lib/ext/commons-io.jar
common/lib/ext/commons-jexl3.jar
common/lib/ext/commons-lang.jar
common/lib/ext/commons-lang3.jar
common/lib/ext/commons-logging.jar
common/lib/ext/jackson-annotations.jar
common/lib/ext/jackson-core.jar
common/lib/ext/jackson-databind.jar
common/lib/ext/jackson-dataformat-yaml.jar
common/lib/ext/spring-core.jar
common/lib/ext/swagger-annotations.jar
common/lib/ext/swagger-core.jar
common/lib/ext/swagger-models.jar
common/lib/ext/swagger-parser.jar
That said, there are times when libraries are needed. You’ll want to get the minimum necessary (ideally, 1 for a given function/need) to limit the potentially tedious work of importing a pile of dependencies. If you find a deep list of dependencies that end up “importing the world” you’ll likely want to look for another library with less baggage.
The number of third-party JARs we’ve used over the years is like 2. One for SSH (which has been mostly replaced by built-in facilities for SFTP now) and one for PGP encryption (BouncyCastle – which is also now part of the core set of libs). We considered adding Jackson at some point but decided against it – and now it is part of the core list too. Often times there are useful functions available in Apache Commons. But more often than not, the relatively narrow function we wanted required “import the world” so we either looked elsewhere or created our own using Apache code as a guide. And as can be seen in the above abbreviated list, many of them are now included.
Be cautious here. This indicates a potential mismatch of how to use wM IS as an integration tool (not an app dev tool) vs how Java development is done. Referencing an old post again that cautions about being too Java-focused.