Kick off Wise 1.3 (perhaps 2.0...?) development

[asoldano]

Folks,

we've been silent here for quite some time and now I'd like to get back on the project and revive it a bit ;-)

I just created https://issues.jboss.org/browse/WISE-174 as the first task I have in mind is basically to update the library to work with the recent JBossWS 4 and JBoss AS 7.1.

Btw, JBossWS has finally completed its transition to the Apache CXF based stack, so we might even prune Wise removing the JBossWS-Native specific stuff.

My idea would be to work on this and "quickly" cut an initial release, meant for the new generation WS and JBoss application server.

Among the most basic things we need to do for this new version, I'd say we have Maven 3 support and JDK 7 support.

Once that's done, we'll go through the outstanding jiras, remove the out of date ones and get back on bug fixes and new features.

[asoldano]

OK, it really took months to find out some time to spend on Wise, anyway a couple of weeks ago I started developing a web gui for exposing basic functionalities of the core.

The sources are currently available at http://anonsvn.jboss.org/repos/wise/webgui/branches/cdi-jsf/ and will soon be moved into trunk, replacing the stuff there which never really took off.

The new webgui is a JavaEE web app (CDI + JSF) using RichFaces 4.3 for dynamically rendering the parameter and result trees of elements:

Next weeks we'll be cleaning up the code a bit (feel free to checkout and provide feedback!) and finally tagging and cutting a 2.0.0 release.

Stay tuned!

[sonicaaaa]

Hi Alessio, I have just started to play with the web gui and I've already found it really useful.

My first addition to your code has been this line added to the bottom of @PostConstruct public void init()

wsdlUrl = FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap().get("endpoint");

To support url parameter like this:

http://localhost:8080/wise-gui/?endpoint=http://www.html2xml.nl/Services/Calculator/Version1/Calculator.asmx?wsdl

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.

I am going to try most of the lib as soon as possible!

Good work!

paolo

[asoldano]

Paolo, thanks a lot for the feedback!

I'll go and check what can be done to support the scenario you're describing above; btw, if you want to share more details on the whole scenario / idea you have, feel free :-)

Cheers

Alessio

[sonicaaaa]

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.

If you look at these examples:

http://mswiderski.blogspot.co.uk/2012/07/service-task-with-web-service.html

or

http://duncandoyle.blogspot.co.uk/2012/10/jbpm5-calling-webservices-from-your.html

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!

[asoldano]

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.

[asoldano]

Hi again,

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:

Element customerElement = new ElementBuilderImpl(client, true, true).buildTree(customerPar.getType(), customerPar.getName(), null, true);
customerElement.getChildByName("id").setValue("1234");
customerElement.getChildByName("name").getChildByName("firstName").setValue("Foo");
customerElement.getChildByName("name").getChildByName("lastName").setValue("Bar");
customerElement.getChildByName("name").getChildByName("middleName").setValue("The");

In next future I'll be going on cleaning the tree view and preparing a decent api for the builder, I'm targetting this stuff for 2.0.1 release. Any feedback is welcome ;-)

[1] http://anonsvn.jboss.org/repos/wise/core/trunk/core/src/main/java/org/jboss/wise/tree/

[2] http://anonsvn.jboss.org/repos/wise/core/trunk/integration-testsuite/common/src/test/java/org/jboss/wise/test/integration/complex/WiseIntegrationComplexTest.java

[3] http://anonsvn.jboss.org/repos/wise/core/trunk/integration-testsuite/common/src/test/java/org/jboss/wise/test/integration/smooks/WiseIntegrationSmooksTest.java

[4] http://anonsvn.jboss.org/repos/wise/core/trunk/integration-testsuite/common/src/test/java/org/jboss/wise/test/integration/tree/WiseIntegrationTreeTest.java