WASP Architecture

Architecture

  • WASP Architecture

    The final product expected out of this development is a Workflow and Service Automation Platform. The platform will allow users to automate processes of different types such as manual processes carried out by people, software-based processes such as execution of (web) services, and manufacturing processes where machines are wrapped by a standard software interface. A combination of these process types is also allowed to be created in the platform.

    The idea is to offer the platform to users for automating their processes regardless of the actual type. Users then will be owners of their processes which can be personal or company-wide. Moreover, companies can belong to special groups (e.g. a supply chain) thus processes can go across companies. Consequently, user roles that go beyond a company scope will be enabled as well. Roles will help users specify governance of processes or parts of them. Special monitoring will also be included at different levels of granularity (e.g. activity, process, company, group).

    A SaaS / PaaS business and operation model are expected where users pay for a membership to automate their processes.

    Technical Specification

    Introduction

    This document presents the technical details of how the whole system is composed from the architectural point of view. Any software needed to run the platform are also indicated here together with any specific version numbers.

    System architecture

    Components are described below. For graphical representation, see Figure 1.

    · Camunda engine. This component is the core for controlling all processes. It tracks all process instances, process templates, activities and their execution. This is effectively the brain of the whole Workflow and Service Automation Platform. Communication occurs via REST API that sits on a Tomcat distribution; it has its own database.

    · Liferay portal. This component is a subsystem in its own right; it manages websites including user administration. It hosts the website with internal applications called portlets. Each portlet represents a distinct functionality/tool within our Workflow and Service Automation Platform.

    · Process editor portlet. This portlet sits inside the Workflow and Service Automation platform as an independent application. It allows the user to manage processes in a graphical way, where processes are based on BPMN 2.0 standard.

    · imgC:/Users/Mitch/AppData/Local/Temp/msohtmlclip1/01/clip_image003.png) Marketplace portlet. This portlet also sits inside the Workflow and Service Automation platform as an independent application. It allows the user to manage services for later use in processes.

    · Liferay DB. Database where website information and configuration are stored. Also, user data is stored there.

    · Camunda DB. Database where process information and any engine configuration are stored. No track of user exists in this one.

    · Access from Internet. This represents the only access point from the Internet, which is via a web browser.

    Required software

    · Compiler: Java, JDK 1.8

    · Liferay portal v7.2 – runs on Tomcat

    · Camunda engine v7.9 – runs on Tomcat

    · Tested in MySQL server v5.2-7

Previous
Next