Hello Thomas,
I understand what you are saying. I'm afraid in retrospect that I went too far
off-topic, so let me refocus.
I guess its an overly obvious observation that data which requires a rules
engine seems to have a lot of inter-relationships. As a pathelogical case, say
that a Shipment has origin and destination locations, mode of shipment, and
carriers. These attributes are actually fairly complex objects (or tables if
you prefer) which control the application of rules to the Shipment - the
business practices associated with a particular location, carrier, mode, etc.
While there are too many locations in the world to keep them preloaded in the
rules engine, a whole lot of shipments transit the same location (like major
airports) or use the same carriers. The caching, reuse and cross reference of
these "detail objects" seem to be a key design consideration. As you say, the
design of business objects and intelligent caching are important matters. The
nice thing about making them complex EJB objects, is that the system is smart
enough, if warranted, to retrieve part of the Shipment via SQL, re-use carrier
information already loaded into the rules engine, load a location from cache,
etc. All of which is transparent to the rules engine.
[EMAIL PROTECTED] wrote:
> I'm not attempting to compare Toplink to my RDBMS integration framework
> directly. But the general approaches are comparable.
>
> When writing objects to a database, there is a point where Toplink has to
> map changes made to a complex (EJB) object to the database tuples
> representing that object. If the complex object joins multiple database
> tuples, Toplink will usually have to issue multiple SQL statements. Only in
> the (seldom) case of updatable database views this can be done by a single
> statement. The RDBMS will then update the base relation tuples itself.
> Restoring complex objects from multiple database tuples will also involve
> similar steps for both Toplink and my framework.
>
> Surely, there is the important matter of how "intelligently" the database
> connection is done. Aspects include the design of the Business Object Model
> (conceptual level) the database schema (logical level) eventually defining
> the mapping between Business Objects and Database Objects. Another
> important aspect are intelligent caching strategies minimizing database
> interaction.
>
> Look at the following example rule using a business object on the LHS.
>
> (defrule my-rule
> (some-pattern ... (primary-key ?pk) ...)
> (business-object (primary-key ?pk) ...)
> ...
> =>
> ...)
>
> The following rule defines the mapping between the business and its
> database objects. In this case a join is performed by Jess. Another
> possibility could be to define a database view directly representing the
> business object. Depending on the application, either of the two solutions
> can be the optimal one.
>
> (defrule read-business-object
> (need-business-object (primary-key ?pk))
> (primary-database-object (primary-key ?pk) (foreign-key ?fk) ...)
> (secondary-database-object (primary-key ?fk) ...)
> =>
> (assert (business-object (primary-key ?pk) ...)))
>
> Imagine, for instance, a complex join that has to be computed over and over
> again. From a performance point of view it can sometimes be better to
> preload and cache some of the (more) static base relations and to let the
> database engine join the (more) dynamic ones. The rest of the join can then
> be done by the application server, or, in this case, by Jess.
>
> A caching strategy can be implemented by selectively retracting or keeping
> the database facts. Event and/or time-controlled refreshing or purging can
> also be done. For example, in my system I use database triggers in order to
> generate change notifications. These can be used to update the fact list.
>
> To complete the example, the next rule is generated by my framework in
> order to query the database.
>
> (defrule read-primary-database-object
> ?goal <- (need-primary-database-object (primary-key ?pk))
> =>
> (retract ?goal)
> (query-kb "schema.table" ?goal))
>
> 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]
---------------------------------------------------------------------
