Not even a contest with webMethods IS. Flow is designed ground up for mapping and is an extremely fast and productive environment for doing that.
Sounds like you are thinking from an RPC world, try thinking from a messaging world. Data aggregation becomes just message building with each service just doing their thing without knowledge of the other services and yes the webMethods platform of products does this very well. But a J2EE based system could do it as well. I threw J2EE out for you because it sounded like you like to do things harder than they need to be.
IMHO good architecture and good systems are simple and easy to maintain/support. The webMethods platform is a very good host of all kinds of Web Services. It is simple and highly productive to develop in. I’ve done both J2EE and webMethods IS and there really isn’t any comparison when it comes to developer productivity and maintainability.
I have found that developers as well as architects that come from either a hardcore J2EE or .Net background have a very difficult time with the concept of webMethods. It requires a different way of thinking about constructing applications.
That being said there is no reason why you can’t segment your Web Services as you have suggested. There is no right answer. I haven’t found a compeling reason to have a J2EE application server but you might and that’s okay. That’s the great thing about the concept of services.