19

Click here to load reader

Architectural Patterns - Interactive and Event Handling Patterns

  • Upload
    assinha

  • View
    492

  • Download
    1

Embed Size (px)

DESCRIPTION

This presentation describes about Interactive architectural patterns and Event Handling Architectural patterns.

Citation preview

Page 1: Architectural Patterns  - Interactive and Event Handling Patterns

Architectural Patterns[PART 2]

Page 2: Architectural Patterns  - Interactive and Event Handling Patterns

Architectural PatternsInteractive 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

Page 3: Architectural Patterns  - Interactive and Event Handling Patterns

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.

Page 4: Architectural Patterns  - Interactive and Event Handling Patterns

Model-View-Controller

Example – Web browser

Forward Request

HTTP Browser

(User)

Servlet(Controller)

Model Database

Request

Invoke

Response

Result

Response

JSP(View)

Page 5: Architectural Patterns  - Interactive and Event Handling Patterns

Architectural PatternsEvent Handling Patterns – It describes how to initiate, receive, demultiplex, dispatch and process events in networked systems.• Proactor• Reactor• Asynchronous Completion Token • Acceptor-Connector

Page 6: Architectural Patterns  - Interactive and Event Handling Patterns

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 appropriatecallback that contains application-specific code.

Page 7: Architectural Patterns  - Interactive and Event Handling Patterns

Write file data to client connection (Async)

Proactor

Client(Web Server) OS Completion

DespatcherHandler

HTTP Get requestRead complete

Read complete

Parse request

File System

Read File(sync)

Write complete

Write complete

Page 8: Architectural Patterns  - Interactive and Event Handling Patterns

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 DispatcherCompletion Dispatcher (the Notification Queue) : it is responsible for calling back to the application’s Completion Handlers when Asynchronous Operations complete.

Page 9: Architectural Patterns  - Interactive and Event Handling Patterns

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 long-duration 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.

Page 10: Architectural Patterns  - Interactive and Event Handling Patterns

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

Page 11: Architectural Patterns  - Interactive and Event Handling Patterns

Reactor

Client Reactor Demultiplexer EventHandler

Instantiate event handler

register event handler

handleEvents() Select(…)

handles

handleEvent(…)

Dem

ultiplexD

ispatch

Page 12: Architectural Patterns  - Interactive and Event Handling Patterns

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

Page 13: Architectural Patterns  - Interactive and Event Handling Patterns

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.

Page 14: Architectural Patterns  - Interactive and Event Handling Patterns

Asynchronous Completion Token

Client Initiator

Completion Handler ACT Service

Create an ACTInvoke a service including ACT

Response including same ACT

Process Result

Completion_Action

Do some other operation / Process response from other services

Page 15: Architectural Patterns  - Interactive and Event Handling Patterns

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 listenfor 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.

Page 16: Architectural Patterns  - Interactive and Event Handling Patterns

Acceptor-ConnectorService 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.

Page 17: Architectural Patterns  - Interactive and Event Handling Patterns

Acceptor

Acceptor component initialization and service processing : -

Server Acceptor ServiceHandler

Reactor

Initialize end pointsRegister handler

Get handleHandle events ( Loop for events)

Handle Connection EventCreate and Register Service handler

Register handler for Client I/O

Get handle

Handle Data Event

Service (process msg)

Initialization Complete and ready for service processing

Page 18: Architectural Patterns  - Interactive and Event Handling Patterns

Connector

Acceptor component initialization and service processing : -

Server Acceptor ServiceHandler

Reactor

Initiate connectionRegister handler

Handle events ( Loop for events)Handle Connection event

Perform service-specific initializationRegister service handler

Get handle

Handle Data Event

Service (process msg)

Initialization Complete and ready for service processing

Connection Complete

Page 19: Architectural Patterns  - Interactive and Event Handling Patterns

Thank You

Your suggestions and comments are always welcome.

Please send me your feedback at [email protected]