This document defines top-level design of a cloud software system and its interoperation with the external systems.
The Top-level view section provides bird’s-eye view onto the system, describing system decomposition into applications and inter-system connections.
The software architecture for the server part of the web system is also described.
TOP-LEVEL VIEW
APPLICATIONS
Web application provides (Web) user interface for end-users and internal staff. Client technologies incorporated are: HTML, Flash, and JavaScript. This tier is responsible for presentation only, with all the business logic put in Business Services behind it. The implementation is based on ASP MVC.
Core business services application is the central part of the web system as it implements all the business logic. Implementation is based on WCF services with TCP/binary binding for communication with upper tiers (as most efficient of all standard bindings). WCF services are hosted in Windows service, since IIS6 hosting does not support TCP binding.
Database application provides persistency framework for business services. Data storage is implemented using SQL Server.
Web Client is a browser-based application that presents study material to users. Implementation is based on Adobe Flash platform.
Payment System is an external application that provides payment services for the web application allowing its customers to buy licenses. The payment system of choice is PayPal and Authorise.Net.
A number of Supporting Services, that are not part of the Core business services, contribute to overall system behavior. See below for details.
INTER-SYSTEM INTERFACES
(e1) This is the main interface between the web system and user’s browser that is used to allow system users to interact with the system. Communication is based on standard HTTP protocol.
(e2) This is the interface for the Client application to programmatically access the system. The main purpose of this interface is to pass study material from server for presentation on the client and receive student score in return.
(e3) The interface provided by external payment system to the web system to notify and complete transactions initiated by the customers.
SUPPORTING SERVICES
Backup/Restore Manager application implements data backup and restore services. This application communicates directly with Database application and provides its services to Core business services.
Scheduler application is responsible for triggering periodic events, such as periodic account cleanup and license expiration, which are then handled by the Core business services.
System State Manager application is responsible for managing system state (either active or inactive) and provides soft system shutdown feature.
SUPPORTING SERVICES INTERFACES
Note: all interfaces between internal services are based on .NET WCF bindings.
(i1) The interface provided by the Backup/Restore Manager to invoke backup or restore process of system data.
(i2) The interface provided by the Database application to Backup/Restore Manager to extract and upload system data during backup/restore process. The implementation is based on standard SQL Server 2005 backup mechanisms.
(i3) The interface provided by Core business services to Scheduler application to invoke system operations that support scheduling.
(i4) The interface provided by the System State Manager to initiate soft system shutdown and wakeup operation. Using this interface Core business services can query for current system state (either active or inactive).
LAYERS
The system has layered design with each subsystem spanning multiple layers:
A layer can directly access only the layer immediately below it.
The four logical layers of the web server system are:
- Data storage layer implements data persistency in the relational database
- Data accessors layer implements object-relational mapping and queries to manipulate data
- Business services layer implements actual business logic of the system
- Web presentation layer implements Web-based interface for the user to work with the system
SCALABILITY
Scalability of the system is based on the design of StockTrader benchmarking application. Thanks to this design the system can be easily scaled out by just starting another service node with minimum configuration steps.
SYSTEM COMPONENTS AND CONNECTORS
The following diagram outlines core system components and their connections to further discuss scalability options:
Users access the system using their browser via HTTP protocol. Web Application serves Web pages to users and communicates to internal Business Service which performs actual business processing and has access to the system data storage.
SCALABLE SERVICE
Following the design proposed by StockTrader benchmark each scalable service in addition to its business logic should expose two additional special-purpose WCF services: Configuration and Node service.
Configuration Service allows each service instance in the system to be configured from central configuration management console.
Node Service communicates events between several instances of the same service (like configuration change event happened to one node).
LOAD BALANCING
The following diagram depicts how load balancing of client request processing is achieved:
Each public application (or public service) can be deployed in multiple instances to many machines. Clients of the public application are not aware of each instance, instead they access the system through single end point address, identifying the application to its clients. Requests from clients are evenly distributed across running application instances thanks to Network Load Balancer (NLB). All machines running instances of the application are grouped into cluster with the same virtual IP address which is accessible to application clients.
For more information on NLB see Network Load Balancing article in Windows 2012 Help system.
Internal business services (used by public applications) can be deployed in multiple instances too. Each public application is aware of running instances of internal business services it uses and distributes request processing across them.
Each instance of the internal business service has direct access to common application data storage.
CONFIGURATION SERVICE
The following diagram is the view on the same system but with emphasis on configuration service connectors (note that connectors between other services and their clients are hidden on this diagram):
Each service (public application and internal services as well) has its configuration stored in configuration repository (data base) dedicated to this service, with multiple instances of the same service sharing the same configuration repository. Each service hosts special-purpose Configuration service that provides access to this repository. When initializing, service instance gets connection string to its configuration repository defined in its application configuration file.
Configuration defines links between services implementing different layers of the system. For example, public services depend on internal services to process requests. Having this information, single configuration service hosted by any machine can be used to configure entire system. Connecting to service instance on one layer provides direct access to configuration repository of that layer and indirect access to configuration repositories of other layers (configuration updates get ‘pushed’ through the layers via the Configuration service).
NODE SERVICE
The following diagram depicts the same system but with emphasis on node service connectors (connectors between other services and their clients are hidden on this diagram):
Each business service hosts special-purpose Node service that links together several instances (nodes) of the same service type. Through the Node service each instance can notify peer instances of configuration changes happened to this node.
SCALABILITY OVERVIEW
Having the described above design, new nodes can be easily added to improve performance of any service layer – either public or internal services.
Since all the configurable values are stored in repository and not in application configuration file then the whole system can be configured remotely and from a single management console.