Monday, February 11, 2013

Wise is back


It's been a couple of years since we wrote here last time. At least from my point of view, the project has basically been on hold while waiting for the underlying ws layer to stabilize (and for me to have time to update its integration here ;-)). Moreover we've been kind of waiting for the web gui work to come to an end, but unfortunately that never really took off due to lack of time from the contributors working on it. Anyway, in the mean time, both application server and its WS layer made giant steps ahead and JBoss AS 7 series comes today with a fully compliant web services stack based on a proper Apache CXF integration. Last summer I actually updated and cleaned-up the wise-core, made it build with Maven 3 and added support for AS 7, however that was not enough for a release. More recently I decided to invest some energies (and most of my spare time ;-)) on creating a GUI for the basic wise functionalities, basically what we had in the project before the donation to JBoss / Red Hat. So I basically started from one of the very nice JBoss Developer Framework quickstarts and built a JavaEE 6 web app based on CDI and JSF 2 (using RichFaces 4.3). I have to say that it actually turned out to be easier / faster then I expected to get to what you see in the snapshots below.
The GUI is basically a fully dynamic, single page webapp for quickly invoking webservice endpoints without the need of generating and compiling client stubs or directly writing SOAP xml messages. You start by typing the URL of the wsdl contract you want to consume (you can provide username and password if required, http basic auth only supported atm):



then you click on "OK" button and let Wise fetch the wsdl, parse it together with any referenced schema and finally present you a list of available endpoint operations:


you select an operation and Wise shows a tree representing the input parameters for that:


you can fill in input boxes with data, enable/disable elements (for nillable ones only) and add/remove elements for collection and list parameters. Finally, you click on "Perform invocation" button and get another tree for the result object:


That's all, very simple, yet really effective and quick solution for testing ws endpoints. No need for either writing a single line of code or playing with XML. No external tool needed (besides for your browser). And possibly even more interesting, no special technical knowledge required, so e.g a business analyst might validate WS service results without bugging the developer who worked on it ;-) (keep in mind that in most scenarios, exposing a simple test WS endpoint is basically a matter of adding a single @WebService annotation on a POJO or EJB3 class...)

You can get the Wise 2.0 core as well as the first Wise GUI release from the project download page. The core artifacts are also available on the JBoss Maven repository; the web GUI is meant for being deployed on JBoss AS 7.1 or greater, please refer to the enclosed README file for details on building and deploying it (it's basically a single command though, assuming you have Maven properly setup).

For the next releases, I can foresee interesting and not too difficult to achieve enhancements to the web GUI, mainly on supporting WS-Policy enabled endpoints / contracts (the underlying WS stack is already fully supporting that stuff). I will create jiras soon and will probably work on them assuming I can still save some time to spend on Wise; anyway any contribution is more then welcome, keep an eye on jira and feel free to jump in anytime.

Stay tuned!

2 comments:

schrepfler said...

Nice work, however supporting only SOAP is kind of limiting considering that most API's today are RESTful.
Isn't is appropriate for Wise to be able to import a WADL and support both form based resources as well as xml/json rappresentations of the payload (if grammar document is provided by the wadl or alternatively a schema/jsonschema could be mapped to the resource path subsequently)

Alessio Soldano said...

Hi Srđan,
thanks for the feedback.
Regarding WADL, I personally have some doubts on it, possibly due to a limited knowledge of the REST "world"; to me the WADL thing is like going back to non REST approach and use WSDL. Don't get me wrong, I'm strongly believe that having a contract for a service is important, I'm just wondering if in such a scenario it's not better to simply stick to WSDL and non-REST.

This said, should a contribution come on supporting WADL, I'll be more then happy to provide pointers and merge the contributed code :-)