Software Design and Architecture Lecture 13
This lecture delves into the intricacies of software design and architecture, exploring advanced concepts and best practices in the field. Dive deep into the principles that govern the design of software systems and understand the crucial role that architecture plays in creating robust and scalable applications. Gain valuable insights from real-world examples and case studies to enhance your knowledge and skills in software development.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 13
Review Shared Data Software Architectures Black board Style architecture
Outline Implicit Asynchronous Communication Software Architecture
IMPLICIT ASYNCHRONOUS COMMUNICATION SOFTWARE ARCHITECTURE
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.
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.
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.
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
Based on Observer pattern Basically, components communicate using a generalized Observer Design Pattern style of communication.
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.
Specializations Often connectors in an implicit invocation system include the traditional procedure call in addition to the bindings between event announcements and procedure calls.
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?
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.
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.
NON-BUFFERED EVENT-BASED IMPLICIT INVOCATIONS
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.
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.
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
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.
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.
BUFFERED MESSAGE-BASED SOFTWARE ARCHITECTURE
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.
The buffered message-based software architecture Messaging is a mechanism or technology that handles asynchronous or synchronous message delivery effectively and reliably.
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.
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.
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.
Benefits: Anonymity: provides high degree of anonymity between message producer and consumer. Concurrency: supports concurrency both among consumers and between producer and consumers. Scalability
Limitations: Capacity limit of message queue: Increased complexity of the system design and implementation.
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.
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
Summary Implicit Asynchronous Communication Software Architecture
