Software Architecture - 2

1. Software Architecture - 2 October 26, 2014

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

3. Implicit Asynchronous Communication Architecture • Overview • Asynchronous implicit invocation communication • Non-buffered • Buffered. • Publisher-subscriber (producer-consumer) • 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.

4. Implicit Asynchronous Communication Architecture • Publisher-subscriber (producer-consumer) • 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.

5. Non-Buffered Event-Based Implicit Invocations • 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.

6. Non-Buffered Event-Based Implicit Invocations

7. Non-Buffered Event-Based Implicit Invocations

8. Non-Buffered Event-Based Implicit Invocations

9. Non-Buffered Event-Based Implicit Invocations • 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.

10. Non-Buffered Event-Based Implicit Invocations • 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.

11. Non-Buffered Event-Based Implicit Invocations • 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.

12. Non-Buffered Event-Based Implicit Invocations • 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.

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

14. Buffered Message-Based Software Architecture • What is a message? • A message is a structured data with an id, message header, property, and body, e.g. an XML document. • What is messaging? • A mechanism or technology that handles asynchronous or synchronous message delivery effectively and reliably. • 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.

15. Point-to-Point Messaging (P2P) • A P2P 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. • P2P messaging requires every message in the queue be processed by a consumer.

16. Point-to-Point Messaging (P2P)

17. Publish-Subscribe Messaging (P&S) • 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 P2P 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

18. Publish-Subscribe Messaging (P&S)

19. Buffered Message-Based Software Architecture • 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.

20. Buffered Message-Based Software Architecture • 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.

21. Buffered Message-Based Software Architecture • 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

22. Chapter 9INTERACTION ORIENTED SOFTWARE ARCHITECTURES

23. INTERACTION ORIENTED SOFTWARE ARCHITECTURES • 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 • 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

24. INTERACTION ORIENTED SOFTWARE ARCHITECTURES • Two major style • Model-View-Controller (MVC) • Presentation-Abstraction-Control (PAC) • 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.

25. Model-View-Controller (MVC) • 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. • Views: • In this metaphor, views deal with everything graphical: they request data from their model and display the data. • Controllers: • Controllers contain the interface between their associated models and views and the input devices (e.g., keyboard, pointing device, time)

26. MVC-I • 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.

27. MVC-I • 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.

28. MVC-I

29. MVC-I • 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.

30. MVC-I • 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 actionPerformed() can take care all necessary changes. • We just want to use this example to see how MVC-I architecture works.

31. MVC-II

32. MVC-II • 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.

33. MVC-II

34. MVC-II • Fig 9.4 depicts a sequence diagram for a generic MVC architecture.

35. MVC-II • 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.

36. MVC-II

37. MVC-II • The myServletServlet sets an item value and stores this item in a JavaBean named myBean, then transfers the control to a JSP page named fromServlet.jsp which retrieves the item from the myBean 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.

38. MVC • 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.

39. MVC • 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.

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

41. Presentation-Abstraction-Control (PAC) • 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.

42. Presentation-Abstraction-Control (PAC) • 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.

43. Presentation-Abstraction-Control (PAC) • 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.

44. Presentation-Abstraction-Control (PAC) • 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.

45. Presentation-Abstraction-Control (PAC) • 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.

46. Presentation-Abstraction-Control (PAC)

47. Presentation-Abstraction-Control (PAC) • 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 C4 informs agent P4 to update its presentation, in this case, it also hides the next button since there is no next page after last page. • Agent C4 also informs agent A4 to update the data on next button.

48. Presentation-Abstraction-Control (PAC) • After C4 handles all local processing, it contacts its parent agent, C1, to let it take over. • After C1 gets the message from C4, it tells A1 to move the next page, which is the last page in the document, and then asks P1 to display that page. • C1 also informs C5 to hide the last button since the current page is the last page (or let the last button stay based on the requirement specification).

49. Presentation-Abstraction-Control (PAC) • 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 PAC2, PAC3, PAC4, and PAC5 are all buttons, they have very similar data and presentation functionality such as hide, move-over, gray-out features; their controls, however, are different.

50. Presentation-Abstraction-Control (PAC)