Hi!
>I read all the documentation of rule based systems,
Wow! You must have read a lot of stuff ;-)
>but am sorry to say that
>i am still not able to appreciate its importance in a business. Can any
body
>give me some specific example and then quote out by comparing the
difference
>between the procedural and rule based approach.
>From a programming paradigm point of view rulebased programming is
declarative, i.e., the goal is separated from the method used to achieve
that goal. You specify the goal and the underlying mechanism (e.g., Jess'
inference mechanisms) tries to achieve it.
Apart from rulebased systems SQL is a good example of a declarative
approach. You don't care HOW the database query engine performs a query.
You just specify WHAT has to be delivered. Database triggers provide a way
to specify ECA (event-condition-action) rules that are often used to define
business rules. Technically, the same can be done using rulebased systems
like Jess or CLIPS.
The specification of business rules or the definition of a workflow is a
good application for rulebased systems. For example, certain workflow
products (e.g., HP Changengine) or so-called Integration Engines (e.g., IBM
MQSeries Integrator) contain/are rules engines.
Using a procedural approach you'd need to consider each and every
conceivable process routing, which can be a rather tedious and error-prone
task. Using a rulebased approach - the rules are then usually referred to
as business rules - you specify preconditions that have to be met before a
specific action can be performed. In this case the routing is implicit and
the overall complexity should be lower. Tasks can be performed as soon as
preconditions are met, which yields more flexible workflows leveraging any
concurrency inherent to the process.
I use a rulebased approach for system integration. State changes of
business objects, i.e., business events, are monitored and published. Jess
ECA rules are used to specify follow-up actions to be performed in other
information systems. Example: a Sales Order is created and processed by the
Sales Department using a Computer Aided Selling (CAS) system. When the
Sales Order has reached a certain state (event-condition) the process can
proceed by creating a Manufacturing Order (action) in a Production Planning
and Control System.
I've used a rulebased approach (using Jess) for the initialization and
configuration of my component-based integration system. I specify which
components are needed and how they are connected. Upon startup the system
automatically determines how to instantiate and configure the components.
Example: JDBC connections are specified by providing the usual parameters.
Components relying on database connections and other components are
specified using a rule stating any precondition (e.g., the
components/connections that have to exist before this component can be
instantiated) and the statements to be used to instantiate/configure the
component.
Using a usual procedural approach, you need to write a sequential program
lining up the initialization and configuration code in the right order.
>After all what is wrong with
>encoding business knowledge in business objects of business level
middletier
>layer.
Actually, it would be a large step ahead if everybody did it that way.
Unfortunately, business knowledge is scattered all over the parts (I tried
to avoid the notion "components") of existing systems. I must admit that
I'm a great CORBA advocate and that I carried out some consulting projects
and held a lot of talks in that field. And I always suggested exactly what
you'r also saying above.
There might be another advantage of the rulebased approach when compared to
what you (and I, usually) proposed above. Business rules could be specified
in a (largely) system-independent way and stored in a metadata repository,
which would act as a central point of documentation or some kind of
corporate memory. Business rules could then be retrieved by different
systems (workflow and integration engines, application servers using
rulebased systems for business rule processing). Rule maintenance (e.g.,
modifications) would be easier, lowering maintenance costs.
>Kindly quote an business example !!!
See above.
Greetings
Thomas
________________________________
Dipl.-Inform. Thomas Barnekow
Fraunhofer IAO, Competence Center Software Technology
mail: Nobelstra�e 12, D-70569 Stuttgart,
Germany
phone: +49 (0) 711 / 970 - 2346
fax: +49 (0) 711 / 970 - 2300
mobile: +49 (0) 172 / 7126018
email: [EMAIL PROTECTED]
web: http://www.swt.iao.fhg.de
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
