The main competitive advantage of the platform is the orientation on business applications purposed for large worldwide enterprise customers. The core of the platform allows to:
The basic functionality also provides the following key features for the core and for all of the hosted applications:
Of course, all of the hosted/integrated applications should follow the main development architecture and guidelines to support the same highest level of security and reliability.
The whole platform is developed using service-oriented approach and consists of several separated services. All of the components are separately scalable and distributable. Azure as backend provides the powerful automatic scalability and SLA based on cloud technologies. Selected architecture, technologies and approaches allow to have the highest level of reliability and scalability.
Components, which implement the business logic, are developed as WCF-services. Front-end components may be implemented using different technologies and approaches (ASP.Net MVC, AngularJS etc.) as soon as they support the integration with the WCF-services.
Each of the business applications should also represent the set of services with separate business-logic and front-end.
The platform provides the set of core services that are common for all of the applications across the platform like:
The first diagram shows the general outline of the main system components. Each service node is the separate application integrated with the platform. It consists of the several components. Application component represents application’s specific front-end and business logic. It may internally consist of the several services (for example, MVC application as front-end and WCF as business logic).
At the same time, every service node has a Management Agent handling the communication with the platfom core named “Management Console”. When a new service node is provisioned, an instance of Management Agent is created.
We decided to use modular architecture approach because different software tiers will have different set of application specific parameters, different structure of tariff information and different algorithms of invoice calculation. This means that every type of application will be managed by its own Application Management Module with specific code for this application. In some cases, there might be two different subtypes of each Application Management Module, for SMB and Enterprise tenants.
Communication between Management Console and other services (service nodes, Azure, DNS service) is remote and asynchronous. When UI request is issued, remote service required to fulfill this request might be not available or busy with another task. Some requests, especially Azure provisioning requests, might take long time. Some requests are actually series of requests to different remote services.
To handle this we use asynchronous request queue. UI requests and internal Console events that require actions from other services are translated into command events. Command events are queued. Queue is implemented over SQL.
There is a background task called Queue Manager. Queue Manager polls the queue and executes commands, retries them if the service is not available and stores operation results in corresponding command event records.
There is a second communication entity called Audit Log. All Console and Application events are logged. This includes:
Some of these events will be used for billing, but some are not, so we suggest calling this database an Audit Log, not a Billing Log.
Audit Log is used for: