Architecture 101

1
Architecture 101
This presentation is part of a short course on
Architecture and Open Systems. Please see
http//ecs.soton.ac.uk/ph/OpenSystems

• Peter Henderson
• Dependable Systems and Software Engineering and
• Open Middleware Infrastructure Institute
• University of Southampton

2
Objectives

• To talk about Very Large (IT) Systems
• Specifically Distributed Systems
• Built to Open Systems Principles
• From Components
• With Standard Interfaces
• Relate this to OMII
• And to System Research in general

3
Motivational Example
Browser
Web Server
HTTP/ HTML
Form data/ HTML
Browser IE, Firefox, Web Server Tomcat,
IIS, Jetty, Active Page JSP, ASP, PHP,
Database Connector jdbc1, odbc2, Database
Server mySQL, SQLServer,
Active Page
Query / RS
Database Connector
Database Server
SQL/ RS
Database
4
OMII - Open Middleware Infrastructure Institute

• UK funded
• A source of middleware components for Grid
  architectures
• Open System Principles
• Open standards Open source
• Harvested from eScience projects
• Quality improved
• Made available specifically for eScience projects
  in the UK

5
OMII-Europe - Open Middleware Infrastructure
Institute for Europe

• EU funded
• Interoperability among major middleware
  infrastructures
• Open System Principles
• Open standards Open source
• Three(two) middlewares
• Globus, gLite, UNICORE CROWN, OMII
• Five Business components
• JSDL, VOMS, Portal, DAI, RUS
• Raise the level of integration for cross-domain
  Grid applications

6
Open Systems Concepts

• Component
• Interface
• Modularity
• Granularity
• Standards
• Conformance
• Openness
• Portability
• Interoperability
• Adaptor
• COTS

• Architecture
• Object Oriented
• Service Oriented
• Message Oriented
• Data Oriented
• Evolution (whole life)
• Heterogeneity
• View and Viewpoint
• Reuse
• Stakeholder
• Requirements
• Connector

7
Open Systems Definitions

• An Open System is one in which many of the
  interfaces (internal and external) conform to
  widely agreed standards
• so that variety and evolution of the system can
  be achieved and
• so that portability and interoperability of
  components are achieved
• largely by plug and play

8
Motivational Example
Browser
Web Server
HTTP/ HTML
Form data/ HTML
Browser IE, Firefox, Web Server Tomcat,
Jetty, IIS Active Page JSP, ASP, PHP, Database
Connector jdbc1, jdbc2, Database Server
mySQL, SQLServer,
Active Page
Query / RS
Database Connector
Database Server
SQL/ RS
Database
9
Open Systems Principles

• For an interface to be considered to conform to
  widely agreed standards there needs to be a
  strong reason why it can be expected to be
  maintained through evolution, such as
• Its an official or de facto standard that has
  many distinct suppliers (e.g. TCP/IP)
• Its a de facto standard that has one supplier
  but on which many component suppliers are
  dependent (e.g. Windows)

10
Open Systems Principles

• The more distinct applications in which a
  component has been deployed, the more confidence
  we are likely to have in its quality and in the
  openness of its interfaces
• Legacy components need to be bridged to be part
  of an open system. The adaptor used to bridge
  them is properly considered to be part of the
  legacy. i.e we make old components into pluggable
  components rather than support legacy interfaces

11
Motivational Example
Browser
Web Server
HTTP/ HTML
Form data/ HTML
Browser IE, Firefox, Web Server Tomcat,
Jetty, IIS Active Page JSP, ASP, PHP, Database
Connector jdbc1, jdbc2, Database Server
mySQL, SQLServer,
Active Page
Query / RS
Database Connector
Database Server
SQL/ RS
Database
12
Component, Interface, Composition
Component A is a Component Interface/Service B
supplies interface J, B requires interface
K Composition BLUE contains C and D BLUE is a
Component BLUE hides interface L
A
B
K
J
C
D
L
M
K
Notation loosely based on UML derivative SysML
block diagrams
13
Compositions
14
Component

• An identifiable and generally replaceable unit of
  composition. Typically something that is
  constructed independently
• Will be known by its name and version number and
  by the set of interfaces that it supports and
  requires
• Will exist in many versions through time

15
Interface

• An identifiable and generally agreed means of
  communication with a component
• Can be call-based, message-based or stream-based
• Can be synchronous or asynchronous
• Will be known by its name and version number and
  by the protocol for using it
• Will exist in many versions through time

16
Modularity

• A system is modular if its various parts can be
  easily replaced
• Modular structure implies the existence of
  mutually agreed interfaces

17
Granularity

• A modular system may have parts of different
  sizes
• The size of the parts is referred to as the
  granularity of the modular structure
• This is a recursive concept leading to the notion
  of
• hierarchical structure

18
Standards

• International standards
• De facto standards
• Agreements among users and supplies of components
  as to the means of interfacing

19
Conformance

• A component may supply an interface that may or
  may not conform to a given standard
• Validating conformance requires the existence of
  elaborate testing capabilities

20
Openness

• A combination of the number of open interfaces
• And the extent to which these interfaces actually
  conform to particular standards
• Also related to the number on independent
  suppliers who support the interface

21
Portability

• Ability to move a component from one system to
  another without change
• Related to, but not identical to,
  interoperability
• Portbility is a property of components
• Interoperability is a property of interfaces

22
Interoperability

• Ability of two components in different systems to
  communicate with each other
• Relies on agreed interfaces
• Which may be consensus-based standards
• Or mutually agreed protocols
• Which are only Open if their descriptions are
  public

23
Adaptor

• Otherwise a bridge
• A component designed to eliminate a mismatch
  between interfaces
• To make Legacy components pluggable, they need to
  be equipped with an adaptor

24
COTS

• Commercial of-the-shelf components
• Commodity of-the-shelf components
• Generally adhere to open interfaces
• Quality includes extent to which COTS components
  can be sourced from different suppliers

25
Architecture

• IEEE 1471
• The fundamental organization of a system
  embodied in
• its components,
• their relationships to each other,
• and to the environment,
• and the principles guiding its design and
  evolution

26
Object Oriented

• A widely-used architecture for sequential
  programs
• Also a paradigm for distributed computing (e.g.
  CORBA) where remote objects can be accessed using
  remote pointers (or equivalent)
• Objects have state which needs to be made
  persistent

27
Service Oriented

• A development of Distributed computing that holds
  that the remote functionality should not be an
  object but a service
• Which generally does not have state, but which
  can access statefull resources (usually
  databases)
• More loosely-coupled than object-oriented

28
Message Oriented

• Examples are MQ and JMS
• Where remote processing is invoked by (generally
  asynchronous) messages, courtesy of a messaging
  service
• Scales well for systems where immediacy is not an
  issue (e.g. much B2B)
• Integrates well with OO and SO
• Also loosely-coupled
• Can be Point-to-point or Publish and Subscibe
  (broadcast)

29
Data Oriented

• e.g. DDS
• Distributed Architecture where emphasis is on the
  centrality of data and its (infrequent?) changes
• Processes subscribe to data sources and are
  notified of changes

30
Evolution

• Systems evolve in their functionality and other
  characteristics
• Their potential-for-change is a measure of their
  goodness
• Can new functionality be deployed simply by
  plugging in a new component
• Like installing a new application on a desktop
  computer
• See Laws on Dynamic Systems

31
Heterogeneity

• Extent to which components can be of different
  types

32
View and Viewpoint

• A Viewpoint has many Views
• This is from IEEE 1471 (see later)
• Recommends Viewpoints
• Structural
• Behavioural
• Technical
• Cross cutting (e.g. security, performance)

33
Reuse

• TBS

34
Stakeholder

• TBS

35
Requirements

• TBS

36
Connector

• Architecture is usually considered to comprise
  Components and Connectors
• e.g. processes and streams, programs and files,
  services and RPC, objects and RMI

37
Sources

• TOGAF
• ODP/RM
• IEEE 1471
• Zachman (IBM)
• ATAM (SEI) tradeoff analysis
• SEI CMMI

• UML 2.0
• SysML
• IEEE 1220 (SysE Processes)
• IEEE 12207 (SE Processes)
• Requirements mgmt tools

38
TOGAF

• Enterprise Architecture
• The Open Group Architecture Framework
• ADM Architecture Definition Method
• Comprises reference models and processes

39
ODP/RM

• Open Distributed Processing
• Reference Model
• Models of communication between components with
  interfaces
• Basis for many systems models that followed it

40
IEEE 1471

• Architecture Description Standards
• Distinguishes Viewpoint and View
• A Viewpoint has many Views
• Recommends Viewpoints
• Structural
• Behavioural
• Technical
• Cross cutting (e.g. security, performance)

41
Zachman

• Big matrix 46 of concerns

Distributed System Architecture
42
ATAM SEI

• Architecture Tradeoff Assessment Model
• Assumes business architecture is defined
• Looks at alternatives for implementation and
  deployment
• Cost Benefit analysis

43
CMMI

• Capability Maturity Model
• Integration
• Recent evolution of CMM
• Concentrating on integration projects
• Applicable to v large deployments

44
UML 2.0

• Standard for software design an documentation
• Many diagrams
• Plus underlying information model
• Object Oriented in principle
• But has been applied in many other scenarios,
  Systems Engineering in particular

45
SysML

• The Systems Engineering Evolution of UML 2.0
• Adds diagrams for Requirements and Parametric
  models
• Modifies Block diagrams
• Generally inherits much of the good stuff from
  UML (e.g. Use Case)

46
IEEE 1220

• Application and management of the Systems
  Engineering Process

47
IEEE 12207

• Software Lifecycle Processes

48
Requirements Management Tools

• Records relationships between requirements, e.g.
  refines
• Allows tracking of changes
• Usually text based (in database)
• Can be integrated with case tools such as UML
  tools

49
Our Contributions

• Based on old work I have been doing over last 10
  years in various projects

50
Background
Research Projects and Collaborations 1998 ABCD
Business Critical Design 2000 HICBSE Component
based Design 2000 RICES Large Scale Enterprise
Systems 2004 OMII Open Systems for Grids 2006
OMII-Europe Interoperability of
Grids 1991-2001 ICL/Fujitsu consulted on
architecture and open distributed systems for
large projects 2003-2006 IBM major collaborator
on setting up OMII
Papers 1995 POSD Process Oriented System
Design, based on ODP 1998 Laws Rules of
composition for components 2000 Asset Mapping
structural analysis of installed legacy
systems 2004 Distributed Systems Service
Oriented Architectures, Grids, Web Services 2006
Large Scale Systems Requirements Drift and
other reasons for failure
51
Laws for Dynamic Systems

• A component, added to a system, may not disrupt
  the behaviour of that system.
• A component, using the services of another, does
  so at its own risk and must protect itself from
  damage.
• A component offering a service does so at its own
  risk and must protect itself from misuse.

Peter Henderson Laws for Dynamic Systems ICSR
1998
52
Why Large IT Projects Fail

• There is too much optimism as to the potential
  benefits of IT and as to the cost of delivering
  those benefits
• There is too little investment at the beginning.
• Sufficient investment is made eventually, but is
  too late.
• There is not enough technical know-how in the
  project team.
• There is insufficient consideration of teams,
  project management and risks.
• The project does not plan incremental roll-out
  and fails to anticipate the effect of big-bang on
  the organisation.
• The project tries to match IT to the existing
  Business Processes of the organisation, rather
  than changing the Business Processes
• Initial underinvestment leads to an investment
  legacy, where the project has invested in bad
  decisions and doesn t have the courage to
  retreat.
• There are many management disaster scenarios such
  as parent/child or the enthusiastic-builder
• There is a requirements explosion - what is
  eventually required is significantly different
  from what was originally anticipated

Peter Henderson Why Large IT Project Fail
submitted 2006
53
Requirements Drift
54
OMII - Open Middleware Infrastructure Institute

• UK funded
• A source of middleware components for Grid
  architectures
• Open System Principles
• Open standards Open source
• Harvested from eScience projects
• Quality improved
• Made available specifically for eScience projects
  in the UK

55
OMII-Europe - Open Middleware Infrastructure
Institute for Europe

• EU funded
• Interoperability among major middleware
  infrastructures
• Open System Principles
• Open standards Open source
• Three(two) middlewares
• Globus, gLite, UNICORE CROWN, OMII
• Five Business components
• JSDL, VOMS, Portal, DAI, RUS
• Raise the level of integration for cross-domain
  Grid applications

56
OMII-Europe Architecture