From Presentation Zen:

It is just plain stupid to use projected slides (i.e., visuals) used in a live presentation as a document to be read later by people who did not see the talk.
[PowerPoint printouts used for communicating battle plans?]

Amen.

Nick Malik is an architect in MSIT’s Enterprise Architecture group. He’s been blogging a while, though I only discovered his blog a couple of weeks ago. Yesterday he posted about OMG’s SOA SIG’s Draft RFI on EDA and it’s relationship to SOA and BPM. That’s a veritable alphabet soup of acronyms! To translate, the Object Management Group’sSpecial Interest Group on Service Oriented Architecture has posted a draft Request for Information on Event Driven Architecture and it’s relationship to Service Oriented Architecture and Business Process Management. Here’s the summary from the actual document:

The EDA Sub-group of the OMG SOA SIG seeks information from members of the EDA, BPM and SOA community as well as anyone interested in promoting standards in this area. Requested information will be evaluated by the EDA Sub-group, resulting in the development of Requests for Proposal(s) (RFP) for standardization of Event definition, relationship between EDA, BPM and SOA that will ultimately allow development of standards for Complete Life Cycle of Events -Ontology of Events, Sense and Respond Services, Events Metrics and processing of complex events. Please note that it is our intent to develop modeling standards for the EDA/SOA and EDA-Business Process interaction and provide standards for the implementation of that interaction as well.

First off, I’m a bit wary about this part: “it is our intent to develop modeling standards”. Of course, OMG is responsible for UML and long time readers should be well aware of my opinion of UML. I don’t want to set the bozo bit on an entire organization, but I am skeptical that any new modeling “standards” from OMG will be any more effective than the Unwanted Modeling Language.

Secondly, EDA seems to be vaguely defined, if at all. Wikipedia has this to say about EDA:

An event-driven architecture (EDA) defines a methodology for designing and implementing applications and systems in which events transmit between loosely coupled software components and services. An event-driven system is typically comprised of event consumers and event producers. Event consumers subscribe to an intermediary event manager, and event producers publish to this manager. When the event manager receives an event from a producer, the manager forwards the event to the consumer. If the consumer is unavailable, the manager can store the event and try to forward it later. This method of event transmission is referred to in message-based systems as store and forward.
[emphasis in original]

Assuming events are encoded as messages, then you can rewrite “event consumers / event producers” as “message receivers / message senders” and you really blur the line with SOA?

The big difference in EDA seems to be the use of an “intermediary event manager”. The problem I have with this approach is that the “intermediary event manager” works fine if you have a small number of endpoints, but how will it scale to handle hundreds of systems? Thousands? Tens of thousands? I don’t see how the centralized event manager approach can possibly scale to handle tens of millions of events delivered between tens of thousands of systems. The management of such a system would be a nightmare? If a business process went south, you would obviously look in the central event manager as the source of the problem, but I would think that would be like finding a needle in a haystack. You could federate the event managers, instead of attempting to scale out the center. But a federated event manager approach would seem to defeat much of the purpose of an EDA in the first place. If you’re going to federate your event managers, why not cut out the middle man and make each event producer it’s own event manager as well? What is the benefit of separating these capabilities?

I guess fleshing out EDA isn’t a bad idea, but it seems more like a solution looking for a problem to me.

Wednesday Oct 4th is the season premier for Lost. Two days later on Oct 6th is the season premier of Battlestar Galactica. These are my favorite two shows – an in my opinion the best two – on TV right now. According to Major Nelson, a one hour recap of BSG called “The Story So Far” is available on XBLM. If they could post a Lost and the Lost Experience recap on XBLM, that would just be perfect.

I’m sure my wife will blog this in more detail, but we’re on vacation so blogging isn’t top of her mind. Today was my brother’s wedding – I was the best man with the whole speech giving and everything. We left the kids with my wife’s sister tonight, but last night we brought them to the rehearsal dinner. They were the only two kids there but there were straight up amazingly well behaved. All night. Long past their bedtime (though to be honest, we are in Washington DC and still sort of on west coast time). I mean, I expect my kids to behave – but this was above and beyond. We got to the restaurant around 6pm and didn’t leave until 9:30! Tonight, at the wedding, several people told us how impressed they were with our kids. I am too.

Just wanted to blog how incredibly proud I am of my kids.

Ruby’s symbols are often talked about in terms of efficiency – taking up less memory and executing faster. While these are both laudable goals, symbols are more than just performance improvers. The ability to name things is valuable semantically. Take a look thru p&p’s Composite UI AppBlock and you’ll see strings used as names for things all over the place. It’s great for loose coupling, you see. But how do you tell the difference between a string used as a name and a string used for some other reason like user input? You can’t.

Rails makes extensive use of symbols – anyone who has Rolled on Rails has seen “scaffold :recipe”. That’s just the tip of the iceberg. Rails uses symbols extensively across both ActionPack and ActiveRecord (and probably others I’m not familiar with). It’s a great approach, but one that’s unique to Ruby as far as I’m aware.