Technical Overview

soapui is more or less a "standard" java swing application. It is built around a core object model defined in the com.eviware.soapui.core.* packages and its WSDL implementation in the com.eviware.soapui.impl.wsdl.* packages. The javadocs give a short description of all packages and classes, they are a good start to get an overview.

soapui is built with maven and related project tools/methodologies/patterns.

Core Object Model

The core object model com.eviware.soapui.core.* packages define all soapui model objects (Projects, Interfaces, Operations, etc..) as abstract interfaces. The interfaces are generally "read-only", modification of objects is implementation-dependant through actions that the implementations provide (for example for renaming a request).

The com.eviware.soapui.model.tree defines the TreeModel used by the soapui navigator and its contained SoapUITreeNodes.

soapui currently has no builder/factory mechanism for adding new implementations of the core model, the usage of the core-implementation for WSDL 1.1 (see below) is "hardcoded" into the current Workspace implementation class (this should obviously be fixed).

WSDL implementation

The WSDL/SOAP/HTTP-Binding implementation of the core object model is available in the com.eviware.soapui.impl.wsdl.* packages;

  • com.eviware.soapui.impl.wsdl.* : contains implementations for the core object model. Each implementation class is "bound" to a configuration-file element using the corresponding XMLBeans class as described below (under "Configuration Files").
  • com.eviware.soapui.impl.wsdl.actions.* : contains all actions for model item implementations
  • com.eviware.soapui.impl.wsdl.panels.* : contains all panels for model item implementations
  • com.eviware.soapui.impl.wsdl.support : contains WSDL/SOAP related support classes (validation, importing, etc)
  • com.eviware.soapui.impl.wsdl.teststeps.* : contains available teststep extensions together with assertion-related classes

Libraries Used

The following libraries are used in soapui:

  • XMLBeans 2 (ASL V2) is used for all XML/Schema processing/validation and SOAP message parsing/generation.
  • WSDL4J 1.5 (CPL) is used for WSDL parsing
  • HttpClient 3 (ASL V2) is used for the posting of SOAP messages
  • JGoodies Looks/Forms (BSD) are used for UI-enhancement (together with custom extensions)
  • log4j (ASL V2) is used for logging
  • a number of jakarta-commons (ASL V2) libraries are used for general functionality

See a complete list of dependencies in the maven dependencies report.

Configuration Files

The 2 configuration file formats for workspaces and projects are defined in the src/xsd/soapui.xsd schema and the corresponding XMLBeans objects are created using the custom maven goal maven soapui:generate-xml-beans. The generated classes all have their names extended with the Config suffix to distinguish them from soapui interfaces/classes.

XML Editor

The XMLEditor component used in soapui is an extension of the jEdit Syntax package adding mouse-wheel, undo/redo and find/replace functionality. The extension class JXmlTextArea is available in the com.eviware.soapui.support package.

Extension Points

If you want to add new functionality, you could:

  • create new Assertions by extending the WsdlAssertion abstract base class (look at SimpleContainsAssertion for an example) and adding the extension to WsdlTestRequest
  • create new Test Steps by extending the WsdlTestStep abstract base class (look at TransferResponseValuesTestStep for an example) and adding the extension to WsdlTestCase
  • improve the WsdlInterfaceDesktopPanel with improved browsing/searching facilities.
  • improve the xml-editor by extending the JEditTextPane class.
  • etc..

Known Issues

Of course there a number of things that in hindsight could have been "done better", so if you want to help out (which would be great!), you can look at:

  • The WsdlRequestDesktopPanel and WsdlTestRequestDesktopPanel classes are more or less identical except for assertion/logging-related functionality for test requests. Common code should either be moved to a abstract base class or an external helper class
  • The possibility to use other implementations of the core interfaces should be added to WorkspaceImpl.
  • The creation of TestCase steps should be implemented with some Factory/Registry pattern implementation so new test-steps can easily be added.
  • The creation of Assertions should be implemented with some Factory/Registry pattern implementation so new assertions can easily be added.