Unit4 Notes 1s4e21
This document was ed by and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this report form. Report r6l17
Overview 4q3b3c
& View Unit4 Notes as PDF for free.
More details 26j3b
- Words: 6,563
- Pages: 28
DESIGN PATTERNS-I UNIT - 7 DESIGN PATTERNS – 1: Syllabus :
- 6hrs
• What is a pattern • what makes a pattern? • Pattern categories; • Relationships between patterns; • Pattern description. • Communication Patterns: • Forwarder-Receiver; • Client-Dispatcher-Server; • Publisher-Subscriber. The architect Christopher Alexander defines the term pattern as: Each pattern is a three-part rule, which expresses a relation between a certain context, a problem & a solution. What is pattern? A pattern for software architecture describes a particular recurring design problem that arises in specific design contexts, and presents a well-proven generic scheme for its solution. The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate. What Makes a Pattern? Three-part schema that underlies every pattern: Context: a situation giving rise to a problem. Problem: the recurring problem arising in that context. Solution: a proven resolution of the problem. Context: For eg: “developing software with a human-computer interface”. Specifying the correct context for the problem is difficult. It is practically impossible to determine all situations in which a pattern may be applied. Problem:
Defines problem specification Defines set of forces o The term ‘force denotes any aspect of the problem that should be considered while solving it, such as
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 1
DESIGN PATTERNS-I o Requirements the solution must fulfill o Constraints you must consider o Desirable properties the solution should have. Solution:
In software architectures, such a solution includes two aspects: Every pattern specifies a certain structure, a spatial configuration of elements. It consists of both components and their relationships. Every pattern specifies runtime behavior. This runtime behavior addresses the dynamic aspects of the solution.
Explain the MVC design for software architecture, with OMT (6M) diagram Let us consider software with a human-computer interface. -
The interface is prone to change. To provide the functionality extension will be challenging. Usually interface will be adapted for specific customers. When upgrading an operating system the parameters to provide interface may change. o Changes will increase the cost of development and copies of different implementations have to be saved in memory.
The important aspects of -interface development are: 1. Changes to interface should be easy and possible at run time. 2. Adapting or porting the interface should not impact code in the functional core of the application.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 2
DESIGN PATTERNS-I To solve the problem, divide an interactive application into three areas: processing , output & input.
Basic parts of any application: 1. Data being manipulated by the input events. 2. A -interface through which data manipulation occurs. 3. The data is logically independent from how it is displayed to the . The internal representation of data is different. Model component:
Encapsulates core data & functionality
Independent of specific output representations or input behavior.
View component:
Display information to the
Obtains the data it displays from the model.
There can be multiple views of the model.
Controller component:
Each view has an associated controller component.
Controllers receive input (service request---keyboard input/ mouse click)
-
which are sent either to the model or to the view.
The interacts with the system only via controllers. To achieve clear understanding of model-view-controller, the set-up sequence can be analyzed. The model is initialized. After this the view is initialized. The reference to a controller is made. The controller is the middle component, therefore controller references to both model and view. The updations are only through controller, hence controller s with view. At execution level, view recognizes input event. Input event is data entry or menu selection. View procedure calls appropriate method on controller. Controller procedure accesses model and updates it.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 3
DESIGN PATTERNS-I -
If model has been changed, view is updated (via the controller). With this set-up functional core independency is achieved. We can change from a non-graphical to a graphical interface, without modifying the model subsystem. (Independent of specific ‘look and feel’). We can add a for a new input device without affecting information display or the functional core.
The following OMT class diagram illustrates this solution:
What is pattern? Explain briefly properties of patterns for software architecture----8M Properties of patterns for Software Architecture 1. A pattern addresses a recurring design problem that arises in specific design situations, and presents a solution to it. i. Context: a situation giving rise to a problem. ii. Problem: the recurring problem arising in that context. iii. Solution: a proven resolution of the problem. 2. Patterns document existing, well-proven design experience. Patterns not created artificially but by reusing the design knowledge of several experienced practitioners. Using past experience of practitioners high quality software can be developed. Example MVC pattern for developing interactive applications. 3. Patterns identify & and specify abstractions that are above the level of single classes and instances, or of components. i. A pattern describes several components, classes, objects ii. Every pattern reveals details, responsibilities, relationships and their cooperation between the components. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 4
DESIGN PATTERNS-I
4.
5.
6.
7.
8.
iii. All components together solve the problem that the pattern addresses. iv. Eg: MVC – three cooperating components. Patterns provide a common vocabulary and understanding for design principles i. Every pattern has names eg: MVC ii. Every pattern facilitates effective discussion of design problems and solutions. iii. Pattern never explains solution to particular problem. Every Problem gives solution by implementing components and their relationships. Patterns are a means of documenting software architectures. i. Pattern helps in design software architectures. ii. Pattern helps in easily modify/ extend original architecture. iii. Eg: MVC, u also know how to extend it with a new function. Patterns the construction of software with defined properties. i. Pattern gives skeleton of functional behavior ii. Pattern gives implementation of the functionality of the application. iii. It also explains about non-functionality requirements for software systems--changeability, reusability, testability, reliability… iv. Does MVC changeability, reusability of the system? Patterns help you build complex and heterogeneous software architectures i. Predefined design artifacts the speed & quality of design. ii. Understanding and applying well written patterns saves the time when compared to searching for the solutions. iii. A pattern gives the basic structure of the solution to a particular design problem; it does not specify a fully detailed solution. Patterns help you to manage software complexity No need to waste time inventing a new solution to your problem. Pattern gives solution to most of the problem and reduces the complexity of the software. But, Patterns do not: provide an exact solution provide complete solutions solve all design problems
What is pattern? How it is categorized?-------------------10M Pattern Categories We group patterns into three categories:
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 5
DESIGN PATTERNS-I
Architectural patterns Architectural patterns are used to describe viable software architectures that are built according to some overall structuring principle. Definition: An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. Eg: Model-view-controller pattern. Design patterns Design patterns are used to describe subsystems of a software architecture as well as the relationships between them (which usually consists of several smaller architectural units) Definition: A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly-recurring structure of communicating components that solves a general design problem within a particular Context. They are medium-scale patterns. They are smaller in scale than architectural patterns, but tend to be independent of a particular programming language or programming paradigm. Eg: Publisher-Subscriber pattern. Idioms Idioms deals with the implementation of particular design issues. Definition: An idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language. Idioms represent the lowest- level patterns. They address aspects of both design and implementation. Eg: counted body pattern. Relationships between patterns A pattern solves a particular problem, but its application may raise new problems. Some of these can be solved by other patterns. Example1: refinement of the MVC pattern In MVC Model has core functionality and it s adaptable interface When the State of model changes controller updates all its dependent views. We can use Observer pattern to achieve this updation. Example2: document-view of the MVC pattern Variant Of MVC is Document-view pattern Controller+ model component job is done by document component. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 6
DESIGN PATTERNS-I Document component does the functionality of Model & controller (store & implement change propagation mechanism) Example3: transparent peer-to-peer inter-process communication
Used for communication in Distributed applications for High performance peerto-peer inter-process communication. Here we need to consider 2 set of Forces: Time: searching for location of remote server Exchangeable without affecting clients/ servers Client should be able to access service of server without dependent on server location information. Example pattern: forward-receiver & Proxy pattern
Pattern description 1. Name : The name and a short summary of the pattern 2. Also known as: Other names for the pattern, if any are known 3. Example : A real world example demonstrating the existence of the problem and the need for the pattern 4. Context : The situations in which the patterns may apply 5. Problem : The problem the pattern addresses, including a discussion of its associated forces. 6. Solution : The fundamental solution principle underlying the pattern 7. Structure : A detailed specification of the structural aspects of the pattern, including CRC – cards for each participating component and an OMT class diagram. 8. Dynamics : Typical scenarios describing the run time behavior of the pattern 9. Implementation: Guidelines for implementing the pattern. These are only a suggestion and not a immutable rule. 10. Examples resolved: Discussion for any important aspects for resolving the example that are not yet covered in the solution , structure, dynamics and implementation sections. 11. Variants: A brief description of variants or specialization of a pattern 12. Known uses: Examples of the use of the pattern, taken from existing systems 13. Consequences: The benefits the pattern provides, and any potential liabilities. 14. See Also: References to patterns that solve similar problems, and the patterns that help us refine the pattern we are describing. Give the differences between patterns vs methods.---5M Patterns vs methods Explain Pattern Pattern gives guidelines to implement each component? Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 7
DESIGN PATTERNS-I In implementation each component is implemented as Micro-method to give solution to the problem. Communication patterns: Explain communication patterns.---------------------------10M 1. Forward-receiver 2. Client-dispatcher-server 3. Publisher-subscriber Most of the today’s software systems run on distributed systems. These distributed systems need a means for communication. Problems: -wired into existing applications, leading to various problems. o Difficult to change the communication mechanism later. o Portability o Migration of sub systems from one network node to another is only possible if the communication facility allows it. Solution: uses for communication, eg: by using o Encapsulation o Location transparency We discuss two patterns that addresses these topics: o The Forwarder – Receiver design pattern (provides encapsulation) o The Client – Dispatcher – Server design pattern (provides location transparency) Forwarder-Receiver The Forwarder-Receiver design pattern provides transparent inter - process communication for software systems with a peer-to-peer interaction model. It introduces forwarders and receivers to decouple peers from the underlying communication mechanisms. Client-Dispatcher-Server
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 8
DESIGN PATTERNS-I The Client-Dispatcher-Server design pattern introduces an intermediate layer between clients and servers, the dispatcher component. It provides location transparency by means of a name service, and hides the details of the establishment of the communication connection between clients and servers. Keeping cooperating component consistent is another problem in communication. We discuss one pattern that addresses this issue: The Publisher – Subscriber pattern The Publisher-Subscriber design pattern helps to keep the state of cooperating components synchronized. To achieve this it enables one-way propagation of changes: one publisher notifies any number of subscribers about changes to its state.
Forwarder-Receiver Name: Forwarder-Receiver The Forwarder-Receiver design pattern provides transparent inter - process communication for software systems with a peer-to-peer interaction model. It introduces forwarders and receivers to decouple peers from the underlying communication mechanisms. Example: real-world example •
The company DwarfWare offers applications for the management of the computer networks.
•
System consists of agent processes written in Java that run on each available network node.
•
These agents are responsible for observing and monitoring the resources. Also they allow modifying the routing tables.
•
During Exchange of information each agent act as client or server as required. •
The communication between the peers must not depend on a particular mechanism for inter-process communication.
•
Provide location transparency (applications to access remote components without any knowledge of their physical location)
Context: Peer-to-peer communication.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 9
DESIGN PATTERNS-I Problem: •
Distributed applications can use low level IPC mechanisms(T/IP, sockets or message queues) or Higher level mechanisms--RPC
•
But Low level mechanisms are OS & network protocol dependent.
The Forwarder-Receiver pattern: balance the following forces: 1. Encapsulation : The system should allow the exchangeability of the communication mechanisms. 2. Location transparency: The cooperation of components follows a peer-to-peer model--sender only needs to know the names of its receivers. 3. The communication between peers should not have a major impact on performance. Solution: Peers may act as clients or servers. Therefore the details of the underlying IPC mechanisms for sending or receiving messages are hidden from peers by encapsulating all system-specific functionality into separate components. system specific functionalities are the mapping of names to physical locations, the establishment of communication channels and marshaling and unmarshaling messages. Structure Forwarders, receivers and peers are agents. Each peer knows the names of the remote peers with which it needs to communicate. It uses a forwarder to send a message to other peers and a receiver to receive the messages from other peers. The different types of messages that can be ed between the two peers are command messages, information messages and response messages. o Command messages are related to implementation process. For instance, changing of routing tables of host machine is a command message. o information messages: data on network resources and network events. o Response messages: acknowledgement details such as, the arrival of a message. Peer pattern 1) Continuously monitor network events and resources. 2) Listen for incoming messages from remote agents. 3) Each agent may connect to any other agent to exchange information and requests. 4) The network management infrastructure connects the network ’s console with all other agents. 5) s may send requests to network agents or retrieve messages from them by using available network istration tools. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 10
DESIGN PATTERNS-I
Forwarder pattern 1) Sends messages across process boundaries. 2) Provides a general interface that is an abstraction of a particular IPC mechanism. 3) Includes functionality for marshaling and delivery of messages. 4) Contains a mapping from names to physical addresses. 5) Determines the physical location of the recipient by using its nameto-addresses mapping. 6) In the transmitted message, the forwarder specifies its own peer, so that remote peer is able to send a response to the message originator.
Receiver pattern 1) Wait for incoming messages on behalf of their agent process. 2) As soon as the message arrives, they convert the received data stream into a general message format and forward the message to their agent process.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 11
DESIGN PATTERNS-I
Explain forward-receiver design pattern with the help of OMT.------12M The static relationships in the Forwarder-Receiver design pattern are shown in the diagram(OMT) below. • • • • • •
To send a message to a remote peer, the peer invokes the method sendMsg of its forwarder, ing the message as an argument. The method sendMsg must convert messages to a format that the underlying IPC mechanism understands. For this purpose, it calls marshal. sendMsg uses deliver to transmit the IPC message data to a remote receiver. When the peer wants to receive a message from a remote peer, it invokes the receiveMsg method of its receiver After message reception receiveMsg calls unmarshal (convert messages to a format that the underlying IPC mechanism understands) receiveMsg invokes receive. Receive then sends response message from remote receiver to peer.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 12
DESIGN PATTERNS-I
Dynamics Two peers p1 and p2 communicate with each other as shown in figure 11. P1 uses a forwarder Forw1 and receiver Recv1. P2 handles all message transfers with a forwarder Forw2 and a receiver Recv2. 1) P1 requests a service from a peer P2. It sends the request to its forwarder Forw1 and specifies the name of the recipient. 2) Forw1 determines the physical location of the remote peer and marshals the message. 3) Forw1 delivers the message to the remote receiver Recv2. 4) P2 would have requested its receiver Recv2 to wait for an incoming request. Recv2 receives the message arriving from Forw1. 5) Recv2 unmarshals the message and forwards it to its peer P2. 6) P1 calls its receiver Recv1 to wait for response. 7) P2 performs the requested service and sends the result and the name of the recipient P1 to the forwarder Forw2. The forwarder marshals the result and deliver it to Recv1. 8) Recv1 receives the response from P2, unmarshals it and delivers it to P1.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 13
DESIGN PATTERNS-I
Implementation 1. The first step is to specify a name-to–address mapping catalog. The name of the system can be maintained with a convention. The actual physical address of the peer has to be mapped to name of the peer. Peers reference other peers by name, namespace should be created. A namespace defines rules and constraints to which names must confirm in a given context. A name does not necessarily refer to single address. It may refer to a group of addresses. For instance, name can be stated as peer VideoServer. The naming convention is of 15characters and starts with capital letter. The alternative naming convention can be structure names as pathnames. For instance, ‘/Server/VideoServer/AVIServer’ 2. Specify the message protocols to be used between peers and forwarders. The message protocols to be used between peers and forwarders should be specified. Protocol defines the detailed structure of message data a forwarder receives from its peer. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 14
DESIGN PATTERNS-I Data is partitioned into multiple packets. o Messages contain sender and data. o Messages do not contain the name of the recipient. o The name of the recipient is ed by the sender as an extra argument to its forwarder. o Time-out values provided to forwarders and receivers will not block the system when failure of receiving responses arise. 3. The communication mechanism is selected. Low-level mechanisms (T/IP) are efficient and flexible in communication protocols. Low-level mechanisms require more programming and they are platform dependent. High-level mechanisms such as socket programming are platform independent. Sockets are available on most of the operating systems. 4. The forwarder is implemented. The forwarder provides its functionality through a public interface and encapsulates the details of a particular IPC mechanism. The mapping repository is created between names and physical addresses. i. The mapping repository may be static or dynamic. ii. The dynamic repository will provide the updations such as migration at run-time. iii. Forwarder uses this repository to establish the communication link to the remote peer. Forwarder can use private repository or common (global) repository. The repository uses hash table to manage all address mappings. i. The local repository can be implemented, scope of which is within the intranet. ii. The global repository will have one entry of physical address for a peer. It just acts as a look-up table. 5. The receiver is implemented. Receivers run asynchronously. Decision should be made whether the receivers should block until a message arrives. i. Blocking Receivers: Receivers may wait for an incoming message. The control is returned to peer when it receives a message. ii. Non-blocking receivers can be implemented by specifying the time out values. More than one communication channels within receiver can be used. Multiple threads within the receiver can be created. Each thread will be responsible for a particular communication
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 15
DESIGN PATTERNS-I channel. Internal message queues should be used for buffering messages. 6. The peers of application are implemented. Peer acting as clients, send a message to a remote peer and waits for the response. After receiving the response, it continues with its task. Peers acting as servers continuously wait for incoming messages. When such a message arrives, they execute a service that depends on the message they received and send a response back to the originator of the request. For asynchronous communication – one way communication can be implemented. In one-way communication peer sends a message without requiring a response. For synchronous communication – two way communication can be implemented. In two-way communication peer sends a message and waits for response. 7.
A start-up configuration is implemented. A start up routine should create a repository of name-address pairs. Repository can allow different peers to have different name-to-address mapping. Forwarders and receivers must be initialized with a valid name-toaddress mapping. The repository configuration can change dynamically i.e at run-time.
Example Resolved: • The company DwarfWare offers Common protocol to send and receive messages between agents, format of requests, information messages and responses. • Agent request information and is sent to recipient agent. Recipient agent then gives response to the sender agent. • When an agent transmits a command message, the recipient receives the message, interprets it and performs the appropriate command. • Information is displayed on the n/w istration console using GUI in every machine. Variants Forwarder-Receiver without name-to-address mapping: To improve performance issue: remove the mapping from names to physical locations within forwarders and receivers. Now the peers need to tell their forwarder the physical location of the recipient.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 16
DESIGN PATTERNS-I Know uses: 1. The software development toolkit TASC (distributed applications) 2. The material flow control software 3. The ATM-P switching system 4. Distributed Smalltalk environment BrouHaHa. Consequences The Forwarder -Receiver design pattern offers two benefits: 1. Efficient inter-process communication •
Every forwarder of an IPC message knows the physical locations of its receivers.
2. Encapsulation of IPC facilities. •
IPC mechanism dependencies are encapsulated within the forwarders and receivers
•
A change of the underlying IPC mechanism does not affect the peers that communicate with each other.
Liability: No for flexible re-configuration of components. Forwarder-Receiver cannot adapt if distribution of peers change at run-time. The change affects all peers collaborating with the migrated peer. The problem can be solved by adding central dispatcher component for forwarderReceiver pattern.. See also The Client-Dispatcher-Server design pattern provides transparent inter-process communication for software systems in which the distribution of components is not known at compile-time or may vary dynamically at run-time. --------------------------*************-----------------------
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 17
DESIGN PATTERNS-I Client-Dispatcher-Server Explain client-dispatcher- Server design pattern (8M) The Client-Dispatcher-Server design pattern introduces an intermediate layer between clients and servers, the dispatcher component. It provides location transparency by means of a name service, and hides the details of the establishment of the communication connection between clients and servers. Example To develop a software system for the retrieval of new scientific information. The information providers are both on our local network and distributed over the world. To access an individual information provider, it is necessary to specify its location and the service to be executed. When an information provider receives a require a request from client application, it runs the appropriate service and returns the requested information to the client. Context: A software system integrating a set of distributed servers, with the servers running locally or distributed over a network. Problem forces: A component should be able to use a service independent of the location of the service provider. The code implementing the functional core of a service consumer should be separate from the code used to establish a connection with service providers. Solution Dispatcher implements a name service to allow clients to refer the servers by names instead of physical location. Dispatcher is responsible for establishing a communication channel between a client and a server. Each server is uniquely identified by name and is connected to client by dispatcher. Clients rely on dispatcher to locate a particular server and connect. The roles of the server and client can change dynamically. Structure Client: perform domain-specific tasks. Before sending a request to a server, client asks the dispatcher for a communication channel. client uses this channel to communicate with the server. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 18
DESIGN PATTERNS-I Invoke services of servers--- processing tasks
Server: provides a set of operations / service to clients. Server ed with the dispatcher by its name and address.
Dispatcher: Functionality: establishing communication channels between clients and servers--- returns a communication handle to the client. •
Name service: the dispatcher implements functions for ing and locating servers.
•
It takes the name of a server component and maps this name to the physical location of the server component.
•
If the dispatcher cannot initiate a communication link with the requested server, it informs the client about the error it encountered.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 19
DESIGN PATTERNS-I
The static relationships between clients, servers and the dispatcher are as follows:
Explain the dynamics of client-dispatcher- Server design pattern----------------10M Dynamics •
A typical scenario for the Client-Dispatcher-Server design pattern includes the following phases:
•
A server s itself with the dispatcher component ( service).
•
Client (DoTask)
•
At a later time, a client asks the dispatcher for a communication channel to a specified server. (getchannel)
•
The dispatcher looks up the server that is associated with the name specified by the client in its registry. (LocateServer)
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 20
DESIGN PATTERNS-I •
The dispatcher establishes a communication link to the server. (establishChannel)
•
(acceptConnection) If it is able to initiate the connection successfully
•
it returns the communication channel to the client (sendRequest). If not, it sends the client an error message.
•
The client uses the communication channel to send a request directly to the server. (receiveRequest)
•
the server executes the appropriate service (Run service)
•
When the service execution is completed, the server sends the results back to the client.
Implementation Step 1: The applications are separated into client and servers. The sending and receiving transaction logic code are defined. Partitioning applications into clients and server is predefined. Clients may act as servers (vice versa), the roles of clients and servers are not predefined and may change at run-time. Step 2: communication facilities that are required is decided. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 21
DESIGN PATTERNS-I Communication facilities are required for following interactions: 1. Interactions between clients and the dispatcher. 2. Interactions between servers and dispatcher. 3. Interactions between the clients and servers. Different communication mechanism can be used for different interactions. Dispatcher and client will work shared memory if they reside on same machine. Servers and clients get connected using sockets if they reside on different machines. Servers and dispatcher get connected using sockets if they reside on distributed machines. Same communication for all interactions will reduce the complexity of implementation but performance may decrease. Step 3: Interaction protocols between components are specified.
Protocol specify the activities for initializing and maintaining a communication channel, structure of messages being transmitted and structure of data being transmitted. DSprotocol specifies the following: How servers with the dispatcher? The activities that are necessary to establish the communication channel to the server. CDprotocol specifies the following: Interaction that occurs when a client requests dispatcher to establish a connection to server. On the failure of communication link, the dispatcher informs client. Dispatcher may try to establish a communication link several times before it reports an error. CSprotocol specifies the following: The client sends a message to the server using the communication channel previously established between them. Both need to share common knowledge of syntax and semantics of messages they send and receive. Step4: Decide how to name servers. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 22
DESIGN PATTERNS-I Naming of servers should follow some conventions. For instance, the names should uniquely identify the servers. The names should not carry any location information. Example: ID_SERVER_X OR ServerX. The location independent names are mapped to physical locations by the dispatcher. Step 5: Dispatcher is designed and implemented. Dispatcher is located within the address space of the client. Local procedure calls should be used for CDprotocol. For CSprotocol and DSprotocol T ports, sockets or shared memory should be used. Implement registry: A dispatcher includes a registry for mapping server names to their physical locations. You need to consider performance issues. When many clients access many servers using one dispatcher bottleneck(traffic jam)problem can arise in dispatcher, which can be solved using multi-threading in Dispatcher Here one thread handles one request allows handling request in parallel.
Constraints on communication mechanisms: Each server may allocate its own socket. (limit for possible servers) Dispatcher should maintain internal message queues to save client requests. On the arrival of service requests, server opens a new socket and es new socket descriptor to dispatcher. Dispatcher uses the socket descriptor and forwards information to client. After the interaction is completed, server closes socket descriptor. Step 6: The client and server components are implemented .
In one mechanism servers may with dispatcher and in another servers dynamically and un themselves.
Example resolved
T port number and the Internet address of the host machine are combined uniquely to identify the server. Message header is of fixed size and random amount of data is appended. Size and format of data, sender and receiver is provided in the message header. Messages are tagged with sequence numbers to enable to enable receiver of the message to recombine the incoming packets into correct order.
Variants -
Distributed dispatchers Client-dispatcher-server with communication managed by clients
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 23
DESIGN PATTERNS-I -
Client-dispatcher-server with heterogeneous communication. Client-dispatcher-service 1. Distributed dispatchers a. Distributed dispatchers can be used instead of single dispatcher. b. A dispatcher receives a client request on a remote machine. Connection is established with remote dispatcher on the target node. c. Remote dispatcher initiates a connection with the requested server and sends the communication channel back to the first dispatcher (via this to client). d. Clients can also communicate with directly with the dispatcher on the remote machine. 2. Client-dispatcher-server with communication managed by clients. a. Instead of establishing a communication channel to servers, a dispatcher may only return the physical server location to the client. b. It is the responsibility of the client to manage all communication activities with the server. 3. Client-dispatcher-server with heterogeneous communication. a. More than one communication mechanism between server and client can exist such as sockets or named pipes. b. Dispatcher is capable of ing more than one communication mechanism c. Server s itself with dispatcher and specifies the communication mechanism it s. 4. Client -dispatcher –service a. In this pattern clients address services and not servers. b. On the request, the dispatcher looks up which servers provide the specified service in its repository. c. If connection fails dispatcher access another server which provides the same servers.
Known uses: Sun's implementation of Remote procedure Calls (RPC) Uses “Client-Dispatcher-Server with communication managed by clients”. The OMG Corba (Common Object Request Broker Architecture) Consequences Advantages: a. Exchangeability of servers - Change servers and add new servers without modifications to the dispatcher component. (un-, ) b. Location and migration transparency - Servers may be dynamically migrated to other machines, it does not imply any changes to clients. c. Re-configurations - Start-up time and run-time can be specified. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 24
DESIGN PATTERNS-I d. Fault tolerance - On failure, new servers can be activated at a different network node without any impact on clients. Disadvantages: The bottle necks may be faced using client-dispatcher-server pattern are following: a. Lower efficiency is obtained through indirection and explicit connection establishment. i. - Dispatcher’s activity in locating and ing servers and explicitly establishing the connection will lead to overhead. ii. The alternative is to get rid of dispatcher by hard-coding server location into the client. iii. But we will be loosing the exchangeability of servers. b. Sensitivity to change in the interfaces of the dispatcher component. Sensitivity to change in the interface of the dispatcher component, as the dispatcher plays the central role, the software system is sensitive to changes in the interface of the dispatcher. --------------------------******************-------------------------Publisher-subscriber model Explain publisher-subscriber design pattern.--------------------------10M The Publisher-Subscriber design pattern helps to keep the state of cooperating components synchronized. To achieve this it enables one-way propagation of changes: one publisher notifies any number of subscribers about changes to its state. Also known as: Observer, Dependents Context: data changes in one place, but many other components depend on this data. Problem: The solution should balance the following forces: One or more components must be notified about state changes The number and identities of dependent components is not known a priori, or may even change over time.
Explicit polling by dependents for new information is not feasible.
The publisher and its dependents should not be tightly coupled when introducing a change-propagation mechanism. Solution: Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 25
DESIGN PATTERNS-I •
Publisher is a dedicated component (called subject). Subscribers are the components dependent on changes in the publisher. Publisher maintains the registry of subscribers. Publishers changed state is notified to all subscribers. Subscribers retrieve the changed data.
•
All components dependent on changes in the publisher are its subscribers (called observers).
•
Whenever a component need information •
/ subscribe interface offered by the publisher.
•
Un / unsubscribe interface offered by the publisher.
•
The publisher (registry) ----currently ed components.
•
Whenever the publisher changes state, it sends a notification to all its subscribers.
Implementation - Publishers and subscribers shall be depicted by abstract base classes. - Decision of which internal state to be notified for subscribers is made. - An object can be a subscriber to many publishers. - An object can take roles of a publisher and subscriber. - Subscription and the ensuing notification is differentiated according to the event type. This allows subscribers to get needed messages - The publisher send selected details of data change when it notifies its subscribers or can just send a notification and give subscribers the responsibility to find out what changed. Push-model Publisher sends all changed data when it notifies the subscriber.
Pull model
Publisher only sends the minimal information when sending a change notification. Subscribers are responsible for retrieving the data they need.
The subscribers have no choice about if and when they want to retrieve the data.
Very rigid dynamic behavior. Model is not Offers more flexibility by more messages suitable for complex data changes. between publisher and subscribers. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 26
DESIGN PATTERNS-I
Even pushing a package description is a Data changes are found. The process of overhead. finding data changes is organized as a decision tree. This model is best suited when subscribers need the published information most of the The model is used when only the time. individual subscribers can decide if and when they need a specific piece of information.
The variants of publisher – subscriber patterns are: 1. Gatekeeper 2. Event channel 3. Producer-consumer Gatekeeper This pattern is applied for distributed systems. Publisher instance in one process notifies remote subscribers. In the receiving process gatekeeper demultiplexes the messages by surveying the entry points to the process. Gatekeeper notifies subscribers when events for which they ed occur. Event Channel This pattern strongly decouples publishers and subscribers. Subscribers wish to be notified about the occurrences of changes and not about identity of publisher. Publishers are not interested in which components are subscribing. An event channel is created and placed between the publisher and the subscribers. The event channel appears as subscriber for publisher (vice-versa). Implementation - A subscriber s with event channel. - istration instance with proxy publisher is created. - Proxy subscriber is created between a publisher and an event channel as shown in the figure below. - Connection is made over a process boundary with local proxy subscriber. - Publisher, event channel and subscriber all exist in different processes. - Event channel with buffer will provide more decoupling capacity.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 27
DESIGN PATTERNS-I
When messages from a publisher arrive, the event channel does not have to notify the subscribers immediately. Producer-consumer - Producer supplies information. - Consumer accepts information for further processing. - Producer and consumer are strongly decoupled. - A buffer is placed between them. - The producer writes to the buffer without any regard for the consumer. - The consumer reads data from the buffer at its own discretion. - Synchronization is achieved by stating buffer overflow and underflow. - The producer is suspended when the buffer is full. - The consumer waits if the buffer is empty. It should be noted that publisher-subscriber pattern provide many – many relationship for number of components. The producer-consumer pattern provide one-one relationship for number of components. Event-channel + producer-consumer provide more than one producer or consumer. Several producers can provide data by only allowing them to write to the buffer in series. If more than one consumer we can use iterators. When one consumer reads data from the buffer, the event –channel does not delete that data from the buffer, but only marks it as read by the consumer. The consumer is given the illusion that the data is consumed, and hence deleted, while other consumers will be given the illusion that the data is still present and unread.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 28
- 6hrs
• What is a pattern • what makes a pattern? • Pattern categories; • Relationships between patterns; • Pattern description. • Communication Patterns: • Forwarder-Receiver; • Client-Dispatcher-Server; • Publisher-Subscriber. The architect Christopher Alexander defines the term pattern as: Each pattern is a three-part rule, which expresses a relation between a certain context, a problem & a solution. What is pattern? A pattern for software architecture describes a particular recurring design problem that arises in specific design contexts, and presents a well-proven generic scheme for its solution. The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate. What Makes a Pattern? Three-part schema that underlies every pattern: Context: a situation giving rise to a problem. Problem: the recurring problem arising in that context. Solution: a proven resolution of the problem. Context: For eg: “developing software with a human-computer interface”. Specifying the correct context for the problem is difficult. It is practically impossible to determine all situations in which a pattern may be applied. Problem:
Defines problem specification Defines set of forces o The term ‘force denotes any aspect of the problem that should be considered while solving it, such as
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 1
DESIGN PATTERNS-I o Requirements the solution must fulfill o Constraints you must consider o Desirable properties the solution should have. Solution:
In software architectures, such a solution includes two aspects: Every pattern specifies a certain structure, a spatial configuration of elements. It consists of both components and their relationships. Every pattern specifies runtime behavior. This runtime behavior addresses the dynamic aspects of the solution.
Explain the MVC design for software architecture, with OMT (6M) diagram Let us consider software with a human-computer interface. -
The interface is prone to change. To provide the functionality extension will be challenging. Usually interface will be adapted for specific customers. When upgrading an operating system the parameters to provide interface may change. o Changes will increase the cost of development and copies of different implementations have to be saved in memory.
The important aspects of -interface development are: 1. Changes to interface should be easy and possible at run time. 2. Adapting or porting the interface should not impact code in the functional core of the application.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 2
DESIGN PATTERNS-I To solve the problem, divide an interactive application into three areas: processing , output & input.
Basic parts of any application: 1. Data being manipulated by the input events. 2. A -interface through which data manipulation occurs. 3. The data is logically independent from how it is displayed to the . The internal representation of data is different. Model component:
Encapsulates core data & functionality
Independent of specific output representations or input behavior.
View component:
Display information to the
Obtains the data it displays from the model.
There can be multiple views of the model.
Controller component:
Each view has an associated controller component.
Controllers receive input (service request---keyboard input/ mouse click)
-
which are sent either to the model or to the view.
The interacts with the system only via controllers. To achieve clear understanding of model-view-controller, the set-up sequence can be analyzed. The model is initialized. After this the view is initialized. The reference to a controller is made. The controller is the middle component, therefore controller references to both model and view. The updations are only through controller, hence controller s with view. At execution level, view recognizes input event. Input event is data entry or menu selection. View procedure calls appropriate method on controller. Controller procedure accesses model and updates it.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 3
DESIGN PATTERNS-I -
If model has been changed, view is updated (via the controller). With this set-up functional core independency is achieved. We can change from a non-graphical to a graphical interface, without modifying the model subsystem. (Independent of specific ‘look and feel’). We can add a for a new input device without affecting information display or the functional core.
The following OMT class diagram illustrates this solution:
What is pattern? Explain briefly properties of patterns for software architecture----8M Properties of patterns for Software Architecture 1. A pattern addresses a recurring design problem that arises in specific design situations, and presents a solution to it. i. Context: a situation giving rise to a problem. ii. Problem: the recurring problem arising in that context. iii. Solution: a proven resolution of the problem. 2. Patterns document existing, well-proven design experience. Patterns not created artificially but by reusing the design knowledge of several experienced practitioners. Using past experience of practitioners high quality software can be developed. Example MVC pattern for developing interactive applications. 3. Patterns identify & and specify abstractions that are above the level of single classes and instances, or of components. i. A pattern describes several components, classes, objects ii. Every pattern reveals details, responsibilities, relationships and their cooperation between the components. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 4
DESIGN PATTERNS-I
4.
5.
6.
7.
8.
iii. All components together solve the problem that the pattern addresses. iv. Eg: MVC – three cooperating components. Patterns provide a common vocabulary and understanding for design principles i. Every pattern has names eg: MVC ii. Every pattern facilitates effective discussion of design problems and solutions. iii. Pattern never explains solution to particular problem. Every Problem gives solution by implementing components and their relationships. Patterns are a means of documenting software architectures. i. Pattern helps in design software architectures. ii. Pattern helps in easily modify/ extend original architecture. iii. Eg: MVC, u also know how to extend it with a new function. Patterns the construction of software with defined properties. i. Pattern gives skeleton of functional behavior ii. Pattern gives implementation of the functionality of the application. iii. It also explains about non-functionality requirements for software systems--changeability, reusability, testability, reliability… iv. Does MVC changeability, reusability of the system? Patterns help you build complex and heterogeneous software architectures i. Predefined design artifacts the speed & quality of design. ii. Understanding and applying well written patterns saves the time when compared to searching for the solutions. iii. A pattern gives the basic structure of the solution to a particular design problem; it does not specify a fully detailed solution. Patterns help you to manage software complexity No need to waste time inventing a new solution to your problem. Pattern gives solution to most of the problem and reduces the complexity of the software. But, Patterns do not: provide an exact solution provide complete solutions solve all design problems
What is pattern? How it is categorized?-------------------10M Pattern Categories We group patterns into three categories:
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 5
DESIGN PATTERNS-I
Architectural patterns Architectural patterns are used to describe viable software architectures that are built according to some overall structuring principle. Definition: An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. Eg: Model-view-controller pattern. Design patterns Design patterns are used to describe subsystems of a software architecture as well as the relationships between them (which usually consists of several smaller architectural units) Definition: A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly-recurring structure of communicating components that solves a general design problem within a particular Context. They are medium-scale patterns. They are smaller in scale than architectural patterns, but tend to be independent of a particular programming language or programming paradigm. Eg: Publisher-Subscriber pattern. Idioms Idioms deals with the implementation of particular design issues. Definition: An idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language. Idioms represent the lowest- level patterns. They address aspects of both design and implementation. Eg: counted body pattern. Relationships between patterns A pattern solves a particular problem, but its application may raise new problems. Some of these can be solved by other patterns. Example1: refinement of the MVC pattern In MVC Model has core functionality and it s adaptable interface When the State of model changes controller updates all its dependent views. We can use Observer pattern to achieve this updation. Example2: document-view of the MVC pattern Variant Of MVC is Document-view pattern Controller+ model component job is done by document component. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 6
DESIGN PATTERNS-I Document component does the functionality of Model & controller (store & implement change propagation mechanism) Example3: transparent peer-to-peer inter-process communication
Used for communication in Distributed applications for High performance peerto-peer inter-process communication. Here we need to consider 2 set of Forces: Time: searching for location of remote server Exchangeable without affecting clients/ servers Client should be able to access service of server without dependent on server location information. Example pattern: forward-receiver & Proxy pattern
Pattern description 1. Name : The name and a short summary of the pattern 2. Also known as: Other names for the pattern, if any are known 3. Example : A real world example demonstrating the existence of the problem and the need for the pattern 4. Context : The situations in which the patterns may apply 5. Problem : The problem the pattern addresses, including a discussion of its associated forces. 6. Solution : The fundamental solution principle underlying the pattern 7. Structure : A detailed specification of the structural aspects of the pattern, including CRC – cards for each participating component and an OMT class diagram. 8. Dynamics : Typical scenarios describing the run time behavior of the pattern 9. Implementation: Guidelines for implementing the pattern. These are only a suggestion and not a immutable rule. 10. Examples resolved: Discussion for any important aspects for resolving the example that are not yet covered in the solution , structure, dynamics and implementation sections. 11. Variants: A brief description of variants or specialization of a pattern 12. Known uses: Examples of the use of the pattern, taken from existing systems 13. Consequences: The benefits the pattern provides, and any potential liabilities. 14. See Also: References to patterns that solve similar problems, and the patterns that help us refine the pattern we are describing. Give the differences between patterns vs methods.---5M Patterns vs methods Explain Pattern Pattern gives guidelines to implement each component? Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 7
DESIGN PATTERNS-I In implementation each component is implemented as Micro-method to give solution to the problem. Communication patterns: Explain communication patterns.---------------------------10M 1. Forward-receiver 2. Client-dispatcher-server 3. Publisher-subscriber Most of the today’s software systems run on distributed systems. These distributed systems need a means for communication. Problems: -wired into existing applications, leading to various problems. o Difficult to change the communication mechanism later. o Portability o Migration of sub systems from one network node to another is only possible if the communication facility allows it. Solution: uses for communication, eg: by using o Encapsulation o Location transparency We discuss two patterns that addresses these topics: o The Forwarder – Receiver design pattern (provides encapsulation) o The Client – Dispatcher – Server design pattern (provides location transparency) Forwarder-Receiver The Forwarder-Receiver design pattern provides transparent inter - process communication for software systems with a peer-to-peer interaction model. It introduces forwarders and receivers to decouple peers from the underlying communication mechanisms. Client-Dispatcher-Server
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 8
DESIGN PATTERNS-I The Client-Dispatcher-Server design pattern introduces an intermediate layer between clients and servers, the dispatcher component. It provides location transparency by means of a name service, and hides the details of the establishment of the communication connection between clients and servers. Keeping cooperating component consistent is another problem in communication. We discuss one pattern that addresses this issue: The Publisher – Subscriber pattern The Publisher-Subscriber design pattern helps to keep the state of cooperating components synchronized. To achieve this it enables one-way propagation of changes: one publisher notifies any number of subscribers about changes to its state.
Forwarder-Receiver Name: Forwarder-Receiver The Forwarder-Receiver design pattern provides transparent inter - process communication for software systems with a peer-to-peer interaction model. It introduces forwarders and receivers to decouple peers from the underlying communication mechanisms. Example: real-world example •
The company DwarfWare offers applications for the management of the computer networks.
•
System consists of agent processes written in Java that run on each available network node.
•
These agents are responsible for observing and monitoring the resources. Also they allow modifying the routing tables.
•
During Exchange of information each agent act as client or server as required. •
The communication between the peers must not depend on a particular mechanism for inter-process communication.
•
Provide location transparency (applications to access remote components without any knowledge of their physical location)
Context: Peer-to-peer communication.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 9
DESIGN PATTERNS-I Problem: •
Distributed applications can use low level IPC mechanisms(T/IP, sockets or message queues) or Higher level mechanisms--RPC
•
But Low level mechanisms are OS & network protocol dependent.
The Forwarder-Receiver pattern: balance the following forces: 1. Encapsulation : The system should allow the exchangeability of the communication mechanisms. 2. Location transparency: The cooperation of components follows a peer-to-peer model--sender only needs to know the names of its receivers. 3. The communication between peers should not have a major impact on performance. Solution: Peers may act as clients or servers. Therefore the details of the underlying IPC mechanisms for sending or receiving messages are hidden from peers by encapsulating all system-specific functionality into separate components. system specific functionalities are the mapping of names to physical locations, the establishment of communication channels and marshaling and unmarshaling messages. Structure Forwarders, receivers and peers are agents. Each peer knows the names of the remote peers with which it needs to communicate. It uses a forwarder to send a message to other peers and a receiver to receive the messages from other peers. The different types of messages that can be ed between the two peers are command messages, information messages and response messages. o Command messages are related to implementation process. For instance, changing of routing tables of host machine is a command message. o information messages: data on network resources and network events. o Response messages: acknowledgement details such as, the arrival of a message. Peer pattern 1) Continuously monitor network events and resources. 2) Listen for incoming messages from remote agents. 3) Each agent may connect to any other agent to exchange information and requests. 4) The network management infrastructure connects the network ’s console with all other agents. 5) s may send requests to network agents or retrieve messages from them by using available network istration tools. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 10
DESIGN PATTERNS-I
Forwarder pattern 1) Sends messages across process boundaries. 2) Provides a general interface that is an abstraction of a particular IPC mechanism. 3) Includes functionality for marshaling and delivery of messages. 4) Contains a mapping from names to physical addresses. 5) Determines the physical location of the recipient by using its nameto-addresses mapping. 6) In the transmitted message, the forwarder specifies its own peer, so that remote peer is able to send a response to the message originator.
Receiver pattern 1) Wait for incoming messages on behalf of their agent process. 2) As soon as the message arrives, they convert the received data stream into a general message format and forward the message to their agent process.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 11
DESIGN PATTERNS-I
Explain forward-receiver design pattern with the help of OMT.------12M The static relationships in the Forwarder-Receiver design pattern are shown in the diagram(OMT) below. • • • • • •
To send a message to a remote peer, the peer invokes the method sendMsg of its forwarder, ing the message as an argument. The method sendMsg must convert messages to a format that the underlying IPC mechanism understands. For this purpose, it calls marshal. sendMsg uses deliver to transmit the IPC message data to a remote receiver. When the peer wants to receive a message from a remote peer, it invokes the receiveMsg method of its receiver After message reception receiveMsg calls unmarshal (convert messages to a format that the underlying IPC mechanism understands) receiveMsg invokes receive. Receive then sends response message from remote receiver to peer.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 12
DESIGN PATTERNS-I
Dynamics Two peers p1 and p2 communicate with each other as shown in figure 11. P1 uses a forwarder Forw1 and receiver Recv1. P2 handles all message transfers with a forwarder Forw2 and a receiver Recv2. 1) P1 requests a service from a peer P2. It sends the request to its forwarder Forw1 and specifies the name of the recipient. 2) Forw1 determines the physical location of the remote peer and marshals the message. 3) Forw1 delivers the message to the remote receiver Recv2. 4) P2 would have requested its receiver Recv2 to wait for an incoming request. Recv2 receives the message arriving from Forw1. 5) Recv2 unmarshals the message and forwards it to its peer P2. 6) P1 calls its receiver Recv1 to wait for response. 7) P2 performs the requested service and sends the result and the name of the recipient P1 to the forwarder Forw2. The forwarder marshals the result and deliver it to Recv1. 8) Recv1 receives the response from P2, unmarshals it and delivers it to P1.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 13
DESIGN PATTERNS-I
Implementation 1. The first step is to specify a name-to–address mapping catalog. The name of the system can be maintained with a convention. The actual physical address of the peer has to be mapped to name of the peer. Peers reference other peers by name, namespace should be created. A namespace defines rules and constraints to which names must confirm in a given context. A name does not necessarily refer to single address. It may refer to a group of addresses. For instance, name can be stated as peer VideoServer. The naming convention is of 15characters and starts with capital letter. The alternative naming convention can be structure names as pathnames. For instance, ‘/Server/VideoServer/AVIServer’ 2. Specify the message protocols to be used between peers and forwarders. The message protocols to be used between peers and forwarders should be specified. Protocol defines the detailed structure of message data a forwarder receives from its peer. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 14
DESIGN PATTERNS-I Data is partitioned into multiple packets. o Messages contain sender and data. o Messages do not contain the name of the recipient. o The name of the recipient is ed by the sender as an extra argument to its forwarder. o Time-out values provided to forwarders and receivers will not block the system when failure of receiving responses arise. 3. The communication mechanism is selected. Low-level mechanisms (T/IP) are efficient and flexible in communication protocols. Low-level mechanisms require more programming and they are platform dependent. High-level mechanisms such as socket programming are platform independent. Sockets are available on most of the operating systems. 4. The forwarder is implemented. The forwarder provides its functionality through a public interface and encapsulates the details of a particular IPC mechanism. The mapping repository is created between names and physical addresses. i. The mapping repository may be static or dynamic. ii. The dynamic repository will provide the updations such as migration at run-time. iii. Forwarder uses this repository to establish the communication link to the remote peer. Forwarder can use private repository or common (global) repository. The repository uses hash table to manage all address mappings. i. The local repository can be implemented, scope of which is within the intranet. ii. The global repository will have one entry of physical address for a peer. It just acts as a look-up table. 5. The receiver is implemented. Receivers run asynchronously. Decision should be made whether the receivers should block until a message arrives. i. Blocking Receivers: Receivers may wait for an incoming message. The control is returned to peer when it receives a message. ii. Non-blocking receivers can be implemented by specifying the time out values. More than one communication channels within receiver can be used. Multiple threads within the receiver can be created. Each thread will be responsible for a particular communication
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 15
DESIGN PATTERNS-I channel. Internal message queues should be used for buffering messages. 6. The peers of application are implemented. Peer acting as clients, send a message to a remote peer and waits for the response. After receiving the response, it continues with its task. Peers acting as servers continuously wait for incoming messages. When such a message arrives, they execute a service that depends on the message they received and send a response back to the originator of the request. For asynchronous communication – one way communication can be implemented. In one-way communication peer sends a message without requiring a response. For synchronous communication – two way communication can be implemented. In two-way communication peer sends a message and waits for response. 7.
A start-up configuration is implemented. A start up routine should create a repository of name-address pairs. Repository can allow different peers to have different name-to-address mapping. Forwarders and receivers must be initialized with a valid name-toaddress mapping. The repository configuration can change dynamically i.e at run-time.
Example Resolved: • The company DwarfWare offers Common protocol to send and receive messages between agents, format of requests, information messages and responses. • Agent request information and is sent to recipient agent. Recipient agent then gives response to the sender agent. • When an agent transmits a command message, the recipient receives the message, interprets it and performs the appropriate command. • Information is displayed on the n/w istration console using GUI in every machine. Variants Forwarder-Receiver without name-to-address mapping: To improve performance issue: remove the mapping from names to physical locations within forwarders and receivers. Now the peers need to tell their forwarder the physical location of the recipient.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 16
DESIGN PATTERNS-I Know uses: 1. The software development toolkit TASC (distributed applications) 2. The material flow control software 3. The ATM-P switching system 4. Distributed Smalltalk environment BrouHaHa. Consequences The Forwarder -Receiver design pattern offers two benefits: 1. Efficient inter-process communication •
Every forwarder of an IPC message knows the physical locations of its receivers.
2. Encapsulation of IPC facilities. •
IPC mechanism dependencies are encapsulated within the forwarders and receivers
•
A change of the underlying IPC mechanism does not affect the peers that communicate with each other.
Liability: No for flexible re-configuration of components. Forwarder-Receiver cannot adapt if distribution of peers change at run-time. The change affects all peers collaborating with the migrated peer. The problem can be solved by adding central dispatcher component for forwarderReceiver pattern.. See also The Client-Dispatcher-Server design pattern provides transparent inter-process communication for software systems in which the distribution of components is not known at compile-time or may vary dynamically at run-time. --------------------------*************-----------------------
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 17
DESIGN PATTERNS-I Client-Dispatcher-Server Explain client-dispatcher- Server design pattern (8M) The Client-Dispatcher-Server design pattern introduces an intermediate layer between clients and servers, the dispatcher component. It provides location transparency by means of a name service, and hides the details of the establishment of the communication connection between clients and servers. Example To develop a software system for the retrieval of new scientific information. The information providers are both on our local network and distributed over the world. To access an individual information provider, it is necessary to specify its location and the service to be executed. When an information provider receives a require a request from client application, it runs the appropriate service and returns the requested information to the client. Context: A software system integrating a set of distributed servers, with the servers running locally or distributed over a network. Problem forces: A component should be able to use a service independent of the location of the service provider. The code implementing the functional core of a service consumer should be separate from the code used to establish a connection with service providers. Solution Dispatcher implements a name service to allow clients to refer the servers by names instead of physical location. Dispatcher is responsible for establishing a communication channel between a client and a server. Each server is uniquely identified by name and is connected to client by dispatcher. Clients rely on dispatcher to locate a particular server and connect. The roles of the server and client can change dynamically. Structure Client: perform domain-specific tasks. Before sending a request to a server, client asks the dispatcher for a communication channel. client uses this channel to communicate with the server. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 18
DESIGN PATTERNS-I Invoke services of servers--- processing tasks
Server: provides a set of operations / service to clients. Server ed with the dispatcher by its name and address.
Dispatcher: Functionality: establishing communication channels between clients and servers--- returns a communication handle to the client. •
Name service: the dispatcher implements functions for ing and locating servers.
•
It takes the name of a server component and maps this name to the physical location of the server component.
•
If the dispatcher cannot initiate a communication link with the requested server, it informs the client about the error it encountered.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 19
DESIGN PATTERNS-I
The static relationships between clients, servers and the dispatcher are as follows:
Explain the dynamics of client-dispatcher- Server design pattern----------------10M Dynamics •
A typical scenario for the Client-Dispatcher-Server design pattern includes the following phases:
•
A server s itself with the dispatcher component ( service).
•
Client (DoTask)
•
At a later time, a client asks the dispatcher for a communication channel to a specified server. (getchannel)
•
The dispatcher looks up the server that is associated with the name specified by the client in its registry. (LocateServer)
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 20
DESIGN PATTERNS-I •
The dispatcher establishes a communication link to the server. (establishChannel)
•
(acceptConnection) If it is able to initiate the connection successfully
•
it returns the communication channel to the client (sendRequest). If not, it sends the client an error message.
•
The client uses the communication channel to send a request directly to the server. (receiveRequest)
•
the server executes the appropriate service (Run service)
•
When the service execution is completed, the server sends the results back to the client.
Implementation Step 1: The applications are separated into client and servers. The sending and receiving transaction logic code are defined. Partitioning applications into clients and server is predefined. Clients may act as servers (vice versa), the roles of clients and servers are not predefined and may change at run-time. Step 2: communication facilities that are required is decided. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 21
DESIGN PATTERNS-I Communication facilities are required for following interactions: 1. Interactions between clients and the dispatcher. 2. Interactions between servers and dispatcher. 3. Interactions between the clients and servers. Different communication mechanism can be used for different interactions. Dispatcher and client will work shared memory if they reside on same machine. Servers and clients get connected using sockets if they reside on different machines. Servers and dispatcher get connected using sockets if they reside on distributed machines. Same communication for all interactions will reduce the complexity of implementation but performance may decrease. Step 3: Interaction protocols between components are specified.
Protocol specify the activities for initializing and maintaining a communication channel, structure of messages being transmitted and structure of data being transmitted. DSprotocol specifies the following: How servers with the dispatcher? The activities that are necessary to establish the communication channel to the server. CDprotocol specifies the following: Interaction that occurs when a client requests dispatcher to establish a connection to server. On the failure of communication link, the dispatcher informs client. Dispatcher may try to establish a communication link several times before it reports an error. CSprotocol specifies the following: The client sends a message to the server using the communication channel previously established between them. Both need to share common knowledge of syntax and semantics of messages they send and receive. Step4: Decide how to name servers. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 22
DESIGN PATTERNS-I Naming of servers should follow some conventions. For instance, the names should uniquely identify the servers. The names should not carry any location information. Example: ID_SERVER_X OR ServerX. The location independent names are mapped to physical locations by the dispatcher. Step 5: Dispatcher is designed and implemented. Dispatcher is located within the address space of the client. Local procedure calls should be used for CDprotocol. For CSprotocol and DSprotocol T ports, sockets or shared memory should be used. Implement registry: A dispatcher includes a registry for mapping server names to their physical locations. You need to consider performance issues. When many clients access many servers using one dispatcher bottleneck(traffic jam)problem can arise in dispatcher, which can be solved using multi-threading in Dispatcher Here one thread handles one request allows handling request in parallel.
Constraints on communication mechanisms: Each server may allocate its own socket. (limit for possible servers) Dispatcher should maintain internal message queues to save client requests. On the arrival of service requests, server opens a new socket and es new socket descriptor to dispatcher. Dispatcher uses the socket descriptor and forwards information to client. After the interaction is completed, server closes socket descriptor. Step 6: The client and server components are implemented .
In one mechanism servers may with dispatcher and in another servers dynamically and un themselves.
Example resolved
T port number and the Internet address of the host machine are combined uniquely to identify the server. Message header is of fixed size and random amount of data is appended. Size and format of data, sender and receiver is provided in the message header. Messages are tagged with sequence numbers to enable to enable receiver of the message to recombine the incoming packets into correct order.
Variants -
Distributed dispatchers Client-dispatcher-server with communication managed by clients
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 23
DESIGN PATTERNS-I -
Client-dispatcher-server with heterogeneous communication. Client-dispatcher-service 1. Distributed dispatchers a. Distributed dispatchers can be used instead of single dispatcher. b. A dispatcher receives a client request on a remote machine. Connection is established with remote dispatcher on the target node. c. Remote dispatcher initiates a connection with the requested server and sends the communication channel back to the first dispatcher (via this to client). d. Clients can also communicate with directly with the dispatcher on the remote machine. 2. Client-dispatcher-server with communication managed by clients. a. Instead of establishing a communication channel to servers, a dispatcher may only return the physical server location to the client. b. It is the responsibility of the client to manage all communication activities with the server. 3. Client-dispatcher-server with heterogeneous communication. a. More than one communication mechanism between server and client can exist such as sockets or named pipes. b. Dispatcher is capable of ing more than one communication mechanism c. Server s itself with dispatcher and specifies the communication mechanism it s. 4. Client -dispatcher –service a. In this pattern clients address services and not servers. b. On the request, the dispatcher looks up which servers provide the specified service in its repository. c. If connection fails dispatcher access another server which provides the same servers.
Known uses: Sun's implementation of Remote procedure Calls (RPC) Uses “Client-Dispatcher-Server with communication managed by clients”. The OMG Corba (Common Object Request Broker Architecture) Consequences Advantages: a. Exchangeability of servers - Change servers and add new servers without modifications to the dispatcher component. (un-, ) b. Location and migration transparency - Servers may be dynamically migrated to other machines, it does not imply any changes to clients. c. Re-configurations - Start-up time and run-time can be specified. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 24
DESIGN PATTERNS-I d. Fault tolerance - On failure, new servers can be activated at a different network node without any impact on clients. Disadvantages: The bottle necks may be faced using client-dispatcher-server pattern are following: a. Lower efficiency is obtained through indirection and explicit connection establishment. i. - Dispatcher’s activity in locating and ing servers and explicitly establishing the connection will lead to overhead. ii. The alternative is to get rid of dispatcher by hard-coding server location into the client. iii. But we will be loosing the exchangeability of servers. b. Sensitivity to change in the interfaces of the dispatcher component. Sensitivity to change in the interface of the dispatcher component, as the dispatcher plays the central role, the software system is sensitive to changes in the interface of the dispatcher. --------------------------******************-------------------------Publisher-subscriber model Explain publisher-subscriber design pattern.--------------------------10M The Publisher-Subscriber design pattern helps to keep the state of cooperating components synchronized. To achieve this it enables one-way propagation of changes: one publisher notifies any number of subscribers about changes to its state. Also known as: Observer, Dependents Context: data changes in one place, but many other components depend on this data. Problem: The solution should balance the following forces: One or more components must be notified about state changes The number and identities of dependent components is not known a priori, or may even change over time.
Explicit polling by dependents for new information is not feasible.
The publisher and its dependents should not be tightly coupled when introducing a change-propagation mechanism. Solution: Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 25
DESIGN PATTERNS-I •
Publisher is a dedicated component (called subject). Subscribers are the components dependent on changes in the publisher. Publisher maintains the registry of subscribers. Publishers changed state is notified to all subscribers. Subscribers retrieve the changed data.
•
All components dependent on changes in the publisher are its subscribers (called observers).
•
Whenever a component need information •
/ subscribe interface offered by the publisher.
•
Un / unsubscribe interface offered by the publisher.
•
The publisher (registry) ----currently ed components.
•
Whenever the publisher changes state, it sends a notification to all its subscribers.
Implementation - Publishers and subscribers shall be depicted by abstract base classes. - Decision of which internal state to be notified for subscribers is made. - An object can be a subscriber to many publishers. - An object can take roles of a publisher and subscriber. - Subscription and the ensuing notification is differentiated according to the event type. This allows subscribers to get needed messages - The publisher send selected details of data change when it notifies its subscribers or can just send a notification and give subscribers the responsibility to find out what changed. Push-model Publisher sends all changed data when it notifies the subscriber.
Pull model
Publisher only sends the minimal information when sending a change notification. Subscribers are responsible for retrieving the data they need.
The subscribers have no choice about if and when they want to retrieve the data.
Very rigid dynamic behavior. Model is not Offers more flexibility by more messages suitable for complex data changes. between publisher and subscribers. Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 26
DESIGN PATTERNS-I
Even pushing a package description is a Data changes are found. The process of overhead. finding data changes is organized as a decision tree. This model is best suited when subscribers need the published information most of the The model is used when only the time. individual subscribers can decide if and when they need a specific piece of information.
The variants of publisher – subscriber patterns are: 1. Gatekeeper 2. Event channel 3. Producer-consumer Gatekeeper This pattern is applied for distributed systems. Publisher instance in one process notifies remote subscribers. In the receiving process gatekeeper demultiplexes the messages by surveying the entry points to the process. Gatekeeper notifies subscribers when events for which they ed occur. Event Channel This pattern strongly decouples publishers and subscribers. Subscribers wish to be notified about the occurrences of changes and not about identity of publisher. Publishers are not interested in which components are subscribing. An event channel is created and placed between the publisher and the subscribers. The event channel appears as subscriber for publisher (vice-versa). Implementation - A subscriber s with event channel. - istration instance with proxy publisher is created. - Proxy subscriber is created between a publisher and an event channel as shown in the figure below. - Connection is made over a process boundary with local proxy subscriber. - Publisher, event channel and subscriber all exist in different processes. - Event channel with buffer will provide more decoupling capacity.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 27
DESIGN PATTERNS-I
When messages from a publisher arrive, the event channel does not have to notify the subscribers immediately. Producer-consumer - Producer supplies information. - Consumer accepts information for further processing. - Producer and consumer are strongly decoupled. - A buffer is placed between them. - The producer writes to the buffer without any regard for the consumer. - The consumer reads data from the buffer at its own discretion. - Synchronization is achieved by stating buffer overflow and underflow. - The producer is suspended when the buffer is full. - The consumer waits if the buffer is empty. It should be noted that publisher-subscriber pattern provide many – many relationship for number of components. The producer-consumer pattern provide one-one relationship for number of components. Event-channel + producer-consumer provide more than one producer or consumer. Several producers can provide data by only allowing them to write to the buffer in series. If more than one consumer we can use iterators. When one consumer reads data from the buffer, the event –channel does not delete that data from the buffer, but only marks it as read by the consumer. The consumer is given the illusion that the data is consumed, and hence deleted, while other consumers will be given the illusion that the data is still present and unread.
Divya, Asst. Professor, ISE dept., VCET, Puttur
Page 28
Related Documents 171j1w
Unit4 Notes 1s4e21
February 2023 0
Unit4 Database 1z40c
December 2021 0
Unit4 Ad Java 271nl
December 2019 38
Mms9 Workbook 04 Unit4 5d6c21
December 2020 0
Ace3 Unit4 Test j301r
August 2020 0
Chemology Physics Unit4 2011 17km
November 2019 39More Documents from "divya" 264w6i
Now Version Release 1.13.3.5 3x2sm
October 2019 64
1.2 National Income ing.pdf 73131n
November 2021 0
Amul- The Taste Of India 4c6n5h
December 2019 65
Unit4 Notes 1s4e21
February 2023 0
Economizer Coil 2t236w
December 2019 82