Essential%20Software%20Architecture - PowerPoint PPT Presentation

View by Category
About This Presentation



... response time per request increases only linearly (i. ... Each user connection spawned a new process. Virtual memory on each server exceeded at 2000 users ... – PowerPoint PPT presentation

Number of Views:48
Avg rating:3.0/5.0
Slides: 165
Provided by: IGOR2
Learn more at:


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Essential%20Software%20Architecture

Essential Software Architecture
  • Session 1
  • Introduction to Software Architecture

Session Outline
  • IT Systems Application Domain
  • What is Software Architecture?
  • Definitions
  • What does an architect do?
  • Architectures and technologies
  • Further reading

IT Systems Application Domain
  • IT systems are everywhere
  • Banks
  • Shops
  • Internet sites
  • Large, complex, heterogeneous, distributed
  • Use commercial-of-the-shelf middleware,
    databases, web servers, application packages
  • Major problems are architecture design,
    technology selection, application and business

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
  • More on these later in this session

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

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.

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

Architecture Defines Structure
  • Decomposition of system in to components/modules/s
  • 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

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

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

Architecture Patterns/Styles
  • Patterns catalogue successfully used structures
    that facilitate certain kinds of component
  • 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 and Styles are the same thing the
    patterns people won anonymous SEI member

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

Architecture is an Abstraction
  • Architecture provides an abstract view of a
  • 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
  • portray the design philosophies embodied in the
  • Every system should have a marketecture
  • Easy to understand
  • Helps discussion during design, build, review,
    sales (!) process

  • Hierarchical decomposition is a powerful
    abstraction mechanism
  • Partitions design
  • Allocate components to development teams
  • Why isnt the Client component decomposed?

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

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

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

What does an Architect do?
  • Many responsibilities
  • Liaison with stakeholders
  • Technology knowledge
  • Software engineering
  • Risk managements
  • Long list at
  • http//

Architectures and Technologies
  • Architects reduce risks by using proven design
  • Must map abstract design pattern to concrete
  • Software vendors have created (COTS) technologies
    that explicitly support widely used patterns
  • Makes implementation of patterns easier
  • Reduces risk if technology is well built

Architectures and Technologies
  • Each technology has multiple vendors/open source
  • Architects need to choose technology wisely
  • Proof of concept prototype
  • Detailed feature evaluation

  • 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
  • Made harder by early lifecycle nature of much of
    the design

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,

Essential Software Architecture
  • Session 2
  • Introduction to the Case Study

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

ICDE Schematic
ICDE Monitoring
ICDE Use Cases
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)

ICDE version 2.0
  • ICDE v2.0 scheduled for development in 12 month
  • 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

ICDE v2.0 Business Goals
Business Goal Supporting Technical Objective
Encourage third party tool developers Simple and reliable programmatic access to data store for third party tools
Heterogeneous (i.e. non-Windows) platform support for running third party tools
Allow third party tools to communicate with ICDE users from a remote machine
Promote the ICDE concept to users Scale the data collection and data store components to support up to 150 users at a single site
Low-cost deployment for each ICDE user workstation
Architecturally Significant Requirements for ICDE
  • ICDE project requirements
  • Heterogeneous platform support for access to ICDE
  • Instantaneous event notification
  • 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
  • Minimize license costs for a deployment
  • Unknowns
  • Minimize dependencies, making unanticipated
    changes potentially easier

  • ICDE is a reasonably complex system
  • Will be used to illustrate concepts during the
    remainder of this course

Essential Software Architecture
  • Session 3
  • Quality Attributes

What are Quality Attributes
  • Often know as ilities
  • Reliability
  • Availability
  • Portability
  • Scalability
  • Performance (!)
  • Part of a systems NFRs
  • how the system achieves its functional

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,
  • 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.

Quality Attribute Specification
  • QAs must be concrete
  • But what about testable?
  • Test scalability by installing system on 10K
  • Often careful analysis of a proposed solution is
    all that is possible
  • Its all talk until the code runs

  • Many examples of poor performance in enterprise
  • 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

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

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

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

Response Time
  • Example shows response time distribution for a
    J2EE application

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

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

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

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

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
  • as the load increases, throughput remains
    constant (i.e. 100 tps), and response time per
    request increases only linearly (i.e. 10

Scalability Add more hardware
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

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,
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
  • Needed to support 100Ks of users
  • Tech crash .

Scalability Data Size
  • How does an application behave as the data it
    processes increases in size?
  • Chat application sees average message size
  • 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?

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
  • E.g. downloading applications from the Internet

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

  • 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!

  • 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

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
  • The application needs to be ported from Linux to
    the Microsoft Windows platform.

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.

Modifiability for ICDE
  • The range of events trapped and stored by the
    ICDE client to be expanded.
  • Third party tools to communicate new message
  • Change database technology used
  • Change server technology used

  • Difficult, specialized quality attribute
  • Lots of technology available
  • Requires deep knowledge of approaches and
  • Security is a multi-faceted quality

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

Security Approaches
  • SSL
  • PKI
  • Web Services security
  • JAAS
  • Operating system security
  • Database security
  • Etc etc

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

  • 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

  • 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

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

  • 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

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

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

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

Design Trade-offs
  • QAs are rarely orthogonal
  • They interact, affect each other
  • highly secure system may be difficult to
  • 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
  • Must satisfy all stakeholder needs
  • This is the difficult bit!

  • QAs are part of an applications non-functional
  • Many QAs
  • Architect must decide which are important for a
    given application
  • Understand implications for application
  • Understand competing requirements and trade-offs

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

Essential Software Architecture
  • Session 4
  • A Guide to Middleware Architectures and

  • Middleware is the plumbing or wiring of IT
  • 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

Middleware Classification
  • Message-oriented middleware
  • J2EE
  • Message brokers
  • Business process orchestrators

  • Venerable distributed object technology
  • Still widely used in telecomms, defense
  • Many different implementations

CORBA Code Example
module ServerExample interface MyObject
string isAlive()
class MyServant extends _MyObjectImplBase
public String isAlive() return "\nLooks
like it\n"
ORB orb ORB.init(args, null) MyServant objRef
new MyServant() orb.connect(objRef) ORB orb
ORB.init(args, null) // Lookup is a wrapper
that actually access the CORBA Naming // Service
directory details omitted for
simplicity MyServant servantRef
lookup(Myservant)String reply
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

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

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

  • 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

MOM Server
Peer-to-peer MOM technologies are the alternative
MOM Transactions
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
Response queue
Scaling MOM
Messaging Some thoughts
  • Highly attractive asynchronous technology
  • Supports loosely-coupled, dynamic applications
  • Scales well, high throughput possible
  • Many implementations, various qualities of
  • caveat emptor

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
  • Subscribers receive all messages from subjects
    they subscribe to

Create/ Publish
Register/ Subscribe
Publish-Subscribe with Multicast
Based on TIBCO Rendezvous
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
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

J2EE Overview
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
  • Transactions
  • Security
  • Directory
  • Threading
  • Connection pooling

EJB Container
Beans and State
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
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

Message Brokers - Motivation
What if
  • the common In-format message format changes?
  • any legacy system API changes?
  • any of the transformations needs modifying?

Alternative Solution
  • Transformations in broker
  • Simplified endpoints
  • Decouples Web and legacy components

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

Message Broker Features
  • Message transformation transform between
    different source/target formats
  • Graphical message format definition and mapping
  • 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

Message Brokers
Hub and Spoke Architecture
Input Messages
Output Messages
Rules Processing
Example - WMQI
BizTalk Mapping Tool
  • 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

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
  • Often proprietary technology
  • Good open source, standards-based like Mule now

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
  • Builds on middleware providing
  • Process execution engine
  • Visual process definition tools
  • Process monitoring tools

Typical Scenario
  • Business process automation

Example - BizTalk
BPO Architecture
Message Broker
  • Web Services standard for describing workflows
  • Many design and execution tools
  • Eg ActiveBPEL
  • Version 2.0 is a significant improvement

Integration Issues Point-to-Point
  • Point-to-Point evolution
  • Spaghetti architecture, hard to modify
    potentially (N2-N) interfaces

Broker Spaghetti
  • No free lunch
  • Just relocates the spaghetti

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

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

Essential Software Architecture
  • Session 5
  • A Software Architecture Process

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

An Architecture Process
  • Highly iterative
  • Can scale to small/large projects

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

  • 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
  • Constraints impose restrictions on the
    architecture and are (almost always)
  • They limit the range of design choices an
    architect can make.

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.
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.
  • All requirements are not equal
  • High the application must support this
  • 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
  • Its design not meant to be easy!

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

Choosing the Architecture Framework
  • Choose a architecture pattern/patterns that suit
  • No magic formula
  • Analyze requirements and quality attributed
    supported by each pattern
  • Complex architectures require creative blending
    of multiple patterns.

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.

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

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. Non-reliable messaging is faster than reliable, with the difference dependent of the quality of the messaging technology used.
Scalability Queues can be hosted on the communicating endpoints, or be replicated across clusters of messaging servers hosted on a single or multiple server machines. This makes messaging a highly scalable solution.
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
  • Loose Coupling As with messaging, there is no
    direct binding between publishers and

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 non-reliable messaging faster than reliable. If a publish-subscribe broker supports multicast/broadcast, it will deliver multiple messages in a more uniform time to each subscriber.
Scalability Topics can be replicated across clusters of servers hosted on a single or multiple server machines. Clusters of server can scale to provide very high message volume throughput. Also, multicast/broadcast solutions scale better than their point-to-point counterparts.
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.

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

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 doesnt 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.
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
  • And independent development

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
  • Isolate dependencies on middleware and any COTS
    infrastructure technologies.
  • Use decomposition to structure components
  • Minimize calls between components, as these can
    prove costly if the components are distributed.

A Simple Design Example
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

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
  • Validating an architecture design poses tough
  • coz its a design that cant be executed or
  • consists of new and COTS components that have to
    be integrated
  • Two main techniques
  • manual testing of the architecture using test
  • 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

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

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 re-implemented to support the new engine. Client components are unaffected as they only use the abstract service layer.
Scalability The concurrent user request load doubles during the 3 week enrollment period. The application server is scaled out on a two machine cluster to handle the increased request load.
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 .
  • 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?

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.

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

  • 3 step, iterative architecture design process
  • Can be customized to small/meduim/large projects
  • Agnostic to overall process framework (ie RUP,
    agile, waterfall, etc)

Essential Software Architecture
  • Session 6
  • Documenting a Software Architecture

Architecture Documentation
  • Architecture documentation is a thorny issue
  • Commonly there is no documentation covering the
  • 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!