Saturday, June 13, 2009

On CICS event processing


Recently, IBM has announced "CICS Event Processing". A full presentation explaining what it is about, is available on the Web. As I have written many times in the past, the processing part of events is just a part of a bigger picture, that includes: producing the events before the processing, route the events to the right processing elements, and consuming the events by consumers. In some cases, devising the event processing application is the easier part of the work, and the more difficult part is to connect it to the rest of the world. Since a substantial amount of the world transactions are going through CICS, which is a rather old, but still alive and kicking transaction processor, then it makes good sense to take it as a place for instrumentation, and emit events that can be sent either to further processing or directly to a consumer or a dashboard. The event processing part of CICS perform simple and mediated event processing, e.g. filtering, transformation, enrichment and routing. For pattern matching it sends the event to an event processing engine. I think that we'll see more of the producer side event processing support, that will reduce the need to write ad-hoc adapters and make it more cost-effective to use. We'll also see the complementary part - the consumer side, on which I'll write in a later date.

Thursday, June 11, 2009

On some authors' dilemmas


This is an illustration of the "prisoner's dilemma", a known concept from game theory. These days I am facing some smaller scale dilemmas that do not include decisions about imprisonment, but relate to the book that I am writing together with Peter Niblett - Event Processing in Action



After completing the first 1/3 of the book, the draft have been sent to many "anonymous reviewers". Yesterday I got the result of 11 reviewers, they generally liked the draft, some of them made comments that demonstrate some of the dilemmas of writing such a book. The dilemma stems from the fact that the target audience is not monolithic, and this is evident by variety of opinions. Which reminds me that many years ago I have taught a basic first-year ("freshmen") university course, and in this course there has been a lab in which the teaching assistant taught them some products (I think it was MS-Access), one of the teaching assistants told me that one student asked him what version of the software should be used, and another student asked him how to insert the floppy disk (remember?) to the disk drive. It was difficult to teach such heterogeneous audience. In the book target audience there is less polarization, but still there is a variety: people who are part of the "event processing community", people who are somewhat familiar with event processing (or think they are familiar), and people who don't know if event is written with "v" or with "w"... The target audience is further segmented to: developers that are interested only in the technical side, system architects / designers who are interested to understand principles, students or newcomers to the area, who are interested to study the area. One of the facets of this diversity is that one reviewer wrote that we should write more about the business motivation since the most important thing is to explain decision makers what is the value of event processing to the enterprise, while another reviewer thought that the introduction is boring and that we should move directly to chapter 3 that starts with the technical stuff. The way we chose is to have an introduction chapter provides an overview, gives ten different examples that represent different types of event processing application, explanation of the various reasons for doing event processing and some key terms. We decided that one introduction chapter is enough for those who want to get some notion of what is the motivation, and may still be of interest to those who already know or are not really interested in motivations, just in technical details. There is another book being written which is dedicated to the business side (by Mani Chandy and Roy Schulte) for those who would like to get a complete business oriented book - our book is more for the technical audience. For those who are not interested -- we'll recommend in the preface to skip this chapter. I'll write more about some other authors' dilemma in subsequent postings.