Not sure I understand what you mean by the “copy” operation, but I can weigh in with an opinion on the last question.
-
For the most part, Flow is easier to write and maintain than Java - at least to folks who don’t have significant Java experience. Since not all developers on a webM project will have strong Java skills, writing services in Flow allows for faster TTM and easier long-term maintenance (since more can maintain it). I can also teach someone to code good Flow faster than I can teach them to code good Java.
-
Debugging tools in the Developer are focused on Flow, making it easier to troubleshoot than Java services. No trace or step for Java in the Developer, so you have to use external tools.
However, sometimes Java is more appropriate than Flow. I try to follow two simple rules:
Rule 1) try to write it in Flow first, then write it in Java if Flow can’t do it, or the performance of the Flow service is terrible (and that performance is due to the flow code behavior, not to some external cause)
Rule 2) if you write it in Java, keep it simple. If you have three things you need to achieve, that’s three small simple services, not one big one. If you are modifying a string in a document, set your input to be just the string and use flow to get the string out of the document, then pass it to your Java service. This keeps your Java pipeline and logic code cleaner and simpler.
Keep in mind these are just my rules, not defined best practices from SAG PS. 
#webMethods#Flow-and-Java-services#Integration-Server-and-ESB