OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tamie message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: EBA


From OASIS XML daily news July 2:

interesting comments on the testability of event-based systems, and their suitability to large-scale systems, beyond the usual UI application.

 

Jacques

---------------------------------------------------------------

Event-Based Architectures (EBAs) simplify system design, development, and testing because they minimize the relationships between the parts of a system... 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. 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.

http://www.ddj.com/architect/208801141



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]