Project Description
Event-Based Components (EBC) bring software development on par with mechanical engineering and electrical engineering in that they describe how software components can be made truely composable.

This project develops tools to help programming with EBCs.

Event-Based Components Overview

Event-Based Components (EBC) are the next step after "traditional" components or Injection-Based Components (IBC). Both are components, but EBCs don´t have any dependencies on particular "service components".

EBCs provide services to their environment through methods. In this they don´t differ from IBCs. Neither EBCs nor IBCs know who´s using them.

EBCs don´t call services of other components, though. Instead they "broadcast messages" (events) containing requests or just information. They don´t know whether there is any component receiving these messages.

An IBC customer repository contract might look like this:

interface ICustomerRepo_IBC
    Customer FindByName(string customerName);

An EBC contract for the same service could look like this:

interface ICustomerRepo_EBC
    void Input_FindCustomerByName(string customerName);
    event Action<Customer> Output_CustomerFound;

There are different ways to encode bi-directional communication between EBCs, but this is the basic way to do it:
  • input is received through regular methods
  • output is delivered through delegates; whether such a delegate is simple or multicast, is not important to the general EBC paradigm

Input methods and output delegates all have exactly 1 parameter. There are two reasons for this constraint:
  • If the number of parameters is fixed it´s much easier to build tools to support EBCs programming.
  • Requiring 1 parameter is in line with messaging APIs for async or distributed communication like MSMQ.

EBC communication is event-based that means it´s message oriented. This sounds as if EBCs were asynchronous. But they are not. At least not at the outset. The EBC paradigm is meant as a next step after synchronous IBCs.

Of course EBCs are easier and more naturally to be used in async and distributed scenarios than IBCs. But you can start doing EBC programming in sync scenarios.

EBCs are viewed to be part of a spectrum of programming paradigms layered on each other:
  1. procedural programming
  2. Object Oriented Programming
  3. Injection-Based Components - this is what DI containers are for
  4. sync Event-Based Components - we are here ;-)
  5. async Event-Based Components - this is where technologies like Concurrency Coordination Runtime come into play
  6. distributed Event-Based Components - this is where technologies like NServiceBus or Application Space come into play

Last edited Jan 27, 2011 at 5:18 AM by ralfw, version 8