Clearing the Terminal Junk

Today as I was on my regular - code, build and test cycle, that suddenly there was a huge lump of error trace. It was so huge as to going to the exact origin was making my work take long. After every build thought I did a clear, it hardly helped me because, it actually "seems" to clear the screen, but actually holds the previous output, so even after the clear, scrolling up the screen will take us to the old terminal output (that I supposed to have cleared).

I wondered how I could actually clear off the entire terminal output, because after a cycle is complete, it hardly makes any sense to hold the previous output on my terminal buffer, rather it makes us more confused. After some googling, I got the solution - for the Mac (its the “⌘K” key combination). Wondering where I could get on this my Linux box, that I noticed the "Terminal -> Reset and Clear" option. Good it worked the way I wanted,.. but there was no shortcut key. Right away, I created one, and now I have the "Ctrk+K" combination clearing of the screen and its previous output buffer.

Try it! Probably you will never use the clear again !!

Getting your toolbox ready for OSGi

This is my second post on OSGi. In my previous post, I just mentioned about what OSGi is all about. In the coming posts, I will be explaining on developing OSGi applications. As before, I won't be repeating anything that has been already written so well by other authors. I will be just siting some links to them. I will try to be innovative by linking thoughts in various articles or adding a missing point to the existing article, or giving a new way of doing things.

But, before we begin out on expedition and get our hands dirty on developing OSGi applications, let us pack up our toolbox for it. However if you are too eager to getting a feel of developing applications on OSGi, just read on this article by “Neil Bartlett” on EclipseZone.

There is nothing special that you need in developing OSGi application, other than an OSGi platform implementation jar to your regular Java environment and a simple text editor. Still, we all like tools in our day-to-day life to make things easy. With this post, I will just try to get ourselves acquainted with the tools that will make our life of developing OSGi applications simpler.

Eclipse

Eclipse is my favorite IDE for Java development. Although you can use can continue to use your own favorite IDE, if you are not already using Eclipse; there is more to using Eclipse. Eclipse itself is build on the Equinox runtime that is an OSGi implementation platform, and Eclipse allows to interact with the Equinox runtime. And sometimes its really very easy to developing your bundles in there.

Eclipse calls the so-called OSGi bundles as Plug-in, and the environment it provides for developing these Plug-ins is called Plugin Development Environment popularly called as PDE.

Maven

Maven is basically a build management tool – like the Ant, but much much more. Maven can manage a project's build, reporting and documentation from a central piece of information provided by the POM file.

Maven is popularly helpful for its dependency management. It allows a project and all its dependencies to be managed gracefully. The variety of maven plug-ins that are available makes the usage of Maven even simpler to be used for most of the odd kind of projects.

If you are new to Maven, it may feel a bit intimidating, at first, but you will soon feel very comfortable with it and would always think of how could you make use of Maven to make use of your tasks easier. I will not talk more on this – there is enough written on Maven.

Although we could use Ant, the simplicity given by the Maven is just enough to make us learn Maven if we don't know it already - its simple. Believe me!

We will be using the power of Maven to simplify many of our tasks for OSGi.

Pax Projects

Probably the most important tool in your box for the OSGi world would be the set of tools provided by the OPS4J under the Pax project – an umbrella project for all the OSGi projects at OPS4J. OPS4J was probably one of the early adopters of the OSGi, and therefore what they provide is worth the time they have spent on it. There are several projects under the Pax, all geared to making your OSGi life simpler, without any hype attached.

I would have loved to write on the tools provided by the Pax projects, but Craig Walls has made my job easier by posting exactly the same on his blog few days back. So I would just like to refer to it apart from looking at Pax official site.

And if you are wondering where to begin from on the Pax tools, just start on the pax-runner, pax-cursor and pax-construct to begin with.

The version numbers of most of the projects should not make you upset. You will find that most of them are still having a major version of '0'. Probably this is one of their strategies that indicates them avoiding the hype. I don't want to create any hype either, just check it out yourself. And if you find any place that needs improvements, feel free to do it right away, after all OPS4J is not just about liberty of source, its about a community participation.

Spring & Spring-DM

We will be using Spring for what it is popular for – Dependency Injection. Spring-DM (Spring Dynamic Modules for OSGi service platforms) is another project from Spring Framework specifically focussed at OSGI. Probably we all would like our code to work not only in OSGi, but also in other environments as well. In designing such an application, you would probably do not want your domain objects to be coupled with the OSGi API.

That apart, just like Spring provides us with some great tools and utilities to getting our developer life easier, Spring DM will also provides some tools and utilities specific to OSGi, apart from the dependency injection aspects specifically for OSGi.

Whats Next?

Once these tools are at our box we will be in a better position to learn more and develop OSGi applications easily. Its not about mastering the tools above, but knowing about them will give us a holistic understanding of developing OSGi applications easily.

In my forthcoming posts, I will be using up these tools to develop OSGi applications.

Thinking beyond liberty of Source...

Thinking to start or contributing to Open Source project ...?

Have you ever wondered at the richness of the Wikipedia, the amount and variety of information it contains? You can think to find there almost everything under the sun over there,.. and if you don't, you can always add it there. Great, isn't? All this richness was possible only because people all around the world can participate in authoring the Wikipedia. One can never think of such a great encyclopedia being authored by one or a few authors. You can always create new pages, edit or add to the existing ones and thus add to the richness of the Wikipedia.

Now think of the same richness and flexibility being brought to the Software world. Wow! that would be fantastic!! Yes, OPS4J provides you this flexibility with the philosophy - “wiki brought to coding”.

Here is the reproduction of the OPS4J philosophy from their wiki's home page:

OPS4J stands for Open Participation Software for Java, and this community is trying to build a new, more open model for Open Source development, where not only the usage is Open and Free, but the Participation is Open as well. Removal of barriers, let more people in, have more fun and less politics. I have also seen Open Development as a term to describe this.

Think of it as Wiki brought to Coding. Wikipedia is of course the most outstanding example of open collaboration.

If this is your first visit to OPS4J, we recommend you the Introduction.

What is “wiki brought to coding” ?

Wikis that drive the Wikipedia is a collaboration tool where contents or media could be added, edited and updated by virtually everyone with valid credentials. However Wikipedia just allows this credentials to anybody who just registers with it – no special merit is needed for you to obtain the credentials.

While both the philosophies of FOSS – Open Source and Free Software promote the openness in the software source and the liberty of the user to modify and redistribute the software without royalties, none of them actually dictates the ways in which someone could actually be a part of the project itself.

Beyond the FOSS philosophy

OPS4J extends the concept of wiki into the software world. You just need to register with the site and then you can create, modify and contribute to the software or its documentation.

The site itself is wiki-based, meaning that once registered, you can add and edit wiki pages that make up the site – just like Wikipedia. You also have write access the SVN, meaning that you can create your own projects, or add to the existing ones. So,.. no more patch submissions and waiting for you to prove yourself to be meritorious to have the write access to the SVN. Whats more – you also have almost an unrestricted access to the JIRA too!

Its a home away from home for a developer. You have access to almost all the tools and rights needed to operate a software project. The whole world seems to be your team.

Why this “No Barrier” approach to Open Source?

There are already Open Source promoted by organisations such as Apache, SourceForge, JBoss and the like, but they do not adequately allow everybody to participate. These projects are either merit based, privately owned or commercially controlled. They have their own way in how it restricts people from participating in the software evolve.

These and similar thoughts on its philosophy is explained clearly here, and at the links given at the references.

It also answers few other questions that maybe coming up in our minds such as:

1. Why does "No Barrier" projects make sense?

2. When does a "No Barrier" project not make any sense?

3. How about the bad guys (trying to destroy the code bases)?

4. How does it work here at OPS4J?

5. Who is in control at OPS4J?

6. As a user, what licensing applies to me?

7. What can I do to make OPS4J better?

8. I want to start sharing some code and invite others to help out. How do I do that?

9. I have found a bug in some code, what shall I do now?

Conclusion

Essentially the OPS4J is right in its innovative philosophy to promote Open Source that is essentially liberal. All those who have worked behind this upcoming idea has to be given all the credits.

So what are you waiting for? Just jump ahead, create your account and start participating and see your ideas grow and mature!

References

OPS4J itself has much to say about the philosophy of “No Barrier” and “Open Development”, and how it tries to implement them. If these ideas excite you, please make sure to go through the following links.

1. http://wiki.ops4j.org – Home Page

2. http://wiki.ops4j.org/confluence/x/mYE6 – Introduction

3. http://wiki.ops4j.org/confluence/x/Cg – Community Tour

4. http://wiki.ops4j.org/confluence/x/Cw – Principles of Open Participation Software

5. http://wiki.ops4j.org/confluence/x/D – Practicalities at OPS4J

Open Source with Liberty

How many of us know that Open Source softwares essentially are Free Software as well (most of the time)? Again, if one has read the definition of Free Software? See http://en.wikipedia.org/wiki/Free_Software and http://en.wikipedia.org/wiki/Open_Source.

Okay, I will give it out brief. Free in the Free Software as with its philosophy defines "free" as in "free thoughts" and not as in "free beer". Essentially what makes a software Open Source or Closed Source or Free Software is determined by the license that it carries. But when most of the licenses (almost all the popular ones) that qualify for "Open Source" also qualify for the "Free Software", essentially the software that carries such a license is essentially Open Source as well as Free Software.

NB: If you don't understand something as you read on, just open up a new tab on your browser and do a search on the subject, you will find so many good links. So much has been already written on the subject that I find it pointless to write them again. Please guess it right that I am too lazy to give out those links here. Hope you can excuse me for that!

Even while most of the software qualify under both categories, its authors and promoters try to push it as Open Source, and not Free Software. Why? Popularity ... branding your software as being "Open Source" makes it more popular than branding it as "Free Software". Try to imagine a software that you have used and was promoted as "Free Software". Can't gain much... right?

I am not being paid by Eric S Raymond or OSI, neither by Richard Stallman or GNU or FSF, so I should make a clear stand on both. While there are very narrow differences in the qualified Licenses for the two, they differ in their philosophies to where the emphasis goes. While the Open Source philosophy emphasis is on the openness of the source (of the software), Free Software emphasis is on the liberty and freedom on the software that you use. As the FSF/GNU site mentions it, Free Software and Open Source are not enemies, but rather closed source is the enemy.

Why did I write this post?

As I talk to my friends and colleagues, I understand that not many understand FOSS/FLOSS (addressing the Free and Open Source Software in a single name) in the real sense. For many, free software is something you don't have to pay for, and in that sense, open source is also free. And Open Source is something where you can see the source. To people like them, while at least when they read this line, they must realize that there needs to have a more thorough understanding of the FOSS/FLOSS philosophy.

There are good number of essays on this topic, but I thought of writing this post to save some of your time reading it. But if you are a bit more free, just read this one to understand some differences between the two philosophy. (Okay, this will not explain why most people prefer an Open Source branding as such, though it explains that "open source" is considered as a "marketing" campaign for free software).

There is so much to write on the subject, but this is a comparatively small post because:

1. I am lazy in writing essays.
2. I am not good at essays.
3. People often don't have time to read essays unless its really critical, and I understand that the need to understand FOSS is hardly ever critical unless you are selling a software with a sprinkle of FOSS around threatening your own license.

I try to promote FLOSS as I deal with people personally, but for others, some of my posts like this should help. Just post on a comment if it helped a penny on your thoughts to know FOSS.

OSGi - Add dynamic modularity to your Java applications

Ever imagined, how the Plug and Play (PnP) devices have eased the way we use our electronic devices, especially our PCs and laptops? You purchase a TV tuner card (or any of your other favorite card), plug it into your PC's PCI/PCMCIA slot, and ... Viola! Your PC can now act as a TV! Now your expansion card has added the functionalities of a TV to your PC. You remove the card, and back - your PC has lost its functionality of the TV. To whichever PC, you plug this card in, it just adds the TV functionality!

Mmm! I am not going to talk on those expansion cards. But just imagine if we could get such a functionality in our Java applications. You develop modules similar to the TV tuner card, that you plug in, and your application will gain that additional functionality ... essentially modular!

And now imagine those "hot-swappable" capabilities - you plug in your USB web camera even while your PC is running, take a snap, plug it out- thats it!. Hmm... impressive! Can we get such functionality in Java Applications - add are remove modules on the fly - without restarts? The answer is a big YES! OSGi makes this possible.

What is OSGi?

OSGi stands for Open Services Gateway initiative. This doesn't pretty much explain about what it does. This abbreviation is a thing of the past, and the OSGi Alliance itself is trying to forget it. Now officially, its just a trademark with no special meaning. The shortest description given about OSGi is "Universal Middleware". Software that you write once and then can use in binary form universally: in many different platforms, many different industries, and for many different purposes.

The OSGi Environment
(from the article "The last mile of software deployment" at http://www.aqute.biz/resources/2002/lastmile.pdf)

OSGi is a component-based platform for developing applications in Java. The OSGi site describes it as "dynamic module system for Java". The official definition of OSGi (in its R4 Specifiations) describes OSGi as follows:

The OSGi Service Platform specification delivers an open, common architecture for service providers, developers, software vendors, gateway operators and equipment vendors to develop, deploy and manage services in a coordinated fashion. It enables an entirely new category of smart devices due to its flexible and managed deployment of services. OSGi specifications target settop boxes, service gateways, cable modems, consumer electronics, PCs, industrial computers, cars, mobile phones, and more. Devices that implement the OSGi specifications will enable service providers like telcos, cable operators, utilities, and others to deliver differentiated and valuable services over their networks.

Okay, enough! Its impressive! But, I am not going into its technical details now. You could just go to the references stated, especaially [1], and of course the OSGi R4.1 specifications.

Why OSGi?

OSGi is there to stay. Many industry players have already embraced it. It offers many advantages to faster development, component reuse, easy integration, and other runtime benefits. Adrian Colyer, CEO of SpringSource has written an excellent blog at [8] on why one should consider OSGi framework for the Java Development.

Apart from the benefits mentioned before, an important consideration for choosing up a framework would be its industry acceptance. OSGi is being adopted by almost all the major players of the industry. Its not just the hype, because OSGi has been there now for about a decade. OSGi came out with its initial R1 specifications back in 1998.

Any real world success stories?

Yes of course! Eclipse is just an excellent example of a successful system running on the dynamics of OSGi. From Eclipse version 3.0 onwards,eclipse is backed by the OSGi framework - Equinox (an OSGi framework implementation). In fact, equinox is one of the widely used and fully compliant OSGi framework implementation.

There are other success stories as well, but I am very lazy to write on them! Okey, you can find some here: http://www.mbeddedserver.com/partners/success_stories.html, and here: http://www.infoq.com/news/2008/01/osgi-success.

The OSGi Service Platform is a set of specifications that define an application model inside a VM. You can think of OSGi like a SOA (Service Oriented Architecture) inside a VM (Some even think beyond!). Inside a running VM, it is possible to install, start, stop, update and un-install applications. The VM never has to be stopped. The specifications have a very flexible and powerful management model that made it possible to use the specifications almost as is in Eclipse.

Equinox powers the dynamics of the Eclipse that enables it to have plugins and extensions to provide so many variety of features. You can find eclipse plugins for almost anything. But, one may argue that even systems like the Firefox allows plugin models without OSGi. Right! but the main point is integration and reusing the wheel. Will Firefox(or other model) support the mechanism as a platform that can be used to build your applications? OSGi already is build up as a framework that will support dynamism and plugin model. The plugins (bundles) will be ought to be coherent when the different components integrate, someting that is enforced by the OSGi framework.

A component bundle once tested is bound to work even in the integrated scenario. Of-course, OSGi is not the only answer, you can roll your own, or get others like the JBoss Microcontainer. But OSGi is already mature enough to support applications rangng from mobile applications to enterprise applications. SpringSource has already built an application server on top of OSGi (See [7]).

Now, if one could point at the failures of eclipse, with plugins, or why it needs a restarts and all, the answer is not simple. OSGi framework is good enough, but eclipse had been shifted to this platform, its evolving. It has to support hundreds of plugin developers. And frankly, eclipse is still not able to fully leverage the platform to its full. But from ground-up, if one could consider writing applications on OSGi, it would be worth investing some of your thoughts.
You can know more about OSGi and Eclipse at references [5] and [6].

Conclusion

As you could guess,... I am not that good at blogging. With this blog, I just want to emphasise that - OSGi is there and its happenning. No indepths of OSGi (Its already there written by some great authors, that I have reffered to at the end of this blog).

OSGi has evolved over the past decade, but it still requires a decent grabbing out. It has all the promises, lots of big players also into play. So if you are among those early adopters, you can definitely have a competitive advantage in building modular applications for a long run. So, if you are planning for a new project, all modular and dynamic, take time to think and invest some time for OSGi before rolling out your own solutions.

Whats Next?

In my coming blogs, I will be trying to give out a heads up with using OSGi, using it for the Web and tools that will help you to develop on OSGi.

References

0. http://www.osgi.org/Main/HomePage
1. http://www.osgi.org/About/Technology?section=2 = The OSGi Technical Overview written for the OSGi Alliance
2. http://www.aqute.biz/OSGi/Articles
3. http://www.aqute.biz/OSGi/Presentations
4. http://www.aqute.biz/OSGi/Resources
5. http://www.aqute.biz/OSGi/Eclipse
6. http://www.eclipse.org/equinox/
7. http://www.springsource.com/products/suite/applicationplatform
8. http://blog.springsource.com/main/2008/05/15/why-should-i-care-about-osgi-anyway/
9. http://www.osgi.org/blog/2006/03/eclipsecon-2006-osgi-on-rise.html
10.http://soa.sys-con.com/node/492519
11.http://soa.sys-con.com/node/577046
12.http://www.redmonk.com/jgovernor/2008/02/05/osgi-and-the-rise-of-the-stackless-stack-just-in-time/

Shed the experience myth, get the most out of your employee

Summary "Get the most out of your employees". Industry freshers at companies are not given up task for a good time, thinking that they will not be able to handle it. Pre-convinced notion that they cannot simply handle such task until they become "experienced" holds back their actual capacity. This experience myth does not die there, but rather goes down the career line at every experience levels. How to come above this experience myth and get those young, smart talents with you? Read on ...

-----------------------------------------

How many time have you made that employee in your organization to under perform? Yes, this must have happened, not deliberately, but because of a myth that might have engulfed you, as with most of the managers – the experience myth.

The experience myth is one of the commonest form of myths that takes away much of the productivity of your valuable employees, even without much notice to it. You require smart, capable employees with you, who may add value to your organization, make your organizations outperform your competitors. So, you place ads for experienced and talented breeds of those people, while mentioning it very prominently - “Freshers need not apply” or at some other times, something similar. Even at other times, when those less experienced move ahead to appear at the interviews, your “experience” screening, quietly puts them off. How many time have you avoided the best of talents this way?

Many times, with such an experience screening, those young, smart talents are denied their most apt position. Often, such unfortunate less experienced candidates may be just lacking those formal industry experience, while they may be having a good hands-on experience that they have acquired during their academic studies as they went beyond their courses to understand those much needed industry experience. Sometimes, even worse happen to these unfortunates where their expertise on the subject and the extra-curricular knowledge won't show up in his academic report. Effectively, this genius student may be far better off than his fellow students who might have scored much above him. Even for other, they may have acquired those much needed experience while they were doing a job hunt, that they simply cannot put onto their CV. While this may be more applicable to knowledge workers, consider if this is true even for the others.

Now an industry fresher like this is not given a chance for a job, or a position befitting him because he is “fresher”. Just realize that he is just industry fresher, not fresher on the subjects of his study.

The, story doesn't end up here. Again down the career path, the same story holds true even when he climbs the "experience ladder". There are positions and tasks meant for people with x-years of industry experience. No matter how competent the employee is, he is not given that position or task, not even tried once. In effect, such down casted employees are performing tasks much below their capacities. The one who is capable of making strategic technical or business decision is made follow such decision from those “experienced” guys higher up. Sometimes, this has a serious side-effect. The employee recognizes the inferior leadership above him, that may frustrate him leading to further decline in employee output.

Has your organization been struck with this experience myth? Has it eaten away much of the productivity and talent pool that you have always wanted? Then, follow these simple remedies:

• # Keep no pre-convinced notion on experience vs capability . Practice this during new hirings, or even for employee evaluations.
• # Go through your organizational hierarchy and look out for those hidden talents and try to bring them up.
• # Recognize the hidden talent in an employee by giving him as challenging tasks as he can, regardless of his position. Ask them for tasks they would like to take up. Give them tasks even beyond their experience level and see if they can do it. Measure his threshold, and thus evaluate him.
• # This kind of employee evaluation will not be a task for a few days, but rather it should be a continuing process.
• # Have frequent interactions and feedback - employee evaluation should be more frequent. Consider a three month cycle.

Get rid of this experience myth, and see how it improves the overall productivity of your organization. You may soon have a pool of those young smart talents with you. Getting to this practice will even attract more and more talents to your interview desks.

Rules Engines for Business Rules

Rules Engines brings agility into business systems by providing way to dynamically change business logic according to the dynamic nature of business. The power of Rules Engines lies in the declarative nature of defining business rules at fly, even without changing the source code of the application.

Introduction

Business applications often have to deal with changing business requirements that are often unpredictable and inevitable for business. Such changes cannot be even predicted during the system design. The conventional way to handle this situation is to go to the source code where the business logic exists, edit, compile, test and redeploy it; which requires a considerable amount of time and energy apart from the hassles of going through a complete release cycle.

Rules Engine eases out such situation by providing a way, that enables Business Analysts and developers to easily build decision logic based on business needs. Basically a Rules Engine externalizes the application logic from the source, thus enabling the business complex rules to be modified even on the fly, while the application is running.

Past, Present and Future

Rules Engines have existed from long time into the business software systems, but they have been gaining importance just recently, as business applications have started growing to be more complex. Rules Engines exist written in various languages including C/C++, C#(.NET), Java etc. But, of recent times, Rules Engines in Java have gained much importance with the Open Source wave.

Most of the earlier and legacy rules engines have proprietary API. making them difficult to integrate with applications. If a rule engine is no longer supported and the business decides to adopt another rule engine, most of the application code will need to be rewritten.

JSR 94 is an attempt to standardize rule engine implementations for Java technology. The specification for the Java Rule Engine API (JSR 94), developed through the Java Community Process (JCP) program, defines a Java runtime API for rule engines by providing a simple API to access a rule engine from a Java SE or Java EE platform.

Many Rules Engines exist in the Java World. Many follow the JSR-94 specifications, while some others do not.

Whats, Whys and Hows of Rules Engines

What is a Rules Engine?

The term Rule Engine is quite ambiguous in that it can be any system that uses rules, in any form, that can be applied to data to produce outcomes.

1. A simple system such as the form validation system can be a rules engine.

2. Action classes that we write, which execute business logic is also a rules engine.

However, the Rules Engines that we are discussing is a kind of Rules Engine, is also an 'Expert System' and are classically known as “Production Rule Systems”.

Please see http://en.wikipedia.org/wiki/Production_system for a good discussion on it. Production rule system is a computer program typically used to provide some form of artificial intelligence, which consists primarily of a set of rules (also termed as productions) about behavior.

Production Rule System is a term coined in the literature of Artificial Intelligence. This is the most common form of architecture used in expert and other types of knowledge based systems. This type of system uses knowledge in the form of production rules, i.e. if(/when) ... then rules.

if (condition-1 and condition-2 and condition-3)
then: take Action-1

If a production's precondition matches the current state of the world (the working memory), then the production is said to be triggered. If a production's action is executed, it is said to have fired. A production system also contains a working memory, which maintains data about current state or knowledge, and a rule interpreter.

Each rule represents a small chunk of knowledge relating to the given domain of expertise. When known facts of the system is supplied to such a system, a number of related rules may collectively chain to an inference and lead to some useful conclusions.

The brain of a Production Rules System is an Inference Engine that is able to scale to a large number of rules and facts; the engine is able to schedule many rules that are eligible for execution at the same time through the use of a "conflict resolution" strategy.

The Rules Engine can be viewed as a sophisticated interpreter of if-then statements. The if-then statements are the rules. A collection of such rules is what we call a RuleBase. Rules Engine is supplied with facts (data from our application) on which the Engine works, and lead to conclusions. These facts along with the rules together is called as the knowledge base. As rules execute, further knowledge may be added to this knowledge base. The outputs from the Rules Engine are determined by the inputs and may include the original input data objects with modifications, new data objects, and possible side effects (such as sending email to the customer). Sometimes, even some of the originally supplied data may be removed from the output.

The results may be used by the client to perform further processing. The rule engine determines when to evaluate each rule based on the input required for the rule as well as the results obtained from the evaluation of previous rules. Dependencies between the rules need not be specified, as they are resolved by the Rules Engine.

In addition to all of the industrial uses for rule systems, a handful of communities have begun springing up around rule engine technologies. Javarules.org and Business Rules Community are the most notable among them.

In further discussions, we will just deal with the Rules Engine as a Production Rule System.

When to use Rules Engine?

This is a very important question, when we are considering to use Rules Engine in our application. Is our effort to implement Rules Engine worth the application's need?

We may consider to use Rules Engine in the following situations:

1. Business logic is too dynamic (changes too often), and a change in a business policy needs to be immediately reflected in the application. Use Rules Engine to manage dynamic business logic and the task flow
2. Business logic is too complicated to be managed at the source code level (source code may have tons of if-else, and switch cases in various nested levels or you are using lots of look-up tables)
3. The application in hand may have business rules that needs to change often or needs to change in ways not anticipated in the original design.
4. Government regulated business, where a government regulation and norms need to be adhered to immediately. (Telecoms, Banking and Insurance sector for example)
5. At the presentation layer to customize the page flow and work flow, as well as to construct custom pages based on session state.

Typical scenarios where Rules Engine are/can be used:

1. Insurance (Rating, Underwriting)
2. Financial services (loans, fraud detection, claims routing and management)
3. Government (application process and tax calculations)
4. Telecoms customer care and billing (promotions for long distance calls that needs to be integrated into the billing system)
5. E-commerce (personalizing the user's experience)
6. Generic infrastructure for application platforms.

Why use Rules Engine?

We can answer to this question, if we could point out the pros and cons of using a Rules Engine in a project.

Advantages

1. Rules separate knowledge from its implementation logic.
2. Application logic is externalised from the System logic.
3. Business logic can be changed easily and fast (sometimes even while the application is running).
4. Rules can be changed without changing source code; thus, there is no need to recompile the application's code.
5. Declarative programming model to define business rules
• Like object (OOP) and aspect-oriented programming (AOP), declarative programming is a full-fledged style of software engineering, well suited to a specific branch of software engineering.
6. Rules that represent business policies are easily communicated and understood. Rules are felt more naturally than many lines of code. Even business peoples can understand these rules (sometimes, with some training).

7. Rule engines can also be used to build expert systems, which may be thought of as large rule banks that are tuned to a specific problem domain, such as workflow automation, resource exploration, or medical diagnosis.

Disadvantages
As with any other tools or technology, using Rules Engine is not without any costs.

1. The learning curve to get acquainted with Rules Engine, its semantics and possibly its syntax
2. Efforts in integrating Rules Engine with our system
3. Different Rules Engine implementation have different format and syntax for defining rules. Hence a decision to switch to another Rules Engine implementation would mean the effort to learn yet another tool.
4. More the facts and rules to process, the Rules Engine requires as much memory to store them as a knowledge base. As the application logic increases and goes complicated, the memory requirement for the application may also scale up.
5. Just like any other part of application, Rules Engine also need that the logic written be tested thoroughly before being moved to production. Using Rules Engine puts a greater emphasis on testing because, a small logic error can have dramatic impact on the business rules.

(We can go over each of these disadvantages, how we can deal with it)

Then definitely, we need to consider that how much of time and energy will the Rules Engine save. If the application is small, or the change in business logic are predictable and preferably low, then use of a Rules Engine is simply an over head.

However, if we are perfectly decided to use a rules engine, the next question that arises is - Which Rules Engine to use?. This is what we deal next.

Which Rules Engine to use?

There are many Rules Engine available in the market today.Most of the rule engines available today loosely implement the JSR 94 specification, providing some commonality to integrating engines from different vendors. Thanks to JSR 94, integrating a rule engine into an application requires very few lines of code. Rules Engines on other platform also exist.

Some Open Source Rules Engine are discussed in http://java-source.net/open-source/rule-engines.

Below we discuss in brief about various Rules Engines available in market:

1. ILOG JRules and Fair Isaac Blaze

1. Main players in the business Rules Engine market
2. Well established user base in Banking and Insurance.
3. Offer variety of tools for non-programmers and administrators
4. High cost and learning curve
5. Best consider for mainline Financial Services and Insurance sectors
6. www.ilog.com/products/jrules and www.blazesoft.com

2. WebLogic Personalization Server

1. Bundled with its Portal product
2. Not given much importance by the BEA itself
3. http://e-docs.bea.com/wlcs/docs20/p13ndev

3. Rules4J and Java Expert System Shell (Jess)

1. Emerging players
2. Easy to use and inexpensive
3. Good capability
4. Short learning curve
5. Jess is the Reference implementation of Sun's JSR-94.
6. www.rules4j.com and http://herzberg.ca.sandia.gov/jess

4. Drools (JBoss Rules)

1. Open Source
2. Free
3. Good Vendor and community support
4. Emerging
5. Good developments going on
6. Powerful yet simple to use
7. Shorter learning curve
8. JSR-94 compliant
9. http://www.jboss.com/products/rules

JSR 94 and Rules Engines

The JSR-94 specification is by no means complete, but it gives client code a unified front end for plugging into different rule engines at runtime. It also supplies a standard way for rule authors and administrators to build and deploy groups of rules in a runtime environment.

JSR 94 defines a simple API to access a rule engine from a Java SE or Java EE client. It provides APIs to

1. Register and unregister rules
2. Parse rules
3. Inspect rule metadata
4. Execute rules
5. Retrieve results
6. Filter results

Note that JSR 94 does not standardize the following:

1. The rule engine itself
2. The execution flow for rules
3. The language used to describe the rules
4. The deployment mechanism for Java EE technology

In other words, it doesn't standardize the semantics of rule execution.

JSR 94 provides guidelines for the rule administration and rule runtime APIs, but it defines no guidelines for what language to use to define the rules and actions. Efforts are under way to standardize a common rule language, including the Rule Markup Language (RuleML).

For our purpose, though the JSR-94 API are low level APIs and its better to just use some Rules Engine, which confirms to the JSR-94. Though we can use these low level APIs, however, this would make our applications, unnecessarily complicated, if we are concerned just in "using" the Rules Engine.

Conclusion

As we saw already, use of a Rules Engine has got its own advantages and disadvantages. The decision to use it should be taken meticulously. Even more important question is the choice of a rules engine. Weigh your needs and organization goals with what each rules engine has to offer. Nevertheless, considering the Rules Engine as an add-on to your application is always a good consideration to start using Rules Engine in your application so that if it grows complex for the need of rules engine, you may always rely on the intelligence of the Rules Engine.