To have some sort of bookmarkable urls when I'll include the webapp in bigger projects.

I am not familiar with CDI+ JSF so I haven't found a quick way to remove the param after the user press the OK button, but I guess I can leave it there, at least for the testing use case I had in mind.

The reason while I introduced the url parameter is because, being a good testing tool it could be useful embed a direct link to a test in something like a generated test report or even directly in any integration/funcional document. It would be even more useful if it could be possible do embed directly the values that are tested, but I supposed there are many limitations to this.

The other context in which I'd like to plug the Wise framework is in jBPM.

They describe a workflow to how to implement, manipulating directly CXF some WS Client that are then wrapped in a WorkItemHandler that is the mechanism that jBPM uses to implement the functionality of defining the details of a Task implementation that can then be used and configured in the design layer.

Duncan's example, in particular, is also trying to define a generic component that could abstract from the direct implementation.

In the next days I'll try to implement he's example with Wise and eventually try to understand if I'll be able to abstract ever more elements thanks to the dynamic nature of Wise to turn the component even more generic and easier to be plugged.

Not sure when I'll be able to work on all of this but it's definitely on my todo list!

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.

regarding the topic mentioned above, I've been spending some time last week(end) on cleaning up the tree view model we have in the webgui subproject and added the result into the core [1]. It's still very in flux, but you can already get how that could be used to invoke ws endpoints without having to parse the generated parameter types through reflection [2] or use Smooks [3]. The integration testcase I wrote at [4] provides an example of tree view usage against the same "complex" endpoint tested in [2].

You can see how one would basically be able to set request parameters pretty much as follows: