久久久久久亚洲,欧美精品三区,精品久久毛片

Give Your Business Logic a Framework with Drools

哼哼 — Mon, 03 Sep 2007 09:40:00 GMT

Most web and enterprise Java applications can be split into three parts: a front end to talk to the user, a service layer to talk to back-end systems such as databases, and business logic in between. While it is now common practice to use frameworks for both front- and back-end requirements (e.g., Struts, Cocoon, Spring, Hibernate, JDO, and Entity Beans), there is no standard way of structuring business logic. Frameworks like EJB and Spring do this at a high level, but don't help us in organizing our code. Wouldn't it would be great if we could replace messy, tangled if...then statements with a framework that gave us the same benefits of configurability, readability, and reuse that we already enjoy in other areas? This article suggests using the Drools rules engine as a framework to solve the problem.

The sample code below gives a sample of the problem we're trying to avoid. It shows some business logic in a typical Java application.

if ((user.isMemberOf(AdministratorGroup)
      && user.isMemberOf(teleworkerGroup))
     || user.isSuperUser(){

         // more checks for specific cases
         if((expenseRequest.code().equals("B203")
           ||(expenseRequest.code().equals("A903")
                        &&(totalExpenses<200)
                &&(bossSignOff> totalExpenses))
           &&(deptBudget.notExceeded)) {
               //issue payments
           } else if {
               //check lots of other conditions
           }
} else {
     // even more business logic
}

We've all come across similar (or even more complex) business logic. While this has been the standard way of implementing business logic in Java, there are many problems with it.

What if the business users come up with another form ("C987") that needs to be added to the already hard-to-understand code? Would you want to be the person to maintain it, once all of the original programmers had moved on?
How do we check that these rules are correct? It's hard enough for technical people--never mind commercial folks--to review. Do we have any methodical way of testing this business logic?
Many applications have similar business rules--if one of the rules change, can we be sure that it is changed consistently across all systems? If a new application uses some of these rules, but also adds some new ones, do we need to rewrite all of the logic from scratch?
Is the business logic easily configurable, not so firmly tied to Java code that we need to recompile/redeploy every time that a small change is made?
What if other (scripting) languages want to leverage the existing investment in business rule logic?

J2EE/EJB and "inversion of control" frameworks (such as Spring, Pico, and Avalon) give us the ability to organize our code at a high level. While they are very good at providing reusability, configuration, and security, none of them would replace the "spaghetti code" in the above example. Ideally, whatever framework we choose will be compatible with not only J2EE applications, but also "normal" Java (J2SE--Standard Edition) programs, and most of the widely used presentation and persistence frameworks. Such a framework should allow us to do the following:

Business users should be able to easily read and verify the business logic.
Business rules should be reusable and configurable across applications.
The framework should be scalable and performant under heavy load.
It should be as easy to use for Java programmers as existing front-end (Struts, Spring) and back-end (object-relational mapping) frameworks.

An additional problem is that while there are only so many ways to organize web pages and database access, business logic tends to differ widely between applications. Our framework should be able to cope with this and still promote code reuse. Ideally, our application would be "frameworks all the way down." By using frameworks in this way, we can a large amount of our application "out of the box," allowing us to write only the parts that add value for the customer.

Rule Engines to the Rescue

How are we going to solve this problem? One solution that is gaining traction is to use a rule engine. Rule engines are frameworks for organizing business logic that allow the developer to concentrate on things that are known to be true, rather than the low-level mechanics of making decisions.

Often, business users are more comfortable with expressing things that they know to be true, than to express things in an if...then format. Examples of things that you might hear from a business expert are:

"FORM 10A is used for expense claims over 200 Euro."
"We only trade shares in quantities of 10,000 or more."
"Purchases over �?0m need the approval of a company director."

By focusing on what we know to be true, rather than the mechanics of how to express it in Java code, the above statements are clearer than our previous code sample. Still, clear as they may be, we still need a mechanism to apply these rules to the facts that we know and get a decision. Such a mechanism is a rule engine.

Rule Engines in Java

JSR 94, the javax.rules API, sets a common standard for interacting with rule engines, much as JDBC allows us to interact with varying databases. What JSR-94 does not specify is how the actual rules are written, leaving plenty of choice among the most widely used Java rule engines:

Jess is perhaps the most mature Java rule engine, with good tool support (including Eclipse plugins) and documentation. However it is a commercial product, and it writes its rules in a Prolog-style notation, which can be intimidating for many Java programmers.
Jena is an open source framework, originally from HP. While it has a rules engine, and is especially strong for those interested in the Semantic Web, it is not fully JSR-94-compliant.
Drools is a JSR-94-complaint rules engine, and is fully open source under an "Apache-style" license. Not only does it express rules in familiar Java and XML syntax, it has a strong user and developer community. For the examples in this article, we'll be using Drools, as it has the easiest to use Java-like syntax and it has the most open license.

Starting a Java Application using Drools

Imagine this scenario: minutes after reading this article, your boss asks your to prototype a stock trading application. As the business users still haven't fully defined the business logic, you think it a good idea to implement it using a rules engine. The final system will be accessible over an intranet and will need to communicate with back-end database and messaging systems. To get started, download the Drools framework (with dependencies). Create a new project in your favorite IDE and make sure all of the .jars are referenced in it, as per Figure 1. This screenshot is Eclipse-based, but the setup will be similar for other IDEs.

Figure 1. Libraries needed to run Drools

Due to the huge potential losses if our stock trading system went amok, it's vital that we have some sort of simulator to put our system through its paces. Such a simulator also gives you confidence that the decisions made by the system are those that are intended, even after rule changes are made. We'll borrow some tools from the Agile toolbox and use JUnit as a framework for our simulations.

The first code we write is the JUnit Test/simulator, as per the following listing. Even if we can't test every combination of values likely to be input into our application, some tests are better than none at all. In this example, all of our files and classes (including unit tests) are in one folder/package, but in reality, you would implement a proper package and folder structure. We'd also use Log4j instead of the System.out calls in the sample code.


import junit.framework.TestCase;
/*
* JUnit test for the business rules in the
* application.
*
* This also acts a 'simulator' for the business
* rules - allowing us to specify the inputs,
* examine the outputs and see if they match our
* expectations before letting the code loose in
* the real world.
*/
public class BusinessRuleTest extends TestCase {
/**
* Tests the purchase of a stock
*/
public void testStockBuy() throws Exception{
//Create a Stock with simulated values
StockOffer testOffer = new StockOffer();
testOffer.setStockName("MEGACORP");
testOffer.setStockPrice(22);
testOffer.setStockQuantity(1000);
//Run the rules on it
BusinessLayer.evaluateStockPurchase(testOffer);
//Is it what we expected?
assertTrue(
testOffer.getRecommendPurchase()!=null);
assertTrue("YES".equals(
testOffer.getRecommendPurchase()));
}
}

This is a basic JUnit test, as we know that our (very simple!) system should buy all stocks with a price of less than 100 Euro. Obviously, this won't compile without our data holding class (StockOffer.java) and our business layer class (BusinessLayer.java). These are provided in the following listings.

/**
* Facade for the Business Logic in our example.
*
* In this simple example, all our business logic
* is contained in this class but in reality it
* would delegate to other classes as required.
*/
public class BusinessLayer {
/**
* Evaluate whether or not it is a good idea
* to purchase this stock.
* @param stockToBuy
* @return true if the recommendation is to buy
*   the stock, false if otherwise
*/
public static void evaluateStockPurchase
(StockOffer stockToBuy){
return false;
}
}

The StockOffer class looks like this:

/**
* Simple JavaBean to hold StockOffer values.
* A 'Stock offer' is an offer (from somebody else)
* to sell us a Stock (or Company share).
*/
public class StockOffer {
//constants
public final static String YES="YES";
public final static String NO="NO";
//Internal Variables
private String stockName =null;
private int stockPrice=0;
private int stockQuantity=0;
private String recommendPurchase = null;
/**
* @return Returns the stockName.
*/
public String getStockName() {
return stockName;
}
/**
* @param stockName The stockName to set.
*/
public void setStockName(String stockName) {
this.stockName = stockName;
}
/**
* @return Returns the stockPrice.
*/
public int getStockPrice() {
return stockPrice;
}
/**
* @param stockPrice The stockPrice to set.
*/
public void setStockPrice(int stockPrice) {
this.stockPrice = stockPrice;
}
/**
* @return Returns the stockQuantity.
*/
public int getStockQuantity() {
return stockQuantity;
}
/**
* @param stockQuantity to set.
*/
public void setStockQuantity(int stockQuantity){
this.stockQuantity = stockQuantity;
}
/**
* @return Returns the recommendPurchase.
*/
public String getRecommendPurchase() {
return recommendPurchase;
}
}

We run BusinessRuleTest through the JUnit extension of our favorite IDE. If you're not familiar with JUnit, more information can be found at . Not surprisingly, our test fails at the second assertion, shown in Figure 2, as we don't (yet) have the appropriate business logic in place. This is reassuring, as it shows that our simulator/unit tests are highlighting the problems that they should.

Figure 2. JUnit test results

Writing the Business Logic using Rules

At this point, we need to write some business logic that says, "If the stock price is less than 100 Euro, then we should buy it." To do this, we will modify BusinessLayer.java to read:


import java.io.IOException;
import org.drools.DroolsException;
import org.drools.RuleBase;
import org.drools.WorkingMemory;
import org.drools.event.DebugWorkingMemoryEventListener;
import org.drools.io.RuleBaseLoader;
import org.xml.sax.SAXException;
/**
* Facade for the Business Logic in our example.
*
* In this simple example, all our business logic
* is contained in this class but in reality it
* would delegate to other classes as required.
* @author default
*/
public class BusinessLayer {
//Name of the file containing the rules
private static final String BUSINESS_RULE_FILE=
"BusinessRules.drl";
//Internal handle to rule base
private static RuleBase businessRules = null;
/**
* Load the business rules if we have not
* already done so.
* @throws Exception - normally we try to
*          recover from these
*/
private static void loadRules()
throws Exception{
if (businessRules==null){
businessRules = RuleBaseLoader.loadFromUrl(
BusinessLayer.class.getResource(
BUSINESS_RULE_FILE ) );
}
}
/**
* Evaluate whether or not to purchase stock.
* @param stockToBuy
* @return true if the recommendation is to buy
* @throws Exception
*/
public static void evaluateStockPurchase
(StockOffer stockToBuy) throws Exception{
//Ensure that the business rules are loaded
loadRules();
//Some logging of what is going on
System.out.println( "FIRE RULES" );
System.out.println( "----------" );
//Clear any state from previous runs
WorkingMemory workingMemory
= businessRules.newWorkingMemory();
//Small ruleset, OK to add a debug listener
workingMemory.addEventListener(
new DebugWorkingMemoryEventListener());
//Let the rule engine know about the facts
workingMemory.assertObject(stockToBuy);
//Let the rule engine do its stuff!!
workingMemory.fireAllRules();
}
}

This class now has some important methods:

loadRules(), which loads the rules from the BusinessRules.drl file.
An updated evaluateStockPurchase(), which evaluates these business rules. Some points to note about this method are:
- We can reuse the same RuleSet over and over (as business rules in memory are stateless).
- We use a new WorkingMemory for every evaluation, as this is our knowledge of what we know to be true at this time. We use assertObject() to place known facts (as Java Objects) into this memory.
- Drools has an event listener model, to allow us to "see" what is going on within the event model. Here we use it to print debug information.
The fireAllRules() method on the working memory class causes the rules to be evaluated and updated (in this case, stock offer).

Before we can run the example again, we need to create our BusinessRules.drl file, as follows:






java.lang.Object


java.lang.String


net.firstpartners.rp.StockOffer



public void printStock(
net.firstpartners.rp.StockOffer stock)
{
System.out.println("Name:"
+stock.getStockName()
+" Price: "+stock.getStockPrice()
+" BUY:"
+stock.getRecommendPurchase());
}






StockOffer




stockOffer.getRecommendPurchase() == null


stockOffer.getStockPrice() < 100



stockOffer.setRecommendPurchase(
StockOffer.YES);
printStock(stockOffer);

This rules file has several interesting parts:

Just after the XML-Schema definitions come the Java objects we reference in our rules. These objects can come from any Java library as required.
Next comes our functions, which can incorporate standard Java code. In this case, we incorporate a logging function to help us see what is going on.
After that comes our rule set, consisting of one or more rules.
Each rule can take parameters (the StockOffer class), one or more conditions that need to be fulfilled, and a consequence that is carried out if and when the conditions are met.

Having modified and compiled our code, we run the JUnit test simulations again. This time, the business rules are called, our logic evaluates correctly, and our tests pass, as seen in Figure 3. Congratulations--you've just built your first rule-based application!

Figure 3. Successful JUnit test

Smarter Rules

Fresh from building the application, you demonstrate the prototype above to the business users, and they remember a few more rules that they forgot to mention earlier. One of the new rules is that we shouldn't trade stocks where the quantity is a negative number (<0). "No problem," you say, and return to your desk, secure in the knowledge that you can quickly evolve your system.

The first thing you do is to update your simulator, and add the following code to BusinessRuleTest.java:


/**
* Tests the purchase of a stock
* makes sure the system will not accept
* negative numbers.
*/
public void testNegativeStockBuy()
throws Exception{
//Create a Stock with our simulated values
StockOffer testOffer = new StockOffer();
testOffer.setStockName("MEGACORP");
testOffer.setStockPrice(-22);
testOffer.setStockQuantity(1000);
//Run the rules on it
BusinessLayer
.evaluateStockPurchase(testOffer);
//Is it what we expected?
assertTrue("NO".equals(
testOffer.getRecommendPurchase()));
}

This tests for the new rule described by the business users. If we run this JUnit test, our new test fails, as expected. We need to add a new rule to our .drl file, as follows.






StockOffer



stockOffer.getStockPrice() < 0



stockOffer.setRecommendPurchase(
StockOffer.NO);
printStock(stockOffer);

This rule is similar in format to the previous one, expect that our is different (testing for negative numbers) and the sets the recommend purchase to No. We run our unit tests/simulator again, and this time the test passes.

At this point, if you're used to procedural programming (like most Java programmers), you may be scratching your head: here we have a file containing two separate business rules, yet we haven't told the rule engine which is more important. However, our stock price (of -22) satisfies both rules (i.e., it is less than 0 and it is less than 100). Despite this, we get the correct result, even if we swap the order of the rules around. How does this work?

The extract of the console output below helps us to see what is going on. We see that both rules are firing (the [activationfired] line), and that the Recommend Buy is first set to Yes and then to No. How does Drools know to fire these rules in the correct order? If you look at the Stock Price Low Enough rule, you will see that one of the conditions is that recommendPurchase() is null. This is enough for the Drools rule engine to decide that the Stock Price Low Enough rule should be fired before the Stock Price Not Negative rule. This process is called conflict resolution.


FIRE RULES
----------
[ConditionTested: rule=Stock Price Not Negative;
condition=[Condition: stockOffer.getStockPrice()
< 0]; passed=true; tuple={[]}]
[ActivationCreated: rule=Stock Price Not Negative;
tuple={[]}]
[ObjectAsserted: handle=[fid:2];
object=net.firstpartners.rp.StockOffer@16546ef]
[ActivationFired: rule=Stock Price Low Enough;
tuple={[]}]
[ActivationFired: rule=Stock Price Not Negative;
tuple={[]}]
Name:MEGACORP Price: -22 BUY:YES
Name:MEGACORP Price: -22 BUY:NO

If you're a procedural programmer, no matter how clever you think this is, you still may not trust it completely. That is why we have our unit tests/simulator: "hard" JUnit tests (using normal Java code) ensure that the rule engine makes its decisions along the lines we want it to. (And doesn't spend billions on worthless stock!) At the same time, the power and the flexibility of our rule engine allows us to quickly develop the business logic.

Later on, we will see more sophisticated forms of conflict resolution.

Conflict Resolution

Now the folks on the business side are really impressed and are starting to think through the possible options. They've come across a problem with stocks of XYZ Corp and have decided to implement a new rule: Only buy stocks of XYZ Corp if they are less than 10 Euro.

As before, you add the test to our simulator and include the new business rule in our rules file, as per the following listings. First, we add a new method to BusinessRuleTest.java:


/**
* Makes sure the system will buy stocks
* of XYZ corp only if it really cheap
*/
public void testXYZStockBuy() throws Exception{
//Create a Stock with our simulated values
StockOffer testOfferLow = new StockOffer();
StockOffer testOfferHigh = new StockOffer();
testOfferLow.setStockName("XYZ");
testOfferLow.setStockPrice(9);
testOfferLow.setStockQuantity(1000);
testOfferHigh.setStockName("XYZ");
testOfferHigh.setStockPrice(11);
testOfferHigh.setStockQuantity(1000);
//Run the rules on it and test
BusinessLayer.evaluateStockPurchase(
testOfferLow);
assertTrue("YES".equals(
testOfferLow.getRecommendPurchase()));
BusinessLayer.evaluateStockPurchase(
testOfferHigh);
assertTrue("NO".equals(
testOfferHigh.getRecommendPurchase()));
}

Next, we need a new in BusinessRules.drl:





StockOffer


stockOffer.getStockName().equals("XYZ")


stockOffer.getRecommendPurchase() == null


stockOffer.getStockPrice() > 10



stockOffer.setRecommendPurchase(
StockOffer.NO);
printStock(stockOffer);

Note that in the business rules file, after the rule name, we set our salience to -1 (i.e., the lowest priority of all of the rules we have specified so far). Most of the rules in our system conflict, meaning Drools must make some decision on the order in which to fire rules, given that the conditions for all of the rules will be met. The default way of deciding is:

Salience: A value we assign, as per the above listing.
Recency: How many times we have used a rule.
Complexity: Specific rules with more complicated values fire first.
LoadOrder: The order in which rules are loaded.

If we did not specify the saliency of our rule in this example, what would happen is:

The XYZ Corp rule ("Don't buy XYZ if the price is more than 10 Euro") would fire first (the status of the Recommend Buy flag would be set to No).
Then the more general rule ("Buy all stock under 100") fires, setting the Recommended Buy flag to yes.

This would give a result that we don't want. However, since our example does set the saliency factor, the test and our business rules work as expected.

While most of the time, writing clear rules and setting the saliency will give enough information to Drools for it to choose the proper order in which to fire rules, sometimes we want to change the entire manner in which rule conflicts are resolved. An example of how to change this is given below, where we tell the rule engine to fire the simplest rules first. A word of warning: be careful when changing conflict resolution, as it can fundamentally change the behavior of the rule engine--a lot of problems can be solved first with clear and well-written rules.


//Generate our list of conflict resolvers
ConflictResolver[] conflictResolvers =
new ConflictResolver[] {
SalienceConflictResolver.getInstance(),
RecencyConflictResolver.getInstance(),
SimplicityConflictResolver.getInstance(),
LoadOrderConflictResolver.getInstance()
};
//Wrap this up into one composite resolver
CompositeConflictResolver resolver =
new CompositeConflictResolver(
conflictResolvers);
//Specify this resolver when we load the rules
businessRules = RuleBaseLoader.loadFromUrl(
BusinessLayer.class.getResource(
BUSINESS_RULE_FILE),resolver);

For our simple application, driven by JUnit tests, we don't need to alter the way the Drools resolves rule conflicts. It is useful to know how conflict resolution works, especially when your application grows to meet more complex and demanding requirements.

Conclusion

This article demonstrated a problem that most programmers have had to face: how to put some order on the complexity of business logic. We demonstrated a simple application using Drools as a solution and introduced the notion of rule-based programming, including how these rules are resolved at runtime. Later on, a follow-up article will take these foundations and show how to use them in an enterprise Java application.

Resources

Sample code for this article
Drools Project home page
Info on Drools rules
"Introduction to Drools and Rule Engines," by the Drools project lead
Drools rules schema files
JSR-94, Java Rule Engines, Overview
Struts framework website
Spring framework website
Hibernate website
JUnit test framework
Jess Java rule engine
Jena semantic and rule engine
JSR-94 home page
Jess in Action home page
"Business Rule Thinking" (Jess-based)
"General Introduction to Rule Systems"
"Jess Implementation of the Rete Algorithm"

Paul Browne , based in Dublin, Ireland, has been consulting in enterprise Java with FirstPartners.net for almost seven years.

哼哼 2007-09-03 17:40 发表评论

Using Drools in Your Enterprise Java Application

哼哼 — Mon, 03 Sep 2007 09:28:00 GMT

Using Drools in Your Enterprise Java Application

by Paul Browne
08/24/2005

These days enterprise Java could almost put you to sleep. How many hundreds of J2EE-EJB web applications have been written that capture information from a web page and store it in a database? What really keeps developers awake at night is trying to write and maintain the complex business logic in their applications. This is a problem not only for new applications, but increasingly, for long-lived, business-critical apps whose internal logic needs to change frequently, often at very short notice.

In an earlier article, "Give Your Business Logic a Framework with Drools," I introduced the Drools framework and showed how it could be used to organize complicated business logic. Drools replaced many tangled if ... then statements with a simple set of things known to be true. If you are ever in a meeting with business customers, and your head hurts with the complexity of what they want you to implement, then maybe you should consider a rule engine such as Drools. This article will show you how you can do this in an enterprise Java application.

Frameworks All the Way Down

Most enterprise Java developers already have their favorite frameworks. In no particular order, these include presentation frameworks (Struts, JSF, Cocoon, and Spring), persistence frameworks (JDO, Hibernate, Cayenne, and Entity Beans) and structural frameworks (EJB, Spring again, Pico, and Excalibur), as well as many others. Each framework does one very useful thing (or more), and gives developers a lot of instant "out of the box" functionality. Deploying an application using frameworks means you avoid a lot of the boring bits and concentrate on what is really needed.

Until now, there was a gap in what the frameworks were able to do, in that business logic had no framework. Tools like EJB and Spring are good, but have little to say about how to organize your if ... then statements! Adding Drools to your developer toolbox means that it is now possible to build an application with "frameworks all the way down." Figure 1 shows a diagram of such an application.

Figure 1. Frameworks for Java applications

This article will build on what we already know of the Drools framework and allow us to build such an application.

When Should I Use a Rule Engine?

It's almost a cliche in software engineering to say that "if you have a hammer, everything looks like a nail." While rule engines can solve a lot of problems for us, it is worth considering whether a rule engine is really appropriate for our enterprise Java application. Some questions to ask are:

How complex is my application? For applications that shuffle data to and from a database, but not much more, it is probably best not to use a rule engine. However, where there is even a moderate amount of processing implemented in Java, it is worthwhile to consider the use of Drools. This is because most applications develop complexity over time, and Drools will let you cope easily with this.
What is the lifetime of my application? The answer to this is often "surprisingly long"--remember the mainframe programmers who thought their applications wouldn't be around for the year 2000? Using a rule engine pays off, especially in the medium to long term. As this article demonstrates, even prototypes can benefit from the combination of Drools and agile methods to take the "prototype" into production.
Will my application need to change? The only sure thing about your requirements is that they will change, either during or just after development. Drools helps you cope with this by specifying the business rule in one or more easy-to-configure XML files.

What About Performance?

If you're writing an enterprise application, chances are that it will need to scale to hundreds, if not thousands, of users. You know that existing Java and J2EE applications can do this, but how will a application using Drools cope with this pressure? The answer is "surprisingly well." While most developers hate to "lose control" and rely on other people's code (i.e., a framework), consider the points below--not only should your application be as fast as "traditional" coding methods, but Drools may even make your application run faster:

Avoids badly written code: Drools guides developers to do "the right thing." You may be sure the code you are writing is good, but would you say the same for the code of your co-developers? Using a framework makes it easier to write good, fast code.
Optimized framework: How often have you seen business logic that repeatedly accesses a database for the same information, slowing down the entire application? Used correctly, Drools can remember not only the information, but also the results of previous tests using this information, giving the entire application a speed boost.
Rete algorithm: Many times we apply "if" conditions that we didn't really need. The Rete algorithm, as implemented by Drools, replaces all of the if ... then statements with an optimized network. It is important to note that the Rete algorithm involves a tradeoff between using more memory to reduce delays at run time. While this isn't a factor in most modern servers, we wouldn't yet recommend deploying Drools on your mobile phone!

Where Were We?

In our previous article, we wrote a simple stock trading application based around the Drools engine. We implemented various business rules, showed how we could rapidly change the rules to meet changing business requirements, and wrote JUnit tests to give us a high degree of confidence that the system would act as it was supposed to. However, the application as we left it had little or no user interface, and used hard-coded data instead of a database. To evolve our application into something that is more enterprise level, we need to add two main things:

Some sort of user interface, ideally based one of the standard web-presentation frameworks.
A Data Access Object (DAO) to let Drools work with a database (or other back end system).

Calling the Rule Engine from a Presentation Framework

Most enterprise Java applications are accessed using a web interface, and one of the most widely adopted web-presentation frameworks is Struts, from Apache. Ideally, we'll write our application so that the presentation layer knows about the business layer underneath, but not the other way around. This has the advantage not only of allowing us to change the presentation framework at a later date (e.g., to an Ajax or web service interface), but also means the code examples give should be readily applicable to other web frameworks like Spring.

The following code snippet demonstrates how to call the business logic tier (using the rule engine) from the web presentation layer. The code uses the results to decide which page to display. In this sample, we use a Struts action, but the code is similar for any other web framework or even a servlet or a JSP page. This snippet works with a supporting struts-config.xml, JSP pages to post/display data, and a way of generating the WAR file for deployment. The snippet shows how to integrate the rule engine with the web framework.


import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
import BusinessLayer;
/**
* Sample Struts action with Pseudocode
*/
public class SampleStrutsAction extends Action{
/**
* Standard Struts doPerfom method
*/
public ActionForward doPerform(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws InvalidEntryPointException {
//Local Variables
StockOffer userOffer =null;
//Get any previous values from the session
userOffer=(StockOffer)request.getSession()
.getAttribute("PREVIOUS_STOCK_OFFER");
//create this object if it is null
if (null==userOffer){
userOffer = new StockOffer();
}
//Update with the incoming values
//These values match those on the form
userOffer.setStockName(request.
getParameterValue("STOCK_NAME"));
userOffer.setStockPrice(request
.getParameterValue("STOCK_PRICE"));
userOffer.setStockQuantity(request
.getParameterValue("STOCK_QTY"));
//Reset the output value
userOffer.setRecommendPurchase(null);
//Call the Business Layer
BusinessLayer
.evaluateStockPurchase(userOffer);
//Forward to the appropriate page
if ("YES".equals(
testOffer.getRecommendPurchase()){
return mapping.findForward("YES_WEB_PAGE");
}
//otherwise default to the no page
return mapping.findForward("NO_WEB_PAGE");
}
}

There are a couple of things going on this sample. Often, we build up the data we need from the user over several web pages, so this sample shows how we can achieve this by retrieving the StockOffer object that we have previously stored in the web server session. Next, we update the StockOffer with any values that the user may have changed on the web page. We then reset the recommendPurchase flag to clear any previous results before we call the business logic layer. Finally, we take the response of the business logic and use it to decide which page to forward the user to.

In this example, note how we split the business logic (yes/no on whether or not to buy a stock) from the presentation logic (decide which page to go to). This allows us to reuse our business rules across several different applications In addition, take look at how the state information (i.e., things that the user has already told us) is stored in the StockOffer object/web server session, and not in the business layer. By keeping the business layer stateless in this way, we make the entire application much more scalable and performant.

Integrating the Rule Engine with the Database Layer

So far, our application has a web presentation layer and a rules engine for the business layer, but no means of getting data to and from a database. This section gives an example of how to do this. We base our example on the Data Access Object (DAO) pattern, where we encapsulate all code that "talks" to the database (or back-end data source) in one pluggable, configurable class. As such, the example is applicable to other persistence frameworks, such as Hibernate and Cayenne.

Some important points about the way we want to organize the data layer are:

Only the business layer should talk to the data layer; if a class in the presentation layer (front end) wants some data, it should pass through the business layer first. This helps makes our code easier to organize and read.
As far as possible, we should keep our data layer stateless--we should hold client data elsewhere (e.g., in the server session at the web front end, as per the previous example). This is distinct from caching of data, which we can do at this level. The difference between the two is state information is often user-specific, while data we cache at the data access layer is mainly sharable across the application. Organizing our layer in this way increases performance.
We should allow the business logic to decide if data is needed or not--if not needed, the call to get the data should not be made.

To implement our simple Data Access Object, we create three new objects: StockNameDao, DaoImplementation, and DaoFactory.

StockNameDao is an interface that defines two methods: getStockNames() returns a list of the stock names that we deal with, and isOnStockList() checks that a given stock is on the list of stocks that we deal with. Our business layer will call these methods as and when it needs the information.

DaoImplementation is an actual implementation of StockNameDao. In this case the values are hard-coded, but we could have queried a database or accessed an information system like Bloomberg via a web service.

DaoFactory is what we use to create an appropriate instance of StockNameDao. The advantage this approach has over creating the class directly is that it allows us to configure what DAO implementation we use at runtime (frameworks like Spring are especially good at this). One factory can return many types of DAOs (e.g., StockNameDao, StockPriceDao, StockHistoryDao), which means we can pass in our DaoFactory, and let the individual rules decide on the data and DAOs that they require.

Here's what the StockNameDao interface looks like:


/**
* Defines a Data Access Object - a non data
* source specific way of obtaining data.
*/
public interface StockNameDao {
/**
* Get a list of stock names for the application
* @return String[] array of stock names
*/
public String [] getStockNames();
/**
* Check if our stock is on the list
* @param stockName
* @return
*/
public boolean isOnStockList(String stockName);
}

And here's the DaoImplementation:


/**
* Concrete Definition of a Data Access Object
*/
public class DaoImplementation
implements StockNameDao {
/**
* Constructor with package level access only
* to encourage use of factory method
*
*/
DaoImplementation(){}
/**
* Get a list of stock names for the app.
* This is a hard coded sample
* normally we would get this from
* a database or other datasource.
* @return String[] array of stock names
*/
public String[] getStockNames() {
String[] stockNames=
{"XYZ","ABC","MEGACORP","SOMEOTHERCOMPANY"};
return stockNames;
}
/**
* Check if our stock is on the list
* @param stockName
* @return true / false as appropriate
*/
public boolean isOnStockList(String stockName){
//Get our list of stocks
String stockList[] = getStockNames();
//Loop and see if our stock is on it
// done this way for clarity . not speed!
for (int a=0; a


The simple DaoFactory just returns a DaoImplementation:

package net.firstpartners.rp;
/**
* Factory Method to get the Data Access Object.
* Normally we could replace this with a
* framework like Spring or Hibernate
*/
public class DaoFactory {
/**
* Get the stock name Dao
* This sample is hardcoded - in reality
* we would make this configurable / cache
* instances of the Dao as appropriate
* @return an instance of StockNameDao
*/
public static StockNameDao getStockDao(){
return new DaoImplementation();
}
}




Now that we have our simple DAO implementation to serve as our database layer, how do we integrate it with the Drools business layer? The updated business rules file, BusinessLayer.xml, shows us how.







java.lang.Object


java.lang.String


net.firstpartners.rp.StockOffer


net.firstpartners.rp.DaoFactory


net.firstpartners.rp.StockNameDao







DaoFactory




public void printStock(
net.firstpartners.rp.StockOffer stock)
{
System.out.println(
"Name:"+stock.getStockName()
+" Price: "+stock.getStockPrice()
+" BUY:"+stock.getRecommendPurchase());
}






StockOffer




stockOffer.getStockName().equals("XYZ")


stockOffer.getRecommendPurchase() == null


stockOffer.getStockPrice() > 10




stockOffer.setRecommendPurchase(
StockOffer.NO);
printStock(stockOffer);








StockOffer



stockOffer.getStockPrice() < 0



stockOffer.setRecommendPurchase
(StockOffer.NO);
printStock(stockOffer);






StockOffer



daoFactory.getStockDao().isOnStockList(
stockOffer.getStockName())


stockOffer.getRecommendPurchase() == null


stockOffer.getStockPrice() < 100



stockOffer.setRecommendPurchase(
StockOffer.YES);
printStock(stockOffer);





There are several changes to this file to integrate the data access layer with our business rules:

    At the top of the file, we have several new  statements to reference the StockNameDao, DaoImplementation, and DaoFactory classes that we added to the system.
    
We have a new tag, , which assigns an instance of the DaoFactory class to a variable.  tags are similar to parameters, except they apply to all business rules, and not just one.
    
The Stock Price Low Enough rule has a new condition, which uses the DaoFactory and StockNameDao to check if the stock is on the list of those that we deal with. 

We run our BusinessRulesTest (simulator) again. The simulator/unit tests run OK, since even though we have changed the structure of the program, we haven't (yet) changed what it does. From looking at the output logs, we can see that our business rules are using StockNameDao as part of their evaluations, and that DaoImplementation.isOnStockList() is being called.
While this example shows the reading of information from a data source, the principles are the same for writing information, if that is what a rule has decided should be done. The differences would be that our DAO would have a setSomeInformation() method, and that the method would be called in the  part of the business rule, once the specific conditions had been met.

Summary
In this article, we showed that most Java server applications have three tiers: presentation, business logic, and data persistence. While the use of frameworks is widely accepted in the presentation and persistence layers, until now no framework has been available to encapsulate low-level business logic. As we've seen in the examples, Drools and JSR-94 are ideal candidates for reducing the complexity and speeding the development of Java applications. I hope that these examples inspire you to take a closer look at rule engines, and that they save many hours of development and maintenance time in your applications.
Resources

    Sample code for this article
    
Drools Project home page
    
Information on Drools rules
    
"Introduction to Drools and Rule Engines," by the Drools project lead.
    
Drools rules schema files
    
JSR-94: Java Rule Engines, Overview
    
Struts framework website
    
Spring framework website
    
Hibernate website
    
JUnit test framework
    
Jess Java rule engine
    
Jena semantic and rule engine
    
JSR-94 home page
    
Jess in Action home page
    
"Business Rule Thinking" (Jess-based)
    
General introduction to rule systems
    
"Jess implementation of the Rete algorithm" 

Paul Browne , based in Dublin, Ireland, has been consulting in enterprise Java with FirstPartners.net for almost seven years. 


哼哼 2007-09-03 17:28 发表评论



Implement business logic with the Drools rules engine
哼哼 — Mon, 03 Sep 2007 09:24:00 GMT
     摘要: Implement business logic with the Drools rules engine
Use a declarative programming approach to write your program's business logic


http://www-128.ibm.com/developerworks/java/library/j-drools/
...  阅读全文

哼哼 2007-09-03 17:24 发表评论


Drools Documentation
哼哼 — Mon, 03 Sep 2007 08:36:00 GMT
     摘要: Drools


Drools Documentation



http://anonsvn.labs.jboss.com/labs/jbossrules
Mark Proctor




Michael Neale




Michael Frandsen




Sam Griffith Jr.




Edson Tirelli

...  阅读全文

哼哼 2007-09-03 16:36 发表评论


BI相关的开源工��P��转）
哼哼 — Sat, 30 Dec 2006 04:26:00 GMT

		
				转自�Q?a >http://challenger11.blogdriver.com/challenger11/1241587.html

我们都知道“瞎子摸象”的故事。不同的瞎子对大象的认识不同�Q�因��Z��们只认识了自己摸到的地方。而企业如果要避免重犯�q�样的错误，那就���M��开商务������Q�BI�Q�。专家认为，BI对于企业的重要性就像聪明才智对于个人的重要性。欧���企业的�l�验也证明，企业避免无知和一知半解危险的有效手段���是商务�����。商务智能旨在充分利用企业在日常�l�营�q�程中收集的大量数据和资料，�q�将它们转化��Z��息和知识来免除各�U�无知状态和瞎猜行�ؓ�?/b>  

		
				支持BI的开源工��h��量众多，但是大多数的工具都是偏重某方面的。例如，CloverETL偏重ETL�Q�JPivot偏重多维分析展现�Q�Mondrian是OLAP服务器。而Bee、Pentaho和SpagoBI�{�项目则针对商务�����问题提供了完整的解决�Ҏ���?/font>
		

		ETL 工具 
		ETL开源工具主要包括CloverETL和Octupus�{��?
		�Q?�Q�CloverETL是一个Java的ETL框架�Q�用来�{换结构化的数据，支持多种字符集之间的转换�Q�如ASCII、UTF-8和ISO-8859-1�{�）�Q�支持JDBC�Q�同时支持dBase和FoxPro数据文�g�Q�支持基于XML的�{换描�q��?
		(2)Octupus是一个基于Java的ETL工具�Q�它也支持JDBC数据源和��Z��XML的�{换定义。Octupus提供通用的方法进行数据�{换，用户可以通过实现转换接口或者��用Jscript代码来定义�{换流�E��?
		OLAP服务�?
		(1)Lemur主要面向HOLAP�Q�虽焉���用C++�~�写�Q�但是可以被其他语言的程序所调用。Lemur支持基本的操作，如切片、切块和旋�{�{�基本操作�?
		(2)Mondrian面向ROLAP包含4层：表示层、计���层、聚集层、存储层�?
		�?表示层：指最�l�呈现在用户昄���器上的以及与用户之间的交互，有许多方法来展现多维数据�Q�包括数据透视表、饼、柱、线状图�?
		�?计算层：分析、验证、执行MDX查询�?
		�?聚集层：一个聚集指内存中一�l�计����?cell)�Q�这些值通过�l�列来限制。计���层发送单元请求，如果��h��不在�~�存中，或者不能通过旋�{聚集导出的话�Q�那么聚集层向存储层发送请求。聚合层是一个数据缓冲层�Q�从数据库来的单元数据，聚合后提供给计算层。聚合层的主要作用是提高�pȝ��的性能�?
		�?存储层：提供聚集单元数据和维表的成员。包括三�U�需要存储的数据�Q�分别是事实数据、聚集和�l��?
		OLAP客户�?
		JPivot是JSP风格的标�{�ֺ��Q�用来支持OLAP表，使用户可以执行典型的OLAP操作�Q�如切片、切块、上钅R��下�ȝ��。JPivot使用Mondrian服务器，分析�l�果可以导出为Excel或PDF文�g格式�?
		数据库管理系�l?
		主要的开源工具包括MonetDB、MySQL、MaxDB和PostgreSQL�{�。这些数据库都被设计用来支持BI环境。MySQL、MaxDB和PostgreSQL均支持单向的数据复制。BizGres��目的目的在于��PostgreSQL成�ؓ数据仓库�?BI的开源标准。BizGres为BI环境构徏专用的完整数据库�q�_���?
		完整的BI开源解��x���?
		1.Pentaho 公司的Pentaho BI �q�_�� 
		它是一个以���程��Z��心的、面向解��x��案的框架�Q�具有商务智能组件。BI �q�_��是以���程��Z��心的�Q�其中枢控制器是一个工作流引擎。工作流引擎使用���程定义来定义在 BI �q�_��上执行的商务��������程。流�E�可以很�Ҏ��被定�Ӟ��也可以添加新的流�E�。BI �q�_��包含�l��g和报表，用以分析�q�些���程的性能。BI �q�_��是面向解��x��案的�Q���^台的操作是定义在���程定义和指定每个活动的 action 文档里。这些流�E�和操作共同定义了一个商务智能问题的解决�Ҏ��。这�?BI 解决�Ҏ��可以很容易地集成到��^台外部的商业���程。一个解��x��案的定义可以包含��L��数量的流�E�和操作�?
		BI�q�_��包括一�?BI 框架、BI �l��g、一�?BI 工作台和桌面收�g���。BI 工作台是一套设计和���理工具�Q�集成到Eclipse环境。这些工具允许商业分析�h员或开发�h员创建报表、��A表盘、分析模型、商业规则和 BI ���程。Pentaho BI �q�_��构徏于服务器、引擎和�l��g的基���之上�Q�包括J2EE 服务器、安全与权限控制、portal、工作流、规则引擎、图表、协作、内容管理、数据集成、多�l�分析和�pȝ��建模�{�功能。这些组件的大部分是��Z��标准的，可��用其他��品替换之�?
		2.ObjectWeb 
		该项目近日发布了SpagoBi 1.8版本。SpagoBi 是一�Ƒ֟�于Mondrain+JProvit的BI�Ҏ���Q�能够通过OpenLaszlo产生实时报表�Q��ؓ商务�������目提供了一个完整开源的解决�Ҏ���Q�它�늛�了一个BI�pȝ��所有方面的功能�Q�包括：数据挖掘、查询、分析、报告、Dashboard仪表板等�{�。SpagoBI使用核心�pȝ��与功能模块集成的架构�Q�这样在���保�q�_���E�_��性与协调性的基础上又保证了系�l�具有很强的扩展能力。用��h��需使用SpagoBI的所有模块，而是可以只利用其中的一些模块�?
		SpagoBI使用了许多已有的开源��Y�Ӟ��如Spago和Spagosi�{�。因此，SpagoBI集成�?Spago的特征和技术特点，使用它们���理商务�����对象�Q�如报表、OLAP分析、��A表盘、记分卡以及数据挖掘模型�{�。SpagoBI支持BI�pȝ��的监控管理，包括商务�����对象的控制、校验、认证和分配���程。SpagoBI采用Portalet技术将所有的BI对象发布到终端用��P��因此BI对象���可以集成到为特定的企业需求而已�l�选择好的Portal�pȝ��中去�?
		3.Bee��目 
		该项目是一套支持商务智能项目实施的工具套�g�Q�包括ETL工具和OLAP 服务器。Bee的ETL工具使用��Z��Perl的BEI�Q�通过界面描述���程�Q�以XML形式�q�行存储。用户必���d��转换�q�程�q�行�~�码。Bee的ROLAP 服务器保证多通SQL 生成和强有力的高速缓存管�?使用MySQL数据库管理系�l?。ROLAP服务器通过SOAP应用接口提供丰富的客户应用。Web Portal作�ؓ主要的用��h��口，通过Web���览器进行报表设计、展�C�和���理控制�Q�分析结果可以以Excel、PDF、PNG、PowerPoint�?text和XML�{�多�U��Ş式导出�?
		Bee��目的特点在于： 
		�?���单快��L��数据讉K���Q?
		�?支持预先定义报表和实时查询； 
		�?通过拖拽方式��L��实现报表定制�Q?
		�?完整报表的轻松控�Ӟ�� 
		�?以表和图�q�行高质量的数据展示�?/p>


哼哼 2006-12-30 12:26 发表评论


哼哼 — Fri, 08 Sep 2006 06:18:00 GMT

		
				    2006�q�的BI产品���把数据仓库建模以及数据挖掘�{�技术实质性地应用�q�来。同时BI技术将与ERP、CRM、企业门��L��技术相融合�Q��Ş成集成化的��品�?
		
		
				    �l�过2005�q�的强劲发展�Q�中国商业智能（BI�Q���Y件市场销售额辑ֈ�10.15亿元人民币，�q�增长率辑ֈ�54.96�Q��?006�q�_��随着履行加入WTO全面开攑ָ�场承诺时间的临近和中国企业国际化的步伐加快以及政府职能的全面转变�Q�中国金融、电信、政府、零售、制造等行业对商业智能技术应用的需求全面爆发。赛�q�顾问预�?006�q�中国BI软�g市场规模���超�q?6亿元人民�?见图1)�?
    
    国内商业�����软�g市场���呈现十大发展趋�ѝ�?
    
    ���势一:融合多种技术的集成产品出现�?
    
    2006�q�BI产品技术的发展���势是：��q��有的初步应用如报表分析、数据集成，向深度和�q�度应用发展�Q�数据仓库徏模和数据挖掘�{�技术的应用���实质性推开�?
    
    2006�q�的BI产品���把数据仓库建模以及数据挖掘�{�技术实质性地应用�q�来。同时BI技术将与ERP、CRM、企业门��L��技术相融合�Q��Ş成集成化的��品。尤其在面向中小企业用户的企业管理��Y件方案中�Q�ERP、CRM厂商会将BI�Ҏ��嵌入到自��q��ERP或CRM�pȝ��中。而整合了企业门户的BI产品�Q�在��Z���~�少旉���、必���d��注意力放在真正重要的决策规则上的�q�代�Q�可以减���作决策时必���d��析的数据量�?
    
    ���势�?BI产品的整体�h格在逐步下降�?
    
    在�h格方面，BI软�g一直处于高端�h位，提供�l�信息化�����“贵族”��用。而以中小企业��Z��表的中、低端客��P��也希望花上几十万���可以上一套BI软�g。因此无论是国际BI厂商�q�是国内BI企业都针寚w��、中、低端用户呈现出不同的�h格策略，��M��价位呈现下降���势。这为国内更�q�大的企业应用BI产品提供了可能�?
    
    ���势�?高端市场归属国际�Q�中低端落户国内�?
    
    中国的BI市场从开始就�l�历了一个激烈竞争的时期�Q�高端市�����国际大厂商所占据�Q�低端市场是国内的BI厂商及行业的ISV及集成商在竞争�?006�q�中国的BI市场可能在低端市场初步出现像用友、金蝶在财务套装软�g那样的格局�Q�几个大的国内BI厂商凭借本地化和销售网�l�占据市�?0�Q�以上的市场份额。而在大的行业市场里，BI���会与解��x��案融合在一��P��市场被行业的ISV所把持�?
    
    ���势�?在营销�{�略上，整合营销���势凸显�?
    
    2006�q�BI厂商���面临激烈而现实的市场竞争。营销手段、��品研发受到前所未有的重视。更多的软文宣传、研讨会�Q�包括行业研讨会�Q�、新品发布会、��E讲以及联合、�ƈ购等���会�?006�q�中国BI市场里上演。多�U�多��L��营销方式���让人目不暇接�?
    
    ���势�?用户重视效益�Q�关注BPM�?
    
    用户之所以投入巨额资金购买BI软�g�Q�目的都是希望对�q�营数据�q�行分析�Q�以实现实时响应。对于企业来�Ԍ���q�希望BI能够支持企业���程优化以及提高生��力。当然其最�l�目标都是向�_�������理要效益。但是目前的很多�l�织�q�没有徏立胦务标准来衡量此项IT投入的效益。�ؓ此，���BI技术和�l�效���理���结合而�Ş成的BPM (企业�l�效���理)成�ؓBI领域用户的关注点。在应用领域斚w���Q�BPM可以深入特定的业务流�E�或功能�Q�在功能划分斚w���Q�BPM可按企业业务功能划分�Q�如财务�l�效���理、客户关�pȝ�W效管理、生产运营�W效管理、交叉业务�W效管理；在系�l�构造方面，BPM能够协调业务�z�d��以达到特定的�l�果�Q�如�~�制预算、评估关键供应商�{�。因此，BI软�g供应商在用BI技术提升企业�W效上面做文章�Q�一定会辑ֈ�一定的用户满意度。   �?/font>
		

		
				                                                         
		
		
				    ���势�?以��品�ؓ依托�Q�增值服务成主角�?
    
    目前BI软�g领域中的多数软�g供应商，其��Y件授权收入和服务收入基本持��^�Q�但随着数据仓库和查询、报表工兯��Y件的应用普及�Q�下一步如何开展分析型应用���成��Z����|��从销售��品中可获得的收入���逐渐降低。此消彼长，帮助用户建立分析和挖掘模型等应用解决�Ҏ��和咨询服务的收入���在明年上升�Q�最�l�将���过软�g产品授权收入。因此，如何在提供增值服务这��C��轮的较量中胜出，是BI软�g供应商现在需要未雨绸�~�的。   �?br />    
    ���势�?应用范围不断扩展�Q�区域边界日���模�p��?
    
    目前�Q�华北、华东和华南地区BI软�g占据了绝大部分的市场份额�Q�而其它四地区的市��Z��额相对偏低。但华北、华东、华南地区由于电信、金融、政府等行业信息化水�q����高，�U�篏了大量数据，渴望从这些数据中��L���Q�因此，2006�q�内���仍是BI软�g的主要应用领域。但随着BI软�g应用范围的不断扩大和用户认知度的提升�Q�各BI软�g供应商将致力于开拓其它区域的市场。另�?006�q�国家的“西部大开发”和“振兴东北老工业基地”两大战略的深入推进和实施，���促�q�西部和东北地区对于交通、能源、电信、电子政务的������Q�这���在一定程度上带动襉K��和东北地区对于BI软�g产品及应用的需求，从而�ؓBI软�g的推�q�和应用带来新的发展机遇。（见图2�Q?/font>
		

		
				                                                       
		
		
				    ���势�?中小企业的BI应用市场份额���逐渐扩大�?
    
    虽然在垂直市��Z���Q�大型企业依然是BI的应用主体，但是中小企业的BI应用需求开始释放�?
    
    中小企业���来���注重自�w�徏设，已经意识��C��息化的重要性和�q�切性。因此，国内�q�大的中���企业逐渐呈现对管理��Y件旺盛的需求态势�Q�必���成�?006�q�国�?BI市场重要�l�成部分。国际一���的BI厂商BO公司和国内BI领域��g��者菲奈特公司已经开发出适合中小企业应用的BI解决�Ҏ���?
    
    赛��_���N��预计2006�q�国内中���企业对BI的应用需求将快速增长，市场份额���由2005�q�的32.7%上升�?2.5%�Q�成为BI市场上新的增长亮炏V��（见图3�Q��?/font>
		

		
				                                                        
		
		
				    ���势�?优势行业��C��不减�Q�行业集成和解决�Ҏ��成�ؓ��L���?
    
    从行业应用来看，中国的金融业、电信业�?006�q�仍���占据着BI应用的优势行业地位。另外政府和消费品制造业及零售业(如百货企业及�q�锁企业)对BI的需求也不容忽视。由于BI的分析型应用���在未来占主导地位，每个行业又都需要不同的行业知识�Q�因此电信及金融的BI业务���会被行业的集成及ISV占据一定的市场份额。（见图4�Q��?/font>
		

		
				                                                        
		
		    ���势�?��d��厂商竞争从“群雄逐鹿”到“三���鼎立”�?
    
    2006�q�主力厂商的竞争���由“群雄逐鹿”态势转变到“三���鼎立”的格局。高端市��Z���l�国际大厂商占有明显优势�Q�中低端市场仍然是国内的BI厂家及行业的 ISV�Q�独立��Y件开发商�Q�及集成商的地盘�Q�新兴的厂商后来居上�Q�迅速抢占高、中、底端市��Z��而在BI市场里�Ş成新�?“三���鼎立”态势竞争格局�?
    
    高端市场上BO、Hyperion、NCR、IBM 、甲骨文、微软、SAS�{�传�l�的国际专业BI厂商������l�占据高端市场相当䆾额�?
    
    国内的专业BI厂商及行业的ISV�Q�专业BI厂商菲奈特，�?006�q�将�l�箋作�ؓ国内BI厂商领先代表扛�v国��化大旗，而用友、金蝶、博�U�等软�g企业的市场潜力正逐步昄����?006�q�市��Z��额将快速上升�?
    
    2005�q�涌入国内BI市场的新兴力量，如三��q����Z��息技术有限公司（MDIT�Q�、上���h��癄���企业。将会成�?006�q�中国BI市场的黑马。传�l�国际厂商、国内BI企业和新�q�入企业����Ş�?006�q�中国BI市场“三���鼎立”之�ѝ�?/font>


哼哼 2006-09-08 14:18 发表评论