My preference is option 1 … using a Spring application with a class which wraps a knowledge base / session. This has the advantage that sometimes I really do want to be able to mix up rules results with logic that I want to implement in Java code. There's obviously a performance impact if you additionally marshall to a separate Drools server, but not a huge amount. The decision should be more about whether you expect all business logic to be implemented in the Drools rules or a combination of rules and business logic code. Steve On 6 Sep 2013, at 00:15, srikanthmalli <srikanthmalli(a)gmail.com&gt; wrote:

So you have 2 different answers, and neither of us provided performance as a reason for our choices. :) I should point out that I also prefer to have rules services (both REST and SOAP), which keep business logic separate from front-end applications. I just prefer to build Spring web apps and use the API to build the knowledge base and evaluate rules, rather than using Drools Server. I like the control it gives me. I also find that there are a lot of things that can be done more reliably, outside the rules code. For one thing, unit testing Java code is much easier than testing DRL or decision tables. This way I am able to pick and choose as I go, whether Java code is the easiest/simplest/fastest way to solve a particular problem, or DRL. Steve On 6 Sep 2013, at 16:21, Genene Geda <ggeda(a)ghx.com&gt; wrote:

The "rules as a service" app I was talking about for option #2 is using spring and it is a RESTful webapp, but dedicated to handle "rules requests". There is no DRL handled by the "rules service" , the DRL / decision tables resides outside this "rules service" app. It is a java app devoted to take "rules request" from other applications and has a proxy to GUVNOR and wraps the returned result ( I use JSON) and Returns to the caller. So, it is java code can use unit tests .... but only deals with a special task of taking "rules" related request and responses by one or more applications. Architecturally, it is a "Horizontal" layer, serving "Verticals". I am not quite convinced on the 'single failure' argument .... as reason against option #2. Yes, architecture determines .... is it to serve one application or multiple? Genene From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of adarsh.chaini(a)hsbcib.com Sent: Friday, September 06, 2013 11:28 AM To: Rules Users List Cc: Rules Users List; rules-users-bounces(a)lists.jboss.org Subject: Re: [rules-users] Integrate Drools with Java application, need recommendations I think it all depends on the architecture and the type of application and the usage of rules with in those applications. Having a separate server adds another single point of failure and latency. The applications that are very distributed in nature and spread across 100's of JVM's would like the business logic more close to the data present in those nodes/JVM's. Thanks & Regards, Adarsh SENIOR LEAD DEVELOPMENT SPECIALIST SCJP, SCWCD FINANCE TECHNOLOGY HSBC BANK PLC HBEU 8 Canada Square,Canary Wharf, London,E14 5HQ,United Kingdom ------------------------------------------------------ Phone +44 207914720 Mobile 07595530105 Email. adarsh.chaini@hsbcib.com<mailto:adarsh.chaini@hsbcib.com> ________________________________ From: Genene Geda <ggeda@ghx.com<mailto:ggeda@ghx.com>> To: Rules Users List <rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>> Date: 06/09/2013 16:22 Subject: Re: [rules-users] Integrate Drools with Java application, need recommendations Sent by: rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org> ________________________________ My preference is option #2 - REST based Why? That way you will have "rules as a service" and you can serve more than one application. Your interface to the GUVNOR repository would be from this "rules service" server instead of each application duplicating the same code. I am building "rules service" as a horizontal for all applications to use it when they need it. In multi-applications environment, standing "rules as a service" is in my opinion - the best solution. So if you are using GUVNOR as a rules repository ( which is a key requirement to achieve separation of "business rules/ logic" from application code base - and to gradually engage the business analysts to fully or partially own rules authoring) .... from my limited experience so far, option #2 is the best approach. Let's know what you decide eventually and the challenges / opportunities .... Genene -----Original Message----- From: rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org> [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Stephen Masters Sent: Thursday, September 05, 2013 6:00 PM To: Rules Users List Subject: Re: [rules-users] Integrate Drools with Java application, need recommendations My preference is option 1 ... using a Spring application with a class which wraps a knowledge base / session. This has the advantage that sometimes I really do want to be able to mix up rules results with logic that I want to implement in Java code. There's obviously a performance impact if you additionally marshall to a separate Drools server, but not a huge amount. The decision should be more about whether you expect all business logic to be implemented in the Drools rules or a combination of rules and business logic code. Steve On 6 Sep 2013, at 00:15, srikanthmalli <srikanthmalli@gmail.com<mailto:srikanthmalli@gmail.com>> wrote: _______________________________________________ rules-users mailing list rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-users ************************************************************ HSBC Bank plc may be solicited in the course of its placement efforts for a new issue, by investment clients of the firm for whom the Bank as a firm already provides other services. It may equally decide to allocate to its own proprietary book or with an associate of HSBC Group. This represents a potential conflict of interest. HSBC Bank plc has internal arrangements designed to ensure that the firm would give unbiased and full advice to the corporate finance client about the valuation and pricing of the offering as well as internal systems, controls and procedures to identify and manage conflicts of interest. HSBC Bank plc Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom Registered in England - Number 14259 Authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority ************************************************************ ************************************************************ HSBC Bank plc may be solicited in the course of its placement efforts for a new issue, by investment clients of the firm for whom the Bank as a firm already provides other services. It may equally decide to allocate to its own proprietary book or with an associate of HSBC Group. This represents a potential conflict of interest. HSBC Bank plc has internal arrangements designed to ensure that the firm would give unbiased and full advice to the corporate finance client about the valuation and pricing of the offering as well as internal systems, controls and procedures to identify and manage conflicts of interest. HSBC Bank plc Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom Registered in England - Number 14259 Authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority ************************************************************ ************************************************************ HSBC Bank plc may be solicited in the course of its placement efforts for a new issue, by investment clients of the firm for whom the Bank as a firm already provides other services. It may equally decide to allocate to its own proprietary book or with an associate of HSBC Group. This represents a potential conflict of interest. HSBC Bank plc has internal arrangements designed to ensure that the firm would give unbiased and full advice to the corporate finance client about the valuation and pricing of the offering as well as internal systems, controls and procedures to identify and manage conflicts of interest. HSBC Bank plc Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom Registered in England - Number 14259 Authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority ************************************************************ ----------------------------------------- SAVE PAPER - THINK BEFORE YOU PRINT! This transmission has been issued by a member of the HSBC Group "HSBC" for the information of the addressee only and should not be reproduced and/or distributed to any other person. Each page attached hereto must be read in conjunction with any disclaimer which forms part of it. Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. Its contents are based on information obtained from sources believed to be reliable but HSBC makes no representation and accepts no responsibility or liability as to its completeness or accuracy.

You said : Also we do not see drools serving multiple applications at this point of time or in near future. Genene -----Original Message----- From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of srikanthmalli Sent: Friday, September 06, 2013 12:21 PM To: rules-users(a)lists.jboss.org 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-... Sent from the Drools: User forum mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Yes, in our architecture application have separate layer that integrate with drools, I am going to start with single application (option 1) and just in case if the things doesn't work the way I wanted it would be easy for me to break and switch to server environment (option 2). Thank you all for valuable input. -Sri -- View this message in context: http://drools.46999.n3.nabble.com/Integrate-Drools-with-Java-application-... Sent from the Drools: User forum mailing list archive at Nabble.com.