Enterprise Systems Architecture
- Architecture { Design is Goals dependent }
- Criteria {
- Speed (SLA defined Load Times)
- Availability (SLA defined Minimum Uptime)
- Load Balancing
- Redundancy (at Application Layer)
- Failover Warm Standby (at DB Layer)
- Scalability
- Fault-Tolerant (core functionality unaffected by downtime of non-critical)
- Reliability (Reprovisioning without downtime)
- Source Control (version control)
- QA cycle (test releases and issue tracking before production)
- Deployment Procedure
- Error Logging (real-time notification)
- Backups (failover DB)
- Performance tuning (Schema design)
- Statistics (Data collection and analysis exposing weak points and driving strategy)
- System Components (Independent, Isolated, Encapsulated) and and Services are unconcerned with inner workings of other Services or Front-End
- Web-Services Layer
- Complexity Strategies (at Firewall)
- Services accessible publicly for integration with other apps by Third Party Developers (Usage Restrictions, Authentication, Encryption) whilst F-E Site also accessible via Browser
- Application Layer (Front-End, Services)
- Encapsulated Services { Data Abstraction with DB access behind Services separate from consuming Front-End }
- Asynchronous Processes { Queues (Enterprise Service Bus) of info messages from Services
- Horizontal Scaling { Services split into manageable parts with Functional responsibilities across team after breakdown of large App }
- Data Warehouse fed by each Service DB (reporting and decision support)
- Complexity Strategies (within Firewall) including Service-Oriented Architecture (SOA)
- Multiple F-E & Single B-E Service { Front-End for different Business Models with multiple UIs and Feature sets (to Target Audience) that communicate over network with single Content Management Service, each with Shared underlying Content Data Structure }
- Single F-E & Multiple B-E Services { Services separated with specific API (Service API) for their feature set of major Functionality and Data Layers that are consumed by F-E UI or other Service APIs
- Persistence (DB) Layer { RDBMS persists storing and protecting the integrity of business data until changed or removed with ACID-compliant DB guarantees and properly designed Database Schema }
- Atomicity { Group statements into Single Transaction (Atomic Units) with Success or Failure (without interruption leaving Invalid Data) using .transaction method on Model Class }
- Consistency { Constraints defined Before and After Transactions with different tolerance for inconsistency }
- Isolation { Prevent access to data during Transaction Process before it is finished (when it is inconsistent) }
- Durability { Speed versus Reliability }
- Web Services Layer (External Interface)
- External Clients provided subset of inner Functionality
IN PROGRESS
Design Activities @ Lynda -
60% Complete InDesign CC Essential Training David Blatner
- DONE Competition Entry submitted my first ever design prepared with InDesign to a competition where the Design a Flyer for Oil and Gas Engineering (Engenya GmbH) @ Freelancer.com. Took about ~10 hrs using InDesign (yikes! but good practice and fun) for Chance to win US$90 (not a chance though as only got rated 2/5 stars). Lesson Learnt: Always clarify whether or not to take design specification wording literally.
Luke's Crazy Analogy for the Day
- Traditional SPAs vs AngularJS vs Precast Concrete vs Cast In-Situ
- Single Page Apps (SPAs aka AJAX apps) traditionally transport data asynchronously between client-side view (template HTML) and server-side data model (JSON or SQL database) via a RESTful controller using the MVC design pattern.
- AngularJS Apps ship the template HTML and data model to the browser for assembly whilst the server statically serves templates and associated data required
- Static Modular Precast Concrete present a DRY solution based on standardised designs that are pre-manufactured using materials in a factory, simply verified by design at fit for purpose, and shipped to site.
- Cast In-Situ Concrete solutions for unique situations require costly ad-hoc design and verification prior to shipping of raw materials to site.
- Dynamic Module Precast Concrete could be a hybrid AngularJS-like solution that enables the static serving of templates (designs) and data (constraints) that ship raw materials to site where a modular robotic contraption adapts them automatically to site environmental variable conditions and builds in-situ in real-time
- Books
- DONE AngularJS Book
- Favourite Sections:
- Chapter 6: API Parent Directives to Coordinate Child Directives
- Chapter 7: $location Service, and $safeApply Monkey Patch, AngularJS Lifecycle, Module Loading Phases and Configurations, API calls (Factory, Service, Provider), Communicating between Scopes ($on, $emit, and $broadcast) (Example Here)
- DONE JavaScript Testing with Jasmine
- DONE Google Maps API V2
- READ (only programmed using 50%) Google Maps API V3 (excellent!)
- READ Redis and Resque GitHub Article (excellent!)
- 10% COMPLETE Enterprise Rails
- IN PROGRESS Journey into Mobile Web @ Codeschool
- Fluid Layouts, Adaptive Design, Responsive Design
- Flexible Maths (Converts Pixels to %)
Problems
- Data Structures
- Dictionaries {
- Dfn: Queried (i.e. CRUD, search) Data Structures. Implementation choice affects Performance. Try each checking abstraction procedure call overhead to avoid non-time-critical options. Maintainable by Isolate Dict. Data Struct. (min. code) from Interface (bus. logic) (i.e. Separation of Concerns) }
- Hash Tables
- Skip Lists
- Balanced/Unbalanced Binary Search Trees (BTrees)
- Priority Queues {
- Dfn: Quick Access Key in Set with Highest Retrieval Priority
- Applic:
- Sort Ordered Tree Struct. Each Leaf (i.e. 7/2 or 1/5) determines Priority (i.e. Month then Date) }
- Suffix Trees & Arrays {
- Dfn: Trie (Tree Struct) to process checking if X is subString of String. Faster in Linear (search time is linear to String length) instead of O(n^2). Expensive in Memory terms.
- Applic:
- String problems. Node for each Char. Root is Null String. Branches at unique Chars. }
- Graph Data Struct {
- Dfn: Best for Algorithms repeatedly asking if (a,b) is in X. Note: Google Maps map stored in Edge Weighted Directed Graph, with Locations (Vertices) and transportation Paths (Edges)
- Issues
- Problem 1: Memory to remember large qty of Vertices and Edges. In-Memory DB that is Queried to Insert/Delete Vertices/Edges from Graph at runtime will not work properly with traditional Adjacency List
- Solution 1: Streaming Library under the hood to Dynamically Load resources
- Algorithms (e.g. Link)
- Quad-Trees
- Frustum Culling
- Applic:
- Adjacency Matrices
- Example - Best with Repeated Edge Insert/Delete using Small/Dense Graphs with say 100 Vertices, Adjacency Matrix has 10,000 entries
- Algorithms (suitable):
- Adjacency Lists
- Applic. Best with Solving Maze Puzzle with One Solution using Sparse Graphs (i.e. Google Maps)
- Example - Best with Attributes Insert/Delete of Graph Edge or Vertex (i.e. size, colour). Handle as Extra Records in Vertex or Edge Records
- Algorithms (suitable):
- Binary Search Trees (BTrees)
- DFS(Depth-First Search)-based Algorithms with Iterative Deepening (traverses nodes and edges, Remembering Previous Nodes to avoid Repetitive Infinite Loop and to prevent Not Reaching all nodes)
Curiosity
Events
Links
