gorton-esa
TRANSCRIPT
1
Essential Software Architecture
Session 1:
Introduction to Software Architecture
2
Session Outline
IT Systems Application Domain What is Software Architecture? Definitions What does an architect do? Architectures and technologies Further reading
3
IT Systems Application Domain IT systems are everywhere
Banks Shops Internet sites
Large, complex, heterogeneous, distributed applications
Use commercial-of-the-shelf middleware, databases, web servers, application packages
Major problems are architecture design, technology selection, application and business integration
4
What is Software Architecture? It’s about software design
All architecture is software design, but not all design is software architecture
Part of the design process Simply, architecture focuses on ‘issues that
will be difficult/impossible to change once the system is built’ Quality attributes like security, performance Non-functional requirements like cost, deployment
hardware More on these later in this session
5
Defintions - ANSI/IEEE Std 1471-2000 “Architecture is the fundamental
organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”
6
Definitions - SEI
“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.”
7
Definitions – Garlan and Shaw “[Software architecture goes] beyond the algorithms
and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives.”
8
Architecture Defines Structure Decomposition of system in to
components/modules/subsystems Architecture defines:
Component interfaces What a component can do
Component communications and dependencies How components communicate
Component responsibilities Precisely what a component will do when you ask it
9
Structure and Dependencies Excessive component
dependencies are bad! Key architecture issue
Identifying components that may change
Reduce direct dependencies on these components
Creates more modifiable systems
C1
Third Party Component
Diagram Key
Component
Dependency
C1 C2 C3 C4
C
Third Party Component
AL
Four components are directly dependent on a third party component. If the third party component is replaced with a new component with a different interface, changes to each component are likely.
Only the AL (abstraction layer) component is directly dependent on the third party component. If the third party component is replaced, changes are restricted to the AL component only
C2 C4C3
10
Architecture Specifies Component Communication Communication involves:
Data passing mechanisms, e.g.: Function call Remote method invocation Asynchronous message
Control flow Flow of messages between components to achieve
required functionality Sequential Concurrent/parallel Synchronization
11
Architecture Patterns/Styles Patterns catalogue successfully used structures that
facilitate certain kinds of component communication client-server Message broker Pipeline
Patterns have well-known characteristics appropriate for particular types of requirements
Patterns are very useful things … Reusable architectural blueprints Help efficiently communicate a design Large systems comprise a number of individual patterns “Patterns and Styles are the same thing – the patterns
people won” [anonymous SEI member]
12
Architecture addresses NFRs
Non-functional requirements (NFRs) define ‘how’ a system works
NFRs rarely captured in functional requirements Aka. architecture requirements Must be elicited by architect
NFRs include: Technical constraints Business constraints Quality attributes
13
Architecture is an Abstraction
Architecture provides an abstract view of a design Hides complexity of design May or may not be a direct mapping between architecture
elements and software elements Example – A Marketecture
informal depiction of system’s structure and interactions. portray the design philosophies embodied in the
architecture Every system should have a marketecture:
Easy to understand Helps discussion during design, build, review, sales (!)
process
14
Decomposition
Hierarchical decomposition is a powerful abstraction mechanism Partitions design Allocate components to
development teams Why isn’t the Client
component decomposed?
Client Broker Server
Diagram Key
Component
Dependency
C
Top Level Architecture Description
SecurityServer
Message Handler
Directory Server Data
StoreRequest Handler
15
Architecture Views
A software architecture represents a complex design artifact
Many possible ‘views’ of the architecture Cf. with buildings – floor plan, external, electrical,
plumbing, air-conditioning
16
Philippe Krutchen - 4+1 View Model Logical view: describes architecturally significant elements of
the architecture and the relationships between them. Process view: describes the concurrency and communications
elements of an architecture. Physical view: depicts how the major processes and
components are mapped on to the applications hardware. Development view: captures the internal organization of the
software components as held in e.g. a configuration management tool.
Architecture use cases: capture the requirements for the architecture; related to more than one particular view
17
SEI – Views and Beyond Module: structural view of the architecture,
comprising the code modules such as classes, packages and subsystems
Component and Connector: describes the behavioral aspects of the architecture. Components are objects, threads or processes, and connectors describe how components interact.
Allocation: shows how the processes are mapped to hardware and gives a view of the source code in the configuration management systems.
This course will focus on structural and behavioral views
18
What does an Architect do?
Many responsibilities: Liaison with stakeholders Technology knowledge Software engineering Risk managements
Long list at: http://www.sei.cmu.edu/ata/arch_duties.html
19
Architectures and Technologies Architects reduce risks by using proven
design patterns Must map abstract design pattern to concrete
implementation Software vendors have created (COTS)
technologies that explicitly support widely used patterns Makes implementation of patterns easier Reduces risk if technology is well built
20
Architectures and Technologies
Each technology has multiple vendors/open source versions
Architects need to choose technology wisely Proof of concept prototype Detailed feature evaluation
Architectural Patterns/Styles
Application Servers
Messaging Message Brokers
ObjectBrokers
Process Orchestration
Concrete COTS technologies
Abstract
21
Summary
“The life of a software architect is a long (and sometimes painful) succession of sub-optimal decisions made partly in the dark”
Architecture involves complex design decisions
Architect role is much more than just technical design
Made harder by early lifecycle nature of much of the design
22
Selected Further Reading
L. Bass, P. Clements, R Kazman. Software Architecture in Practice, Second Edition. Addison-Wesley, 2003.
R. Wirfs-Brock, A. McKean. Object Design: Roles, Responsibilities, and Collaborations. Addison-Wesley, 2002.
M. Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley, 2002.
I.Gorton, A Liu. Performance Evaluation of Alternative Component Architectures for Enterprise JavaBean Applications, in IEEE Internet Computing, vol.7, no. 3, pages 18-23, 2003.
23
Essential Software Architecture
Session 2:
Introduction to the Case Study
24
ICDE System
Information Capture and Dissemination Environment (ICDE) is a software system for providing intelligent assistance to financial analysts scientific researchers intelligence analysts analysts in other domains
25
ICDE Schematic
ICDE
Mon
itorin
g
ICDERepository
ICDERecording Software
Local information repositories
InternetInternet
Analyst
3rd Party Tools
26
ICDE Use Cases
ICDE
Analyst
3rd Party Tools
Data Store
Capture UserActions
Query User Actions
User Assistance
*
*
**
*
*
*
*
*
*
*
*
27
Case Study Context ICDE version 1.0 in production Basically a complex, raw information capture tool, GUI
for looking at captured data 2 tier client-server, single machine deployment
Java, Perl, SQL, Programmatic access to data through very complex SQL
(38 tables, 46 views)
28
ICDE version 2.0 ICDE v2.0 scheduled for development in 12
month timeframe Fixed schedule, budget
Major changes to: Enhance data capture tools (GUI) Support 3rd party tool integration, testing, data
access and large production scale deployments (100’s of users)
Very few concrete requirements for the 3rd party tool support or release to full production environment
29
ICDE v2.0 Business Goals
Business Goal Supporting Technical Objective
Encourage third party tool developers
Simple and reliable programmatic access to data store for third party tools
Heterogeneous (i.e. non-Windows) platform support for running third party tools
Allow third party tools to communicate with ICDE users from a remote machine
Promote the ICDE concept to users
Scale the data collection and data store components to support up to 150 users at a single site
Low-cost deployment for each ICDE user workstation
30
Architecturally Significant Requirements for ICDE v2.0 ICDE project requirements:
Heterogeneous platform support for access to ICDE data Instantaneous event notification (local/distributed) Over the Internet, secure ICDE data access Ease of programmatic data access
ICDE Project team requirements: Insulate 3rd party projects and ICDE tools from database
evolution Reliability for multi-tool ICDE deployments Scalable infrastructure to support large, shared deployments Minimize license costs for a deployment
Unknowns Minimize dependencies, making unanticipated changes
potentially easier
31
Summary
ICDE is a reasonably complex system Will be used to illustrate concepts during the
remainder of this course
32
Essential Software Architecture
Session 3:
Quality Attributes
33
What are Quality Attributes
Often know as –ilities Reliability Availability Portability Scalability Performance (!)
Part of a system’s NFRs “how” the system achieves its functional
requirements
34
Quality Attribute Specification Architects are often told:
“My application must be fast/secure/scale” Far too imprecise to be any use at all Quality attributes (QAs) must be made
precise/measurable for a given system design, e.g. “It must be possible to scale the deployment from
an initial 100 geographically dispersed user desktops to 10,000 without an increase in effort/cost for installation and configuration.”
35
Quality Attribute Specification QA’s must be concrete But what about testable?
Test scalability by installing system on 10K desktops?
Often careful analysis of a proposed solution is all that is possible
“It’s all talk until the code runs”
36
Performance
Many examples of poor performance in enterprise applications
Performance requires a: Metric of amount of work performed in unit time Deadline that must be met
Enterprise applications often have strict performance requirements, e.g. 1000 transactions per second 3 second average latency for a request
37
Performance - Throughput
Measure of the amount of work an application must perform in unit time Transactions per second Messages per minute
Is required throughput: Average? Peak?
Many system have low average but high peak throughput requirements
38
Throughput Example
0
50
100
150
200
250
300
0 5 10 15 20
# of threads
CPU % MST (msp)
Throughput of a message queuing system Messages per second (msp) Maximum sustainable throughput (MST)
Note throughput changes as number of receiving threads increases
39
Performance - Response Time measure of the latency an application exhibits
in processing a request Usually measured in (milli)seconds Often an important metric for users Is required response time:
Guaranteed? Average?
E.g. 95% of responses in sub-4 seconds, and all within 10 seconds
40
Response Time Example shows response time distribution for a
J2EE application
41
Performance - Deadlines
‘something must be completed before some specified time’ Payroll system must complete by 2am so that
electronic transfers can be sent to bank Weekly accounting run must complete by 6am
Monday so that figures are available to management
Deadlines often associated with batch jobs in IT systems.
42
Something to watch for …
What is a Transaction? Message? Request?
All are application specific measures. System must achieve 100 mps throughput
BAD!! System must achieve 100 mps peak throughput for
PaymentReceived messages GOOD!!!
43
ICDE Performance Issues Response time:
Overheads of trapping user events must be imperceptible to ICDE users
Solution for ICDE client: Decouple user event capture from storage using a queue
1. Trap user event2. Write event to queue
3. Return to user thread 4. Read event from queue
5. Write event to ICDE database queue
44
Scalability
“How well a solution to some problem will work when the size of the problem increases.”
4 common scalability issues in IT systems: Request load Connections Data size Deployments
45
Scalability – Request Load
How does an 100 tps application behave when simultaneous request load grows? E.g. From 100 to 1000 requests per second?
Ideal solution, without additional hardware capacity: as the load increases, throughput remains
constant (i.e. 100 tps), and response time per request increases only linearly (i.e. 10 seconds).
46
Scalability – Add more hardware …
Application
ApplicationApplicationApplication
Application
Scale-out: Application replicated on different machines
Scale-up: Single application instance is executed on a multiprocessor machine
CPU
47
Scalability - reality Adding more hard ware should improve
performance: scalability must be achieved without modifications to
application architecture Reality as always is different! Applications will exhibit a decrease in throughput
and a subsequent exponential increase in response time. increased load causes increased contention for resources
such as CPU, network and memory each request consumes some additional resource (buffer
space, locks, and so on) in the application, and eventually these are exhausted
48
Scalability – J2EE example
0
500
1000
1500
2000
2500
0 200 400 600 800 1000 1200
No. of Clients
TP
S
WAS SB
JBoss SB
IAS SB
SS SB
WLS SB
BES SB
I.Gorton, A Liu, Performance Evaluation of Alternative Component Architectures for Enterprise JavaBean Applications, in IEEE Internet Computing, vol.7, no. 3, pages 18-23, 2003.
49
Scalability - connections
What happens if number of simultaneous connections to an application increases If each connection consumes a resource? Exceed maximum number of connections?
ISP example: Each user connection spawned a new process Virtual memory on each server exceeded at 2000
users Needed to support 100Ks of users Tech crash ….
50
Scalability – Data Size
How does an application behave as the data it processes increases in size? Chat application sees average message size
double? Database table size grows from 1 million to 20
million rows? Image analysis algorithm processes images of
100MB instead of 1MB? Can application/algorithms scale to handle
increased data requirements?
51
Scalability - Deployment
How does effort to install/deploy an application increase as installation base grows? Install new users? Install new servers?
Solutions typically revolve around automatic download/installation E.g. downloading applications from the Internet
52
Scalability thoughts and ICDE Scalability often overlooked.
Major cause of application failure Hard to predict Hard to test/validate Reliance on proven designs and technologies is
essential For ICDE - application should be capable of
handling a peak load of 150 concurrent requests from ICDE clients. Relatively easy to simulate user load to validate
this
53
Modifiability
Modifications to a software system during its lifetime are a fact of life.
Modifiable systems are easier to change/evolve
Modifiability should be assessed in context of how a system is likely to change No need to facilitate changes that are highly
unlikely to occur Over-engineering!
54
Modifiability Modifiability measures how easy it may be to
change an application to cater for new (non-) functional requirements. ‘may’ – nearly always impossible to be certain Must estimate cost/effort
Modifiability measures are only relevant in the context of a given architectural solution. Components Relationships Responsibilities
55
Modifiability Scenarios
Provide access to the application through firewalls in addition to existing “behind the firewall” access.
Incorporate new features for self-service check-out kiosks.
The COTS speech recognition software vendor goes out of business and we need to replace this component.
The application needs to be ported from Linux to the Microsoft Windows platform.
56
Modifiability Analysis
Impact is rarely easy to quantify The best possible is a:
Convincing impact analysis of changes needed A demonstration of how the solution can
accommodate the modification without change. Minimizing dependencies increases
modifiability Changes isolated to single components likely to
be less expensive than those that cause ripple effects across the architecture.
57
Modifiability for ICDE
The range of events trapped and stored by the ICDE client to be expanded.
Third party tools to communicate new message types.
Change database technology used Change server technology used
58
Security
Difficult, specialized quality attribute: Lots of technology available Requires deep knowledge of approaches and
solutions Security is a multi-faceted quality …
59
Security
Authentication: Applications can verify the identity of their users and other applications with which they communicate.
Authorization: Authenticated users and applications have defined access rights to the resources of the system.
Encryption: The messages sent to/from the application are encrypted.
Integrity: This ensures the contents of a message are not altered in transit.
Non-repudiation: The sender of a message has proof of delivery and the receiver is assured of the sender’s identity. This means neither can subsequently refute their participation in the message exchange.
60
Security Approaches
SSL PKI Web Services security JAAS Operating system security Database security Etc etc
61
ICDE Security Requirements
Authentication of ICDE users and third party ICDE tools to ICDE server
Encryption of data to ICDE server from 3rd party tools/users executing remotely over an insecure network
62
Availability
Key requirement for most IT applications Measured by the proportion of the required
time it is useable. E.g. 100% available during business hours No more than 2 hours scheduled downtime per
week 24x7x52 (100% availability)
Related to an application’s reliability Unreliable applications suffer poor availability
63
Availability
Period of loss of availability determined by: Time to detect failure Time to correct failure Time to restart application
Strategies for high availability: Eliminate single points of failure Replication and failover Automatic detection and restart
Recoverability (e.g. a database) the capability to reestablish performance levels and recover
affected data after an application or system failure
64
Availability for ICDE
Achieve 100% availability during business hours
Plenty of scope for downtime for system upgrade, backup and maintenance.
Include mechanisms for component replication and failover
65
Integration
ease with which an application can be incorporated into a broader application context Use component in ways that the designer did not
originally anticipate Typically achieved by:
Programmatic APIs Data integration
66
Integration Strategies
Data – expose application data for access by other components
API – offers services to read/write application data through an abstracted interface
Each has strengths and weaknesses …
Application
Data
Third Party Application
API
Interoperability through an API facade
Interoperability achieved by direct data access
67
ICDE Integration Needs
Revolve around the need to support third party analysis tools.
Well-defined and understood mechanism for third party tools to access data in the ICDE data store.
68
Misc. Quality Attributes
Portability Can an application be easily executed on a
different software/hardware platform to the one it has been developed for?
Testability How easy or difficult is an application to test?
Supportability How easy an application is to support once it is
deployed?
69
Design Trade-offs QAs are rarely orthogonal
They interact, affect each other highly secure system may be difficult to integrate highly available application may trade-off lower
performance for greater availability high performance application may be tied to a given
platform, and hence not be easily portable Architects must create solutions that makes sensible
design compromises not possible to fully satisfy all competing requirements Must satisfy all stakeholder needs This is the difficult bit!
70
Summary
QAs are part of an application’s non-functional requirements
Many QAs Architect must decide which are important for
a given application Understand implications for application Understand competing requirements and trade-
offs
71
Selected Further Reading
L. Chung, B. Nixon, E. Yu, J. Mylopoulos, (Editors). Non-Functional Requirements in Software Engineering Series: The Kluwer International Series in Software Engineering. Vol. 5, Kluwer Academic Publishers. 1999.
J. Ramachandran. Designing Security Architecture Solutions. Wiley & Sons, 2002.
I.Gorton, L. Zhu. Tool Support for Just-in-Time Architecture Reconstruction and Evaluation: An Experience Report. International Conference on Software Engineering (ICSE) 2005, St Loius, USA, ACM Press
72
Essential Software Architecture
Session 4:
A Guide to Middleware Architectures and Technologies
73
Introduction
Middleware is the plumbing or wiring of IT applications
Provides applications with fundamental services for distributed computing
Insulates applications from underlying platform (OS, DBMS, etc) APIs
Lots of middleware exists Different purposes Different vendors Different standards and proprietary technologies
74
Middleware Classification
Business Process Orchestrators
Message Brokers
Application Servers
Transport Message-Oriented Middleware, Distributed Objects Systems
J2EE, CCM, .NET
BizTalk, WebSphere Message Broker, SonicMQ
BizTalk, TIBCO StaffWare, ActiveBPEL
75
Outline
CORBA Message-oriented middleware J2EE Message brokers Business process orchestrators
76
CORBA Venerable distributed object technology Still widely used in telecomms, defense Many different implementations
Network
Client
Object Referencerequest
Server
Servantreply
client ORB server ORB
77
CORBA Code Example
module ServerExample { interface MyObject { string isAlive(); };};
class MyServant extends _MyObjectImplBase { public String isAlive() { return "\nLooks like it…\n"; }}
ORB orb = ORB.init(args, null);MyServant objRef = new MyServant();orb.connect(objRef); ORB orb = ORB.init(args, null);// Lookup is a wrapper that actually access the CORBA Naming // Service directory – details omitted for simplicityMyServant servantRef = lookup(“Myservant”)String reply = servantRef.isAlive();
CORBA IDL
Server
Client
78
CORBA – Some Thoughts
Many associated services, eg Naming Notification Transactions
Synchronous technology, client-server relatively tightly coupled
Remote calls can/will fail State management in server objects creates
‘interesting’ recovery issues
79
Messaging - MOM Basic Message Oriented Middleware (MOM)
provides features like: Asynchronous communications between
processes, applications and systems Send-and-forget
Delivering messages despite failures Transactional Messaging
Deliver all messages in a transaction, or none Persistence
Messages can be logged at the server and hence survive server failure
80
Basic Messaging
Send (queue, message) Put message onto queue
Receive (queue, message) Get message from queue
No dependency on state of receiving application on message send
receivesend
queue
81
Persistence
receivesend
queue
Receipt of message at queue implies message is written to disk log
Removal of message from queue deletes message from disk log
Trade-off performance versus reliability
82
MOM Server
MOM Server
Sending Applications
Senders
Message Handler Thread Pool
Sending Applications
Receivers
Peer-to-peer MOM technologies are the alternative design
83
MOM Transactions
Begin transaction ... update database record put message on queue ... commit transaction
Begin transaction ... get message from queue update database record ... commit transaction
84
MOM Transactions Sender and receiver do *not* share a transaction
Rollback on receiver does not affect the sender (already committed)
‘Synchronous’ operations are not atomic Request/response is 3 transactions not 1
Put to request queue Get from request queue, put to response queue Get from response queue
receivesend
Request queue
Response queuesendreceive
85
Scaling MOMMOM Server
Senders Receivers
MOM Server
ApplicationQ
ApplicationQ
86
Messaging – Some thoughts
Highly attractive asynchronous technology Supports loosely-coupled, dynamic
applications Scales well, high throughput possible Many implementations, various qualities of
service caveat emptor
87
Publish-Subscribe Messaging
Extension of MOM to provide 1-to-N, N-to-1, and N-to-N communications
Messages are ‘published’ to logical subjects or topics Subscribers receive all messages from subjects they
subscribe to
Pub Subject
Sub
Sub
SubCreate/Publish Register/
Subscribe
88
Publish-Subscribe with Multicast
rvd
rvd
Publisher
Subscriber
rvd
Subscriber
rvd
Subscriber
rvrd
rvd
Subscriber
rvd
Subscriber
rvrd
Based on TIBCO Rendezvous
89
Performance
0100200300
400500600700
10 20 30 40 50No. Of Subscribers
Milliseconds
MC1
MC2
QB
90
Subject/Topic NamingSydney
DevGroup SupportGroup
InformationInformation
work gossip work gossip
SydneySydney/DevGroupSydney/DevGroup/InformationSydney/DevGroup/Information/workSydney/DevGroup/Information/gossipSydney/SupportGroupSydney/SupportGroup/InformationSydney/SupportGroup/Information/workSydney/SupportGroup/Information/gossip
Sydney/*/InformationSydney/DevGroup/*/*Sydney/DevGroup/**
91
Publish-Subscribe – Some Thoughts Highly decoupled messaging style
Publishers don’t know about subscribers Subscribers don’t know who is publishing Publishers and Subscribers can dynamically appear
and disappear Issues –
Reliability Transactions Security Performance
92
J2EE Overview
Browser-based clientapplications
(HTML, applets,DHTML/scripting)
Java client applications
ERPs, CRMs,Mainframe TP systems
Servlets,JSPs
Webserver
HTTP
Java RMI
Application componentsEJBs
Client tier Business Component tier EIS TierWeb Tier
Container ServicesComponentseg. JTS, JMS
RDBMS
JDBC
JCA
RMI
Windows/COM clientapplications
CAS COM Bridge, RMI over IIOP
93
J2EE Application Server
In J2EE, the application server container provides the execution environment for the J2EE-specific components EJBs Message-driven beans Connectors
Container provides additional services for hosted components Transactions Security Directory Threading Connection pooling
94
EJB Container
Application Server
EJB Container
TransactionService
DirectoryService
SecurityService
Thread Pool
Connection Pool
Persistence
Lifecycle Management
EJB Pool
95
Beans and State
EJB Container
state
Stateless bean pool
Stateful beans state
state
state
state
state
state
EJBClients
96
Deployment Descriptors<ejb-jar><enterprise-beans> <session>
<ejb-name>EntityStock.BrokerHome</ejb-name><home>db.entitystock.BrokerHome</home><remote>db.entitystock.Broker</remote><ejb-class>db.entitystock.BrokerBean</ejb-class><session-type>Stateless</session-type><transaction-type>Container</transaction-type>
</session> </enterprise-beans> <assembly-descriptor> <container-transaction>
<method> <ejb-name>EntityStock.BrokerHome</ejb-name> <method-intf>Remote</method-intf> <method-name>*</method-name> </method> <trans-attribute>Required</trans-attribute>
</container-transaction> </assembly-descriptor></ejb-jar>
97
J2EE – Some Thoughts
Standards-based, multiple vendors, portable Good open source technology available Quality of implementations varies considerably Java only, wide platform support Performance is good, but varies between suppliers Scalable, fail over support through clustering Good integration with web technologies Supports various design patterns, flexible but more
complex (e.g. stateful beans/scalability, entity beans) Standards evolving, need to monitor
98
Message Brokers - Motivation Web
Component
Legacy System #1
Legacy System #2
Legacy System #3
Legacy System #4
In-format
In-format In-format In-format In-format
Key:Message =
In-format
Message Transform Legacyformat
APIcall
QueueRead
99
What if …
the common In-format message format changes?
any legacy system API changes? any of the transformations needs modifying?
100
Alternative Solution
WebComponent
Legacy System #1
Legacy System #2
Legacy System #3
Legacy System #4
In-format
L1-format L2-format L3-format L4-format
Key:Message =
MessageBroker
Transformations in broker
Simplified endpoints
Decouples Web and legacy components
101
Message Brokers
Developed specifically for Enterprise Application Integration (EAI)
Add new layers of functionality to MOM Message transformation Rules engine Intelligent routing Adapters
Typically (but not necessarily) built on top of a MOM layer
102
Message Broker Features
Message transformation – transform between different source/target formats Graphical message format definition and mapping tools High performance transformation engines Message format repositories
Intelligent routing Route messages based on message content
Rules Engine Scripting language, built-in functions Application programming environment
103
Message Brokers
Transformation
Routing
Rules Processing
Input Messages Output Messages
Hub and Spoke Architecture
104
Example - WMQI
105
BizTalk Mapping Tool
106
Adapters An adapter is a component that resides between
the message broker and the source/target systems
Simplify complexity of end system interface through an abstraction layer
Thin adapters - simple wrappers Thick adapters
Programmable Abstract representation of services and meta-data
Centralized adapters co-located with broker Distributed adapters execute in own process and
may be located with source/target system
107
Message Brokers – Some Thoughts Embeds transformations/routing in broker
Can get complex Possible scaling issues
Need to replicate brokers Failure handling
Lightweight, rarely designed to recover from failure
Often proprietary technology Good open source, standards-based like Mule
now available
108
Business Process Orchestration Commonly known as workflow Aim is to automate business processes which need to
access data and business logic across disparate back-end applications
Builds on EAI to ensure business processes are executed in the defined order using the required data
Builds on middleware providing: Process execution engine Visual process definition tools Process monitoring tools
109
Typical Scenario
Business process automation
CustomerPurchasing
SAPCustomerReceiving
Siebel
Sales deskShipping
CreditValidation
AccountsPayable
AccountsReceivable
Oracle
110
Example - BizTalk
111
BPO Architecture
Message Broker
Adapter Adapter Adapter
112
BPEL
Web Services standard for describing workflows
Many design and execution tools Eg ActiveBPEL
Version 2.0 is a significant improvement
113
Integration Issues – Point-to-Point Point-to-Point evolution Spaghetti architecture, hard to modify potentially (N2-N)
interfaces
1 business process = 4 interfaces
5 business processes = 20 interfaces
114
Broker Spaghetti No free lunch … Just relocates the spaghetti
message broker
115
Enterprise Data Model Source sends message to target with common message format as
payload. Target receives message and transforms common format into its own
local data representation. 2xN transformations, no broker needed Getting agreement is the tough bit …
Enterprise Data Model
116
Summary Middleware:
makes building complex, distributed, concurrent applications simpler.
institutionalizes proven design practices by supporting them in off-the-shelf middleware technologies.
Architect’s job is to ‘mix n’match’ technologies to create appropriate solutions Analyze trade-offs Open-minded (no hammer/nail thinking) No good/evil, its just technology
117
Essential Software Architecture
Session 5:
A Software Architecture Process
118
A Software Architecture Process Architects must be versatile:
Work with the requirements team: The architect plays an important role in requirements gathering by understanding the overall systems needs and ensuring that the appropriate quality attributes are explicit and understood.
Work with various application stakeholders: Architects play a pivotal liaison role by making sure all the application’s stakeholder needs are understood and incorporated into the design.
Lead the technical design team: Defining the application architecture is a design activity.
Work with the project management: Planning, estimates, budgets, schedules
119
An Architecture Process
Highly iterative Can scale to small/large projects
Determine Architectural
Requirements Architecture
Design
Validation
120
Determine Architectural Requirements
Sometime called: architecturally significant
requirements architecture use cases
essentially the quality and non-functional requirements for a system.
FunctionalRequirements
StakeholderRequirements
Architecture Requirements
DetermineArchitecture Requirements
121
Examples
A typical architecture requirement : “Communications between components must be
guaranteed to succeed with no message loss” Some architecture requirements are constraints:
“The system must use the existing IIS-based web server and use Active Server Page to process web requests”
Constraints impose restrictions on the architecture and are (almost always) non-negotiable.
They limit the range of design choices an architect can make.
122
Quality Attribute Requirements
QualityAttribute
Architecture Requirement
Performance Application performance must provide sub-four second response times for 90% of requests.
Security All communications must be authenticated and encrypted using certificates.
Resource Management
The server component must run on a low end office-based server with 512MB memory.
Usability The user interface component must run in an Internet browser to support remote users.
Availability The system must run 24x7x365, with overall availability of 0.99.
Reliability No message loss is allowed, and all message delivery outcomes must be known with 30 seconds
Scalability The application must be able to handle a peak load of 500 concurrent users during the enrollment period.
Modifiability The architecture must support a phased migration from the current Forth Generation Language (4GL) version to a .NET systems technology solution.
123
Constraints
Constraint Architecture Requirement
Business The technology must run as a plug-in for MS BizTalk, as we want to sell this to Microsoft.
Development The system must be written in Java so that we can use existing development staff.
Schedule The first version of this product must be delivered within six months.
Business We want to work closely with and get more development funding from MegaHugeTech Corp, so we need to use their technology in our application.
124
Priorities
All requirements are not equal High: the application must support this requirement. Medium: this requirement will need to be supported at some
stage Low: this is part of the requirements wish list.
Tricky in face of conflicts, eg: Reusability of components in the solution versus rapid
time-to-market. Making components generalized and reusable always takes more time and effort.
Minimal expenditure on COTS products versus reduced development effort/cost. COTS products mean you have to develop less code, but they cost money.
It’s design – not meant to be easy!
125
Architecture Design
Design steps are iterative
Risk identification is a crucial output of the design
ArchitectureRequirements
Architecture Views
Choose Architecture Framework
AllocateComponents
Architecture Document
126
Choosing the Architecture Framework Choose a architecture pattern/patterns that
suit requirements No magic formula Analyze requirements and quality attributed
supported by each pattern Complex architectures require creative
blending of multiple patterns.
127
N-Tier Client Server Pattern
Separation of concerns: Presentation, business and data handling logic are clearly partitioned in different tiers.
Synchronous communications: Communications between tiers is synchronous request-reply. Each tier waits for a response from the other tier before proceeding.
Flexible deployment: There are no restrictions on how a multi-tier application is deployed. All tiers could run on the same machine, or each tier may be deployed on its own machine.
Databases
Application Server
Web Server
Web Client
Web Client
Web Client
Client Tier
Web ServerTier
Business Logic Tier
Data Management Tier
128
N-Tier Client Server – Quality Attribute Analysis
QualityAttribute
Issues
Availability Servers in each tier can be replicated, so that if one fails, others remain available. Overall the application will provide a lower quality of service until the failed server is restored.
Failure handling If a client is communicating with a server that fails, most web and application servers implement transparent failover. This means a client request is, without its knowledge, redirected to a live replica server that can satisfy the request.
Modifiability Separation of concerns enhances modifiability, as the presentation, business and data management logic are all clearly encapsulated. Each can have its internal 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.
129
Messaging Pattern
Asynchronous communications: Clients send requests to the queue, where the message is stored until an application removes it. Configurable QoS: The queue can be configured for high-speed, 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.
ServerServer
ClientClient
ClientQueue Server
130
Messaging – Quality Attribute AnalysisQuality Attribute
Issues
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.
131
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 reliable messaging, the underlying communication mechanism may be point-to-point or broadcast/multicast.
Loose Coupling: As with messaging, there is no direct binding between publishers and subscribers.
Subscriber
Publisher Subscriber
SubscriberTopic
132
Publish-Subscribe – Quality Attribute Analysis
QualityAttribute
Issues
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.
133
Broker Pattern
Hub-and-spoke architecture: The broker acts as a messaging hub, and senders and receivers connect as spokes.
Performs message routing: The broker embeds processing logic to deliver a message received on an input port to an output port.
Performs message transformation: The broker logic transforms the source message type received on the input port to the destination message type required on the output port.
Receiver-2
Sender-1 Receiver-1
Broker
Sender-2
inPort1
inPort2
OutPort1
OutPort2
134
Broker Pattern - Quality Attribute Analysis
QualityAttribute
Issues
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.
135
Process Coordinator Pattern
Process encapsulation: The process coordinator encapsulates the sequence of steps needed to fulfill the business process. The sequence can be arbitrarily complex.
Loose coupling: The server components are unaware of their role in the overall business process, and of the order of the steps in the process.
Flexible communications: Communications between the coordinator and servers can be synchronous or asynchronous.
Server-3Server-2 Server-4
ProcessCoordinator
Server-1
step1
step2 step3 step4
Startprocessrequest
Processresults
136
Process Coordinator – Quality Attribute Analysis
QualityAttribute
Issues
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.
137
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
138
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.
139
A Simple Design Example
Validate
OrderInput
read
NewOrders
OrderQ
Store
CustomerSystem
OrderSystem
SendEmail
EmailServer
WriteOrder
CheckOrder
WriteOrder
GetOrder
Figure KeyExisting Component
New Component
Dependency
Database
Persistent Queue
ErrorLog
140
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
141
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
142
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.
143
Scenario ExamplesQuality
AttributeStimulus Response
Availability The network connection to the message consumers fails.
Messages are stored on the MOM server until the 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 components must be made available in the application.
The application needs to be rebuilt with the new libraries, and the all configuration files must be updated on every desktop to make the new components visible in the GUI toolbox.
Security No requests are received on a user session for ten minutes.
The system treats this session as potentially insecure 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 engine goes out of business.
A new transformation engine must be purchased. 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 doubles during the 3 week enrollment period.
The application server is scaled out on a two machine cluster to handle the increased request load.
144
Scenarios for Order Processing Example
QualityAttribute
Stimulus Response
Modifiability The Customer System packaged application is updated to an Oracle database.
The Validate component must be rewritten to interface to the Oracle system.
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 unavailable.
If either fails, order processing halts and alerts are sent to system administrators so that the problem can be fixed.
Needs fixing ….
145
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?
146
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.
147
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
148
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)
149
Essential Software Architecture
Session 6:
Documenting a Software Architecture
150
Architecture Documentation
Architecture documentation is a thorny issue Commonly there is no documentation
covering the architecture. If it is, it’s out-of-date, inappropriate and basically
not very useful. Also projects that have masses of
architecture related information Sometimes invaluable, but often it’s out-of-date,
inappropriate and not very useful!
151
Documenting an Architecture is good! Others can understand/evaluate the design. We can understand the design after a period
of time. Others in the project team and development
organization can learn from the architecture. We can do analysis on the design, perhaps to
assess its likely performance, or to generate standard metrics.
152
But it’s difficult …
No universally accepted architecture documentation standard.
An architecture can be complex, and documenting it in a comprehensible manner is time consuming and non-trivial.
An architecture has many possible views. Documenting all the potentially useful ones is time consuming and expensive.
An architecture design often evolves Keeping the architecture documents current is often forgotten, especially with time and schedule pressures in a project.
153
Think carefully about what to document Project complexity
A small project may only need a ‘marketecture’ Project longevity
One-off stop gap software? Strategic, long-term, will evolve?
Needs of stakeholders Small team, a whiteboard might be ok Large, dislocated team needs more Integrators? Testers? Programmers?
Need to spend documentation dollars/euros wisely on high value products
154
UML 2.0
UML is a powerful way to document an architecture
Provides a relatively formal, unambiguous description
New features in UML 2.0 appropriate for architectures
Good tools available, some free Can be used to depict various
structural/behavioral architecture views
155
Component Diagramid Component View
OrderProcessing
MailQueue
SendEmail
MailServer
OrderSystem
CustomerSystem OrderQueue
«table»
NewOrders
1validate
1
readQ
1writeQ
1
read
1send
1
1readQ
1
1
writeQ
1
156
Class Diagram
cd OrderProcessing
OrderReader
Validate Store
QueueWriter
1
1
1 1
1
1
157
Sequence Diagramsd Interactions
OrderReader
MailQueue
Validate
OrderQueue
Store QueueWriter
NewOrders CustomerSystem
readOrderData
success:=validateOrder
success:=newOrder
success:=storeOrder
success:=writeQueue
success:=acknowledgeOrderSuccess
success:=writeQueue
158
Deployment Diagramdd Deployment View
OrdersDB
OrderServer
«executable»
:OrderProcessing
«table»
:NewOrders
MOMServer
:MailQueue
:OrderQueue
MailServer
:MailServer
OrderSystem
CustomerSystem
«executable»
:CustomerSystem
«executable»
:OrderSystem
:SendEmail
CRM
ERP
SOAP
JDBC
159
Component Interfacesid Component View
OrderProcessing
MailQueue
SendEmail
MailServer
OrderSystemCustomerSystem
OrderQueue
«table»
NewOrders
JDBC
SMTP
QueueRead
QueueRead
QueueWrite
CustomerServices
QueueWrite
160
Component Decomposition
id Component View
OrderProcessing
validateOrder
getOrders writeConfirmation
writeOrder
MailQueue
SendEmail
MailServer
OrderSystemCustomerSystem
validate
ProvidedInterface1
OrderQueue
«table»
NewOrders
JDBC
QueueWrite
QueueWrite
CustomerServices SMTP
QueueRead
QueueRead
cd Component View
OrderProcessing
getOrders
validateOrder
writeConfirmation
writeOrder
or: OrderReader
val: Validate
qw: QueueWriter
st: Store
«delegate»
«delegate»
«delegate»
«delegate»
161
Document Template
Documentation is easier if there’s a template to use Reduces start-up time for projects by providing
ready-made document structures familiarity gained with the document structure aids
in the efficient capture of project design details. help with the training of new staff
162
Template HeadingsArchitecture Documentation TemplateProject Name: XXX1 Project Context2 Architecture Requirements2.1 Overview of Key Objectives2.2 Architecture Use Cases2.3 Stakeholder Architectural
Requirements2.4 Constraints2.5 Non-functional Requirements2.6 Risks3 Solution3.1 Relevant Architectural Patterns3.2 Architecture Overview3.3 Structural Views3.4 Behavioral Views3.5 Implementation Issues4 Architecture Analysis4.1 Scenario analysis4.2 Risks
163
Summary
Some documentation is nearly always a good idea
Trick is to produce ‘just enough’ and no more requires upfront planning and thinking Commitment to keeps docs current
UML 2.0 makes architecture documentation easier
Some good UML 2.0 tools, try ‘em out.
164
Essential Software Architecture
Session 7:
ICDE Case Study Design