1. SOFTWARE DESIGN AND ARCHITECTURE LECTURE 13

2. Review Shared Data Software Architectures – Black board Style architecture

3. Outline Implicit Asynchronous Communication Software Architecture

4. IMPLICIT ASYNCHRONOUS COMMUNICATION SOFTWARE ARCHITECTURE

5. Implicit Asynchronous Communication Software Architecture The main purpose of this type of communication architecture is to provide a decoupling between the event/message, the publishers/producers, and the subscribers/customers. These are very popular architectures in distributed applications.

6. Implicit Invocation Style Instead of invoking a procedure directly – A component can announce (or broadcast) one or more events. – Other components in the system can register an interest in an event by associating a procedure with the event. – When an event is announced, the broadcasting system (connector) itself invokes all of the procedures that have been registered for the event.

7. Event-based, Implicit Invocation Style Suitable for applications that involve loosely-coupled collection of components, each of which carries out some operation and may in the process enable other operations. Particularly useful for applications that must be reconfigured “on the fly”: – Changing a service provider. – Enabling or disabling capabilities.

8. Components – Modules whose interfaces provide a collection of procedures/methods and a set of events that it may announce Connectors – Bindings between event announcements and procedure/method calls

9. Based on Observer pattern Basically, components communicate using a generalized Observer Design Pattern style of communication.

10. Implicit Invocation Invariants Announcers of events do not know which components will be affected by those events. Components cannot make assumptions about the order of processing. Components cannot make assumptions about what processing will occur as a result of their events.

11. Specializations Often connectors in an implicit invocation system include the traditional procedure call in addition to the bindings between event announcements and procedure calls.

12. Integrated Development Environments (IDEs) Think of the debugging process (use of breakpoints) – How editors behaves on a breakpoint? – How variables monitors behave on a breakpoint? – How these components know when these are required?

13. Examples Used in programming environments to integrate tools: – Debugger stops at a breakpoint and makes that announcement. – Editor responds to the announcement by scrolling to the appropriate source line of the program and highlighting that line.

14. Examples Used to enforce integrity constraints in database management systems (called triggers). Used in user interfaces to separate the presentation of data from the applications that manage that data.

15. NON-BUFFERED EVENT-BASED IMPLICIT INVOCATIONS

16. Non-buffered Event-Based Implicit Invocations The nonbuffered event-based implicit invocation architecture breaks the software system into two partitions: – Event sources and – Event listeners. The event registration process connects these two partitions. There is no buffer available between these two parties.

17. Non-buffered Event-Based Implicit Invocations In the event-based implicit invocations (nonbuffered) each object keeps its own dependency list. Any state changes of the object will impact its dependents. the basic concept of event-based implicit invocation, which is the opposite of the direct explicit method invocation whereby the invoker must wait for the response from the called module; in this case, the invoker does not proceed until the called party responds.

18. Applicable domains of nonbuffered event-driven architecture: Interactive GUI component communication and integrated development environment (IDE) tools Applications that require loose coupling between components that need to notify or trigger other components to take actions upon asynchronous notifications When event handlings in the application are not predictable

19. Benefits: Framework availability: Many vendor APIs such as Java AWT and Swing components are available. Reusability of components: It is easy to plug in new event handlers without affecting the rest of the system. System maintenance and evolution: Both event sources and targets are easy to update. Independency and flexible connectivity: Dynamic registration and deregistration can be done dynamically at runtime. Parallel execution of event handlings is possible.

20. Limitations: It is difficult to test and debug the system since it is hard to predict and verify responses and the order of responses from the listeners. – The event trigger cannot determine when a response has finished or the sequence of all responses. There is tighter coupling between event sources and their listeners than in message queue-based or message topic-based implicit invocation. Reliability and overhead of indirect invocations may be an issue.

21. BUFFERED MESSAGE-BASED SOFTWARE ARCHITECTURE

22. The buffered message-based software architecture It breaks the software system into three partitions: – message producers, – Message consumers, and – message service providers. They are connected asynchronously by either a message queue or a message topic.

23. The buffered message-based software architecture Messaging is a mechanism or technology that handles asynchronous or synchronous message delivery effectively and reliably.

24. The buffered message-based software architecture A messaging client can produce and send messages to other clients, and can also consume messages from other clients. Each client must register with a messaging destination in a connection session provided by a message service provider for creating, sending, receiving, reading, validating, and processing messages.

25. Applicable domains of message-based architecture: Suitable for a software system where the communication between a producer and a receiver requires buffered message-based asynchronous implicit invocation for performance and distribution purposes. The provider wants components that function independently of information about other component interfaces so that components can be easily replaced.

26. Applicable domains of message-based architecture: The provider wants the application to run whether or not all other components are running simultaneously. The application business model allows a component to send information and to continue to operate on its own without waiting for an immediate response.

27. Benefits: Anonymity: provides high degree of anonymity between message producer and consumer. Concurrency: supports concurrency both among consumers and between producer and consumers. Scalability

28. Limitations: Capacity limit of message queue: Increased complexity of the system design and implementation.

30. Advantages Provides strong support for reuse since any component can be introduced into a system simply by registering it for the events of that system. Eases system evolution since components may be replaced by other components without affecting the interfaces of other components in the system.

31. Disadvantages When a component announces an event: – it has no idea how other components will respond to it, – it cannot rely on the order in which the responses are invoked – it cannot know when responses are finished

32. Summary Implicit Asynchronous Communication Software Architecture