Software Architecture 2 29 November 2020 Architectural Patterns

Software Architecture - 2 29 November 2020

Architectural Patterns - 2 n Implicit Asynchronous Communication Architecture – Non-buffered event-based Implicit Invocation – Buffered messaged-based n n n Interaction-Oriented Architecture – – Model-View-Controller (MVC) Presentation-Abstraction-Control (PAC) – – – Client-server Broker Service-oriented architecture (SOA) Distributed Architecture Component-based Architecture

Implicit Asynchronous Communication Architecture n Overview – Asynchronous implicit invocation communication n n Non-buffered Buffered. – Publisher-subscriber (producer-consumer) n n Subscribers are interested in some events/messages issued by a publisher Subscribers register themselves with the event source. Once an event is fired off by an event source, all corresponding subscribers are notified. It is up to the subscribers to decide on the actions to execute.

Implicit Asynchronous Communication Architecture – Publisher-subscriber (producer-consumer) n n n The message queue/topic are typical buffered asynchronous architectures subscribers also need to register their interests with; the event/message is fired off when available on the buffered message queue or topic. Message queue one-to-one or point-to-point architecture between message senders and message receivers; Message topic one-to-many architecture between publishers and subscribers.

Non-Buffered Event-Based Implicit Invocations n n n The architecture breaks the system into two partitions: – Event sources – event listeners. The event registration process connects these two partitions. There is no buffer available between these two parties.

Non-Buffered Event-Based Implicit Invocations

Non-Buffered Event-Based Implicit Invocations n The event-based implicit invocation is a good solution for user interaction in a user interface application. Following are simple Java fragments that demonstrate how event sources and event targets (listeners) work together in an event-driven architecture for a user interface application.

Non-Buffered Event-Based Implicit Invocations n Applications – Suitable for interactive GUI component communication. – Suitable for applications that require loose coupling between components that need to notify or trigger other components to take actions upon asynchronous notifications. – Suitable for the implementation of state machines. – Suitable when event handlings in the application are not predictable.

Non-Buffered Event-Based Implicit Invocations n Benefit – Many vendor APIs such as Java AWT and Swing components available. – Easy to plug-in new event handlers without affecting the rest of the system. – Easy to update both of event sources and targets. – Dynamic registration and deregistration can be done dynamically at run-time. – Possibility of parallel execution of event handlings.

Non-Buffered Event-Based Implicit Invocations n Limitations – Difficult to test and debug the system since it is hard to predict and verify responses and the order of responses from the listeners. – The event trigger cannot determine when a response has finished or the sequence of all responses. – There is tighter coupling between event sources and their listeners than in message queue based or message topic based implicit invocation.

Buffered Message-Based Software Architecture n The architecture breaks into three partitions: – Message producers, – message consumers, and – message service providers. n They are connected asynchronously by either – a message queue – a message topic. n This architecture is also considered data-centric.

Buffered Message-Based Software Architecture n What is a message? – A message is a structured data with an id, message header, property, and body, e. g. an XML document. n What is messaging? – A mechanism or technology that handles asynchronous or synchronous message delivery effectively and reliably. n n A messaging client can send messages to other clients and receive messages from other clients. A client must register with a messaging destination in a connection session provided by a message service provider for creating, sending, receiving, reading, validating, and processing messages.

Point-to-Point Messaging (P 2 P) n n n A P 2 P messaging architecture is composed of message queues, senders, and receivers. Each message is sent to a specific queue maintained by the consumer The queue retains all messages until either the messages are consumed or the messages expire. Each message has only one consumer, i. e. , the message will be “gone” once it is delivered. This approach allows multiple receivers but only one of them will get the message. P 2 P messaging requires every message in the queue be processed by a consumer.

Point-to-Point Messaging (P 2 P)

Publish-Subscribe Messaging (P&S) n n n The P&S messaging architecture is a hub-like architecture, where publisher clients send messages to a message topic that acts like a bulletin board. Message topic publishers and subscribers are not aware of each other. One difference between P&S from P 2 P is that each topic message can have multiple consumers. The system delivers the messages to all its multiple subscribers instead of single receiver as in the message queue system. Normally a message topic consumer must subscribe the topic before it is published

Publish-Subscribe Messaging (P&S)

Buffered Message-Based Software Architecture n Applications – Suitable for systems where the communication needs buffered message-based asynchronous implicit invocation for performance and distribution purposes. – The provider wants the components not to depend on information about other components' interfaces, so that components can be easily replaced. – The provider wants the application to run whether or not all other components are up and running simultaneously. – A component can send information to another and continue to operate on its own without waiting for an immediate response.

Buffered Message-Based Software Architecture n Benefits – Providing high degree of anonymity between message producer and consumer. – The message consumer does not know who produced the message (user independence), where the producer lives on the network (location independence), or when the message was produced (time independence). – Supporting for concurrency among consumers and between producer and consumers.

Buffered Message-Based Software Architecture n Limitations: – Capacity limit of message queue. This is not an inherent limitation but an implementation issue that can be eased if the queue is implemented as a dynamic data structure (e. g. , linked lists). – However, there is an absolute limit based on available memory. It is also difficult to determine the numbers of agents needed to satisfy the loose couplings between agents. – Complete separation of presentation and abstraction by control in each agent generate development complexity since communications between agents only take place between the control of agents. – Increased complexity of the system design and implementation

Chapter 9 INTERACTION ORIENTED SOFTWARE ARCHITECTURES

INTERACTION ORIENTED SOFTWARE ARCHITECTURES n n The key point - the separation of user interactions from data abstraction and business data processing. The interaction oriented software architecture decomposes the system into three major partitions: – Data module – Control module – View presentation module n n The data module provides the data abstraction & all business logic. The view presentation module is responsible for data output presentation and it may provide an input interface for user input. The control module determines the flow of control involving view selections, communications between modules, job dispatching, and certain data initialization and system configuration actions. Multiple view presentations in different formats are allowed

INTERACTION ORIENTED SOFTWARE ARCHITECTURES n Two major style – Model-View-Controller (MVC) – Presentation-Abstraction-Control (PAC) n n Both of MVC and PAC are used for interactive applications multiple talks and user interactions. They are different in their flow of control and organization. The PAC is an agent based hierarchical architecture The MVC does not have a clear hierarchical structure and all three modules are connected together.

Model-View-Controller (MVC) n n Objects of different classes take over the operations related to the application domain (the model), the display of the application's state (the view), and the user interaction with the model and the view (The controller). Models: – The model of an application is the domain-specific software simulation or implementation of the application's central structure. n Views: – In this metaphor, views deal with everything graphical: they request data from their model and display the data. n Controllers: – Controllers contain the interface between their associated models and views and the input devices (e. g. , keyboard, pointing device, time)

MVC-I n n n The MVC-I is a simple version of MVC architecture where the system is simply decomposed into two sub-systems: The Controller-View and the Model. Basically, the Controller-View takes care of input and output processing and their interfaces; the Model module copes with all core functionality and the data. The Controller-View module registers with (attaches to) the data module.

MVC-I n n n The Model module notifies the Controller-View module of any data changes so that any graphics data display will be changed accordingly; the controller also takes appropriate action upon the changes. The connection between the Controller-View and the Model can be designed in a pattern of subscribe-notify whereby the Controller-View subscribes to the Model and the Model notifies the Controller-View of any changes. In other words, the Controller-View is an observer of the data in the Model module.

MVC-I

MVC-I n n Simple GUI example designed in MVC-I. The View has a GUI interface with two text fields, for the user to enter a new number in one of the text fields and the accumulated summation is displayed in the other text field. The summation is held in the Model module. Model provides all business logics including all getter and setter methods.

MVC-I n n Whenever the data in the Model is updated it will notify the registered GUI components of changes, and then the GUI components will update their displays. This is why we say that the data in the Model of MVC architecture is active rather than passive. Actually, for this specific example there is no need to have separated Model to notify the change because action. Performed() can take care all necessary changes. We just want to use this example to see how MVC-I architecture works.

MVC-II

MVC-II n The MVC in figure 9. 2 is the same as MVC-I in figure 9. 1 except that the controller and the view are separated.

MVC-II

MVC-II n Fig 9. 4 depicts a sequence diagram for a generic MVC architecture.

MVC-II n n n After clients start up the MVC application, the controller initializes the Model and View, and attaches the View and itself to the Model (this is called registration with the Model. Later, the Controller intercepts a user request either directly from command line or through the View interface, and forwards the request to the Model to update the data in the Model. The changes in the Model will trigger the Model to notify all attached or registered listeners of all changes, and the interface in the View will also be updated right way.

MVC-II

MVC-II n n n The my. Servlet sets an item value and stores this item in a Java. Bean named my. Bean, then transfers the control to a JSP page named from. Servlet. jsp which retrieves the item from the my. Bean and displays it on a Web page. Whenever the data is changed the display is also changed. The following Java classes show a MVC-II template to provide more detailed explanations on the MVC-II architecture.

MVC n Applications: – Suitable for interactive applications where multiple views are needed for a single data model and the interfaces are prone to data changes frequently. – Suitable for applications where there are clear divisions between controller, view, and data modules so that different professionals can be assigned to work on different aspects of such applications concurrently.

MVC n Benefits: – There are many MVC vendor framework toolkits available. – Multiple views synchronized with same data model – Easy to plug-in new or change interface views, – Very effective for developments if Graphics expertise professionals, programming professionals, and data base development professionals are working in a team in a designed project.

MVC Does not fit well agent-oriented applications such as interactive mobile and robotics applications. n Multiple pairs of controllers and views based on the same data model make any data model change expensive. n The division between the View and the Controller is not clear in some cases. n

Presentation-Abstraction-Control (PAC) n n n The PAC architecture is similar to MVC but with some important differences. The PAC was developed from MVC to support the application requirement of multiple agents in addition to interactive requirements. In PAC, the system is decomposed into a hierarchy of many cooperating agents.

Presentation-Abstraction-Control (PAC) n n n Each agent has three components (Presentation, Abstraction, and Control). The Control component in each agent is in charge of communications with other agents. The top-level agent provides core data and business logics. The bottom level agents provide detailed specific data and presentations. A middle level agent may play a role of coordinator of low-level agents. There are no direct connections between Abstraction component and Presentation component in each agent.

Presentation-Abstraction-Control (PAC) n n The PAC three components concepts are applied to all concrete sub-system architectures. It is very suitable for any distributed system where all the agents are distantly distributed and each of them has its own functionalities with data and interactive interface. In such a system, all agents need to communicate with other agents in a well-structured manner. The PAC is also used in applications with rich GUI components where each of them keeps its own current data and interactive interface and needs to communicate with other components.

Presentation-Abstraction-Control (PAC) n n Of course, some concrete agent needs all three components and some other agents do not. For some middle level agents the interactive presentations are not required, so they do not have a Presentation component. The control component is required for all agents because this is the only way for an agent to talk to another agent. Figure 9. 6 shows a block diagram for a single agent in PAC design.

Presentation-Abstraction-Control (PAC) n n The Control component is a mediator between the Presentation component and the Abstraction component within the agent, and also a bridge between the agent itself and other agents as well. The Presentation component and the Abstraction component are loosely coupled. The Presentation component is responsible for both data input and data output in GUI interfaces where the data come from the Abstraction component. The Abstraction component is responsible for providing logical data concepts and services and encapsulating all detailed data manipulation.

Presentation-Abstraction-Control (PAC)

Presentation-Abstraction-Control (PAC) n n n Assume that the current page is the second to last page in the document at this time. If the user clicks on the next button, the control agent C 4 informs agent P 4 to update its presentation, in this case, it also hides the next button since there is no next page after last page. Agent C 4 also informs agent A 4 to update the data on next button.

Presentation-Abstraction-Control (PAC) n n n After C 4 handles all local processing, it contacts its parent agent, C 1, to let it take over. After C 1 gets the message from C 4, it tells A 1 to move the next page, which is the last page in the document, and then asks P 1 to display that page. C 1 also informs C 5 to hide the last button since the current page is the last page (or let the last button stay based on the requirement specification).

Presentation-Abstraction-Control (PAC) n n n We can see that all the agents communicate via the controls. The data structure shown on the upper-right corner of Figure 9. 7 indicates the pointer and data. Since PAC 2, PAC 3, PAC 4, and PAC 5 are all buttons, they have very similar data and presentation functionality such as hide, moveover, gray-out features; their controls, however, are different.

Presentation-Abstraction-Control (PAC)

Presentation-Abstraction-Control (PAC) n n The sequence diagram in Figure 9. 9 shows the interaction sequence in the example we discussed above. When the next button is pressed to display the last page in the document PAC 4 and PAC 1 react as follows: P 4 informs C 4 that the “next” button was pressed; C 4 sends update to A 4; C 4 informs P 4 to update its presentation or shape; C 4 contacts C 1 (a top level agent). C 1 sends update to A 1 to move the pointer to next (last page) C 1 instructs P 1 to display the last page.

Presentation-Abstraction-Control (PAC)

Presentation-Abstraction-Control (PAC) n Applications: – Suitable for an interactive system where the system can be divided into many cooperating agents in a hierarchical manner. – Each agent has its own specific assigned job. – Suitable when the coupling among the agents is expected to be loose so that changes on an agent does not affect others.

Presentation-Abstraction-Control (PAC) n Benefit: – Support of multi-tasking and multiviewing. – Support agent reusability and extensibility. – Easy to plug-in new agent or replace an existing one. – Support for concurrency where multiple agents are running in parallel in different threads or different devices or computers.

Presentation-Abstraction-Control (PAC) n Limitations: – Overhead due to the control bridge between presentation and abstraction and the communication of controls among agents. – Difficult to determine the right number of the agents due to the loose coupling and high independence between agents – Complete separation of presentation and abstraction by control in each agent generate development complexity since communications between agents only take place between the controls of agents.

Presentation-Abstraction-Control n Context – Development of an interactive system with the help of agents n Problem – A system consists of a set cooperating agents. – Each agent is responsible for one particular task n Solution – Structure the application as a tree-like hierarchy of PAC agent. – Each agent is responsible for one aspect of the system’s functionality

Presentation-Abstraction-Control – Each agent consists of three components: presentation, abstraction, and control n n n The presentation component provides the visible behavior of the agent The abstraction component maintains the data model and operations on the data model Control component connects the presentation and abstraction and communication with other agents. – The top level agent provides the functional core of the system – Bottom level agents represent self-contained semantic concepts on which the user can act, such as a spreadsheet – Intermediate level agents represent either combinations of, or relationships between, low level agents. n Known uses – Network Traffic Management – Mobile Robot

PAC Pattern - Structure Error. Handler error. Data send. Msg receive. Msg display. Error handle. Error Bar. Chart chart. Data send. Msg receive. Msg open close Repository Data send. Msg receive. Msg View. Mediator view. Data send. Msg receive. Msg open. View close. View Spreadsheet election. Data send. Msg receive. Msg Open Close enter. Data Pie. Chart pie. Data send. Msg receive. Msg open close

PAC Pattern - Structure View. Mediator Agent Abstraction chart. Data set. Chart. Data get. Chart. Data Bar. Chart Agent Control interaction. Data send. Msg receive. Msg get. Data Presentation present. Data Update Open Close Zoom print

Chapter 10 DISTRIBUTED ARCHITECTURE

Overview n n n A distributed system can be modeled by the client-server architecture, and this forms the basis for multi-tier architectures; alternatives are the broker architecture such as CORB, and the Service-Oriented Architecture (SOA). The important features of a distributed architecture are its service location transparency, and its services reliability and availability. Additionally, there are several technology frameworks to support distributed architectures, including. NET, J 2 EE, CORBA, . NET Web services, AXIS Java Web services, and Glo. Bus Grid services.

Client-Server

Client-Server Advantages: Separation of responsibilities such as user interface presentation and business logic processing. n Reusability of server components. Disadvantages: n Lack of heterogeneous infrastructure to deal with the requirement changes. n Security complications. n Server availability and reliability. n Testability and scalability. n Fat clients with presentation and business logic together. n

Multi-tiers

Broker Architectural Style n Overview – The broker architecture is a middleware architecture used in distributed computing to coordinate and facilitate communication between registered servers and clients. – It can be used to structure distributed software systems with decoupled components that interact by remote service invocations. – A broker component is responsible for coordinating communication, such as forwarding requests, as well as for transmitting results and exceptions. – A broker can be either an invocation-oriented service, to which clients send invocation requests for brokering, or a document or message- oriented broker to which clients send a message (such as an XML document). – Client and the server never interact with each other directly. – A broker system is also called the proxy-based system.

Broker Architectural Style – Servers make their services available to their clients by registering and publishing their interfaces with the broker. – Clients can request the services of servers from the broker statically or dynamically by look-up. – A broker component is responsible for coordinating communications – brokering the service requests, locating a proper server, forwarding and dispatching requests, and sending responses or exceptions back to clients. – CORBA (Common Object Request Broker Architecture) is a good implementation example of the broker architecture.

Broker Architectural Style – In addition, the clients can dynamically invoke the remote methods even if the interfaces of the remote objects are not available at the compilation time. – Client has a direct connection to its clientproxy and server has direct connection to its server-proxy. – The proxy talks to the mediator-broker.

Broker Architectural Style Components: n Broker n Stub n Skeleton n Bridge n Network

Broker Component n n n Co-ordinates communications – passes on requests and returns replies. The broker keeps all servers registration information including their functionality and services as well as location information. The broker provides APIs for clients to request, servers to respond, registering or unregistering server components, transferring messages, and locating servers.

Stub Component n n Client-side proxy: It mediates between client and broker and provides additional transparency between them. To the client, a remote object appears like a local one. The proxy hides the inter-process communication at protocol level and performs marshalling of parameter values and unmarshaling of results from the server. The stub is generated at the static compilation time and deployed to the client side to be used as a proxy for the client.

Skeleton Component n n Server-side proxy: It is also statically generated by the service interface compilation and then deployed to the server side. It encapsulates low-level system-specific networking functions like what client-proxy does and provides high-level APIs to mediate between the server and the broker. It receives the requests, unpacks the requests, unmarshals the method arguments, and calls the appropriate service. When it receives the result back from the server it also marshals the result before sending it back to the client.

Bridges n n These optional components are used to hide implementation details when two brokers interoperate. It encapsulates underlying network detail implementation and mediates different brokers such as DCOM, . NET Remote and Java CORBA brokers. They can take requests and parameters in one format and translate them to another format. A bridge can connect two different networks based on different communication protocols.

Network Component n n Network: The connections between the components are the network with designated protocol standards such as TCP/IP OIIP or SOAP. The request carries data in a format of message document or method invocation.

Broker model

Brokers with client-server proxy

Brokers with client-server proxy Advantages n n n Server component implementation and location transparency. Changeability and extensibility. Simplicity for clients to access server and server portability. Interoperability via broker bridges. Reusability. Feasibility of runtime changes of server components (add or remove server components on the fly). Disadvantages: n n n Inefficiency due to the overhead of proxies Low fault-tolerance Difficulty in testing due to the amount of proxies

CORBA

Service-Oriented Architecture (SOA) n Overview – A Service Oriented Architecture (SOA) starts with a businesses process. – A service is a business functionality that is welldefined, self-contained, independent from other services, and published and available to be used via a standard programming interface. – Software manages business processes through a SOA with well-defined and standard interfaces that can build, enhance, and expand their existing infrastructure more flexible.

Service-Oriented Architecture (SOA) – SOA services can be extensively reused within a given domain or product line, and even among legacy systems. – Loose coupling of service–orientation provide great flexibility for enterprises to make use of all available service recourses regardless of platform and technology restrictions. – The connections between services are conducted by common and universal message oriented protocols such as the SOAP Web service protocol, which can deliver requests and responses between services loosely. – A connection can be established statically or dynamically.

Service-Oriented Architecture (SOA)

SOA Implementation in Web Services

Service-Oriented Architecture (SOA) Advantages: n n n n Loose-coupling is the key attribute of SOA. Each service component is independent from other services due to the stateless service feature. The implementation of a service will not affect the application of the service as long as the exposed interface is not changed. A client or any service can access other services regardless of their platform, technology, vendors, or language implementations. Any service can be reused by any other service. Because clients of a service only need to know its public interfaces, service composition and integration become much easier. SOA based business application development comes much more efficient in term of time and cost. Loosely coupled services make themselves easy to scale. The coarse-grained, document-oriented, and asynchronous service features enhance the scalability attribute.