On Named Architectures

Ok, let me begin by saying that as a software architect, I don't pay much heed to buzz on things like Service-oriented Architecture (SOA) and the precise definitions of which pieces you need before you get to apply the peel-off sticker to your system. But, I happened to be reading The Register this morining and I came across this snippet from a report on the Gartner Hype Cycle:

Event-driven Architecture (EDA) is an architectural style for distributed applications, in which certain discrete functions are packaged into modular, encapsulated, shareable components, some of which are triggered by the arrival of one or more event objects.

That caught my eye, partly because I've never heard of the term "Event-driven Architecture" in capitalized form and partly because it was buried in a report talking about things as nebulous as Web 2.0 and Collective Intelligence. But mostly, my reaction was one of "hey, that's what I've been doing for ages", followed by the quick realization of "how could you not build a significantly large system that wasn't 'event driven'?"

So what is it?

Now, I needed to know exactly what was meant by this phrase, because surely an EDA can't just be "a system with events". So off to Google it is. Some quotes of what I found. These are just "top ten" search results.

Event-driven architecture is more a set of guidelines than a product. The active ingredient: a small piece of software called an agent that can sit on a particular machine and watch for something to happen.
...
Can't any application do that?
Probably, but most application techniques rely on a request-reply process in which they send a message to other applications asking for some action or data, then have to wait for the reply before doing anything. Rather than wait for one activity, agents can launch several responses, each of which can be completed independently, often with no further action from the agent. Agents can also be told to watch for a range of events that may or may not happen, and may happen in an order that's hard to predict. "You could do this before, but it took a heroic effort," says Ray Schulte, vice president and research team leader for application integration at Gartner Inc. "So that was limited to a few high-payback applications like trading."

Emphasis mine; www.baselinemag.com

Effective organizations use (usually implicit) contracts that specify what should be communicated and when. The VP is responsible for telling the CEO that a plant has burned; the CEO is not responsible for extracting that information from the VP. Pharmaceutical companies are responsible for telling the FDA when drug trials result in deaths; the FDA is not required to poll the pharmaceuticals to obtain this information. The shared model—the shared expectation—about what is to be communicated is an implicit subscription.
...
In SOAs, the person who needs information is responsible for asking the person who has the information: The client invokes a service on a server, and the server has no responsibility other than to respond to service invocations. In EDA, the client who needs information is responsible for updating subscriptions (models, forecasts, and plans) at the server with the information, and the server is responsible for continuously propagating relevant information. Three aspects of EDA contracts make EDA more powerful than SOA:
...
Some might argue that EDA and the Event Web are nothing but well-known push technology. These skeptics miss the key point: Traditional push technologies and pub-sub systems exploit only a tiny fraction of the power of EDA for four reasons:
...

Emphasis mine; www.developer.com

After reading some these and other "articles" on EDA, I realized that this is a typical bad reasoning pattern at work. Virtually all of the documents I found take great pains to point out how SOA is just a simple "publish-subscribe" model and it's not as powerful as EDA because of x, y and z, so you should be using EDA. This reasoning is flawed because it presumes that your only choices are these rigid categories of SOA and EDA. Why are seemingly reasonable people thinking like this, I wondered. There are few points in these articles that need to be addressed.

There's more to life than HTTP

Then, it hit me. These SOA and EDA technologies are all in the all-too-prevelant webbish category, where the biggest (only?) tool in the toolbox is an HTTP request. So, when people are talking about SOA requests, they're really talking about HTTP requests. And they came to the same realization as everyone else I've ever met who used HTTP as their default protocol within their architecture: HTTP doesn't cut it because it is fundamentally request/reply with strict limitations on who is the server and who is the client on a given actual connection. If you want events to flow both ways, you have to do silly things like make requests that just wait until the next event or make HTTP connections in both directions. (I'll bet that the next thing we see [if it doesn't exist already] is that EDA will start adopting SIP as its protocol of choice, since, in some ways, SIP is just "two-way" HTTP.)

The way I would look at such a problem is to say "why did we pick HTTP if it doesn't meet the needs of our application"? And, usually, especially for interfaces where I influence all participants, I don't. And is it "a heroic effort", as claimed in one of the articles I read? No, I just use a communication mechanism appropriate to the application domain.

It's the application, not the architecture

The other major point of confusion for me revolves around the use cases exemplified by the VP needing to tell CEO of the burning factory or the need to tell stock traders when a stock price has changed. Clearly these are requirements of the application domain, whatever that might be. And since we chose our implementation approach based on our application domain requirements, why are we even looking at a rigid architectural structure like SOA or whatever if it doesn't meet our requirements? That's just foolish.

Even so, the requirements in question here are not architectural requirements; they're application requirements. You want to know when things are on fire without asking. You want to use rules based analysis to trigger stock alerts for ten million clients. Sure. Take those requirements, and put together the interfaces and systems you need to achieve that.

But sometimes we don't know all of the requirements up front. Maybe we already have our SOA-ish system and we want to add something to it that the architectural model doesn't support. Now what do we do? Well, the first step is to fire your architect for chosing such a ridiculously rigid approach that makes basic such first-year assumptions as "everything is request-reply" :). But don't hire the next guy that tells you that "everything is shared-model EDA" or whatever, either. As someone who has built and continues to build large, constantly evolving systems with hundreds of parts, I look at these models as complete academic or marketing bollocks.

Build (or buy, if you must) yourself a set of tools so you can create interfaces of all sorts. Then, when it comes to each interface, you can judge whether (today) it has any or all of request-reply, subscribe-publish, unsolicited-events, store-and-forward queuing, bulk data transfer, and so on. Decide on areas of responsibility, make well-defined interfaces between them using the most appropriate protocols and transport and build your system. Don't just always use HTTP because it's all you know; learn some more communications techniques. Would you hire a carpenter who only knew how to use one tool? Fill your toolbox and reap the rewards in terms of producitivy, quality and performance.