although this is a pretty old post in terms of the speed of “software development” development, I ought to drop a few notes.

First of all, I do agree that there is a “lack of common”. On a circuit board, you’d better agree on a certain Voltage, like 0..5 V+=. Something like a short-circuit brining the 230 V~ to the board would evaporize it. As long as the components (yes, components, back to the old days…) don’t protected themselves.

What sexy thingy could possibly protect the components from being blown up this way? Well, you guessed it: a microkernel.

At least in my opinion, Ralf’s idea becomes revolutionary when you drop your affiction to method signatures, and draw your attention to messages aka data carriers aka payloads.

Opposite to electric circuits, where the only language spoken would be electric charge, expressed in Volts and Watts, events could, if we let them, throw around anything, even dynamics. Just add a [Serializable] attribute. Although I’d agree that the simpler the definition was, the better we’d walk away, we could still leave any verification to the receiving component, as long as we implement a good fuse.

The most important thing that Ralf offered with the EBCs, at least in my humble opinion, is that there is no “response”. What in turn lets any x-tier architecture become deprecated. If you want to talk to me, throw a ball at my direction. If I want to talk to you, I’ll throw a ball at your direction. As simple as it sounds, as simple it is. No more hierarchies. Call it democracy at the level of data containers (aka SOAP messages, be it inProc or outProc, it doesn’t matter).

As long as all parties involved speak the same language (repeat: as I said, that’s a microkernel’s job), you, as a coder, “just” have to say goodbye to orchestration.

Can I use your expression compiler (with permission and included license of course) in my OSS project? It’s here http://servelat.codeplex.com/

Thanks,
Yevhen