In the area of microservices more and more people are looking into lightweight and domain IT solutions. Regardless of how you look at microservice the overall idea is to make sure it does isolated work, don't cross the border of the domain it should cover.
That way of thinking made me look into it how to leverage the KIE (Knowledge Is Everything) platform to bring in the business aspect to it and reuse business assets you might already have - that is:
business rules
business process
common data model
and possibly more... depending on your domain
In this article I'd like to share the idea that I presented at DevConf.cz and JBCNConf this year.
Since there is huge support for microservice architecture out there in open source world, I'd like to present one set of tools you can use to build up knowledge driven microservices, but keep in mind that these are just the tools that might (and most likely will) be replaced in the future.
Tools box
jBPM - for process management
Drools - for rules evenalutaion
Vert.x - for complete application infrastructure binding all together
Hazelcast - for cluster support for distributed environments
Use case - sample
Overall use case was to provide a basic back loan solution that process loan applications. So the IT solution is partitioned into following services:
Apply for loan service
Main entry point to the loan request system
Allow applicant to put loan request that consists of:
applicant name
monthly income
loan amount
length in years to pay off the loan
Evaluate loan service
Rule based evaluation of incoming loan applications
Low risk loan
when loan request is for amount lower that 1000 it’s considered low risk and thus is auto approved
Basic loan
When amount is higher than 1000 and length is less than 5 years - requires clerk approval process
Long term loan
When amount is higher than 1000 and length is more that 5 years - requires manager approval and might need special terms to be established
Process loan service
Depending on the classification of the loan different bank departments/teams will be involved in decision making about given loan request
Basic loans department
performs background check on the applicant and either approves or rejects the loan
Long term loans department
requires management approval to ensure a long term commitment can be accepted for given application.
Architecture
Each service is completely self contained
Knowledge driven services are deployed with kjar - knowledge archives that provide business assets (processes, rules, etc)
Services talks to each other by exchanging data - business data
Services can come and go as we like - dynamically increasing or decreasing number of instances of given service
no API in the strict sense of its meaning - API is the data
More if you're interested...
Complete presentation from JBCNConf and video from DevConf.cz conference.
As part of ongoing development of jBPM version 7 I'd like to give a short preview of one of the changes that are coming. This in particular relates to changes how workbench and kie server are integrated. In version 6 (when kie server was introduced with BPM capability) we have had two independent execution servers:
one embedded in workbench
another in in kie server
in many cases it caused bit of confusion as users were expecting to see processes (and tasks, jobs etc) created in kie server vie workbench UI. To achieve that users where pointing workbench and kie server to same data base and that lead to number of unexpected issues as these two were designed in different way and were not intended to work in parallel.
jBPM version 7 is addressing this problem in two ways:
removes duplication when it comes to execution servers - only kie server will be available - no execution in workbench
integrates workbench with kie server(s) so its runtime views (e.g. process instances, definitions, tasks) can be used with kie server as backend
While the first point is rather clear and obvious, the second takes a bit to see its full power. It's not only about letting users use workbench UI to start processes or interact with user tasks, it actually makes the flexible architecture of kie server to be fully utilized (more on kie server can be found in previous blog series).
In version 6.4 there was new Server Management UI introduced to allow easy and efficient management of kie servers. This came with concept of server templates - that is a definition of the runtime environment regardless of how many physical instances are going to run with this definition. That in turn allow administrators to define partitioned environment where different server templates are representing different part of the organization or domain coverage.
Server template consists of:
name
list of assigned containers (kjars)
list of available capabilities
Once any kie server starts and connects to workbench (workbench acts as controller) then it will be presented in server management under remote servers. Remote servers reflects the current state of controller knowledge - meaning it only changes the list upon two events triggered by kie servers:
start of the kie server in managed mode - which connects to controller and registers itself as remote server
shutdown of the kie server in managed mode - which notifies controller to unregister itself from remote servers
With this setup users can create as many server templates as they need. Moreover at the same time each server template can be backed by as many kie server instances as it needs. That gives the complete control of how individual server templates (and buy that part of your business domain) can scale individually.
So enough of introduction, let's see how it got integrated for execution. Since there is no more execution server embedded in workbench, all that needs it will be carried on by kie server(s). To accomplish this workbench internally relies on two parts:
server management (that maintains server templates) to know what is available and where
kie server client to interact with remote servers
Server management is used to collect information about:
server templates whenever project is to be deployed - regardless if there are any remote servers or not - again this is just update to the definition of the server
remote servers whenever kie server interaction is required - start process, get process instances, etc
NOTE: in case of multiple server templates are available there will be selection box shown on the screen so users can decide which server template they are going to interact with. Again, users do not care about individual remote servers as they represent same setup so it's not important which server instance will be used for given request, as long as one of them is available.
Server templates that do not have any remote servers available won't be visible on the list of server templates.
And when there is only one server template selection is not required and that one becomes the default - for both deployment and runtime operations.
On right top corner users can find server template selection button in case there are more than one server template available. Once selected it will be preserved across screen navigation so it should be selected only once.
Build & Deploy has been updated to take advantage of the new server management as well, whenever users decide to do build and deploy:
if there is only one server template:
it gets selected as default
artifact name is used as container id
by default container is started
if there are more than one server templates available user is presented with additional popup window to select:
container id
server tempalte
if container should be started or not
That concludes the introduction and basic integration between kie server and workbench. Let's now look what's included and what's excluded from workbench point of view (or the differences that users might notice when switching from 6 to 7).
First of all, majority of runtime operations are suppose to work exactly the same what, that includes:
Process definition view
process definition list
process definition details
Operations
start process instance (including forms)
visualize process definition diagram
Process instance view
process instance list (both predefined and custom filters)
process instance details
process instance variables
process instance documents
process instance log
operations
start process instance (including forms)
signal process instance (including bulk)
abort process instance (including bulk)
visualize process instance progress via diagram
Tasks instance view
task list (both predefined and custom filters)
task instance details (including forms)
life cycle operations of a task (e.g. claim, start, complete)
task assignment
task comments
task log
Jobs view
jobs list (both predefined and custom filters)
job details
create new job
depending on status cancel or requeue jobs
Dashboards view
out of the box dashboards for processes and tasks
All of these views retrieve data from remote kie server so that means there is no need for workbench to have any data sources defined. Even the default that comes with wildfly is not needed - not even for dashboards :) With that we have very lightweight workbench that comes with excellent authoring and management capabilities.
That leads us to a last section in this article that explains that changed and what was removed.
Let's start with changes that are worth noting:
asynchronous processing of authoring REST operations has been moved from jbpm executor to UberFire async service - that makes the biggest change in cluttered setup where only cluster member that accepted request will know its status
build & deploy from project explorer is unified - regardless if the project is managed or unmanaged - there are only two options
compile - which does only in memory project build
build and deploy - which includes build, deploy to maven and provision to server template
Now moving to what was removed
since there is no jbpm runtime embedded in workbench there is no REST or JMS interfaces for jBPM, REST interfaces for the authoring part is unchanged (create org unit, repository, compile project etc)
jobs settings is no longer available as it does not make much sense in new (distributed) setup as the configuration of kie servers is currently done on server instance level
ad hoc tasks are temporally removed and will be introduced as part of case management support where it actually belongs
asset management is removed in the form it was known in v6 - the part that is kept is
managed repository that allows single or multi module projects
automatic branch creation - dev and release
repository structure management where users can manage their modules and create additional branches
project explorer still supports switch between branches as it used to
asset management won't have support for asset promotion, build of projects or release of projects
send task reminders - it was sort of hidden feature and more of admin so it's going to be added as part of admin interface for workbench/kie server
Enough talking (... writing/reading depends on point of view) it's time to see it in action. Following are two screen casts showing different use cases covered.
Case 1 - from zero to full speed execution
Create new repository and project
Create data object
Create process definition with user task and forms that uses created data object
Build and deploy the project
Start process instance(s)
Work on tasks
Visualize the progress of process instance
Monitor via dashboards
Case 2 - from existing project to document capable processes
Create process instance to check weather in US based on zip code
Work on tasks
Visualize process instance progress - this project does not have image attached so it comes blank
Monitor via dashboards
Before we end a short note for these that want to try it out. Since we have integration with kie server and as you noticed it does not require any additional login to kie server and workbench uses logged in user, there is small need for configuration of Wildfly:
workbench comes with additional login module as part of kie-security.jar so to enable smooth integration when it comes to authentication, please declare in standalone.xml of your wildfly following login module:
so the default other security domain should look like this:
<security-domain name="other" cache-type="default">
<authentication>
<login-module code="Remoting" flag="optional">
<module-option name="password-stacking" value="useFirstPass"/>
</login-module>
<login-module code="RealmDirect" flag="required">
<module-option name="password-stacking" value="useFirstPass"/>
</login-module>
<login-module code="org.kie.security.jaas.KieLoginModule" flag="optional"
module="deployment.kie-wb.war"/>
</authentication>
</security-domain>
important element is marked with red as it might differ between environments as it relies on the actual file name of the kie-wb.war. Replace it to match the name of your environment.
NOTE: this is only required for kie wb and not for kie drools wb running on wildfly. Current state is that this works on Wildfly/EAP7 and Tomcat, WebSphere and WebLogic might come later...
That's all for know, comments and ideas more than welcome
