Using CEP is not beginning but finishing of EDA

Giles Nelson joined the debate about CEP versus EDA. I am very happy with that because he is deeply involved in the evolvement of Apama, which is a state-of-the-art complex event processor marketed by Progress Software.

Giles expressed his view in 7 clear statements. I agree with him to a certain extend, however I have one major remark with regard to his point 7 where he states:

If you are using CEP then you have at least the beginnings of an EDA because you will have been focussing on event-types.

This is a dangerous statement that could create confusion. The events in CEP are merely technical events, messages entering the system, which not necessarily represent business events or any other real-life events as meant in an EDA approach. In CEP data from incoming message streams are correlated within time-frame constraints. This data may represent "anything", e.g. arbitrary spawned clouds of arbitrary mathematical figures which are written to arbitrary ordered messages, without any functional or time-based relationship. The time-frames CEP uses to constrain the correlations between the messages could be the time-frames in which the messages are received by the CEP-engine and not content based on when the event - represented by the data in the message - actually occurred (in this example when the figures were spawned or generated).

One should be aware of the misconception that publishing the message is the event of interest. It's right that from a system point of view publishing a message is an event that triggers an endpoint's software-component. However, from an EDA point of view the message represents a different event. The message does not represent the event of its own publishing, but it represents a real-life business event. That is a different type of event that occurred at an earlier moment in time; ideal slightly earlier (near real-time) but possibly a longer time ago.

So I would rather claim using CEP-technology as being the finishing implementation of EDA. But indeed, using CEP could make you aware of the beginnings of EDA.

EDA versus CEP, once again...

Just as SOA adds the "business" aspect to methods to be invoked, in my opinion EDA should add the "business" aspect to events to be processed in order to structurally mature the IT-landscape that supports the business. A bunch of services doesn't make an SOA, neither does a bunch of events make an EDA.

And from an architectural point of view, EDA is even a lot more than event processing from a "business" event perspective as stated above.

E.g. think of the architectural challenges of semantics mediation, extremely loosely coupled process flows and transaction control. And think of security in a extremely loosely coupled environment: authentication, authorization, encryption, credential assertion, non-repudiation. All of these aspects are not explicitly addressed in CEP (Complex Event Processing), but are in EDA.

CEP is just one among these aspects. The overall architecture from a business events perspective is called EDA: Event-driven Architecture. And, on the other hand, EDA does not only deal with complex events (correlations) but also with simple events.

So CEP is not EDA, EDA is more than CEP. Promoting CEP as being EDA is far too simple. And yet that is what is happening in the current IT space.

Especially the vendors of event processors focus too much on CEP as being EDA. That is completely wrong and won't help us one step further beyond SOA as we know it today.

Vendors, please change your attitude and help the business to seriously mature their IT-landscapes in stead of proclaiming techniques and products as architectural styles!

Market does not understand EDA

I attended the 1st International SOA Symposium in the Amsterdam ArenA at 6 and 7 october. The reason why I attended this symposium was because EDA came to the scene. But I really was disappointed.

Clemens Utschig-Utschig and Manas Deb (Oracle) together spent a complete presentation titled - "SOA and EDA" - to the subject. I did not one moment notice the architecture aspect during their talk. Clemens and all the others I listened to mention EDA and start talking about complex event processing; that is not architecture, that is technique. The clue with EDA is to drive your architectural approach from a business events perspective, just like SOA is driven from a business services perspective.

CEP is a way of processing messages (fair enough to name these messages "events"). That was clearly understood and explained by all of the "EDA-speakers". But EDA is about how business events drive the overall architecture of the IT-systems and it is about how these events should be modeled. EDA it is not primarily about the ability to process and correlate streams of thousands of messages per second as the speakers were trying us to believe. The real EDA paradigm was one step to far for all of the respective speakers, unfortunately.

Another misconception was that the speakers I heard were trying to convince the audience to only pass the references to data in the message, WRONG! One of the architectural principals behind EDA is self-contained documents that describe events. Passing references (primary keys) is a performance trade-off, not an architectural principal. Passing references creates dependencies to sources the might be out of your scope or control; it assumes knowledge of reference data. Passing references is a pattern toward tight coupling in stead of toward loose coupling.

My conclusion is that EDA is not yet well understood in the market. Perhaps next year?

SOA Approach to Integration

After I read Service Oriented Architecture with Java I decided to read another SOA-book of Packt Publishing. The book is titled:

SOA Approach to Integration

As an Enterprise Integration Architect I was very pleased to read this book and I would recommend every integration architect to read it. Why? Not only because it will teach you the ideas behind SOA from an integration perspective, but also because it teaches you the developers language.

The book is also of great value if you are a developer, because it teaches you the various technologies to implement SOA.

The book starts with positioning SOA as an integration style, which I do think is a valid perspective. The term Process-Oriented Architecture is introduced. Yet another acronym, POA, which sounds to me like BPM. BPM, however, is not mentioned in the index of the book. But let's stay away from this semantic discussion.

The authors explain best practices for using XML for integration. They explain the web services approach, including design guidelines. The WS-I Basic Profile comes to the scene and - in the context of Process Oriented Integration - BPEL is comprehensively explained, including some code snippets.

To me the most interesting part of the book was the last chapter. These 90 pages (a quarter of the book) deal with the SOA platform, being the Enterprise Service Bus (ESB). The ESB architecture is described as well as the concepts of Service Containers as the primary tier of the bus. Bus Services are mentioned (Mediation, Transformation and Process Flows); Security and Transactions; Reliability, Scalability and Management; Application Development Considerations; and finally Extending the ESB to Partners. These are the things developers are concerned with. It is a very good idea for an architect to have a notice of what puts the burden on the developers, and to be able to understand their language.

My conclusion is that this book supplies its readers with feet-on-earth knowledge of SOA between concepts and technical implementation. Very worthwhile reading.

[Click the picture for details]

EDA versus CEP (and SOA)

CEP (Complex Event Processing) correlates multiple messages within given time frames. EDA is an architectural approach to model information systems from a business event perspective. EDA differs from SOA by its focus. SOA puts services at the center of the model and EDA does so with business events. The SOA-approach tends to result in a synchronous communication style and the EDA-approach in an asynchronous communication style.

CEP is not about business events by definition. CEP is a technique to process message streams. These messages do not need to represent business events. A business event is something that happens (change of state) where your business has planned to react upon in a predefined way. A business event is represented by a message, but not all messages are representations of business events. CEP is about messages, EDA is about business events.

CEP can be used to implement EDA. You might say: EDA is CEP at the business level. The business can be seen as a complex event processor which holds states, reacts on state changes and correlates business events. Every living organism behaves like a complex even processor, also humans. The only thing we do all day is react on (correlated) events. That's why the paradigm is so powerful, because it is a natural instinct. Current technologies like ESB, XML, SOAP, JMS and globally adopted communication standards including WS-*, enable and boost real-time event processing at the business level. The collection of these real-time business events is the representation of the business dynamics at this very moment. And these dynamics can easily be made visible (BAM), if... you model your systems around business events, EDA.

I think EDA will definitely and radically change the way we currently look at business applications, including SOA.