An ESB, in short, enables you to create and deploy integration applications typically involving many disparate systems. For example, you can write an application that receives a SOAP message over HTTP, retrieves additional data from a database, does some manipulation of the data and sends a new set of data to a SAP system. Here, the application has two distinct roles, one is to communicate with the external systems (HTTP, database, SAP, etc.) and the other is to do some processing logic such as data manipulation.
An enterprise can have many different applications deployed onto the ESB. These applications are all related to the enterprise's business in one way or the other. They usually are not directly connected with one another and are written only to serve a specific function. There can be a situation where each of these applications seems to be functioning normally, but at the business level something unusual is occurring. Let me illustrate. Suppose one of these applications is a "Password Management" application and another is "Transfer Funds". Each of these applications will have some typical volume in a given time interval. There could be times when they encounter a spike which, let us assume, is normal. Now, lets say, one day, all of a sudden both these activities show spikes. The fact that the spikes happened at or around the same time could mean that some fraudulent activity may be happening. How do you detect that? You can change the two applications to emit events when spikes occur. Then you can collect these events and process them to find out if together they represent an interesting business event. This job is typically that of an event processor.
So, an event processor is capable of receiving a set of events from multiple sources. The set of events is called a cloud of events. The event processor has capability to process these events to detect interesting higher level events. These "interesting higher level" events are called complex events and this paradigm is called Complex Event Processing (CEP). Note that an ESB is capable of connecting to a variety of external systems, so the events can come from within the ESB as well as from the external systems.
When enterprises architect their applications to take advantage of events from individual applications to detect other higher level events, the architecture is called an Event-Driven Architecture.
Traditionally, event processors have also been used to do processing on a continuous stream of events. This paradigm is called Event Stream Processing (ESP). To process the stream on a continuous basis usually a specialized language is required to specify the instructions. One such language is Continuous Query Language (CQL) invented by the STREAM group at Standford. If the event processor is part of an ESB, then obviously it can receive the stream of events from a variety of external systems. Similarly, it can also send a stream of events to a variety of external systems.
That, in brief, is how Complex Event Processing, Event Stream Processing and Event-Driven Architectures are related to an ESB.
IEP is a open source Complex Event Processing engine and is part of Open ESB. Using these two technologies you can easily achieve all your event processing needs.
If you want to find out more about Complex Event Processing, here are two excellent resources - http://complexevents.com/ and http://pavg.stanford.edu/cep/
. The lab is made available online 