- Implement business logic with the Drools rules engine - The author used Drools rule engine to demonstrate how business logic could be externalized in an application and possibly maintained by end users. Rules are stored in xml format and loaded into a rule engine at runtime. A rule is composed of 3 parts, parameter, condition and consequence. Parameters are passed in by the engine. If condition is met, then the instructions in consequence are executed. The instructions are defined in java language.
- Getting Started With the Java Rule Engine API (JSR 94): Toward Rule-Based Applications - Java Rule Engine API is composed of rules administrator API and runtime client API. Users call the administrator API to register and unregister RuleExecutionSet and call client API to apply the RuleExecutionSet. Several open source rule engines were mentioned in the article as well, including Jess, Drools, FairIssac Blaze Advisor, ILog JRules, etc.
Sunday, March 16, 2008
Open Source Rule Engines
Wednesday, March 12, 2008
An Introduction to Enterprise Service Bus
The first chapter of Open-Source ESBs in Action has a good introduction to Enterprise Service Bus. The followings are discussed in the chapter.
- EAI vs. ESB
- EAI products are based on the hub and spoke model. All data exchange is centralized in the hub.
- ESB products are based on the bus model. Data are distributed to the destinations through the bus. In the distribution process, data/messages can be transformed or enhanced.
- The data exchange in ESB products is based on open standards, such as, JCA, XML, JMS, and web services standards.
- Reasons to start thinking of an ESB
- Necessity to integrate applications
- Heterogonous environment
- Reduction of total cost of ownership
- Core functionalities of an ESB
- Location transparency
- Transport protocol conversion
- Message transformation
- Message routing
- Message enhancement
- Security
- Monitoring and management
- Current open source ESB projects
Monday, March 10, 2008
Managed ThreadId
Managed Stack Explorer allows one to trace stacks for .NET 2.0 applications at run time. This is handy for tracing deadlock problems. But the project I worked on was based on .NET 1.1. What a pity! After a second thought, I realized that I just need to keep track of the resources locked by threads. When deadlock happened, that is, when a thread issued lock request over some resource but failed after a predefined period of time, I dumped the stack frame of the threads locking the resource. Then the problem boiled down to how to identify the resource locking threads. Originally, I used System.AppDomain.GetCurrentThreadId to identify a thread. But according to the documentation, this id is not stable.
Note An operating-system ThreadId has no fixed relationship to a managed thread, because an unmanaged host can control the relationship between managed and unmanaged threads. Specifically, a sophisticated host can use the Fiber API to schedule many managed threads against the same operating system thread, or to move a managed thread among different operating system threads.Instead, to identify a thread in .NET 1.1, use Thread.GetHashCode. For applications in .NET 2.0 and later, use Thread.ManagedThreadId.
Tuesday, March 4, 2008
Oracle AnyData Data Type
Saturday, March 1, 2008
Subscribe to:
Posts (Atom)
