środa, 27 lipca 2016

Knowledge Driven Microservices

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.



Presentation at DevConf.cz



In case you'd like to explore the code or run it yourself have a look at the complete source code of this demo in github.

9 komentarzy:

  1. Thanks for writing such a wonderful article. Can you please let us know how to get the process output to Drools Rules. We are thinking of execution of atomic processes using Drool Rules i.e. Drool as a controller. But we are facing issue in getting output of processes back to rule. Can you let us know how to do it. We thought of using DB for sharing the output so rule will have to go to DB to check output of processes and decide the next flow.

    OdpowiedzUsuń
    Odpowiedzi
    1. I would go for implementing ProcessEventListener (afterProcessCompleted event is relevant) and then push out data you need (most likely from process variables) into vert.x cluster so drools can pick it up and process it. I'd rather not use db for this as it does not fit into loose coupling approach and is more of a pull style rather event driven.

      Usuń
    2. Thanks Maciej, we are able to get the process output using ProcessEventListener and depending on the first output and rules, we are starting another process.

      I have another questions on it...
      We have facts inserted to node1-kieServer and after executing 3rd rule it went down and auto fail-over should happen to node2. How will it be taken care in KieServer?

      Also how to auto persists Drools Stateful Ksession to DB.

      Thanks
      Sandip Desale

      Usuń
    3. if we talk about rule execution in kie servers as long as you will use stateless session that will not differ as you will have to use load balancing of any kind to route it only to active nodes. Stateful sessions will be gone meaning data/facts in the node that went down won't be persisted in anyway.

      Persistence of ksession is currently not supported in rule extension of kie server due to potential problems with performance as the current persistence is based on JPA and complete serialisation of all facts which is real cases is not practical as it takes too much time.

      Usuń
  2. Thanks for suggestion. Let us look into it more.

    OdpowiedzUsuń
  3. Maciej - Going trough the presentation, my understanding of this architecture is that it would require using the drools & bpm engines in an embedded style not via a KIE REST deployment. Can you please confirm or not my supposition?

    OdpowiedzUsuń
    Odpowiedzi
    1. Cristian, correct as the main purpose of this sample is to have jbpm and drools running in VERT.X environment though you could create KIE Server extension that would the other way around - kie server joins vert.x world instead.

      Usuń
    2. Thank you Maciej, appreciate you feedback. Yes, that was my presumption also, to integrate Vert.X with KIE Server Verte.X nodes should act as regular REST consumers of KIE exposed services. I like the idea - I find it awesome, of having actually the bpm/rules engines running as native Vert.X nodes, this would scale very well for heavily intensive cases where lots of bpm/rules should be deployed as micro-services. Are you guys planning to evolve this architecture in an actual KIE IO/microservice product deployment version additional to the legacy JEE flavor?

      Usuń
    3. thanks, t does work nicely and provide a lot of options to utilize business knowledge (rules and process) with vert.x for high scalable services.
      At the moment there are no immediate plans for this as there is huge backlog of other tasks ahead of us though there are other works around that - there was recently webinar with more advanced and up to date vert.x with bpm (https://www.redhat.com/en/about/events/business-process-management-microservices-world) though can't find any recording of it..and I haven't watched it either :(

      Usuń