Over the last year and a half, I have been following with interest the rise of user and vendor interest in event processing, and in particular in EDAs (event-driven architectures). My own take on EDAs: there's some real value-add there.
Now, from a mainframe DB2 programmer's point of view, business-event handling is older than dirt. The basics of events, triggers, business rules, and stored procedures were there in the 1980s if not before. What's new over the last few years is the idea of service-oriented architecture (SOA) that spans an enterprise network using standardized software interfaces.
The basis of a SOA is often an enterprise service bus (ESB) that acts to route calls from Web service consumer code (e.g., a Web browser), to Web service provider code (e.g., enterprise applications). This means that the ESB can see events flying back and forth from systems management, database transactions, and specific applications for specific types of events (e.g., quantitative apps handling stock arbitraging), filter them, report them, and act on them.
An event processing engine over/in the ESB -- the event-driven architecture -- is a great way to handle existing event processing (such as systems management) across the enterprise. In particular, it allows users to capture those combinations of events that existing applications and databases do not see, because those apps can't listen in on all the messages coming from the outside or going between processes.
 |
|
|
|
|
... an EDA moves event processing out of hard-coded existing stored procedures and applications to the enterprise-network level, where the developer can write enterprise-spanning apps.
|
|
|
|
|
|
|
|
|
|
Moreover, such an EDA moves event processing out of hard-coded existing stored procedures and applications to the enterprise-network level, where the developer can write enterprise-spanning apps. Hence the ideas of "business activity monitoring" (figuring out what's happening in the enterprise by monitoring events on the enterprise network), "the 360-degree view" (adding monitoring the enterprise's environment via RSS feeds, Web searches, etc.), and "the just-in-time enterprise" (semi-automated rapid responses to business events). No wonder vendors ranging from IBM, Sun, and Progress Software and users like Orbitz are talking about EDAs.
Why mainframers should pay attention to EDAs
However, none of this explains why EDAs should be of particular interest to mainframers. After all, a fair amount mainframe transaction processing is batch, which is definitely not real-time, and the idea of fast reaction to an event that has just happened does not apply to batch transactions. Moreover, in the past the very security schemes that have been so effective at protecting the mainframe from attack have tended to keep it unusually separate from distributed and Internet processing. In other words, the mainframe has been kept from accessing much of the extra-enterprise outside-of-corporate and out-of-enterprise "cloud" data that can be quite useful in giving the enterprise greater agility and speed-to-react.
Two things have changed over the past few years to make event processing more relevant to the mainframe. First, the increasing occurrence of consolidated Linux workloads on the mainframe has tended to drag with it a new involvement with distributed and Web-savvy architectures. Second, a new user push to bring "near-real-time" business-intelligence insights out of the data warehouse is involving those mainframes that have been large-enterprise repositories of decision-support data.
Moreover, the mainframe is becoming better able to support SOAs (and therefore EDAs) than ever before. For example, entire chunks of WebSphere are being moved over to the z10. As I noted in an earlier piece on the mainframe as a hub, it can now act as an equal partner in an Intranet or Unix/Linux-based network, and as a specialist in particular types of tasks.
Moving beyond SOA to EDA
|
|
|
|
|
EDA on the mainframe can capture events across event types and organizational boundaries.
|
|
|
|
|
|
|
|
|
|
The increasing Linux-style virtualization of mainframes makes it an excellent place to capture a wide range of events. EDA on the mainframe can capture events across event types and organizational boundaries. The mainframe's advantage of physical co-location of most of the event-generating processes, along with the attendant benefits of lower TCO (total cost of ownership), easier administration, better scalability, and so on makes it an attractive and sensible option.
This is not to say that achieving an EDA on today's z10 is entirely easy. For example, IBM's Business Events product runs on AIX and Linux, not z/OS, so the likely IBM-recommended programmer interface for such an EDA is not yet available on z/OS; not to mention hooks for handling events involving IMS, VSAM, and CICS. However, on the Linux side, most if not all of the necessary software and services appear to be available from IBM or third parties.
Event processing software is the next big thing for the mainframe
EDA may seem like another fad that will not impinge on keep-the-business-running mainframes. But event processing software is code that views all messages as events and therefore can enhance every piece of software in IT, not to mention the running of the business. And if IBM is correct -- and I believe they are -- event processing and EDAs are the "next big thing" for users. In other words, like the SOA, sooner or later (probably sooner), it will affect mainframe IT.
It is better for mainframe users to act proactively and implement a "hub" or other enabler of EDAs and be viewed as a positive step by the business, than for them to cast the mainframe as a passive source of events that lacks the ability to deliver real-time decision support that CEOs and CFOs crave. The action item for mainframers, therefore, is to pull the trigger on starting EDA implementation: to identify the business opportunities for an EDA and the software needed for implementation, and then coordinate with IBM and third-party vendors in proactive implementation of a "360-degree view."
