This article mainly talks about version 7 and onwards though some of the aspects are also applicable for version 6.
- Admin Console – is workbench (or it’s lighter version that includes only runtime views) with embedded controller
- Controller – is KIE Controller used with KIE Servers that are running in managed mode
- Smart Router – is a optional component that acts as kind of intelligent load balancer as it can both route requests to individual KIE Servers and aggregate data from different KIE Servers
- Managed KIE Server – KIE Server that is connected to Controller and takes the configuration from the controller, overriding anything it has locally (even included in the image)
- Unmanaged KIE Server – KIE Server that runs completely standalone, does not require any other component to be fully functional
- Managed Smart Router – router that is connected to Controller though it owns the right to dynamically update server template it represents
Architecture 1: Immutable unmanaged KIE Servers with Smart Router and Admin Console
This architecture is as cloud native as possible, it promotes the immutable execution servers paradigm that means both execution server itself and all KJARs should be colocated and included in the image itself (with all dependencies). That way any instance of that service (regardless when it starts) will always be identical.
It then uses Managed Smart Router to benefits from routing and aggregation. Smart Router will dynamically update Controller with new containers coming in so Admin Console can properly setup clients to interact with it.
In this architecture end users interact with KIE Servers always via Smart Router – either by using Admin Console and its runtime views or by another application.
Individual KIE Servers can come and go at anytime and register/unregister in the Smart Router. These KIE Servers might be with the same id – meaning representing the same image or different images. In this case (since images are immutable) they will represent other set of kjars.
As an example, let’s look at the diagram above:
- There are three KIE Servers behind the router – each represents independent image (meaning it has different kjars included)
- KIE Server – ABC
- KIE Server – DEF
- KIE Server – GHI
- There could be multiple instances of given KIE Server image – multiple PODs in OpenShift terminology
- KIE Server starts completely independent from each other and smart router (though it will constantly attempt to register in Smart Router in case it was not up at the time KIE Server started)
- KIE Containers to be started is included in the image
Architecture 2: Immutable managed KIE Servers with Admin Console and optionally Smart Router
Immutable managed architecture is slight variation of the first architecture though all KIE Servers are managed by controller thus Smart Router is then optional component as users can access individual KIE Servers directly as they are managed. Smart Router is needed when end users should be able to look at all KIE Servers at once instead of grouped by server template.
The images are still immutable, meaning they include KJARs that should be running, but the final word what set of KJARs (included in the image) should be started has controller. This is to secure that both Admin Console and KIE Server have same set of KIE Containers defined.
In practice, this architecture requires additional step in the deployment (as part of the deployment pipeline) to create immutable server template in the controller that would match kjars included in the image. Main reason for this is to protect the Admin Console from being affected by wrong image connecting with template id that it should not. So Admin Console completely relies on the controller configuration rather than runtime.
In this architecture, users can use both router or individual KIE Servers to interact with their capabilities. Same rules apply as for first architecture when it comes to KIE Server images and their instances. Whenever new instance of the KIE Server starts it register itself in the controller and optionally in the Smart Router.
Architecture 3: “Empty” managed KIE Servers with Admin Console and optionally Smart Router
Another architecture moves into another direction, instead of making the images immutable it promotes the dynamic behaviour of KIE Server. “Empty” KIE Server means that the image is without any KJARs included, it’s pure KIE Server runtime that when started has nothing deployed to it.
With managed capabilities, controller can dynamically instruct KIE Servers what needs to be deployed. So the additional deployment step (as in architecture 2) can be used. By making the server template immutable similar architecture as in 2 can be achieved, though it might be impacted by differences in downloaded artefacts – this might be especially visible in case snapshots are used.
Benefit is that there is single image of KIE Server used (per release version) that, when started, is given list of parameters that defines it behaviour:
- KIE Server ID that refers to server template in controller
- switches to turn off capabilities
- url to controller
- optionally url to smart router
Architecture 4: Immutable unmanaged KIE Servers with Smart Router
This is another aspect of the immutable images though simplified as there is no need for controller and thus Admin Console is not used. With that in mind users will still have KIE Server image per set of KJARs to ensure immutability though there is no “managed” client for it.
This architecture targets mainly setups where there will be other components (applications/services) interacting with KIE Servers via Smart Router.
KIE Servers behave exactly the same as in architecture 1 and allow to add new instances or images at any time. Smart Router will constantly update the routing table to make sure it provides access to all available server with efficient balancing.