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
3

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

Defintions - ANSI/IEEE Std 14712000

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

Architecture Defines Structure

Decomposition of system in to components/modules/subsystems Architecture defines:

Component interfaces

What a component can do How components communicate Precisely what a component will do when you ask it

Component communications and dependencies

Component responsibilities

Structure and Dependencies

Excessive component dependencies are bad! Key architecture issue

C1

C2

C3

C4

C1

C2

C3

C4

Identifying components that may change Reduce direct dependencies on these components

AL Third Party Component

Creates more modifiable systems

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.

Third Party Component

Diagram Key

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

Architecture Specifies Component Communication

Communication involves:

Data passing mechanisms, e.g.:

Function call Remote method invocation Asynchronous message Flow of messages between components to achieve required functionality Sequential Concurrent/parallel Synchronization
10

Control flow

Architecture Patterns/Styles

Patterns catalogue successfully used structures that facilitate certain kinds of component communication

client-server Message broker Pipeline

Patterns have well-known characteristics appropriate for particular types of requirements Patterns are very useful things

Reusable architectural blueprints Help efficiently communicate a design Large systems comprise a number of individual patterns Patterns and Styles are the same thing the patterns people won [anonymous SEI member]

11

Architecture addresses NFRs

Non-functional requirements (NFRs) define how a system works NFRs rarely captured in functional requirements

Aka. architecture requirements Must be elicited by architect Technical constraints Business constraints Quality attributes
12

NFRs include:

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 informal depiction of systems structure and interactions. portray the design philosophies embodied in the architecture Easy to understand Helps discussion during design, build, review, sales (!) process
13

Example A Marketecture

Every system should have a marketecture:

Decomposition

Hierarchical decomposition is a powerful abstraction mechanism

Top Level Architecture Description

Diagram Key

C Client Broker Server

Componen t Dependenc y

Partitions design Allocate components to development teams

Messag e Handler Director y Server

Security Server

Why isnt the Client component decomposed?

Request Handler

Data Store

14

Architecture Views

A software architecture represents a complex design artifact Many possible views of the architecture

Cf. with buildings floor plan, external, electrical, plumbing, air-conditioning

15

Philippe Krutchen - 4+1 View Model

Logical view: describes architecturally significant elements of the architecture and the relationships between them. Process view: describes the concurrency and communications elements of an architecture. Physical view: depicts how the major processes and components are mapped on to the applications hardware. Development view: captures the internal organization of the software components as held in e.g. a configuration management tool. Architecture use cases: capture the requirements for the architecture; related to more than one particular view

16

SEI Views and Beyond

Module: structural view of the architecture, comprising the code modules such as classes, packages and subsystems Component and Connector: describes the behavioral aspects of the architecture. Components are objects, threads or processes, and connectors describe how components interact. Allocation: shows how the processes are mapped to hardware and gives a view of the source code in the configuration management systems. This course will focus on structural and behavioral views
17

What does an Architect do?

Many responsibilities:

Liaison with stakeholders Technology knowledge Software engineering Risk managements http://www.sei.cmu.edu/ata/arch_duties.html

Long list at:

18

Architectures and Technologies

Architects reduce risks by using proven design patterns Must map abstract design pattern to concrete implementation Software vendors have created (COTS) technologies that explicitly support widely used patterns

Makes implementation of patterns easier Reduces risk if technology is well built

19

Architectures and Technologies

Architectural Patterns/Styles

Abstract

Application Servers

Messaging

Message Brokers

Object Brokers

Process Orchestration

Concrete COTS technologies

Each technology has multiple vendors/open source versions Architects need to choose technology wisely

Proof of concept prototype Detailed feature evaluation

20

Summary

The life of a software architect is a long (and sometimes painful) succession of sub-optimal decisions made partly in the dark Architecture involves complex design decisions Architect role is much more than just technical design Made harder by early lifecycle nature of much of the design
21

Selected Further Reading

L. Bass, P. Clements, R Kazman. Software Architecture in Practice, Second Edition. AddisonWesley, 2003. R. Wirfs-Brock, A. McKean. Object Design: Roles, Responsibilities, and Collaborations. AddisonWesley, 2002. M. Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley, 2002. I.Gorton, A Liu. Performance Evaluation of Alternative Component Architectures for Enterprise JavaBean Applications, in IEEE Internet Computing, vol.7, no. 3, pages 18-23, 2003.
22

Essential Software Architecture

Session 2: Introduction to the Case Study

23

ICDE System

Information Capture and Dissemination Environment (ICDE) is a software system for providing intelligent assistance to

financial analysts scientific researchers intelligence analysts analysts in other domains

24

ICDE Schematic
Local information repositories

Internet Internet
ICDE Repository

M ICD on E ito rin g

ICDE Recording Software

Analyst 3rd Party Tools

25

ICDE Use Cases

ICDE
* * Analyst * Capture User Actions *

* User Assistance

* *

Data Store

* * Query User Actions *

3rd Party Tools

26

Case Study Context

ICDE version 1.0 in production Basically a complex, raw information capture tool, GUI for looking at captured data 2 tier client-server, single machine deployment Java, Perl, SQL,

Programmatic access to data through very complex SQL (38 tables, 46 views)

27

ICDE version 2.0

ICDE v2.0 scheduled for development in 12 month timeframe

Fixed schedule, budget Enhance data capture tools (GUI) Support 3rd party tool integration, testing, data access and large production scale deployments (100s of users)

Major changes to:

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

28

ICDE v2.0 Business Goals

Business Goal Encourage third developers party Supporting Technical Objective toolSimple 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 toScale the data collection and data store components to users support up to 150 users at a single site Low-cost deployment for each ICDE user workstation

29

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 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 Minimize dependencies, making unanticipated changes potentially easier

ICDE Project team requirements:

Unknowns

30

Summary

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

31

Essential Software Architecture

Session 3: Quality Attributes

32

What are Quality Attributes

Often know as ilities

Reliability Availability Portability Scalability Performance (!) how the system achieves its functional requirements

Part of a systems NFRs

33

Quality Attribute Specification

Architects are often told:

My application must be fast/secure/scale

Far too imprecise to be any use at all Quality attributes (QAs) must be made precise/measurable for a given system design, e.g.

It must be possible to scale the deployment from an initial 100 geographically dispersed user desktops to 10,000 without an increase in effort/cost for installation and configuration.
34

Quality Attribute Specification

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

35

Performance

Many examples of poor performance in enterprise applications Performance requires a:

Metric of amount of work performed in unit time Deadline that must be met

Enterprise applications often have strict performance requirements, e.g.

1000 transactions per second 3 second average latency for a request

36

Performance - Throughput

Measure of the amount of work an application must perform in unit time

Transactions per second Messages per minute Average? Peak?

Is required throughput:

Many system have low average but high peak throughput requirements
37

Throughput Example
300 250 200 150 100 50 0 0 5 10 # of threads 15 20 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

38

Performance - Response Time

measure of the latency an application exhibits in processing a request Usually measured in (milli)seconds Often an important metric for users Is required response time:

Guaranteed? Average?

E.g. 95% of responses in sub-4 seconds, and all within 10 seconds

39

Response Time

Example shows response time distribution for a J2EE application

40

Performance - Deadlines

something must be completed before some specified time

Payroll system must complete by 2am so that electronic transfers can be sent to bank Weekly accounting run must complete by 6am Monday so that figures are available to management

Deadlines often associated with batch jobs in IT systems.

41

Something to watch for

What is a

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

ICDE Performance Issues

Response time:

Overheads of trapping user events must be imperceptible to ICDE users Decouple user event capture from storage using a queue
5. Write event to ICDE database queue

Solution for ICDE client:

1. Trap user event

2. Write event to queue

3. Return to user thread

4. Read event from queue

43

Scalability

How well a solution to some problem will work when the size of the problem increases. 4 common scalability issues in IT systems:

Request load Connections Data size Deployments

44

Scalability Request Load

How does an 100 tps application behave when simultaneous request load grows? E.g.

From 100 to 1000 requests per second?

Ideal solution, without additional hardware capacity:

as the load increases, throughput remains constant (i.e. 100 tps), and response time per request increases only linearly (i.e. 10 seconds).

45

Scalability Add more hardware

Scale-out: Application replicated on different machines

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

Application

Application

CPU

Application

Application

Application

46

Scalability - reality

Adding more hard ware should improve performance:

scalability must be achieved without modifications to application architecture

Reality as always is different! Applications will exhibit a decrease in throughput and a subsequent exponential increase in response time.

increased load causes increased contention for resources such as CPU, network and memory each request consumes some additional resource (buffer space, locks, and so on) in the application, and eventually these are exhausted
47

Scalability J2EE example

2500 2000 TPS 1500 1000 500 0 0 200 400 600 800 1000 1200 No. of Clients 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.
48

Scalability - connections

What happens if number of simultaneous connections to an application increases

If each connection consumes a resource? Exceed maximum number of connections? Each user connection spawned a new process Virtual memory on each server exceeded at 2000 users Needed to support 100Ks of users Tech crash .
49

ISP example:

Scalability Data Size

How does an application behave as the data it processes increases in size?

Chat application sees average message size double? Database table size grows from 1 million to 20 million rows? Image analysis algorithm processes images of 100MB instead of 1MB?

Can application/algorithms scale to handle increased data requirements?

50

Scalability - Deployment

How does effort to install/deploy an application increase as installation base grows?

Install new users? Install new servers?

Solutions typically revolve around automatic download/installation

E.g. downloading applications from the Internet

51

Scalability thoughts and ICDE

Scalability often overlooked.

Major cause of application failure Hard to predict Hard to test/validate Reliance on proven designs and technologies is essential

For ICDE - application should be capable of handling a peak load of 150 concurrent requests from ICDE clients.

Relatively easy to simulate user load to validate this

52

Modifiability

Modifications to a software system during its lifetime are a fact of life. Modifiable systems are easier to change/evolve Modifiability should be assessed in context of how a system is likely to change

No need to facilitate changes that are highly unlikely to occur Over-engineering!

53

Modifiability

Modifiability measures how easy it may be to change an application to cater for new (non-) functional requirements.

may nearly always impossible to be certain Must estimate cost/effort

Modifiability measures are only relevant in the context of a given architectural solution.

Components Relationships Responsibilities

54

Modifiability Scenarios

Provide access to the application through firewalls in addition to existing behind the firewall access. Incorporate new features for self-service check-out kiosks. The COTS speech recognition software vendor goes out of business and we need to replace this component. The application needs to be ported from Linux to the Microsoft Windows platform.
55

Modifiability Analysis

Impact is rarely easy to quantify The best possible is a:

Convincing impact analysis of changes needed A demonstration of how the solution can accommodate the modification without change.

Minimizing dependencies increases modifiability

Changes isolated to single components likely to be less expensive than those that cause ripple effects across the architecture.
56

Modifiability for ICDE

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

57

Security

Difficult, specialized quality attribute:

Lots of technology available Requires deep knowledge of approaches and solutions

Security is a multi-faceted quality

58

Security

Authentication: Applications can verify the identity of their users and other applications with which they communicate. Authorization: Authenticated users and applications have defined access rights to the resources of the system. Encryption: The messages sent to/from the application are encrypted. Integrity: This ensures the contents of a message are not altered in transit. Non-repudiation: The sender of a message has proof of delivery and the receiver is assured of the senders identity. This means neither can subsequently refute their participation in the message exchange.

59

Security Approaches

SSL PKI Web Services security JAAS Operating system security Database security Etc etc

60

ICDE Security Requirements

Authentication of ICDE users and third party ICDE tools to ICDE server Encryption of data to ICDE server from 3rd party tools/users executing remotely over an insecure network

61

Availability

Key requirement for most IT applications Measured by the proportion of the required time it is useable. E.g.

100% available during business hours No more than 2 hours scheduled downtime per week 24x7x52 (100% availability) Unreliable applications suffer poor availability
62

Related to an applications reliability

Availability

Period of loss of availability determined by:

Time to detect failure Time to correct failure Time to restart application Eliminate single points of failure Replication and failover Automatic detection and restart the capability to reestablish performance levels and recover affected data after an application or system failure
63

Strategies for high availability:

Recoverability (e.g. a database)

Availability for ICDE

Achieve 100% availability during business hours Plenty of scope for downtime for system upgrade, backup and maintenance. Include mechanisms for component replication and failover

64

Integration

ease with which an application can be incorporated into a broader application context

Use component in ways that the designer did not originally anticipate Programmatic APIs Data integration

Typically achieved by:

65

Integration Strategies
Interoperability through an API facade

Application

API

Third Party Application Data

Interoperability achieved by direct data access

Data expose application data for access by other components API offers services to read/write application data through an abstracted interface Each has strengths and weaknesses
66

ICDE Integration Needs

Revolve around the need to support third party analysis tools. Well-defined and understood mechanism for third party tools to access data in the ICDE data store.

67

Misc. Quality Attributes

Portability

Can an application be easily executed on a different software/hardware platform to the one it has been developed for? How easy or difficult is an application to test? How easy an application is to support once it is deployed?
68

Testability

Supportability

Design Trade-offs

QAs are rarely orthogonal

They interact, affect each other highly secure system may be difficult to integrate highly available application may trade-off lower performance for greater availability high performance application may be tied to a given platform, and hence not be easily portable

Architects must create solutions that makes sensible design compromises

not possible to fully satisfy all competing requirements Must satisfy all stakeholder needs This is the difficult bit!
69

Summary

QAs are part of an applications nonfunctional requirements Many QAs Architect must decide which are important for a given application

Understand implications for application Understand competing requirements and tradeoffs

70

Selected Further Reading

L. Chung, B. Nixon, E. Yu, J. Mylopoulos, (Editors). Non-Functional Requirements in Software Engineering Series: The Kluwer International Series in Software Engineering. Vol. 5, Kluwer Academic Publishers. 1999. J. Ramachandran. Designing Security Architecture Solutions. Wiley & Sons, 2002. I.Gorton, L. Zhu. Tool Support for Just-in-Time Architecture Reconstruction and Evaluation: An Experience Report. International Conference on Software Engineering (ICSE) 2005, St Loius, USA, ACM Press

71

Essential Software Architecture

Session 4: A Guide to Middleware Architectures and Technologies

72

Introduction

Middleware is the plumbing or wiring of IT applications Provides applications with fundamental services for distributed computing Insulates applications from underlying platform (OS, DBMS, etc) APIs Lots of middleware exists

Different purposes Different vendors Different standards and proprietary technologies

73

Middleware Classification
Business Process Orchestrators
BizTalk, TIBCO StaffWare, ActiveBPEL

Message Brokers

BizTalk, WebSphere Message Broker, SonicMQ

Application Servers

J2EE, CCM, .NET

Transport

Message-Oriented Middleware, Distributed Objects Systems

74

Outline

CORBA Message-oriented middleware J2EE Message brokers Business process orchestrators

75

CORBA

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

Client Object Reference request

Server Servant reply

client ORB

server ORB

Network

76

CORBA Code Example

module ServerExample { interface MyObject { }; Server string isAlive(); }; CORBA IDL

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

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

Client

77

CORBA Some Thoughts

Many associated services, eg

Naming Notification Transactions

Synchronous technology, client-server relatively tightly coupled Remote calls can/will fail State management in server objects creates interesting recovery issues
78

Messaging - MOM

Basic Message Oriented Middleware (MOM) provides features like:

Asynchronous communications between processes, applications and systems Send-and-forget

Delivering messages despite failures Deliver all messages in a transaction, or none Messages can be logged at the server and hence survive server failure

Transactional Messaging

Persistence

79

Basic Messaging

Send (queue, message)

Put message onto queue Get message from queue

Receive (queue, message)

No dependency on state of receiving application on message send

send receive

queue

80

Persistence
send

queue
receive

Receipt of message at queue implies message is written to disk log Removal of message from queue deletes message from disk log Trade-off performance versus reliability
81

MOM Server
Senders Sending Applications Receivers Sending Applications

Message Handler Thread Pool MOM Server

Peer-to-peer MOM technologies are the alternative design

82

MOM Transactions
Begin transaction ... update database record put message on queue ... commit transaction Begin transaction ... get message from queue update database record ... commit transaction

83

MOM Transactions

Sender and receiver do *not* share a transaction

Rollback on receiver does not affect the sender (already committed) Synchronous operations are not atomic

Request/response is 3 transactions not 1

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

Request queue
send receive

receive

send

Response queue
84

Scaling MOM
MOM Server ApplicationQ

Senders

Receivers

MOM Server ApplicationQ

85

Messaging Some thoughts

Highly attractive asynchronous technology Supports loosely-coupled, dynamic applications Scales well, high throughput possible Many implementations, various qualities of service

caveat emptor

86

Publish-Subscribe Messaging

Extension of MOM to provide 1-to-N, N-to-1, and N-to-N communications Messages are published to logical subjects or topics Subscribers receive all messages from subjects they subscribe to

Sub Pub
Create/ Publish

Subject

Register/ Subscribe

Sub

Sub
87

Publish-Subscribe with Multicast

Subscriber Subscriber rvd rvd rvrd

Publisher

Based on TIBCO Rendezvous

rvrd

rvd

rvd

rvd

rvd

Subscriber

Subscriber

Subscriber

88

Performance
Milliseconds 700 600 500 400 300 200 100 0 10 20 30 40 50 No. Of Subscribers

MC1 MC2 QB

89

Subject/Topic Naming
Sydney DevGroup SupportGroup

Information

Information

work

gossip

work

gossip

Sydney Sydney/DevGroup Sydney/DevGroup/Information Sydney/DevGroup/Information/work Sydney/DevGroup/Information/gossip Sydney/SupportGroup Sydney/SupportGroup/Information Sydney/SupportGroup/Information/work Sydney/SupportGroup/Information/gossip

Sydney/*/Information Sydney/DevGroup/*/* Sydney/DevGroup/**

90

Publish-Subscribe Some Thoughts messaging style Highly decoupled

Publishers dont know about subscribers Subscribers dont know who is publishing Publishers and Subscribers can dynamically appear and disappear Reliability Transactions Security Performance

Issues

91

J2EE Overview
Client tier Web Tier Business Component tier EIS Tier

HTTP Browser-based client applications (HTML, applets, DHTML/scripting)

Web server

RMI
Servlets, JSPs Application components EJBs

JCA

Java RMI Java client applications

Container Services Components eg. JTS, JMS

ERPs, CRMs, Mainframe TP systems JDBC RDBMS

CAS COM Bridge, RMI over IIOP Windows/COM client applications

92

J2EE Application Server

In J2EE, the application server container provides the execution environment for the J2EE-specific components

EJBs Message-driven beans Connectors Transactions Security Directory Threading Connection pooling

Container provides additional services for hosted components

93

EJB Container
Application Server EJB Container EJB Pool Transaction Service

Lifecycle Management

Directory Service

Persistence

Connection Pool

Security Service

Thread Pool

94

Beans and State

state EJB Container Stateless bean pool state

state state EJB Clients

state

Stateful beans

state

state

95

Deployment Descriptors
<ejb-jar> <enterprise-beans> <session> <ejb-name>EntityStock.BrokerHome</ejb-name> <home>db.entitystock.BrokerHome</home> <remote>db.entitystock.Broker</remote> <ejb-class>db.entitystock.BrokerBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> <assembly-descriptor> <container-transaction> <method> <ejb-name>EntityStock.BrokerHome</ejb-name> <method-intf>Remote</method-intf> <method-name>*</method-name> </method> <trans-attribute>Required</trans-attribute> </container-transaction> </assembly-descriptor> </ejb-jar>
96

J2EE Some Thoughts

Standards-based, multiple vendors, portable Good open source technology available Quality of implementations varies considerably Java only, wide platform support Performance is good, but varies between suppliers Scalable, fail over support through clustering Good integration with web technologies Supports various design patterns, flexible but more complex (e.g. stateful beans/scalability, entity beans) Standards evolving, need to monitor

97

Message Brokers - Motivation

Key: Message =

Web Component
In-format

In-format

In-format

In-format

In-format

Legacy System #1

Legacy System #2

Legacy System #3

Legacy System #4

Queue Read
In-format

Message Transform

API call
Legacyformat

98

What if

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

99

Alternative Solution
Key: Message =

Web Component

In-format

Message Broker

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

Legacy System #1

Legacy System #2

Legacy System #3

Legacy System #4

Transformations in broker Simplified endpoints Decouples Web and legacy components

100

Message Brokers

Developed specifically for Enterprise Application Integration (EAI) Add new layers of functionality to MOM

Message transformation Rules engine Intelligent routing Adapters

Typically (but not necessarily) built on top of a MOM layer

101

Message Broker Features

Message transformation transform between different source/target formats

Graphical message format definition and mapping tools High performance transformation engines Message format repositories Route messages based on message content Scripting language, built-in functions Application programming environment

Intelligent routing

Rules Engine

102

Message Brokers
Hub and Spoke Architecture Input Messages Transformation Routing Rules Processing Output Messages

103

Example - WMQI

104

BizTalk Mapping Tool

105

Adapters

An adapter is a component that resides between the message broker and the source/target systems Simplify complexity of end system interface through an abstraction layer Thin adapters - simple wrappers Thick adapters

Programmable Abstract representation of services and meta-data

Centralized adapters co-located with broker Distributed adapters execute in own process and may be located with source/target system

106

Message Brokers Some Thoughts

Embeds transformations/routing in broker

Can get complex Need to replicate brokers Lightweight, rarely designed to recover from failure Good open source, standards-based like Mule now available

Possible scaling issues

Failure handling

Often proprietary technology

107

Business Process Orchestration Commonly known as workflow

Aim is to automate business processes which need to access data and business logic across disparate backend applications Builds on EAI to ensure business processes are executed in the defined order using the required data Builds on middleware providing:

Process execution engine Visual process definition tools Process monitoring tools

108

Typical Scenario

Business process automation

Siebel Accounts Payable

Credit Validation

Customer Purchasing

Sales desk Accounts Receivable

Shipping

Oracle

SAP

Customer Receiving
109

Example - BizTalk

110

BPO Architecture

Message Broker Adapter Adapter Adapter

111

BPEL

Web Services standard for describing workflows Many design and execution tools

Eg ActiveBPEL

Version 2.0 is a significant improvement

112

Integration Issues Point-toPoint evolution Point-to-Point

Spaghetti architecture, hard to modify potentially (N2-N) interfaces

1 business process = 4 interfaces

5 business processes = 20 interfaces

113

Broker Spaghetti

No free lunch Just relocates the spaghetti

message broker

114

Enterprise Data Model

Source sends message to target with common message format as payload. Target receives message and transforms common format into its own local data representation. 2xN transformations, no broker needed Getting agreement is the tough bit

Enterprise Data Model

115

Summary

Middleware:

makes building complex, distributed, concurrent applications simpler. institutionalizes proven design practices by supporting them in off-the-shelf middleware technologies.

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

116

Essential Software Architecture

Session 5: A Software Architecture Process

117

A Software Architecture Process

Architects must be versatile:

Work with the requirements team: The architect plays an important role in requirements gathering by understanding the overall systems needs and ensuring that the appropriate quality attributes are explicit and understood. Work with various application stakeholders: Architects play a pivotal liaison role by making sure all the 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
118

An Architecture Process

Highly iterative Can scale to small/large projects

Determ ine Architectural Requirem ents

Architecture Design Validation

119

Determine Architectural Requirements

Sometime called:

architecturally significant requirements architecture use cases

Functional Requirements

Stakeholder Requirements

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

Determine Architecture Requirements

Architecture Requirements

120

Examples

A typical architecture requirement :

Communications between components must be guaranteed to succeed with no message loss The system must use the existing IIS-based web server and use Active Server Page to process web requests

Some architecture requirements are constraints:

Constraints impose restrictions on the architecture and are (almost always) non-negotiable. They limit the range of design choices an architect can make.
121

Quality Attribute Requirements

Quality Attribute Performance Security Resource Management Usability Availability Reliability Scalability Modifiability Architecture Requirement Application performance must provide sub-four second response times for 90% of requests. All communications must be authenticated and encrypted using certificates. The server component must run on a low end office-based server with 512MB memory. The user interface component must run in an Internet browser to support remote users. The system must run 24x7x365, with overall availability of 0.99. No message loss is allowed, and all message delivery outcomes must be known with 30 seconds The application must be able to handle a peak load of 500 concurrent users during the enrollment period. The architecture must support a phased migration from the current Forth Generation Language (4GL) version to a .NET systems technology solution.
122

Constraints
Constraint Business Architecture Requirement The technology must run as a plug-in for MS BizTalk, as we want to sell this to Microsoft.

Development

The system must be written in Java so that we can use existing development staff.

Schedule

The first version of this product must be delivered within six months.

Business

We want to work closely with and get more development funding from MegaHugeTech Corp, so we need to use their technology in our application.

123

Priorities

All requirements are not equal

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!

124

Architecture Design

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

Architecture Requirements

Choose Architecture Framework

Allocate Components

Architecture Views

Architecture Document

125

Choosing the Architecture Framework

Choose a architecture pattern/patterns that suit requirements

No magic formula Analyze requirements and quality attributed supported by each pattern

Complex architectures require creative blending of multiple patterns.

126

N-Tier Client Server Pattern

Separation of concerns: Presentation, business and data handling logic are clearly partitioned in different tiers. Synchronous communications: Communications between tiers is synchronous request-reply. Each tier waits for a response from the other tier before proceeding. Flexible deployment: There are no restrictions on how a multitier application is deployed. All tiers could run on the same machine, or each tier may be deployed on its own machine.

Client Tier

Web Client

Web Client

Web Client

Web Server Tier

Web Server

Business Logic Tier

Application Server

Data Management Tier

Databases

127

N-Tier Client Server Quality Attribute Analysis

Quality Attribute Availability Issues 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. 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. 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. 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. 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 128 system.

Failure handling

Modifiability

Performance

Scalability

Messaging Pattern

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

Client Client Client

Queu e

Server Server Server

129

Messaging Quality Attribute Analysis

Quality Attribute Availability Issues 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. If a client is communicating with a queue that fails, it can find a replica queue and post the message there. 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. Message queuing technology can deliver thousands of messages per second. Nonreliable messaging is faster than reliable, with the difference dependent of the quality of the messaging technology used. 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.

Failure handling Modifiability

Performance

Scalability

130

Publish-Subscribe Pattern

Many-to-Many messaging: Published messages are sent to all subscribers who are registered with the topic. Configurable QoS: In addition to non-reliable and reliable messaging, the underlying communication mechanism may be point-topoint or broadcast/multicast. Loose Coupling: As with messaging, there is no direct binding between publishers and subscribers.

Subscriber Publisher Topic Subscriber Subscriber

131

Publish-Subscribe Quality Attribute Analysis

Quality Attribute Issues Availability Topics with the same logical name can be replicated across different server instances managed as a cluster. When one fails, publishers send messages to replica queues. 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. 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. 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. 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.

Failure handling Modifiability

Performance

Scalability

132

Broker Pattern

Hub-and-spoke architecture: The broker acts as a messaging hub, and senders and receivers connect as spokes. Performs message routing: The broker embeds processing logic to deliver a message received on an input port to an output port. Performs message transformation: The broker logic transforms the source message type received on the input port to the destination message type required on the output port.

Sender-1

inPort1

OutPort1

Receiver-1

Broker

Sender-2
inPort2 OutPort2

Receiver-2

133

Broker Pattern - Quality Attribute Analysis

Quality Attribute Availability Issues To build high availability architectures, brokers must be replicated. This is typically supported using similar mechanisms to messaging and publish-subscribe server clustering. 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. 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. 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. Clustering broker instances makes it possible to construct systems scale to handle high request loads.
134

Failure handling

Modifiability

Performance

Scalability

Process Coordinator Pattern

Process encapsulation: The process coordinator encapsulates the sequence of steps needed to fulfill the business process. The sequence can be arbitrarily complex. Loose coupling: The server components are unaware of their role in the overall business process, and of the order of the steps in the process. Flexible communications: Communications between the coordinator and servers can be synchronous or asynchronous.

Start process request

Process results

Process Coordinator

step1 step2 step3 step4

Server-1

Server-2

Server-3

Server-4

135

Process Coordinator Quality Attribute Analysis

Quality Attribute Availability Failure handling Issues The coordinator is a single point of failure. Hence it needs to be replicated to create a high availability solution. 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. 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. 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. The coordinator can be replicated to scale the application both up and out.

Modifiability

Performance

Scalability

136

Allocate Components

Need to:

Identify the major application components, and how they plug into the framework. Identify the interface or services that each component supports. Identify the responsibilities of the component, stating what it can be relied upon to do when it receives a request. Identify dependencies between components. Identify partitions in the architecture that are candidates for distribution over servers in a network

And independent development

137

Some Design Guidelines

Minimize dependencies between components. Strive for a loosely coupled solution in which changes to one component do not ripple through the architecture, propagating across many components. Remember, every time you change something, you have to retest it. Design components that encapsulate a highly cohesive set of responsibilities. Cohesion is a measure of how well the parts of a component fit together. Isolate dependencies on middleware and any COTS infrastructure technologies. Use decomposition to structure components hierarchically. Minimize calls between components, as these can prove costly if the components are distributed.
138

A Simple Design Example

read Write Order

OrderQ

New Orders
Check Order

OrderInput

Write Order

Get Order

SendEmail Validate
Error Log

Store

Customer System

Order System

Email Server

Figure Key Existing Component New Component Dependency

Database Persistent Queue

139

Example Design

Based on messaging Application components are: OrderInput: responsible for accessing the new orders database, encapsulating the order processing logic, and writing to the queue. Validate: encapsulates the responsibility of interacting with the customer system to carry out validation, and writing to the error logs if an order is invalid. Store: responsibility of interacting with the order system to store the order data. SendEmail: removes a message from the queue, formats an email message and sends it via an email server. It encapsulates all knowledge of the email format and email server access. Clear responsibilities and dependencies

140

Architecture Validation

Aim of the validation phase is to increase confidence of the design team that the architecture is fit for purpose. The validation has to be achieved within the project constraints of time and budget The trick is to be as rigorous and efficient as possible. Validating an architecture design poses tough challenges. coz its a design that cant be executed or tested consists of new and COTS components that have to be integrated Two main techniques: 1. manual testing of the architecture using test scenarios. 2. construction of a prototype that creates a simple archetype of the desired application aim of both is to identify potential flaws in the design so that they can be improved before implementation commences. Cheaper to fix before built
141

Scenarios

Part of 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.
142

Scenario Examples
Quality Attribute Availability Stimulus The network connection to the message consumers fails. Response 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. 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. 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. A new transformation engine must be purchased. The abstract service layer that wraps the transformation engine component must be reimplemented to support the new engine. Client components are unaffected as they only use the abstract service layer. The application server is scaled out on a two machine cluster to handle the increased request load.
143

Modifiability

A new set of data analysis components must be made available in the application. No requests are received on a user session for ten minutes.

Security

Modifiability

The supplier of the transformation engine goes out of business.

Scalability

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

Scenarios for Order Processing Example

Quality Attribute Modifiability Stimulus Response The Customer System packaged application is updated to an Oracle database. The Validate component must be rewritten to interface to the Oracle system.

Availability

The email server fails.

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

Reliability

The Customer or Order systems are unavailable.

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

Needs fixing .
144

Prototyping

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

Only one way build something!

Proof-of-concept prototype: Can the architecture as designed be built in a way that can satisfy the requirements? Proof-of-technology prototype : Does the technology (middleware, integrated applications, libraries, etc) selected to implement the application behave as expected?

145

Prototyping Strategy

Build minimal system required to validate architecture, eg: An existing application shows that the queue and email systems are capable of supporting five thousand messages in five minutes So:

Write a test program that calls the Customer System validation APIs five thousand times, and time how long this takes. Write a test program that calls the Order System store APIs five thousand times, and time how long this takes.

146

Prototyping Thoughts

Prototypes should be used judiciously to help reduce the risks inherent in a design. Only way to address:

Performance Scalability Ease of integration Capabilities of off-the-shelf components 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
147

Need to be carefully scoped and managed.

Summary

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

148

Essential Software Architecture

Session 6: Documenting a Software Architecture

149

Architecture Documentation

Architecture documentation is a thorny issue Commonly there is no documentation covering the architecture.

If it is, 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!

150

Documenting an Architecture is good!

Others can understand/evaluate the design. We can understand the design after a period of time. Others in the project team and development organization can learn from the architecture. We can do analysis on the design, perhaps to assess its likely performance, or to generate standard metrics.
151

But its difficult

No universally accepted architecture documentation standard. An architecture can be complex, and documenting it in a comprehensible manner is time consuming and non-trivial. An architecture has many possible views. Documenting all the potentially useful ones is time consuming and expensive. An architecture design often evolves Keeping the architecture documents current is often forgotten, especially with time and schedule pressures in a project.
152

Think carefully about what to document

Project complexity

A small project may only need a marketecture One-off stop gap software? Strategic, long-term, will evolve? Small team, a whiteboard might be ok Large, dislocated team needs more Integrators? Testers? Programmers?

Project longevity

Needs of stakeholders

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

153

UML 2.0

UML is a powerful way to document an architecture Provides a relatively formal, unambiguous description New features in UML 2.0 appropriate for architectures Good tools available, some free Can be used to depict various structural/behavioral architecture views
154

Component Diagram
id Com ponent View OrderProcessing table New Orders read 1 w riteQ 1 1 readQ validate 1 Custom erSystem 1 1 w riteQ 1 OrderQueue 1 SendEm ail M ailQueue

1 s end 1 M ailServer

readQ

OrderSystem

155

Class Diagram
cd OrderProcessing OrderReader 1 1 QueueWriter

1 Validate

1 Store

156

Sequence Diagram
s d In t e r a c t io n s O r d e r R e a d e r V a lid a t e N e w O rd e rs r e a d O r d e r D a ta s u c c e s s := v a l i d a te O r d e r s u c c e s s := n e w O rd e r s u c c e s s := s to r e O r d e r s u c c e s s := w r i te Q u e u e s u c c e s s := a c k n o w le d g e O rd e rS u c c e s s s u c c e s s := w r i te Q u e u e S to r e C u s to m e r S y s te m Q u e u e W r it e r O rd e rQ u e u e M a ilQ u e u e

157

Deployment Diagram
d d D e ploym e nt V ie w O r de r S e r ve r O r de r s DB JD B C e xe c u ta b le : O r de r P ro c e s s in g M a ilS e r ve r ta b le :Ne w O rd e r s

:M a ilS e r ve r

S O AP

:S e ndEm a il

Cus to m e r S ys te m C RM e xe cu ta b le : Cus tom e r S ys te m

M O M S e r ve r

:M a ilQ ue ue O r d e r S ys te m ER P e xe c u ta b le : O r d e r S ys te m :O r d e r Q ue ue

158

Component Interfaces
id Com pone nt V ie w Orde rP roc e s s ing ta b le Ne w Orde rs JD B C Qu e u e W rite M a ilQue ue

Qu e u e R e a d Qu e u e W rite S e ndEm a il Orde rQue ue Qu e u e R e a d S MTP M a ilS e rve r Cus tom e rS ys te m Orde rSys te m

C u s to m e rS e rvice s

159

Component Decomposition
id Component View

cd Component View
JDBC table New Orders getOrders writeC onfirm ation OrderProcessing QueueWrite MailQueue

OrderProcessing delegate or: OrderReader qw : QueueW riter delegate writeConfirm ation val: Validate st: Store

validateOrder writeOrder QueueRead

QueueWrite

getOrders
SendEmail

OrderQueue Cus tom erServices QueueRead SMTP MailServer validate CustomerSystem OrderSystem

delegate validateOrder

delegate w riteOrder

ProvidedInterface1

160

Document Template

Documentation is easier if theres a template to use

Reduces start-up time for projects by providing ready-made document structures familiarity gained with the document structure aids in the efficient capture of project design details. help with the training of new staff

161

Template Headings
Architecture Documentation Template Project Name: XXX 1 Project Context 2 Architecture Requirements 2.1 Overview of Key Objectives 2.2 Architecture Use Cases 2.3 Stakeholder Architectural Requirements 2.4 Constraints 2.5 Non-functional Requirements 2.6 Risks 3 Solution 3.1 Relevant Architectural Patterns 3.2 Architecture Overview 3.3 Structural Views 3.4 Behavioral Views 3.5 Implementation Issues 4 Architecture Analysis 4.1 Scenario analysis 4.2 Risks
162

Summary

Some documentation is nearly always a good idea Trick is to produce just enough and no more

requires upfront planning and thinking Commitment to keeps docs current

UML 2.0 makes architecture documentation easier Some good UML 2.0 tools, try em out.
163

Essential Software Architecture

Session 7: ICDE Case Study Design

164