Essential%20Software%20Architecture - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

Essential%20Software%20Architecture

Description:

... 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: http://cs.calstatela.edu
Category:

less

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

Title: Essential%20Software%20Architecture


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
Business Goal Supporting Technical Objective
Encourage third party tool developers Simple and reliable programmatic access to data store for third party tools
Heterogeneous (i.e. non-Windows) platform support for running third party tools
Allow third party tools to communicate with ICDE users from a remote machine
Promote the ICDE concept to users Scale the data collection and data store components to support up to 150 users at a single site
Low-cost deployment for each ICDE user workstation
30
Architecturally Significant Requirements for ICDE
v2.0
  • ICDE project requirements
  • Heterogeneous platform support for access to ICDE
    data
  • Instantaneous event notification
    (local/distributed)
  • Over the Internet, secure ICDE data access
  • Ease of programmatic data access
  • ICDE Project team requirements
  • Insulate 3rd party projects and ICDE tools from
    database evolution
  • Reliability for multi-tool ICDE deployments
  • Scalable infrastructure to support large, shared
    deployments
  • Minimize license costs for a deployment
  • Unknowns
  • Minimize dependencies, making unanticipated
    changes potentially easier

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

32
Essential Software Architecture
  • Session 3
  • Quality Attributes

33
What are Quality Attributes
  • Often know as ilities
  • Reliability
  • Availability
  • Portability
  • Scalability
  • Performance (!)
  • Part of a 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
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.
123
Constraints
Constraint Architecture Requirement
Business The technology must run as a plug-in for MS BizTalk, as we want to sell this to Microsoft.
Development The system must be written in Java so that we can use existing development staff.
Schedule The first version of this product must be delivered within six months.
Business We want to work closely with and get more development funding from MegaHugeTech Corp, so we need to use their technology in our application.
124
Priorities
  • All requirements are not equal
  • High the application must support this
    requirement.
  • Medium this requirement will need to be
    supported at some stage
  • Low this is part of the requirements wish list.
  • Tricky in face of conflicts, eg
  • Reusability of components in the solution versus
    rapid time-to-market. Making components
    generalized and reusable always takes more time
    and effort.
  • Minimal expenditure on COTS products versus
    reduced development effort/cost. COTS products
    mean you have to develop less code, but they cost
    money.
  • 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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
144
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 .
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
Documentin
About PowerShow.com