JDK 6 Script Engine

One of the cool feature of jdk1.6 is the ability to call java script from the java code. Have a look at the sample code, which reverse the string using java script

package com.jdk16;

import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;

public class ReverseUsingJS {
public static void main(String args[]) {
ScriptEngineManager scriptManager = new ScriptEngineManager();
ScriptEngine engine = scriptManager.getEngineByName("javascript");
try {
engine.put("name", "reverse");
engine.eval("var outputVar = '';for (i = 0; i <= name.length; i++) {"
+ " outputVar = name.charAt(i) + outputVar" + "}");
String name = (String) engine.get("outputVar");
System.out.println(name);
} catch (ScriptException e) {
System.err.println(e);
}
}
}

Inter Process Orchestration

In this white paper I am thinking, infact had starting making the framework, that will enable inter process orchestration, with due respect to BPEL of the world. I have named this framework as "Process Choreographer"
Note :- Process can be any Java Object.

Process Choreographer is a lightweight Java framework for building workflows using java beans to orchestrate events. You can think of Process Choreographer as a simple alternative to BPEL where the workflows are all specified and implemented using Java code rather than declarative XML.

When building highly concurrent or distributed applications (like insurance claim processing) it is very common for there to be many events happening; often asynchronously and in different threads and its very common to need to perform kinds of workflow or orchestration across these events.

Off course one can certainly use things like BPEL to solve these kinds of problems. However often this is a bit heavy weight & complex and you just want to have a bean based workflow using regular Java code to represent the activities involved in the workflow. Further more, BPEL will always comes with the cost of performance. I have heard many times where my client/patners have asked me, we want to run atleast 10 transaction per second, Process Choreographer framework will be answer to these problems.

One of the main goals of Process Choreographer is to reuse what the Java platform is good for in the workflow space; then supplement it with missing abstractions rather than re inventing the wheel. Hence
1) Write a plain old java class (from where every things begins)
2) Use normal java code construct like if - else, while etc
3) Use regular Java fields in your workflow class, then use JDBC/DAO/JPA to deal with
persistence

While working with various client and their concurrent or distributed applications there are many use cases for needing to orchestrate among multiple concurrent events.

1) starting dependent services that is where a parent component is dependent on the child components starting; where the start process may be asynchronous in different threads. e.g. there may be a recovery process on startup which you need to wait for.
2) implementing master-slave type protocols where you need to monitor the state of the master and slave to make decisions on what to do; together with dealing with transitions from Started to Recovering to Running then maybe to FailingOver etc.
3) implementing message orchestration. You may want to implement some simple orchestrations, waiting for either a response to arrive or a timeout to fire etc

Process Choreographer aim to solve to over come above problem by providing the ability to do the following

1. Execute Process In Sequence

2. Execute Process In Parallel Split

3. Process Synchronization : Synchronize two parallel threads of execution.

4. Process Exclusive choice: Choose one execution path from many alternatives

5. Simple Process Merge: Merge two alternative execution paths

Soon I will update you with design of this framework.

Injecting Transactions Into Rules

First of all, some guys may think this slightly strange. With due respect to rules and not making them procedural, there are several business use case where from the THEN part, there is a need to call the web service. I was experimenting this thought on JBoss Rules, Quick Rules etc rule engine. But interestingly , all these rule engine never stops me calling the Web Service but there is no transaction control over it (distributed transaction). Thanks to java open source world and jboss rules guys, I can play with their code.

How can we inject transaction? Thanks to Spring and declarative transactions, this is very much feasible. So here was my game plan in nut shell, introduce a new attribute in the JBoss Rule grammar named "Transaction" and at the time of rule execution run the spring container and inject the declarative transactions.

BPM, BRM in SOA

Introduction

It’s a myth propagated by many consultants and vendors that Business Rule Management System (BRM) and Business Process Management System (BPM) are two alternatives for creating flexible and agile enterprise solution. There is no denying the fact that BPM uses rules for decision making. As always truth lies somewhere in the middle, BPM and BRMS are like two sides of a coin which can’t be separated, especially if used in conjunction with principle of service oriented architecture (SOA)

The underline idea behind this is totally separate process logic from decision logic. So what is process logic? Process logic is the specific logic of the business process such as controlling the sequence of activities, adhering of deadline and handling of exception. It is implemented using Process Engines like jBPM etc. Decision logic represents process independent management policies and principles and are implemented using rule engines like JBoss rules etc as part of BRMS

Principles of SOA

1. Explicit boundaries
   SOA is a design approach for special enterprise solution and special information technology software architecture

=> Consistent result responsibility

2. Shared Contract and Schema, not class that is, service share common contract

SOA is strictly independent of the technology.

=> Unambiguous service level

3. Service orientation is an evolution of component based architectures that is service are reusable

=> Proactive event sharing

4. Vendor Independent

SOA is strictly independent of the technology

5. Policy Driven

6. Services are discoverable

7. Business Driven

The granularity of the process modeling determines the granularity of the business service

8. Loosely coupled
9. Wire format not programming languages APIs
10. Document oriented

Consider a message in string format

2007-11-0642055

and compare it to document format:

2007-1-06

420

55

BPM & BRM in SOA

BPM is a closed loop model consisting of three steps: -

Step 1: Analyze, plan, model, test and simulate business process

Step 2: Execute business process via workflow spanning all applications

(process logic) by mean of process engine on a SOA as the

infrastructure.

Step 3: Plan, monitor and control processes, their performance and the

interplay of all business process.

BRP is a closed loop model consisting of three steps: -

Step 1: Based on business vocabulary it describes rules

Step 2: Describes the lifecycle of rules perform analysis, and design

simulation and test, via execution through rule engine.

Step3: Rule monitoring and controlling including responsibilities.

SOA transforms existing business computing assets into well-defined services. It can work effortlessly with BPM because of the reliance on services. SOA exposes services while BPM consumes them. When properly implemented, SOA opens a vast inventory of services for BPM to piece together into an all-inclusive flow of services.

While BPM defines and orchestrates the flow

The drive to use SOA to create a more agile infrastructure also highlights the importance of externalizing highly volatile business logic that is subject to change.

Highly volatile business logic can be defined as business rules. In the traditional application structure these business rules are buried in the application while in a more modern approach they are separated. Just as process flow can be separated from application code into an external BPM engine, the same can be done with business rules. Separating both process flow and business rules empowers a business analyst to make operational changes more quickly, providing maximum flexibility and adaptability.

An important shared characteristic of BPM, BRM and SOA is that they all deliver tactical cost/time benefits while building a base for competitive growth. Each one contributes to the overall agility of a company's IT infrastructure in the long term.

Business application companies such as Oracle/PeopleSoft/Siebel and SAP are contributing to the new opportunity of SOAs by supplying a new class of business applications called service-oriented business applications (SOBAs). SOBAs provide extended functionality for use on Web services standards and should contribute significantly to a company's repository of business services.

So the evolution toward service orientation as an enterprise elevates process thinking, analytics and performance measurement as core competencies to achieve competitive advantage. Accordingly, companies should establish best practices around these disciplines in parallel with implementing the supporting technologies.

Process and Rules in SOA

Many business areas employ rules. Traditional examples include marketing strategies,
pricing policies, customer relationship management practices, human resources activities,
regulatory constraints, product and service offerings. As rules evaluation matured, areas
such as recommendation technology revolve around rules.
Although the definitions of processes and rules differ the differences are not as clear cut.
Typically both rules and orchestration concepts are intertwined within the definition of a
business process.

Feature of rule engines vs orchestration engine (BPM)

Execution time Rules Engines strive to evaluate business rules as quickly as possible. In
contrast, ORCHESTRATION ENGINEs cater to long-running processes, where services
can take minutes, hours or even days to complete.

Synchronicity Rules evaluation is synchronous. In contrast, processes are intrinsically
asynchronous. Typically the ORCHESTRATION ENGINE invokes services in an
asynchronous manner. The mechanisms required to deal with asynchonicity such as
correlation and compensations are readily available in orchestration environments.

Statefulness Rules Engines are stateless; when a rule fires an engine typically pulls its
inputs from the knowledge base, evaluates it, and then updates the knowledge base.
In contrast, ORCHESTRATION ENGINEs are specifically designed to hold the state
(i.e., execution context) of each active orchestration.

Determinism The Rules Engine fires simultaneously all rules whose conditions are satisfied.
The order in which these rules actually execute is non-deterministic. In contrast,
process implementations strive for close alignment with the business. Business
processes are deterministic, and people go to great lengths to ensure determinism.

Rules are orchestrated by the process engine the same way as other services. This is absolutely consistent and show SOA elegance and power. Decision logic is primarily understood as business logic, as its process independent. This underscores the principle of the resusability of services. Rules are modeled and implemented once and are then available for use in different processes.

The right way of using rule engine by mean of BRM for all process-independent rules in SOA and it bring following merits: -

1. reusability of services and hence higher productivity.

2. rule change control mechanism can be controlled.

3. rule changes are versioned and achieved

4. process independent of rules.

Example, showing rule and process are closely coupled

WHEN status=new
THEN DO
creditRating:=call(creditService,customerData)
status:=ranked
END
WHEN status=ranked AND creditRating=threshold
THEN DO
floodCertification:=call(floodService,propertyAddress)
END
WHEN status=ranked AND creditRating>=threshold
THEN DO
appraisedValue:=call(appraisalService,propertyAddress)
END
WHEN status=ranked AND haveCertification and haveAppraisal
THEN DO
decision:=call(decisionService,application,creditRating,floodCertification,
appraisedValue)
status:=decisioned
END

WHEN status=decisioned
THEN DO
documentation:=call(letterService,application,decision)
status:=documented
END
WHEN status=documented
THEN DO
call(mailingService,documentation)
status:=mailed
END

Challenges in BRM

<<todo>>

JBoss Seam

What is JBoss Seam

JBoss definition of JBoss Seam is “It’s a lightweight framework of Java EE 5.0”

After reading this definition normally following question starts popping up:-

• Isn’t Java EE (Enterprise Edition) 5.0 itself a collection of

“frameworks”?

• Why do you need another one that is outside the official specification

Then what is actually JBoss Seam? JBoss seam can be viewed as “missing framework “, that should have been included in Java EE 5.0.

Key Features

1. It sits on top of Java EE 5.0 framework to provide a consistent and easy to understand programming model for all components in an enterprise web application
2. It also makes stateful applications and business process-driven applications a breeze to develop.

So, JBoss Seam is an agile framework. That is, Seam is all about developer productivity and application scalability.

The “glue” to Java Framework

The core framework in Java EE 5.0 is composed of:-

• EJB (Enterprise Java Bean) 3.0. EJB3 is a POJO (Plain Old Java Objects) based lightweight framework for business services and data persistence
• JSF (Java Server Faces) 1.2. JSF is a MVC (Model View Controller) component framework for web application

To make EJB3 and JSF work together, there is requirement for an artificial facade object (which is normally called backing bean) to tie business components to web pages, and boilerplate code to make method calls across framework boundaries. Gluing these technologies is the part of JBoss Seam.

Seam collapses the artificial layer between EJB3 and JSF. It provides a consistent, annotation based approach to integrate EJB3 and JSF. With a few simple annotations, the EJB3 business components in Seam can now be used directly to back JSF web forms or handle web UI events. Seam allows developers to use the “same kind of stuff”, annotated POJOs, for all application components. In another word, Seam brings out the synergy between EJB3 and JSF.

Designed for Stateful application

Seam is designed for stateful applications. Web applications are inherently multi – user applications and e-commerce based applications are inherently stateful and transactional.

In Seam, all the basic application components are inherently stateful. They are much easier to use than the HTTP session since their states are declaratively managed by Seam. There is no need to write distracting state management code in a Seam application -- just annotate the component with its scope, lifecycle methods, and other stateful properties -- and Seam takes over the rest. Seam stateful components also provide much finer control over user states than the plain HTTP session does. For instance, you can have multiple “conversations”, each consisting of a sequence of web requests and business method calls, in a HTTP session.

Furthermore, database caches and transactions can be automatically tied with the application state in Seam. Seam automatically holds database updates in memory and only commits to the database at the end of a conversation. The in-memory cache greatly reduces database load in complex stateful applications.

Seam takes state management in web applications a big step further by supporting integration with the Open Source JBoss jBPM business process engine.

POJO Services via Dependency Injection

Seam is a “lightweight framework” because it promotes the use of POJO (plain old Java objects) as service components. There are no framework interfaces or abstract classes to “hook” components into the application.

Seam wires POJO components together using a popular design pattern known as “dependency injection” (DI). Under this pattern, the Seam framework manages the lifecycle of all the components. When a component needs to use another, it declares this dependency to Seam using annotations. Seam determines where to get this dependent component based on the application’s current state and “injects” it into the asking component.

Expanding on the dependency injection concept, a Seam component A can also create another component B and “outjects” the created component B back to Seam for other components, such as C, to use later.

Avoid XML Abuse

Annotation based approach coupled with configuration by exception approach of JBoss Seam has made possible to remove hassles of xml configurations

Designed for testing

Seam is designed from ground up for easy testing. Since all Seam components are just annotated POJOs, they are very easy to unit test

RETE

The Rete algorithm uses a rooted acyclic directed graph, the Rete, where the nodes, with the exception of the root, represent patterns, and paths from the root to the leaves represent left-hand sides of rules. At each node is stored information about the facts satisfied by the patterns of the nodes in the paths from the root up to and including this node. This information is a relation representing the possible values of the variables occurring in the patterns in the path.

The Rete algorithm keeps up to date the information associated with the nodes in the graph. When a fact is added or removed from working memory, a token representing that fact and operation is entered at the root of the graph and propagated to its leaves modifying as appropriate the information associated with the nodes.

Example

When a fact is modified, say, the age of Ram is changed from 20 to 21, this is expressed as a deletion of the old fact (the age of Ram is 20) and the addition of a new fact (the age of Ram is 21).

The Rete Algorithm s intended to improve the speed of forward-chained rule systems by limiting the effort required to recomputed the conflict set after a rule is fired. Its drawback is that it has high memory space requirements. It takes advantage of two empirical observations:

• Temporal Redundancy: The firing of a rule usually changes only a few facts, and only a few rules are affected by each of those changes.
• Structural Similarity: The same pattern often appears in the left-hand side of more than one rule.

The Rete consists of:-

· Root node

· Of one input-pattern nodes

· Two input join nodes

The root node has as successors one-input "kind" nodes, one for each possible kind of fact (the kind of a fact is its first component). When a token arrives to the root a copy of that token is sent to each "kind" node where a SELECT operation is carried out that selects only the tokens of its kind.

Then for each rule and each of its patterns we create a one input alpha node. Each "kind" node is connected to all the alpha nodes of its kind and delivers to them copies of the tokens it receives. To each alpha node is associated a relation, the Alpha Memory, whose columns are named by the variables appearing in the node's pattern. For example, if the pattern for the node is (is-a-parent-of ?x ?y) then the relation has columns named X and Y. When a token arrives to the alpha node a PROJECT operation extracts from the token tuple's the components that match the variables of the pattern. The resulting tuple is added to the alpha memory of the node.

Then, for each rule Ri, if Ai,1 Ai,2 ... Ai,n are in order the alpha nodes of the rule, we construct two-input nodes, called Beta Nodes, Bi,2 Bi,3 ... Bi,n where

Bi,2 has its left input from Ai,1 and its right input from Ai,2

Bi,j, for j greater than 2, has its left input from Bi,j-1

and its right input from Ai,j

At each beta node Bi,j we store a relation, the Beta Memory, which is the JOIN of the relations associated to its left and right input, joined on the columns named by variables that occur in both relations. For example if the left input relation and right input relations are:

               X              Y                            X              Z

               =========                            =========

               ann          4                             ann          tom

               sam         22                           ann          sue

                                                             tom          jane

then the resulting beta memory relation is

               X              Y             Z

               =================

               ann          4              tom

               ann          4              sue

Finally the last beta node of each rule is connected to a new alpha node where a
PROJECT operation takes place to select all and only the variables that occur on
the right-hand side of the rule.

New Articles/Papers

I am currently working on white paper on BPM/BRM ins SOA.

Key points knocking in my mind
=======================
1. Expose rules as webservice (how to auto generate code)
2. Where and how logic (business/presenatation etc) can exposed as web service? That is Process
Logic and Decision Logic in SOA
3. Processes and Rules in an SOA
4. Challenges in BRMS exposing logic as SOA

Few More Areas of My Research
=======================
1. Rule Analytics
2. Rule execution simulation and testing
3. Rule authoring & security. How to make sure changes in the rule conditions (IF part).
That is, something on the line of Rule Fraud Detection
3. Rule of BRMS in claim management
4. Orchestration framework both Inter and Intra process
5. Increasing availability (caching solutions), looking into open source solution like Terracota vs
paid solution like Tangasol conhernece
6. Rule base Navigation handling that is, flexib le web page navigation handling using Rules
Engine
7. Rule based UI validations
8. Sync and Async parallel execution framework using java.util.concurrent
9. Rule Processing and BPM design patterns