loadUI – a short technical background

olensmar — Wed, 07 Jul 2010 12:06:51 +0000

Here comes a little background information for those of you curious about the inner makings and ideas used in loadUI.

Why JavaFX?

Perhaps the biggest “surprise” when first being exposed to loadUI is the user interface. There is a story for this; when we started planning our next tool about two years ago we had a couple of primary goals we wanted to achieve, many of them related to the usability and user-interface of the product; we wanted it to be cool, eye-catching and innovative but still usable and easy to understand – not an easy feat. Doing this with Swing seemed possible but not very “natural” (although we really like Swing!), and using some non-java technology wasn’t really an option since we wanted to use OSGi for a modular core and be able to reuse code from our soapUI project. JavaFX was still in its early stages and seemed really promising, so we took the decision and have been mostly very happy since; having the possibility to create a “fluent” interface like the one we have on top of an enterprise core using all the latest technologies is a perfect match for us. We have had a usability expert designing much of interface and usability; much of the loadUI interface was actually created on paper long before we got around to coding it.

JavaFX usage

Since the loadUI front end is almost pure JavaFX (a couple of Swing components are still there for performance or functionality reasons), it utilizes a lot of the included features; we rely heavily on the included Controls, such as TextBoxes, Buttons, CheckBoxes, etc. (and hope for many more to come in future iterations of JavaFX). Most of the graphical parts of loadUI uses a mixture of Images, FXDs and Shapes to achieve the desired look, and as often as possible we try to use CSS to style these. The CSS improvements in 1.3 have made a huge difference, allowing us to move away from custom controls in a lot of areas and use the standard ones with some custom styling. Another area which improved quite a bit in 1.3 is the layouting. Before, we had to implement our own custom layouts a lot of the time. Now we can achieve the same using the existing Containers and different LayoutInfo properties, and we also make heavy use of the XMigLayout provided by the JFXtras project.

Modularity at the Core

At its core loadUI makes heavy use of the Apache Felix OSGi implementation. It consists of a number of different bundles, many of them being pure Java and forming the “back-end” of the application. One of the bundles, loadui-api, holds a number of Java Interfaces, exposing the functionality of loadUI. Any front-end to loadUI will mainly access the backend through the API, but also through the Service layer in OSGi. The JavaFX front-end does just this, as does the command-line runner now available in the nightly builds. They are implemented as OSGi bundles as well and listen for the various Services that the core API defines (which are provided by the other bundles). To make things a bit easier, we use the Spring Dynamic Modules project which provides IoC and manages exporting and importing OSGi Services.

Groovy makes things so… groovy!

Another one of our initial goals was to make it easy for others to add their own components to loadUI. For this purpose we have a really cool component architecture in loadUI which allows you to create your own custom components by simply writing Groovy scripts and saving them to the file system. These then show up inside of loadUI and act just as the standard component set (in fact, almost all the standard components were created in this way). The challenge here was how to specify the look of the component in groovy, which is then rendered by JavaFX. We solved this by basically using an MVC pattern, where you write the Model for the component in Groovy, and the JavaFX code renders the View. The whole infrastructure is extremely dynamic; you can create and modify custom components and they will be automatically picked up and updated in the loadUI interface (a blog post on this is in the making) without requiring you to restart loadUI or even stop your tests.

CometD for LoadTest Distribution

loadUI has a really nice infrastructure for distributing your LoadTests to multiple loadUI Agents (interactively, drag-and-drop, etc); each agent basically has the same core infrastructure as the main application but without the JavaFX bundle and interface. Communication between the loadUI Controller (as we call it) and its configured agents goes over the CometD protocol (using Jetty), and is even SSL encrypted for security reasons. This gives us both a very low overhead and high flexibility, and since it is based on standard HTTP(S), most networks should not have a problem handling these communications. Read more on how this works in loadUI in the Agents and TestCases document.

Redistribution challenges

One other challenge we met was that of redistribution; currently one is not allowed to redistribute the JavaFX runtime for legal reasons, and providing loadUI as a downloadable webstart application didn’t seem feasible. We have solved this by running the main loadUI application as local web-start application (via javaws) with a standard jnlp dependency to the JavaFX runtime; our installer installs the required JRE and sets up all required paths in the bat and jnlp files, in this way we were able to provide our users with an almost-standard way of installation applications. This is a temporary solution though; as soon as the JavaFX runtime redistribution is allowed we will do that instead, as it will not require an internet connection for the installer to work and gives us better control of the actual execution environment.

Final Words

So, as I’m sure you can understand, we are really proud to have come this far and really believe the loadUI has the possibility of leading the way for a new kind of enterprise applications; those that both look and work like a dream.

Feedback is as always very welcome, here or on the forum. And if you haven’t tried loadUI yet, or are just interested in more details, head over to the loadUI website for movies, documentation and downloads.

Thanks for your time!

/Ole

eviware.com

What happened to the old blog?

olensmar — Tue, 06 Jul 2010 12:48:12 +0000

Hi everyone! We’ve merged most of the content of the old eviware blog into the updated soapUI documentation now available at http://www.soapui.org. If you are looking for some specific page or content that you can not find please post this on our general forum at http://www.eviware.com/forum so we can either point you in the right direction or add the missing content (or both!)

Sorry for the inconvenience.

best regards!

/Ole

loadUI Release

Niclas Reimertz — Mon, 21 Jun 2010 20:00:52 +0000

Today eviware released our new software, loadUI.

I’m really excited about it. I think loadUI represents something very new. We’ve taken Load Testing and created a new, more intuitive way of creating performance tests which requires less work to do the same task. We’ve also added the ability to do this in real time. Previously Load Testing has been very static work; you would need to create the complete tests and run them to the end before you could update them. This was very counter intuitive since Load Testing is very non-static in its nature; it’s about chasing that elusive bottleneck that sticks it head out every now and then, but not all the time and not every time.

This is what we set out to do when building loadUI; being able to react to variations in response times or server behavior and then honing in on the bottlenecks. In real time. When the system started to wobble; not after it had recovered.

At the same time, I think you’ll find that loadUI is not a one trick pony; you still have all functionality needed for Load Testing. It’s just that you can do it in real time. And in a sexy tool. There. I said it. Sexy.

Eviware Blog