Today I released version 4.2.6 of Imixs-Workflow. The new release is prepared for the Imixs-Archive feature which is the next big thing in Imixs-Workflow. The new version also includes some improvements of the Rest API and several bug fixes. The release notes can be seen on GitHub.
Running Payara and PostgreSQL in Docker
To setup a docker stack with Glassfish/Payara Server and a PostgreSQL Database Server is really easy, as the Payara project provides a good designed docker container. In the following short tutorial I will explain how to setup a simple development environment with a Glassfish/Payara server and a PostgreSQL Database. Continue reading “Running Payara and PostgreSQL in Docker”
New Version of Open Source Workflow Engine
In these days I released the latest version 4.2.0 of the human-centric open source workflow engine Imixs-Workflow.
With version 4.2.0, the second minor release of Imixs-Workflow version 4 is now available. After the stability and performance improvements of version 4 were confirmed with the minor update 4.1, now the first feature update has been released. Imixs-Workflow 4.2 offers a number of additional features and technical improvements. You can join the project on GitHub.
JCA and Wildfly 10
In the last few days, I struggled to implement my first JCA adapter. My goal was a solution for a transactional access to external Systems like Hadoop or Lucene from my Java EE application. As I finally succeed, I try here to answer some my own questions: Continue reading “JCA and Wildfly 10”
JSF – RequestScoped CDI Beans and Imixs-Workflow
You can use Imixs-Workflow with a RequestScoped CDI Bean in JSF easily. The thing which is important is that you add two hidden fields into your form containing the $uniqueid and $version.
<!-- Workflow Events -->
<ui:repeat var="event" value="#{workflowController.events}">
<h:commandButton action="#{workflowController.process}"
value="#{event.item['txtname']}">
<f:setPropertyActionListener
target="#{workflowController.workitem.item['$ActivityID']}"
value="#{event.item['numactivityid']}" />
</h:commandButton>
</ui:repeat>
<h:inputHidden value="#{workflowController.workitem.item['$uniqueid']}" />
<h:inputHidden value="#{workflowController.workitem.item['$version']}" />
This mechanism ensures that the form can not be posted back to the server if the workitem was processed in the meantime. This situation can occur if the user opens the same workitem in multible browser tabs and tries to submit the same workitem form different tabs without refreshing the content. It also secures the situation when the user opens different worktiems in different tabs and tries to submit.
The Imixs-JSF project still uses ConversationScoped CDI Beans. The reason is an issue with the fileUploadController. But I think we will got back to RequestScoped also for the workflowController CID Bean in the future.
Deploy Gitbucket on Wildfly
When trying to deploy the Gitbucket project into wildfly I go tthe following error message:
WARN [org.jboss.modules] (ServerService Thread Pool -- 81) Failed to define class liquibase.serializer.core.yaml.YamlSerializer$LiquibaseRepresenter in Module "deployment.gitbucket.war:main" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link liquibase/serializer/core/yaml/YamlSerializer$LiquibaseRepresenter (Module "deployment.gitbucket.war:main" from Service Module Loader): org/yaml/snakeyaml/representer/Representer ...
This is a known issue and discussed here.
You can fix it if you add the file ‘jboss-deployment-structure.xml’ into the WEB-INF/ folder with the following content:
<jboss-deployment-structure> <deployment> <dependencies> <system export="true"> <paths> <path name="com/sun/net/ssl/internal/ssl" /> <path name="com/sun/net/ssl" /> </paths> </system> <!-- add snakeyaml dependency --> <module name="org.yaml.snakeyaml"/> </dependencies> </deployment> </jboss-deployment-structure>
How to install:
The following is a short install guide how to modify the gitbucket.war downloaded form the project release page:
1.) Download latest version from release page:
wget https://github.com/gitbucket/gitbucket/releases/download/4.7.1/gitbucket.war
change the version if needed
2.) unzip the war file
unzip gitbucket.war -d tmp/gitbucket.war
3.) create the ‘jboss-deployment-structure.xml’ file and add the content as explained above. Than copy the file into the WEB-INF folder
cp jboss-deployment-structure.xml /tmp/gitbucket.war/WEB-INF/
4.) create the doDeploy file
touch tmp/gitbucket.war/gitbucket.war.dodeploy
5.) start deployment by moving the folder to the wildfly deploy directory
cd tmp/ mv gitbucket.war /opt/wildfly/standalone/deployments/
Install Script
You can use also my install script from here to install gitbucket on Wildfly 9.x & 10.x under Linux.
/bin/bash wildfly-install.sh [INSTALLDIR] [GITBUCKET-VERSION]
You can specify the install directory of your wilfly installation and the gitbucket version.
Example:
/bin/bash wildfly-install.sh [INSTALLDIR] [GITBUCKET-VERSION]
Note: The script must be run as root. The script assumes that wildfly is running with the user ‘wildfly’. You can change this in your script if needed.
Why we should secure Business Objects?
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 we 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 we 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. Continue reading “Why we should secure Business Objects?”
Wildfly – Install PostgreSQL JDBC Driver as a Module
Instead of deploying a JDBC driver with the wildfly auto-deploy feature, the driver can be alternatively installed as an module. This is also necessary to be used with XA-Datasources. So it is a recommended way to install the driver as a module. The following section shows how to a jdbc driver module is created. Continue reading “Wildfly – Install PostgreSQL JDBC Driver as a Module”
JPA and @OneToMany – How to Optimize?
In this article I want to explain an issue concerning the JPA OneToMany relationship which I was faced with in one of my own projects. Working with object -orientated languages like java we often model relationships between object in various cases. One of such relationships is the OnToMany relationship. For example an object ‘Server’ may have a relationship to an object ‘Configuration’. To make the ‘Configuration’ object generic we can model the JPA object in Java like this:
@javax.persistence.Entity
public class Configuration implements java.io.Serializable {
private static final long serialVersionUID = 1L;
@Id
@GeneratedValue
private BigInteger id;
public String itemValue;
public String itemName;
@SuppressWarnings("unused")
private Configuration() {
}
public Configuration(String name, String value) {
itemValue = value;
itemName = name;
}
}
Microservices, Verticals and Business Process Management?
If you think about modern architecture, you will possibly find that one of the best solution (for the moment) seems to be a microservice architecture. Microservices are a quite different approach as we followed in the past, where we often designed monolithic enterprise applications. In a monolithic application context a single software system is encapsulating the business-logic, the database-layer and the UI components. The Java EE architecture provides a perfect framework to build such kind of applications to be deployed and executed in a scalable and transactional application server environment.
But monolithic enterprise applications are sometimes difficult to maintain, even if only little changes need to be made to one of its components. This is one reason why the idea came up to split a monolithic application block into several microservices.
One of the question is, how to change the architecture from a monolith approach to a modern service based architecture? A good overview what this means can be read in Christians Posta’s Blog.
Vertical Services
At the first look it seems to be easy to separate business logic into isolated services. But often this approach ends with a closely spaced set of microservices, which are not really loose coupled. One of the reasons can be the database layer which survives as a monolithic block behind all the new microservices. This happens when we think that database objects are related to each other. And this is only a very realistic picture of our real business world. But this creates complex synchronization points between all of our services and teams and you have to coordinate all of the changes in the database layer. Often a database change caused by one service affects also other services.
One solution to solve this problem can be, dividing the functionality into cohesive “verticals”, which are not driven by technical or organizational aspects. Each vertical will have its own “business logic”, “database” and an optional “UI component”. With this approach, we don’t need to re-deploy the entire monolithic business-service tier, if we made changes to a single database object or a functionality of one of these verticals. Ideally, a single team can own and operate on each vertical as well.
Usually, it is recommended to control the synchronization between the services by sending events. The approach behind this idea is the “Reactive Programming” style. The communication between the services is realized in an asynchronous way . So the business logic of one service layer did not depend on the result of another service layer. A service may or may not react on a specific event. And this is the idea of loose coupling.
But does this fit your business requirements?
The “Business Process Service Architecture”
One problem with decoupling the business logic into separate services is the fact, that there still exists an “Over-All-Business-Logic” behind all these services. This is known as the “Business Process.” If, in our example above, the Order-Service, Invoice-Service and Logistic-Service are implemented as separate building blocks, there is still the general bussiness process of the “Ordering-Management” in the background defining states and business rules. For example if a product is ordered by a customer (Order-Service) the product may not be shipped (Logistic-Service) before an invoice was sent to the customer (Invoice-Service). So it is not sufficient, if the Invoice-Service and the Logistic-Service react asynchronously on a new event, triggered by the Order-Service, without reflecting the business process.
What we can do now, is defining separate events indicating each phase in the Order-Management-Process. For example the Order-Service can send an “Order-Ready-For-Invoice-Event” to signal that the invoice need to be send. And a new “Order-Ready-For-Shipment-Event” can be triggered by the Invoice-Service to indicate that the invoice for the order was sent to the customer and the product can be shipped. But now we have again created the same problem as we had before with the common database. We couple our services via specific event types which are reflecting our business process. The business process is now spread across various services.
To avoid this effect of tightly coupled services we can separate the business process itself as a service. This means that we move the Over-All-Business-Logic out of our services and provide a separate new service layer reflecting only the business process.
I will call this a “Business-Process-Service-Architecture”. In this architecture style each service layer depends on the business-process-service. Events are sent only between a vertical and the Business-Process-Service layer. Our Order-Service, Invoice-Service and Logistic-Service may or may not react on those process events. The advantage of this architecture is, that we now have one service which controls the ordering management process and is reflecting the state for each process instance. Each vertical can call the business-service layer to query the status of the Over-All-Business-Process and also use these workflow information for further processing. Also we can change our business process independent from our vertical service layers.
BPMN 2.0 and Workflow Engines
One of the most common technologies to describe a business process is the ‘Business Process Model and Notation’ – BPMN 2.0 standard. BPMN was initially designed to describe a business process without all the technical details of a software system. A BPMN diagram is easy to understand and a good starting point to talk about a business process with technician as also with management people. Beside the general description of a business process, a BPMN model can also be executed by a process or workflow engine. The Workflow Management System controls each task from the starting point until it is finished. So based on the model description the workflow engine controls the life-cycle of a business process. An example of a workflow engine which can be integrated into a Business Process Service Architecture is the Open Source project Imixs-Workflow.
Beside the general control of the business process, our new service can also collect any kind of meta information from our verticals. The service becomes the central information point in our microservice architecture. We can now change our business process model and integrate new verticals without affecting existing implementations. We have finally decoupled our services. This is one of the most important effects you can achieve with this architecture style. In a future article I will show an example how to integrate a Business Process Service based on a RESTfull service interface.
Continue Reading: How to Design a Business Process Service Architecture