There’s one quite naive argument that sometimes determines the technology choice. I want to write about it because this argument I’ve been hearing on and off for years. It’s about favouring XML to avoid recompilation.
I remember in the late days of EJB2, one of the selling points of Spring was that you can reconfigure the wiring of your beans without recompilation. At that time I was quite enthusiastic about this feature… even though the argument was almost completely negligible.
My friend said today:
“Another advantage [of XML workflow] is you can do some modification to the flow without recompiling the whole app”
It’s true that you don’t need to recompile. However, if you want fully implement the change to the XML workflow you probably still have to:
- run tests
- validate the app works
- check-in the change to your VCS (new revision created)
- make sure the integration build on newly created revision works OK
- validate the application (built with the new revision) works on the integration box
In most cases, updating XML by hand on the integration/prod box is not practical. Don’t fall for the ‘no recompilation’ argument because it is negligable. Usually you still need a build & QA cycle.
This post is not intended to claim that XML is bad for you (although I probably agree with that statement =)). This post claims that ‘no recompilation’ argument is void.
Nevertheless, If I have to use a workflow in my java app it will declared in java and not in xml. I’m great fan of fluent, type-safe & intellisense-ready configurations!