One of my IBM colleagues, Jim Spohrer, the IBM University Relations Director, has written about the need of students to receive transdisciplinary education. Indeed we find more and more that doing things require not just multidisciplinary skills, of people from several disciplines working together, but also transdisciplinary skills, where people have good skills in several disciplines and a single person knows how to integrate these disciplines. This is, of course, contrary to the academic tradition, where promotion processes for faculty members advocate the association with a single well-defined discipline. We can see much more transdisciplinary programs today then 20 years ago. I believe that a program in which a student learns combination of computer science with another discipline (biology, business, mechanical engineering, cognitive psychology and more...), not only at the intersection between the disciplines, but rather at the union, of having deep understanding in both disciplines as the type of skills required in the marketplace.
While surfing the web to find something, through the wonders of Google search, I reached the site of the Langley flying school and came across the illustration above under the title "the pilot decision making process".
The cycle starts with a situation, which is defined as a critical situation which requires action. The detection and identification of such a situation is what starts the process, thus the decision process is inherently event driven, then the pilot needs to assess the options, sometimes the options are very obvious, and sometimes there is a creativity in that process, then there is a need to chose among the options, act according to the selected action and assess whether the situation has been resolved. Note that this may be either reactive (situation already happened) or proactive (situation is expected to happen). Of course, when possible it is better to be proactive, it is much better to eliminate crash of the aircraft then try to rescue the crew and passengers when the crash already happened, both from economic point of view and from safety to human life point of view. Note that the pilot needs to react to critical situations, for the process-driven business as usual case, an autonomic pilot is sufficient. Can we extend the autonomic pilot also to deal with critical situations?
A recent article in the IBM developerWorks discusses two ways to enrich data used for rules from external databases, one of them is doing the enrichment in the request level, before calling the "decision server" (which is the current name for using BRMS system using the request-response protocol), the other one is doing enrichment during the rule processing itself. The article describes how each of these options is done and also discusses pros and cons, the benefits of enrichment by the request level are - less complexity, and better performance of the rule component; the benefits off enrichment at the rule level are - handling dynamic data and more specialization for the exact data that is being used by the rule.
Thinking about event processing -- there is similarity to the BRMS case, event can be enriched both by the event producer and as part of the event processing itself, the arguments are not far from those in the BRMS case, there is one fundamental difference in event processing -- the work is not done using the "request-response" protocol, moreover, the different part of the system are decoupled, thus the event producer does not necessarily know what purposes the event is going to be used, thus there may be different types of enrichment needed for different uses. The dynamic aspect is applicable here, and there may be some race conditions in highly dynamic systems between updates in the database that was enriched and its use in enrichment, unless the event processing enrichment system locks the data in the database until it is being used in the event processing system, which requires the event processing system to exhibit a transactional behavior for part of it, but I'll not get now into this issue,
Bottom line: The considerations in event driven architecture are somewhat different than the request-response systems that are the most common one in computing.
