In our project we have to implement business logic regarding mapping of certain objects to some actions. We will have a series of conditions for specific types of objects to be verified before a certain action finally gets resolved. In other words for 7 types of objects we can have a series of actions ( from out of almost 45 actions).
We were thinking of using Drools to write down the aforementioned rules. Does anyone have some positive / negative experience with using Drools as far as its efficiency is concerned? There is also the jBPM framework that can be used (if I am not mistaken Drools are used there) – anyone is familiar with that framework? Perhaps you have some other ideas of how to solve the problem?
With regards efficiency, you should have no issues at all with Drools. That sounds like a pretty tiny set of facts and rules to me. The Rete engine on which it is based is almost certainly faster at making decisions than any pile of if-then-else statements you code up yourself. And a particular benefit that I noticed is that response times are extremely predictable.
Obviously all fact models and rules differe, but as an example, the application I'm currently building has hundreds of facts in working memory at any time, and more than 1000 rules. It's able to make decisions about incoming requests in about 20 milliseconds.
The full jBPM framework doesn't sound necessary for what you describe. However, it is good at what it does. For instance there is a process modelling GUI if you're looking to design workflows, and Guvnor can be usable for non-technical rules authors if the technical team puts in some up-front effort on writing DSLs and building decision tables.
For completeness, the main competitors are probably FICO Blaze Adviser or IBM ILog JRules. Generally when it comes to benchmarks those tend to be slightly ahead of Drools, but they are expensive. Admittedly, if you decide to pay for JBoss/RedHat service contracts then it's not much different, but if you're happy to take community support on Drools, then it's free!
My only concern about Drools is that there is no decent GUI for it that a non-IT business people could really use. Lots of products claim that they do provide such UI but it always turns out to be not really true. So, you have to accept the fact that your development team will end up creating and testing all those rules based on decision tables or some other formats.
Other than that, Drools is a great BRE used by governments, banks and large companies.
Drools is very efficient and fast. But as with any technology & framework it will need an investment to integrate into your project and it is not a magic bullet. You need to consider:
How many rules will you have? I would not recommend any rule engine if there is less than 20 rules. It might not justify the effort you will spend for the compexity of adding a rule engine just for 7 objects and 45 actions...
Will you need DSL (Domain Specific Language) capabilities? Ie. will non-technical people write rules? IMHO this is not very usable in Drools in comparison to eg. Oracle OPA. But again I have not seen a non-technical person safely tinkering with a rule system yet. Apart from changing values in a decision table.
How often will your rules change? If you need a centralised system to manage, version, package, test your rules then Drools Guvnor is a very capable product.
jBPM is not a rule engine, it's a workflow engine. Drools is a rule engine. So Drools is what you're looking for.
Drools and jBPM are companion projects: they integrate really nicely if you need workflows with rules.
Drools is good well JBPM is bit complex as compared to other BPMN engines. I would suggest go for Activiti because it is bit easier and integration of anything say Spring, LDAP etc.; with Activiti is easier. Also you can integrate Drools with Activiti.. so go for Activiti as aworkflow engine and Drools for a rules engine.
Related
Rules Engines are often sold under the premise of making it possible for business people to modify some very dynamic parts of the application directly, without any involvement or programming done by the developers.
In my opinion, putting into production any code that is not covered by automated tests represents a grave risk. I know that many rules engines are actually a rules management environments, including versioning, promotion between environments etc.but what support they offer to BA for writing tests? I have seen some documents where it seems frameworks like JUnit are integrated into the engine and this is certainly not the type or programming that non-programmer would do.
BA can easily change the rule with business engine, but how easy is for him to write a test that can cover it without the help of a programmer? How is the problem of rules test coverage resolved in practice?
"making it possible for business people to modify some very dynamic parts of the application directly, without any involvement or programming done by the developers."
We have been using a commercial rules engine for over 6 years now. We build template applications that are customized as per the customer's (like banks etc) requirements. The customization's are in the form of decisioning rules which are written in business vocabulary. Below are some of the observations that I've made over 6 years
I've never seen any rules customized on the fly in production by any customer. They all go through proper testing in the UAT environment before they are pushed to production. The whole app is not re-deployed, only the business rules are pushed.
Rules are written by the BA's but most of the time they still need to go through the developers for performance tuning purposes because of the execution model that these rules engine use.
I doesn't know about many open source rules engines but for the one we use, we wrote custom eclipse plugins so that that BA's can generate the test cases in the form JUnits
I think most of the rules engines will provide some sort of a API that tells which rules were fired in the form of audit report for a given request. But the challenge for us was to find the test data that can fire a particular rule. We call it as rule relevant data.
After completing several small projects with WCF, I'm quite happy with what it can do.
However, having spent a brief amount of time looking into the alternatives, I'm struggling to find exactly what benefits/drawbacks I would experience from using Java based web services such as AXIS2 or Metro?
Obviously open-source is perhaps one of them and also breaking away from Windows Server/IIS, but I can't see much more?
In comparing these two approaches specifically, I would evaluate your overall productivity between the two. Assuming you have an option of pursuing either/or, I've found the logistical work around with Metro and AXIS2 to be higher than WCF.
Given that both of these are essentially access points, whatever system complexity lies behind the scenes in terms of compatibility are key decision points. Even though we live in a world of unlimited interop possibilities, I tend to prefer stacks where consistency can yield productivity and performance gains.
As for open-source, while there is greater volume on the Java side than with .Net, I've also found that more of those projects are built to support functionality that's missing in the Java web service plaform (RESTlet, for example.)
Getting out of Windows/IIS is certainly an option with Java/Metro/AXIS2, whereas with WCF you're stuck with that as your front-end server. I've personally found both to be (too) configuration heavy, so neither have worked as an advantage for me in that respect. However, alternative hosts for the Java combination are certainly a possibility, so that may hold more value in certain situations.
All in all, both platforms (in the aggregate) will have scenarios where they're more advantageous than the other. Where those scenarios apply in your environment is what I find most relevant.
I'm not satisfied with the answers given by the SOAP vs REST questions notably here:
Performance of SOAP vs. XML-RPC or REST
because it's just general philosophical answers and not pragmatic answers with some study cases.
Nobody can give precise cases of when soap would be more suitable than rest, especially as for performance point of view ?
Update:I think REST is winning the war.
Performance is not the deciding factor.
First I should say, asking a SOAP-vs-REST question is a little cockeyed, because SOAP is a XML envelope format, and REST is an architecture. So I will make a little assumption and suppose that you are really considering SOAP-vs-POX or SOAP-vs-JSON or SOAP-vs-some other data formatting approach.
The deciding factor should be this:
Do you now need, or will you need in the future, the SOAP envelope?
The SOAP Envelope allows things like framework-provided encryption, digsig, routing, and authorization checks, among other things. You can of course, do those things with REST (or more accurately, with plain-old-XML, or JSON, etc) but you have to do more work yourself, to make that happen.
If Performance - whatever you construe it to mean - really is your #1 criterion, then you should probably abandon SOAP and POX and move to protobufs or something else optimized for performance. These can be faster to serialize and faster to transmit.
If you think this answer is "too philosophical" and you really want hard figures, well, then I suppose you'll need to conduct some tests. The actual perf will vary greatly on the toolkits you choose, the shape of the messages, and the extra data services (like encryption and so on) that you use. But in the end, perf won't be, or shouldn't be, decisive either way.
If your SOAP toolkit is 20% easier to use. debug, and maintain as your POX toolkit, then you should use SOAP, regardless of the performance. People (coders, architects, testers) are much more expensive than CPUs and networks these days. You can always buy another 2 cpus, or a bigger network, if necessary, and if your design is correct. But you can't buy 20% less time developing, at any cost, if your framework is hard to use, or if it drives away your people. Unless you are running a geo-scale network, you will do better to optimize for the people, instead of for the network.
You can find an article comparing REST and SOAP here:
http://www.jopera.org/files/www2008-restws-pautasso-zimmermann-leymann.pdf
Authors conclusions seemed to be:
Use RESTful services for tactical, ad hoc integration over the Web
Prefer WS-* Web services in professional enterprise application integration scenarios with a longer lifespan and advanced QoS requirements
Personally I do not like terminology like "professional enterprise" because it is loose and informal. However in my opinion authors made some good points in the article. Maybe to conclude and to give some own thoughts:
If you want to make API public - do it in RESTful way. Why? It is simple to use for a client application so it will make your service more popular. For example Amazon is exposing both REST and SOAP APIs, but 85% of their users have chosen REST version Amazon API - SOAP vs. REST
Use SOAP and WS-* stack if you will create (or you have some control of the process of creating) both consumers and producers of your services and you do need advanced features of WS-*. This will probably required more resources also because SOAP applications tends to be "heavier" (more features, but more sophistication also).
Also considering performance REST could be faster (messages are definitely shorter and you do not need to parse xml).
Hope it will help.
In your example of flash client - it is really hard to tell without knowing the details, however if one do not need all this security and transactional features of WS-* I think building REST application would be simpler and faster.
Answering to comment
I should use soap because i'm in so
called "professional enterprise"
And assuming of course that your choice isn't really dictated by big software vendors.
SOAP is suited for bigger enterprises because it encourages more formal approach. It offers specifications, which are huge, so your developers may need time to learn them and maybe even some professional training --> so spending companies resources. It also offers tools - and not all of them are open source, so this can also mean additional resources. But if your team will learn this way of integrating services it will probably be efficient and resulting code will be high quality.
REST in contrary is more a philosophy of developing applications. So, no huge specifications, no specialized tools. No resource spending. This may work nice if you have a small team of good programmers - they will not need so many guidelines if they know the basic principles . Unfortunately it is also easier to do things wrong.
Another thing to consider is the applications size - the richer the API, the more services you want to integrate, the harder it will be to do it RESTful. Also building small SOAP application wouldn't be probably a good idea - whole overhead and entrance cost is just too high.
You need to evaluate pros and cons for your project. It is impossible to give recommendation without knowing all the details I think.
And finally - this has nothing to do with reasonable arguments but more with politics. I think that management level people seem to prefer WS-* stack and SOAP (it has support of "big enterprises" so it is easier for them to justify their choose). On the other hand people from academic background[1] prefers REST - because there is still a lot of research that can be conducted in the area.
[1] I'm somewhere in between, so I can observe both behaviors ;-)
When is a Business Rules Engine used?
What is the difference between Business Rules Engines and scripting/configuration/customization
A business rules engine, or a business rules management system, should be used when you are trying to implement a decision in your code. But not just any decision. A decision that:
Involves lots of rules
Has rules that change often
Has rules that are complex or interact in complex ways (think lots of nested IFs otherwise)
Has rules that only someone with domain knowledge can understand/verify
Is one that the business people REALLY want to be able to change without your help
Involves using predictive analytics / scores as part of the decision making
These are the kinds of decisions that pay off the use of a business rules management system. Don't start with the rules, start with the DECISIONS.
Business rules are verbose (so business people find them easier to read), declarative not procedural and atomic (so they can be stored, managed and reused like data in a database).
More on why to use business rules here in this piece on why I believe in business rules.
Business rules engines are typically used to provide customizable "IF some-condidtion THEN do-something" sorts of logic to applications. These types of business rules can trigger certain workflows to execute or bubble up event knowledge to higher level rules, causing them to be evaluated.
Using a rule engine also allows for easier separation of concerns by removing the business logic from your code. Rules engines today typically also offer a front-end where users can add new rules without having to modify scripts inside the application.
Rules engines implement algorithms such as Rete (speaking from Drools experience) that make the task of evaluating the rules quicker. The rule engine also provides forward chaining, backward chaining, hybrid chaining, etc. of rules. However, these could be implemented in a scripting language as well. You can achieve some of the same sorts of things with both approaches, but I believe that it depends on the complexity and number of rules as to which avenue you should choose.
Take a look at this link from the Jess project: http://www.jessrules.com/guidelines.shtml
It provides a step-by-step walk through of questions to ask yourself in order to determine if a rules engine meets your needs, or is overkill.
Rules engines can do forward and backward chaining as well as inferencing. Check out Fair Isaac Blaze, Drools or iLog for implementations.
I am a total newbie to the world of SOA. As such, I am looking at some "SOA frameworks/technologies", and trying to understand how to utilize them to build a highly scalable (Facebook class) website.
There are several "pains" I am trying to solve here:
Composability (+ managing dependencies, Pub/Sub)
Language-independence of services
Scalability & Performance
High availability
I looked into some technologies that answer a subset of the above criteria:
Thrift - Facebook's cross-platform RPC platform
WCF - supports SOAP, JSON & REST, so it can be considered language-interoperable. Generates WSDL files that can be use to generate java proxies.
Microsoft DSS - just inclued it in my survey, but it doesn't seem relevant as it is highly state-driven and .NET specific.
Web Services
Now, I understand how I get some aspects of composability and language-independence out of the above. But, I haven't found much concrete information (not buzz) about how to use the above / other tools for scalability and high availability. So finally I get to my question:
How does one leverage SOA technologies to solve the pains I defined above? Where can I find technical guides for that? I am looking for more than just system diagrams, but rather actual libraries, code samples, APIS...
I think the question has more to do with the concepts involved than the tools. Answers to the items:
Understand and internalize bounded context. Keeping unrelated pieces separate its important to get real reuse on different services. Related technologies won't help you on this, its you that separate the app in appropriate contexts, which you can appropriately reuse for different services.
Clear endpoint for communication based on known protocols allows implementing different pieces with different technologies
Having the operations flow like independent actions based on different protocols, gives you a lot of places where you can add tiers. Is a particular sub-process of the overall process using lots of resources and the server can't take it anymore, just move to a separate server. Load kept growing, and that server isn't taking it anymore, add an additional server and load balance. You also have more opportunity to use caching and connection pooling.
Have a critical sub-process that needs to be available all the time, add a server so you can have a fail over. Have an overall process that needs to be "available" all the time, use queues for pieces that can be processed later.
Do you really need to support that type of load? Set appropriate performance/load/interoperability targets that relate to the specific scenario. If you really need to support that type of load, I recommend you get someone on board who has dealt with it.
If it is something for a load that might eventually be, identify the bounded contexts and design the interaction between those with a SOA mindset. Keeping the code clean is all you have to do for the rest, use TDD, loose coupling, focused integration tests, etc in your code base. With good code, if you later need to separate pieces of the system, it will be a lot easier.
There are interesting and relevant things said about services and architecture by Amazon's CTO - Werner Vogels:
An interview about the Amazon technology platform
A post on his blog - "Eventually Consistent - Revisited"
A 50 min presentation about Availability & Consistency
IDesign.net has a bunch of great downloads for WCF.
Worth a look at: http://www.manning.com/davis/ ?
Check out the Mule project which bundles the CXF services stack and also the Mule REST pack which provides RESTful alternatives. I think you'll see it addresses all of your pains and there are lots of examples in the documentation as well as the distribution.
May I recommend the book: Enterprise Service Oriented Architectures published by Springer Verlag.
All of the advice here is well and good, but don't worry about it until you really need to.
Focus on building a usable, functional application that people really like. When you start running into problems, then start handling bottlenecks.
You will never be able to foresee every way an application will fail, so how can you tell if [[insert tech here]] is your answer?