I guess the biggest “feature” in BE4 is the multi-threaded rule engine capability. Can give a very useful performance boost on multi-core systems and can be simpler than going multi-engine…

Cheers

Amazingly, BusinessEvents is the only product to offer good state models for tracking entity states. I have never understood why.

SQL-like vendors offer something that Esper calls patterns. This is a way of expressing something like “event A before event B but not before event C”. This kind of thing is very useful, but provides only limited control over states.

No other CEP product allows you to define a state model for an order (for example) and have the system track the order through the states.

Some vendors let you code your own state machine in a script-like language, but I would not consider this to be the same thing.

I look forward to see where Tibco BE heads in the future.

My comments apply mostly to the current shipping version of BusinessEvents, which has extended its distribution mechanism over the version you have docs for.

“the engine first looks in working memory …”
Since BE2.2, the strategy per class is set by the developer, for in-memory only, cache+memory (default), and cache-only (i.e. explicit retrieval) modes. This is for fine-tuning and performance reasons, obviously.

“data is divided into concept instances and event data”
Event objects are really just a special type of object (and with appropriate event classes). Events are characterised by their Time To Live (how long they live in the Event Processing Agent, whether rule-driven or otherwise), and what “consumes” them. The latter is important because the registration of “consumption” can be used by the middleware layer to determine a successful “delivery” of the event. If the system has a catastrophic failure before event consumption, the event can be consumed by another agent instead.

“data tends to be relatively static, so it makes sense to put it in an in-memory database”
The in-memory role is primarily for reduced latency. CEP is about comparing new events with past events, so the latter must be easily (and speedily) accessible, whilst be capable of being updated as needed with information from the new events.

“asserting the same facts in multiple rule engines will cause each engine to go through the pattern matching process”
In the general sense, yes, but remember that raw / external events are only ever delivered to a single agent (for processing, and thence assertions / updates to any shared facts).

“Does BE integrate coherence Maps for the node memories, or is it simply using coherence as an external datastore?”
The latter, as sharing Rete node information would not be useful for other Event Processing Agent types (ie non-Rete) that are contributing to the solution.

[Incidentally, for usage advice and commentary with BE, end-users and partners should head over to TIBCOmmunity's BE discussion forums.]

Cheers

When the Instance.getByExtId(extId) function is invoked, the engine first
looks in working memory and the Rete network for references to the instance. If
none are found, then the engine gets the instance from the cache and asserts it into
working memory. If the entity instance is not found in working memory or cache,
your application logic determines what to do next, for example, create a new
instance of that entity type.

From my understanding of how BE works, data is divided into concept instances and event data. The concept instances “can” reside in coherence outside of BE rule engine. The event data enters BE through channels. What BE calls concept instances sounds functionally similar to initial facts in expert systems. That data tends to be relatively static, so it makes sense to put it in an in-memory database. I can’t tell if the event data is also stored in coherence. Is event data also stored in coherence? The paragraph seems to imply developers are responsible for partitioning the data and asserting it to each BE engine instance. Is that a correct interpretation?

In the interest of exploration, I thought it would be good to explain the approach I used to implement fault tolerance with Rete. In Jamocha, the alpha and beta node memories use HashMaps. When I implemented a proof of concept fault tolerance with coherence, I changed my collection factory to return coherence HashMap, instead of java.util.HashMap. This has several benefits for those familiar with fault tolerant Rete. The first is that one engine in the cluster performs the pattern matching. The other active engines sharing the same rules and facts have their node memories updated through coherence. This avoids asserting the same facts in multiple active engines sharing the same rules and eliminates redundant rule activation. The second is that if the fact doesn’t create any partial matches, it never replicates the node memories, since there’s nothing to replicate. In contrast, asserting the same facts in multiple rule engines will cause each engine to go through the pattern matching process.

For the record, this is basically what Oracle did with JESS. I’ve been blogging about this specific topic since 2005, so several people in the field are aware of these issues. The redundant activation issue is quite old and predates my own research. When I designed jamocha, I specifically chose to use Maps for this reason. The other benefit of using Maps for the node memories is it makes it easier to implement distributed Rete.

Does BE integrate coherence Maps for the node memories, or is it simply using coherence as an external datastore?

“replicating just the beta node indexes is much more efficient than replicating all facts”
Which is certainly true if you are replicating all facts on every (rule execution) cycle, as the Rete index represents a “compiled form” of the conditions dependent on those facts.

But in BE (’s Rule Engine) you are:
(a) not replicating the entire WM on every cycle
(b) only replicating certain WM “as needed” (and even then, note that “notification of change” <> “replicate WM fact”, and that not all WM will need to be shared anyway)
(c) due to the event-at-a-time nature of continuous, complex event processing, we are likely to be replicating small numbers of facts in any cycle anyway.

So any assumption that the
Performance(replication(index)) << Performance(replication(WM delta))
is, at best, very use case and implementation dependent - and in the case of CEP, where the WM delta for shared facts may be very small, this might not be the overhead some might assume…

[Note: I don't want to undermine Peter's work on Distributed Rete - developing a distribution mode for Rete indexes, handling the issues of managing rule (Rete) updates, etc, are all complex problems - is very interesting, although probably with high levels of dependancy on middleware latency like any other distributed rule solution, and probably unproven in a CEP application.]

In any case, thanks for the dialog as it certainly helps to explain / position how BE works!