Category Archives: Architecture

Architecture Development

Using Hadoop as an Archive Solution

In the Imixs-Workflow project we are currently working on a new archive solution to archive business data into a big data storage. The main goal is to store business data over a very long period of time (10 to 30 years). Therefore we evaluate different big data solutions and concepts to be integrated with the Imixs-Workflow system. read more »

Architecture News

JSON Web Token and JASPIC

The Imixs Project started a new JSON Web Token project called Imixs-JWT.

Imixs-JWT is a compact easy to use library to generate and verify JSON Web Tokens. The library is based on maven and can be add with the following dependency available from Maven Central:

<dependency>
 <groupId>org.imixs.jwt</groupId>
 <artifactId>imixs-jwt</artifactId>
 <version>1.0.0</version>
</dependency>

The following example shows how to build a JWT in Java:

import org.imixs.jwt.*;
import java.security.InvalidKeyException;
import java.security.NoSuchAlgorithmException;
import javax.crypto.SecretKey;

...
// We need a signing key...
SecretKey secretKey = HMAC.createKey("HmacSHA256", "secret".getBytes());
String payload="{\"sub\":\"1234567890\",\"name\":\"John Doe\",\"admin\":true}";
JWTBuilder builder = new JWTBuilder().setKey(secretKey).setJSONPayload(payload);
System.out.println("JWT=" + builder.getToken());

// will result in:
// eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
// eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.
// TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

 

JASPIC Auth Module for JWT

The project also provides a JASPIC authentication module. JASPIC is an authentication standard and can be used in Java EE application servers. The module was tested with Wildfly 10 and can be used also with different application servers.

 

 

Architecture

Why Imixs-Workflow Builds on Java EE

The Open Source Workflow Project Imixs-Workflow has started in 2007 with the beginnings of the new Java EE platform. From then until now, th Java Enterprise Platform has evolved dramatically and is today, with its current version v7, a robust and widely used enterprise architecture.

Why is it so important to our Open Source project to build on Java EE? read more »

Architecture Development

How to use Environment Variables in WildFly Docker Containers

When setting up a Wildfly server, it is possible to use environment variables in the standalone.xml file by using the Bean Shell expression.

See the following example which sets up the database, user and password in a database configuration in the standalone.xml file by accessing environment variables:

<datasource jta="true" jndi-name="java:/jdbc/my_datasource" pool-name="my_pool" enabled="true" use-ccm="true">
    <connection-url>${env.POSTGRES_CONNECTION}</connection-url>
    <driver-class>org.postgresql.Driver</driver-class>
    <driver>postgresql</driver>
    <security>
      <user-name>${env.POSTGRES_USER}</user-name>
      <password>${env.POSTGRES_PASSWORD}</password>
    </security>
</datasource>

With the Bean Shell expression it is not necessary to turning parameters into System Properties: just use the expression:

${env.SYSTEM_ENVIRONMENT_VAR}

Especially when running wildfly in a docker container, this can be very helpful, because you can pass through environment variables to the container:

docker run --name="wildfly" -d -p 8080:8080 -p 9990:9990 \
    -e WILDFLY_PASS="admin_password" \
    -e POSTGRES_USER="my-postgres-user" \
    -e POSTGRES_PASSWORD="mypassword" \
    -e POSTGRES_CONNECTION="jdbc:postgresql://postgres/mydb" \
    imixs/wildfly

Also in combination with docker-compose environment variables can be set in the docker-compose.yml file. See the next example of a docker-compose.yml file, which sets up a postgres service and a wildfly service with a connection pool configuration as defined before in the standalone.xml:

postgres:
 image: postgres:9.6.1
 environment:
 POSTGRES_PASSWORD: mypassword
 POSTGRES_DB: mydb

mywildflyservice:
 image: imixs/mywildfly
 environment:
 POSTGRES_USER: "my-postgres-user"
 POSTGRES_PASSWORD: "mypassword"
 POSTGRES_CONNECTION: "jdbc:postgresql://postgres/mydb"
 ports:
 - "8080:8080"
 - "9990:9990"
 - "8787:8787"
 links: 
 - postgres:postgres

This is an example, which we use in combination with the wildfly docker container provided by the Imixs-Workflow project.

Architecture Development

Don’t model Business Behavior in Objects!

During the past years I saw many projects where nearly any kind of business requirements was modeled into the technical object model, independent of the reason of the requirement. In many cases, modelling business requirements into a technical object model is quite ok and I agree with it in general. But also modelling business requirements into the affected business objects can lead into a ugly and complicated data structure. Let’s look into a short example to illustrate my thoughts: read more »

Architecture

How to Integrate Imixs-Workflow with Single Sign On

Imixs-Workflow can now be easily combined with the Open Source Identity and Access Management solution Keycloak. Keycloak is an Open Source Identity and Access Management Server which can be used together with Wildfly to authenticate users with a modern authentication mechanism based on OpenID Connect SAML and OAuth. This is a short tutorial how to setup the Single Sign On Server Keycloak and configure the Imixs-Workflow to authenticate users. read more »

Architecture Development

How to secure Business Objects

This post explains how you can secure your business objects in a model driven way, using the Imixs-Workflow engine.

Most applications deal with security in a functional way. This means that a business application typically defines different functional roles which are mapped to different users. For example let’s look on a simple Ordering System. In an Ordering System, we will have roles like

  • Order-Creator‘ – creating the order
  • Order-Approver‘ – validating and approving
  • Order-Executor‘ – execution

These roles are typical for such an business application and mostly tightly coupled to the corresponding business methods – e.g. createOrder(), approveOrder() and executeOrder(). This works well in a monolithic business application where you can control the security layers as also the business logic. But as more complex the business application becomes, also the enclosed security becomes more complicated. For modern application design, in addition, you often have to deal with external web services and business logic which need to be adapted easily to changing requirements. So this static security model leads into a hell of hard coded business rules or, what is worse, can no longer guarantee the security. read more »

Architecture Development

How to Run a Custom Build of Imixs-Office-Workflow Using Docker

The Imixs-Workflow project supports Docker and provides also a Docker image for the workflow management suite ‘Imixs-Office-Workflow‘. Imixs-Office-Workflow provides a full featured business process management suite and can also be used to be extended in various ways. With Docker it becomes easy to setup a custom build for development, test and productive environments.

Setup a New Custom Build

To setup a new custom build of Imixs-Office-Workflow you can use the Imixs-Office-Archetype maven project, which provides a simple starting point for custom development. To run you custom build using Docker you should add a docker folder into your project with the following structure:

-/.data
-/.deployments
-/configuration
 |-standalone.xml
-docker-compose.yml
-Dockerfile

Customize Wildfly standalone.xml

First you can use the standalone.xml file located in the /configuration folder to configure your wildfly server to your project needs. Typically this will be a data-pool configuration and a security realm. This is an example of a custom database pool configuration which can be run in a docker container to access a postgres database running in another Docker container:

...
  <datasource jta="true" jndi-name="java:/jdbc/office-test" pool-name="office-test" enabled="true" use-ccm="true">
 <connection-url>jdbc:postgresql://postgres/office-test</connection-url>
 <driver-class>org.postgresql.Driver</driver-class>
 <driver>postgresql-9.3-1102.jdbc41.jar</driver>
 <security>
 <user-name>postgres</user-name>
 <password>adminadmin</password>
 </security>
 <validation>
 <validate-on-match>false</validate-on-match>
 <background-validation>false</background-validation>
 </validation>
 <timeout>
 <set-tx-query-timeout>false</set-tx-query-timeout>
 <blocking-timeout-millis>0</blocking-timeout-millis>
 <idle-timeout-minutes>0</idle-timeout-minutes>
 <query-timeout>0</query-timeout>
 <use-try-lock>0</use-try-lock>
 <allocation-retry>0</allocation-retry>
 <allocation-retry-wait-millis>0</allocation-retry-wait-millis>
 </timeout>
 <statement>
 <share-prepared-statements>false</share-prepared-statements>
 </statement>
 </datasource>
 ...

Note that the connection-url points to the host ‘postgres’ which need to be linked later to this container.

The Dockerfile

Next you can create a custom Dockerfile to describe you Imixs-Office-Workflow container for your custom build:

FROM imixs/office-workflow:latest
# add custom standalone.xml file
ADD configuration/standalone.xml /opt/wildfly/standalone/configuration/

The Dockerfile is quite simple. It extends the office imixs/office-workflow container and adds the new custom configuration file standalone.xml into the container

Docker-Compose

We use now docker-compose to describe the environment where we run a PostgreSQL Server, a WildFly Application Server and our custom build of Imixs-Office-Workflow.

 postgresloml:
  image: postgres:9.4.6
  environment:
    POSTGRES_PASSWORD: adminadmin
    POSTGRES_DB: office-test
  volumes:
    - ./.data/db:/var/lib/postgresql/data

 officetest:
  build: .
  environment:
    WILDFLY_PASS: adminadmin
  ports:
    - "8080:8080"
    - "9990:9990"
  links: 
    - postgresloml:postgres
  volumes:
   - "./.deployments:/opt/wildfly/standalone/deployments"

The docker-compose.yml file describes the PostgreSQL container with a custom database named ‘office-test’ (see the standalone.xml file), and a new imixs/ofifce-workflow container running our custom build of Imixs-Office-Workflow. The volumes parameter binds the local ./deployments/ folder which is used for autodeployments our application artifacts and also to configure hot-deployment during the development phase.

To start the environment simply run:

docker-compose up

That’s it! Now you can deploy your application aretfact of Imixs-Office-Workflow together with ah postgresql-jdbc.jar file into the local ./deploymetns folder.

After you access Imixs-Office-Workflow from your web browser (http://localhost:8080/office-test) the default user account ‘admin’ with the default password ‘adminadmin’ will be created and can be changed from the Admin section

 

Architecture Development

Docker-Compose – How To Install

The Imixs-Workflow project supports Docker and provides several Docker containers to run business applications like Imixs-Office-Workflow on a Docker host. A business application like Imixs-Office-Workflow requires to start different containers to separate the database form the application/web server. With the help of the Docker Tool ‘Docker-Compose’ the  definition of multi-container Docker applications is quite simple. The Imixs project provides different Docker-Compose definitions stored in a docker-compose.yml file.

The Installation

The following installation guide is written for linux users. For other plattforms see the installation guide here.

Fist download docker-compose sources from GitHub and change mod with the following command:

curl -L https://github.com/docker/compose/releases/download/1.7.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
 chmod +x /usr/local/bin/docker-compose

After installation you should verify the installation with the following command::

docker-compose --version

this should result in something like:

docker-compose version 1.7.0, build 0d7bf73

How to downgrade the docker-compose

Depending on you docker installation it can be result in a version conflict between Docker and Docker-Compose after a manual installation. You will see an errer message when starting docker-compose like the following:

client and server don't have same version (client : 1.18, server: 1.17)

In this case you can easily install a lower version of docker-compose with the curl command as shown above.

Run Docker-Compose

After you have installed Docker-Compose successfully you can start a multi-container Docker application with the following command:

docker-compose up

You can run the containers in background:

docker-compose up -d

to stop all containers run:

docker-compose stop

 

 

Architecture Development

BPMN Versioning

Running BPMN models in a BPM system often requires to take care about the internal version of a BPMN model. This occurs, for example, in scenarios where you run multiple instances of an active process in a live system with different versions of the same BPMN model.

The Imixs-Workflow Engine provides a nice mechanism to manage different versions of a BPMN 2.0 model. This allows to setup complex production environments with different models and different model versions at the same time. A model version, which is placed as an extension element of a BPMN 2.0 model can be evaluated by the Imixs-Workflow engine:
imixs-bpmn-versioning
read more »