As a follow up of previous articles about KIE Server, I'd like to present the extensibility support provided by KIE Server. Let's quickly look at KIE Server architecture...
Extensions overview
KIE Server is built around extensions, every piece of functionality is actually provided by extension. Out of the box we have following:- KIE Server extension - this is the default extension that provides management capabilities of the KIE Server - like creating or disposing containers etc
- Drools extension - this extension provides rules (BRMS) capabilities, e.g. allows to inserting facts and firing rules (among others)
- jBPM extension - this extensions provides process (BPMS) capabilities e.g. business process execution, user tasks, async jobs
- jBPM UI extension - added in 6.4 additional extension that depends on jBPM extension and provides UI related capabilities - forms and process images
With just these out of the box capabilities KIE Server provides quite a bit of coverage. But that not all... extensions provide the capabilities but these capabilities must be somehow exposed to the users. And here KIE Server comes with two transports by default:
- REST
- JMS
Due to a need to be able to effectively manage extensions in runtime these are packaged in different jar files. So looking at the out of the box extensions we have following modules:
- Drools extension
- kie-server-services-drools
- kie-server-rest-drools
- jBPM extension
- kie-server-services-jbpm
- kie-server-rest-jbpm
- jBPM UI extension
- kie-server-services-jbpm-ui
- kie-server-rest-jbpm-ui
All above modules are automatically discovered on runtime and registered in KIE Server if the are enabled (which by default they are). Extensions can be disabled using system properties
- Drools extension
- org.drools.server.ext.disabled = true
- jBPM extension
- org.jbpm.server.ext.disabled = true
- jBPM UI extension
- org.jbpm.ui.server.ext.disabled = true
But this is not all... if someone does not like the client api a client api can also be extended by implementing custom interfaces. This is why there is an extra step needed to get remote client:
kieServerClient.getServicesClient(Interface.class)
Why extensions are needed?
Let's not look at why would someone consider extending KIE server?
- First and foremost is there might be missing functionality which is not yet implemented in KIE Server but exists in engines (process or rule engine).
- REST extension
- Another use case is that something should be done differently than it is done out of the box - different parameters and so on..
- client extension
- Last but not least, it should be possible to extend the transport coverage meaning allow users to add other transports next to REST and JMS.
- server extension
With this users can first of all, cover their requirements even if the out of the box KIE Server implementation does not provide required functionality. Next such extensions cane contributed to be included in the project or can be shipped as custom extensions available for other users.
This benefits both project and users so I'd like to encourage every one to look into details and think if there is anything missing and if so try to solve it by building extensions.
Let's extend KIE Server capabilities
Following three articles will provide details on how to build KIE Server extensions:
- Extend existing server capability with extra REST endpoint
- Extend KIE Server with additional transport
- Extend KIE Server client with new capabilities
... time to start the work :)
Important note: While most of the work could be achieved already with 6.3.0.Final I'd strongly recommend to give it a go with 6.4.0 (and thus all dependencies refer to 6.4.0-SNAPSHOT) as the extensions have been simplified a lot.
