AW: AW: [xmlblaster] Rule Based Publishing

[<Michele.Laghi at swisscom.com>]

Hello again,
in any case, if we implement it as a plugin we are still open. We could have a I_RulesEngine and let our plugins implement it. We could then have a jeops based plugin, a javascript plugin (I agree that a user should not need to learn a new language each time) or a tcl plugin or what more ... and then we can start flight ....

Salutissimi
Michele

> -----Ursprüngliche Nachricht-----
> Von: Marcel Ruff [mailto:ruff at swand.lake.de]
> Gesendet am: Dienstag, 23. April 2002 09:18
> An: xmlblaster at server.xmlBlaster.org
> Betreff: Re: AW: [xmlblaster] Rule Based Publishing
> 
> Michele.Laghi at swisscom.com wrote:
> > I had a (very) quick look at jeops and from a first glance 
> it looks pretty similar to jrules (a commercial product).
>  > Making the choice of using it instead of javascript (or even tcl) 
> could suddently transform xmlBlaster
>  > into a rules engine or even a complete workflow engine.
>  > This would broaden the application possibilities of 
> xmlBlaster even more
>  > (I just saw what telecom companies are spending in 
> workflow engines).
> > 
> > So I think it might be interesting to give a closer look at jeops.
> > 
> > Saluti
> > Michele
> 
> Saluto,
> 
> some thoughts about the rule engine JEOPS
> http://www.di.ufpe.br/~jeops/
> 
> 
> JEOPS:
> ======
> 
> /**
>   * Simple rule for trading.
>   */
> rule trade {
>    /* In this rule, one agent will buy a product from another 
> agent. */
>    declarations
>      Salesman s;
>      Customer c;
>      Product p;
>    conditions
>      c.needs(p);  // he won't buy junk...
>      s.owns(p);
>      s.priceAskedFor(p) <= c.getMoney();
>    actions
>      s.sell(p);
>      c.buy(p);
> }
> 
> 
> Javascript:
> ===========
> 
> boolean trade(s, c, p)
> {
>     if (c.needs(p) && s.owns(p) && s.priceAskedFor(p) <= 
> c.getMoney()) {
>        s.sell(p);
>        c.buy(p);
>     }
> }
> 
> I prefere the Javascript approach, every teenager pupil
> knows the syntax (from developing his homepage), the
> customer of the product does not need to learn a new
> language ...
> 
> The next point is we often have to deal with time:
> 
> 
> boolean trade(s, c, p)
> {
>     if (c.needs(p) && s.owns(p) && s.priceAskedFor(p) <= 
> c.getMoney()) {
>        tm.waitForCreditClearance(); // has buyer money
>        s.sell(p);
>        sleep(10000); // bank earns interest rate
>        c.buy(p);
>     }
> }
> 
> or "if terminalserver has delivered more than 100 bytes
> over the last minute and the last byte is not older than 10 sec"
> is a very timing based rule with history information.
> 
> 
> Another point is the dynamic on the fly change of rules
> in a hot running system.
> does JEOPS support this?
> 
> =====================
> 
> On the other hand we could compile the JEOPS rule java classes
> on the fly, and probably gain some performance when
> executing 1 million times.
> 
> JEOPS defines a "Knowledge base" which fits very nice to
> xmlBlaster, our message approach keeps the "Knowledge Base"
> up to date in 'real time' -> a real gain of value.
> 
> Native workflow/rule support in xmlBlaster would be a real
> gain for xmlBlaster, we should follow this track.
> 
> Did i miss the point?
> 
> Marcel
> -- 
> Marcel Ruff
> mailto:ruff at swand.lake.de
> http://www.lake.de/home/lake/swand/
> http://www.xmlBlaster.org
> 
>