Essential Software Architecture

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?

• Its 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/s
  ubsystems
• 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

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 systems 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 isnt the Client component decomposed?

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 - 41 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

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 Monitoring
26
ICDE Use Cases
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
  (100s of users)
• Very few concrete requirements for the 3rd party
  tool support or release to full production
  environment

29
ICDE v2.0 Business Goals
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 systems 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

• QAs 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
• Its 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

• 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

5. Write event to ICDE database queue
2. Write event to queue
1. Trap user event
4. Read event from queue
3. Return to user thread
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
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
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 senders 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 applications 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

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 applications 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
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

77
CORBA Code Example
module ServerExample interface MyObject
string isAlive()
CORBA IDL
class MyServant extends _MyObjectImplBase
public String isAlive() return "\nLooks
like it\n"
Server
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
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

receive
send
queue
81
Persistence
queue
receive
send

• 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
Peer-to-peer MOM technologies are the alternative
design
83
MOM Transactions
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

Request queue
receive
send
send
receive
Response queue
85
Scaling MOM
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

Sub
Create/ Publish
Register/ Subscribe
Pub
Subject
Sub
Sub
88
Publish-Subscribe with Multicast
Based on TIBCO Rendezvous
89
Performance
90
Subject/Topic Naming
Sydney Sydney/DevGroup Sydney/DevGroup/Information
Sydney/DevGroup/Information/work Sydney/DevGroup/
Information/gossip Sydney/SupportGroup Sydney/Supp
ortGroup/Information Sydney/SupportGroup/Informati
on/work Sydney/SupportGroup/Information/gossip
Sydney//Information Sydney/DevGroup// Sydney/De
vGroup/
91
Publish-Subscribe Some Thoughts

• Highly decoupled messaging style
• Publishers dont know about subscribers
• Subscribers dont know who is publishing
• Publishers and Subscribers can dynamically appear
  and disappear
• Issues
• Reliability
• Transactions
• Security
• Performance

92
J2EE Overview
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
95
Beans and State
96
Deployment Descriptors
ltejb-jargt ltenterprise-beansgt ltsessiongt ltejb-na
megtEntityStock.BrokerHomelt/ejb-namegt lthomegtdb.en
titystock.BrokerHomelt/homegt ltremotegtdb.entitysto
ck.Brokerlt/remotegt ltejb-classgtdb.entitystock.Bro
kerBeanlt/ejb-classgt ltsession-typegtStatelesslt/ses
sion-typegt lttransaction-typegtContainerlt/transact
ion-typegt lt/sessiongt lt/enterprise-beansgt
ltassembly-descriptorgt ltcontainer-transactiongt
ltmethodgt ltejb-namegtEntityStock.BrokerHome
lt/ejb-namegt ltmethod-intfgtRemotelt/method-intf
gt ltmethod-namegtlt/method-namegt
lt/methodgt lttrans-attributegtRequiredlt/trans-att
ributegt lt/container-transactiongt
lt/assembly-descriptorgt lt/ejb-jargt
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
99
What if

• the common In-format message format changes?
• any legacy system API changes?
• any of the transformations needs modifying?

100
Alternative Solution

• 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
Hub and Spoke Architecture
Input Messages
Output Messages
Transformation
Routing
Rules Processing
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

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

114
Broker Spaghetti

• No free lunch
• Just relocates the spaghetti

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

116
Summary

• Middleware
• makes building complex, distributed, concurrent
  applications simpler.
• institutionalizes proven design practices by
  supporting them in off-the-shelf middleware
  technologies.
• Architects job is to mix nmatch 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 applications 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

120
Determine Architectural Requirements

• Sometime called
• architecturally significant requirements
• architecture use cases
• essentially the quality and non-functional
  requirements for a system.

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
123
Constraints
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.
• Its design not meant to be easy!

125
Architecture Design

• Design steps are iterative
• Risk identification is a crucial output of the
  design

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.

128
N-Tier Client Server Quality Attribute Analysis
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.

130
Messaging Quality Attribute Analysis
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.

132
Publish-Subscribe Quality Attribute Analysis
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.

134
Broker Pattern - Quality Attribute Analysis
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.

136
Process Coordinator Quality Attribute Analysis
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
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 its a design that cant be executed or
  tested
• consists of new and COTS components that have to
  be integrated
• Two main techniques
• manual testing of the architecture using test
  scenarios.
• 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 SEIs 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 Examples
144
Scenarios for Order Processing Example
Needs fixing .
145
Prototyping

• Scenarios cant 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
• Dont 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, its out-of-date, inappropriate and
  basically not very useful.
• Also projects that have masses of architecture
  related information
• Sometimes invaluable, but often its 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 its 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/behaviora
  l architecture views

155
Component Diagram
156
Class Diagram
157
Sequence Diagram
158
Deployment Diagram
159
Component Interfaces
160
Component Decomposition
161
Document Template

• Documentation is easier if theres 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 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
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