Something to consider is how you want to scale. If you separate things, then you do have the advantage that you can scale out the web layer easily, whilst maintaining a long running session for your rules evaluation. On the other hand if your rules work well within stateless sessions, that's not so much of an issue, although as you mention, memory can be an issue. Rules engines such as Drools are hungry, so it can be a benefit to keep them separate from a more complex application which has its own heavy memory demands elsewhere.
One tip would be that if you go for the single application option, keep your rules evaluation in its own Maven jar project module, and a separate web/war module. At least this way, you can start with a single application, but you can break it up without too much trouble later. Steve On 6 Sep 2013, at 20:27, Genene Geda <[email protected]> wrote: > You said : Also we do not see drools serving multiple applications at this > point of time or in near future. > >> then, architecturally you may not need option #2. > > Genene > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of srikanthmalli > Sent: Friday, September 06, 2013 12:21 PM > To: [email protected] > Subject: Re: [rules-users] Integrate Drools with Java application, need > recommendations > > Thank you all for your valuable input. > It seems like performance is not the issue between the 2 options. So I really > need to see the differences between 2 options to make my decision. > It’s not going to be 100% rule based business logic, we evaluated whole > application and decided to use “rules based solution” where it makes sense. > To serve each request application will call drools in different point of > times few times (may be 6-8 times, all are atomic requests, sometimes > simultaneously) to make some business decisions. > Also we do not see drools serving multiple applications at this point of time > or in near future. > Option1: > 1) May need more coding on application (consumer) side to implement > 2) Application will have Drools specific coding and need to aware of Drools > libraries > 3) Debugging – easy to do as everything is Java > 4) Unit testing – easy to do as everything is Java, may need to write > TestNG/Junit test cases > 5) Load test/performance test – May need to write TestNG/Junit test cases > 6) How about memory, as the rules will be evaluating in same JVM as > application? > > Option2: > 1) Easy coding on the application (consumer) side to implement, just need > to > build REST/JSON request > 2) And application need not to be aware of any Drools libraries and Drools > specific coding > 3) Debugging – No idea on how to do > 4) Unit Testing – We have tool SoapUI so I don’t think it is a problem. > 5) Load/performance Test – We have tool SoapUI so I don’t think it is a > problem. > 6) How about memory, as the rules will be evaluating in different JVM than > application, wouldn’t it be helpful? > 7) Monitoring, one more thing to make sure it is up running. > > What is the value of implementing Webservice (spring and REST/SOAP based) to > handle the requests given the out of box Drools-Server, any specific reasons? > > -Sri > > > > > -- > View this message in context: > http://drools.46999.n3.nabble.com/Integrate-Drools-with-Java-application-need-recommendations-tp4025834p4025852.html > Sent from the Drools: User forum mailing list archive at Nabble.com. > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
