Bài giảng Kiến trúc phần mềm - Chương: Quy trình kiến trúc phần mềm - Trần Minh Triết

al 
 logic modified in many cases without changes rippling into other tiers.
Performance This architecture has proven high performance. Key issues to consider are the 
 amount of concurrent threads supported in each server, the speed of 
 connections between tiers and the amount of data that is transferred. As 
 always with distributed systems, it makes sense to minimize the calls needed 
 between tiers to fulfill each request.
Scalability As servers in each tier can be replicated, and multiple server instances run on the 
 same or different servers, the architecture scales out and up well. In practice, 
 the data management tier often becomes a bottleneck on the capacity of a 
 system. 13
 Messaging Pattern
 Asynchronous 
 communications: Clients 
 send requests to the queue, 
 where the message is 
 stored until an application 
 removes it. Configurable 
 Client Server
 QoS: The queue can be Client Que Server
 configured for high-speed, Client ue Server
 non-reliable or slower, 
 reliable delivery. Queue 
 operations can be 
 coordinated with database 
 transactions. 
 Loose coupling: There is 
 no direct binding between 
 clients and servers. 14
 Messaging – Quality Attribute 
 Analysis
Quality Issues
Attribute
Availability Physical queues with the same logical name can be replicated across different 
 messaging server instances. When one fails, clients can send messages to 
 replica queues.
Failure handling If a client is communicating with a queue that fails, it can find a replica queue and 
 post the message there. 
Modifiability Messaging is inherently loosely coupled, and this promotes high modifiability as 
 clients and servers are not directly bound through an interface. Changes to 
 the format of messages sent by clients may cause changes to the server 
 implementations. Self-describing, discoverable message formats can help 
 reduce this dependency on message formats.
Performance Message queuing technology can deliver thousands of messages per second. Non-
 reliable messaging is faster than reliable, with the difference dependent of 
 the quality of the messaging technology used.
Scalability Queues can be hosted on the communicating endpoints, or be replicated across 
 clusters of messaging servers hosted on a single or multiple server machines. 
 This makes messaging a highly scalable solution.
 15
 Publish-Subscribe Pattern
 Many-to-Many messaging:
 Published messages are 
 sent to all subscribers who 
 are registered with the topic. 
 Configurable QoS: In 
 addition to non-reliable and Subscriber
 reliable messaging, the Publisher Topic Subscriber
 underlying communication Subscriber
 mechanism may be point-to-
 point or broadcast/multicast. 
 Loose Coupling: As with 
 messaging, there is no 
 direct binding between 
 publishers and subscribers. 
 16
 Publish-Subscribe – Quality Attribute 
 Analysis
 Quality Issues
 Attribute
Availability Topics with the same logical name can be replicated across different server 
 instances managed as a cluster. When one fails, publishers send messages to 
 replica queues.
Failure handling If a publisher is communicating with a topic hosted by a server that fails, it can 
 find a live replica server and send the message there. 
Modifiability Publish-subscribe is inherently loosely coupled, and this promotes high 
 modifiability. New publishers and subscribers can be added to the system 
 without change to the architecture or configuration. Changes to the format of 
 messages published may cause changes to the subscriber implementations.
Performance Publish-subscribe can deliver thousands of messages per second, with non-
 reliable messaging faster than reliable. If a publish-subscribe broker supports 
 multicast/broadcast, it will deliver multiple messages in a more uniform time 
 to each subscriber.
Scalability Topics can be replicated across clusters of servers hosted on a single or multiple 
 server machines. Clusters of server can scale to provide very high message 
 volume throughput. Also, multicast/broadcast solutions scale better than their 
 point-to-point counterparts.
 17
 Broker Pattern
 Hub-and-spoke architecture:
 The broker acts as a 
 messaging hub, and senders 
 and receivers connect as 
 spokes. inPort1 OutPort1
 Sender-1 Receiver-1
 Performs message routing:
 The broker embeds processing Broker
 logic to deliver a message 
 received on an input port to an 
 output port. Sender-2 Receiver-2
 Performs message inPort2 OutPort2
 transformation: The broker 
 logic transforms the source 
 message type received on the 
 input port to the destination 
 message type required on the 
 output port.
 18
 Broker Pattern - Quality Attribute 
 Analysis
 Quality Issues
 Attribute
Availability To build high availability architectures, brokers must be replicated. This 
 is typically supported using similar mechanisms to messaging and 
 publish-subscribe server clustering.
Failure handling As brokers have typed input ports, they validate and discard any 
 messages that are sent in the wrong format. With replicated brokers, 
 senders can fail over to a live broker should one of the replicas fail.
Modifiability Brokers separate the transformation and message routing logic from the 
 senders and receivers. This enhances modifiability, as changes to 
 transformation and routing logic can be made without affecting 
 senders or receivers.
Performance Brokers can potentially become a bottleneck, especially if they must 
 service high message volumes and execute complex transformation 
 logic. Their throughput is typically lower than simple messaging 
 with reliable delivery.
Scalability Clustering broker instances makes it possible to construct systems scale 
 to handle high request loads.
 19
 Process Coordinator Pattern
 Process encapsulation: The 
 process coordinator 
 encapsulates the sequence of Start
 process Process
 steps needed to fulfill the request results
 business process. The Process
 sequence can be arbitrarily Coordinator
 complex. 
 Loose coupling: The server 
 components are unaware of step1
 their role in the overall business step2 step3 step4
 process, and of the order of the 
 steps in the process. 
 Flexible communications: Server-1 Server-2 Server-3 Server-4
 Communications between the 
 coordinator and servers can be 
 synchronous or asynchronous. 
 20
 Process Coordinator – Quality 
 Attribute Analysis
 Quality Issues
 Attribute
Availability The coordinator is a single point of failure. Hence it needs to be replicated to 
 create a high availability solution.
Failure handling Failure handling is complex, as it can occur at any stage in the business process 
 coordination. Failure of a later step in the process may require earlier steps 
 to be undone using compensating transactions. Handling failures needs 
 careful design to ensure the data maintained by the servers remains 
 consistent.
Modifiability Process modifiability is enhanced because the process definition is 
 encapsulated in the coordinator process. Servers can change their 
 implementation without affecting the coordinator or other servers, as long 
 as their external service definition doesn’t change.
Performance To achieve high performance, the coordinator must be able to handle multiple 
 concurrent requests and manage the state of each as they progress through 
 the process. Also, the performance of any process will be limited by the 
 slowest step, namely the slowest server in the process.
Scalability The coordinator can be replicated to scale the application both up and out. 
 21
 Allocate Components
 Need to:
 Identify the major application components, and how they 
 plug into the framework.
 Identify the interface or services that each component 
 supports.
 Identify the responsibilities of the component, stating what 
 it can be relied upon to do when it receives a request.
 Identify dependencies between components.
 Identify partitions in the architecture that are candidates 
 for distribution over servers in a network
 And independent development
 22
 Some Design Guidelines
 Minimize dependencies between components. Strive for a 
 loosely coupled solution in which changes to one component do 
 not ripple through the architecture, propagating across many 
 components. 
 Remember, every time you change something, you have to re-
 test it.
 Design components that encapsulate a highly “cohesive” set of 
 responsibilities. Cohesion is a measure of how well the parts of 
 a component fit together. 
 Isolate dependencies on middleware and any COTS 
 infrastructure technologies. 
 Use decomposition to structure components hierarchically. 
 Minimize calls between components, as these can prove costly 
 if the components are distributed. 
 23
 A Simple Design Example
 read Write
 Order OrderQ
New OrderInput
Orders
 Get
 Order
 Check Write
 Order Order
 SendEmail
 Validate Store
Error
Log
 Customer Order Email
 System System Server
 Figure Key
 Existing 
 Component Database
 New Persistent 
 Component Queue
 Dependency
 24
 Example Design
 Based on messaging
 Application components are:
 OrderInput: responsible for accessing the new orders 
 database, encapsulating the order processing logic, and writing 
 to the queue.
 Validate: encapsulates the responsibility of interacting with the 
 customer system to carry out validation, and writing to the error 
 logs if an order is invalid.
 Store: responsibility of interacting with the order system to 
 store the order data.
 SendEmail: removes a message from the queue, formats an 
 email message and sends it via an email server. It encapsulates 
 all knowledge of the email format and email server access.
 Clear responsibilities and dependencies
 25
 Architecture Validation
 Aim of the validation phase is to increase confidence of the 
 design team that the architecture is fit for purpose. 
 The validation has to be achieved within the project constraints 
 of time and budget
 The trick is to be as rigorous and efficient as possible.
 Validating an architecture design poses tough challenges.
 „coz it‟s a design that can‟t be executed or tested 
 consists of new and COTS components that have to be 
 integrated
 Two main techniques:
 1. manual testing of the architecture using test scenarios. 
 2. construction of a prototype that creates a simple archetype of the 
 desired application
 aim of both is to identify potential flaws in the design so that they 
 can be improved before implementation commences. 
 Cheaper to fix before built
 26
 Scenarios
 Part of SEI‟s ATAM work 
 Involves defining: 
 some kind of stimulus that will have an impact on the 
 architecture. 
 working out how the architecture responds to this 
 stimulus. 
 If the response is desirable, then a scenario is 
 deemed to be satisfied by the architecture. 
 If the response is undesirable, or hard to quantify, 
 then a flaw or at least an area of risk in the 
 architecture may have been uncovered.
 27
 Scenario Examples
 Quality Stimulus Response
 Attribute
Availability The network connection to the Messages are stored on the MOM server until the 
 message consumers fails. connection is restored. Messages will only be 
 lost if the server fails before the connection 
 comes back up.
Modifiability A new set of data analysis The application needs to be rebuilt with the new 
 components must be made libraries, and the all configuration files must be 
 available in the application. updated on every desktop to make the new 
 components visible in the GUI toolbox.
Security No requests are received on a user The system treats this session as potentially insecure 
 session for ten minutes. and invalidates the security credentials 
 associated with the session. The user must 
 logon again to connect to the application.
Modifiability The supplier of the transformation A new transformation engine must be purchased. 
 engine goes out of business. The abstract service layer that wraps the 
 transformation engine component must be re-
 implemented to support the new engine. Client 
 components are unaffected as they only use the 
 abstract service layer.
Scalability The concurrent user request load The application server is scaled out on a two 
 doubles during the 3 week machine cluster to handle the increased request 
 enrollment period. load. 28
 Scenarios for Order Processing 
 Example
 Quality Stimulus Response
 Attribute
Modifiability The Customer System packaged The Validate component must be rewritten to 
 application is updated to an Oracle interface to the Oracle system.
 database.
Availability The email server fails. Messages build up in the OrderQ until the 
 email server restarts. Messages are then 
 sent by the SendEmail component to 
 remove the backlog. Order processing is 
 not affected.
Reliability The Customer or Order systems are If either fails, order processing halts and alerts 
 unavailable. are sent to system administrators so that 
 the problem can be fixed.
 Needs fixing .
 29
 Prototyping
 Scenarios can‟t address everything:
 “On Friday afternoon, orders must be processed before close-
 of-business to ensure delivery by Monday. Five thousand 
 orders arrive through various channels (Web/Call 
 centre/business partners) five minutes before close-of-
 business.”
 Only one way – build something!
 Proof-of-concept prototype: Can the architecture as 
 designed be built in a way that can satisfy the 
 requirements?
 Proof-of-technology prototype : Does the technology 
 (middleware, integrated applications, libraries, etc) 
 selected to implement the application behave as 
 expected?
 30
 Prototyping Strategy
 Build minimal system required to validate 
 architecture, eg:
 An existing application shows that the queue and 
 email systems are capable of supporting five 
 thousand messages in five minutes
 So:
 Write a test program that calls the Customer System
 validation APIs five thousand times, and time how long 
 this takes.
 Write a test program that calls the Order System store 
 APIs five thousand times, and time how long this takes.
 31
 Prototyping Thoughts
 Prototypes should be used judiciously to help 
 reduce the risks inherent in a design. 
 Only way to address: 
 Performance
 Scalability
 Ease of integration
 Capabilities of off-the-shelf components 
 Need to be carefully scoped and managed. 
 Ideally take a day or two, a week or two at most. 
 Usually thrown-away so keep them cheap
 Don‟t let them acquire a life of their own
 32
 Summary
 3 step, iterative architecture design process
 Can be customized to small/meduim/large projects
 Agnostic to overall process framework (ie RUP, agile, 
 waterfall, etc)
 33