At TUCON last month we announced BusinessEvents 4.0, which went GA (General Availability) at the end of May. It is worth going into a bit more detail over what is new and how this moves the game on for complex event processing applications.
First, a few comments on the typical use cases where BusinessEvents is being applied:
- high throughput (eXtreme Transaction Processing style) event processing distributed across multiple systems (with the latter being a requirement for enterprise applications in any case to cover High Availability and Fault Tolerence)
- knowledge-rich, complex, adaptive application / business logic being applied to events with low latency
- combinations of both of the above!
So how does BE4 move the CEP game forward? Lets look at the main features:
- Product selection: a modular installer, allowing different combinations of event processing elements / languages / features / services
allows for tuned deployments, such as web-service based decisions… - Development and testing: new Eclipse-based IDE (BusinessEvents Studio), with productivity enhancements and things like remote debugging / stepping through distributed agents on the network
allows for easier development of large business models and applications - Complex event definintions: a new Pattern Matcher Framework for creating declarative complex event patterns without intermediate rules, states, timers etc
allows for simple complex event definitions without learning a rule language, query language etc - Integration types: new channels, for HTTP SOAP (and associated WSDL) and also TCP-IP, for new use cases involving web services and internet monitoring
allows for new event processing types, such as internet service gateways, without resorting to TIBCO BusinessWorks interfaces - Decision management: visual test environment in-situ with the decision table editor
allows easier business user development of decisions based on complex events - End-user support: graphical dashboards for end-user KPIs
allows for graphical business user interfaces to allow interaction with the managed events - Operations support: graphical Monitoring and Management utility for operations, and platform support for ZLinux on mainframes (!)
allows operations staff to monitor the event processing agents and performance.
We’ll go over these and the use cases they support over the next weeks.
Hey Paul,
I saw a demo of BE 4.0 in Vegas during TUCON, and it looked pretty cool. With regards to customers welcoming the big version change, how is TIBCO coming along with the marketing? My company just started on a new TIBCO BusinessEvents project in Asia, and the client wanted 3.0, not 4.0. Also, the people in our US client are still not knowledgeable about 4.0 enough to advocate switching away from 3.0. I’m very interested to see how TIBCO marketing will overcome the fears.
Thanks, Paul. I love this blog.
Jazon
Hi Jazon – good to hear from you.
BE4 is released and running, but BE3 is still supported for ongoing projects. It will take a while for everyone to transition to BE4. Reasons for existing customers to do so are:
- IDE with new output diagrams to help understanding control / event flow, and debugger
- new component features (better Decision Manager with rule analyser, Pattern Matching Framework, more choices for backing store / DB concept sources, HTTP and TCP channels, …)
- integration with dashboard capabilities (BE Views)
- Management console
However, some BE4 features like multi-threaded Rete and cache aside are backported to / available on BE3, to allow existing customers to exploit some of these capabilities.
For sure, with Training Courses only now becoming available for BE4, we are in a transition period right now. But you are right that customers need to consider carefully reasons for not using the latest and greatest version.
Cheers
I agree what’s being done is more important than how fast. It would be nice for the industry as a whole to come up with a few representative examples, so that end users can have a starting point. Obviously users can also do the evaluation themselves, but spending months building applications on several products and testing them could be time prohibitive.
Congrats on the new release. Does Tibco plan to publish any benchmarks to give the public a clear definition and demonstration of extreme event processing? In past blog entries, numbers like 5K/second was mentioned. Something more formal with examples would be great. It would also be great to see how long it takes BE4 to process 1 million events.
Hi Peter
Congrats on the new release.
Thanks!
Does Tibco plan to publish any benchmarks to give the public a clear definition and demonstration of extreme event processing? In past blog entries, numbers like 5K/second was mentioned. Something more formal with examples would be great.
The only “plan” we have would be around supporting an event processing standard with a reference example that could also be used for performance testing. Event throughput can be measured in many ways: for example, a 5K/second example might deal with 1-10K XML messages (stress testing XML parsing and XPATH / XSLT processing), with event patterns lasting 10secs-1day (stress testing the overall pattern size performance / space), and so on. For sure its an interesting area. We also have an internal benchmark doc used for customer sizing and planning and done with BE301 and multi-threaded Rete, but it is not for public (/competitor) access at this time.
It would also be great to see how long it takes BE4 to process 1 million events.
Obviously, 1M events can be “processed” in a very short time – but it depends entirely on the “processing” being done! Comparing an event with a single integer parameter with a value in a BE preprocessor would be pretty fast – indeed would need to have a testbed set up capable of producing events fast enough – but would not be very representative of anything…
Probably benchmarking would be a good topic for an EPTS working group. Or for some subsets, maybe the STAC guys.
Cheers