At the end of June, I shared my views on the relationship between SOA and EDA (peers and complements) with the OMG's SOA SIG during the OMG Technical Meeting in Boston. As I mentioned previously, the purpose of my talk was to discuss why EDA is important, and speak to the SOA-EDA relationship from an architectural point of view.
Yes, the SOA 2.0 thing came up, but was quickly discounted (not just by me) as marketing. An interesting aside on the SOA 2.0 thing is the ‘ripple effect’. Now that a giant (Oracle) has stepped into the event processing waters, many of the smaller event processing specialists – StreamBase, Coral8, Rhysome, Apama (Progress) – are (rightfully) finding their way into the press and onto practitioner radars. So, that’s good.
I based my presentation on my event-driven architecture overview paper. Because I prefer pictures over bullet plastered slides, I created three new illustrations that I want to share here. Given I was at the OMG, I was very careful to characterize all of my ‘diagrams’ as pictures, since they include no standard notations (oops).
SOA and EDA’s Complementary Relationship
The first two are simple (conceptual) pictures, showing the interactions between services and events.
The first, is “event-driven SOA”, when the occurrence of an event (a thing that happens inside or outside your business) triggers the invocation of one or many services.
[click on picture to enlarge]
The second, is “service as event source”, when a service generates an event. That event may signify a problem or impending problem, an opportunity, a threshold, or a deviation.
[click on picture to enlarge]
In the third picture, I show the broader event architecture, again at a conceptual level. On the far left, I show 8 different event source examples. In the middle, I show 6 examples of event-driven actions, and a variety of subscribers. So, while services can play the role of event source or target, they are just one of many event sources/targets. Event-driven architecture is much broader than its relationship with SOA, including real-time information flow and analysis and complex event processing. This is why I say ‘complements and peers’.
Broader EDA – EDA as Peer
[click on picture to enlarge]
The Discussion
I must admit, I wasn’t sure how my talk would go. The first presenter, David Frankel from SAP, gave an interesting presentation on Model Driven Business Process Platforms, and the group was receptive, but quiet until David finished. Then, they asked questions.
Me, I prefer discussion along the way. Because the discussion – unless completely off topic or down a rat hole – is the most interesting part. So with some trepidation that the next 45 minutes would be me talking at the group, I started my spiel. A few slides in, as soon as I said “events have specifications (definitions) and occurrences (instances)” the discussion broke out. [it’s always good to follow a coffee break!]
The part of the discussion I want to highlight here focused on the ‘event splat’ on the left side of the conceptual EDA diagram above. For folks that have designed and/or worked with an event-driven architecture/system this will be familiar territory. For those thinking about event-driven architecture, the concepts raised are important to be aware of.
As mentioned, the discussion started with my providing some definition around the term event. I presented the following:
• An event is a [notable] thing that happens inside or outside your business.
• An event (business or system) may signify a problem or impending problem, an opportunity, a threshold, or a deviation.
• Events have specifications (definitions) and individual occurrences (instances).
Conceptually, this was fine. However, the group wanted clarity around “event occurrence”. Aren’t there really two concepts embedded in “event occurrence”? One: The thing that happened. Two: Notification that the thing happened.
As it was asked in the session, “If an event occurs in the forest, how do you know it happened?” Isn’t that through a notification?
Good question. Logically, there are two event concepts (occurrence and notification), plus the originating thing that happened. Consider a simple example, where orders are treated as events:
-
A new order (123) comes in. Physically, order 123 is captured and processed as an order. The order is the originating Thing that Happened.
-
Logically, the order is also an event. More specifically, order 123 is an occurrence of the order event.
-
For the event to be processed (heard), it must be detectable and understandable by the event processor. This is accomplished via a notification that order 123 happened.
-
The event notification carries information about the event occurrence (order 123), in a format described by the order event specification.
These concepts and relationships are depicted in a new (almost standard modeling format) illustration below. You’ll see that I’ve grouped the individual concepts “Thing That Happened” and “Event Notification” as “Event Occurrence”.
[click on picture to enlarge]
In my own event work, we chose to instantiate and process the composite “event occurrence”. In this view, the arrival of the event occurrence served as notification.
That’s just one way. Others have done the opposite – instantiating an event notification that embeds ‘the thing that happened’. And others still, instantiate both.
Implementation styles and reasoning will always vary. What’s most important is grasping the fundamental concepts. As for me, I’ll try to note when I say “event occurrence” I really mean “the thing that happened” + “notification”. So, when the event occurs in the forest, someone hears it.
Event Related Standards
Following my talk, the group discussed requirements for EDA related standards. What became quickly apparent is there are numerous existing standards associated to events and event processing. Most have systems origins. The next step for the SOASIG is to cull through these standards, and see what’s applicable to business events, and event-driven architecture.
Some of the standards mentioned were:
WSDM
WS-Eventing
WS-Notification
EPC Global – Application Level Event Spec
eDoc UML Profile
Corba Event Service and Notification Service
If you can think of others, let me know.
As for scope, the OMG SOASIG is currently focused on the interrelationships (interactions) between SOA, EDA and BPM, not the broad event-driven architecture space.
