Apromore’s service-oriented architecture is structured over three layers with the logic layer blended between the data and presentation layers (see figure below). The data layer hosts process models and event logs. Process models are stored as relational data in Apromore’s internal canonical process format, as well as native XML files (e.g. BPMN, EPML, AML). Event logs are stored as XML files in the XES and MXML formats. The logic layer hosts the Manager service, which is in charge of the typical operations of a model repository, e.g. importing, storing and exporting models, creating folders, renaming models. The presentation layer hosts the Portal and the Editor. The former is the main user interface of Apromore, from which the various capabilities offered by Apromore can be easily accessed on top of the process models available in the repository. The Editor offers a visual interface for editing and visually analyzing process models. Manager, Portal and Editor are implemented as independent Web applications which communicate using SOAP through the WSDL interface provided by the Manager, with the Portal and the Editor acting as Web service clients for the Manager. The Manager can also be accessed by third-party clients that are external to the Apromore environment, such as ProM or WoPeD.
Apromore’s software architecture
Apromore relies on four core technologies: Spring, ZK, OSGi and Eclipse Virgo. Spring provides a simplified management of Java-based enterprise applications through the use of Java annotations and XML configurations. ZK is an AJAX framework used for designing the Portal. OSGi provides a flexible framework for managing component dependencies through the use of plugin bundles. Eclipse Virgo is a Web server based on the OSGi component model.
Each plugin is packaged as an OSGi bundle, whereby each bundle is composed of a set of Java classes, libraries and configuration files, plus explicitly-defined external dependencies on other OSGi bundles. OSGi offers several advantages over other plugin frameworks. First, plugins can be dynamically deployed, without the need to restart the Web server every time a plugin is added or removed. Second, multiple versions of the same plugin can coexist. This in turn does not only guarantee retro-compatibility of plugins, but it also prevents the violation of dependencies when a new version of a plugin is released. These characteristics make OSGi a particularly suitable technology for rapid research prototyping.
Apromore supports three types of plugins, namely logic, portal and editor plugins. Logic plugins sit in the logic layer of the architecture and capture the actual logic of the various capabilities offered by Apromore, e.g. similarity search, merge, query. A logic plugin can be invoked by the Manager, the Portal or the Editor. An example of a logic plugin is the Apromore Canonizer, which is in charge of converting a process model from its native format (e.g. BPMN or PNML) into Apromore’s internal canonical format (CPF), and vice versa. Another example is the Structure logic plugin, which encapsulates the logic for block-structuring a process model.
Portal and editor plugins both sit in the presentation layer, and provide user interfaces for the logic plugins. Specifically, a portal plugin has control over the models and logs in the repository, while an editor plugin handles a single model. For example, the portal plugin for Structure allows users to select a model to structure, while the editor couterpart allows users to invoke the structuring logic directly from the editor interface and see the resulting structured model. These connections between plugins are implemented through OSGi dependencies. For example, the figure below shows the dependencies of the portal plugin for Structure (called “ibpstruct-portal”) from the Virgo Admin Console. We can see that this plugin depends, among others, on the logic plugin for Structure (called “ibpstruct-logic”).
OSGi dependencies for the Structure portal plugin, from the Virgo Admin Console
In order to simplify the development of new plugins, Apromore provides several plugin templates and examples which hide complex technical details that are essential for the correct management of plugins. This allows developers to focus only on the implementation of their algorithms.
We use jBPT in Apromore to capture the canonical process format as a set of Java libraries. The jBPT code library is a compendium of technologies that support the design, execution, and evaluation of business process models. The library offers a broad range of basic analysis and utility functionality such as different graph abstractions to capture business processes, and, due to its open publishing model, can easily be extended.
Finally, we use YourKit to profile our code. YourKit supports open source projects with its full-featured Java Profiler. YourKit, LLC is the creator of YourKit Java Profiler and YourKit .NET Profiler, innovative and intelligent tools for profiling Java and .NET applications.
Apromore is licensed under LGPL version 3.0. Relicense opportunities are possible. If interested, contact Prof. Marcello La Rosa at marcello.larosa_AT_unimelb.edu.au.