Wise' swan song?

It is with a bitter sweet sense that I write here 5yrs after my latest post... but I think I owe the community an explanation.

Anyone who happened to follow the Wise GUI development I was happy to talk about back in 2016 most probably noticed that the PR for bringing Wise into WildFly eventually got reverted before WildFly 11 release.  The initial attempt to add the GUI component to the application server was adding a couple of seconds to the boot time and no agreement could be achieved on the approach to workaround that. Effectively, the Wise project definitely entered maintenance only mode and the few contributors moved to other tasks.

Fast forward to 2021, as the core of Wise is still in use in a few Red Hat products, the maintenance requirements led us (Stefano and me) to refreshing our memories of the project: I've spent a few days on upgrading dependencies and even happened to resolve multiple years old jiras tickets... eventually ending up with a library that runs on these days WildFly versions (23, 22, 21), consuming JBossWS 5 series components. I admit this has given me a bit of satisfaction ;-)

So, yes, here is Wise Core 2.2.0.Final, a nice new minor with a fairly decent payload. Unfortunately, I can't promise anything about the future. Still, should anyone want to invest time on this library, the github repository is there waiting for contributions!

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)!

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:

JBoss Wise: breaking barriers to WS testing from alepalin

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!

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!

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...

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 ;-)

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!

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!

As you know I'll be in Berlin Thursday and Friday for JUDCon talking about Wise.

As you know I'll be in Berlin Thursday and Friday for JUDCon talinkg about wise.
I'd like to use this opportunity to meet some of you and having great talks about Wise, SibillaTest (aka TestedBy), or any other geek's argument...you know what non-geek calls crazy.
Where and when ca you find me? Well check on tripit when I'll arrive and where I'll stay.
I'll be of course at JUDCon's HackFest, but I'm more than open to plan other talks over a German beer.
Would you have a run with me? I'll run in Berlin for sure Friday and maybe also Thursday in the morning (if I find friends running with me, I'll run for sure Thursday too).
I have in mind more or less 10km of easy running (1h or so) to take a look to the city, since I''ve never stayed in Berlin and it seems I'll not have more spare time to take a look around. More precisely I'd like to take this run.
Write me if you want to join me both for a run or a beer, we can agree meeting point and time. For German people: write me also if you see something wrong in the planned run...something like "too more traffic here"...or "too more gangsters there!!" :D

See you in Berlin

[cross posted here too]

Wise will be at JUDCon (Berlin 7-8 October)

As cross posted here, I'll present Wise projcet during next upcoming JUDcon.
As you can see from the agenda the speech will part of "Soa and integration track" and will be focused on this points:

• Wise core:
  
  
  
  • Support of WS-*
  
  
  • Integration in ESB
  
  
  • One line WS calls
  
  
  • API to explore the dynamic generated stubs
  
  
  
  


• Wise-wegui:
  
  
  
  • A tool to help business analysts during validation tests of WS
  
  
  • The legacy web GUI and how it has been used in my company during the last year
  
  
  • The upcoming GWT gui
  
  
  
  


• LMS: Logging Meta Service


• The Wise Code donation: why have I donated my pet project to JBoss.org

I'll post here and there a report of the speech and slides too.

I hope I'll have also opportunities to have some interesting lightning talks about Wise and/or TestedBy during spare time there. Twitter, comment on the blog, or email are all fine if you want to contact me about that. I'll probably post in next days some proposal to have a run together too :)

Wise have new cool logo

This is the new logo for Wise. Cool, isn’t it?

We’re excited to officially have our new brand. Thank you very much to James Cobb and Cheyenne Weaver for our new logo, graphics and other branding help.

As said in this post we are backing on Wise giving it a new life with a lot of development on the road. And we had to do them with this owl observing us so seriously

Don’t forget desktop wallpapers and/or to wear your open source pride!

Wise 1.1 released

Our great team is proud to announce the 1.1 release of Wise project.

This release contains only the wise-core. For the Wise-Lms module please still refer to 1.0 release.

In this version we have totally changed the way to configure Wise Core. Why? We have moved all configuration to the code, passing all (in fact few) config during WSDynamicClient instantiation. In other words we have removed our dependency on JBoss MK, to be more flexible and compatible with JBoss ESB and JBoss AS 5. Please refer to section 4 of our programmers guide for further details

Another important change is how we are managing multithread use of our API, providing a thread pool of endpoints, permitting a concurrent safe and performant invocation of WSMethod even if the used JBossWS native stack doesn't provide a threadsafe access to generated classes (see WISE-25) . In general a lot of work have been done to ensure better performance and to avoid problems in concurrent use of our API.

More samples and integration tests on support of MTOM, WS-Security, and WS-Addressing.

We have improved also Support of (J)Ruby and Groovy. The question is why Wise instead of some native Ruby/groovy WS client? For a lot of reasons, like Smooks transformation support and support of WS-*

Finally the project have been mavenized and a lot of unit, integration and stress tests have been integrated in our build lifecycle.

For more details, please have a look at our JIRA

What are next steps for the project? For sure we will work in next weeks on JBossESB integration, because we would strongly purpose Wise 1.1 integration for next version of JBossESB, providing (above all) WS-* support in ESB zero code webservice invocation.

We have already opened discussion on 1.2 roadmap too and something will be announced very very soon. At least we will support CXF as underlying stack, provide a first release of webgui module.
Join the discussion on our forums and give your 2c on roadmap discussion and/or give us your feedback about current version. Of course feel free to report bugs or feature requests in our Jira

We also aims to write a series of post on this blog with some complex samples (i.e. using smooks mapper in a complex webservice client application), step by step guide to use Wise in a seam application, or ruby and so on. You should expect also some previews of our webgui modules here.

A special thanks to Tom Fennelly of Smooks project for all the help provided in this release.

Stay tuned!

Wise 1.0.1 is on the way

Wise's team has decided to publish a 1.0.1 release shortly.

We are doing that because we are doing some improvement related to our integration with JBoss ESB. Moreover we have found some subtle concurrency issue and we have fixed them.

That said, I'm writing this post mainly to announce that starting from Wise-core will be also a deployable sar in JBoss AS supporting Wise based webservice invocation also from web application and EJB. If you have time take a look to our svn and in particular to 2 samples demonstrating this use:

1. HelloWorldServlet that demonstrate the use of Wise-core into a servlet
2. seamSample that is a seam-gen generated sample which is able to invoke a webservice using Wise-core API with very little coding.

Any suggestions and feedbacks about would be very very appreciated through our Jira or our forums.

After this release we will concentrate on Wise 1.1 that will be focused on our web GUI tools on which we are getting help from a new member of our team (welcome Fabrizio!).

If you like Wise and all efforts we are doing about, don't forget that our Project Leader (Stefano Maestri, well...me) is an external contributor and he is enlisted for JBoss Community Leader Award. Your vote would be more than welcome.

Wise's code_swarm

As a lot of projects leader are doing in these days, I have fallen into temptation of code_swarm and I've generated Wise's svn code_swarm movie.

Oki, it seems a bit ridiculous if you compare it with other JBoss projects ones, but you know we are a young project ;)

Anyway we are getting some good feedback from community for our 1.0 release and we are working hard to integrate it in ESB 4.5
If you have too some questions or feedbacks please join our user forum and shot.
Also our developer forum is active in these days planning next steps. Your 2 cents are more than welcome.

And now..... ladies and gentlemen Wise' code_swarm movie:

Wise 1.0 released

Our great team is proud to announce the 1.0 release of Wise project.

This release contains the Wise-core and Wise-Lms module

Wise-core module 1.0 release aims to provide stable APIs for JAX-WS webservice invocation and some new cool feature. Take a look to our Programmers guide for a complete description of the features and possible uses of our APIs. Let us remark some of these features:

• Support of MTOM, WS-Security, and WS-Addressing
• Support of (J)Ruby. As for Groovy, the question is why Wise instead of some native Ruby WS client? For a lot of reasons, like Smooks transformation support, support of WS-*
• Initial support of JAX-RS
• More samples
  

Wise-Lms module is a new module: Lms is an acronym for Logging Meta Service. Lms' goal and use are very similar to the axis' tcp monitor ones: it logs any tcp communication and gives developers the opportunity to review any request-response communications. Lms is a JBoss deployable application (an ear) and have a jmx mbean as application core and a web user interface to make its use easy. To have more information please refer to our documentation of Wise-Lms module.

What are next step for the project? For sure we will work in next weeks on JBossESB integration, but we have already opened discussion on 1.1 roadmap and something will be announced very very soon. Join the discussion on our forums and give your 2c on roadmap discussion and/or give us your feedback about current version. Of course feel free to report bugs or feature requests in our Jira

Wise 1.0 roadmap

Wise team has just started the coding phase driving us to 1.0 release.

Some highlight of 1.0 roadmap:

• Support of WS-Security, WS-RM and WS-Addressing
• Support of (J)Ruby. As for Groovy, the question is why Wise instead of some native Ruby WS client? For a lot of reasons, like Smooks (and not only) transformation support, support of WS-*,
• Support of xjc for JAXB object generation from an XSD (not necessary embedded/linked in wsdl). That's good itself, but moreover it's the first step needed to support JAX-RS too.
• first release of LMS subproject

Moreover this release would provide a stable API to our user.

Would you lend an hand? Join our forums, discuss issues with us, test 0.9 release and provide patches and purpose new features. If you want to contribute don't miss our contributor guideline

We have also started a discussion about Wise webgui that will not be in this relase, but could be very interesting, and for which we would like very much contributions from community (and we are also getting some!)

Wise 0.9 released

We are proud to announce the first JBoss's release of Wise project.

This release contains only the Wise-core module with all basic features enabled. Take a look to our Programmers guide for a complete description of the features and possible uses of our APIs.

Some cool features we would remark are:

1. One line of code invocation
2. Interactively explore your wsdl objects
3. Support of Groovy
4. Support of standard and Smooks' based JAX-WS handlers
   
5. WiseMapper: from your own object model to the generated JAX-WS model and vice versa. We Support year both Smooks and your own custom mapper.

We are working hard to define the definitive roadmap for 1.0 release (scheduled before the end of the year) and we will post about here very soon.

This first release have to be considered as a preview release kicked out to ask feedback from the community for our APIs. We don't consider at this level API stable, but we would stabilize them before the end of the year and so we are publishing a preview of our 1.0 release.
Please have a look, get it to play and give us feedback in our developer forum. Of course don't hesitate to ask help in our user forum too.

Stay tuned for 1.0 roadmap...you could get some great surprises ;)

Reasons for a code donation

As said in announcing post Wise comes from a code donation.

I have just posted on my personal blog my reasons for this code donation.

I'm cross posting here because community may be interested ;)

Wise is JBoss.org project

We are proud to announce Wise is a JBoss.org project.

Wise is an acronym standing for Wise Invokes Services Easily

Wise comes from a code donation by Stefano Maestri and Alessio Soldano and it has already been included in JBossESB 4.4 as new webservice client.

What is Wise? In a nutshell it's building a java framework to invoke webservices easily, usable as base for zero-code webservices invocation application. But it's much more than this, aiming to provide also a web based generic interface to invoke web service, and a tool keeping track of serice invocations and soap message exchanged.

Take a look to its homepage for much more infos.

We will have in few days our first release signed JBoss.org and a bright roadmap is coming too on this blog.

Stay tuned