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.

Thanks a lot for your detailed comment. I think it’s a good thing to dispute with both concepts (IBC and EBC) in a critical way. During the last weeks I got the feeling that people missed this important discussion and were hyping EBCs too much just because this style of programming is “different” (but without questioning the backgrounds and impacts)…

Back to your comment: it’s adding some new aspects that I didn’t see before. I’m not very certain about them, but I think it’s time to dig deeper into EBCs again I’m still an interface guy and like them as formal contract. In your comment you say when a component C calls f() and g(), an interface for f() and g() doesn’t make sense. I believe it makes sense when f() and g() belong to the same logical context and thus should be coupled into an interface. This explicitness IMHO improves readability and comprehensibility.

I think EBCs could get big with tools. Tools for binding, tools for navigation, but most of all tools for visualizing EBC systems. With such tools we could start to see EBCs not on a class/method base, but on a bigger scale as component systems. And this would be a big deal! Are such tools on their way yet?

~ Matthias

P.S.: EBC 2.0? Where can I find information/descriptions about that?

Interfaces as formal contracts are not missing from EBC. Right to the contrary! You can still define the offerings of an EBC component like your DataAccessComponent using an interface. And that´s even better than with IBC. Because in order to specify an IBC completely (like your BusinessClient) you´d need to list all exported interfaces as well as all imported interfaces. In your case that would be IBusinessClient + IDataAccessComponent.

In the EBC world the specification of the BusinessClient component would be just IBusinessClient.

I deem this an advantage over IBC. Specifications are more compact.

You´re right in that the current bindings are a bit cumbersome. EBC surely would benefit from generating them from some DSL.

However I find in my daily EBC practise that this drawback is only minimal compared to what is gained from EBC.

a) EBC “require” you to clearly separate domain functionality from code that just composes such functionality. It is a very helpful separation of concerns.

b) The difficult to read binding code usually is not very long. Due to the ease with which you can design on different levels of abstractions (compared to IBC) EBC boards are kept quite small.
In addition it is recommended to keep the design sketches with your code. They are a “poor mans DSL” until there is a designer tool. If you do that look at them to understand your software, not the wiring code in the boards. It´s a common mistake to stay glued to the code instead of using diagrams. With UML I understand why people do that; diagrams and code quickly get out of sync because it´s hard to translate from diagram into code. But that´s different with EBC. The translation is trivial. Thus the code is in sync with the diagram. And changes should flow from the diagram/design to the code.

So EBC fosters a less ad hoc, less cowboy programmer way of software development. Look at the cumbersome wiring code as a feature instead of a bug It´s a constant reminder to program in a clean way. Yes, that takes some getting used to it… but my experience is that´s worthwhile.

c) Although the wiring code is kinda hard to read it in fact is simple. It´s so regular… Once you develop an eye for it, it´s not that hard to comprehend anymore. I deem this simplicity very important. It makes software more predictable in its form. And that helps evolving it.

d) EBC very explicitly deal with dependencies. The only dependencies left are concentrated in board. And these board don´t have any domain functionality on them. So highly dependent code is simple. And complicated code is independent. That´s in accordance with all good principles of software development. Dependencies are the developers bane – penning them up in a few places thus is a great help.

Finally one word about topological dependencies as I termed them: They make IBC dependent on how functionality is grouped. If component C needs functions f() and g() it´s dependent on them. Maybe that cannot be avoided. But why in all the world should C also be dependent on f() and g() being lumped together on an interface?

As long as that´s the case C has two reasons to change (which is against the SRP): it needs to change if new domain requirements come up regarding its domain responsibility; and it needs to change if f() and g() are rearranged onto different interfaces for whatever reason. That´s bad.

-Ralf

PS: I suggest all interested in EBC to have a look at EBC 2.0. It´s a whole different view on how to carve out components from requirements. And the beauty of it: the nasty request/response communication simply goes away…

PPS: Just for the record: I´m not advovating giving up IBC altogether! Even EBC rely on them for defining EBC boards. But also beyond that IBC are of value. Don´t try to throw them away. They can be of great use within EBC parts/actions (atomic EBC components).

I totally agree to the lag of overview:
We are using the image of electronic circuits, which includes the components (== classes), the output-pins (== events) and the input-pins (== methods). The solder would be the EBC binder.

But we are still missing a circuit board! It would give us an overview of the connected (or faulty connected) pins. I’m thinking of a designer like the one for the Windows Workflow foundation… This could be the missed tool.

I’m going to watch the progress of EBC. Let’s see if it can join the club of the standard design patterns.