loadUI provides its load testing magic through heavy use of the following technologies:
- JavaFX - used for creating a truly unique and interactive user interface
- Groovy - used for providing an extremely flexible and dynamic component model
- OSGi / Spring DM - used for modularization and extensibility (based on the Apache Felix implementation)
loadUI runs as a local Java WebStart application (due to redistribution restrictions for the JavaFX Runtime) which will most likely change as soon as redistribution of the JavaFX runtime is permitted and we can package it as a standard standalone application.
Lets have a look at this in a little more detail and finish of with instructions on how to build and run loadUI locally.
1. JavaFX
loadUI almost exclusively uses JavaFX to provide its user-interface, only a few swing components are used either for performance or functionality reasons but we hope to replace these all with JavaFX counterparts as JavaFX evolves (so we can use the prism rendering engine). loadUI makes heavy use of the included Controls, such as TextBoxes, Buttons, CheckBoxes, etc. (we hope for many more to come in future iterations of JavaFX). Most of the graphical parts of loadUI uses a mixture of Images, FXD's and Shapes to achieve the desired look, and as often as possible we try to use CSS to style these. The CSS improvements in JavaFX 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 styles.
For layouting we use the existing Containers and different LayoutInfo properties together with the XMigLayout provided by the JFXtras project (thank you!). When it comes to animations and effects we have used these sparsely for both performance and "keeping-it-clean" reasons, but will increase on them if they provide improved usability and an improved user experience.
2. Groovy
An interesting problem we were faced with was integrating Groovy and JavaFX. loadUI has a really cool component architecture which allows you to create your own custom components by writing Groovy scripts which automatically show up (and are updated!) inside 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 "DSL"-possibilities in groovy allowed us to create an extremely efficient syntax for building components and their behavior, making development of new components a breeze (of course custom components can be created with Java, but in most cases the simplicity of the groovy possibilities are preferable).
3. OSGi
loadUI uses OSGi at its core and consists of a quite a number of different bundles (all coded as maven2 sub-modules in the source code). Many of these bundles are pure Java and together they make up the backend of the application. One of the bundles, loadui-api, holds a number of Java Interfaces exposing the functionality of loadUI. Any frontend 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; it is implemented as an OSGi bundle as well, and listens for the various Services that the API defines and which are provided by the other bundles. We use the Spring Dynamic Modules project, which provides IoC and manages exporting and importing OSGi Services, to simplify OSGi service usage and implementation.
As mentioned above it is easy to create custom components using the groovy-based component infrastructure, but if more elaborate components are required extending loadUI via OSGi is just as possible; for example the soapUI-Runner component is a separate OSGi bundle that contains all its dependencies and functionality and exposes defined loadUI services which will automatically be discovered and picked up the the loadUI runtime.
4. Building and Running from SVN
The source code for loadUI is located in the eviware public SVN under the following path:
/loadui/trunk/loadui-project/
Use the following command (requires SVN) to check the project out into the current working directory:
svn checkout svn://svn.eviware.com/loadui/trunk/loadui-project
To build loadUI from source, you will need to do the following:
- Install Maven 2 (loadUI consists of a large number of maven2 modules)
- Install the JavaFX SDK
- Set the JAVAFX_HOME environment variable to point to the location of your JavaFX SDK folder.
Run the following command (from the command-line) in the root of the project folder that you checked out (loadui-project):
mvn clean install
This will do a full build (but without the installers in order to save time). Once this has completed without errors you will be ready to start loadUI; there are two executable components to loadUI, the main loadUI application (loadUI controller) and the command line loadUI Agent. Run them as follows
- For the Controller navigate into the directory loadui-project/loadui-installer/target/controller and execute loaduitest.bat/.sh
- For the Agent Navigate into the directory loadui-project/loadui-installer/target/runner and execute loadUI-agent.bat/.sh
5. Globally Created Files
loadUI saves all created files in a ".loadui" folder under the current users home directory;
- a workspace file will be created containing the projects and agents configured, together with workspace settings
- project files for each created project will be put here by default
- a keystore.jks file containing the default key used for encrypting traffic between the loadUI application and configured loadUI agents
- a .groovy folder which contains cached libraries used by groovy script components
- a controller-cache folder which contains cached OSGI bundles used by the loadUI core
- a fileStorage folder used on agents for caching files used by distributed components
Hope that gets you started, please don't hesitate to comment or ask questions on our loadUI forum boards at http://www.eviware.com/forum.
