essential software architecture
Download
Skip this Video
Download Presentation
Essential Software Architecture

Loading in 2 Seconds...

play fullscreen
1 / 164

Essential Software Architecture - PowerPoint PPT Presentation


  • 357 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Essential Software Architecture' - adriano


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
essential software architecture

Essential Software Architecture

Session 1:

Introduction to Software Architecture

session outline
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 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
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
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
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
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
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
C1

C2

C3

C4

C1

C2

C3

C4

AL

Third Party

Component

Third Party

Component

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.

Diagram Key

Component

Dependency

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

C

Structure and Dependencies
  • Excessive component dependencies are bad!
  • Key architecture issue
    • Identifying components that may change
    • Reduce direct dependencies on these components
  • Creates more modifiable systems
architecture specifies component communication
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
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
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 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
Top Level Architecture Description

Diagram Key

Component

Dependency

C

Client

Broker

Server

Security

Server

Message Handler

Directory Server

Request Handler

Data

Store

Decomposition
  • Hierarchical decomposition is a powerful abstraction mechanism
    • Partitions design
    • Allocate components to development teams
  • Why isn’t the Client component decomposed?
architecture views
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
Philippe Krutchen - 4+1 View Model
  • Logical view: describes architecturally significant elements of the architecture and the relationships between them.
  • Processview: 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.
  • Developmentview: 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
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
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
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 technologies20
Abstract

Architectural Patterns/Styles

Application Servers

Messaging

Message Brokers

Object

Brokers

Process

Orchestration

Concrete COTS technologies

Architectures and Technologies
  • Each technology has multiple vendors/open source versions
  • Architects need to choose technology wisely
    • Proof of concept prototype
    • Detailed feature evaluation
summary
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
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 architecture23

Essential Software Architecture

Session 2:

Introduction to the Case Study

icde system
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
Local information

repositories

Internet

ICDE

Repository

ICDE

Recording Software

Analyst

3rd Party

Tools

ICDE Schematic

ICDE

Monitoring

case study context
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 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
architecturally significant requirements for icde v2 0
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
summary31
Summary
  • ICDE is a reasonably complex system
  • Will be used to illustrate concepts during the remainder of this course
essential software architecture32

Essential Software Architecture

Session 3:

Quality Attributes

what are 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
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 specification35
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
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
Performance - Throughput
  • Measure of the amount of work an application must perform in unit time
    • Transactions per second
    • Messages per minute
  • Is required throughput:
    • Average?
    • Peak?
  • Many system have low average but high peak throughput requirements
throughput example
Throughput Example
  • Throughput of a message queuing system
    • Messages per second (msp)
    • Maximum sustainable throughput (MST)
  • Note throughput changes as number of receiving threads increases
performance response time
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
Response Time
  • Example shows response time distribution for a J2EE application
performance deadlines
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
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
ICDE Performance Issues
  • Response time:
    • Overheads of trapping user events must be imperceptible to ICDE users
  • Solution for ICDE client:
    • Decouple user event capture from storage using a queue

5. Write event

to ICDE database queue

2. Write event

to queue

1. Trap user event

4. Read event

from queue

3. Return to user thread

scalability
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
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
Scale-up:

Single application instance is executed on a multiprocessor machine

Application

Scale-out: Application replicated on different machines

Application

CPU

Application

Application

Application

Scalability – Add more hardware …
scalability reality
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
Scalability – J2EE example

I.Gorton, A Liu, Performance Evaluation of Alternative Component

Architectures for Enterprise JavaBean Applications, in IEEE Internet

Computing, vol.7, no. 3, pages 18-23, 2003.

scalability connections
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
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
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 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
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!
modifiability54
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
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
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
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
Security
  • Difficult, specialized quality attribute:
    • Lots of technology available
    • Requires deep knowledge of approaches and solutions
  • Security is a multi-faceted quality …
security59
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
Security Approaches
  • SSL
  • PKI
  • Web Services security
  • JAAS
  • Operating system security
  • Database security
  • Etc etc
icde security requirements
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
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
availability63
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
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
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
Interoperability through an API facade

Application

API

Third Party Application

Data

Interoperability achieved by direct data access

Integration Strategies
  • Data – expose application data for access by other components
  • API – offers services to read/write application data through an abstracted interface
  • Each has strengths and weaknesses …
icde integration needs
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
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
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!
summary70
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 reading71
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 architecture72

Essential Software Architecture

Session 4:

A Guide to Middleware Architectures and Technologies

introduction
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

BizTalk, TIBCO StaffWare, ActiveBPEL

Message Brokers

BizTalk, WebSphere Message Broker, SonicMQ

Application Servers

J2EE, CCM, .NET

Transport

Message-Oriented Middleware, Distributed Objects Systems

Middleware Classification
outline
Outline
  • CORBA
  • Message-oriented middleware
  • J2EE
  • Message brokers
  • Business process orchestrators
corba
Client

Server

Object Reference

request

Servant

reply

client ORB

server ORB

Network

CORBA
  • Venerable distributed object technology
  • Still widely used in telecomms, defense
  • Many different implementations
corba code example
CORBA Code Example

module ServerExample

{

interface MyObject { string isAlive(); };

};

CORBA IDL

class MyServant extends _MyObjectImplBase

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

}

Server

ORB orb = ORB.init(args, null);

MyServant objRef = new MyServant();

orb.connect(objRef);

ORB orb = ORB.init(args, null);

// Lookup is a wrapper that actually access the CORBA Naming

// Service directory – details omitted for simplicity

MyServant servantRef = lookup(“Myservant”)String

reply = servantRef.isAlive();

Client

corba some thoughts
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
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
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

send

receive

queue

persistence
Persistence

queue

send

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
mom server
MOM Server

Receivers

Senders

Sending

Applications

Sending

Applications

Message

Handler Thread Pool

MOM Server

Peer-to-peer MOM technologies are the alternative design

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

send

receive

Response queue

scaling mom
MOM Server

ApplicationQ

Senders

Receivers

MOM Server

ApplicationQ

Scaling MOM
messaging some thoughts
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
Publish-Subscribe Messaging
  • Extension of MOM to provide 1-to-N, N-to-1, and N-to-N communications
  • Messages are ‘published’ to logical subjects or topics
  • Subscribers receive all messages from subjects they subscribe to

Sub

Create/

Publish

Register/

Subscribe

Pub

Subject

Sub

Sub

publish subscribe with multicast
Publish-Subscribe with Multicast

Based on

TIBCO

Rendezvous

subject topic naming
Sydney

DevGroup

SupportGroup

Information

Information

work

gossip

work

gossip

Subject/Topic Naming

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

publish subscribe some thoughts
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 application server
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

EJB Pool

Transaction

Service

Directory

Service

Lifecycle Management

Persistence

Security

Service

Connection Pool

Thread Pool

EJB Container
beans and state
state

EJB Container

state

Stateless bean pool

state

state

EJB

Clients

state

state

Stateful beans

state

Beans and State
deployment descriptors
Deployment Descriptors

EntityStock.BrokerHome

db.entitystock.BrokerHome

db.entitystock.Broker

db.entitystock.BrokerBean

Stateless

Container

EntityStock.BrokerHome

Remote

*

Required

j2ee some thoughts
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

Key:

Message =

In-format

Queue

Read

API

call

Message

Transform

Legacyformat

In-format

In-format

In-format

In-format

In-format

Legacy

System #1

Legacy

System #2

Legacy

System #3

Legacy

System #4

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

Component

Key:

Message =

In-format

Message

Broker

L1-format

L2-format

L3-format

L4-format

Legacy

System #1

Legacy

System #2

Legacy

System #3

Legacy

System #4

Alternative Solution
  • Transformations in broker
  • Simplified endpoints
  • Decouples Web and legacy components
message brokers
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 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 brokers103
Message Brokers

Hub and Spoke Architecture

Input Messages

Output Messages

Transformation

Routing

Rules Processing

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

Purchasing

Credit

Validation

Accounts

Payable

SAP

Siebel

Sales desk

Accounts

Receivable

Oracle

CustomerReceiving

Shipping

Typical Scenario
  • Business process automation
bpo architecture
BPO Architecture

Message Broker

Adapter

Adapter

Adapter

slide112
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
1 business process =

4 interfaces

5 business processes =

20 interfaces

Integration Issues – Point-to-Point
  • Point-to-Point evolution
  • Spaghetti architecture, hard to modify potentially (N2-N) interfaces
broker spaghetti
message brokerBroker Spaghetti
  • No free lunch …
  • Just relocates the spaghetti
enterprise data model
Enterprise

Data Model

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 …
summary116
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 architecture117

Essential Software Architecture

Session 5:

A Software Architecture Process

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
An Architecture Process
  • Highly iterative
  • Can scale to small/large projects
determine architectural requirements
Functional

Requirements

Stakeholder

Requirements

Determine

Architecture Requirements

Architecture

Requirements

Determine Architectural Requirements
  • Sometime called:
    • architecturally significant requirements
    • architecture use cases
  • essentially the quality and non-functional requirements for a system.
examples
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.
priorities
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
Architecture

Requirements

Choose

Architecture

Framework

Allocate

Components

Architecture

Views

Architecture

Document

Architecture Design
  • Design steps are iterative
  • Risk identification is a crucial output of the design
choosing the architecture framework
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
Client

Tier

Web

Client

Web

Client

Web

Client

Web Server

Tier

Web Server

Business Logic Tier

Application Server

Data

Management Tier

Databases

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.
messaging pattern
Client

Server

Client

Queue

Server

Client

Server

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.
publish subscribe pattern
Subscriber

Publisher

Subscriber

Topic

Subscriber

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.
broker pattern
Sender-1

Receiver-1

inPort1

OutPort1

Broker

Sender-2

Receiver-2

inPort2

OutPort2

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.
process coordinator pattern
Start

process

request

Process

results

Process

Coordinator

step1

step2

step3

step4

Server-1

Server-2

Server-3

Server-4

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.
allocate components
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
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
OrderQ

read

Write

Order

New

Orders

OrderInput

Get

Order

Check

Order

Write

Order

SendEmail

Validate

Store

Error

Log

Customer

System

Order

System

Email

Server

Figure Key

Existing Component

New

Component

Dependency

Database

Persistent Queue

A Simple Design Example
example design
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
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:
    • manual testing of the architecture using test scenarios.
    • construction of a prototype that creates a simple archetype of the desired application
  • aim of both is to identify potential flaws in the design so that they can be improved before implementation commences.
    • Cheaper to fix before built
scenarios
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.
prototyping
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
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
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
summary148
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 architecture149

Essential Software Architecture

Session 6:

Documenting a Software Architecture

architecture documentation
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
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
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
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 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
document template
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 headings
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

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

Essential Software Architecture

Session 7:

ICDE Case Study Design

ad