|
Event-Based Architectures simplify system design, development, and testing because they minimize relationships between system parts.
June 26, 2008
URL:http://www.drdobbs.com/architecture-and-design/event-based-architectures/208801141
Ted is a software architect and author of Event-Based Programming: Taking Events to the Limit. He can be contacted at [email protected].
Software systems seem to be ruled by a fundamental law: As they get larger, their complexity increases exponentially. The reason for this is actually simple: Complexity is due not just to the number of parts in the system, but also to the relationship between the parts. Event-Based Architectures (EBAs) simplify system design, development, and testing because they minimize the relationships between the parts of a system.
I've built a number of EBA-based systems, ranging from a Windows desktop app for the real-estate market with about 10,000 concurrent users, to a single-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 or predominantly using event notifications, instead of direct method calls. An "event notification" is a signal that carries information about an event that was detected by the sender. While you're probably familiar with events like button clicks, events can be defined to include almost any conditions or occurrences you can think of. Notifications can be used to carry any domain-specific information you want, and in any type of system—embedded, GUI-based, distributed, or other.
There are different ways to deliver notifications, but the most common technique uses an indirect method call that is made through a pointer initialized at runtime. At design time, the compiler is unaware of what object (and perhaps even what type of object) the pointer will be referencing when the call is made. In an EBA, each part emits signals related to its internal state and reacts to signals received from other parts. This simple input/output model has important consequences: Each part can be developed and tested in isolation from the rest of the system, because it knows nothing about the other parts. In a well-designed EBA, the relationship of complexity versus size tends to be more linear than exponential, so the larger the system is, the better off you are with an EBA, compared to other conventional approaches.
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 a result of the occurrence of an event, a part might emit a notification. Notifications are signals sent to other parts to inform them about an event. Events don't move around in a system, notifications do. As if there wasn't enough confusion between events and notifications, people often say "firing an event" to indicate the sending of a notification. The expression is so common that I use it throughout this article.
The most well-known delivery mechanism for sending notifications from one part to another uses indirect method calls, but there are other mechanisms. With indirect method calls, there are essentially two different ways to deliver notifications:
Languages such as Java and C++ natively support typed calls. Languages such as C#, VB.NET, and Delphi support both typed and untyped calls. Java programmers can also use untyped calls, but need to resort to reflection 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();
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 A don't need to be of any special type. How important this distinction is usually depends on the size of the system you're building, and whether you have control of both the sender and receiver of notifications.
When you develop an EBA, most of the exchanges between the parts are based on notifications. Keep in mind that notifications can be exchanged between parts that don't reference each other. If you used a class diagram to describe this system, it would tell you little about how the system works, because there would be few or no associations between the classes. You would essentially end up with a diagram just listing all the classes, with no lines connecting them. A better way to document EBAs is to use "Signal Wiring Diagrams" (usually just called "Wiring Diagrams") which show who sends signals (notifications) to whom. I developed wiring diagrams several years ago to better model EBAs; see Figure 2.
The large boxes in Figure 2 denote objects. The names in the boxes show the object types. The small black boxes on the object borders are pins. Pins are the inputs and outputs of an object, in terms of notification signals. Each signal has arrows to denote the direction of flow. A small label above the signal line indicates the name of the notification. In Figure 2, the signal Print is sent from PrintManager to DocumentPrinter. Input pins can also contain the name of the method they connect to. You may have noticed that there are no interfaces shown in the diagram. When notifications are sent using untyped calls, interfaces are not involved. PrintManager doesn't know anything about the DocumentPrinter type. Indeed, PrintManager need not even know that DocumentPrinter is handling its Print notifications.
When notifications are sent using typed calls, interfaces are involved. In such cases, the interfaces are shown as gray boxes enclosing the pins that are associated with the interface methods; see Figure 3.
Signal wiring diagrams get their name because they look like hardware circuit diagrams used by electrical engineers. Software objects look like integrated circuits, with input and output pins. Notifications appear as interconnection wires. From a systems perspective, both hardware diagrams and signal wiring diagrams are representations of systems composed by parts wired together. Whether the boxes are implemented with hardware or software matters little, conceptually. The software objects might be replaced by hardware equivalents, with minimal changes to the overall diagram. Figure 4 shows the complete wiring diagram of SystemBrowser, a program I present in this article.
You can find a Visio stencil for wiring diagrams online (see www.ddj.com/code/ and www.faisoncomputing.com/samples/ EventBasedProgramming/VisioSignalWiringDiagramStencil.zip).
Again, an EBA relies on parts that are independent of each other and that communicate using event notifications. If the parts are essentially oblivious of each other, then how do the parts get created and wired together? Good question. Before answering it, let's look at how things work in traditional object-oriented systems. The operating system calls a program's entry point, which typically instantiates a top-level class, which in turn instantiates other intermediate-level classes, each of which might instantiate other intermediate-level classes and low-level classes. In GUI programs, the top-level class is often the main window. Intermediate-level classes tend to be those that handle important functionality. Low-level classes generally are domain-specific types used 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 whose root is the top-level class; see Figure 5. The graph implicitly shows coupling, because a class that contains code to instantiate another class is coupled to that class. The top-level class is hence directly or indirectly coupled to all the other classes in the system. The intermediate-level classes are directly or indirectly coupled to many other intermediate-level classes.
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 Builder is called by the program's entry point and has one job—to create instances of all the intermediate-level classes. Intermediate-level classes are no longer responsible for instantiating other intermediate-level classes. Intermediate-level classes communicate with each other exclusively using event notifications. When the notifications use untyped calls, there is no type coupling between the classes. The coupling diagram of this kind of system has a star shape, with all the low-level classes in the middle and all the intermediate-level classes at the periphery; see Figure 6.
The intermediate-level classes at the periphery of the diagram are not coupled to each other. For these classes to interact, notification paths between them must exist. These paths are created using another special type 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 Binder have access to all the intermediate classes of the system and hence they 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 is a small, event-based program I wrote that works somewhat like Windows Explorer. The program has a GUI with a main window divided into sections: a top toolbar, a bottom status bar, and a middle section with left and right panes. The left pane shows a directory tree, 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, notice that the main form is missing. An accident? No. In SystemBrowser, the main form does nothing more than hold the various UI elements together, and doesn't participate in the handling or dispatching of notifications in 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/
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 DirectoryContent populate themselves because I wanted to focus on what was important about SystemBrowser, in terms of its event-based design. The complete source code is available online. Looking at the code, you'll notice a number of methods starting with the word "Fire". I use a separate Fire method to handle the firing of each event type, avoiding having event semantics scattered around, while having a single place to set breakpoints when testing an event.
The larger a system gets, the more you can benefit from Event-Based Architectures. The individual parts, be they classes or components, have little or no type coupling to the rest of the system. This is especially important for testability. EBAs are eminently testable. They can be tested incrementally and can be developed using a test-driven approach. You can develop and test every major part of a system in isolation. Very cool.
Over the years, I have developed many different types of software systems using EBAs. People sometimes find it perplexing that the salient classes in an EBA have no associations between them, but this is often a good thing because EBAs reduce coupling in order to reduce complexity. I have found that signal wiring diagrams are a good way to document and model EBAs. Although they are different from most of the diagrams you're probably seen before, they are easy to understand and easy to create.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.