Event-Based Architectures

Event-Based Architectures simplify system design,development, and testing because they minimize relationships betweensystem parts.

ByTed Faison
June 26, 2008
URL:http://www.ddj.com/architecture-and-design/208801141

Ted is a software architect and author of Event-Based Programming:Taking Events to the Limit. He can be contacted atted.faison@computer.org.

Software systems seem to be ruled by a fundamental law: As they getlarger, their complexity increases exponentially. The reason for this isactually simple: Complexity is due not just to the number of parts inthe system, but also to the relationship between the parts. Event-BasedArchitectures (EBAs) simplify system design, development, and testingbecause they minimize the relationships between the parts of a system.

I've built a number of EBA-based systems, ranging from a Windows desktopapp for the real-estate market with about 10,000 concurrent users, to asingle-user desktop application that talks to a secure web service.

What Is an EBA?

An EBA is an architecture based on parts that interact solely orpredominantly using event notifications, instead of direct method calls.An "event notification" is a signal that carries information about anevent that was detected by the sender. While you're probably familiarwith events like button clicks, events can be defined to include almostany conditions or occurrences you can think of. Notifications can beused to carry any domain-specific information you want, and in any typeof system—embedded, GUI-based, distributed, or other.

There are different ways to deliver notifications, but the most commontechnique uses an indirect method call that is made through a pointerinitialized at runtime. At design time, the compiler is unaware of whatobject (and perhaps even what type of object) the pointer will bereferencing when the call is made. In an EBA, each part emits signalsrelated to its internal state and reacts to signals received from otherparts. This simple input/output model has important consequences: Eachpart can be developed and tested in isolation from the rest of thesystem, because it knows nothing about the other parts. In awell-designed EBA, the relationship of complexity versus size tends tobe more linear than exponential, so the larger the system is, the betteroff you are with an EBA, compared to other conventional approaches.

Events and Notifications

Most popular object-oriented languages support the concept of events,but there is confusion between the terms "event" and "notification."Just to be clear, an event is something that happens to a part. As aresult of the occurrence of an event, a part might emit a notification.Notifications are signals sent to other parts to inform them about anevent. Events don't move around in a system, notifications do. As ifthere wasn't enough confusion between events and notifications, peopleoften say "firing an event" to indicate the sending of a notification.The expression is so common that I use it throughout this article.

How Notifications Travel

The most well-known delivery mechanism for sending notifications fromone part to another uses indirect method calls, but there are othermechanisms. With indirect method calls, there are essentially twodifferent ways to deliver notifications:

• Typed calls. A typed call is a call through a known type (a class or interface). The caller has a pointer to a typed object, and calls one of the object's methods.
• Untyped calls. An untyped call is a call to a method of an object whose type is unknown. The caller knows only the signature of the method to be called, and knows nothing about the object to which the method belongs.

Languages such as Java and C++ natively support typed calls. Languagessuch as C#, VB.NET, and Delphi support both typed and untyped calls.Java programmers can also use untyped calls, but need to resort toreflection and Method.invoke() to do so.

In Figure 1, assume you have two classes A and B, which interact using notifications. When some event occurs in A, you want B.DoSomething() to be executed. To achieve this, A will have to send a notification to B. To send notifications using typed calls, class A needs to contain a field referencing type B. At runtime, this reference is somehow set; for this example, it doesn't matter how or when. When firing the event, class A invokes the method B.DoSomething() on the referenced object using code of the form:

if (referenceToB != null)referenceToB.DoSomething();

[Click image to view at full size]

Figure 1: Two classes that interact using notifications.

To send notifications using untyped calls, class A needs to have a field referencing not type B, but a method with the signature of B.DoSomething(). In .NET languages, delegates are language-defined entities that can point to methods with a given signature. In C#, class A might have a delegate defined like this:

public delegate void SomeHandler();

The delegate can then be used to define a field to hold a reference to a method with the given signature:

public event SomeHandler myHandler;

At runtime, myHandler would be initialized somehow (the details of which are not important here) to point at the method DoSomething of some instance of class B. Class A would then use this code to fire an event:

if (myListener != null)myListener();

In Java, the same thing can be accomplished using reflection with Method.invoke(). Class A would need to have a field of type Method. At runtime, class A would need to initialize the Method field to point to method DoSomething() of some instance of B. Class A would then use the Method field to invoke B.DoSomething().

Typed and untyped calls achieve the same net result (invoking DoSomething() on an instance of class B), but with important differences—with typed calls, class A must know about type B, so A must be created with the knowledge of B. Also, any objects that wish to handle notifications from A need to be of type B, or derived from B. With untyped calls, A does need to know about type B. Objects wishing to handle notifications from Adon't need to be of any special type. How important this distinction isusually depends on the size of the system you're building, and whetheryou have control of both the sender and receiver of notifications.

Wiring Diagrams

When you develop an EBA, most of the exchanges between the parts arebased on notifications. Keep in mind that notifications can be exchangedbetween parts that don't reference each other. If you used a classdiagram to describe this system, it would tell you little about how thesystem works, because there would be few or no associations between theclasses. You would essentially end up with a diagram just listing allthe classes, with no lines connecting them. A better way to documentEBAs is to use "Signal Wiring Diagrams" (usually just called "WiringDiagrams") which show who sends signals (notifications) to whom. Ideveloped wiring diagrams several years ago to better model EBAs; seeFigure 2.

The large boxes in Figure 2 denote objects. The names in the boxes showthe object types. The small black boxes on the object borders are pins.Pins are the inputs and outputs of an object, in terms of notificationsignals. Each signal has arrows to denote the direction of flow. A smalllabel above the signal line indicates the name of the notification. InFigure 2, the signal Print is sent from PrintManager to DocumentPrinter.Input pins can also contain the name of the method they connect to. Youmay have noticed that there are no interfaces shown in the diagram.When notifications are sent using untyped calls, interfaces are notinvolved. PrintManager doesn't know anything about the DocumentPrinter type. Indeed, PrintManager need not even know that DocumentPrinter is handling its Print notifications.

[Click image to view at full size]

Figure 2: A simple wiring diagram showing untyped call notifications.

When notifications are sent using typed calls, interfaces are involved.In such cases, the interfaces are shown as gray boxes enclosing the pinsthat are associated with the interface methods; see Figure 3.

[Click image to view at full size]

Figure 3: A wiring diagram showing typed call notifications.

Signal wiring diagrams get their name because they look like hardwarecircuit diagrams used by electrical engineers. Software objects looklike integrated circuits, with input and output pins. Notificationsappear as interconnection wires. From a systems perspective, bothhardware diagrams and signal wiring diagrams are representations ofsystems composed by parts wired together. Whether the boxes areimplemented with hardware or software matters little, conceptually. Thesoftware objects might be replaced by hardware equivalents, with minimalchanges to the overall diagram. Figure 4 shows the complete wiringdiagram of SystemBrowser, a program I present in this article.

[Click image to view at full size]

Figure 4: The wiring diagram of SystemBrowser.

You can find a Visio stencil for wiring diagrams online (see www.ddj.com/code/ and www.faisoncomputing.com/samples/ EventBasedProgramming/VisioSignalWiringDiagramStencil.zip).

Hooking the Parts Together

Again, an EBA relies on parts that are independent of each other andthat communicate using event notifications. If the parts are essentiallyoblivious of each other, then how do the parts get created and wiredtogether? Good question. Before answering it, let's look at how thingswork in traditional object-oriented systems. The operating system calls aprogram's entry point, which typically instantiates a top-level class,which in turn instantiates other intermediate-level classes, each ofwhich might instantiate other intermediate-level classes and low-levelclasses. In GUI programs, the top-level class is often the main window.Intermediate-level classes tend to be those that handle importantfunctionality. Low-level classes generally are domain-specific typesused by and exchanged between intermediate-level classes. For example,in a word-processing program, a SpellingChecker class might be an intermediate one and a Paragraph class might be a low-level one.

If you diagrammed the instantiation sequence of a traditional OO system,you would generally end up with a single-rooted directed graph whoseroot is the top-level class; see Figure 5. The graph implicitly showscoupling, because a class that contains code to instantiate anotherclass is coupled to that class. The top-level class is hence directly orindirectly coupled to all the other classes in the system. Theintermediate-level classes are directly or indirectly coupled to manyother intermediate-level classes.

[Click image to view at full size]

Figure 5: The instantiation graph of a traditional object-oriented system.

In EBAs, much of this coupling is avoided by using a special type of part called a Builder (not to be confused with the Builder OO design pattern). An EBA Builderis called by the program's entry point and has one job—to createinstances of all the intermediate-level classes. Intermediate-levelclasses are no longer responsible for instantiating otherintermediate-level classes. Intermediate-level classes communicate witheach other exclusively using event notifications. When the notificationsuse untyped calls, there is no type coupling between the classes. Thecoupling diagram of this kind of system has a star shape, with all thelow-level classes in the middle and all the intermediate-level classesat the periphery; see Figure 6.

[Click image to view at full size]

Figure 6: Typical coupling diagram of an event-based system.

The intermediate-level classes at the periphery of the diagram are notcoupled to each other. For these classes to interact, notification pathsbetween them must exist. These paths are created using another specialtype of part called a Binder. At system startup time, after the Builder has created all the intermediate parts, the Binder takes over and wires them together. When the Binder is finished, the system is ready to perform its intended functions. Both the Builder and Binderhave access to all the intermediate classes of the system and hencethey are coupled to those classes. The coupling diagram for the Builder and Binder system is star-based, but this time the Builder and Binder are in the center and the coupling arrows are directed outward, towards the intermediate-level classes.

SystemBrowser: An Event-Based System

SystemBrowser is a small, event-based program I wrote that workssomewhat like Windows Explorer. The program has a GUI with a main windowdivided into sections: a top toolbar, a bottom status bar, and a middlesection with left and right panes. The left pane shows a directorytree, the right the files and subdirectories in the selected directory;see Figure 7.

Figure 4 is the complete wiring diagram for SystemBrowser. FormMenuToolbar contains a menu and toolbar, which are created by the Builder,then attached to the main form at startup time. In Figure 4, noticethat the main form is missing. An accident? No. In SystemBrowser, themain form does nothing more than hold the various UI elements together,and doesn't participate in the handling or dispatching of notificationsin the system.

I wrote a C# implementation of SystemBrowser. The Builder instantiates all classes and maintains references to them, holding them in scope for the lifetime of the application. The Binder wires all the objects together. To keep things simple, I combined the Builder and Binder code into a single class called BuilderBinder. Listing One shows the Builder code and Listing Two shows the Binder code. (Both listings are available online at www.ddj.com/code/

[Click image to view at full size]

Figure 7: SystemBrowser UI.

What controls the building and binding of the system is the startup code in the EntryPoint class (Listing Three, online). Listing Four shows the salient code of FormMenuToolbar, DirectoryTree, and DirectoryContent, respectively. I omitted the details of how DirectoryTree and DirectoryContentpopulate themselves because I wanted to focus on what was importantabout SystemBrowser, in terms of its event-based design. The completesource code is available online. Looking at the code, you'll notice anumber of methods starting with the word "Fire". I use a separate Firemethod to handle the firing of each event type, avoiding having eventsemantics scattered around, while having a single place to setbreakpoints when testing an event.

Conclusion

The larger a system gets, the more you can benefit from Event-BasedArchitectures. The individual parts, be they classes or components, havelittle or no type coupling to the rest of the system. This isespecially important for testability. EBAs are eminently testable. Theycan be tested incrementally and can be developed using a test-drivenapproach. You can develop and test every major part of a system inisolation. Very cool.

Over the years, I have developed many different types of softwaresystems using EBAs. People sometimes find it perplexing that the salientclasses in an EBA have no associations between them, but this is often agood thing because EBAs reduce coupling in order to reduce complexity. Ihave found that signal wiring diagrams are a good way to document andmodel EBAs. Although they are different from most of the diagrams you'reprobably seen before, they are easy to understand and easy to create.