Roy Schestowitz wrote:
> Open source rule management
>
> Jess and JBoss Rules reviewed
>
> ,----[ Quote ]
> | How to choose between them? If you are especially price-sensitive,
> | then JBoss Rules is the answer; it's free. If you seek a formal
> | network of service partners, or if you like the "true" open source
> | approach that focuses on development, versus user support, again
> | JBoss would be the better choice.
> `----
One of my favorite Rules Engines was Prolog. Really elegent methods
for quickly evaluating complex business rules used to manage complex
relationships between components. Borland had a very nice GUI
interface as well.
The problem was that Business Rules are often almost written by the
Legistlator - In COBOL.
Business Rules can be very complex, because they are generally
agreements arranged by lawyers, who often don't have the primary
interest in the successful transaction, but in generating the "escape
clause" conditions. As a result even when a business rule seems
logical, or seems to make sense, careful reading and interpretation can
reveal that what seemed simple, easy, and logical, suddenly becomes
something very complex, difficult, and not intuitively logical. You
have to design the "intuition" into the complex business rules.
There have been numerous attempts to try and define rules engines using
"WorkFlow" engines, "Transformation" engines, and "Translation"
engines. Most "rules engines" are good at one, but not all. Things
can get really ugly if you try to use one as another.
WBI is a good example of a system that breaks down the components.
The simplest piece in the trivial field-by-field translations of
messages that need to be managed with integrity. A message must be
properly processed by all recipients, or rolled back if transformation
fails. Message Broker lets you route to all recipients, make sure that
the translations are successful, and if there is a failure, can roll
back the requesst on all target recipients.
The simple translation gets more complex when you need to manage
integration between multiple systems. For example, if you want to
integrate SAP, SEIBEL, and PEOPLESOFT, along with the company
accounting system and corporate customer database, things can get
really wierd. Each system has their own idea of "custotmer ID" Which
means you now have to have a way to map one unique customer to each of
the other customers. But you might have a hierarchy of contacts
whithin this contact list. Who is allowed to engage in what tasks?
This is where workflow comes in. The big thing about workflow is not
how it handles the "normal" or "automated" traffic, but how it handles
the exceptions. When do you have to do additional verification? When
should you pass this off to human beings who can resolve the issue
using direct contact with the customer, to clarify the unresolved
issue? The workflow engine or "process orchestrator" can manage this.
This allows each message or transaction to go through the message
system and routing, and allows pending transactions to be routed to
work queues which can be read and responeded to by the right person.
Finally, you have authentication. Who should be allowed to do what?
This is simple in a single-system/single-server application, but when
you have 3-4 different open and proprietary systems, you need a way to
manage all of those identities, roles, responsibilities, and
permissions. This is where LDAP provides a powerful tool. Unlike
traditional relational databases, LDAP is more like a tree with links.
Each node can reference other nodes, creating complex hierarchies, but
also complex networks. For example, if I have a logged in user, and he
wants to access a system that can only be accessed by someone who is
authorized to perform a specific role, and that role is only allowed to
do certain tasks, LDAP provides the tools to establish those
relationships. One person might have 5-6 roles, and their might be 5-6
people capable of performing that specific role. LDAP can match the
person to the role (even if it's through a complex tree), and resolve
that someone has permission to access the resource or function. In
Linux, this can be done using userids, groups, and setuid scripts and
programs, but LDAP manages these permissions across multiple systems
and multiple languages and functions.
Many of the problems that come up when doing a medium sized software
development project, say $1 million or more, can provide some sense of
the problems that need to be dealt with. But when you have a large
network of people doing thousands of $20,000 contracts and deals, and
the pipeline has to produce several million dollars per day, you begin
to see why $50,000 for a system that "gets it right" and can quickly be
changed for quickly changing rules, often supercedes the cost of a
license.
Take the case of a U.S. insurance company. They have 48-50 state
regulatory agencies, federal regulatory agencies, accounting standards,
sarbanes-oxley, SEC regulators, HIPPA, and numerous other standards
complaince things that need to be done. 95% of the transactions can be
fully automated, but the 5% can gum up the works and shut down the
whole system if the performance, availability, security, operational
support, and capacity aren't properly planned and managed. Suddenly
even if only for a few hours, the "money machine" shuts down.
Some of these complex systems generate over $1 million per MINUTE.
> http://www.computerworld.com.au/index.php/id;878069534;fp;4194304;fpid;1
Having said all of this, it is also interesting to point out that many
companies, including BEA, IBM, Sun, and Oracle, now use OSS components
as part of their solutions, because the engines themselves provide
critical functions at a far lower cost and with far less effort and
specialized training - than the prior proprietary technology. And they
run some of these gateway and transformation functions on Linux.
|
|
