Published on January 17, 2014
Architectural Patterns [PART 2]
Architectural Patterns Interactive System Patterns – It describes architecture that support the adaptation of user interface parts without causing major effect to Application specific functionality or the underlying data model. • Model-View-Controller
Model-View-Controller This pattern can be used to divide system’s task to three different components - Model, View and Controller. • Model contains the core functionality and data. It is independent of the data received or presented in the views. There can be multiple view for same Model. • View displays information to the user. It may allow user to edit the data from the application’s model. • Controller handles user input. It can also perform set-up and coordinating tasks for an application. Views and Controllers together comprise the user interface. A change-propagation mechanism (e.g. Subscriber-obsever) ensures consistency between the user interface and the model.
Model-View-Controller Example – Web browser Invoke Result Request HTTP Browser (User) Response Model Servlet (Controller) JSP (View) Database
Architectural Patterns Event Handling Patterns – It describes how to initiate, receive, demultiplex, dispatch and process events in networked systems. • Proactor • Reactor • Asynchronous Completion Token • Acceptor-Connector
Proactor This pattern can be used for the demultiplexing and dispatching of multiple event handlers which are triggered by the completion of asynchronous events. It requires a dedicated thread for each connected client. In this pattern application issues an asynchronous operation to the OS and registers a callback with a Completion Dispatcher that will notify the Application when the operation completes. The OS then performs the operation on behalf of the application and subsequently queues the result in a well-known location. The Completion Dispatcher is responsible for dequeueing completion notifications and executing the appropriate callback that contains application-specific code.
Proactor Client (Web Server) OS Completion Despatcher HTTP Get request Read complete Handler File System Read complete Parse request Read File(sync) Write file data to client connection (Async) Write complete Write complete
Proactor Components – Proactive Initiator: Any entity in the application that initiates an Asynchronous Operation. The Proactive Initiator registers a Completion Handler and a Completion Dispatcher with a Asynchronous Operation Processor, which notifies it when the operation completes. Completion Handler (Acceptor ) : interfaces that are implemented by the application for Asynchronous Operation completion notification. Asynchronous Operations : it is used to execute requests (such as I/O and timer operations) on behalf of applications. Asynchronous Operation Processor : When Asynchronous Operations complete, the Asynchronous Operation Processor delegates application notifications to a Completion Dispatcher Completion Dispatcher (the Notification Queue) : it is responsible for calling back to the application’s Completion Handlers when Asynchronous Operations complete.
Reactor This can be used for handling service requests delivered concurrently to a service handler by one or more clients by demultiplexes and despathching the incoming requests to the associated request handlers. A reactor defines an interface that allows applications to register or remove event handlers and their associated handles, and run the application's event loop. It uses its synchronous event demultiplexer to wait for indication events to occur on its handle set. When this occurs, the reactor first demultiplexes each indication event from the handle on which it occurs to its associated event handler. Then it dispatches the appropriate hook method on the handler to process the event. Reactor pattern can not support many simultaneous users and/or longduration user requests as it serializes all processing at the event demultiplexing layer. As a result only one request can be dispatched and processed iteratively at any given time.
Reactor Components – Resources: Any resource that can provide input to or consume output from the system. Synchronous Event Demultiplexer: Uses an event loop to block on all resources. When it is possible to start a synchronous operation on a resource without blocking, the demultiplexer sends the resource to the dispatcher. Dispatcher: Handles registering and unregistering of request handlers. Dispatches resources from the demultiplexer to the associated request handler. Request Handler: An application defined request handler and its associated resource
Reactor Client Reactor Demultiplexer Instantiate event handler register event handler Select(…) handles Dispatch handleEvent(…) Demultiplex handleEvents() EventHandler
Asynchronous Completion Token This pattern can be used to demultiplex and process efficiently the responses of asynchronous operations it invokes on services. • For every asynchronous operation that a client invokes on a service, an asynchronous completion token (ACT) is created and Passed to the service together with the operation, which holds but does not modify the ACT. • When the service replies to the initiator, its response includes the ACT that was sent originally. • The initiator can then use the ACT to identify the completion handler that will process the response from the original asynchronous operation
Asynchronous Completion Token ACT – It contains information that uniquely identifies the completion handler, which is the function or object responsible for processing the operation's response. Components – Service - Provides functionality that can be accessed asynchronously. Completion handler – It is a function or object within an application that is responsible for processing service responses. Client initiator - Invokes operations on a service asynchronously. It also demultiplexes the response returned by these operations to a designated completion handler.
Asynchronous Completion Token Client Initiator Completion Handler ACT Create an ACT Invoke a service including ACT Do some other operation / Process response from other services Response including same ACT Completion_Action Process Result Service
Acceptor-Connector This pattern can be used to decouple service tasks performed by a service from the steps required to initialize the service. It is beneficial for an application which receives a large number of concurrent connections with peers residing across long-latency networks and not able to perform blocking or continuous polling for incoming connections on any individual peer due to latency. Components Reactor - The Reactor allows multiple Acceptors to listen for connections from different peers efficiently within a single thread of control. The Reactor allows multiple Service Handlers to have their connections initiated and completed asynchronously by a Connector configured within a single thread of control.
Acceptor-Connector Service Handler It contains a communication endpoint (peer stream ) that encapsulates an I/O handle (I/O descriptor). This endpoint is initialized by the Acceptor/Connector and is subsequently used by the Service Handler to exchange data with its connected peer. Acceptor This implements the strategy for passively initializing a Service Handler which communicates with the peer. The Reactor calls back to the Acceptor’s accept method when a connection arrives on the passive-mode peer acceptor endpoint. The accept method uses this passive-mode endpoint to accept connections into the Service Handler’s peer stream and then activate a Service Handler. Connector This implements the strategy for actively initializing a Service Handler which communicates with the peer. The Connector activates a connected Service after initialization is complete. The complete method finishes activating Service Handlers whose connections were initiated and completed asynchronously. the Reactor calls back the complete method automatically when an asynchronous connection is established.
Acceptor Acceptor component initialization and service processing : Server Acceptor Initialize end points Service Handler Reactor Register handler Get handle Handle events ( Loop for events) Handle Connection Event Create and Register Service handler Register handler for Client I/O Initialization Complete and ready for service processing Get handle Handle Data Event Service (process msg)
Connector Acceptor component initialization and service processing : Server Acceptor Initiate connection Service Handler Reactor Register handler Handle events ( Loop for events) Handle Connection event Connection Complete Perform service-specific initialization Register service handler Initialization Complete and ready for service processing Get handle Handle Data Event Service (process msg)
Thank You Your suggestions and comments are always welcome. Please send me your feedback at email@example.com
These are often referred to as the architectural styles, and include patterns such ... a range of patterns that the handling of the ... event handling.
... to model interactive ... Architectural patterns are often combined with ... event handling structures in both patterns would be redundant ...
Architectural patterns are similar to DSSAs but applied ... When handling input from the user the windowing ... Interactive applications
Event Systems (V.2) ... Handling & Synchronization Architectural Patterns Design Patterns Idioms ... Architectural Patterns Design Patterns Idioms
An architectural pattern is a general, ... Architectural patterns are similar to software design pattern but have a broader scope. ... Error handling;
Architectural Pattern: Layers . Intention. After collecting requirements from customers, we have to define the architecture of the system. So, we need to ...
Another suggestion when studying and considering the use of interactive design patterns is to ... the handling Controller. As with ... architectural ...
128 Architectural Patterns View components present information to the user. Different views present the information of the model in different ways.