Hi Paolo,
first of all thanks a lot for the feedback / followup.
I've been reading the post from Duncan and thinking about this topic a bit. The sample mentioned there is interesting, I can ofcourse see few "issues" from a WS point of view that could be possibly addressed using Wise, as you noticed. Among them, I would probably mention the direct usage of JAXB, the need of compile time defined mappers for the request/response and the need for in advance generation of stubs (the request / response type classes). Moreover such an approach would probably work for DOC/Lit contracts only. Using Wise you could avoid manually generating / writing the req/res classes (the tool would internally do that) and you could navigate the Wise model (see WSMethod, WSEndpoint, WSService, WebParameter) and finally use reflection on the Type linked in WebParameter instances to dynamically build up request parameter map to perform the invocation with.
That might not be super-easy for complex scenarios though (while it would definitely be quite easy for the simple example mentioned in the Duncan's example, it's just a string parameter there). So, you might want to use a Smooks based approach. The Wise core testsuite comes with an example ([1], [2]) of Smooks transformation applied on both request parameters and response results. In the example Smooks transformations are defined to map a user model to the WS generated types.
It might be interesting to try writing up an example using mapping files dynamically generated by inspecting the Wise model, perhaps using <String key, primitive value> maps as parameter input and result output; I'll probably try spending some time on this sooner or later, if it's doable that would further lower the complexity of ws invocation.