Saturday, August 27, 2016

Wise GUI on WildFly

Wow, last post here is almost 3yrs old... sorry.. anyway, time for a quick update!
After I released the Wise webgui in 2013, the idea of a GUI allowing easily invoking webservices endpoints was appreciated quite a lot.
Needless to say, I thought about having it available in JBoss AS / WildFly by default a lot of time ago (way before eventually releasing the gui ;-) ), so the fact the web application was well received convinced me to make a proposal for including Wise in the container. However, that task has constantly been on hold because of more urgent and relevant stuff to work on... and we also got some not-so-good feedback on the choice of using JSF/RichFaces for the GUI.
More recently, Rebecca joined the Wise team and offered to work on an alternative and GWT based implementation of the GUI; she also tried to gather and consider any feedback that would have likely turned into a requirement for the GUI inclusion in the container.
Time passed by and eventually a new gwt-gui was released in June this year; then we tried again pushing on the container integration...and here we are today :-)
A pull request for including Wise by default in WildFly has been merged upstream on master few hours ago.
Here are the steps for playing with the new GUI directly on WildFly :-)

  • Checkout WildFly master on GitHub and build it
  • Add a management user to the container distribution that's created in dist/target directory
  • Boot the container (standalone, default configuration)
  • Open up a web browser on http://localhost:8080/wise
  • Login with the above created user credentials
  • Enjoy :-) (test any locally deployed WS endpoint or any available online, for example this one)

The container inclusion work has allowed us to find out a bunch of bugs and possible improvements of the GUI... as a matter of fact many issues has already been fixed on JIRA and a new release of both core and gwt gui is coming soon. So stay tuned (and report any bug you find)!

Wednesday, October 23, 2013

Wise presentation at JBug Milan

Yesterday I've been presenting on Wise at the Milan JBoss User Group.
I went through the core Wise concept and finished with a demo of the Wise GUI, which looked interesting to the attending developers :-)
The slides for the presentation are online at Slideshare:

Monday, July 8, 2013

Wise GUI on Openshift

Last Friday I cut a bug fix release of both Wise core and Wise webgui. Most of the changes are basically meant to consolidate / optimize the web user interface, making it simpler to understand and faster.

Building and deploying Wise webgui to your local JBoss AS 7 instance is really a matter of unpacking a zip file and issuing a single command (mvn clean package jboss-as:deploy). Starting from today, you can also try a demo Wise application on my Openshift area: https://ws-asoldano.rhcloud.com/wise-gui/

I might be updating that in the future before cutting new releases, so don't be too surprised if you catch it offline for some minutes; anyway feel try to stick any public wsdl url in there and test your preferred ws endpoint. Please post any feedback on the forum :-)
If you don't know what to test and just want to give Wise a try, http://www.webservicex.net/ has plenty of misc test ws endpoints (almost all up and running).
Enjoy!

Wednesday, June 12, 2013

JBoss Tools and release of Wise-core 2.0.2.Final

The release of Wise core 2.0.1.Final few months ago came with some new features, including the message preview functionality. As previously blogged, an obvious usage scenario of that is writing a SOAP message preview tool.
Now, given JBoss Tools (Eclipse plugins for JBoss technology) offers a similar functionality and was having few issues in that area, I ended up talking a bit with JBoss Tools developers and eventually had them try migrating to Wise instead of the existing message preview implementation ;-)
So I'm quite happy upcoming JBoss Tools 4.1.0 will be using Wise core for its WS Tester plugin!
By the way, this also brought additional testing coverage to Wise; as a matter of fact a quite important bug was found by Brian Fitzpatrick (thanks Brian!) while working on the migration... so here I am at announcing a bug fix release, Wise core 2.0.2.Final.
The new version is available for download as binary distribution, its Maven artifact are on the usual repository and next release of JBoss Tools (4.1.0.Beta2) is going to consume it.

Consider giving a try at both JBoss Tools and Wise core new version, feedback is welcome!
For those using the Wise webgui, a simple update in the main pom.xml to use core 2.0.2.Final is enough for pulling in the new version.
Enjoy!

Friday, March 22, 2013

Wise GUI 1.0.1 additions

Wise core 2.0.1 and Wise webgui 1.0.1 have just been released!
The core comes with a couple of interesting new features which I introduced in the previous posts: detyped contract browsing / endpoint invocation and request message preview. This post will hence show the nice additions that webgui has just got :-)

The request parameter panel is now a multi-tab panel:

in particular the "Options" tab allows setting:

  • the username / password to be used for the actual invocation (might be different from the wsdl retrieval ones)
  • an override value for the target endpoint address (which is useful for quickly testing different endpoints conforming to the same wsdl contract)


Moreover, it's possible to get a popup window showing a preview of the SOAP request message that would be created and sent for the currently provided request parameters (no message actually goes on the wire):


Finally, should the user be interested in having a look at the actual SOAP response message that has been received upon invocation, the "View message" button shows it in another popup window:


I believe the 1.0.1 additions should further expand the set of Wise GUI usage scenarios; you can download the latest version, have a try and feel free to provide feedback :-)
Further improvements are planned for next release, possibly including a major UI change for allowing user management, so stay tuned...

Friday, March 1, 2013

Writing a SOAP message preview tool


Previous post introduced a new tree view of request parameters for invoking an endpoint. Here I'd like to show an example of a practical usage of such addition to Wise core: a customized SOAP message preview tool.
There're few scenarios in which a user needs to know how a SOAP message for invoking a given WSDL operation will look like. Computing that can be easy or difficult, depending on the complexity of the contract (number of schemas, wsdl style, etc.), that's why resorting to leveraging tools is actually a good idea ;-)

Using Wise, we start by building a WSDynamicClient instance consuming our target wsdl and selecting the WSMethod to use (here we already knew the service, port and operation names):
then it's time to create an ElementBuilder as follows:
please note we're setting the request flag (given we're building the tree for request parameters) and we disable default value generation for leaf elements (as we want to provide custom default values and do not want elements from schema sequences to default to null).
The builder is used to build up the request trees (one for each method parameter):
the populateElement method is where we customize the tree according to our scenario needs:
as you can see, we don't want null elements [A], we set default values for leaves [B], we add one element for each array/collection [C] and run a single cycle of lazy element expansion [D] (cyclic element type references in the schemas are converted into lazy load elements in the tree).
In this case, the default values are set in quite a dirty way in getDefaultValue(Class cl), basically we check provided class and return a "?" for String, zero for any numerical type, "1970-01-01T00:00:00.000Z" for XMLGregorianCalendar and an empty string otherwise.
Once the tree is available, getting the actual parameter objects to perform the invocation with is a matter of calling toObject() on each tree root element:
And finally, the message preview is written to a provided output stream as follows:
That's all!
You can have a look at the whole code in the MessagePreviewIntegrationTest I've recently added to the current Wise core 2.0.1-SNAPSHOT. Any feedback / comment is welcome!

And if you're wondering how this is currently implemented, well, you know Wise basically uses JAXWS tooling from JBossWS to generate a compliant ws client; the Wise model is built by parsing the generated client and the tree view is derived from the model. The message preview flow is pretty similar to the invocation one, except a special jaxws handler is installed in the client in order for writing down the SOAP message generated by the internal ws stack (Apache CXF here); the handler also stops the handler chain execution so that no message actually goes to wire and Wise early return the message preview.

As previously explained, delegating to a fully compliant WS stack here, ensure correctness of the messages, even of their preview ;-)

Thursday, February 28, 2013

Detyped WS contract browsing and endpoint invocation

In response to some good feedback received from the community after the recent 2.0 release, I've been enriching the API of Wise Core to further simplify ws testing using it.
Till now the Wise core API has fundamentally been based on the WSEndpoint, WSMethod, WebParameter abstraction:
A given WSDL contract is mapped to at least one WSEndpoint instance having one or more WSMethod instances. Each WSMethod can have multiple WebParameter objects depending on the WSDL operation signature. By inspecting the type information in WebParameter instances, the user is meant to build the actual objects to be passed as arguments to WSMethod:invoke(Object args). While effective, this might turn out to be not very practical and easy (due to reflection, see here) if the consumed WSDL contract is complex and includes multiple nested schema types.
It's well known that Wise core supports Smooks transformations, with the sake of allowing conversion of existing application data models into the object structure required for performing the invocation. However that's not really helping a lot when the target is programmatically testing a given endpoint.
In particular some users expressed the interest in the tree view offered by the Wise GUI on top of the core model: similarly to what is shown in the GUI, a tree model (think about e.g. the DOM tree approach) could be provided to describe each parameter type of a given WSMethod. Each element of the tree would allow getting children and setting values (for leaves only). So here is what I came up with: The current Wise core 2.0.1-SNAPSHOT features an implementation of the Element interface above, as well as a builder implementation for converting a WebParameter into an Element tree:
The end result is in a really simplified contract browsing of a WS endpoint as well as simple invocation (see the integration test here too):
The tree view can of course be used to convert and access the data returned in the InvocationResult instance.
Please note how the parameters type info is completely hidden to the user, who basically ends up setting string values for leaves elements. Strings are parsed into proper primitives (and wrappers) depending on the actual parameter type. Wise default Element impl is currently able to convert values to String, Character, all numerical types, QName, XMLGregorianCalendar and Duration classes.
So, leveraging Wise, a user can invoke / test an endpoint by browsing its contract and setting parameters in a fully dynamic and detyped way, while still being sure the generated SOAP request is compliant with the contract requirements and constraints.

The additions described above are currently being tested and will be included soon in next release. Any comment / feedback is welcome as usual!