Comments on Software Systems HATC Corporation Beijing December

Comments on 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 gcf@indiana. edu http: //www. infomall. org 1

Design, analysis, and management of a BIG software project I n General Principles • Quality control in software development • documentation/archives • codes n n Design of the architecture of a large-scale or complicated system 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) 2

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 • • n n Principles Reliability Performance Interface between subsystem and main framework How to design a large-scale distributed air traffic control system Architecture • Modularity • Reusability (difficulty for us) • Design model (two-tier or three-tier) n n Algorithm and performance of air traffic flow control Training of senior system architect 3

Overall Remarks n n Talk based on my experience which is very different from that of your company I have developed software in a small company and in university setting with a mix of students and staff I watched other large software activities including Apache and other open source Preferred software model changes faster than software engineering techniques • • n C++ Corba Java Web Services Maybe some software engineering 4

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 n Obviously use CVS or equivalent for preserving version control Document all actions in Wiki/Blog/email 5

General Principles II n n Computers are getting faster which implies we do not have to worry about efficiency as much 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 n So avoid pointers even more and prefer to communicate data, not pointers thereto, when communicating between modules Use databases; not ad-hoc storage mechanisms where performance cost can tolerate 6

General Principles III n 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 Use tools like Junit to provide automated repeatable tests 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 • Each module separately • Full system as it builds up 7

General Principles IV n n n Minimize configuration variables that must be changed for each installation Rather provide a message-based and user-based interface that system can use to set operating parameters Make each module as independents as possible; build together • • n Module Documentation User interface (portlets are an example) Configuration interface Store configuration data in a database that is independent of system 8

Web services n n n Web Services build loosely-coupled, distributed applications, (wrapping existing codes and databases) based on the SOA (service oriented architecture) principles. Web Services interact by exchanging messages in SOAP format The contracts for the message exchanges that implement those interactions are described via WSDL interfaces. 9

A typical Web Service n 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) The simplest implementations involve XML messages (SOAP) and programs written in net friendly languages like Java and Python Web Services WSDL interfaces Portal Service Security WSDL interfaces Web Services Payment Credit Card Catalog Warehouse Shipping control 10

Messaging Structure n Web Service Communication is messaging (transport protocol, routing) using SOAP protocol Service itself Messaging Process SOAP Body Header Service itself Process SOAP Header Body Customizable Handler Chain processes SOAP Header Invoke Other Services from Header or Body 11

Merging the OSI Levels n n All messages pass through multiple operating systems and each O/S thinks of message as a header and a body Important message processing is done at • • n n n Network Client (UNIX, Windows, J 2 ME etc) Web Service Header Application EACH is < 1 ms (except for small sensor clients and except for complex security) But network transmission time is often 100 ms or worse Thus no performance reason not to mix up places processing done IP TCP App SOAP 12

Linking Modules Closely coupled Java/Python … Module B Module A Method Calls. 001 to 1 millisecond n Coarse Grain Service Model Service B Messages Service A 0. 1 to 1000 millisecond latency From method based to RPC to message based to event-based publish-subscribe Message Oriented Middleware “Listener” Subscribe to Events Service B Publisher Post Events Message Queue in the Sky Service A 13

Each Service has its own portlet Individual portlet for the Proxy Manager Use tabs or choose different portlets to navigate through interfaces to different services 2 Other Portlets OGCE Consortium

Portal Architecture Clients (Pure HTML, Java Applet. . ) Aggregation and Rendering Portlet Class: Web. Form Clients Portal Portlet Class Portal Internal Services Portlets SERVOGrid (IU) Remote or Proxy Portlets Web/Grid service Computing Web/Grid service Data Stores Web/Grid service Instruments Grid. Port etc. (Java) COG Kit Local Portlets Libraries Hierarchical arrangement Services Resources 15

General Principles V n n n Do not spend too long documenting and prefer methods like javadoc that again are naturally associated with code Do describe actions (as opposed to code functionality) in your Wiki/Blog/email The quality and speed of different people varies a lot • Evaluate this and assign responsibilities according n 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 16

General Principles VI n n Evaluate carefully timing constraints 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 -6 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 17

Consequences of Rule of the Millisecond n Useful to remember critical time scales • • • n n n Classic Programming 1) 0. 000001 ms – CPU does a calculation 2 a) 0. 001 to 0. 01 ms – Parallel Computing MPI latency 2 b) 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 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 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. 18

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 n n Remember computers are going to get faster than slower so err on side of modularity versus performance Rare to be worth optimizing performance but rather make a good design that has no bad aspects making performance unnecessarily bad 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 19

Philosophy of Web Service Grids n n n Much of Distributed Computing was built by natural extensions of computing models developed for sequential machines This leads to the distributed object (DO) model represented by Java and CORBA • RPC (Remote Procedure Call) or RMI (Remote Method Invocation) for Java 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 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 Thus replace distributed objects by services connected by “one-way” messages and not by request-response messages 20

What is a Simple Service? n 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 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 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 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 21 profile, file access. . services

• • • 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 hierarchy Lines of Code Methods Objects Programs Packages Methods CPUs Services Clusters MPPs Databases Sensor Federated Databases Sensor Nets Component Grids Compute Resource Grids Data Resource Grids Overlay and Compose Grids of Grids 22

Choice of languages n n One needs to evaluate real-time version but I would prefer Java to C++ or C Java has good software development tools and current generation of programmers well trained in it C++ allows higher performance but find out if you need this Prefer Web Service model if performance allowed • Use message-based interaction not method based where 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 23

Client Side Air Traffic Control n n Analyze all performance requirements Remember life cycle costs are larger than build costs • Difficult consequences if contract just to build – not to 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! 24

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 (Narada. Brokering) • View is rendering As Controller 25

I: Data Mining and GIS Grid Databases with NASA, USGS features SERVOGrid Faults WFS 1 UDDI Data Mining Grid WFS 3 WFS 2 NASA WMS handling Client requests SOAP WMS Client HTTP 26

Typical use of Grid Messaging in NASA Sensor Grid Eventing Datamining Grid GIS Grid 27

Typical use of Grid Messaging Filter or Datamining Sensor Grid Post after Processing Post before Processing Narada Brokering Grid Database Archives Web Feature Service Notify Subscribe HPSearch Manages WS-Context Stores dynamic data WFS (GIS data) GIS Grid Geographical Information System 28

I: Data Mining Grid Databases with NASA, USGS features SERVOGrid Faults UDDI WFS 4 SOAP Pipeline Filter PI Data Mining HPSearch Workflow Narada Brokering System Services Filter WS-Context WFS 3 GIS Grid 29

Architecture n n Consider requirements of application along side performance of computers and networks • Remember performance of hardware will increase as will cost of people 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 n n Build a data architecture in XML for all information that will be in messages Use pointers internally to entities Things in messages use system metadata to look up references • i. e. database lookup not hardware memory model As before use the slowest most general method possible • Avoid unnecessary performance Build a fault tolerance model into initial architecture 30

ATC Performance and Algorithm n n Find size (in latency, bandwidth) of critical requirements 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 n Performance requirements drive architecture Build hierarchical algorithm to match hierarchical architecture 31

How to become a Software Architect n n n Work hard! Understand modern technologies and their trends so future enhances design choices Be able to understand system (requirements) in a clear fashion Be able to decompose systems in a clear methodical fashion Isolate detail into modules and use two or three level programming model 32

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 databases Service Data • The Grid is built by coordinating such services assuming we have solved problem of programming the service 33

Two-level Programming II n n The Grid is discussing the composition of distributed services with the runtime Service 1 Service 2 interfaces to Grid as opposed to UNIX Service 3 Service 4 pipes/data streams Familiar from use of UNIX Shell, PERL or Python scripts to produce real applications from core programs Such interpretative environments are the single processor analog of Grid Programming Some projects like Gr. ADS from Rice University are looking at integration between service and composition levels but dominant effort looks at each level separately 34

3 Layer Programming Model Web Service 1 WS 2 WS N-1 Web Service N Level 1 Programming inside services Application expressed in in Java Fortran C++ MPI etc. WS-* Infrastructure Level 2 Programming choosing services by virtualization Application Semantics (Metadata, Ontology) Semantic Grid Level 3 Grid Programming composing multiple services Service Workflow, Transactions, Mediation Substantial work in UK e-Science program, international semantic web community 35

Plethora of Standards n n Java is very powerful partly due to its many “frameworks” that generalize libraries e. g. • Java Media Framework • Java Database Connectivity JDBC 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 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 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 36

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 37