Most event processing systems would be incomplete without the ability to process events in the form of messages.   Messages can be delivered in either a connection-oriented protocol or a connectionless protocol.   Most enterprise-class messaging systems have both.   Many messaging systems have features like guarenteed delivery, which are important to many applications.

On the other hand, you do not have to work with a messaging system or enterprise service bus (ESB) to process events, because the transport layer is independent from the event processing layer, theoretically.  Most enterprise-class event processing system architectures will use a combination of both asynchronous and synchronous messaging. 

To understand event processing I recommend you turn to network management and the practical use of Simple Network Management Protocol (SMNP) for a basic undertanding of event processing.   SNMP uses both synchronous event-based messaging, called polling, and asynchronous messaging, called traps.   Network management systems engineers use a combination of both polling and trapping in all enterprise-class operational NMS.  Optimizing polling and trapping is one of the tasks good NMS engineers do well. The same holds true in most distributed event processing architectures.  

For example, look at the CEP/EP reference architecture on this site.  You will notice that the mechanism for event transport is generic, represented as an event bus, but it does not specify the transport protocol.  If you are receiving raw events and comparing correlated results against a signature in a database, you are using both asynchronous and synchronous messaging.    In theory, you could build an event processing system with only connection-oriented protocols, but this would be an exeception, not the rule.

Event processing is generally associated with messaging because we generally represent event-objects as electronic messages.   In theory, we could call these cyber event-objects anything we want; for example, we could call them “packets.” However, packets are generally associated with the underlying Internet Protocol (IP) layer by network engineers.  

Moving up the stack, we think in terms of a complete message-object, which we generally call “a message.”  This message could be an SNMP event-object, an SMTP event-object (an email message), or an HTML request to a web server, to only name a few.    In fact, the basic unit of work at the application level of a distributed network application is what we call “a message.”  

So, in On Messaging and Events Opher asks, “Is event processing just fancy name to message processing ?”

Events are generally represented in some electronic format.  The event-object must be transported electronically in cyberspace, and the way that it is transported is in what network engineers generally call “a message.”   It make no difference what we call it, really; because whatever we call it, it is still binary data representing information we are interested in, hopefully in a format we can efficiently process.    Enterprise-class event processing systems are designed to work with myriad formats, protocols and transports.   One size does not fit all.