Information system architectures and architecting

1
Information system architectures and architecting

• A practical tour
• Einar Landre
• Cell Network AS
• einar.landre_at_cellnetwork.no

2
Topics covered

• Introduction
• Definitions and terminology
• History of information systems and their software
  architectures
• Client / Server
• Web
• Components
• Services
• Future trends and requirements
• From domain model to code A practical tour
• Levels of design
• System decomposition
• Services
• Academic foundation
• Design by contract, Open-Closed, Liskov,
  Dependency inversion, Package stability
• References

3
Introduction
4
Ancient architecture
Facts Cheops (Khufu) height 280
cubits perimeter 1760 cubits perimeter
2pheight 143.200 scale model of earth Kings
chamber 3-4-5 triangle cubit 52.35 cm
5
Architecting a dogs house
Can be built by one person Requires Minimal
modeling Simple process Simple tools
6
Architecting a house
Built most efficiently and timely by a
team Requires Modeling Well-defined
process Power tools
7
Forces in software
Functionality
Cost
Compatibility
The challenge over the next 20 years will not be
speed or cost or performance it will be a
question of complexity. Bill Raduchel, Chief
Strategy Officer, Sun Microsystems
Our enemy is complexity, and its our goal to
kill it. Jan Baan
8
Defining architecting and architecture

• Architecting, the planning and building of
  structures, is as old as human societies and as
  modern as the exploration of the solar system.
• Architecting, the art and science of building
  systems.
• Eberhardt Rechtin, The art of systems
  architecting
• Architecture The set of design decisions about
  any system (or smaller component) that keeps its
  implementors and maintainers from exercising
  needles creativity.
• A (software) systems architecture consists of
• The structure of its parts (including
  design-time, test-time, runtime hardware and
  software parts).
• The nature and relevant external visible
  properties of those parts (modules with
  interfaces, hardware units, objects).
• The relationships and constraints between them.

9
Software architecture

• Defines how the software is built
• Acts as the knowledge base of the software
• Foundation for improvement
• Foundation for change
• Foundation for new features
• Characteristics of a good architecture
• Built from recognizable patterns and archetypes
• Facilitates change and extension
• Supports the open closed design principle
• Easy to understand
• Supports the driving requirements
• Clear separation of concern
• Balanced distribution of responsibility
• Balances economic and technical constraints

10
Architecting versus Engineering

• Architecting, deals largely with unmeasurables
  using non quantitative tools and guidelines based
  on practical lessons learned (heuristic)
• Software design patterns
• Best practices
• Engineering, deals almost entirely with
  measurables using analytical tools derived from
  mathematics and the hard sciences
• Proven reliability of a system
• Formal validation and verification of correctness
• Response time requirements

11
Architecture depends on purpose

• Architectures are tightly connected to their
  purpose, and to some extent they are only
  understood through their purpose
• The pyramids?
• To be successful a architecture must meet two
  requirements
• Acceptable cost
• Acceptable time
• Some architectures has been stable for 100 years
• Automobiles
• Airplanes
• Ships
• Railroad systems
• Others close to thousand
• Cathedrals

12
Software as critical system component

• Software the centerpiece of complex system
  design
• Airplanes
• Ships (The frigate project, probably the
  largest IT project in the country)
• Healthcare
• Business (banking, retail, public services,
  traditional industry)
• Classical systems engineering is based on
  Decomposition Integration
• The system hierarchy
• Software become a sub-system of its processor
  unit
• Software architectures are layered
• Library units call another library unit
• Software and hardware hierarcys become
  disconnected
• The engine control software is a subsystem of the
  engine.
• The user interface is a subsystem of the dash
  board.
• The software architecture is layered (user
  interaction and engine control)
• Understanding this is critical when architecting
  software intensive systems

13
The situation illustrated
Car Engineer View
Software Engineer View
Car
User Interface
Communication
Engine
Dashboard
Controller
Engine Control View
Engine Controller
Both views are correct, but their purpose and
target group differs
14
System and software architecture dependencies

• System - response to a need/problem
• Bank self service
• Mobile communication system
• Naval communication systems
• Energy supply system
• System architecture (software intensive)
• The structures and parts of a system
• Defines software environment
• Naval communication system
• Satellites, phones, antennas,.
• Software architecture
• The structures and parts of software
• Includes design time, test times, language
  constraints and interfaces

15
Summary

• Today I am more convinced than ever. Conceptual
  integrity is central to product quality. Having a
  system architect is the most important step
  toward conceptual integrity.
• Fredrick P. Brooks, JR
• The mythical man month after twenty years

16
History of information systems and their software
architectures
17
In 1974 IBM released its Systems Network
Architecture (SNA)
3705 Front-End Controller
Phone Lines
3705 Front-End Controller

• Before SNA terminals was physically attached to
  programs
• SNA enabled effective use of thousands of
  terminals (users)
• Application areas involved
• 3270 terminal (synchronous terminal and printer)
  
• Transaction Processing, Time sharing and Batch
• The almighty god in a SNA network was VTAM
  (Virtual Telecommunications Access Method)
• Software architectures still monolitic (user
  interface, data and algorithms in one chunk)
• 1974 was also the year Kerf Kahn released the
  TCP/IP specification

18
Client / Server The architecture of the 1980ties
Client
Server
protocol
Files Databases
User Interface Business Logic

• Originally used to scale mini computer networks
• Client machine(s) responsible for user
  interaction and business logic
• Server machine(s) responsible for data and
  common services as print
• Applied at both at system and software levels
• Boosted by the BSD Unix release embedding the
  TCP/IP protocol stack in 1981
• Unix workstations (SUN) and later PC the
  dominant users of the architecture
• Identified problems
• Tight coupling of client and server made changes
  hard
• Distribution of software to many clients
• Lack of scalability in the large
• Sensitive to network latency
• Unreliable outside local area network
  environment
• Client and Server share state

19
Internet and Web oriented architectures (1994
today)
HTTP Transport
Client
Server
Internet
Browser
Web Server

• Browser installed on any type of computer with
  graphical user interface attached to Internet
• http//www.cellnetwork.no - The Unified Resource
  Locator (URL) was born
• Web server provided textual content formatted in
  HTML
• Java launches and become famous for its ability
  to download code (the applet)
• Web servers evolve to handle dynamic content
• Common Gateway Interface (CGI) and Perl
• Programs are impossible to maintain
• Sun launches the servlet concept, enabling server
  side dynamic HTML management
• The need to simplify user interface programming
  results in tag libraries
• Sun Java Server Pages (JSP), MS got ASP and
  Open Source got PHP
• New server side technologies has emerged
  including J2EE and MS .NET

20
Component architectures (1990 today)
TCP/IP Network

• Convergence of distributed object models (CORBA)
  and Transaction Processing Monitors
• Enterprise Java Beans (EJB)
• Distributed Component Object Model (DCOM) from
  Microsoft
• Move software towards assembly of
  pluggable-parts
• Based on the concept of hiding implementation
  from specification
• Object Oriented
• EJB uses the Java interface construct combined
  with Remote Method Invocation
• Network transparent
• Identified problems
• Solutions become more rigid than first
  anticipated (not as easy to plug)
• More TP monitor than distributed objects
• Sensitive to network latency

21
The N-tier web architecture practical use of
components
HTTP Transport
Server - side
Client
Internet
Web Server
Application Server (EJB)
Browser
Database Server

• The server side is dominated by the N-tier
  architecture
• Web, Application and Database servers are large
  software components
• They can reside on one or more physical
  computers
• The architecture provides scalability and
  redundancy
• Based on the same principles as IBM applied in
  1974
• Designed to handle thousands of interactive
  users
• Identified problems
• More rigid than first anticipated
• More TP monitor than distributed object model
• Sensitive to network latency

22
Beyond components Network to Network Services
Network to Network
XML
Network
Network
system
system

• Systems in different networks can communicate
• Also known as web services
• Supports synchronous and asynchronous
  communication
• Supported by mechanisms such as
• UDDI (Universal Description, Discovery
  Integration)
• SOAP (Simple Object Access Protocol XML)
• Systems within network built on N-tier
  technology
• Typical use
• Place an order at a supplier system
• Problems
• Scalability
• Management

23
Challenge - Systems become more and more
distributed

• Deutsches fallacies of networking becomes an
  issue
• The network is reliable
• The latency is zero
• Bandwidth is infinite
• The network is secure
• The topology doesnt change
• There is one administrator
• Transport cost is zero
• There is one administrator
• These issues are not handled by classical
  architectures such as
• N-tier
• Client / Server

24
Distributed architectures Participant to
Participant
protocol

• Participant can be anything from a super
  computer, printer, mobile phone, PDA or car
• Participants may be limited with respect to power
  supply, memory and cpu capacity
• Participants will be switched on and off
• A participant must advertise its services, and
  be able to find other participants services
• Existing architectures does not support this
• They fail on Deutsches fallacies
• Dynamic lookup of services
• Sun Jini network technology provides a solution
• Dynamic distribution of networked services is
  built into the language run-time environment
• www.jini.org
• rio.jini.org
• java.sun.com/jini

25
JavaSpaces an example of a distributed object
store
A JavaSpace is defined by a Java
interface write(Entry tmpl, Transaction txn,
Long lease) read(Entry tmpl, Transaction txn,
Long timeout) readIfExist take takeIfExist(Entry
tmpl, Transaction txn, Long timeout) notify(Entry
tmpl snapshot(Entry e) An entry is a Java object
implementing the Entry interface Class
PersonEntry implements Entry, PersonBean Public
String name // Space requires public Public
String address Public void setName(String
name) Public String getName() JavaSpace is based
on Linda Tuple spaces developed at Yale
(Gelerntner)
26
Example of a space based web architecture

• The Servlet receives HTTP requests and process
  these requests.
• Business objects are stored as JavaBeans in a
  JavaSpace, and the servlet will read and write
  bean objects to and from the space
• Behind the space specialized agents listens for
  specific types of requests in the space and
  produces valid response objects.
• The effect of this architecture is total
  decoupling of client side from server side.
• The space can be located anywhere and neither the
  servlet nor the agents need to worry about that.
• This architecture is an example of a alternative
  to client/server and N-tier, though the blueprint
  conforms to an N-tier solution.

Web Container
Servlet
read write take
JavaSpace
JavaBean Void setX(iX) X getX()
27
Architectural evolution in terms of generations

• N-tier
• Distribute applications and services across
  systems
• Requires a tightly controlled network
• An extension of the client/server model
• CORBA, EJB and DCOM
• Network to Network
• Systems in different networks can communicate
• Systems itself built with N-tier technology
• Web services, XML, UDDI, SOAP
• Participant to participant
• A participant in one network can identify and
  communicate with a participant located in another
  network
• Jini network technology

Participant to Participant
Network to Network
N-tier
Client / Server
28
Summary

• Web is similar to IBMs terminal world of 1974
• Systems Network Architecture
• Client/Server and N-tier components requires
  stable and controlled networks
• Deutsches fallacies
• Understanding round-trip delay and latency is
  required
• Components more rigid than first anticipated
• New architectures required for next generation of
  distributed collaborative systems
• Jini Network technology provides a solution
• Architectures are critical in todays software
  systems
• The more complex systems success depends on
  architecture at both system and software levels.

29
From domain model to code

• A practical tour based on Java

30
The design process Building a working system

• Decompose system into modules
• Maximize cohesion
• Minimize coupling
• Determine relations between modules
• Inheritance
• Composition
• Identify where flexibility is desirable and where
  it is not
• Determine the form of inter module communication
• Remote Procedure Calls
• Messaging
• Specify module interfaces
• Should be well defined
• Facilitate independent testing
• Improve group communication

31
Characteristics of bad design and their cause

• Rigid
• hard to change because every change affect the
  whole system
• Fragile
• when making a change, unexpected parts of the
  system fails
• Immobile
• hard to reuse in other applications because of
  tight couplings
• The main cause of bad design is direct mapping of
  the domain model
• Violating documented design principles
• Object oriented languages makes this worse
• What about components?

32
Design in practice Levels

• Architectural (system) design
• Scope Subsystems, Processors, Tasks, Packages,
  safety reliability
• Patterns Micro kernel, Rendezvous, Broker,
  Proxy
• Define terminology
• Mechanistic design
• Scope Class collaboration
• Patterns Design Patterns (GOF) and Core J2EE
  patterns ?
• Detail design
• Scope Class, Data and O-R mapping

33
Phases of design, scope and deliveries
Source Doing hard time, Douglas 1999
Design phase Scope What is specified
Architectural System wide Processor wide Number and type of processors Packages of objects running on each processor Inter-process communication Concurrency model, and inter-thread communication strategies Software layering and vertical slices Error handling policies
Mechanistic Inter-object Instances of design patterns of multiple collaborating objects Containers and design-level classes and objects Medium-level error handling policies
Detailed Intra-object Algorithmic detail within class Details of data members (types, ranges) Details of functional members (arguments)
34
Architectural design Processors (physical)
Processor boundary network boundary Think of
the software layers
35
Architectural design - Tasks

• Definition
• Separate function that must occur or appear to
  occur concurrently
• Task types
• Event driven
• Clock driven
• Priority and Critical
• Task coordinator
• Implementation
• Java Threads
• Agents
• Message driven beans
• Standalone processes
• EJB session beans

36
Architectural design Packages

• Packages is a grouping mechanism of functionality
• UML has a representation, the same has Ada , C
  and Java
• A poor package structure in Java will haunt the
  system in its lifetime
• Separate specification from implementation
• Use separate source threes
• Package structure defines the architecture
• Specifications
• no.cellnetwork.marketplace.business.MarketServiceF
  actory
• no.cellnetwork.marketplace.business.UserAccountSer
  vice
• Implementation
• no.cellnetwork.marketplace.business.MarketServiceF
  actoryImpl
• no.cellnetwork.marketplace.business.UserAccountSer
  viceImpl

37
Architectural design Packages and sub-systems
Defence system

• Group functionality into logical packages
• Required to manage complexity
• Identify interfaces and package dependencies
• Abstract versus concrete packages

Commercial system
38
Architectural design Packages and Layers

• User Interface Layer
• Responsible for all user interactions
• Realized by portal frameworks and to some extent
  Swing components.
• Includes Web services and XML interfaces for
  communication
• Business Service Layer
• Responsible for domain specific functions
• Realized by JavaBeans,Session Beans, Jini
  Services and Servlets and other ordinary classes
• Data Integration Layer
• Responsible for data access and access to other
  systems
• Implemented in databases (SQL), Entity Beans and
  Data Access Objects
• Asynchronous messaging a part of this layer

39
Architecture Illustrated

• User Interaction Layer
• Tag libraries a issue
• Usability a issue
• Information architecture a issue
• Business Service Layer
• Defined by interfaces and interfaces only.
• Interfaces should be network ready. Eg. Throws
  RemoteException.
• Implemented as EJB, Servlet,JavaBeans
• Data Integration Layer
• Defined by interfaces, message standards and
  database tables.
• Agents are self contained processes with a well
  defined purpose
• Agents can also implement domain specific
  business rules
• Message service can be JMS, Corba, JavaSpaces
• Data can be local databases or external legacy
  systems. Communication managed by agents

• User Interaction Layer
• Web, Rich client (swing) and Mobile

Business Service Layer
Business Service
Business Service
Business Service
Data Integration Layer
Access Service
Access Service
Message Service
Agent
Agent
Data
Data
Data
40
Mechanistic design

• Mechanistic design is concerned with adding and
  organizing classes to support a particular
  implementation strategy
• Bruce Powel Douglass
• Goal
• Transform the analysis model into a effective
  working design
• Maximize cohesion
• Minimize couplings
• Tools
• Separate specifications from implementation
• Design patterns (GOF book)
• Inheritance and composition
• What about EJBs?

41
Practical design step one decomposing the
domain model
42
Identified services and data objects

• ContractService
• findAll
• findBySeller
• findByBuyer
• OfferService
• make
• Find
• BidService
• make
• accept
• find
• RequestService
• make
• find

• BidBean
• getPrice
• setPrice
• CarMarketBean
• setPrice
• getPrice
• Contract
• getPrice
• getBuyer

43
Marketplace services and factory specification
44
Service specification

• Specification consists of
• Specification is composed of package and
  interface
• The service throws RemoteException and is
  implicit networked enabled
• Its up to the implementer to decide on
  distribution or not
• Sample code
• package no.cellnetwork.business.marketplace
• import Java.rmi.RemoteException
• public interface RequestService
• public Collection find(...) throws
  RemoteException
• public void make(..) throws RemoteException

45
RequestService EJB design
46
Service implementation EJB example

• Specify EJB specific interfaces
• package no.cellnetwork.business.marketplace
• import javax.ejb.EJBObject
• public interface BidServiceRemote extends
  EJBObject, BidService
• public interface BidServiceHome extends EJBHome
• public BidServiceRemote create() throws
  RemoteException,,
• Implementing the bean
• package no.cellnetwork.business.marketplace
• public class BidServiceBean implements
  SessionBean, BidService
• public Collection find()
• public void make()
• public void accept()

47
Implementing the factory

• public RequestService createRequestService()
• RequestServiceRemote remote null
• InitialContex ctx new InitialContext()
• try
• Object ref ctx.lookup("RequestService")
  
• RequestServiceHome home
  (RequestServiceHome)PortableRemoteObject.narr
  ow( ref,RequestServiceHome.class)
• remote home.create()
• catch (Exception e)
• // throw new MarketException("Could not
  create RequestService")
• return (RequestService)remote

48
Detail design the last step before code

• Scope
• Classes and type safe attributes
• Representing complex data structures
• Database design and OR mapping
• Object oriented databases and Java Data Objects

49
Making attributes type safe

• Ada provides this
• Type Missile_Speed_Type is float 0.0..6000.0
• Type Missile_Range_Type is float 0.0..4000.0
• Missile_Speed Missile_Speed_Type
• Missile_Range Missile_Range_Type
• Some_Float Float
• Some_Float Missile_Range Missile_Speed --
  Stopped by compiler !!
• Java requires class encapsulation
• Lack of operator overloading an issue
• Class Speed_Type ..
• Class Range_Type

50
Mapping objects to relational databases

• Database on 3d normal form is good for objects
  too
• No redundancy - performance an issue, use your
  brain
• No internal dependency - unique rows
• Database should be designed to support the object
  model
• Relations a result of business methods in objects
• Complex queries best done manually (Torque is a
  tool but performance an issue)
• Stored procedure speeds performance
• What about entity beans
• Think of it as a persistent object
• Spann one table, though EJB 2.0 supports foreign
  key
• Small result sets
• Consider to use a Data Access Service
• Returns valueObjects (JavaBeans)
• Encapsulates your SQL

51
Using the DataAccessService
52
Composite data structures (GOF 104)
53
Key success factors

• Architecture
• Services ( interfaces)
• Layers (packages)
• Separate specification from implementation
  (packageinterface true)
• Understanding of OO design principles
• More than inheritance
• Patterns a good tool
• Understand the network boundary (bandwidth
  latency)
• A good process addressing the right problem at
  the right time
• Hacking is banned Model your system and evolve
  it carefully
• Starting with the database is banned Database
  derived from object model
• Think in terms of design levels - Stay at the
  right abstraction level

54
Academic foundation
55
Design challenges

• Bad design is the result of violating well
  documented design principles
• Maximize cohesion
• Minimize coupling
• Academic foundation
• Design by contract
• The Open / Closed principle
• Liskovs substitution principle
• The dependency inversion principle

56
Design by contract the assertion mechanism

• Pre-conditions
• Specify properties that must hold whenever an
  operation is called
• Client responsible for checking
• Post-conditions
• Describe properties that the operation guarantees
  when completed
• Class responsible for ensuring
• Invariants
• Global properties of class that must be preserved
  at all times
• Class responsible for ensuring consistency
• Exception
• arises when pre-conditions satisfies but one or
  more post-conditions fail

57
Inheritance Design by contract

• Parents invariant rule
• Class invariants of parent are retained in the
  subclass
• Assertion redefinition rule
• Pre-conditions may only be weakened in the
  subclass
• Post-conditions may only be strengthened in the
  subclass

58
The open closed principle

• Software entities (classes, modules, components)
  should be open for extension but closed for
  modification
• Closed Client
• The client is closed because, in order to use
  another server, its code must be changed to
  mention the new server.
• Open Client
• The client is open because it uses services
  published for an abstract class. In order to
  introduce change to the server, the designer need
  only to add new derived server classes. The
  Client class remains unaltered.

59
Liskov substitution principle (Polymorphism)

• Functions that use base class interfaces must not
  depend on nor be confused by any derivatives of
  those interfaces
• This rule is a logical consequence of the
  open-closed principle
• More formally
• Consider a function F that uses type T.
• Given S a subtype of T, F should be able to use
  objects of type S without knowing it.
• Breaking it requires code like this
• void F(T input)
• if (input instanceoff S) .

Barbara Liskovs work is featured in Jim
Copliens book Advanced C Programming Styles
and Idioms
60
The dependency inversion principle

• Abstractions should not depend on details.
  Details should depend on abstractions.
• Inverted dependency with abstract layers
• Each layer derives from an abstract class. Lower
  layers used by higher layer through lower layers
  abstract interface. So Layers depends on
  abstract classes

61
Package Stability

• The dependencies between packages in a design
  should be in the direction of the stability of
  the packages. A package should only depend upon
  packages that are more stable than that it is.
• Robert Martins Package Stability Metrics
• Ca - Afferent Couplings The number of classes
  outside this package that depend upon classes
  within this package.
• Ce Efferent Couplings The number of classes
  inside this package that depends upon classes
  outside this package.
• I Instability (Ce / (CaCe)) This metric has
  a range 0,1. I0 indicates a maximally stable
  package. I1 indicates a maximally instable
  package.

62
Not all packages should be stable

• If all packages in a system where maximally
  stable, the system would be unchangeable.
• We want to design our package structure so that
  some packages are instable and some are stable.
• The ideal configuration for a system with three
  packages has the changeable packages on top. They
  depend upon stable packages at the bottom.

I1, instable
I1, instable
I0, Stable
63
The stable abstraction principle
Packages that are maximally stable should be
maximally abstract. Instable packages should be
concrete. The abstraction of a package should be
in proportion to its stability. Abstraction
versus stability It should be noted that
many packages do fall within (0,0) zone. An
example would be a database schema. Database
schemas are notorously volatile and are highly
dependent upon. This is one of the reasons that
the interface between OO applications and
databases is so difficult.
64
References

• The art of systems architecting, 2nd edition,
  2002, Maier, Rechtin, ISBN 0-8493-0440-7
• Objects, Components and Frameworks with UML,
  DSouza, Wills, 1999, ISBN 0-201-31012-0
• Pattern oriented software architectures, Patterns
  for concurrent and networked objects, 2000,
  Schmidt et al, ISBN 0-471-60695-2
• Object oriented software engineering, Jacobson,
  1992, ISBN 0-201-54435-0
• The Jini specification, 2nd edition, Waldo et al,
  ISBN 0-201-72617-3
• Doing hard time, Douglas, 1999, ISBN
  0-201-49837-5
• Design patterns, 1995, Gamma et al, ISBN
  0-201-63361-2
• Core J2EE Patterns, 2001, Crupi et al, ISBN
  0-130-64884-1
• Developing enterprise java applications with J2EE
  and UML, Ahmed, Umrysh,2002,ISBN 0-201-73829-5
• www.sei.cmu.edu
• www.bredemeyer.com