Comments on Software Systems

Comments o

Software Systems

HATC Corporation, Beijing December 6 2005

Geoffrey Fox

CTO Anabas Corporation and

Computer Science, Informatics, Physics Pervasive Technology Laboratories Indiana University Bloomington IN 47401

[email protected]

Design, analysis, and management

of a BIG software project I

n General Principles

• Quality control in software development • documentation/archives

• codes

n Design of the architecture of a large-scale or complicated system n How to start

• Methodology • Decomposition • Subtask and goal

n How to choose programming language and development

environment

• Trend of programming language (C, C++, and Java) • Platforms (Windows, Unix, and Linux)

• Is there any de facto programming language(s) for a certain type of

applications (e.g. C and C++ used to be popular in real-time systems)

Design, analysis, and management

of a BIG software project II

n How to design a client-side (stand alone) air traffic control – a

real-time client-side monitor system • Principles

• Reliability • Performance

• Interface between subsystem and main framework

n How to design a large-scale distributed air traffic control system n Architecture

• Modularity

• Reusability (difficulty for us)

• Design model (two-tier or three-tier)

n Algorithm and performance of air traffic flow control n Training of senior system architect

Overall Remarks

n

Talk based on my experience which is very different

from that of your company

n

I have developed software in a small company and in

university setting with a mix of students and staff

n

I watched other large software activities including

Apache and other open source

n

Preferred software model changes faster than software

engineering techniques

• C++

• Corba

• Java

• Web Services

n

Maybe some software engineering

General Principles I

n

Have a clear management structure with one person in

charge of important decisions

• Decisions can and should be debated

n

Communicate electronically and preserve records in a

searchable fashion

• Email possible if a clean master list but probably Wikis and

Blogs are better

• Equip with Search – Google web or desktop better than most

built in search capabilities

n

Obviously use CVS or equivalent for preserving version

control

n

Document all actions in Wiki/Blog/email

General Principles II

n

Computers are getting faster which implies we do not

have to worry about efficiency as much

n

Build smaller modules

• As modules decrease in size, the overhead of interacting with

them increases

• But smaller modules with simple functionality are much

easier to build and test

n

So avoid pointers even more and prefer to

communicate data, not pointers thereto, when

communicating between modules

n

Use databases; not ad-hoc storage mechanisms where

performance cost can tolerate

General Principles III

n

Test as much as you can by having others (Q/A)

exercise code – especially where you need to evaluate

system results (output) to see if correct

n

Use tools like Junit to provide automated repeatable

tests

n

The harder tests are “where you don’t know answer”

Then I used to prepare two codes

• One was “production system” with all the bells and whistles • The other had few options and just did main problem

n

Always test incrementally

General Principles IV

n

Minimize configuration variables that must be changed

for each installation

n

Rather provide a message-based and user-based

interface that system can use to set operating

parameters

n

Make each module as independents as possible; build

together

• Module

• Documentation

• User interface (portlets are an example) • Configuration interface

n

Store configuration data in a database that is

independent of system

Web services

n

Web Services

build

loosely-coupled,

distributed

applications,

(wrapping existing

codes and databases)

based on the

SOA

(service oriented

architecture) principles.

n

Web Services interact

by exchanging messages

in

SOAP

format

n

The contracts for the

message exchanges that

implement those

interactions are

described via

WSDL

A typical Web Service

n In principle, services can be in any language (Fortran .. Java ..

Perl .. Python) and the interfaces can be method calls, Java RMI Messages, CGI Web invocations, totally compiled away (inlining)

n The simplest implementations involve XML messages (SOAP) and

programs written in net friendly languages like Java and Python

Paymen Credit

Card

Warehous e

Shipping control

WSDL interfaces

WSDL interfaces

Securit

y Catalog

Porta Service

Web Services Web Services

Messaging Structure

n

Web Service Communication is messaging

(transport protocol, routing) using SOAP

protocol

Invoke Other Services

from Header or Body

Messaging

Process SOA Header Body Process SOA

Body Header

Customizable Handle Chain processe

SOAP Header Servic

itself Servicitself

Merging the OSI Levels

n All messages pass through multiple operating systems and each

O/S thinks of message as a header and a body n Important message processing is done at

• Network

• Client (UNIX, Windows, J2ME etc) • Web Service Header

• Application

n EACH is < 1ms (except fo

small sensor clients an

except for complex security)

n But network transmissio

time is often 100ms or worse

n Thus no performance reason

not to mix up places processin done

IP

TCP

SOAP

App

Linking Modules

n

From method based to RPC to message based to event-based

publish-subscribe Message Oriented Middleware

Module A Module

B

Method Call .001 to 1 millisecond

Service A Service

B Message_s

0.1 to 1000 millisecond latency

Coarse Grain Service Model

Closely coupled Java/Python …

Service B Service A

Publisher Post Events “Listener

Subscribe to Events

Message Queue in the

OGCE

Consortiu m

Individual portlet for the Proxy Manager

Use tabs or choose

different portlets to navigate through

interfaces to different

services

2 Other Portlets

Portal Architecture

WebForm SERVOGrid(IU) Web/Griservice

Web/Gri service Web/Gri service Computing Data Stores Instruments GridPort etc. (Java) COG Kit

Clients Portal Portlets Libraries Services Resources

General Principles V

n

Do not spend too long documenting and prefer methods

like javadoc that again are naturally associated with

code

n

Do describe actions (as opposed to code functionality)

in your Wiki/Blog/email

n

The quality and speed of different people varies a lot

n

Do not let anybody take decisions into their own hands

Debate goals and processes but once decision is made

all must adhere to it

• Decisions can be changed and should be if needed

General Principles VI

n

Evaluate carefully timing constraints

n

Use simplest most robust approach that satisfies time

constraints

• That’s why I recommend databases for configuration as this

is not a time critical part of system

n

Note computer does one instruction in 10

milliseconds

but a network communication takes 1-100 milliseconds

• Invoking a process has about 1 millisecond overhead • Method calls 0.01 to 0.01 milliseconds

• Using a database a few milliseconds • People only notice 30 milliseconds

Consequences of Rule of the Millisecond

n

Useful to remember

critical time scales

• 2a) 0.001 to 0.01 ms – Parallel Computing MPI latency • 2b) 0.001 to 0.01 ms – Overhead of a Method Call

• 3) 1 ms – wake-up a thread or process either? • 4) 10 to 1000 ms – Internet delay: Workflow n

So use pointers and the compute memory system when

latencies of ≤ 1 millisecond but use URI looked up in a

context store when longer delays allowed

n

Transfer data when read-only and long latency allowed

Always choose the slowest allowed methodology and

remember when in doubt, Moore’s law favors computer

performance and systems always get more complex and

harder to maintain.

Classic

Programming

Architecture of a large System

n Divide system hierarchically into parts

• Interaction between parts will be messages with no conventional pointers • Can have URI’s that need to be looked up in a database (essentially)

n Keep doing this until overhead prohibitive

• Overhead is “surface”/”volume” for ALL systems – people, software …

-and always decreases in relative importance as system gets bigger

n Remember computers are going to get faster than slower so err

on side of modularity versus performance

n Rare to be worth optimizing performance but rather make a

good design that has no bad aspects making performance unnecessarily bad

n Specify data structures in XML NOT Java or C++ first

• Design ATCML first specifying data structures needed in Air Traffic

Control

• Map to SQL for databases (don’t use XML databases) • Map to C++ or Java for programming

Philosophy of Web Service Grids

n

Much of Distributed Computing was built by natural

extensions of computing models developed for sequential

machines

n

This leads to the

distributed object

(DO) model represented

by Java and

CORBA

•

RPC (Remote Procedure Call) or RMI (Remote Method

Invocation) for Java

n

Key people think this is not a good idea as it scales badly

and ties distributed entities together too tightly

•

Distributed Objects

Replaced by

Services

n

Note

CORBA

was considered too complicated in both

organization and proposed infrastructure

•

and

Java

was considered as “tightly coupled to Sun”

So there were other reasons to discard

n

Thus replace distributed objects by

services

connected by

“

one-way

” messages and not by request-response messages

What is a Simple Service?

n Take any system – it has multiple functionalities

• We can implement each functionality as an independent

distributed service

• Or we can bundle multiple functionalities in a single service

n Whether functionality is an independent service or one of many method calls into a “glob of software”, we can always make them as Web services by converting interface to WSDL

n Simple services are gotten by taking functionalities and making as

small as possible subject to “rule of millisecond”

• Distributed services incur messaging overhead of one (local) to

100’s (far apart) of milliseconds to use message rather than method call

• Use scripting or compiled integration of functionalities ONLY

when require <1 millisecond interaction latency

n Apache web site has many (pre Web Service) projects that are

multiple functionalities presented as (Java) globs and NOT (Java)

Simple Services

• Makes it hard to integrate sharing common security, user

profile, file access .. services

Grids of Grids of Simple Services

• Link via methods  messages  streams

• Services and Grids are linked by messages

• Internally to service, functionalities are linked by methods

• A simple service is the smallest Grid

• We are familiar with method-linked hierarch

Lines of Code  Methods  Objects  Programs  Packages

Overlay and Compose

Grids of Grids Methods Services Component Grids

CPUs Clusters Compute Resource Grids MPPs

Databases _DatabasesFederated

Sensor Sensor Nets

Data

Choice of languages

n

One needs to evaluate real-time version but I would

prefer Java to C++ or C

n

Java has good software development tools and current

generation of programmers well trained in it

n

C++ allows higher performance but find out if you need

this

n

Prefer Web Service model if performance allowed

possible

• Web services if requires messages and interoperability with

outside world

• JDBC is message based interaction with external database n

Aim at supporting both Windows or Linux platforms if

possible

Client Side Air Traffic Control

n

Analyze all performance requirements

n

Remember life cycle costs are larger than build costs

maintain

n

Use Model View Controller architecture and separate

Model and View

• Control is often the interaction between Model and View

• So client is not same as user module; always separate business

logic from user interface

n

Use GIS!

Web Services and M-MVC

n Web Services are naturally

M-MVC – Message based Model View Controller with

• Model is Web Service • Controller is Messages

(NaradaBrokering)

• View is rendering

As Controller

I: Data Mining and GIS Grid

WMS handling Client requests

WMS Client UDD

I

WFS 2 Databases with

NASA, USGS features SERVOGrid Faults

WFS

1 NASAWMS

HTTP SOAP

WFS 3

Data Mining Grid

WMS Client

Typical use of Grid Messaging in NASA

Datamining Grid

Sensor Grid

Grid Eventing GIS Grid

Typical use of Grid Messaging

Web Feature Service

GIS Grid

Geographica

Architecture

n Consider requirements of application along side performance of

computers and networks

• Remember performance of hardware will increase as will cost

of people

n Don’t fix number of tiers but rather build system from entities

linked by messages such as services linked by SOAP • Messaging good even if not SOAP

• SOAP has “container overhead”

n Build a data architecture in XML for all information that will be

in messages

n Use pointers internally to entities

n Things in messages use system metadata to look up references

• i.e. database lookup not hardware memory model

n As before use the slowest most general method possible

• Avoid unnecessary performance

n Build a fault tolerance model into initial architecture

ATC Performance and Algorithm

n

Find size (in latency, bandwidth) of critical

requirements

n

Use publish-subscribe technology to support link

between data sources and programs

• Introduces a few (1-5) millisecond delay but much easier to

build and more fault tolerant

• Prefer asynchronous links as makes more modular and more

robust

n

Performance requirements drive architecture

n

Build hierarchical algorithm to match hierarchical

architecture

How to become a Software Architect

n

Work hard!

n

Understand modern technologies and their trends so

future enhances design choices

n

Be able to understand system (requirements) in a clear

fashion

n

Be able to decompose systems in a clear methodical

fashion

n

Isolate detail into modules and use two or three level

programming model

Two-level Programming I

• The Web Service (Grid) paradigm implicitly assumes a

two-level Programming Model

• We make a

Service

(same as a “distributed object” or

“computer program” running on a remote computer) using

conventional technologies

– C++ Java or Fortran Monte Carlo module – Data streaming from a sensor or Satellite – Specialized (JDBC) database access

• Such

services

accept and produce data from users files and

database

• The Grid is built by coordinating such services assuming

we have solved problem of programming the service

Servic

e Data

Two-level Programming II

n

The Grid is discussing the composition of distributed

services

with the runtime

interfaces to Grid as

opposed to UNIX

pipes/data streams

n

Familiar from use of UNIX Shell, PERL or Python

scripts to produce real applications from core programs

n

Such interpretative environments are the single

processor analog of

Grid Programming

n

Some projects like GrADS from Rice University are

looking at integration between service and composition

levels but dominant effort looks at each level separately

Service

1 Service2

Service

3 Service4

WS 2 WS N-1

Web Service 1 Web Service N

3 Layer Programming Model

Level 2 Programming choosing services by virtualization

Application Semantics (Metadata, Ontology) Semantic Grid Level 1 Programming inside services

Application expressed in in Java Fortran C++ MPI etc.

Level 3 Grid Programming composing multiple services

Service Workflow, Transactions, Mediation WS-* Infrastructure

Substantial work in UK e-Science program, international semantic web community

Plethora of Standards

n Java is very powerful partly due to its many “frameworks” that generalize libraries e.g.

• Java Media Framework

• Java Database Connectivity JDBC

n Web Services have a correspondingly collections of specifications that represent critical features of the distributed operating systems for

“Grids of Simple Services”

• About 60 WS-* specifications introduced in last 2-3 years

• These are low level with higher level standards such as access

database (OGSA-DAI) or “Submit a job” built on top of these

n Many battles both between standard bodies and between companies as each tries to set standards they consider best; thus there are multiple standards for many of key Web Service functionalities

n Microsoft a key player and stands to benefit as Web Services open up

enterprise software space to all participants

• e.g. MQSeries (IBM) and Tibco have to change their messaging

systems to support new open standards

The WS-* Infrastructure

n

Core Grid Services build on and/or extend the 60 or so

WS-* Infrastructure specifications which define

• Container Model, XML, WSDL …

• Service Internet ( (Reliable) Messaging, Addressing)

including extensions for high performance transport and representation. This is natural basis for streaming

applications

• Service Discovery

• Workflow and Transactions • Security

• Metadata and State including lifetime • Notification

• Policy, Agreements

• Management (service interactions) • Portals and User Interfaces