I Serge,
A late entry for this subject, I know, but I would like to contribute with my 5 cents.
About 2 years ago I had the very same idea to build a FLOW-to-Java service translator, for the simple reason of facilitating the job of making the overall performance of a system improve by translating the FLOW Services to Java correspondents, maintaining the original FLOW ones as ‘sources’.
The main intention was to automate the process and cut-short the translation effort.
The first thing I did was a Proof-of-Value to determine if it was worthwhile… and it wasn’t!
Java services effectively perform better in some specific constructs (such as LOOPs) but the translator would have to incredibly smart to go to the extend of replacing some service calls (e.g., math & string manipulation) to Java constructs and still be runtime compatible with the translated FLOW (e.g., you have to be aware that the management of the pipeline is completely different in FLOW services… and that the USE of SEQUENCEs and calls to other services add to the runtime differences).
I first tried to mimic in a Java pseudo-translation the way FLOW handles pipeline and service calls, and came to the conclusion that the FLOW service engine does a good job there and I would end having very little performance improvements. To really have performance improvements, you need intelligence to understand the logic on a FLOW Service (be aware of language side effects and other ‘tricks’) and translate that logic (not the language steps) to efficient Java logic.
Bottom line, I saw no value in the effort and I dropped the project.
Still, being performance improvement a target, I started a new project to help find bottlenecks and pinpoint services that would benefit from refactoring: a Service Profiler.
It is now a commercial tool and I’m not going to advertise it… but you can quickly find it by entering in the Google Search: webMethods “service profiler”
Regards