1. Chapter 3
1.1. Cloud Computing
1.1.1. Definition: refers to the delivery of computing and storage capacity as a service to a heterogeneous community of end-recipients
1.1.2. Name: Clouds are used as an abstraction for the complex infrastructure it contians in system diagrams
1.1.3. Service Models
1.1.3.1. (Software as a Service) SaaS
1.1.3.1.1. Examples
1.1.3.1.2. Multi-Tenancy
1.1.3.1.3. Pay Per Use
1.1.3.1.4. Auto-upgraded
1.1.3.1.5. Accessible by many end-user devices
1.1.3.1.6. Idea: "Applications not important any more - we see the world as services accessible anywhere by anyone"
1.1.3.2. (Platform-as-a-Service) PaaS
1.1.3.2.1. Examples
1.1.3.2.2. Homogenous application run-time infrastructure
1.1.3.2.3. Elastic Scalability via scale-out
1.1.3.2.4. Sometimes combined with development services
1.1.3.2.5. Idea: "Deploy into a standardized, automated and self-maintaining application run-time
1.1.3.2.6. Why PaaS?
1.1.3.2.7. What is not so good in PaaS?
1.1.3.2.8. Public PaaS Offerings
1.1.3.2.9. Building Private PaaS Clouds
1.1.3.3. (Infrastructure as a Service) IaaS
1.1.3.3.1. Examples
1.1.3.3.2. Virtual Servers
1.1.3.3.3. Virtual Storage
1.1.3.3.4. Virtual Data-Centers
1.1.3.3.5. Dynamic Resource Scheduling
1.1.3.3.6. Idea: "Configure your datacenter via a browser"
1.1.3.4. X as a Service
1.1.3.4.1. Database as a Service
1.1.3.4.2. Messaging as a Service
1.1.3.4.3. HPC as a Service
1.1.3.4.4. Even: Human as a Service
1.1.4. Deployment Models
1.1.4.1. Private/Internal
1.1.4.2. Public/External
1.1.4.3. Hybrid
1.1.5. Characteristics
1.1.5.1. Self-Service
1.1.5.2. (Elastic) Scalability
1.1.5.3. Reliability and Fault Tolerance
1.1.5.4. Optimization and Consolidation
1.1.5.5. Quality of Service (QoS)
1.1.5.6. Mutli-Tenancy
1.1.5.7. Cost: Pay per use (CAPEX to OPEX)
1.1.5.8. Maintenance
1.1.6. Why Cloud Computing?
1.1.6.1. Turn CapEx to OpEx
1.1.6.1.1. Capex = Purchase Hardware (long term investment)
1.1.6.1.2. Opex = Rent Hardware as needed
1.1.6.1.3. Get better resource utilisation
1.1.6.2. Flexibility
1.1.6.2.1. Self-service
1.1.6.2.2. Elastic scalability
1.1.6.3. Easier to maintain/run
1.1.6.3.1. Homogenous environments
1.1.6.3.2. Auto-updated
2. Chapter 4
2.1. Engineering for PaaS
2.1.1. New patterns
2.1.1.1. Application-level modularisation
2.1.1.2. Always on
2.1.1.3. Continuous delivery
2.1.1.4. DevOps
2.1.1.5. Big/fast data
2.1.1.6. Elastic scalability
2.1.1.7. BASE
2.1.1.8. Software fault tolerance
2.1.2. Software "Engineering"
2.1.2.1. Change of paradigms: "You build it, you run it"
2.1.2.2. The "old-school" approach of increasing the production depth could be contra-productive
2.1.2.3. "No responsibility without control"
2.1.2.4. Where then is the engineering?
2.1.2.4.1. Automation of the tool chain
2.1.2.4.2. Modeling and simulation
2.1.2.4.3. Highly adaptiveness
2.1.2.4.4. Development is empirical intrinsically - there is no mass-production
2.1.3. Application Life-Cycle Automation
2.1.3.1. Automation increases speed and preserves quality
2.1.3.2. Continuous build, test, and even delivery is key to improved time-to-market
2.1.3.3. Goal: Automate manual tasks as far as possible
2.1.3.4. Attention: Maintenance effort of automation infrastructure has to be minimized
2.1.4. PaaS Age Munition
2.1.4.1. Know the software engineering basics
2.1.4.2. Know the distribution basics
2.1.4.2.1. CAP
2.1.4.2.2. scaling
2.1.4.2.3. fault tolerance
2.1.4.3. Know the PaaS principles & characteristics
2.1.4.3.1. non-technical
2.1.5. Case Study: cloudfoundry.org
2.1.5.1. OpenPaaS
2.1.5.1.1. OpenSource
2.1.5.1.2. Hybrid, Public, or Private
2.1.5.1.3. Multi-Cloud, Multi-IaaS
2.1.5.1.4. Multi-Services
2.1.5.1.5. Multi-Framework
2.1.5.1.6. Mutli-Language
2.1.5.2. Architecture
2.1.5.2.1. Kernel (CloudFoundry OSS)
2.1.5.2.2. Kernel and Orchestrator Shells
2.1.5.2.3. Orchestrator
2.1.5.3. Basic Premises
2.1.5.3.1. Fail Fast
2.1.5.3.2. Self Healing
2.1.5.3.3. Horizontally Scalable Components
2.1.5.3.4. Distributed State
2.1.5.3.5. No Single Point Of Failure (SPOF)
2.1.5.3.6. KISS
3. Chapter 1
3.1. Design Methods
3.1.1. Problem domain -> solution space
3.1.2. Principles
3.1.2.1. Abstraction
3.1.2.2. Visualisation
3.1.2.3. Modeling
3.1.2.4. Divide & Conquer
3.1.2.5. Branch & Bound
3.1.2.6. OO
3.1.2.7. Single Responsibility Principle (SRP)
3.1.2.8. Separation of Concerns
3.1.2.9. Open-Closed Principle
3.1.2.10. DRY
3.1.2.11. Program against interfaces
3.1.2.12. Dependency Inversion Principle
3.1.2.13. Dependency Injection (IoC = Inversion of Control)
3.1.3. The "What" gets translated into the "How"
3.1.4. Examples
3.1.4.1. Structured Design (SD)
3.1.4.1.1. Hierachical structured functional modules
3.1.4.1.2. Decomposition, structure, plumbing
3.1.4.1.3. Strictly divided view of data and functions
3.1.4.2. Object-oriented Design (OOD)
3.1.4.2.1. Class hierarchies
3.1.4.2.2. Information hiding, inheritance, polymorphy
3.2. Procedure model
3.2.1. Rule set for creating a piece of software from inception to delivery
3.2.2. Examples
3.2.2.1. Waterfall
3.2.2.2. Spiral model
3.2.2.3. RUP/OpenUP
3.2.2.4. V-Modell [XT]
3.2.2.5. Agile
3.2.2.5.1. XP
3.2.2.5.2. Crystal
3.2.2.5.3. Scrum
3.3. Distributed System
3.3.1. Hardware
3.3.1.1. Memory and storage
3.3.1.1.1. Address space
3.3.1.1.2. Data
3.3.1.2. Computing Power
3.3.1.2.1. CPUs
3.3.1.2.2. Processes/Threads
3.3.2. Software
3.3.2.1. Logic/Algorithms
3.3.3. Control
3.3.4. Reasons
3.3.4.1. Problem-related
3.3.4.1.1. "Real" distribution
3.3.4.1.2. e.g. calling website in USA from Europe -> needs to be transported to user
3.3.4.2. Property-related
3.3.4.2.1. Performance and Scalability
3.3.4.2.2. Fault Tolerance
3.3.4.2.3. Service and Client Location Independence
3.3.4.2.4. Maintainability and Deployment
3.3.4.2.5. Security
3.3.4.2.6. Business Integration
3.3.5. Challenges
3.3.5.1. Network Latency
3.3.5.2. Predictability
3.3.5.3. Concurrency
3.3.5.4. Scalability
3.3.5.5. Partial Failure
3.3.5.6. Rules
3.3.5.6.1. Only distribute system if distribution is really needed
3.3.6. Systemic Requirements
3.3.6.1. CAP
3.3.6.1.1. Consistency
3.3.6.1.2. Availability
3.3.6.1.3. Partition Tolerance
3.3.6.1.4. Description
3.3.6.2. ACID
3.3.6.2.1. Atomicity
3.3.6.2.2. Consistency
3.3.6.2.3. Isolation
3.3.6.2.4. Durability
3.3.6.3. BASE
3.3.6.3.1. Basically available
3.3.6.3.2. Soft-state (or scalable)
3.3.6.3.3. Eventually consistent
3.3.7. Application Areas
3.3.7.1. Examples
3.3.7.1.1. Internet
3.3.7.1.2. Telecommunication networks
3.3.7.1.3. B2B collaboration systems
3.3.7.1.4. Internation financial transactions
3.3.7.1.5. Embedded systems
3.3.7.1.6. Scientific applications
3.3.7.1.7. Google Search Engine
3.3.7.1.8. eBay
3.3.7.1.9. Amazon
3.3.7.1.10. Facebook
3.3.7.1.11. Twitter
3.3.7.1.12. Austrian Schengen Informationssystem (SIS)
3.3.7.1.13. Austrian Zentrales Melderegister (ZMR)
3.3.8. Middleware
3.3.8.1. Solves problems dealing with low-level networking
3.3.8.1.1. not easy to scale
3.3.8.1.2. cumbersome and errorprone to use
3.3.8.1.3. hard to maintain and change
3.3.8.1.4. doesn't provide transparency of the distributed communication
3.3.8.2. Solution
3.3.8.2.1. Distributed Component Object Model (DCOM)
3.3.8.2.2. Common Object Request Broker Architecture (CORBA)
3.3.8.2.3. RPC models
3.3.8.2.4. JavaSpaces/Jini
3.3.8.2.5. Enterprice Service Busses
3.3.8.2.6. MOM
3.3.9. Architectural Styles
3.3.9.1. Client-Server
3.3.9.2. N-Tier
3.3.9.3. Cluster (tightly coupled)
3.3.9.4. Peer-to-Peer
3.3.9.5. Space based
3.3.9.6. Distributed Caches/Storage
3.3.9.7. SOA
3.3.9.7.1. Web Services
3.3.9.7.2. Enterprise Service Bus
3.3.9.7.3. Process Engine
3.3.9.7.4. Task/Wizard Based UI
3.3.9.8. Command and Query Responsibility Segregation (CQRS)
3.4. Distributed Transactions
3.4.1. Transaction Processing Monitors
3.4.1.1. oldest kinds of middleware
3.4.1.2. provide infrastructure to develop, run and manage distributed transaction applications efficiently and reliably
3.4.1.3. main purpose: extend a distributed application with concept of transactions
3.4.1.4. Transactional invocations are typically marking the beginning and end of a transaction in the client code
3.4.1.4.1. At the beginning the client contacts the TP monitor to acquire a transaction ID and context
3.4.1.4.2. At the end of the transaction the client notifies the TP monitor again
3.4.1.4.3. The TP monitor then runs a commit protocol to determine the outcome of the transaction (2 phase commit, 2PC)
3.4.2. Involves more than one transactional resource
3.4.3. Conventional RPC doesn't support the transactions
3.5. Server-side
3.5.1. Component Infrastructures
3.5.1.1. Execution environment for SW components, called a component container, or container for short
3.5.1.1.1. Cannot be executed alone, they require container
3.5.1.1.2. Container services handle the technical issues of an application
3.5.2. Components and Middleware
3.5.2.1. Often built on top of ditributed object middleware as an extension
3.5.2.2. most of the functionality of component infrastructures can be build using
3.5.2.2.1. invocation interceptors
3.5.2.2.2. invocation contexts
3.5.2.2.3. suitable lifecycle managers
3.5.2.3. Existing component infrastructures already provide useful default implementations of important, recurring features
3.5.2.4. Distributed object middleware systems
3.5.2.4.1. EJB (based on Java RMI)
3.5.2.4.2. CORBA Components (based on CORBA)
3.5.2.4.3. COM+ uses DCOM
3.6. Distribution Infrastructures
3.6.1. Peer-To-Peer (P2P)
3.6.1.1. Peers communicate and coordinate themselves in fulfilling user services
3.6.1.2. Many P2P systems use remote objects internally for communication between peers
3.6.2. Grid computing
3.6.2.1. Grid consists of multiple computers linked to one system
3.6.2.2. makes extensive use of remote communication as the distributed resources need to be managed and computing requests and results need to be transmitted
3.6.3. Different code mobility paradigms extend the client/server paradigm
3.6.3.1. Remote evaluation
3.6.3.2. Code on demand
3.6.3.3. Mobile agents
4. Chapter 2
4.1. Engineering
4.1.1. Waterfall Phases
4.1.1.1. Requirements Elicitation
4.1.1.2. Architecture and Design
4.1.1.3. Development
4.1.1.4. Quality Assurance
4.1.2. Management
4.1.2.1. Procedure model
4.1.2.2. (Project-) Management ("KVP")
4.1.2.3. Product Lifecycle Management
4.1.3. All together
4.1.3.1. Methodologies
4.1.3.2. Technology
4.1.3.3. Best Practices
4.1.3.4. Tools
4.2. Design Methods and Principles
4.2.1. Methods
4.2.1.1. First idea of a system
4.2.1.2. Big Design Up Front (BDUF)
4.2.1.3. Top-down/Bottom-up
4.2.1.4. Domain/Test/Feature Driven Design
4.2.1.4.1. Rich vs. Anemic Domain Models
4.2.1.4.2. Fat vs. Lean Controllers
4.2.1.5. Copy from patterns
4.2.1.6. Design by Contract
4.2.2. Principles
4.2.2.1. Clean Code Development (CCD)
4.2.2.1.1. Separation of Concerns (SoC)
4.2.2.1.2. Inversion of Control (IoC)
4.2.2.1.3. Don't repeat yourself (DRY)
4.2.2.1.4. Keep it simple, stupid (KISS)
4.2.2.1.5. You Ain't Gonna Need It (YAGNI)
4.2.2.1.6. Favor Composition over Inheritance (FCoI)
4.2.2.1.7. Single Level of Abstraction (SLA)
4.2.2.1.8. Information Hiding (Coupling/Cohesion)
4.2.2.2. SOLID
4.2.2.2.1. Single Responsibility Principle (SRP)
4.2.2.2.2. Open Closed Principle (OCP)
4.2.2.2.3. Liskov Substitution Principle (LSP)
4.2.2.2.4. Interface Segregation Principle (ISP)
4.2.2.2.5. Dependency Inversion Principle (DIP)
4.2.2.3. OO
4.2.2.3.1. Acyclic Dependencies Principle (ADP)
4.2.2.3.2. Common Resuse Principle (CRP)
4.2.2.3.3. The Stable Dependencies Principle (SDP)
4.2.2.3.4. Law of Demeter
4.2.3. Design following rational Object-oriented analysis and design OOAD
4.2.3.1. Use-Case Model, Specification -> Analysis and Design -> Design Model, Architecture Document, Data Model
4.2.3.2. Tasks to complete
4.2.3.2.1. Identification of interfaces
4.2.3.2.2. Identification and design of subsystems
4.2.3.2.3. Identification and design of design classes
4.2.3.2.4. Modeling design and implementation mechanismus
4.2.3.2.5. Modeling nonfunctional requirements (e.g. concurrency and distribution)
4.2.3.3. Analysis vs. Design
4.2.3.3.1. Analysis
4.2.3.3.2. Design
4.3. Modeling Distribution and Parallelism
4.3.1. Modeling Distribution
4.3.1.1. Deployment view
4.3.1.1.1. Shows (distributed) nodes and connections
4.3.1.1.2. UML: Deployment diagram
4.3.2. Modeling Parallelism
4.3.2.1. UML
4.3.2.1.1. Class diagrams
4.3.2.1.2. Activity diagrams
4.3.2.1.3. Sequence diagrams
4.3.2.1.4. State diagrams
4.4. Remoting Styles and Patterns
4.4.1. Remoting Styles
4.4.1.1. Remote Procedure Call (RPC)
4.4.1.2. Messages
4.4.1.3. Shared Repository
4.4.1.4. Continuous streams of data
4.4.2. Remoting Patterns
4.4.2.1. Interface Description
4.4.2.2. Client Proxy
4.4.2.3. Requestor
4.4.2.4. Client Request Handler
4.4.2.5. Marshaller
4.4.2.6. Remoting Error
4.4.2.7. Invoker
4.4.2.8. Server Request Handler
4.5. Advanced Patterns
4.5.1. Command Query Responsibility Segregation (CQRS)
4.5.1.1. Most applications read data more frequently than they write data
4.5.1.2. Split models
4.5.1.2.1. Bring list of students rather than all students
4.5.1.2.2. Separate rich domain models from view models
4.5.1.3. Tradeoff read/write speed
4.5.1.3.1. De-normalize for reading will pay!
4.5.1.4. Separation of reading DB and writing DB, reading DB is denormalized for read-optimization
4.5.1.5. When to use: When more read than write queries are in the system
4.5.1.6. Related Patterns and Concept
4.5.1.6.1. Patterns
4.5.1.6.2. Concept
4.5.2. Application-level Modularisation
4.5.2.1. Design components as single deployment units
4.5.2.2. Prerequisite for elastic scalability in cloud environments
4.5.2.3. Facilitates
4.5.2.3.1. localisation of errors
4.5.2.3.2. always-on deployments
4.6. Domain Driven Design (DDD)
4.6.1. focuses the domain layer (req. layered architecture)
4.6.2. utilises an "Ubiquitous language"
4.6.3. Can be seen as an OOAD method
4.6.4. consists of
4.6.4.1. Architectural techniques
4.6.4.2. Design techniques
4.6.4.3. Procedures
4.6.5. Elements of the domain layer
4.6.5.1. Entities
4.6.5.2. Value Objects
4.6.5.3. Aggregates
4.6.5.4. Associations
4.6.5.5. Services
4.6.5.6. Domain Events
4.6.5.7. Modules
4.6.5.8. Factories
4.6.5.9. Repositories