sap crystal reports qr code THE MECHANICS OF EVENT FIRING in Font

Maker QR in Font THE MECHANICS OF EVENT FIRING

Summary

The simplest way to fire an event is with a procedure call. All OO programming languages have builtin 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.

n an EBS, notifications represent the bulk of intercomponent and interobject communication traffic. As you ve seen, you can deliver notifications using any number of delivery models, such as messages or procedure calls, but the delivery model is really only a low-level detail. Looking at a system from a higher level, you can abstract away the details of how communication occurs and focus on what an interaction is trying to accomplish and how. Software systems can be considered societies of communicating and cooperating processes. Process interactions are similar to conversations between people. The expression interaction dynamics is used to describe the ways software processes interact with each other over time, with particular interest in the following areas: Roles: Which process is giving information to the other The word information is used here to denote both commands and data. One process might assume the role of caller or data provider with respect to the other. Control: Which process is in charge of the interaction Which one is responsible for initiating it Can the interaction be aborted If so, by which process Is one of the processes responsible for monitoring the progress of the interaction Which process decides when the interaction terminates Timing: When sending messages, can the sender wait forever for a response Can the sender continue with other work while waiting for a response Does the sender require a response within a certain time frame Can the receiver accept other messages while processing a prior one Flow: Is information sent in a single exchange, or it is broken down into an iteration of smaller ones If an iterative flow is used, how is the end of the iteration signaled Looking at different kinds of software systems, it becomes apparent that there are recurring ways that processes interact in terms of communication mechanics, assumptions made by the communicating parties, goals of the sender, overall timing, and so on. I ll call these recurrences interaction patterns, and I ll show that they describe situations that are extremely common, not just in software systems but in everyday life. The patterns presented in this chapter are based on a paper I presented at a patterns workshop in the summer of 1998.1 I ve renamed some patterns to give them a broader characterization. In keeping with the conventions adopted by popular patterns handbooks, I ll begin each pattern with a synopsis box, describing the context in which the pattern applies. A list of forces follows, describing the system constraints that the pattern must deal with. Each pattern has at least two examples, depicting an occurrence in everyday life and in a software system.

1. Ted Faison, Interaction Patterns for Communicating Processes (proceedings of PLoP98, Pattern Languages of Programs, Monticello, IL, August 1998, http://citeseer.ist.psu.edu/faison98interaction.html).

Much of the work on software patterns centers on the structure, relationship, and organization of objects and classes. The emphasis is on characterizing what objects do and what structure they have, especially in relationship to one another. This inclination toward function and structure is due to the influence of Alexander s work 20 years ago,2 regarding the patterns adopted in the architecture of buildings and cities. But software systems are more than collections of objects with a purpose. They are rather like a group of people that accomplish a task by conversing or exchanging messages with one another. Studying the dynamics of conversations can be useful, because it reveals that there are patterns in the way we communicate. Implied assumptions, expectations, understandings, and goals drive entities to communicate. In terms of dynamics, what is important is how the entities carry out a conversation or transaction: who starts it, who ends it, who gives information to the other, whether both parties can talk at the same time, what the goals are, and so on. When analyzing communication and looking for communication patterns, a good place to look for analogies is natural language: the language we use every day to talk to each other. After all, natural languages have evolved over thousands of years and have developed ways to support every conceivable type of communication situation. There are hundreds of natural languages in use today, and probably even more that have died out. Some, like Latin and Sanskrit, have disappeared from speech but continue to survive in writing. Linguistics is the field that studies the structure and dynamics of language, so one would expect to learn a great deal about communication patterns from linguistics. When considering linguistics, what is most interesting for the current discussion is sentence morphology. The shortest complete sequence of words that has meaning by itself is a sentence. There are different types of sentences, depending on what needs to be said and how. The three most important types are imperative, declarative, and interrogative. Table 9-1 provides a brief description.