One of the interesting questions about the acquisition of Apama by Software AG is what is the strategy of Software AG going forward in the event processing area, given that it has already acquired in the past an event processing technology from RTM which is named "WebMethods Business Events".
An article in COMPUTERWORLD attempts to shed light on this issue, citing Stephen Ried from Forrester: "Apama and WebMethods Business Events complement each other; While the former RTM is really lightweight and can be embedded in many Software AG products to provide basic event communication capabilities, the Apama product is for those customers who like a dedicated business event management platform.".
According to this - there are two major use patterns. Event processing as components embedded inside other products, I have written before about the component approach to event processing, and indeed not every product needs all the event processing capabilities. On the other hand, a full fledged event processing application require an event processing platform, optimized for performance metrics.
I haven't blogged for a while, hectic week is ending (our working week is Sunday - Thursday, so this is the evening of the last working day!). Meanwhile I have noticed that Streambase has declared "component exchange program", looking closer, this includes a collection of stuff, starting from Twitter adapter, and even including the Streambase implementation to our "Fast Flower Delivery" example. Very good idea. Now, the challenge is to have a global components exchange that is not specific to a single vendor. In my previous posting I have written about event processing building blocks, and having a building block exchange is the ultimate way to implement this idea, everybody will be able to mix and match building blocks. The inhibitor is the lack of standard. Let's say that I want to use two of the exchange components, and that one should send events to the other, then of course they need to agree on how event is being represented, writing adapters for each pair of components is not very appealing. Furthermore, if one develops an application out of various programmable components, one would want them to be speak the same language. So -- having an exchange around a single product is nice, having an exchange in the industry level will be even nicer. More -later.
