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 applications

Use commercial-of-the-shelf middleware, databases, web servers, application packages

Major problems are architecture design, technology selection, application and business integration

What is Software Architecture? It’s about software design

All architecture is software design, but not all design is software architecture

Part of the design process Simply, architecture focuses on ‘issues that

will be difficult/impossible to change once the system is built’ Quality attributes like security, performance Non-functional requirements like cost, deployment

hardware More on these later in this session

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

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

Architecture Defines Structure Decomposition of system in to

components/modules/subsystems Architecture defines:

Component interfaces What a component can do

Component communications and dependencies How components communicate

Component responsibilities Precisely what a component will do when you ask it

Structure and Dependencies Excessive component

dependencies are bad! Key architecture issue

Identifying components that may change

Reduce direct dependencies on these components

Creates more modifiable systems

C1

Third Party Component

Diagram Key

Component

Dependency

C1 C2 C3 C4

C

Third Party Component

AL

Four components are directly dependent on a third party component. If the third party component is replaced with a new component with a different interface, changes to each component are likely.

Only the AL (abstraction layer) component is directly dependent on the third party component. If the third party component is replaced, changes are restricted to the AL component only

C2 C4C3

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

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 design Hides complexity of design May or may not be a direct mapping between architecture

elements and software elements Example – A Marketecture

informal depiction of system’s structure and interactions. portray the design philosophies embodied in the

architecture Every system should have a marketecture:

Easy to understand Helps discussion during design, build, review, sales (!)

process

Decomposition

Hierarchical decomposition is a powerful abstraction mechanism Partitions design Allocate components to

development teams Why isn’t the Client

component decomposed?

Client Broker Server

Diagram Key

Component

Dependency

C

Top Level Architecture Description

SecurityServer

Message Handler

Directory Server Data

StoreRequest Handler

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 - 4+1 View Model Logical view: describes architecturally significant elements of

the architecture and the relationships between them. Process view: describes the concurrency and communications

elements of an architecture. Physical view: depicts how the major processes and

components are mapped on to the applications hardware. Development view: captures the internal organization of the

software components as held in e.g. a configuration management tool.

Architecture use cases: capture the requirements for the architecture; related to more than one particular view

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://www.sei.cmu.edu/ata/arch_duties.html

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

Architectures and Technologies

Each technology has multiple vendors/open source versions

Architects need to choose technology wisely Proof of concept prototype Detailed feature evaluation

Architectural Patterns/Styles

Application Servers

Messaging Message Brokers

ObjectBrokers

Process Orchestration

Concrete COTS technologies

Abstract

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

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.

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

Mon

itorin

g

ICDERepository

ICDERecording Software

Local information repositories

InternetInternet

Analyst

3rd Party Tools

ICDE Use Cases

ICDE

Analyst

3rd Party Tools

Data Store

Capture UserActions

Query User Actions

User Assistance

*

*

**

*

*

*

*

*

*

*

*

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 timeframe Fixed schedule, budget

Major changes to: Enhance data capture tools (GUI) Support 3rd party tool integration, testing, data

access and large production scale deployments (100’s of users)

Very few concrete requirements for the 3rd party tool support or release to full production environment

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

Summary

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 system’s NFRs “how” the system achieves its functional

requirements

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

Quality Attribute Specification QA’s must be concrete But what about testable?

Test scalability by installing system on 10K desktops?

Often careful analysis of a proposed solution is all that is possible

“It’s all talk until the code runs”

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

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

0

50

100

150

200

250

300

0 5 10 15 20

# of threads

CPU % MST (msp)

Throughput of a message queuing system Messages per second (msp) Maximum sustainable throughput (MST)

Note throughput changes as number of receiving threads increases

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

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 queue

1. Trap user event2. Write event to queue

3. Return to user thread 4. Read event from queue

5. Write event to ICDE database queue

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

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

Scalability – Add more hardware …

Application

ApplicationApplicationApplication

Application

Scale-out: Application replicated on different machines

Scale-up: Single application instance is executed on a multiprocessor machine

CPU

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

0

500

1000

1500

2000

2500

0 200 400 600 800 1000 1200

No. of Clients

TP

S

WAS SB

JBoss SB

IAS SB

SS SB

WLS SB

BES SB

I.Gorton, A Liu, Performance Evaluation of Alternative Component Architectures for Enterprise JavaBean Applications, in IEEE Internet Computing, vol.7, no. 3, pages 18-23, 2003.

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

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?

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

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

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!

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

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.

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

Change database technology used Change server technology used

Security

Difficult, specialized quality attribute: Lots of technology available Requires deep knowledge of approaches and

solutions Security is a multi-faceted quality …

Security

Authentication: Applications can verify the identity of their users and other applications with which they communicate.

Authorization: Authenticated users and applications have defined access rights to the resources of the system.

Encryption: The messages sent to/from the application are encrypted.

Integrity: This ensures the contents of a message are not altered in transit.

Non-repudiation: The sender of a message has proof of delivery and the receiver is assured of the sender’s identity. This means neither can subsequently refute their participation in the message exchange.

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 network

Availability

Key requirement for most IT applications Measured by the proportion of the required

time it is useable. E.g. 100% available during business hours No more than 2 hours scheduled downtime per

week 24x7x52 (100% availability)

Related to an application’s reliability Unreliable applications suffer poor availability

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 failover

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

Integration Strategies

Data – expose application data for access by other components

API – offers services to read/write application data through an abstracted interface

Each has strengths and weaknesses …

Application

Data

Third Party Application

API

Interoperability through an API facade

Interoperability achieved by direct data access

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.

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?

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!

Summary

QAs are part of an application’s non-functional requirements

Many QAs Architect must decide which are important for

a given application Understand implications for application Understand competing requirements and trade-

offs

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 Technologies

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

Middleware Classification

Business Process Orchestrators

Message Brokers

Application Servers

Transport Message-Oriented Middleware, Distributed Objects Systems

J2EE, CCM, .NET

BizTalk, WebSphere Message Broker, SonicMQ

BizTalk, TIBCO StaffWare, ActiveBPEL

Outline

CORBA Message-oriented middleware J2EE Message brokers Business process orchestrators

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

Network

Client

Object Referencerequest

Server

Servantreply

client ORB server ORB

CORBA Code Example

module ServerExample { interface MyObject { string isAlive(); };};

class MyServant extends _MyObjectImplBase { public String isAlive() { return "\nLooks like it…\n"; }}

ORB orb = ORB.init(args, null);MyServant objRef = new MyServant();orb.connect(objRef); ORB orb = ORB.init(args, null);// Lookup is a wrapper that actually access the CORBA Naming // Service directory – details omitted for simplicityMyServant servantRef = lookup(“Myservant”)String reply = servantRef.isAlive();

CORBA IDL

Server

Client

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

receivesend

queue

Persistence

receivesend

queue

Receipt of message at queue implies message is written to disk log

Removal of message from queue deletes message from disk log

Trade-off performance versus reliability

MOM Server

MOM Server

Sending Applications

Senders

Message Handler Thread Pool

Sending Applications

Receivers

Peer-to-peer MOM technologies are the alternative design

MOM Transactions

Begin transaction ... update database record put message on queue ... commit transaction

Begin transaction ... get message from queue update database record ... commit transaction

MOM Transactions Sender and receiver do *not* share a transaction

Rollback on receiver does not affect the sender (already committed)

‘Synchronous’ operations are not atomic Request/response is 3 transactions not 1

Put to request queue Get from request queue, put to response queue Get from response queue

receivesend

Request queue

Response queuesendreceive

Scaling MOMMOM Server

Senders Receivers

MOM Server

ApplicationQ

ApplicationQ

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

Publish-Subscribe Messaging

Extension of MOM to provide 1-to-N, N-to-1, and N-to-N communications

Messages are ‘published’ to logical subjects or topics Subscribers receive all messages from subjects they

subscribe to

Pub Subject

Sub

Sub

SubCreate/Publish Register/

Subscribe

Publish-Subscribe with Multicast

rvd

rvd

Publisher

Subscriber

rvd

Subscriber

rvd

Subscriber

rvrd

rvd

Subscriber

rvd

Subscriber

rvrd

Based on TIBCO Rendezvous

Performance

0100200300

400500600700

10 20 30 40 50No. Of Subscribers

Milliseconds

MC1

MC2

QB

Subject/Topic NamingSydney

DevGroup SupportGroup

InformationInformation

work gossip work gossip

SydneySydney/DevGroupSydney/DevGroup/InformationSydney/DevGroup/Information/workSydney/DevGroup/Information/gossipSydney/SupportGroupSydney/SupportGroup/InformationSydney/SupportGroup/Information/workSydney/SupportGroup/Information/gossip

Sydney/*/InformationSydney/DevGroup/*/*Sydney/DevGroup/**

Publish-Subscribe – Some Thoughts Highly decoupled messaging style

Publishers don’t know about subscribers Subscribers don’t know who is publishing Publishers and Subscribers can dynamically appear

and disappear Issues –

Reliability Transactions Security Performance

J2EE Overview

Browser-based clientapplications

(HTML, applets,DHTML/scripting)

Java client applications

ERPs, CRMs,Mainframe TP systems

Servlets,JSPs

Webserver

HTTP

Java RMI

Application componentsEJBs

Client tier Business Component tier EIS TierWeb Tier

Container ServicesComponentseg. JTS, JMS

RDBMS

JDBC

JCA

RMI

Windows/COM clientapplications

CAS COM Bridge, RMI over IIOP

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

EJB Container

Application Server

EJB Container

TransactionService

DirectoryService

SecurityService

Thread Pool

Connection Pool

Persistence

Lifecycle Management

EJB Pool

Beans and State

EJB Container

state

Stateless bean pool

Stateful beans state

state

state

state

state

state

EJBClients

Deployment Descriptors<ejb-jar><enterprise-beans> <session>

<ejb-name>EntityStock.BrokerHome</ejb-name><home>db.entitystock.BrokerHome</home><remote>db.entitystock.Broker</remote><ejb-class>db.entitystock.BrokerBean</ejb-class><session-type>Stateless</session-type><transaction-type>Container</transaction-type>

</session> </enterprise-beans> <assembly-descriptor> <container-transaction>

<method> <ejb-name>EntityStock.BrokerHome</ejb-name> <method-intf>Remote</method-intf> <method-name>*</method-name> </method> <trans-attribute>Required</trans-attribute>

</container-transaction> </assembly-descriptor></ejb-jar>

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 Web

Component

Legacy System #1

Legacy System #2

Legacy System #3

Legacy System #4

In-format

In-format In-format In-format In-format

Key:Message =

In-format

Message Transform Legacyformat

APIcall

QueueRead

What if …

the common In-format message format changes?

any legacy system API changes? any of the transformations needs modifying?

Alternative Solution

WebComponent

Legacy System #1

Legacy System #2

Legacy System #3

Legacy System #4

In-format

L1-format L2-format L3-format L4-format

Key:Message =

MessageBroker

Transformations in broker

Simplified endpoints

Decouples Web and legacy components

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

Message Brokers

Transformation

Routing

Rules Processing

Input Messages Output Messages

Hub and Spoke Architecture

Example - WMQI

BizTalk Mapping Tool

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

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

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

Typical Scenario

Business process automation

CustomerPurchasing

SAPCustomerReceiving

Siebel

Sales deskShipping

CreditValidation

AccountsPayable

AccountsReceivable

Oracle

Example - BizTalk

BPO Architecture

Message Broker

Adapter Adapter Adapter

BPEL

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

1 business process = 4 interfaces

5 business processes = 20 interfaces

Broker Spaghetti No free lunch … Just relocates the spaghetti

message broker

Enterprise Data Model Source sends message to target with common message format as

payload. Target receives message and transforms common format into its own

local data representation. 2xN transformations, no broker needed Getting agreement is the tough bit …

Enterprise Data Model

Summary Middleware:

makes building complex, distributed, concurrent applications simpler.

institutionalizes proven design practices by supporting them in off-the-shelf middleware technologies.

Architect’s job is to ‘mix n’match’ technologies to create appropriate solutions Analyze trade-offs Open-minded (no hammer/nail thinking) No good/evil, its just technology

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 application’s stakeholder needs are understood and incorporated into the design.

Lead the technical design team: Defining the application architecture is a design activity.

Work with the project management: Planning, estimates, budgets, schedules

An Architecture Process

Highly iterative Can scale to small/large projects

Determine Architectural

Requirements Architecture

Design

Validation

Determine Architectural Requirements

Sometime called: architecturally significant

requirements architecture use cases

essentially the quality and non-functional requirements for a system.

FunctionalRequirements

StakeholderRequirements

Architecture Requirements

DetermineArchitecture Requirements

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.

Quality Attribute Requirements

QualityAttribute

Architecture Requirement

Performance Application performance must provide sub-four second response times for 90% of requests.

Security All communications must be authenticated and encrypted using certificates.

Resource Management

The server component must run on a low end office-based server with 512MB memory.

Usability The user interface component must run in an Internet browser to support remote users.

Availability The system must run 24x7x365, with overall availability of 0.99.

Reliability No message loss is allowed, and all message delivery outcomes must be known with 30 seconds

Scalability The application must be able to handle a peak load of 500 concurrent users during the enrollment period.

Modifiability The architecture must support a phased migration from the current Forth Generation Language (4GL) version to a .NET systems technology solution.

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.

Priorities

All requirements are not equal High: the application must support this requirement. Medium: this requirement will need to be supported at some

stage Low: this is part of the requirements wish list.

Tricky in face of conflicts, eg: Reusability of components in the solution versus rapid

time-to-market. Making components generalized and reusable always takes more time and effort.

Minimal expenditure on COTS products versus reduced development effort/cost. COTS products mean you have to develop less code, but they cost money.

It’s design – not meant to be easy!

Architecture Design

Design steps are iterative

Risk identification is a crucial output of the design

ArchitectureRequirements

Architecture Views

Choose Architecture Framework

AllocateComponents

Architecture Document

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.

N-Tier Client Server Pattern

Separation of concerns: Presentation, business and data handling logic are clearly partitioned in different tiers.

Synchronous communications: Communications between tiers is synchronous request-reply. Each tier waits for a response from the other tier before proceeding.

Flexible deployment: There are no restrictions on how a multi-tier application is deployed. All tiers could run on the same machine, or each tier may be deployed on its own machine.

Databases

Application Server

Web Server

Web Client

Web Client

Web Client

Client Tier

Web ServerTier

Business Logic Tier

Data Management Tier

N-Tier Client Server – Quality Attribute Analysis

QualityAttribute

Issues

Availability Servers in each tier can be replicated, so that if one fails, others remain available. Overall the application will provide a lower quality of service until the failed server is restored.

Failure handling If a client is communicating with a server that fails, most web and application servers implement transparent failover. This means a client request is, without its knowledge, redirected to a live replica server that can satisfy the request.

Modifiability Separation of concerns enhances modifiability, as the presentation, business and data management logic are all clearly encapsulated. Each can have its internal logic modified in many cases without changes rippling into other tiers.

Performance This architecture has proven high performance. Key issues to consider are the amount of concurrent threads supported in each server, the speed of connections between tiers and the amount of data that is transferred. As always with distributed systems, it makes sense to minimize the calls needed between tiers to fulfill each request.

Scalability As servers in each tier can be replicated, and multiple server instances run on the same or different servers, the architecture scales out and up well. In practice, the data management tier often becomes a bottleneck on the capacity of a system.

Messaging Pattern

Asynchronous communications: Clients send requests to the queue, where the message is stored until an application removes it. Configurable QoS: The queue can be configured for high-speed, non-reliable or slower, reliable delivery. Queue operations can be coordinated with database transactions.

Loose coupling: There is no direct binding between clients and servers.

ServerServer

ClientClient

ClientQueue Server

Messaging – Quality Attribute AnalysisQuality Attribute

Issues

Availability Physical queues with the same logical name can be replicated across different messaging server instances. When one fails, clients can send messages to replica queues.

Failure handling If a client is communicating with a queue that fails, it can find a replica queue and post the message there.

Modifiability Messaging is inherently loosely coupled, and this promotes high modifiability as clients and servers are not directly bound through an interface. Changes to the format of messages sent by clients may cause changes to the server implementations. Self-describing, discoverable message formats can help reduce this dependency on message formats.

Performance Message queuing technology can deliver thousands of messages per second. Non-reliable messaging is faster than reliable, with the difference dependent of the quality of the messaging technology used.

Scalability Queues can be hosted on the communicating endpoints, or be replicated across clusters of messaging servers hosted on a single or multiple server machines. This makes messaging a highly scalable solution.

Publish-Subscribe Pattern

Many-to-Many messaging: Published messages are sent to all subscribers who are registered with the topic.

Configurable QoS: In addition to non-reliable and reliable messaging, the underlying communication mechanism may be point-to-point or broadcast/multicast.

Loose Coupling: As with messaging, there is no direct binding between publishers and subscribers.

Subscriber

Publisher Subscriber

SubscriberTopic

Publish-Subscribe – Quality Attribute Analysis

QualityAttribute

Issues

Availability Topics with the same logical name can be replicated across different server instances managed as a cluster. When one fails, publishers send messages to replica queues.

Failure handling If a publisher is communicating with a topic hosted by a server that fails, it can find a live replica server and send the message there.

Modifiability Publish-subscribe is inherently loosely coupled, and this promotes high modifiability. New publishers and subscribers can be added to the system without change to the architecture or configuration. Changes to the format of messages published may cause changes to the subscriber implementations.

Performance Publish-subscribe can deliver thousands of messages per second, with non-reliable messaging faster than reliable. If a publish-subscribe broker supports multicast/broadcast, it will deliver multiple messages in a more uniform time to each subscriber.

Scalability Topics can be replicated across clusters of servers hosted on a single or multiple server machines. Clusters of server can scale to provide very high message volume throughput. Also, multicast/broadcast solutions scale better than their point-to-point counterparts.

Broker Pattern

Hub-and-spoke architecture: The broker acts as a messaging hub, and senders and receivers connect as spokes.

Performs message routing: The broker embeds processing logic to deliver a message received on an input port to an output port.

Performs message transformation: The broker logic transforms the source message type received on the input port to the destination message type required on the output port.

Receiver-2

Sender-1 Receiver-1

Broker

Sender-2

inPort1

inPort2

OutPort1

OutPort2

Broker Pattern - Quality Attribute Analysis

QualityAttribute

Issues

Availability To build high availability architectures, brokers must be replicated. This is typically supported using similar mechanisms to messaging and publish-subscribe server clustering.

Failure handling As brokers have typed input ports, they validate and discard any messages that are sent in the wrong format. With replicated brokers, senders can fail over to a live broker should one of the replicas fail.

Modifiability Brokers separate the transformation and message routing logic from the senders and receivers. This enhances modifiability, as changes to transformation and routing logic can be made without affecting senders or receivers.

Performance Brokers can potentially become a bottleneck, especially if they must service high message volumes and execute complex transformation logic. Their throughput is typically lower than simple messaging with reliable delivery.

Scalability Clustering broker instances makes it possible to construct systems scale to handle high request loads.

Process Coordinator Pattern

Process encapsulation: The process coordinator encapsulates the sequence of steps needed to fulfill the business process. The sequence can be arbitrarily complex.

Loose coupling: The server components are unaware of their role in the overall business process, and of the order of the steps in the process.

Flexible communications: Communications between the coordinator and servers can be synchronous or asynchronous.

Server-3Server-2 Server-4

ProcessCoordinator

Server-1

step1

step2 step3 step4

Startprocessrequest

Processresults

Process Coordinator – Quality Attribute Analysis

QualityAttribute

Issues

Availability The coordinator is a single point of failure. Hence it needs to be replicated to create a high availability solution.

Failure handling Failure handling is complex, as it can occur at any stage in the business process coordination. Failure of a later step in the process may require earlier steps to be undone using compensating transactions. Handling failures needs careful design to ensure the data maintained by the servers remains consistent.

Modifiability Process modifiability is enhanced because the process definition is encapsulated in the coordinator process. Servers can change their implementation without affecting the coordinator or other servers, as long as their external service definition doesn’t change.

Performance To achieve high performance, the coordinator must be able to handle multiple concurrent requests and manage the state of each as they progress through the process. Also, the performance of any process will be limited by the slowest step, namely the slowest server in the process.

Scalability The coordinator can be replicated to scale the application both up and out.

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

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.

A Simple Design Example

Validate

OrderInput

read

NewOrders

OrderQ

Store

CustomerSystem

OrderSystem

SendEmail

EmailServer

WriteOrder

CheckOrder

WriteOrder

GetOrder

Figure KeyExisting Component

New Component

Dependency

Database

Persistent Queue

ErrorLog

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

Validating an architecture design poses tough challenges. ‘coz it’s a design that can’t be executed or tested consists of new and COTS components that have to be

integrated Two main techniques:

1. manual testing of the architecture using test scenarios. 2. construction of a prototype that creates a simple archetype of the

desired application aim of both is to identify potential flaws in the design so that they

can be improved before implementation commences. Cheaper to fix before built

Scenarios

Part of SEI’s ATAM work Involves defining:

some kind of stimulus that will have an impact on the architecture.

working out how the architecture responds to this stimulus. If the response is desirable, then a scenario is

deemed to be satisfied by the architecture. If the response is undesirable, or hard to quantify,

then a flaw or at least an area of risk in the architecture may have been uncovered.

Scenario ExamplesQuality

AttributeStimulus Response

Availability The network connection to the message consumers fails.

Messages are stored on the MOM server until the connection is restored. Messages will only be lost if the server fails before the connection comes back up.

Modifiability A new set of data analysis components must be made available in the application.

The application needs to be rebuilt with the new libraries, and the all configuration files must be updated on every desktop to make the new components visible in the GUI toolbox.

Security No requests are received on a user session for ten minutes.

The system treats this session as potentially insecure and invalidates the security credentials associated with the session. The user must logon again to connect to the application.

Modifiability The supplier of the transformation engine goes out of business.

A new transformation engine must be purchased. The abstract service layer that wraps the transformation engine component must be re-implemented to support the new engine. Client components are unaffected as they only use the abstract service layer.

Scalability The concurrent user request load doubles during the 3 week enrollment period.

The application server is scaled out on a two machine cluster to handle the increased request load.

Scenarios for Order Processing Example

QualityAttribute

Stimulus Response

Modifiability The Customer System packaged application is updated to an Oracle database.

The Validate component must be rewritten to interface to the Oracle system.

Availability The email server fails. Messages build up in the OrderQ until the email server restarts. Messages are then sent by the SendEmail component to remove the backlog. Order processing is not affected.

Reliability The Customer or Order systems are unavailable.

If either fails, order processing halts and alerts are sent to system administrators so that the problem can be fixed.

Needs fixing ….

Prototyping

Scenarios can’t address everything: “On Friday afternoon, orders must be processed before

close-of-business to ensure delivery by Monday. Five thousand orders arrive through various channels (Web/Call centre/business partners) five minutes before close-of-business.”

Only one way – build something! Proof-of-concept prototype: Can the architecture as

designed be built in a way that can satisfy the requirements?

Proof-of-technology prototype : Does the technology (middleware, integrated applications, libraries, etc) selected to implement the application behave as expected?

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 Don’t let them acquire a life of their own

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)

Essential Software Architecture

Session 6:

Documenting a Software Architecture

Architecture Documentation

Architecture documentation is a thorny issue Commonly there is no documentation

covering the architecture. If it is, it’s out-of-date, inappropriate and basically

not very useful. Also projects that have masses of

architecture related information Sometimes invaluable, but often it’s out-of-date,

inappropriate and not very useful!

Documenting an Architecture is good! Others can understand/evaluate the design. We can understand the design after a period

of time. Others in the project team and development

organization can learn from the architecture. We can do analysis on the design, perhaps to

assess its likely performance, or to generate standard metrics.

But it’s difficult …

No universally accepted architecture documentation standard.

An architecture can be complex, and documenting it in a comprehensible manner is time consuming and non-trivial.

An architecture has many possible views. Documenting all the potentially useful ones is time consuming and expensive.

An architecture design often evolves Keeping the architecture documents current is often forgotten, especially with time and schedule pressures in a project.

Think carefully about what to document Project complexity

A small project may only need a ‘marketecture’ Project longevity

One-off stop gap software? Strategic, long-term, will evolve?

Needs of stakeholders Small team, a whiteboard might be ok Large, dislocated team needs more Integrators? Testers? Programmers?

Need to spend documentation dollars/euros wisely on high value products

UML 2.0

UML is a powerful way to document an architecture

Provides a relatively formal, unambiguous description

New features in UML 2.0 appropriate for architectures

Good tools available, some free Can be used to depict various

structural/behavioral architecture views

Component Diagramid Component View

OrderProcessing

MailQueue

SendEmail

MailServer

OrderSystem

CustomerSystem OrderQueue

«table»

NewOrders

1validate

1

readQ

1writeQ

1

read

1send

1

1readQ

1

1

writeQ

1

Class Diagram

cd OrderProcessing

OrderReader

Validate Store

QueueWriter

1

1

1 1

1

1

Sequence Diagramsd Interactions

OrderReader

MailQueue

Validate

OrderQueue

Store QueueWriter

NewOrders CustomerSystem

readOrderData

success:=validateOrder

success:=newOrder

success:=storeOrder

success:=writeQueue

success:=acknowledgeOrderSuccess

success:=writeQueue

Deployment Diagramdd Deployment View

OrdersDB

OrderServer

«executable»

:OrderProcessing

«table»

:NewOrders

MOMServer

:MailQueue

:OrderQueue

MailServer

:MailServer

OrderSystem

CustomerSystem

«executable»

:CustomerSystem

«executable»

:OrderSystem

:SendEmail

CRM

ERP

SOAP

JDBC

Component Interfacesid Component View

OrderProcessing

MailQueue

SendEmail

MailServer

OrderSystemCustomerSystem

OrderQueue

«table»

NewOrders

JDBC

SMTP

QueueRead

QueueRead

QueueWrite

CustomerServices

QueueWrite

Component Decomposition

id Component View

OrderProcessing

validateOrder

getOrders writeConfirmation

writeOrder

MailQueue

SendEmail

MailServer

OrderSystemCustomerSystem

validate

ProvidedInterface1

OrderQueue

«table»

NewOrders

JDBC

QueueWrite

QueueWrite

CustomerServices SMTP

QueueRead

QueueRead

cd Component View

OrderProcessing

getOrders

validateOrder

writeConfirmation

writeOrder

or: OrderReader

val: Validate

qw: QueueWriter

st: Store

«delegate»

«delegate»

«delegate»

«delegate»

Document Template

Documentation is easier if there’s a template to use Reduces start-up time for projects by providing

ready-made document structures familiarity gained with the document structure aids

in the efficient capture of project design details. help with the training of new staff

Template HeadingsArchitecture Documentation TemplateProject Name: XXX1 Project Context2 Architecture Requirements2.1 Overview of Key Objectives2.2 Architecture Use Cases2.3 Stakeholder Architectural

Requirements2.4 Constraints2.5 Non-functional Requirements2.6 Risks3 Solution3.1 Relevant Architectural Patterns3.2 Architecture Overview3.3 Structural Views3.4 Behavioral Views3.5 Implementation Issues4 Architecture Analysis4.1 Scenario analysis4.2 Risks

Summary

Some documentation is nearly always a good idea

Trick is to produce ‘just enough’ and no more requires upfront planning and thinking Commitment to keeps docs current

UML 2.0 makes architecture documentation easier

Some good UML 2.0 tools, try ‘em out.

Essential Software Architecture

Session 7:

ICDE Case Study Design