Some inputs:
As for “sufficiently skilled in Flow”, the opposite is meant to be true. Its meant to be easier to learn and use Flow than to possess strong Eclipse, Spring, and Ant skills, etc. If you have strong Java skills but feel less comfortable in Flow, perhaps its a matter of spending a little more time getting acquainted with Flow programming.
The same issue of ‘small changes breaking a program’ exists for other programming languages. The only way to combat this is having an automated regression test framework. I prefer manually unit testing Flow services, with the regression framework testing higher-level services (what folks call system or integration testing).
Absolutely - you need to be a programmer to be a Flow programmer. However, Flow programming’s primary benefit is ease of coding and ease of debugging – delivered by these mechanisms:
-
Coding: Flow programs display stack variable structures at both design time and run-time. In contrast, the Java IDE debuggers graphically display data structures (and their values) only at run time .
-
Debugging – The webMethods save/restorePipeline services are pretty powerful tools. The Java equivalent would be a static method that serialized all current stack variables into a file. This would not too difficult to write. Some years ago, I recall reading about a test framework (a Java one I think). When invoked by a production exception handler, a method call would serialize the stack variables into a file, and generate a unit testcase (with the serialized stack attached) to replicate the bug on a QA environment.
To be sure, there are disadvantages to Flow - lack of diff/merge tools, lackluster refactoring support. Also, webMethods have not focused on adding features to their development environment as they should have. (Imagine multi-point/multi-touch support for Flow programming… it’d halve the time it took to map major data structures).