System and method for creating and executing highly scaled cloud applications

Abstract

The invention relates to the field of developing and executing web-based software applications. Claimed is a group of inventions, and more particularly a cloud system and a method for developing and executing web-based software applications. The cloud system consists of microservices that interact with one another by means of a software interface. Said microservices include: a metamodel service; a metadata management service; a meta-language cross compiler service capable of translating the source code of a meta-language that describes the business logic of the object of an application into an Erlang code and compiling the resulting Erlang code into a binary code for an Erlang virtual machine, which can be loaded and executed by an application execution service; a session management service; an application execution service; an external data interface service capable of working with external databases and web services; and an external API service. The metamodel service and the session management service are designed so that they can be supplemented by at least one service on a master-slave basis in order to distribute query-related load. The technical result is that of improving efficiency, providing horizontal scaling during the development and execution of applications and also simplifying the description of the business logic of applications by the use of a meta-language.

Description

[0001] SYSTEM AND METHOD OF CREATION AND EXECUTION OF HIGHLY

[0002] SCALABLE CLOUD APPLICATIONS

[0003] AREA OF TECHNOLOGY

[0004] This technical solution relates to the development and implementation of web-based software applications. More specifically, the invention relates to methods for creating highly scalable cloud applications developed using software platforms.

[0005] LEVEL OF TECHNOLOGY

[0006] US Patent Publication No. 10, 324, 690 B2, published June 18, 2019, discloses a solution that describes a system and method for automatically creating enterprise software applications with minimal manual coding. The preferred embodiment provides a graphical design tool that models the application using the Unified Model Language (UML), validates the UML model, and automatically generates a deployable application. The preferred embodiment also provides a library framework from which the target application can be built.

[0007] Information source US 7,735,062 B2, published June 8, 2010, discloses a solution that describes a system and method for developing software applications. The claimed system and method enable the creation of visual application models, storing software application versions in a centralized repository, automatically generating and deploying software applications, identifying dependencies between software applications, and automating the development of multiple, dependent software applications by multiple developers.

[0008] Prior art solutions have several drawbacks, namely the use of XML format for storing model descriptions, which can create additional difficulties in semantic analysis of relationships with other models and elements, as they can be stored in separate XML fragments in a relational database. Prior art solutions also have poor scalability. Also, prior art solutions for application development and implementation require the client to have a specific IT infrastructure in place to run the generated application, which is unsuitable for use in SaaS (Software As A Service) mode and is more suitable for on-premises development and deployment.

[0009] ESSENCE OF THE INVENTION

[0010] The technical objective is to create a system and method for the rapid development of highly scalable cloud applications that can be used using the SaaS model. To address this technical objective, a cloud system and method for developing and executing web-based software applications were created, as defined in the independent claims. Additional embodiments of the present invention are presented in the dependent claims.

[0011] The technical result consists of increased productivity and horizontal scalability during application development and execution, as well as simplified description of application business logic through the use of a meta-language. Additionally, the technical result consists of achieving the intended purpose.

[0012] The claimed result is achieved by implementing a cloud system for developing and executing software web applications, consisting of micro-services interacting with each other via a software interface, wherein the micro-services are: a meta-model service including a meta-data repository and a meta-model interface service, wherein the meta-model service is configured to be supplemented by at least one service according to the "master - slave" scheme for distributing the load during requests; a meta-data management service containing a web interface for working with meta-data, interacting with the meta-model service for receiving and changing meta-data, configured to provide convenient means for working with meta-data constituting the configuration of application modules; implementation of a visual editor for building interface forms of the application; provision of a visual editor of the source code of the meta-language;implementation of mechanisms for working with versions of metadata described in a metalanguage, provision of tools for translating metadata into other languages ​​for localization of applications; a metalanguage cross-compiler service, configured to translate the source code of a metalanguage representing a description of the business logic of an application object into code in the Erlang language, compiling the resulting code in the Erlang language into binary code for the Erlang virtual machine, which can be loaded and executed by the application execution service; a session management service, configured to authorize users, create a session, search for an executor service with the necessary metadata, initiate the executor service with the necessary metadata, create an executor process and a web interface, supplement with at least one service according to the "master - slave" scheme for load balancing of requests;an application executor service capable of loading and executing applications stored in a system repository in the form of a set of metaobjects of complex structure, including a description of business logic in the form of compiled binary code, within a specific user work session, supplemented by at least one service for distributing the load upon requests; an external data interface service capable of working with external databases and web services; an external API service of the system.

[0013] In a particular implementation of the proposed system, the metalanguage cross-compiler contains a lexer, a parser, and an Erlang code generator.

[0014] In another particular implementation of the proposed system, the application execution service contains an executor core, a metadata cache, a web interface, and execution processes dynamically created upon request.

[0015] In another particular embodiment of the proposed system, the interface service with external data is designed to be able to work with external databases through connectors that take into account the specifics of the corresponding data source.

[0016] In another particular embodiment of the proposed system, the interface service with external data is designed to provide a unified API for working with data or web services.

[0017] The claimed result is also achieved by implementing a method for developing and executing software web applications, which contains the following stages: describing application objects in the form of meta-data stored in a meta-data repository, through a meta-data management service and a meta-model service, using a compiler-type meta-language, wherein the description of application objects is based on the description of meta-model classes;the described metadata, presented as a set of meta-objects containing properties, nested objects, and the source code of the meta-language implementing the events and procedures of the object, are converted into code in the Erlang language, while comparing the source code of the meta-language with the grammar of the language and producing a list of lexemes of the recognized language, performing syntactic parsing of the obtained list of lexemes, obtaining a syntax tree for parsing the lexemes, performing semantic analysis of the syntax tree for parsing the lexemes, obtaining the converted source code of the meta-language in the Erlang language, compiling the obtained code in the Erlang language into executable binary code for the Erlang virtual machine; writing the obtained binary code to the system repository;After launching the resulting application, a session is created via the session management service and a search is performed for the executor service with the necessary metadata, the executor service is initiated with the necessary metadata, the executor process and the web interface are created; the binary code from the system repository is launched and executed via the executor service, while the binary code is executed directly on the Erlang virtual machine.

[0018] In a particular implementation of the proposed system, the meta-model contains classes, sub-classes, attributes, behavior, types and sub-types.

[0019] In another particular implementation option of the proposed system, the description of object classes includes the addition of new classes and the inheritance of existing classes.

[0020] DESCRIPTION OF DRAWINGS

[0021] The invention will be further described in accordance with the accompanying drawings, which are provided to illustrate the invention and in no way limit its scope. The following drawings are attached to the application:

[0022] Fig. 1 illustrates the generalized architecture of the proposed cloud system. Pos. 101 - software platform, pos. 102 - application development platform, pos. 103 - application execution platform, pos. 104 - relational DBMS, pos. 105 - metadata repository, pos. 106 - meta-information, pos. 107 - interface description block, pos. 108 - business logic description block, pos. 109 - data description block.

[0023] Fig. 2 illustrates the architecture of the proposed cloud system. Item 110 — system user, Item 111 — metadata management service, Item 112 — Designer web interface, Item 113 — cross-compiler service, Item 114 — balancer, Item 115 — session management service, Item 116 — main session manager, Item 117 — main session table, Item 118 — additional session manager, Item 119 — additional session table, Item 120 — main meta-model service, Item 121 — additional meta-model service, Item 122 — main meta-model, Item 123 — additional meta-model, Item 124 — main model database, Item 125 — additional model database, Item 126 - data provider service, pos. 127 - data provider, pos. 128 - database connector, pos. 129 - external database, pos. 130 - web provider service, pos. 131 - web provider, pos. 132 - web connector, pos. 133 - external web service, pos. 134 - executor service, pos. 135 - executor core, pos.136 - metadata cache, pos. 137 - executor web interface process, pos. 138 - executor process.

[0024] Fig. 3 illustrates the executor service diagram. Item 139 - executor service, Item 140 - executor core, Item 141 - main supervisor, Item 142 - external API, Item 143 - main executor, Item 144 - executor supervisor, Item 145 - web interface supervisor, Item 146 - metadata cache, Item 147 - executor process, Item 148 - web interface process.

[0025] Fig. 4 illustrates the generalized structure of meta-data. Pos. 149 - meta-model, pos. 150 - meta-data, pos. 151 - configuration, pos. 152 - description of classes, pos. 153 - description of class attributes, pos. 154 - description of class behavior, pos. 155 - description of types, pos. 156 - description of sub-types, pos. 157 - description of modules, pos. 158 - description of meta-objects, pos. 159 - description of object properties, pos. 160 - description of object business logic, pos. 161 - versions of meta-objects, pos. 162 - system accounts, pos. 163 - meta-data schemas, pos. 164 - roles, pos. 165 - users, pos. 166 - privileges.

[0026] Fig. 5 illustrates the structure of the meta-model class description. Item 167 - main class, Item 168 - base main class, Item 169 - child main class, Item 170 - sub. class, Item 171 - class attributes, Item 172 - value types, Item 173 - attribute sub-types, Item 174 - value lists, Item 175 - class events, Item 176 - class methods.

[0027] Fig. 6 illustrates the structure of the description of the metadata object. Pos. 177 - main class, pos. 178 - meta-object, pos. 179 - class attributes, pos. 180 - class events, pos. 181 - class methods, pos. 182 - sub-class 1, pos. 183 - sub-class 2, pos. 184 - class attribute A1, pos. 185 - class event E1, pos. 186 - class method implementation, pos. 187 - object property and value for attribute A1, pos. 189 - implementation of object event E1, pos. 190 - implementation of object procedure P1.

[0028] Fig. 7 illustrates the diagram of versioning of a metadata object. Pos. 191 - meta-object, pos. 192 - unchangeable attributes of the object, pos. 193 - version 1 of the object data, pos. 194 - version 2 of the object data, pos. 195 - value of the property of the object of version 1, pos. 196 - implementation of the event of the object of version 1, pos. 197 - implementation of the procedure of the object of version 1, pos. 198 - value of the property of the object of version 2, pos. 199 - implementation of the event of the object of version 2, pos. 200 - implementation of the procedure of the object of version 2.

[0029] Fig. 8 illustrates the meta-information delimitation scheme. Pos. 201 - account, pos. 202 - scheme 1, pos. 203 - scheme 2, pos. 204 - module, pos. 205 - object, pos. 206 - relationships between objects, pos. 207 - meta-model, pos. 208 - data description, pos. 209 - sub-accounts, pos. 210 - roles, pos. 211 - users, pos. 212 - privileges.

[0030] Fig. 9 illustrates the process of compiling the source code of the system's Meta-language. Item 213 - meta-language compiler, Item 214 - Erlang compiler, Item 215 - meta-language source code, Item 216 - Erlang source code, Item 217 - binary module in BEAM format.

[0031] Fig. 10 illustrates the algorithm of the meta-language compiler. Item 218 - meta-language source code, Item 219 - lexer, Item 220 - parser, Item 221 - Erlang code generator, Item 222 - list of lexemes, Item 223 - syntax tree, Item 224 - Erlang source code, Item 225 - lexical analysis error, Item 226 - syntactic parsing error, Item 227 - compilation error.

[0032] Fig. 11 illustrates the operation scheme of the meta-language parser. Pos. 228 - parser, pos. 229' - list of lexemes, pos. 229 - syntactic analysis, pos. 230 - checking for duplicate variables, pos. 231 - checking for references to variables, pos. 232 - checking for references to built-in functions, pos. 233 - checking for references to meta-data, pos. 234 - syntax tree, pos. 235 - context-free grammar, pos. 236 - table of names (variables), pos. 237 - table of built-in functions, pos. 238 - meta-data repository.

[0033] Fig. 12 illustrates an example of a syntax tree. Pos. 239 - variable N, pos. 240 - assignment operator, pos. 241 - subtraction operator, pos. 242 - sin() function, pos. 243 - number 100, pos. 244 - multiplication operator, pos. 245 - number 10, pos. 246 - addition operator, pos. 247 - abs() function, pos. 248 - number -1, pos. 249 - number 3.

[0034] Fig. 13 illustrates the Erlang code generator operation diagram. Item 250 - code generator, Item 251 - syntax tree, Item 252 - syntax tree traversal, Item 253

[0035] - compilation of variable declarations, pos. 254 - compilation of operators and expressions, pos. 255 - checking of function arguments, pos. 256 - Erlang code generation, pos. 257 - Erlang source code, pos. 258 - semantic checking, pos. 259 - table of built-in functions, pos. 260 - Erlang code templates.

[0036] Fig. 14 illustrates the structure of the Erlang module. Item 261 - Erlang module, Item 262

[0037] - preliminary declarations, pos. 263 - main function of the module, pos. 264 - module declaration, pos. 265 - declaration of procedure parameters, pos. 266 - functions for working with variables, pos. 267 - functions for working with arrays, pos. 268 - RETURN processing function, pos. 269 - registration of parameters, pos. 270 - initialization of parameters, pos. 271 - registration of variables, pos. 272 ​​- main procedure code, pos. 273 - call of the RETURN function.

[0038] Fig. 15 illustrates the algorithm for creating a user session. Item 274 - request to create a session, Item 275 - session manager, Item 276 - request to allocate an executor, Item 277 - check for the presence of an executor with a scheme, Item 278 - check for the presence of an executor with a module, Item 279 - check for reaching the maximum limit on the number of users, Item 281 - check for reaching the maximum limit on the cache capacity, Item 280 - instantiation of a new executor service, Item 282 - executor service, Item 283 - initialization of a scheme, Item 284 - loading a module from metadata, Item 285 - creation of an executor process, Item 286 - creation of a web interface process.

[0039] Fig. 16 illustrates the algorithm for executing a business logic procedure. Item 287 - web interface process, Item 288 - initiation of procedure execution, Item 289 - executor process, Item 290 - checking the procedure code in the process, Item 291 - transferring the procedure for execution, Item 292 - Erlang OTP, Item 293 - calling system kernel functions, Item 294 - main executor, Item 295 - calling built-in meta-language functions, Item 296 - loading code into the meta-data cache, Item 297 - checking the procedure code in the cache, Item 298 - loading code from the cache into the executor process, Item 299 - binary code of the procedure, Item 300 - system repository, Item 301 - model service, Item 302 - binary procedure code, pos. 303 - metadata cache.

[0040] Fig. 17 illustrates the general diagram of the computing device.

[0041] DETAILED DESCRIPTION OF THE INVENTION

[0042] The following detailed description of the invention includes numerous implementation details intended to provide a clear understanding of the present invention. However, one skilled in the art will readily appreciate how the present invention may be utilized with or without these implementation details. In other instances, well-known methods, procedures, and components have not been described in detail to avoid unnecessarily obscuring the features of the present invention.

[0043] Furthermore, it will be clear from the foregoing description that the invention is not limited to the embodiment described. Numerous possible modifications, changes, variations, and substitutions, while preserving the spirit and form of the present invention, will be apparent to those skilled in the art.

[0044] The proposed method and cloud system for developing and executing web software applications are based on representing software applications in the form of metamodels stored in a system repository and executed on a computing device.

[0045] A cloud-based system for developing and running web applications consists of microservices interacting with each other via an API. The proposed cloud system ensures high performance and horizontal scalability for accommodating large numbers of simultaneous users.

[0046] Fig. 1 illustrates the generalized architecture of the proposed system for developing and executing web software applications.

[0047] The architecture involves dividing software applications into two large parts: the software core (platform) 101 and the application part (meta-information) 106, stored in the repository 105. Meta-information is stored in the system repository, organized in the relational database management system (RDBMS) 104. The software core (platform) 101 consists of two large subsystems: the application development platform 102 and the application execution platform 103.

[0048] Application development platform 102 is responsible for providing developers with tools for describing application models in the platform format. Examples of such development tools include: a system metadata navigator, a meta-object attribute editor, an object interface form editor, and a business logic procedure editor.

[0049] Application execution platform 103 provides mechanisms and resources for launching applications based on metadata descriptions. The execution platform uses application metadata stored in the metadata repository to load and execute applications, including generating the application interface, user interaction, and executing business logic procedures.

[0050] The application description in meta-information 106 consists of three main parts: a description of the business object interface 107, a description of the object's business logic 108, and a description of the data 109. The application's business object interface is described by a set of attributes and visual forms of the objects. The object's business logic is described using the system's built-in meta-language, compiled for execution into binary modules. The application's data description is defined by the data provider and is described by a set of data sources, which may include various DBMSs or web services.

[0051] Fig. 2 illustrates the detailed architecture of the proposed system.

[0052] The proposed system is based on a meta-model service 120, which enables storage and access to metadata in the system repository. The service consists of a relational database 124, which includes the system repository, and a meta-model 122, which supports all operations related to the system repository and provides an external API interface to the repository capable of handling multiple parallel asynchronous requests. Using the API abstracts the data structure within the repository (in the relational database) and ensures independence from the metadata storage method.

[0053] The main functions of the meta-model service for working with the system repository are: obtaining meta-information for arbitrary requests to the repository; entering new meta-information; modifying existing meta-information; deleting meta-information.

[0054] The meta-model ensures the integrity of meta-data during any operations with meta-information.

[0055] To improve system performance with a large number of repository requests, as well as to enhance fault tolerance, the system provides for a master-slave meta-model configuration, in which the primary service (the "master") is supplemented by several "slaves," and the request load can be distributed among them. Figure 1 shows a "slave" meta-model service 121, which also has its own relational database 125, which contains a copy of the system repository. The databases of the primary and slave services are synchronized (replicated) automatically. Meta-information modification operations are possible only in the primary service, while requests to read meta-information are possible in all services. If the primary meta-model service fails for any reason, one of the "slaves" takes its place and becomes the primary service, and all other services begin to synchronize with it.In this scheme, the number of “slave” services of the meta-model is practically unlimited and is determined by the scaling requirements of the system.

[0056] The 111 metadata management service is designed to provide system users with all the necessary resources and tools for application development. The core service is the Application Designer web interface, which provides a convenient interface for developers to work with metadata. The Designer web interface interacts directly with the metamodel service via an external API to retrieve metadata and make changes to it.

[0057] The service's main functions include: managing business accounts and sub-accounts and accessing them; managing system users, user roles, and privilege lists; managing metadata schemas and accessing them; managing metadata (a set of classes and their descriptions, including attributes and behavior); convenient navigation through applications (modules) and metadata objects in the selected schema; and providing metadata object editors. The Designer web interface also implements a visual editor for constructing object interface forms; and a source code editor for business logic procedures and events.

[0058] The service implements a mechanism for working with metadata object versions and also provides the ability to translate business object metadata into other languages ​​for application localization. The Designer web interface also interacts with the 113 cross-compiler service to translate the source code of metalanguage procedures into executable binary code.

[0059] The metadata management service enables parallel operation of a large number of users simultaneously, allocating a separate process for each user session.

[0060] The implementation of the metadata management service also assumes the possibility of horizontal scaling by launching additional services between which sessions will be distributed using load balancer 114.

[0061] Cross-compiler service 113 is used to translate the source code of application business logic procedures and events (meta-language) into executable binary modules that can be loaded and executed by the application runner service. It is part of the application development system, along with the metadata management service, and is used only from the Designer web interface. The cross-compiler service provides an external API for calling its methods and can handle a large number of asynchronous requests simultaneously. If horizontal scaling is required to handle even more requests, multiple compiler services can be launched, with requests distributed automatically using load balancer 114.

[0062] Cross-compiler service 113 contains a lexer, parser, and Erlang code generator. The compiler service receives the source text of the system's metalanguage procedures, along with additional information required for compilation, such as modules and objects. The compiler provides full grammatical and syntactic analysis of input language constructs and generates compilation errors. During compilation, the service interacts with meta-model service 120 to obtain additional meta-information about the metadata objects used in the procedure's source code, for example, to validate the list and types of arguments for a called application procedure or object. If the meta-model service is unavailable for query from the compiler, the compilation process cannot be completed.Upon successful completion of compilation, the compiler produces binary code of the compiled procedure, compatible with the Erlang virtual machine, which is written by the metadata management service to the system repository.

[0063] Session management service 115 contains session manager 116 and local session table 117. The primary function of the session manager is to authenticate system users and authorize them to use system resources. Authentication and authorization are performed for any user who will use the application development or execution subsystem. This means that before a user can launch, for example, the Designer web interface, the session management service must identify the user using their credentials (e.g., login and password). To authenticate, the session management service makes a request to the meta-model service, where all user accounts are stored. If authentication is successful, the service must authorize the user to launch the Designer web interface with the parameters requested by the user, such as a business account or meta-data schema.

[0064] If authorization is successful, the service creates a session for the user and transfers it to the Designer web interface, which then processes all incoming requests. If the user launches a business application from the system repository, the session management service, after creating the session, allocates application executor resources and transfers the session to the executor. The executor resource allocation process consists of the following steps: searching for an executor service with the necessary metadata, initiating an additional executor service if necessary, initiating the executor service with the necessary metadata, and creating the executor process and the Designer web interface. After a session is created, information about it is written to the local session table of the session manager. After the user exits the application, information about the session is deleted from the service's session table, and the allocated executor processes and the Designer web interface are terminated.To improve the performance of the session management service under high request volumes and to enhance fault tolerance, the system features a master-slave configuration, in which the primary service (the "master") is supplemented by several slaves, all of which can share the load when requests are received. The diagram shows slave session manager 118, which also has its own local session table 119, which contains a copy of the primary session manager's session table. The session tables of the master and slave session managers are synchronized automatically. If the master session manager fails for any reason, one of the slaves takes its place and becomes the primary, and all other managers begin synchronizing with it. Load balancer 114 automatically distributes the load between session management services, as well as between meta-model services.

[0065] The 134 executor service is the basis of the application execution subsystem and ensures the launch and execution of business applications, the description of which is stored in the system repository.

[0066] The main components of the executor service are the executor core 135, the metadata cache 136, the web interface process 137, and the executor process 138.

[0067] The executor core (140 Fig. 3) consists of the main supervisor 141 (Fig. 3), the external AP1 module 142, the main executor 143 together with the built-in meta-language functions, the executor process supervisor 144, the web interface process supervisor 145. The external API 142 provides a set of methods for managing and using the execution service, including methods for initializing the service, loading meta-data, obtaining information about the service and its state, and executing business logic procedures. The main executor module 143 implements the main methods of the service operation, and also contains the implementation of the built-in functions of the system meta-language. The executor supervisor 144 is responsible for instantiating and managing the executor processes 147. The web interface supervisor 145 is responsible for instantiating and managing the processes of the web interface 148.

[0068] Metadata cache 146 (Fig. 3) is a software-managed structure in the execution service process memory, designed for local storage of metainformation necessary for launching and executing business applications by the execution service. Executor core 140 implements the external API for the service and is responsible for interaction with the meta-model service and the session management service. The executor core also manages the service's internal processes. Metadata cache 146 (Fig. 3) stores metainformation associated with the metadata schema (e.g., descriptions of providers and data sources), as well as complete information about the application business objects (modules) contained in the schema. The cache can store metainformation belonging to only one metadata schema. Using a local cache during execution of the executor eliminates the need to access the meta-model service for metadata, which significantly increases performance and reduces the intensity of communication within the system.

[0069] The web interface process 137 (Fig. 2) and the executor process 138 are intended to service a separate session of a user who works with a business application in the system.

[0070] The executor process 147 (Fig. 3) is created by the executor supervisor 144 in response to a request to the executor service from the session management service. The web interface supervisor 148 creates the web interface supervisor 145 when a new user session is created during the launch of the business application for execution. For each user session, a separate pair of execution and web interface processes is always created, thereby achieving complete isolation of the execution of business applications for different sessions. The web interface service 148 interacts with its paired executor service 147 during operation; for example, upon certain actions of the application user, the web interface service can initiate the execution of a business logic procedure using the executor process. The executor process 147 also closely interacts with the metadata cache, for example, when it is necessary to retrieve information about a meta-object during the execution of a business procedure.Moreover, different worker processes can simultaneously access the same data set in the worker service cache if they are sessions of the same application. Thus, a single worker service can serve multiple user sessions if they belong to the same set of applications within the same metadata schema.

[0071] The executor service is completely autonomous and, after initialization, is virtually independent of other system services, enabling virtually unlimited horizontal scaling of the application runtime system to handle very large numbers of concurrent user sessions. Scaling is achieved through the automatic instantiation of additional executor services required to handle new users, depending on the current system load.

[0072] To enable the application to work with external data, external data provider services 126 (Fig. 2) and web services 130 are used. The basis of the provider service is the corresponding provider (data 127 or web provider 131), as well as connectors to data sources 128 or connectors to web services 132. Each connector takes into account the specifics of the corresponding data source 129 or web service 133 and ensures work with them at a low level of the data transfer protocol or service API, performing the transfer of data or commands from / to the data source or web service. The data or web service provider provides a unified API for working with data or services for the system's business applications, abstracting from the specifics of specific data sources or web services.Configuration of web service data providers is performed using the metadata management service. The provider configuration is stored in the metadata in the system repository and can be adjusted at any time by the application developer. Providers interact with the application service worker processes, accepting commands to retrieve or modify data or transmitting received data.

[0073] The following will describe the method for developing and implementing software web applications.

[0074] The first step in the proposed method is to describe arbitrary application business objects in metadata stored in a system repository (metamodel) within a relational database. This description is performed through a metadata management service and a metamodel service using a compiler-based procedural metalanguage with support for objects implementing complex application business logic. The description of application objects is based on the description of metamodel classes.

[0075] The repository's data structure is designed to ensure maximum flexibility and the absence of practical limitations on the possible ways to describe business objects, including their properties (attributes), behavior (methods and events), structure, and relationships. To address this, a model abstraction layer was introduced in the form of object classes (proto-objects), which define all the structures and data necessary to describe real business objects.

[0076] Fig. 4 describes the generalized structure of the metadata repository of the proposed system. The main parts of the repository are: meta-model 149, meta-data 150 and configuration 151.

[0077] Meta-model 149 describes the composition and structure of metadata proto-objects. This approach ensures maximum flexibility and the absence of practical limitations on the possible methods for describing business objects, allowing the basic set of meta-model classes to be expanded as needed. Class description 152 includes a set of attributes 153 and their types 155 (as well as subtypes 156, if necessary); behavior 154—a set of class methods and events; and class structure—if the class is complex and contains nested classes.

[0078] Metadata 150 contains descriptions of business objects 158, which are part of applications (modules) 157. The description of each object 158 ​​is based on the description of its class 152 in metamodel 150. The set of properties 159 and their object types is uniquely defined by the set of attributes of the object class. The values ​​of object properties may be both scalar values ​​of simple types and references to other objects or their properties. The set of procedures of the object's Business Logic 160 is determined based on the behavior (methods and events) described in the class. Object data can be versioned, that is, different versions of the object's property values, created at different points in time, can be saved.

[0079] Configuration 151 contains the structures necessary for organizing all metadata and providing access to it by system users. All metadata, and in particular the configuration, is divided into accounts 162. An account represents a grouping of information based on access rights and unites roles, users, and their privileges, and also includes schemas with all metadata within. Schema 163 is another level of metadata separation based on semantics. A schema determines which metamodel is used within a given schema and, accordingly, how metaobjects are described within that schema.

[0080] Figure 5 illustrates the structure of a meta-model class description. Classes can be of one of two types: a main class 167 or a subclass 170. The main class can be used to describe business objects in the metadata. Subclasses are used to form the structure of complex (composite or nested) classes and cannot be used independently to describe business objects, but only as part of main classes.

[0081] Any class is described by a set of attributes 171 , each of which has a specific type 172 and possibly a subtype 173 . The attribute value type can be a simple scalar type (e.g., numeric, text) or be a reference to: a value list element 174 , another primary class 168 , or an attribute of the primary class. The set of attributes uniquely determines which properties of a business object of a given class should be described and stored in the metadata.

[0082] In addition to attributes, a class can have methods 176 and events 175. The set of methods and events for a class defines its behavior. A class method is a named, predefined procedure that defines the operations possible for an object of a given class. Examples of class methods include: create a new element, write data, and delete an element. Method implementation is assigned to the class itself; that is, method procedures must be predefined for each class. Method procedures are called for execution as a result of user interaction with the application or programmatically (from other business logic procedures). A class event is a named class procedure that is defined for a business object in the metadata. Each class has its own set of events, which uniquely determines which events can be defined for a business object of a given class; that is, the implementation of an event procedure is done in the business object, not in the class.Object event procedures are called to execution as a result of user interaction with the application when certain conditions occur (for example, double-clicking the left mouse button).

[0083] To describe complex (nested) classes, a class structure is used. This structure is a hierarchical set of references to the subclasses that make up the class. Hierarchy here means that each subclass used in the structure can in turn also have nested subclasses. Class structures cannot use classes of the main type; only subclasses are allowed. The class structure determines the constituent parts of a business object and how the object's representation in metadata will be constructed. An example is the main "Document" class, which may contain a "Form" subclass. Using this structure, it is possible to represent a business object of the "Document" class as a collection of form objects that define the visual representation of this object.

[0084] Extending the meta-model is possible in two ways: adding new classes or inheriting from an existing class. A newly created class must define a set of attributes, events, and methods, as well as its structure. Once the new class is defined, business objects can be created for that class. Inheritance is used when the new class largely replicates an existing class with minor modifications. With inheritance, the child class receives all the attributes, methods, and events, as well as the structure of the parent class, but can also add its own attributes, methods, and events, and extend the class structure. Overriding the attributes, methods, and structure of the parent class is prohibited in the child class.

[0085] Fig. 6 illustrates a method for describing a meta-object of meta-data based on the definition of a meta-model class. In this example, class 171 has two attributes (179): attribute A1 (184) and attribute A2. According to this definition, when creating a description of meta-object 178 belonging to this class, the values ​​of the properties of object 187 corresponding to attributes A1 and A2 must be entered. In this case, the type of the value, for example, for the property of object A1 (187), must correspond to the type and sub-type of the attribute of class A1 (184). In the meta-object, it is possible (but not necessary) to define the implementation of procedures for the events of the class (180). In this case, the signatures of the object procedures (procedure name, return value type, list and types of arguments) must fully correspond to the description of events in the class. For example, the implementation of the event of object E1 (189) must correspond to the description of the event of class E1 (185). In the object, it is possible to define the implementation of only those events that have been described in the class.The implementation of object event procedures occurs through the use of an object of the "object event" subclass 182, defined in the class structure. As described above, class methods 181 must be implemented directly in the class. In this example, the class defines two methods 186: method 1 and method 2. Finally, according to the class definition in this example, it is possible (but not required) to define any number of business logic procedures in the meta-object. The procedures are not declared in advance in the class. The implementation of object procedures occurs through the use of an object of the "object procedure" subclass 183, defined in the class structure.

[0086] The mechanism for storing objects in a metadata repository allows for versioning (optional). Figure 7 describes the meta-object data versioning scheme. In this case, all meta-object data is divided into a non-versioned and a versioned portion.

[0087] The non-versioned portion of an object contains immutable attributes 192, such as class and a reference to the parent object, and is used to implement object references and establish relationships between objects. Object data that may change as a result of the object's development (revision) is located in the versioned portion (193, 194).

[0088] The versioned part contains: the values ​​of the properties of object 195, the implementation of the events of object 196, the implementation of the procedures of object 197. The version of an object is a set of versioned data of the object stored in the metadata repository with a unique identifier (number) of the version.

[0089] If the system operates in non-versioning mode, all changes to object data are recorded with version number 0 (old data is not saved). If versioning mode is enabled, modified data for object 194 is recorded with a new version number, while old data for object 193 is also saved with the previous version number. To begin editing an object in versioning mode, a "check-out" operation must be performed. This locks the current (current) version of the object from being edited by other users, and a new version of the object is created, into which the changes are entered. Once the changes are complete, a "check-in" operation is performed, resulting in the new version of the object becoming current and the previous version being unlocked.

[0090] Each version of a meta-object can belong to a specific branch. Within a single branch, all versions of an object are stored sequentially, but different branches can store different versions of objects in parallel. Only one version within a branch can be current (this is the latest version in the branch). In addition to the current version flag, versions can be marked as a "working" version. A working version is a stable and tested version of an object that can be used for execution in an application. Only one working version of an object can be installed (it does not necessarily have to be the same as the current version).

[0091] The proposed cloud system and method can operate in SaaS mode. For the application development and execution system to function in a multi-user environment, a reliable method for delimiting meta-information, including the meta-model, meta-data, and configuration, must be provided. Figure 8 illustrates the method for delimiting meta-information in the system.

[0092] The basis of differentiation is an entity called an "account" 201. An account here refers to a non-personal account of a registered business user of the system. Within the main account, sub-accounts 209 can be created, which are subordinate to the main account. An account must contain at least one personal user profile 211, and the number of user profiles is unlimited. Each user profile can be assigned a specific role 210 and a set of privileges 212. An important feature of this differentiation method is that users, their roles, and privileges are defined separately within an account, meaning they are independent of the users, roles, and privileges of another account.

[0093] The next level of meta-information delimitation is the entity designated as a "schema" (202, 203). A schema combines interrelated information from the meta-model and meta-data, such as descriptions of classes, data, and meta-objects. In this approach, each schema contains its own meta-model (description of classes or proto-objects), which ensures independence from other schemas even within a single account and allows for the safe extension or modification of the meta-model without the risk of unpredictable changes to the description of business objects in another schema. The schema also serves as a "container" for applications developed and executed on the platform, designated by the term "module" 204. An application (module) is a collection of business objects 205, each of which can belong to only one module. To ensure the possibility of reusing business objects from one module in other modules, a mechanism of links 206 between modules is used by creating links to objects.Relationships (object references) can only be created between modules within a single schema. A schema also contains descriptions of external data sources 208 required for application operation. Data sources can be used by any application (module) within a single schema. Thus, modules are grouped into schemas based on functionality (related business objects) and the principle of using common data.

[0094] As mentioned previously, web application development is based on describing arbitrary application business objects in metadata using a compiler-based procedural metalanguage, with support for objects implementing complex application business logic. The language grammar is designed to allow direct interaction with application metadata objects, as well as the efficient use of data from external sources. All application business logic code is broken down into separate procedures or event handlers and bound to business objects in the metadata. This allows for the use of the metaobject context within the procedure itself, for example, a reference to the object's current data form, and direct access to the data in the form. Thus, using the language's capabilities, one can manipulate the data being processed by the application user at runtime and even interfere with data processing or the behavior of the metaobject.

[0095] The general structure of the grammar of a metalanguage is represented by three main blocks: syntactic elements of the language, data organization, and data processing.

[0096] Syntactic elements of the language include syntactic constructs such as comments ( / / , / ** / ), literals (1 , 's', ''s”), brackets ([],(),{}), and keywords that are used when writing code in the metalanguage.

[0097] Data organization includes information about data types (any, integer, string, etc.), data storage structure, and objects. The metalanguage is strongly typed. This means that values ​​of different types cannot be used in expressions without type casting, and only values ​​of a type corresponding to the function definition can be passed as function arguments.

[0098] Data processing occurs through the use of arithmetic operations (+, ++, -, --, *, / , л), assignment operators (=, +=, -=, *=, / =), branching operators (IF, THEN, ELSE, CHOOSE, CASE, RETURN), logical operations (=, <>, >, <, >=, <=, NOT, AND, OR, ANDALSO, ORELSE), cycle operators (FOR - NEXT, DO - LOOP, CONTINUE, EXIT), error handling (THROW, TRY - CATCH, FINALLY), working with objects (CREATE, DESTROY, FUNCTION, EVENT, CALL), SQL operators (CONNECT, DISCONNECT, SELECT, INSERT, UPDATE, DELETE, COMMIT, ROLLBACK, OPEN, CLOSE, FETCH, EXECUTE), and built-in functions (built-in functions, conversion functions, string functions, numeric functions, date-time functions, array functions, miscellaneous functions).

[0099] The language supports calls to other meta-model procedures, as well as recursive calls.

[0100] The second stage of the proposed method is that the described metadata, presented as a set of meta-objects containing properties, nested objects, as well as the source code of the meta-language implementing the events and procedures of the object, is converted into code in the Erlang language, which is subsequently compiled into executable binary code for the Erlang virtual machine (BEAM), using the cross-compiler service.

[0101] Figure 9 illustrates the generalized process of compiling the source code of the system's metalanguage procedures into BEAM binaries. The compiler receives the source code of metalanguage 215 as input. Metalanguage compiler 213 analyzes it and converts it into text that fully satisfies the syntax of the Erlang language and implements the same logic. The metalanguage compiler converts syntactic constructs and function calls into the corresponding constructs and function calls of Erlang, obtaining the resulting code in Erlang 216. Next, the standard Erlang compiler 214 is used to convert the Erlang source code into a binary module in BEAM 217 format.

[0102] Next, with reference to Fig.10, the operation of the meta language cross-compiler will be described.

[0103] As mentioned above, the cross-compiler consists of 3 main modules: lexer 219, parser 220 and Erlang code generator 221.

[0104] The input to lexer 219 is the text of the source code of meta-language 218, lexer 219 compares the input stream with the grammar of the language and, as a result of the analysis, produces a list of recognized lexemes of language 222.

[0105] Lexer 219 parses the input stream of metalanguage source code based on grammar rules. Each lexeme type is described as a pattern—a regular expression. Lexer 219 distinguishes between ignorable characters (space, line terminator, comment), string and numeric literals, date and time values, identifiers, comparison operators, logical operators, arithmetic operators, parentheses, and keywords. The lexemes produced by the lexer are represented as tuples. The format of a lexeme returned by the lexer is:

[0106] {lexeme, line number, character(s)}.

[0107] If the lexer fails to recognize a lexeme during source code analysis, it returns error 225 with the source code line number, and the compilation process stops.

[0108] If all lexemes from the input stream are parsed correctly, the lexer produces a list of parsed lexemes, and the compilation process continues. The list of lexemes is passed to parser 220, which parses the lexemes syntactically, checking the lexemes and their order against the language's syntax definition.

[0109] The parser (228, Fig. 11) parses the list of lexemes 229 from the input stream, transforming them into a syntax tree 234 based on the defined grammar rules. The syntax of the metalanguage constructs is specified using a context-free grammar 235 or BNF (Backus-Naur Form) notation, in the form of grammatical inference rules (productions). In addition to checking the order of the lexemes against the grammatical inference rules (syntax), the parser performs several other important actions:

[0110] 1. maintains a table of variables 236;

[0111] 2. checks for duplicates when declaring variables 230;

[0112] 3. checks that the variable is declared before use;

[0113] 4. checks the dimensions of arrays during initialization during declaration;

[0114] 5. checks the correctness of the access to the variable and array element 231;

[0115] 6.validates calls to built-in functions, including the number of arguments 232;

[0116] 7.validates access to application metadata objects 233.

[0117] If an incorrect syntactic construct is detected during parsing, parser 220 returns error message 226 with the source code line number, and the compilation process stops. If parsing of the lexeme list is successful, the parser produces a lexeme parse tree 223, which is fed to the Erlang code generator 221.

[0118] Fig. 12 illustrates the way of representing the following arithmetic expression in the form of a syntax tree, after processing by the meta-language parser: n = (abs(-1) + 3 ) * 10 - sin(100),

[0119] The result of lexical analysis and syntactic parsing is the following syntax tree of tuples:

[0120] {2,stmt_assign, {2, var, number, local, write, n,[]}, op_eq,

[0121] {2,op_minus,

[0122] {2,op_mul,

[0123] {2,op_plus,

[0124] {2, function, number, abs, [number], [{2, unary_minus, {2, integer, 1}}]},

[0125] {2, integer, 3}},

[0126] {2, integer, 10}},

[0127] {2,function,number,sin,[number],[{2,integer,100}]}}}.

[0128] Code generator 221 performs a top-down traversal of syntax tree 223, performing semantic analysis and various additional checks, such as type conformance in expressions. For each syntactic construct, the code generator converts it into target language (Erlang) code.

[0129] Code generator 250 (Fig. 13) receives a syntax tree of tuples 251 as input and generates Erlang source code 257 as output. The code generator performs a top-down traversal 252 of the syntax tree, performing semantic checks 258 at each step. During traversal of the syntax tree, the generator compiles variable declarations 253 or compiles operators and expressions 254. Semantic checks during compilation of variable and array declarations include checking of initialization expressions. Semantic checks during compilation of operators and expressions include additional syntax checks, as well as checking of expression types and the conformity of expression operand types. When compiling function calls 285, all actual arguments passed are also checked against the function argument types in the built-in function table 259. Erlang code generation 256 is based on predefined Erlang code templates 260.

[0130] If, while traversing the syntax tree 223, the code generator 221 encounters an error (for example, a type mismatch in an expression), it issues a compilation error 227 indicating the source code line number and the process stops.

[0131] If the traversal of the syntax tree 223 is successful, then the output of the code generator 221 is the source code in the Erlang language 224, which can then be used for compilation into binary format.

[0132] The generated Erlang 261 code module is shown in Fig. 14. The entire module code consists of two large parts: preliminary declarations 262 and the main module function 263. The preliminary declarations include: module declaration 264, procedure parameter declaration 265, variable handling functions 266, array handling functions 267, and the RETURN operator processing function 268. The module declaration contains the name of the metalanguage procedure, which is translated into the Erlang module. The parameter declaration contains a list of identifiers and parameter types of the metalanguage procedure, which is translated into the Erlang module. Variable handling functions are auxiliary functions that are used to obtain or set the value of local procedure variables in a module. Array handling functions are auxiliary functions that are used to obtain or set the value of local procedure arrays in a module, including accessing array elements.The RETURN operator processing function is necessary to correctly complete the main function of the module and transfer the return value of the procedure, as well as to set the value of parameters passed by reference.

[0133] The module's main function begins with registering procedure parameters 269 in the module's variable table. This is followed by a call to the parameter initialization function 270. The initialization function 270 is responsible for setting the parameter values ​​based on the actual arguments passed to the procedure (in this case, the main function of the Erlang module) when it is called. This is followed by a section for registering local variables 271 of the procedure in the module's variable table. During registration, variables are always initialized with a value, either the one specified when declaring the variable or the default value for a specific variable type (e.g., for a string variable, this is the empty string; for a numeric variable, it is 0). This is followed by a section of main code 272, which is generated during compilation of the metalanguage procedure's source code. At the end of the module function, the RETURN operator processing function 273 is called.This function is always called, regardless of whether it was specified in the metalanguage procedure's source code or not, and even if the metalanguage procedure does not return a value. The RETURN 268 processing function sets the values ​​of input parameters passed by reference, deletes the module's variable table, and passes the procedure's return value (if any) to the calling function.

[0134] The resulting executable binary code is written to the system repository.

[0135] The third stage of the proposed method is that after launching the received application, a session is created through the session management service and a search is carried out for the executor service with the necessary metadata, the executor service is initiated with the necessary metadata, the executor process and the web interface are created.

[0136] Upon receiving a request to create a new session 274 (Fig. 15), session management service 275 attempts to allocate a worker for this session based on the parameters of the scheme identifier and the module (application) identifier according to the algorithm described below. A search is performed for a running worker service with the specified scheme (276). If there is no worker service with the required scheme, then a new worker service is instantiated (280, 282), and then the required scheme is initialized in the service (283). If a service with the required scheme is found, then a check is performed to see if the required module is loaded into the metadata cache of this service (278). If the module is loaded, then the next check determines whether the permissible limit for the number of simultaneously served users in the service has been exceeded (279). If the limit has already been reached, then a new worker service is instantiated and the scheme is initialized in the same way.If the user limit hasn't been reached, worker processes and a web interface for the session are simply created in this service, since the module is already loaded in the service. If, during the previous step, the module check revealed that it wasn't loaded, it's necessary to check whether the service's maximum cache capacity (281) has been exceeded. If this limit has been reached, a new worker service must be instantiated. If not, it's sufficient to load the module into the service's metadata cache and then create worker processes and a web interface for the session. This completes the session creation process.

[0137] The final step of the proposed method is to launch and execute the binary code from the system repository via the executor service, while the binary code is executed directly on the Erlang virtual machine.

[0138] In Fig. 16, the web interface process 287 initiates a call to the procedure for execution 288, for which it makes a request to the executor process 289. The executor process checks whether the binary module (binary code) of the procedure is loaded into the executor process (290). If the binary code is not loaded, the executor process accesses the local metadata cache 303, which checks whether the binary code of the procedure is loaded into the cache (297). If the binary code is not loaded into the cache, then the executor service makes a request to the model service 301 to load it from the system repository 300, after which the metadata cache can return the required code to the executor process. As soon as the binary code of the procedure (binary module) is loaded into the executor process, it passes it to the Erlang virtual machine (291) for execution. From this moment on, the execution of the binary module is entirely controlled by the Erlang OTP platform 292 and the code of the binary module 299.However, the code of the binary module may contain calls to functions of the system kernel 293 or calls to built-in functions of the meta-language 295, which are processed by the main executor of the service 294. Fig. 17 illustrates the general diagram of the computing device (1700) that provides the data processing necessary for the implementation of the claimed solution.

[0139] In general, the device (1700) contains components such as: one or more processors (1701), at least one memory (1702), data storage means (1703), input / output interfaces (1704), I / O means (1705), network interaction means (1706).

[0140] The processor (1701) of the device performs the basic computing operations necessary for the operation of the device (1700) or the functionality of one or more of its components. The processor (1701) executes the necessary machine-readable instructions contained in the RAM (1702).

[0141] Memory (1702) is usually in the form of RAM and contains the necessary software logic to provide the required functionality.

[0142] The data storage device (1703) can be implemented in the form of HDD, SSD disks, RAID array, network storage, flash memory, optical storage devices (CD, DVD, MD, Blue-Ray disks), etc. The device (1703) allows for long-term storage of various types of information, for example, the above-mentioned files with user data sets, databases containing records of time intervals measured for each user, user identifiers, etc.

[0143] Interfaces (1704) are standard means for connecting and working with the server part, for example, USB, RS232, RJ45, LPT, COM, HDMI, PS / 2, Lightning, FireWire, etc.

[0144] The choice of interfaces (1704) depends on the specific design of the device (N00), which can be a personal computer, mainframe, server cluster, thin client, smartphone, laptop, etc.

[0145] In any embodiment of the system implementing the described method, a keyboard must be used as the I / O data means (1705). The keyboard hardware may be of any known type: it could be a built-in keyboard used on a laptop or netbook, or a separate device connected to a desktop computer, server, or other computing device. The connection may be either wired, in which the keyboard's connecting cable is connected to a PS / 2 or USB port located on the desktop computer's system unit, or wireless, in which the keyboard exchanges data via a wireless communication channel, such as a radio channel, with a base station, which, in turn, is directly connected to the system unit, such as one of the USB ports.In addition to the keyboard, the I / O data means can also include: a joystick, display (touch display), projector, touchpad, mouse, trackball, light pen, speakers, microphone, etc.

[0146] Network interaction means (1706) are selected from a device that provides network reception and transmission of data, for example, an Ethernet card, a WLAN / Wi-Fi module, a Bluetooth module, a BLE module, an NFC module, an IrDa module, an RFID module, a GSM modem, etc. With the help of means (1705), data exchange is organized via a wired or wireless data transmission channel, for example, a WAN, PAN, LAN, Intranet, Internet, WLAN, WMAN or GSM.

[0147] The components of the device (1700) are connected via a common data bus (1710).

[0148] In these application materials, a preferred disclosure of the implementation of the claimed technical solution was presented, which should not be used as limiting other, particular embodiments of its implementation that do not go beyond the scope of the requested scope of legal protection and are obvious to specialists in the relevant field of technology.

Claims

Formula 1. A cloud system for developing and executing web-based software applications, consisting of microservices interacting with each other via a software interface, wherein the microservices are: a metamodel service including a metadata repository and a metamodel interface service, wherein the metamodel service is configured to be supplemented by at least one service according to the "master-slave" scheme for distributing the load upon requests; a metadata management service containing a web interface for working with metadata, interacting with the metamodel service to obtain and modify metadata, configured to provide convenient means for working with metadata constituting the configuration of application modules; implementation of a visual editor for constructing application interface forms; provision of a visual editor for the source code of the metalanguage;implementation of mechanisms for working with versions of metadata described in a metalanguage, provision of tools for translating metadata into other languages ​​for localization of applications; a metalanguage cross-compiler service, configured to translate the source code of a metalanguage representing a description of the business logic of an application object into code in the Erlang language, compiling the resulting code in the Erlang language into binary code for the Erlang virtual machine, which can be loaded and executed by the application execution service; a session management service, configured to authorize users, create a session, search for an executor service with the necessary metadata, initiate the executor service with the necessary metadata, create an executor process and a web interface, supplement with at least one service according to the "master - slave" scheme for load balancing of requests;an application executor service capable of loading and executing applications stored in a system repository in the form of a set of metaobjects of complex structure, including a description of business logic in the form of compiled binary code, within a specific user work session, supplemented by at least one service for distributing the load upon requests; an external data interface service capable of working with external databases and web services; an external API service of the system.

2. The system according to claim 1, characterized in that the meta-language cross-compiler contains a lexer, a parser, and an Erlang code generator.

3. The system according to claim 1, characterized in that the application executor service contains an executor core, a metadata cache, a web interface, and execution processes dynamically created upon request.

4. The system according to paragraph 1, characterized in that the interface service with external data is designed with the ability to work with external databases through connectors that take into account the specifics of the corresponding data source.

5. The system according to paragraph 1, characterized in that the interface service with external data is designed with the ability to provide a unified API for working with data or web services.

6. A method for developing and executing web software applications, comprising the steps of: describing application objects in the form of metadata stored in a metadata repository, through a metadata management service and a metamodel service, using a compiler-type metalanguage, wherein the description of application objects is based on the description of metamodel classes;the described metadata, presented as a set of meta-objects containing properties, nested objects, and the source code of the meta-language implementing the events and procedures of the object, are converted into code in the Erlang language, while comparing the source code of the meta-language with the grammar of the language and producing a list of lexemes of the recognized language, performing syntactic parsing of the obtained list of lexemes, obtaining a syntax tree for parsing the lexemes, performing semantic analysis of the syntax tree for parsing the lexemes, obtaining the converted source code of the meta-language in the Erlang language, compiling the obtained code in the Erlang language into executable binary code for the Erlang virtual machine; writing the obtained executable binary code to the system repository;After launching the resulting application, a session is created via the session management service and a search is performed for the executor service with the necessary metadata, the executor service is initiated with the necessary metadata, the executor process and the web interface are created; the binary code from the system repository is launched and executed via the executor service, while the binary code is executed directly on the Erlang virtual machine.

7. The method according to claim 6, characterized in that the meta-model contains classes, subclasses, attributes, behavior, types and sub-types.

8. The method according to paragraph 6, characterized in that the description of classes of objects includes the addition of new classes and the inheritance of existing classes.