↑ Return to Platform

Architecture

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’s software architecture

The Apromore platform is implemented via a service oriented architecture and deployed over the internet as a Software as a Service. The core service is the Repository Manager. This service exposes all the repository features via WSDL operations for integration with third-party applications, e.g. an external BPM System such as ARIS.

Apromore offers a standard client to access these features. This client is the Portal, a Web mashup able to render on screen all features internally provided by Apromore through dedicated user interfaces. In turn, the Portal communicates with the Editor to allow users to modify the process models in the repository, or create new ones.

The Canonizer is responsible for canonizing process models (i.e. converting them into Apromore’s canonical process format) as they are imported into the repository, or to de-canonize these process models back to a native format (e.g. XPDL, EPML, AML) as they are exported from the repository. The Canonizer is equipped with a plug-in interface such that new formats can be supported simply by dumping new plug-ins into Apromore.

The Toolbox is a facade over the advanced features that can be performed on the stored process model collections, such as filtering the models according to their similarity or merging them in a new model. Similarly to the Canonizer, this service offers a plug-in interface for new features to be added to Apromore on the fly.

Access to the models stored in Apromore is achieved via the Data Access service which encapsulates data-centric operations for reading/writing data upon requests made by the other services.

Finally, the Security Manager controls security aspects such as user authentication and authorization.

Technology

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

virgo

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.

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.

yklogo

License

Apromore is licensed under LGPL version 3.0.