Portfolio

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:

• easily manage the structure of organizations (business units, regional departments, headquarters);
• integrate corporate AD and implement SSO (Single Sign-On);
• manage users and user's roles;
• manage notifications and their templates.

The basic functionality also provides the following key features for the core and for all of the hosted applications:

• high security level based on data separation and encryption;
• high level of stability and scalabity;
• reliable notifications subsystem with guaranteed message dispatch;
• reliable authentication and authorization service with SSO based on most modern approaches involving safe certificates.

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:

• SSO (Single Sign-On);
• notifications subsystem;
• logging;
• billing;
• invoicing;
• provisioning;

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:

• errors that happened and need to be captured;
• warnings, i.e. messages about probable errors that probably need to be captured;
• user activities, such as creating a new user account, signing an NDA document;
• internal application events that are probably useful for debugging (application would emit such events only when explicitly instructed to do so);

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:

• invoice calculation;
• system health monitoring;
• application usage monitoring;
• service Engineer troubleshooting the application;
• collecting statistics and data mining for Executive Management.