And with that, TIBCO’s newest offering, Silver is off and running. 

Announced yesterday at the NOWonline show, it seems to be getting a good bit of attention in the press, analyst and blogosphere communities.  eBizQ picked up on the announcement and commented on its use of CEP in the automation of cloud-app-balancing. As for me, my head is a bit cloudy at the moment, from all the fuss.

So what is Silver, and what does it have to do with CEP? 

Everything. 

TIBCO Silver is new software infrastructure for “cloud” computing.  A “Silver” lining for the clouds you might say. 

And why is this important for CEP? 

Because it’s an infrastructure product that embeds a CEP engine in order to solve problems related to governance (managed access, security, privacy and adherence to regulations), and scalability (uses SLAs to automatically scale up / or down as needed).  The kicker is that it’s automatic, so both the governance and the scaling is accomplished inherently through embedded monitoring, management and event-decision-action rules rather than manual intervention and programming -which AFAIK, is an achilles heel for current cloud products being introduced. 

This should be an interesting announcement for developers of different types of Business2Consumer or Consumer2Consumer apps that are likely to vary widely in resource requirements. The embedded governance allows for various levels of authorization, authentication and encryption policies to be dynamically configured. This is important because some services should be open to everyone and some services, well, just shouldn’t.

As in most cloud architectures, and not counting those who simply put the cloud moniker in front of their latest software product, there is no software to install or hardware to procure or provision, which reduces the barrier to develop and deploy rapid IT solutions (whether that’s infrastructure, platform or applications)

TIBCO Silver is currently in Beta. It will be interesting to see the deployments when they start rolling out.

Ashwin used this great slide at our TIBCO BusinessEvents QLGroup best-practices session this week, courtesy of James Gosling’s blog and credited to Peter Deutsch.

Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences.
1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn’t change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous

Arnon Rotem-Gal-Oz did a follow-up white paper that goes into more details.

Apart from classic Complex Event Processing (event abstraction across time, source, type and attribute) applications for situation-awareness type problems, TIBCO BusinessEvents is also finding uses in sophisticated / dynamic event-driven processes that cannot be fitted easily / entirely within representations such as BPMN, BPEL, etc. Of course, there are many other ways of deploying complex processes across services: consider the wsper project, for example, that aims to exploit and combine WSDL, SCA and BPEL [*1]. Their provided example, interestingly, also maps very nicely onto an EDA using a combination of state model + rules, which have the added advantage of declarative rules that can handle any out-of-process (i.e. complex exception) event [*2] - something BPEL can’t handle [*3].

Notes:

[1] I don’t agree with the wsper metamodel (documented here), which defines an “event” as a subclass of operation, and “state” as an attribute only of event. This seems far too restrictive, although it might fit wsper’s SOA perspective.

[2] Consider the (unfortunate) case whereby, in the supplied HR example, your job candidate “expires” (RIP) in the middle of this process.  You would not want your business process to attempt communication with the dead - you need some flexible, declarative, cross-process exception mechanism. This is typically handled by a “rule”…

[3] On the topic of BPEL we also note one effort looking at retrofitting “event processing” constructs into BPEL. Why not event-driven COBOL, too, one wonders? A more interesting project would surely be standardize the event modeling level (e.g. extend BPMN for CEP, or map CEP to BPDM), rather than trying to force event processing into BPEL (insert here visions of pigs in party frocks). No doubt this topic will come up for some (lively) discussion at the EPTS meeting on CEP standards next month…

I was surprised to see that, in the SOA world, there is some debate as to the usefulness of the Enterprise Service Bus. One reason for this might be the evolution of the term “ESB”, from enhanced middleware to service container framework (a.k.a. Enterprise SOA Bus?). Or possibly the anti-ESB lobby take a narrow definition of SOA (e.g. hierarchy of orchestrated synchronous services), rather than those who include Complex Event Processing within the definition of SOA (e.g. any combination of event-driven, synchronous or asynchronous, independently managed or developed contract-defined services).  In the latter case, which includes Event Driven Architectures, ESBs / message buses are a very common / de facto [*1] means of communicating events to, and between, Event Processing systems - indeed “ESB” could be an abbreviation of “Event Service Bus” for the CEP community.

One of the complaints about ESBs seem to be their proliferation and the need to manage appropriate gateways. I would have thought that System Architects would be happy to partition their message buses and domains, just as network specialists manage physical networks with bridges and routers based on configuration needs. Probably the main problem with ESBs is that they don’t fit into some architect’s pure WS-oriented view of the world - but I would suggest this is the architect’s “problem”, not the ESB’s.

Notes:

[1] In TIBCO BusinessEvents, for example, we include default channel adapters for TIBCO RV and TIBCO EMS (which is JMS).

Another talk at DEBS that threatened to be on-the-ball was Douglas Schmidt’s keynote [*1] on model-driven event processing. Although it was not mentioned, most commercial CEP software systems [*2] can be considered model-driven (e.g. draw a diagram, and the system generates the appropriate code or engine controls).

Every EP researcher has an “angle”, and Vanderbilt’s appears to be “Distributed and Realtime Embedded (DRE) systems”, defined as  resource-constrained, typically microcontroller-based, systems. The presenter introduced “Model Driven Engineering” as a common solution, traditionally using state models, process/data flows, and petri nets, all of which (20-40 years ago) had a large semantic gap
to the Fortran / Assembler etc. code of yesteryear. Recent developments in compilers etc have given us fast Java and associated frameworks; the problem (for this domain) is that too much still needs to be coded “outside of the model”, and exploiting the libraries and frameworks is too much like a lesson in complexity management. So the “semantic gap” remains.

Well, somewhat. In the CEP space for business systems, that gap is targeted by the commercial CEP-tool community (and filled, with varying degrees of success).

The presenter mentioned 2 possible solutions: one is the OMG MDA-based approach, which unfortunately he termed “UML Profiles” (aka subsets of UML for a specific domain or use). These combinations of activity diagrams, state models, and “action semantics” [*3] are considered by Vanderbilt as “domain independent languages”. Well they can be, but they can also be domain-specific (and to prove the point, an email just arrived in my inbox announcing the development of an UML profile for XBRL financial reporting - about as “domain specific” as you get).

Instead, the team at Vanderbilt proposes domain specific languages which they call “metamodels”. Which is confusing,  as in reality metamodels can be domain independenent *or* specific. The OMG Model Integrated Computing group was mentioned as a guiding light for semi-automated translations of models to code [*4]. Also mentioned were examples of technologies that supported DSLs, such as Eclipse GMF.

The next notion was that of being “distributed” - in DRE parlance this translates to “Ultra Large Scaleability” systems, which in turn sounds very related to the commercial notion of XTP… and hence the work on the following technology pieces to assist with managing complex distributed systems [*5] and which may also be relevant to CEP:

• Runtime performance evaluation from models, sort of in-situ performance verification, through things called System Execution Modeling (SEM) tools [*6]
  • These express design rules (as constraints) that can be tested in the model
• Configuration of large numbers of components (100s of 1000s etc) managed via XML configuration files
  • Hence the Platform Independent Component Modeling Language or PICML that uses OCL constraints to provide visualization of system dependancies [*6 again]
• Middleware configuration models using constraints for QOS (Quality of Service), transmit times, etc etc
  • Hence a QoS Modeling Lang called DQML

The title of this keynote was “Meeting the Challenges of Mission-Critical Distributed Event-Based Systems with Q0S-enabled Middleware and Model Driven Engineering”, but was really an introduction to Vanderbilt (et al)’s work on these (somewhat specialist) DRE systems. No harm in that, as it was interesting to learn what they are up to, even it turns out to be orthogonal to CEP per se.

Notes

[1] From Vanderbilt University in good ‘ole Nashville, who also happen to be hosts for DEBS 2009. Some of the Europeans were a little bemused by the announcement for DEBS 2009’s location, due to comments like “… and we have such-and-such, which is really great to visit, only 350 miles away…”. So better bring your pushbike, then.

[2] Unless you are having to hand-code a streaming query, of course!

[3] One example of commercial MDE is TIBCO BusinessEvents, using UML-based models for concepts (UML Class models), and state (UML State models). In lieu of action semantics (which I guess are directly equivalent to what we call Rule Functions) we  prefer to use declarative production rules (and queries). Which are transformed into compiled constructs for efficient event-driven runtimes…

[4] Compare and contrast with the Knowledge-Based Engineering group in the manufacturing part of OMG.

[5] Sounds awfully like those pesky agents again…

[6] Not a common enough term to have a Wikipedia description, though…