Catálogo de publicaciones - libros

Coupling is one of those subjects that many people find terribly boring. The problem might stem from the fact that for most people, the word “coupling” isn’t specific. Hopefully, the material presented in this chapter has helped you understand the various facets of coupling. Knowing what coupling is and what effects it has, you might be inclined to spend time in your next project thinking about ways to design and partition your code to keep coupling under control. After all, a system with minimal coupling is much easier to develop, test, and maintain.

In this chapter, I provided a quick history and overview of events and notifications. Many people who develop “event-based“ programs are unaware of the extensive amount of work and the number of people involved in making events what they are today. Contrary to popular belief, events were not invented by Microsoft for Visual Basic back in the early 1990s. However, Visual Basic is probably the first product that opened up the world of event-based programming to the masses. The adoption of the event-based model in Visual Basic is what made that product so much easier to work with, compared to other products and technologies of the day.

When designing an event-based system, choosing a delivery protocol is not necessarily a simple task. The protocol is a function of several things, including complexity, cost, and system architecture. People have a tendency to master one protocol, such as synchronous procedure call delivery, and then use it to death, applying it even in situations where better choices are available. In the real world, you’ll find that one system parameter often outweighs others, narrowing your choices. For example, in real-time systems, speed usually trumps reliability. It would be out of the question to use a messaging service in such a system. In financial applications, reliability usually trumps speed. If the notification delivery system lost notifications, you’d have a hard time keeping customers. In some systems, security might trump both speed and reliability. To each his own. Hopefully this chapter has helped you choose the right protocol for each situation.

Event notifications are the lifeblood of an event-based system, so it is very important to choose the right type of delivery mechanism and payload. When notifications cross process boundaries, you have to be really careful about what kind of information is in the payload, because expensive marshaling might be involved. A common solution is to make use of lightweight business objects in notification payloads. These lightweight objects are sculpted carefully to exclude references to unnecessary user-defined types. Such lightweight objects can be passed across process boundaries with a minimum of overhead.

In this chapter, I’ve shown you some of the most common notification and messaging middleware systems in use today, but there are many more. The difference between a notification system and a messaging system is becoming increasingly blurred, and many commercial products provide support for both. While research systems tend to be more documented in the literature, commercial systems are on the front line and often push the envelope by using new techniques that can be of general interest.

With so many different types of diagrams out there, you might think there is no room for improvement. UML certainly dominates the landscape of software diagrams, but many people are starting to feel that UML has gotten too complex—that it is trying to solve too many problems at once. Is it a modeling language, a set of diagramming conventions, or a high-level programming language? Depending on how you use it, it can be all three. When dealing with event-based designs, a circuit-oriented diagram is often a good choice. Event notifications travel around the system like signals in an electrical circuit, so it makes sense to depict the system using the same kinds of concepts adopted in hardware diagrams. The next chapter is dedicated to a new kind of diagram developed specifically for event-based systems.

With this case study, you’ve seen how to use events and Coordinator teams to implement a multithreaded service component. I also showed you how to use events and Coordinator teams to create the supporting test programs. By developing HttpService as a component with no coupling to other components, HttpService is independently deployable. Moreover, because its worker classes are also completely decoupled from other classes, the workers are relatively simple to test and easy to reuse.

The simplest way to fire an event is with a procedure call. All OO programming languages have built-in support for firing events this way, but languages vary in the details. All languages support typed object calls, using interfaces, but not all support untyped object calls. Typed object calls are the traditional technique used by people with an object-oriented programming background. People with component-based development and event-based programming experience often favor untyped object calls, to minimize coupling between the event source and event handler.

Many of the interaction patterns that occur between software processes are similar to those that occur in the hardware world. When deciding which type of pattern to use, you should first determine whether you need a push or pull interaction. This decision usually depends on who has control of the interaction—the caller or the callee. The timing of the interaction (synchronous or asynchronous) is probably the second-most important decision. When creating asynchronous interactions, remember that it is usually better to handle the asynchrony on the caller side than the callee side.

Many of the interaction patterns that occur between software processes are similar to those that occur in the hardware world. When deciding which type of pattern to use, you should first determine whether you need a push or pull interaction. This decision usually depends on who has control of the interaction—the caller or the callee. The timing of the interaction (synchronous or asynchronous) is probably the second-most important decision. When creating asynchronous interactions, remember that it is usually better to handle the asynchrony on the caller side than the callee side.