When trying to apply SY services to our drools based solution, we found that we needed an specific solution which was really difficult (or impossible) to implement in the current SY Rules service.
Basically, we needed the possibility:
-Adding rules dinamically and incrementally to the Kie Base. There is easy no way to access to the Kie Container to update.
-Be able to access to the Kie Sessions, to create new Kie Sessions and add the rules to some of the Kie Sessions. We needed control over the created kie sessions. When a new rule set (List of DRL) arrives, we need to create a new Kie Session with these rules, and register this new session.
-Route messages to different Kie Sessions. Then, at the moment of using the rules, some events and facts will arrive. We needed the possibility of receiving them from some service, and route it to the correct kie sessions.
The solution we implemented was based on Bean Services. We implemented a Bean Service for Drools Session Management, and then another for Content Routing, which basically decides which kie sessions will be interested in the received data.
Possible out of the box solutions to gain flexibility
There could be some posibilities to give more control to the out of the box SY solution. The following are some of them, but there could be much more.
-Expose the Kie Containers so that they can be used from the rules. Using this, for example, there could be a rule that gets a kie container, and updates it with new rules for example. The list of Kie Containers could be exposed as a global of a top level kie container.
-There could be a way to access to the session management level in SY. For example, this level:
could be allowed to be overriden by configuration so that the user can provide his own session management implementations, and by default using the same it is using.