Showing posts with label jboss. Show all posts
Showing posts with label jboss. Show all posts
October 05, 2007
JBoss Drools Example
Paul Browne wrote an article about a small sample application at ONJava.com. It is based on the Drools documentation and consists of a sample application you can downloaded together with Drools. It's worth a look if you wanna get started quick & dirty.
May 06, 2007
JBoss Rules 4.0 M2
According to Marc Proctor, JBoss Rules 4.0 is on it's way. I can't wait to check it out, especially the new RuleFlow feature.
April 17, 2007
Spring EJB integration
Last week I had to integrate Spring 2.0.x with EJB 2.x on JBoss 4.0.5. The problem I ran into was merging multiple ApplicationContext instances.
The actual integration was pretty straightforward, cause the Spring documentation is very good at that point. The real problems were cause by the packaging of our application, which yielded ClassCastExceptions and multiple distinct Spring contexts.
Our application is packaged as follows:
+ EAR
-+ WAR
-+ JAR1
-+ JAR2
The WAR defines a ContextLoadListener in it's web.xml and there's a applicationContext.xml file in the WEB-INF directory. JAR2 contains EJB components, which are using BeanFactoryLocator to initialize and use an ApplicationContext.
So we have 2 contexts, one initialized by the WAR and the second by JAR2. What we needed was a way to merge or link the two contexts. The Spring documentation is quite thin when it comes to this matter, at least I couldn't find any useful information regarding the problem. A blog post on CodeChimp gave the final hint. There is a way to define a hierarchic ApplicationContext, using context-param settings in web.xml. You simply define the ApplicationContext which is the parent and all other child contexts can reference to beans from that ApplicationContext. Another good article, which points out the problem is Migrating to Spring over at ONJava.com.
Another problem we ran into was a ClassLoader problem in Jboss. I think this is not JBoss specific, but I'm not really sure how other containers behave so I'm just gonna tell you what problems we had using JBoss 4.0.5. Since classes loaded in WAR and JAR2 have different ClassLoaders, instances are not treated as the same. So if we referenced a bean loaded through JAR2 in WAR, we would get a ClassCastException. We solved the problem by leveraging JBoss's specific class loading architecture. JBoss provides a ClassLoader, called JBossWebLoader, which disables class loading isolation between WAR and JAR2. This way we can share instances across archives, but we do give up isolation.
The actual integration was pretty straightforward, cause the Spring documentation is very good at that point. The real problems were cause by the packaging of our application, which yielded ClassCastExceptions and multiple distinct Spring contexts.
Our application is packaged as follows:
+ EAR
-+ WAR
-+ JAR1
-+ JAR2
The WAR defines a ContextLoadListener in it's web.xml and there's a applicationContext.xml file in the WEB-INF directory. JAR2 contains EJB components, which are using BeanFactoryLocator to initialize and use an ApplicationContext.
So we have 2 contexts, one initialized by the WAR and the second by JAR2. What we needed was a way to merge or link the two contexts. The Spring documentation is quite thin when it comes to this matter, at least I couldn't find any useful information regarding the problem. A blog post on CodeChimp gave the final hint. There is a way to define a hierarchic ApplicationContext, using context-param settings in web.xml. You simply define the ApplicationContext which is the parent and all other child contexts can reference to beans from that ApplicationContext. Another good article, which points out the problem is Migrating to Spring over at ONJava.com.
Another problem we ran into was a ClassLoader problem in Jboss. I think this is not JBoss specific, but I'm not really sure how other containers behave so I'm just gonna tell you what problems we had using JBoss 4.0.5. Since classes loaded in WAR and JAR2 have different ClassLoaders, instances are not treated as the same. So if we referenced a bean loaded through JAR2 in WAR, we would get a ClassCastException. We solved the problem by leveraging JBoss's specific class loading architecture. JBoss provides a ClassLoader, called JBossWebLoader, which disables class loading isolation between WAR and JAR2. This way we can share instances across archives, but we do give up isolation.
March 18, 2007
FIT for rules
Today I checked out a framework called FIT for rules, which is hosted on sourceforge. I was looking for a way to easily provide a test harness for rules implemented with JBoss Rules. The framework uses Framework for Integrated Test - FIT, which I've blogged about before.
It turns out that the FIT for rules framework tries to provide a single interface for JSR 94 compliant rule engines. This interface is not being invoked programmatically, but by providing configurations, similar to the FIT test itself. The idea of using the JSR 94 specification is great and I think it's the only way to implement this kind of framework. What I don't like is the fact that the configuration of the framework is mixed with the FIT test configuration, but that's just my 2 cents.
Since my drools or now JBoss Rules example is not JSR 94 compliant (another todo), I can't really use the framework without any modification. To provide a simple test harness I updated a former FIT example, which is based on an old version of my drools example. It now uses the latest version with JBoss Rules. The interesting thing is I didn't have to change any code. I only updated the dependencies and the build file. I was surprised myself, especially since the example is about a year old.
I think the FIT approach is great for functional testing, but I'm still looking for some framework or tool which handles unit testing of rules.
It turns out that the FIT for rules framework tries to provide a single interface for JSR 94 compliant rule engines. This interface is not being invoked programmatically, but by providing configurations, similar to the FIT test itself. The idea of using the JSR 94 specification is great and I think it's the only way to implement this kind of framework. What I don't like is the fact that the configuration of the framework is mixed with the FIT test configuration, but that's just my 2 cents.
Since my drools or now JBoss Rules example is not JSR 94 compliant (another todo), I can't really use the framework without any modification. To provide a simple test harness I updated a former FIT example, which is based on an old version of my drools example. It now uses the latest version with JBoss Rules. The interesting thing is I didn't have to change any code. I only updated the dependencies and the build file. I was surprised myself, especially since the example is about a year old.
I think the FIT approach is great for functional testing, but I'm still looking for some framework or tool which handles unit testing of rules.
March 13, 2007
JBoss Rules RuleFlow
JBoss Rules is going to have a new feature in the next mileston release which is called "RuleFlow". According to Mark Proctor's blog it allows
It looks neat and I'm looking forward to check it out with my JBoss Rules example. I believe it'll greatly improve handling and usuability of large rule sets.
... users to create a graphical flow chart that defines the order in which rule sets should be evaluated..
It looks neat and I'm looking forward to check it out with my JBoss Rules example. I believe it'll greatly improve handling and usuability of large rule sets.
February 04, 2007
JBoss Rules with custom DSL
I updated my JBoss Rules example, which I started over a year ago, to use a custom Domain Specific Language (DSL) to create the implemented business rules. I'm only gonna blog about the update here, so you might wanna check out my previous blog about this example.
I started off creating a simple text file (dsl file) which contains the two business rules of my example. Then I moved all the logic of the rules file into the dsl file and associated it with a text. For instance the logic "customer:Customer(discount == true) and bill:Bill()" is being associated with a textual description "There is a customer which gets discount". Those descriptions can then be used as a building block in your rules file. The next step was to use the textual descriptions of the dsl file to build the business rules in a new rules file. Finally I had to do some minor changes in the code to get the DSL working. The outcome of all this is a clean and easy to read rules file. Furthermore you have something like a language that you can use to define your business rules.
I think this approach to define rules is very straightforward and I like it a lot! It so much easier to define a business rule with textual description. To establish a simple and easily readable DSL though, is quite difficult. The tool support in that area, at least with JBoss Rules, is very limited. That makes debugging quite a hassle. I think there should be auto-completion and syntax-highlighting in a dsl file, that would make things easier.
I think of all three example I did, this one is the most simplest and easiest to understand.
I started off creating a simple text file (dsl file) which contains the two business rules of my example. Then I moved all the logic of the rules file into the dsl file and associated it with a text. For instance the logic "customer:Customer(discount == true) and bill:Bill()" is being associated with a textual description "There is a customer which gets discount". Those descriptions can then be used as a building block in your rules file. The next step was to use the textual descriptions of the dsl file to build the business rules in a new rules file. Finally I had to do some minor changes in the code to get the DSL working. The outcome of all this is a clean and easy to read rules file. Furthermore you have something like a language that you can use to define your business rules.
I think this approach to define rules is very straightforward and I like it a lot! It so much easier to define a business rule with textual description. To establish a simple and easily readable DSL though, is quite difficult. The tool support in that area, at least with JBoss Rules, is very limited. That makes debugging quite a hassle. I think there should be auto-completion and syntax-highlighting in a dsl file, that would make things easier.
I think of all three example I did, this one is the most simplest and easiest to understand.
January 21, 2007
Drools and Enterprise Services
Weaving complex business logic into application code makes developers deeply responsible for understanding and maintaining that logic, and means that every change in a company's processes requires a recompile and redeploy. Using a rules engine like Drools offers an opportunity to split the rules into their own files, potentially editable by the subject-matter experts instead of developers. Birali Hakizumwami shows how this approach can be made to work for financial applications like mortgage underwriting systems.
This article gives a good overview of how to incorporate Drools Rule Engines (JBoss Rules) into a real world enterprise application. The domain used in this article is quite complex (mortgage underwriting service) and it's a good example of what I think is a big drawback when using a rule engine: testing!
Don't get me wrong, I think using a rule engine to implement business logic is the way to go. What I'm asking myself is how to test those rules. I believe it's quite difficult to test a single rule using a JUnit TestCase, since it can affect other rules or it needs other rules to determine its outcome. And I guess testing gets even harder when you apply conflicting rules.
I'm wondering if their is some kind of test harness when it comes to rule engines?
