1715595 - PowerPoint Presentation

Presented by Sushma Narasimhan Asst. Professor, Computer Science Department Engineered for Tomorrow Unit- 5 ARCHITECTURAL PATTERNS - II

Unit-VDistributed Systems BrokerInteractive Systems Model-View-Controller(MVC) Presentation-Abstraction-Control(PAC)

Distributed SystemQ: What are distributed systems? Why do we need them?A: A distributed system is a collection of independent computers, that appears to its users, as a single coherent system.Advantages of having distributed systems:Economics - Computer networks that incorporate both PCs and workstations offer a better price/performance ratio than mainframe computers. ii) Performance and Scalability - A huge increase in performance can be gained by using the combined computing power of several network nodes. In addition, multiprocessors and networks are easily scalable.

Contd..iii) Inherent distribution - Some applications are inherently distributed, such as database applications that follow a Client-Server model.iv) Reliability - In most cases, a machine on a network or a CPU in a multiprocessor system can crash without affecting the rest of the system.

Contd..Drawbacks of Distributed systemsi) Distributed systems need radically different software than do centralized systems.This is the major technical reason why consortia such as the Object Management Group (OMG) and companies such as Microsoft have developed their own technologies for distributed computing.

Unit-VDistributed Systems BrokerInteractive Systems Model-View-Controller(MVC) Presentation-Abstraction-Control(PAC)

BrokerPattern DefinitionExample ResolvedContextProblemSolutionStructureDynamicsImplementationVariantsKnown UsesConsequences

BrokerDefinitionThe Broker architectural pattern can be used to structure distributed software systems with decoupled components that interact by remote service invocations.A broker component is responsible for co-ordinating communication, such as forwarding requests, as well as for transmitting results and exceptions.

Users of Broker patternQ: Who benefits from using Broker pattern?A: There are three groups of developers who can benefit by using the Broker pattern : i) Those working with an existing Broker system who are interested in understanding the architecture of such systems. ii)Those who want to build 'lean' versions of a Broker system, without all the bells and whistles of a full-blown OLE or CORBA. iii)Those who plan to implement a fully-fledged Broker system.

Broker Pattern - ExampleSuppose we are developing a city information system (CIS) designed to run on a wide area network. Some computers in the network host one or more services that maintain information about events, restaurants. hotels, historical monuments or public transportation.Computer terminals are connected to the network. Tourists throughout the city can retrieve information in which they are interested from the terminals using a World Wide Web (WWW) browser. This front-end software supports the on-line retrieval of information from the appropriate servers and its display on the screen.

Contd..The data is distributed across the network and is not maintained in the terminals. Fig: City Information System

Contd..Since the system changes and grows continuously, the individual services should be decoupled from each other. In addition. the terminal software should be able to access services without having to know their location. One solution is to install a separate network that connects all terminals and servers, leading to an intranet system.However, not every information provider wants to connect to a closed intranet, and available services should also be accessible from all over the world. We therefore decide to use the Internet as a better means of implementing the CIS system.

Broker- Context & ProblemContextThe environment is a distributed and possibly heterogeneous system with independent co-operating components.ProblemBuilding a complex software system as a set of decoupled and interoperating components, rather than as a monolithic application, results in greater flexibility, maintainability and changeability.However, when distributed components communicate with eachother, some means of inter-process communication is required.If components handle communication themselves, the resulting system faces several dependencies and limitations.

Contd..Services for adding, removing, exchanging, activating and locating components are also needed. Applications that use these services should not depend on system-specific details to guarantee portability and interoperability.An application that uses an object should only see the interface offered by the object. It should not need to know anything about the implementation details of an object, or about its physical location.

Contd..Use the Broker architecture to balance the following forces: i) Components should be able to access services provided by others through remote, location-transparent service invocations. ii) You need to exchange, add, or remove components at run-time. iii)The architecture should hide system- and implementation-specific details from the users of components and services.

Broker - SolutionIn the broker architecture, servers register themselves with the broker, and make their services available to clients through method interfaces. Clients access the functionality of servers by sending requests via the broker. A broker's tasks include - locating the appropriate server - forwarding the request to the server - transmitting results and exceptions back to the client.

Contd..Additionally, the broker architecture is flexible, in that it allows dynamic change, addition, deletion, and relocation of objects. The Broker pattern reduces the complexity involved in developing distributed applications, by introducing an object model in which distributed services are encapsulated within objects.They also extend object models from single applications to distributed applications consisting of decoupled components that can run on heterogeneous machines and can be written in different programming languages.

Structure of BrokerThe Broker architectural pattern comprises six types of participating components:ClientsServersBrokersBridgesClient-side proxies Server-side proxies

Contd..i) Server - A server implements objects that expose their functionality through interfaces that consist of operations and attributes.These interfaces are made available either through an interface definition language (IDL) or through a binary standard. There are two kinds of servers: i) Servers offering common services to many application domains. ii) Servers implementing specific functionality for a single application domain or task.

Contd..Example: WWW servers provide access to HTML (Hypertext Markup Language) pages.When a request arrives at the server, the requested document and any additional data is sent to the client using data streams.ii) Client Applications that access the services of at least one server.To call remote services, clients forward requests to the broker. After an operation has executed, they receive responses or exceptions from the broker.

Contd..The interaction between clients and servers is based on a dynamic model, which means that servers may also act as clients.In the context of the Broker pattern, the clients are the available WWW browsers. They are not directly connected to the network.Instead, they rely on Internet providers that offer gateways to the Internet, such as Compuserve.WWW browsers connect to these workstations, using either a modem or a leased line.

Contd..iii) Broker Is a messenger that is responsible for the transmission of requests from clients to servers, as well as the transmission of responses and exceptions back to the client.

Contd..A broker offers APIs (Application Programming Interfaces) to clients and servers that include operations for registering servers and for invoking server methods. When a request arrives for a server that is maintained by the local broker, the broker passes the request directly to the server.If the specified server is hosted by another broker, the local broker finds a route to the remote broker and forwards the request using this route. There is therefore a need for brokers to interoperate.A broker in our CIS example is the combination of an Internet gateway and the Internet infrastructure itself.

Contd..A client specifies the information it wants using unique identifiers called URLs (Universal Resource Locators). By using these identifiers the broker is able to locate the required services and to route the requests to the appropriate server machines. When a new server machine is added, it must be registered with the broker.

Contd..iv) Client side proxies - represent a layer between clients and the broker.This additional layer provides transparency, in that a remote object appears to the client as a local one. In detail, the proxies allow the hiding of implementation details from the clients such as: The inter-process communication mechanism used for message transfers between clients and brokers The creation and deletion of memory blocks The marshaling of parameters and results

Contd..v) Server side proxies - are generally analogous to Client-side proxies. The difference is that they are responsible for receiving requests, unpacking incoming messages, un-marshaling the parameters, and calling the appropriate service. Additionally, they are used for marshaling results and exceptions before sending them to the client.

Contd..In our CIS example, the WWW browsers and httpd servers such as Netscape provide built-in capabilities for communicating with the gateway of the Internet provider.So we do not need to worry about proxies in this case.

Contd..v) Bridges - are optional components used for hiding implementation details when two brokers interoperate. Suppose a Broker system runs on a heterogeneous network. If requests are transmitted over the network, different brokers have to communicate independently of the different network and operating systems in use.A bridge builds a layer that encapsulates all these system-specfic details.

Contd.. Bridges are not required in our CIS example, because all httpd servers and WWW browsers implement the protocols necessary for remote data exchange such as http or f tp.

Contd..Types of Broker systemsThere are two different kinds of Broker systems: those using direct communication and those using indirect communication. To achieve better performance, some broker implementations only establish the initial communication link between a client and a server, while the rest of the communication is done directly between participating components.Messages, exceptions and responses are transferred between client-side proxies and server-side proxies without using the broker as an intermediate layer. This direct communication approach requires that servers and clients use and understand the same protocol. In indirect broker variant, all messages are passed through the broker.

Contd..Fig: Objects involved in a Broker system Our CIS example implements the indirect communication variant, because browsers and servers can only collaborate using Internet gateways

Dynamics of Broker PatternScenario I - illustrates the behavior when a server registers itself with the local broker component:

Contd..The broker is started in the initialization phase of the system. The broker enters its event loop and waits for incoming messages. The user, or some other entity, starts a server application. First, the server executes its initialization code. After initialization is complete, the server registers itself with the broker. The broker receives the incoming registration request from the server. It extracts all necessary information from the message and stores it into one or more repositories.

Contd..These repositories are used to locate and activate servers.An acknowledgment is sent back. iv)After receiving the acknowledgment from the broker, the server enters its main loop waiting for incoming client requests.

Contd..Scenario II - illustrates the behavior when a client sends a request to a local server. In this scenario we describe a synchronous invocation, in which the client blocks until it gets a response from the server.

Contd..i) The client application is started.ii) The client-side proxy packages all parameters and other relevant information into a message and forwards this message to the local broker.iii) The broker looks up the location of the required server in its repositories. Since the server is available locally, the broker forwards the message to the corresponding server-side proxy. iv)In a remote server, the server-side proxy unpacks all parameters and other information, such as the method it is expected to call. The server-side proxy invokes the appropriate service.

Contd..v) After the service execution is complete, the server returns the result to the server-side proxy.The server side proxy packages it into a message with other relevant information and passes it to the broker. vi)The broker forwards the response to the client-side proxy.vii)The client-side proxy receives the response, unpacks the result and returns to the client application. The client process continues with its computation.

Contd..Scenario III - illustrates the interaction of different brokers via bridge components:

Contd..Broker A receives an incoming request. It locates the server responsible for executing the specified service by looking it up in the repositories. Since the corresponding server is available at another network node, the broker forwards the request to a remote broker. ii) The message is passed from Broker A to Bridge A. This component is responsible for converting the message from the protocol defined by Broker A to a network-specific protocol understood by the two participating bridges. After message conversion, Bridge A transmits the message to Bridge B.

Contd..iii) Bridge B maps the incoming request from the network-specific format to a Broker B-specific format.iv) Broker B performs all the actions necessary when a request arrives, as described in the first step of this scenario.

Implementation of BrokerTo implement the Broker pattern, carry out the following steps: 1. Define an object model, or use an existing modelChoice of the object model has a major impact on all other parts of the system under development.Each object model must specify entities such as object names, objects, requests, values, exceptions, supported types, type extensions, interfaces and operations. For example, specify a basic object model and how it can be refined systematically using extensions.The description of the underlying computational model is a key issue in designing an object model.

Contd..2. Decide which kind of component- interoperability the system should offer.Interoperability can be designed, either by specifying a binary standard or by introducing a high-level interface definition language [IDL). An IDL file contains a textual description of the interfaces a server offers to its clients. The binary approach needs support from the programming language.Broker architecture may define its own protocol for the interaction between the broker and other components.

Contd..3. Specify the APIs the broker component provides for collaborating with clients and serversOn the client side, functionality must be available for constructing requests, passing them to the broker and receiving responses.Decide whether clients should only be able to invoke server operations statically or dynamically.The server implementations use API functions primarily for registering with the broker at run-time.

Contd..4. Use proxy objects to hide implementation details from clients and sewersOn the client side, a local proxy object represents the remote server object called by the client.On the server side, a proxy is used for playing the role of the client. Proxy objects have the following responsibilities: i)Client-side proxies package procedure calls into messages and forward these messages to the local broker component. ii) Server-side proxies receive requests from the local broker and call the methods in the interface implementation of the corresponding server.

Contd..5. Design the broker component in parallel with steps 3 and 4In this step, we describe how to develop a broker component that acts as a messenger for every message passed from a client to a server and vice-versa. During design and implementation, iterate systematically through the following steps: i) Specify a detailed on-the-wire protocol for interacting with client-side proxies and server-side proxies. ii) A local broker must be available for every participating machine in the network.

Contd..iii) When a client invokes a method of a server, the Broker system is responsible for returning all results and exceptions back to the original client.iv) If the proxies do not provide mechanisms for marshaling and un-marshaling parameters and results, you must include that functionality in the broker component. v) If your system supports asynchronous communication between clients and servers, you need to provide message buffers within the broker or within the proxies for the temporary storage of messages. vi) Include a directory service for associating local server identifiers with the physical location of the corresponding servers in the broker.

Contd..vii)When your architecture requires system-unique identifiers to be generated dynamically during server registration, the broker must offer a name service for instantiating such names.viii) If your system supports dynamic method invocation, the broker needs some means for maintaining type information about existing servers. ix) Plan the broker's actions when the communication with clients, other brokers or servers fails.

Contd..6. Develop IDL compilersWhenever you implement interoperability by providing an interface definition language, you need to build an IDL compiler for every programming language you support.

Variants of BrokerDirect Communication Broker SystemIn this variant, clients can communicate with servers directly. The broker tells the clients which communication channel the server provides. The client can then establish a direct link to the requested server. In such systems, the proxies take over the broker's responsibility for handling most of the communication activities.

Contd..2. Message Passing Broker SystemThis variant is suitable for systems that focus on the transmission of data, instead of implementing a Remote ProcedureUsing this variant, servers use the type of a message to determine what they must do, rather than offering services that clients can invoke. In this context, a message is a sequence of raw data together with additional information that - specifies the type of a message - its structure - other relevant attributes

Contd..3. Trader System In a trader system, the broker must know which server(s) can provide the service, and forward the request to an appropriate server. Client-side proxies therefore use service identifiers instead of server identifiers to access server functionality. 4. Adapter Broker SystemThe adapter layer is a part of the broker and is responsible for registering servers and interacting with servers. By supplying more than one adapter, you can support different strategies for server granularity and server location.

Contd..Example: if all the server objects accessed by an application are located on the same machine and are implemented as library objects, a special adapter could be used to link the objects directly to the application.4. Callback Broker SystemInstead of implementing an active communication model in which clients produce requests and servers consume them, you can also use a reactive model. The reactive model is event-driven, and makes no distinction between clients and servers. Whenever an event arrives, the broker invokes the callback method of the component that is registered to react to the event.

Known uses of Broker1. CORBAThe Broker architectural pattern was used to specify the Common Object Request Broker Architecture (CORBA) defined by the Object Management Group. CORBA is an object-oriented technology for distributing objects on heterogeneous systems. 2. IBM SOM/DSOMRepresents a CORBA-compliant Broker system.In contrast to many other CORBA implementations, it implements interoperability by combining the CORBA interface definition language with a binary protocol. You can implement a class in SOM in one programming language and derive a subclass from it in another language.

Contd..3. OLE 2.xMicrosoft's OLE 2.x technology provides another example of the use of the Broker architectural pattern. OLE 2.x defines a binary standard for exposing and accessing server interfaces.4. World Wide WebIs the largest available Broker system in the world. Hypertext browsers such as HotJava , Mosaic, and Netscape act as brokers and WWW servers play the role of service providers.5. ATM-PThis variant is implemented in a Siemens in-house project to build a telecommunication switching system based on ATM.

Consequences of BrokerThe Broker architectural pattern has some important benefits:1. Location TransparencyAs the broker is responsible for locating a server by using a unique identifier, clients do not need to know where servers are located.Similarly, servers need not know about the location of clients, as they receive all requests from the local broker component.

Contd..2. Changeability and extensibility of componentsChanges in the communication mechanisms used for the interaction - between servers and the broker - between clients and the broker - between brokers may require you to recompile clients, servers or brokers.Using proxies and bridges, makes it easy for changes to be implemented.

Contd..3. Portability of a Broker systemThe Broker system hides operating system and network system details from clients and servers by using APIs, proxies and bridges. When porting is required, it is therefore sufficient in most cases to port the broker component and its APIs to a new platform and to recompile clients and servers.4. Interoperability between different Broker systemsDifferent Broker systems may interoperate, if they understand a common protocol for the exchange of messages. This protocol is implemented and handled by bridges.

Contd..5. ReusabilityWhen building new client applications, you can often base the functionality of your application on existing services.If components that offer services such as text editing, visualization, printing, database access or spreadsheets are already available, no need to implement these services.Just integrate them into existing applications.

Contd..The Broker architectural pattern imposes some liabilities:1. Restricted efficiencyApplications using a Broker implementation are usually slower than applications whose component distribution is static and known.Systems that depend directly on a concrete mechanism for inter-process communication perform better than a Broker architecture.

Contd..2. Lower fault toleranceCompared with a non-distributed software system, a Broker system may offer lower fault tolerance. If a server or a broker fails during program execution, all the applications that depend on them are unable to continue successfully.

Engineered for TomorrowUnit-VDistributed Systems BrokerInteractive Systems Model-View-Controller(MVC) Presentation-Abstraction-Control(PAC)

Interactive Systems IntroductionThe objective is to enhance the usability of an application.Usable software systems provide convenient access to their services, and therefore allow users to learn the application and produce results quickly. When specifying the architecture of such systems, the challenge is to keep the functional core independent of the user interface.

Contd..The fundamental structural organization for interactive software systems are described by two patterns: i) The Model-View-Controller pattern (MVC) ii) The Presentation-Abstraction-Control pattern (PAC)

Engineered for TomorrowUnit-VDistributed Systems BrokerInteractive Systems Model-View-Controller(MVC) Presentation-Abstraction-Control(PAC)

Model View ControllerPattern DefinitionExample ResolvedContextProblemSolutionStructureDynamicsImplementationVariantsKnown UsesConsequences

Model View ControllerDefinitionThe Model-View-Controller architectural pattern (MVC) divides an interactive application into three components. The model contains the core functionality and data. Views display information to the user.Controllers handle user input. Views and controllers together comprise the user interface.

Model View Controller- ExampleConsider a simple information system for political elections with proportional representation. This offers a spreadsheet for entering data and several kinds of tables and charts for presenting the current results. Users can interact with the system via a graphical interface. All information displays must reflect changes to the voting data immediately. It should be possible to integrate new ways of data presentation, such as the assignment of parliamentary seats to political parties, without major impact to the system.The system should also be portable to platforms with different 'look and feel' standards.

Contd..Fig: Information system for political elections, with proportional representation

Context & ProblemContext Interactive applications with a flexible human -computer interfaceProblemUser interfaces are prone to change requests. When you extend the functionality of an application, you must modify menus to access these new functions.A customer may call for a specific user interface adaptation, or a system may need to be ported to another platform with a different 'look and feel' standard. The user interface platform of long-lived systems thus represents a moving target.

Contd..The following forces influence the solution to the above problem:i) The same information is presented differently in different windows, for example, in a bar or pie chart. ii) The display and behavior of the application must reflect data manipulations immediately. iii) Changes to the user interface should be easy, and even possible at run-time. iv) Supporting different 'look and feel' standards or porting the user interface should not affect code in the core of the application.

SolutionMVC divides an interactive application into the three areas: processing, output, and input. The model component encapsulates core data and functionality. The model is independent of specific output representations or input behavior.View components display information to the user. A view obtains the data from the model. There can be multiple views of the model.

Contd..Each view has an associated controller component. Controllers receive input, usually as events that encode mouse movement, activation of mouse buttons, or keyboard input. The separation of the model from view and controller components allows multiple views of the same model.If the user changes the model via the controller of one view, all other views dependent on this data should reflect the changes. The model therefore notifies all views, whenever its data changes.

Structure of Model View Controlleri) ModelThe model component contains the functional core of the application. It encapsulates the appropriate data, and exports procedures that perform application-specific processing. The model also provides functions to access its data that are used by view components to acquire the data to be displayed. Changes to the state of the model trigger the change-propagation mechanism.The change-propagation mechanism is the only link between the model and the views and controllers.

Contd..

Contd..ii) ViewView components present information to the user.Different views present the information of the model in different ways. Each view defines an update procedure that is activated by the change-propagation mechanism.When the update procedure is called, a view retrieves the current data values to be displayed from the model, and puts them on the screen.iii) ControllerThe controller components accept user input as events.

Contd..How these events are delivered to a controller depends on the user interface platform.If the behavior of a controller depends on the state of the model, the controller registers itself with the change-propagation mechanism and implements an update procedure.

Contd.. An object-oriented implementation of MVC would define a separate class for each component. In a C++ implementation, view and controller classes share a common parent that defines the update interface.

Contd..In our example system, the model holds the cumulative votes for each political party and allows views to retrieve vote numbers. We define several views: a bar chart, a pie chart and a table.

Dynamics of MVCThe following scenarios depict the dynamic behavior of MVC :Scenario I

Contd..The controller accepts user input in its event-handling procedure, interprets the event, and activates a service procedure of the model. The model performs the requested service. The model notifies all views and controllers registered with the change-propagation mechanism of the change. Each view requests the changed data from the model and re- displays itself on the screen. Each registered controller retrieves data from the model to enable or disable certain user functions. The original controller regains control and returns from its event- handling procedure.

Contd..Scenario IIshows how the MVC triad is initialized.

Contd..Scenario IIi) The model instance is created, which then initializes its internal data structures. ii) A view object is created. iii) The view subscribes to the change-propagation mechanism of the model by calling the attach procedure. iv)The view continues initialization by creating its controller.v) The controller also subscribes to the change-propagation mechanism by calling the attach procedure. vi) After initialization, the application begins to process events.

Implementation of MVC1. Separate human-computer interaction from core functionalityAnalyze the application domain and separate the core functionality from the desired input and output behavior. Design the model component of the application to encapsulate the data and functionality needed for the core. Decide which parts of the model's functionality are to be exposed to the user via the controller.The model in our example stores the names of the political parties and the corresponding votes in two lists of equal length.

Contd..2. Implement the change-propagation mechanismExtend the model with a registry that holds references to observing objects. Provide procedures to allow views and controllers to subscribe and unsubscribe to the change-propagation mechanism.The model's notify procedure calls the update procedure of all observing objects.In the example, the Observer class holds the update interface. The methods attach() & detach() are used to allow observing objects to subscribe and unsubscribe.The method notify() will be called by methods that modify the state of the model.

Contd..3. Design and implement the views Design the appearance of each viewImplement all the procedures associated with views.

Contd..4. Design and implement the controllersFor each view of the application, specify the behavior of the system in response to user actions. The underlying platform delivers every action of a user as an event.A controller receives and interprets these events using a dedicated procedure. The initialization of a controller binds it to its model and view and enables event processing.We define a base class Controller with an empty handleEvent() method.

Contd..5. Design and implement the view-controller relationshipA view typically creates its associated controller during its initialization. Each view that requires a controller that differs from its super class redefines the factory method. In our C++ example, the View base class implements a method initialize ( ) that in turn calls the factory method makecontroller ( ).6. Implement the set-up of MVCThe set-up code first initializes the model, then creates and initializes the views.

Contd..After initialization, event processing is started, typically in a loop, such as XtMainLoop ( ) from the X Toolkit. Since the model should remain independent of specific views and controllers, this set-up code should be placed externally, in a main program.7. Dynamic view creationIf the application allows dynamic opening and closing of views, it is a good idea to provide a component for managing open views.

Contd..This component can also be responsible for terminating the application after the last view is closed. The View Handler design pattern, can be used to implement this view management component.8. Pluggable controllersThe separation of control aspects from views supports the combination of different controllers with a view. This flexibility can be used to implement different modes of operation, such as casual user versus expert, or to construct read-only views using a controller that ignores any input. Another use of this separation is the integration of new input and output devices with an application.

Contd..Example: The class TableView supports several controllers.The default controller TableController allows the user to enter voting data.9. Infrastructure for hierarchical views and controllersThe user interface of an application is constructed largely by combining predefined view objects. The Composite pattern is applied to create hierarchically composed views.If multiple views are active simultaneously, several controllers may be interested in events at the same time. Events are distributed to event-handling routines of all active controllers in some defined sequence.

Contd..10. Further decoupling from system dependenciesThe view and controller classes can be made platform independent, by applying the Bridge pattern.Views use a class named ‘display’ as an abstraction for windows and controllers use a ‘sensor’ class.The abstract class ‘display’ defines methods for creating a window, drawing lines and text, changing the look of the mouse cursor and so on. The sensor abstraction defines platform-independent events, and each concrete sensor subclass maps system-specific events to platform-independent events.

Variants of MVC1. Document-ViewIn the Document-View architecture, window display and event handling are closely interwoven.The responsibilities of the view and the controller from MVC, are combined into a single component.The document component corresponds to the model in MVC, and also implements a change-propagation mechanism. The view component of Document-View combines the responsibilities of controller and view in MVC, and implements the user interface of the system.

Known Uses of MVC1. SMALLTALKThe best-known example of the use of the Model-View-Controller pattern is the user-interface framework in the Smalltalk environment.MVC was established to build reusable components for the user interface. These components are shared by the tools that make up the Smalltalk development environment. The VisualWorks Smalltalk environment supports different 'look and feel' standards by decoupling view and controllers via display and sensor classes.

Contd..2. MFCThis Document-View variant of the Model-View-Controller pattern is integrated in the Visual C++ environment.Visual C++ environment is a Microsoft Foundation Class Library for developing Windows applications. 3. ET++A typical ET++-based application implements its own document class and a corresponding view class.ET++ establishes 'look and feel' independence by defining a class Windowport that encapsulates the user interface platform dependencies, in the same way as display and sensor classes.

Consequences The application of Model-View-Controller has several benefits:i) Multiple views of the same modelMVC strictly separates the model from the user-interface components. Multiple views can therefore be implemented and used with a single model.ii) Synchronized views The change-propagation mechanism of the model ensures that all attached observers are notified of changes to the application's data at the correct time.

Contd..iii) Pluggable views and controllersThe conceptual separation of MVC allows exchange of the view and controller objects of a model.User interface objects can even be substituted at run-time.iv) Exchangeability of 'look and feel‘Since the model is independent of all user-interface code, a port of an MVC application to a new platform does not affect the functional core of the application.v) Framework potential It is possible to base an application framework on this pattern. Example- Smalltalk environment

Contd..The liabilities of MVC are as follows:1. Increased complexityUsing separate model, view and controller components for menus and simple text elements increases complexity without gaining much flexibility.2. Potential for excessive number of updatesIf a single user action results in many updates, the model should skip unnecessary change notifications. 3 . Intimate connection between view and controllerController and view are separate but closely-related components, which hinders their individual reuse.

Contd..It is unlikely that a view would be used without its controller, or vice-versa.4. Close coupling of views and controllers to a modelChanges to the model's interface are likely to break the code of both view and controller. This problem is magnified, if the system uses a multitude of views and controllers.5. Inefficiency of data access in viewUnnecessarily requesting unchanged display data from the model weakens performance if updates are frequent.

Contd..6. Inevitability of change to view and controller when portingAll dependencies on the user-interface platform are encapsulated within view and controller.Thus porting of an MVC system requires the separation of platform-dependent code before rewriting.7. Difficulty of using MVC with modern user-interface toolsIf not for portability, using high-level toolkits or user interface builders can rule out the use of MVC.It is usually expensive to retrofit toolkit components or the output of user interface layout tools to MVC.

Engineered for TomorrowUnit-VDistributed Systems BrokerInteractive Systems Model-View-Controller(MVC) Presentation-Abstraction-Control(PAC)

Presentation Abstraction ControlPattern DefinitionExample ResolvedContextProblemSolutionStructureDynamicsImplementationVariantsKnown UsesConsequences

Presentation Abstraction Control(PAC)Pattern DescriptionThe Presentation-Abstraction-Control architectural pattern (PAC) defines a structure for interactive software systems in the form of a hierarchy of cooperating agents.Every agent is responsible for a specific aspect of the application's functionality and consists of three components: presentation, abstraction, and control. This subdivision separates the human-computer interaction aspects of the agent from its functional core and its communication with other agents.

PAC - ExampleConsider a simple information system for political elections with proportional representation. This offers a spreadsheet for entering data and several kinds of tables and charts for presenting current statistics. Users interact with the software through a graphical interface. Different versions, however, adapt the user interface to specific needs.For example, one version supports additional views of the data, such as the assignment of parliament seats to political parties.

Contd..Fig: Information system for political elections with proportional representation

PAC – Context & ProblemContextDevelopment of an interactive application with the help of agents.ProblemInteractive systems can often be viewed as a set of cooperating agents.Agents specialized in human-computer interaction accept user input and display data. Other agents maintain the data model of the system and offer functionality that operates on this data. Additional agents are responsible for tasks such as error handling or communication with other software systems.

Contd..In such an architecture of cooperating agents, each agent is specialized for a specific task, and all agents together provide the system functionality.This architecture also captures both a horizontal and vertical decomposition. The following forces affect the solution: i) Agents often maintain their own state and data. However, individual agents must effectively cooperate to provide the overall task of the application. To achieve this, they need a mechanism for exchanging, data, messages, and events.

Contd..ii) Interactive agents provide their own user interface, since their respective human-computer interactions often differ widely. iii) Systems evolve over time. Their presentation aspect is particularly prone to change.Changes to individual agents, or the extension of the system with new agents, should not affect the whole system.

SolutionStructure the interactive application as a tree-like hierarchy of PAC agents - one top-level agent - several intermediate- level agents - more bottom-level agents. Every agent is responsible for a specific aspect of the application's functionality, and consists of three components - presentation - abstraction - control

Contd..The whole hierarchy reflects transitive dependencies between agents.Each agent depends on all higher-level agents up the hierarchy to the top-level agent.The agent's presentation component provides the visible behavior of the PAC agent. Its abstraction component maintains the data model that underlies the agent, and provides functionality that operates on this data.

Contd..Its control component connects the presentation & abstraction components, and provides functionality that allows the agent to communicate with other PAC agents.The top-level PAC agent provides the functional core of the system.Bottom-level PAC agents represent self-contained semantic concepts on which users of the system can act, such as spreadsheets and charts.Intermediate-level PAC agents represent either combinations of or relationships between lower-level agents.

Contd..ExampleOur information system for political elections defines a top-level PAC agent that provides access to the data repository underlying the system. At the bottom level, there are four PAC agents: one spreadsheet agent for entering data, and three view agents for each type of diagram representing the data. The application has one intermediate-level PAC agent. This coordinates the three bottom-level view agents and keeps them consistent. Users of the system only interact with bottom-level agents.

Contd..

Structure of PACi) Top-level PAC agentThe main responsibility of the top-level PAC agent is to provide the global data model of the software. Abstraction componentThis is maintained in the abstraction component of the top-level agent. The interface of the abstraction component offers functions to manipulate the data model and to retrieve information about it.

Contd.. Presentation componentThe presentation component of the top-level agent has few responsibilities, which include user- interface elements common to the whole application.

Contd.. Control component The control component of the top-level PAC agent has three responsibilities: i) It allows lower-level agents to make use of the services of the top-level agents, mostly to access and manipulate the global data model. ii) It coordinates the hierarchy of PAC agents. iii) It maintains information about the interaction of the user with the system.

Contd..ii) Bottom-level PAC agentsrepresent a specific semantic concept of the application domain, such as a mailbox in a network traffic management system or a wall in a mobile robot system. Presentation component - presents a specific view of the corresponding semantic concept, and provides access to all the functions users can apply to it. Abstraction component - has a similar responsibility as the abstraction component of the top-level PAC agent, maintaining agent-specific data.

Contd.. Control component - maintains consistency between the abstraction and presentation components. - agents communicates with higher-level agents to exchange events and data.

Contd..iii) Intermediate-level PAC agentsHas two different roles to fulfill: i) composition and ii) coordination Abstraction component - maintains the specific data of the inter-mediate- level PAC agentPresentation component - implements its user interface Control component - has the same responsibilities of the control components of bottom-level PAC agents and of the top-level PAC agent.

Contd..

Contd..Fig: PAC hierarchy of the information system for political elections

Contd..Fig: Internal structure of PAC agent, using the bar-chart agentreceiveMsg( ) - All incoming service requests, events and data are handled by this function. sendMsg( ) - is used to pack and deliver service requests, events, and data to other agents.

DynamicsScenario Idemonstrates the behavior when a client calls a service of its external server:

Contd..i) At a certain point in its control flow the client requests a service from an external server by calling the adapter. ii) The adapter constructs a request and asks the microkernel for a communication link with the external server. iii)The microkernel determines the physical address of the external server and returns it to the adapter.iv)After retrieving this information, the adapter establishes a direct communication link to the external server.v) The adapter sends the request to the external server using a remote procedure call.

Contd..vi)The external server receives the request, unpacks the message and delegates the task to one of its own methods.vii)After completing the requested service, the external server sends all results and status information back to the adapter. viii)The adapter returns to the client, which in turn continues with its control flow.

Contd..Scenario II illustrates the behavior of a Microkernel architecture when an external server requests a service that is provided by an internal server.

Contd..i) The external server sends a service request to the microkernel.ii) A procedure of the programming interface of the microkernel is called to handle the service request. iii)During method execution the microkernel sends a request to an internal server.iv) After receiving the request, the internal server executes the requested service and sends all results back to the microkernel.v) The microkernel returns the results back to the external server.vi) Finally, the external server retrieves the results and continues with its control flow.

ImplementationTo implement a PAC architecture, carry out the following ten steps:i) Define a model of the applicationAnalyze the problem domain and map it onto an appropriate software structure.Answer the following questions: - Which services should the system provide? -Which components can fulfill these services? -What are the relationships between components? -How do the components collaborate? -What data do the components operate on? -How will the user interact with the software?

Contd..ii) Define a general strategy for organizing the PAC hierarchyOne rule to follow is that of 'lowest common ancestor'. When a group of lower-level agents depends on the services or data provided by another agent, this agent becomes the root of the sub-tree.A second aspect to consider is the depth of the hierarchy.iii) Specify the top-level PAC agentIdentify - parts that represent the functional core of the system - all user interface elements that are common to the whole applicationAll components identified in this step will be part of the top-level agent.

Contd..iv) Specify the bottom-level PAC agents Identify - components that represent the smallest self-contained units of the system on which the user can perform operations or view presentations. For each of these units, identify - components that provide the human- computer interaction associated with them.v) Specify bottom-level PAC agents for system services.Following services can be implemented as bottom-level PAC agents:

Contd.. - Additional services not directly related to its primary subject, such as error handler - Communication or configuration services vi) Specify intermediate-level PAC agents to compose lower-level PAC agentsOur election example does not provide semantic concepts above individual charts, diagrams, and spreadsheets. Therefore we do not define PAC agents, for composing other PAC agents.

Contd..vii) Specify intermediate-level PAC agents to coordinate lower-level PAC agentsIn our election example, the view coordinator agent is an intermediate-level agent. To implement agents that coordinate multiple views, the View- Handler pattern can be applied.viii) Separate core functionality from human- computer interactionFor every PAC agent, introduce presentation and abstraction components.

Contd..Finally, introduce the control component to mediate between the abstraction and presentation components, and to avoid direct dependencies between them.

Contd..ix) Provide the external interfaceTo co-operate with other agents, every PAC agent sends and receives events and data. This can be implemented by the control component using the Mediator pattern.Ways of implementing communication with other agents are: - apply the Composite Message pattern - provide a public interface that offers every service of an agent as a separate function x) Link the hierarchy togetherConnect every PAC agent with those lower-level PAC agents with which it directly cooperates.

Variants of PAC1. PAC agents as active objectsMany applications, especially interactive ones, benefit from multi-threading. The mobile robot system is an example of a multi-threaded PAC architecture. Every PAC agent can be implemented as an active object that lives in its own thread of control. Design patterns like Active Object and Half-Sync/Half-Async, can help you implement such an architecture.

Contd..ii) PAC agents as processesTo support PAC agents located in different processes or on remote machines, use proxies to locally represent these PAC agents and to avoid direct dependencies on their physical location. Use the Forwarder-Receiver pattern or the Client-Dispatcher-Server pattern to implement the inter- process communication (IPC) between PAC agents.

Known Uses of PAC1. Network Traffic ManagementThis system, displays the traffic in telecommunication networks. Every fifteen minutes all monitored switching units report their current traffic situation to a control point where the data is stored, analyzed and displayed. This helps with identification of potential bottlenecks and in preventing traffic overload.The system includes functions for: - Gathering traffic data from switching units. - Threshold checking and generation of overflow exceptions. - Logging and routing of network exceptions.

Contd.. - Visualization of traffic flow and network exceptions - Displaying various user-configurable views of the whole network - Statistical evaluations of traffic data - Access to historic traffic data - System administration and configurationThe design and implementation of the system follows the Presentation-Abstraction-Control pattern. Every function of the system is represented by its own bottom-level PAC agent. There are dedicated agents for each view of the network, for the jobs the system can perform.Three intermediate-level PAC agents coordinate these bottom-level PAC agents.

Contd..Fig: Network Traffic Management System

Contd..2. Mobile RobotThis system allows an operator to interact with a mobile robot that navigates within a closed and hazardous environment consisting of walls, equipment and people(intruders or accident victims).The robot navigates using its own sensors and information from the system operator. The software allows the operator to: - Provide the robot with a description of the environment it will work in, places in this environment, and routes between places - Subsequently modify the environment - Specify missions for the robot

Contd..Control the execution of missionsObserve the progress of missionsFig: Mobile Robot System

Contd..Wall, Route & Place - Each wall, route and place within an environment is represented by its own bottom-level PAC agent. These agents together visualize the environment.Palette PAC agent - The control users can exert on an environment is implemented in a 'palette' PAC agent. The environment PAC agent and the palette PAC agent form a workspace for the robot.Multi-workspace PAC agent - To support multiple views of the same environment, a multi-workspace PAC agent coordinates the different views of the same workspace.Top Level PAC - The PAC agent at the top level of the hierarchy encapsulates the functional core of the application.

ConsequencesThe PAC architectural pattern has several benefits: i) Separation of concernsDifferent semantic concepts in the application domain are represented by separate agents.Each agent maintains its own state and data, coordinated with, but independent of other PAC agents.ii) Support for change and extensionChanges within the presentation or abstraction components of a PAC agent do not affect other agents in the system. This allows individual modification of the data model underlying a PAC agent or that of the user interface.

Contd..iii) Support for multi-taskingPAC agents can be distributed easily to different threads, processes, or machines.Multi-tasking also facilitates multi-user applications.The shared data repository, or its control component, should take care of serialization or synchronization.

Contd..The liabilities of this pattern are as follows: i) Increased system complexityThe implementation of every semantic concept within an application as its own PAC agent may result in a complex system structure.For example, if every graphical object within a graphics editor is implemented as its own PAC agent, the system would drown in a sea of agents.

Contd..ii) Complex control componentThe quality of the control component implementations is crucial to an effective collaboration between agents, and therefore for the overall quality of the system architecture.The interface of the control components should be independent of internal details, to ensure that an agent's collaborators do not depend on the specific interface of its presentation or abstraction components.iii) EfficiencyThe overhead in the communication between PAC agents, may impact system efficiency. Example: if a bottom-level agent retrieves data from the top-level agent, all intermediate-level agents along the path, are involved in this data exchange.

Contd..iv) ApplicabilityThe smaller the atomic semantic concepts of an application are, and the greater the similarity of their user interfaces, the less applicable this pattern is.For example, a graphical editor in which every individual object , is represented by its own PAC agent will probably result in a complex fine-grain structure, which is hard to maintain.