Essential Software
Architecture
Session 1:
Introduction to Software Architecture
1
Session Outline






IT Systems Application Domain
What is Software Architecture?
Definitions
What does an architect do?
Architectures and technologies
Further reading
2
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
3
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
4
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.”
5
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.”
6
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.”
7
Architecture Defines Structure


Decomposition of system in to
components/modules/subsystems
Architecture defines:

Component interfaces


Component communications and dependencies


What a component can do
How components communicate
Component responsibilities

Precisely what a component will do when you ask it
8
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
C2
C3
C4
C1
C3
C2
C4
AL
Third Party
Component
Third Party
Component
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.
Diagram Key
Component
C
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
Dependency
9
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
10
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]
11
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
12
Architecture is an Abstraction

Architecture provides an abstract view of a design



Example – A Marketecture



Hides complexity of design
May or may not be a direct mapping between architecture
elements and software elements
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
13
Decomposition

Hierarchical
decomposition is a
powerful abstraction
mechanism



Partitions design
Allocate components to
development teams
Why isn’t the Client
component
decomposed?
Diagram Key
Top Level Architecture Description
C
Client
Broker
Server
Component
Dependency
Security
Server
Messag
e
Handler
Director
y Server
Request
Handler
Data
Store
14
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
15
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
16
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
17
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
18
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
19
Architectures and Technologies
Abstract
Architectural Patterns/Styles
Application
Servers
Messaging
Message
Brokers
Object
Brokers
Process
Orchestration
Concrete COTS technologies


Each technology has multiple vendors/open source
versions
Architects need to choose technology wisely


Proof of concept prototype
Detailed feature evaluation
20
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
21
Selected Further Reading




L. Bass, P. Clements, R Kazman. Software
Architecture in Practice, Second Edition. AddisonWesley, 2003.
R. Wirfs-Brock, A. McKean. Object Design: Roles,
Responsibilities, and Collaborations. AddisonWesley, 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.
22
Essential Software
Architecture
Session 2:
Introduction to the Case Study
23
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
24
ICDE Schematic
Local information
repositories
Internet
ICDE
Repository
ICDE
Recording Software
Analyst
3rd Party
Tools
25
ICDE Use Cases
ICDE
*
Capture User
Actions
*
*
Analyst
*
*
*
User Assistance
*
Data Store
*
*
*
Query User Actions
*
*
3rd Party Tools
26
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)
27
ICDE version 2.0

ICDE v2.0 scheduled for development in 12
month timeframe


Major changes to:



Fixed schedule, budget
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
28
ICDE v2.0 Business Goals
Business Goal
Encourage third
developers
party
Supporting Technical Objective
tool
Simple and reliable programmatic access to data
store for third party tools
Heterogeneous (i.e. non-Windows)
support for running third party tools
platform
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
workstation
for
each
ICDE
user
29
Architecturally Significant Requirements
for ICDE v2.0

ICDE project requirements:





ICDE Project team 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
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
30
Summary


ICDE is a reasonably complex system
Will be used to illustrate concepts during the
remainder of this course
31
Essential Software
Architecture
Session 3:
Quality Attributes
32
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
33
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.”
34
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”
35
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
36
Performance - Throughput

Measure of the amount of work an application
must perform in unit time



Is required throughput:



Transactions per second
Messages per minute
Average?
Peak?
Many system have low average but high
peak throughput requirements
37
Throughput Example
CPU %
MST (msp)
300
250
200
150
100
50
0
0
5
10
15
20
# of threads

Throughput of a message queuing system



Messages per second (msp)
Maximum sustainable throughput (MST)
Note throughput changes as number of receiving
threads increases
38
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
39
Response Time

Example shows response time distribution for a
J2EE application
40
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.
41
Something to watch for …

What is a





All are application specific measures.
System must achieve 100 mps throughput


Transaction?
Message?
Request?
BAD!!
System must achieve 100 mps peak throughput for
PaymentReceived messages

GOOD!!!
42
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 event
3. Return to user thread
2. Write event
to queue
5. Write event
to ICDE database queue
4. Read event
from queue
43
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
44
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).
45
Scalability – Add more hardware …
Scale-up:
Single application instance is
executed on a multiprocessor
machine
Scale-out: Application replicated on
different machines
Application
Application
CPU
Application
Application
Application
46
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
47
Scalability – J2EE example
2500
2000
WAS SB
TPS
JBoss SB
1500
IAS SB
SS SB
1000
WLS SB
500
BES SB
0
0
200
400
600
800
1000
1200
No. of Clients
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.
48
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 ….
49
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?
50
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
51
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
52
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!
53
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
54
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.
55
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.
56
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
57
Security

Difficult, specialized quality attribute:



Lots of technology available
Requires deep knowledge of approaches and
solutions
Security is a multi-faceted quality …
58
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.
59
Security Approaches







SSL
PKI
Web Services security
JAAS
Operating system security
Database security
Etc etc
60
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
61
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
62
Availability

Period of loss of availability determined by:




Strategies for high availability:




Time to detect failure
Time to correct failure
Time to restart application
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
63
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
64
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
65
Integration Strategies
Interoperability through an API facade
Application
API
Third Party
Application
Data



Interoperability achieved by direct data
access
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 …
66
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.
67
Misc. Quality Attributes

Portability


Testability


Can an application be easily executed on a
different software/hardware platform to the one it
has been developed for?
How easy or difficult is an application to test?
Supportability

How easy an application is to support once it is
deployed?
68
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!
69
Summary



QAs are part of an application’s nonfunctional requirements
Many QAs
Architect must decide which are important for
a given application


Understand implications for application
Understand competing requirements and tradeoffs
70
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
71
Essential Software
Architecture
Session 4:
A Guide to Middleware Architectures
and Technologies
72
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
73
Middleware Classification
Business Process Orchestrators
BizTalk, TIBCO StaffWare, ActiveBPEL
Message Brokers
BizTalk, WebSphere Message Broker, SonicMQ
Application Servers
Transport
J2EE, CCM, .NET
Message-Oriented Middleware, Distributed Objects Systems
74
Outline





CORBA
Message-oriented middleware
J2EE
Message brokers
Business process orchestrators
75
CORBA



Venerable distributed object technology
Still widely used in telecomms, defense
Many different implementations
Client
Server
Object Reference
request
Servant
reply
client ORB
server ORB
Network
76
CORBA Code Example
module ServerExample
{
interface MyObject {
};
Server
string isAlive();
};
CORBA IDL
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 simplicity
MyServant servantRef = lookup(“Myservant”)String
reply = servantRef.isAlive();
Client
77
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
78
Messaging - MOM

Basic Message Oriented Middleware (MOM)
provides features like:


Asynchronous communications between
processes, applications and systems
Send-and-forget


Transactional Messaging


Delivering messages despite failures
Deliver all messages in a transaction, or none
Persistence

Messages can be logged at the server and hence
survive server failure
79
Basic Messaging

Send (queue, message)


Receive (queue, message)


Put message onto queue
Get message from queue
No dependency on state of receiving
application on message send
send
receive
queue
80
Persistence
send



queue
receive
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
81
MOM Server
Receivers
Sending
Applications
Senders
Sending
Applications
Message
Handler Thread Pool
MOM Server
Peer-to-peer MOM technologies are the alternative design
82
MOM Transactions
Begin transaction
...
update database record
put message on queue
...
commit transaction
Begin transaction
...
get message from queue
update database record
...
commit transaction
83
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
Request queue
send
receive
send
receive
Response queue
84
Scaling MOM
MOM Server
ApplicationQ
Senders
Receivers
MOM Server
ApplicationQ
85
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
86
Publish-Subscribe Messaging



Extension of MOM to provide 1-to-N, N-to-1, and N-toN communications
Messages are ‘published’ to logical subjects or topics
Subscribers receive all messages from subjects they
subscribe to
Sub
Pub
Create/
Publish
Subject
Register/
Subscribe
Sub
Sub
87
Publish-Subscribe with Multicast
Subscriber
Subscriber
rvd
rvd
rvrd
Based on
TIBCO
Rendezvous
Publisher
rvd
rvd
Subscriber
rvrd
rvd
Subscriber
rvd
Subscriber
88
Performance
Milliseconds
700
600
500
400
300
200
100
0
MC1
MC2
QB
10
20
30
40
50
No. Of Subscribers
89
Subject/Topic Naming
Sydney
work
DevGroup
SupportGroup
Information
Information
gossip
Sydney
Sydney/DevGroup
Sydney/DevGroup/Information
Sydney/DevGroup/Information/work
Sydney/DevGroup/Information/gossip
Sydney/SupportGroup
Sydney/SupportGroup/Information
Sydney/SupportGroup/Information/work
Sydney/SupportGroup/Information/gossip
work
gossip
Sydney/*/Information
Sydney/DevGroup/*/*
Sydney/DevGroup/**
90
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
91
J2EE Overview
Client tier
Business Component tier
Web Tier
HTTP
Browser-based client
applications
(HTML, applets,
DHTML/scripting)
Web
server
EIS Tier
RMI
Servlets,
JSPs
Application components
EJBs
JCA
ERPs, CRMs,
Mainframe TP systems
Java RMI
Java client applications
Container Services
Components
eg. JTS, JMS
CAS COM Bridge, RMI over IIOP
JDBC
RDBMS
Windows/COM client
applications
92
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
93
EJB Container
Application Server
EJB Container
EJB Pool
Lifecycle Management
Transaction
Service
Directory
Service
Persistence
Connection Pool
Security
Service
Thread Pool
94
Beans and State
state
EJB Container
Stateless bean pool
state
state
state
state
EJB
Clients
state
Stateful beans
state
95
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>
96
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
97
Message Brokers - Motivation
Web
Component
Key:
Message =
In-format
In-format
Legacy
System #1
Queue
Read
In-format
In-format
In-format
In-format
Legacy
System #2
Legacy
System #3
Legacy
System #4
Message
Transform
API
call
Legacyformat
98
What if …



the common In-format message format
changes?
any legacy system API changes?
any of the transformations needs modifying?
99
Alternative Solution
Web
Component
Key:
Message =

In-format

Message
Broker

L1-format
Legacy
System #1
L2-format
Legacy
System #2
L3-format
Legacy
System #3
L4-format
Legacy
System #4
Transformations
in broker
Simplified
endpoints
Decouples Web
and legacy
components
100
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
101
Message Broker Features

Message transformation – transform between different
source/target formats




Intelligent routing


Graphical message format definition and mapping tools
High performance transformation engines
Message format repositories
Route messages based on message content
Rules Engine


Scripting language, built-in functions
Application programming environment
102
Message Brokers
Hub and Spoke Architecture
Input Messages
Output Messages
Transformation
Routing
Rules Processing
103
Example - WMQI
104
BizTalk Mapping Tool
105
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
106
Message Brokers – Some Thoughts

Embeds transformations/routing in broker


Possible scaling issues


Need to replicate brokers
Failure handling


Can get complex
Lightweight, rarely designed to recover from
failure
Often proprietary technology

Good open source, standards-based like Mule
now available
107
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
108
Typical Scenario

Business process
automation
Siebel
Customer
Purchasing
Credit
Validation
Accounts
Payable
Shipping
Sales desk
Accounts
Receivable
Oracle
SAP
Customer
Receiving
109
Example - BizTalk
110
BPO Architecture
Message Broker
Adapter
Adapter
Adapter
111
BPEL


Web Services standard for describing
workflows
Many design and execution tools


Eg ActiveBPEL
Version 2.0 is a significant improvement
112
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
113
Broker Spaghetti


No free lunch …
Just relocates the spaghetti
message broker
114
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
115
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
116
Essential Software
Architecture
Session 5:
A Software Architecture Process
117
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
118
An Architecture Process


Highly iterative
Can scale to small/large projects
Determine
Architectural
Requirements
Architecture
Design
Validation
119
Determine Architectural Requirements

Sometime called:



architecturally significant
requirements
architecture use cases
essentially the quality
and non-functional
requirements for a
system.
Functional
Requirements
Stakeholder
Requirements
Determine
Architecture
Requirements
Architecture
Requirements
120
Examples

A typical architecture requirement :


Some architecture requirements are constraints:



“Communications between components must be
guaranteed to succeed with no message loss”
“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.
121
Quality Attribute Requirements
Quality
Attribute
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.
122
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.
123
Priorities
All requirements are not equal




Tricky in face of conflicts, eg:




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.
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!
124
Architecture Design


Design steps are
iterative
Risk identification is
a crucial output of
the design
Architecture
Requirements
Choose
Architecture
Framework
Allocate
Components
Architecture
Views
Architecture
Document
125
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.
126
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.
Client
Tier
Web
Client
Web
Client
Web Server
Tier
Web Server
Business
Logic Tier
Application Server
Data
Management
Tier
Web
Client
Databases
127
N-Tier Client Server – Quality Attribute
Analysis
Quality
Attribute
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.
128
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.
Client
Client
Client
Que
ue
Server
Server
Server
129
Messaging – Quality Attribute Analysis
Quality
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. Nonreliable 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.
130
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-topoint or broadcast/multicast.
Loose Coupling: As with
messaging, there is no direct
binding between publishers
and subscribers.
Subscriber
Publisher
Topic
Subscriber
Subscriber
131
Publish-Subscribe – Quality Attribute
Analysis
Quality
Attribute
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 nonreliable 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.
132
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.
Sender-1
inPort1
OutPort1
Receiver-1
Broker
Sender-2
Receiver-2
inPort2
OutPort2
133
Broker Pattern - Quality Attribute Analysis
Quality
Attribute
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.
134
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.
Start
process
request
Process
results
Process
Coordinator
step1
step2
Server-1
Server-2
step3
step4
Server-3
Server-4
135
Process Coordinator – Quality Attribute
Analysis
Quality
Attribute
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.
136
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
137
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 retest 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.
138
A Simple Design Example
OrderInput
New
Orders
Check
Order
OrderQ
Write
Order
read
Get
Order
Write
Order
SendEmail
Validate
Store
Error
Log
Customer
System
Order
System
Email
Server
Figure Key
Existing
Component
Database
New
Component
Persistent
Queue
Dependency
139
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
140
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
141
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.
142
Scenario Examples
Quality
Attribute
Stimulus
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 reimplemented 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.
143
Scenarios for Order Processing Example
Quality
Attribute
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 ….
144
Prototyping
Scenarios can’t address everything:


“On Friday afternoon, orders must be processed before closeof-business to ensure delivery by Monday. Five thousand
orders arrive through various channels (Web/Call
centre/business partners) five minutes before close-ofbusiness.”
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?
145
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.
146
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
147
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)
148
Essential Software
Architecture
Session 6:
Documenting a Software Architecture
149
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!
150
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.
151
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.
152
Think carefully about what to document

Project complexity


Project longevity



One-off stop gap software?
Strategic, long-term, will evolve?
Needs of stakeholders




A small project may only need a ‘marketecture’
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
153
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
154
Component Diagram
id Component View
OrderProcessing
«table»
read
writeQ
1
NewOrders
MailQueue
1
1
readQ
validate
1
CustomerSystem
1
1
1
writeQ
1
OrderQueue
readQ
SendEmail
1
send
1
MailServer
OrderSystem
155
Class Diagram
cd OrderProcessing
OrderReader
QueueWriter
1
1
1
Validate
1
1
1
Store
156
Sequence Diagram
sd Interactions
OrderReader
Validate
Store
NewOrders
CustomerSystem
QueueWriter
OrderQueue
MailQueue
readOrderData
success:=
validateOrder
success:=
newOrder
success:=
storeOrder
success:=
writeQueue
success:=
acknowledgeOrderSuccess
success:=
writeQueue
157
Deployment Diagram
dd Deployment View
OrderServer
OrdersDB
MailServer
JDBC
«table»
«executable»
:
OrderProcessing
:NewOrders
SOAP
:MailServer
:SendEmail
CustomerSystem
«executable»
CRM
:
CustomerSystem
MOMServer
:MailQueue
OrderSystem
ERP
«executable»
:OrderQueue
:
OrderSystem
158
Component Interfaces
id Component View
OrderProcessing
«table»
QueueWrite
JDBC
MailQueue
NewOrders
QueueRead
QueueWrite
SendEmail
CustomerServices
OrderQueue
QueueRead
SMTP
MailServer
CustomerSystem
OrderSystem
159
Component Decomposition
id Component View
cd Component View
OrderProcessing
JDBC
QueueWrite
«table»
MailQueue
NewOrders
getOrders
OrderProcessing
writeConfirmation
«delegate»
validateOrder writeOrder
or: OrderReader
QueueRead
qw:
QueueWriter «delegate»
getOrders
QueueWrite
val: Validate
OrderQueue
CustomerServices
QueueRead
st: Store
SMTP
MailServer
validate
CustomerSystem
writeConfirmation
SendEmail
«delegate»
validateOrder
«delegate»
writeOrder
OrderSystem
ProvidedInterface1
160
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
161
Template Headings
Architecture Documentation Template
Project Name: XXX
1
Project Context
2
Architecture Requirements
2.1
Overview of Key Objectives
2.2
Architecture Use Cases
2.3
Stakeholder Architectural Requirements
2.4
Constraints
2.5
Non-functional Requirements
2.6
Risks
3
Solution
3.1
Relevant Architectural Patterns
3.2
Architecture Overview
3.3
Structural Views
3.4
Behavioral Views
3.5
Implementation Issues
4
Architecture Analysis
4.1
Scenario analysis
4.2
Risks
162
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.
163
Essential Software
Architecture
Session 7:
ICDE Case Study Design
164