WO2022098253A1 - Система и способ создания и исполнения высоко масштабируемых облачных приложений - Google Patents

Система и способ создания и исполнения высоко масштабируемых облачных приложений Download PDF

Info

Publication number
WO2022098253A1
WO2022098253A1 PCT/RU2020/000595 RU2020000595W WO2022098253A1 WO 2022098253 A1 WO2022098253 A1 WO 2022098253A1 RU 2020000595 W RU2020000595 W RU 2020000595W WO 2022098253 A1 WO2022098253 A1 WO 2022098253A1
Authority
WO
WIPO (PCT)
Prior art keywords
meta
service
pos
data
language
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/RU2020/000595
Other languages
English (en)
French (fr)
Inventor
Дмитрий Алексеевич ГОЛУБЕВ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
"craft Systems" LLC
Original Assignee
"craft Systems" LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from RU2020136739A external-priority patent/RU2020136739A/ru
Application filed by "craft Systems" LLC filed Critical "craft Systems" LLC
Priority to CN202080107056.0A priority Critical patent/CN116391172B/zh
Priority to EP20960940.3A priority patent/EP4242830A4/en
Publication of WO2022098253A1 publication Critical patent/WO2022098253A1/ru
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/35—Creation or generation of source code model driven

Definitions

  • This technical solution relates to the development and execution of software web applications. More specifically, the invention relates to methods for creating highly scalable cloud applications developed using software platforms.
  • the preferred embodiment provides a graphic design tool that models an application using the Unified Model Language (UML), validates the UML model, and automatically generates a deployable application.
  • UML Unified Model Language
  • the preferred embodiment also provides a framework of libraries from which the target application can be built.
  • solutions known from the prior art have a number of disadvantages, namely the use of an XML format for storing descriptions of models, which can cause additional difficulties in the sematic analysis of relationships with other models and elements, since they can be stored in separate XML fragments in a relational database.
  • the solutions known from the prior art have poor scalability.
  • solutions known from the prior art for developing and executing applications require a certain ready-made IT infrastructure for the client to operate the generated application, which is not suitable for use in SaaS mode. (Software As A Service), but is more suitable for development and use in the “onpremises” mode (on the client’s territory).
  • the technical task is to create a system and method for the rapid development of highly scalable cloud applications that can be used according to the SaaS model.
  • a cloud system and a method for developing and executing software web applications were created, which are described in independent claims. Additional embodiments of the present invention are presented in dependent claims.
  • the technical result consists in increasing productivity and horizontal scaling in the development and execution of applications, as well as in simplifying the description of the business logic of applications through the use of a meta-language. Additionally, the technical result consists in the implementation of the destination.
  • micro-services consisting of micro-services interacting with each other through a software interface
  • 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 augmented with at least one master-slave service to distribute load on requests; a meta data management service comprising a web interface for working with meta data, interacting with the meta model service for getting 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 application interface forms; providing a visual editor of the source code of the meta-language; implementation of mechanisms for working with versions of meta-data described in the meta-language, providing tools for translating meta-data into other languages for localizing applications; meta-language cross-compiler service capable of translating the meta-language source code representing the description of the business logic of the application object into Erlang code, compiling the resulting Erlang code into binary code
  • the metalanguage cross-compiler contains a lexer, a parser, and an Erlang code generator.
  • the application execution service contains the executor core, metadata cache, web interface, and execution processes dynamically created on demand.
  • an interface service with external data is made with the ability to work with external databases through connectors that take into account the specifics of the corresponding data source.
  • an external data interface service is configured to provide a unified API for working with data or web services.
  • the claimed result is also achieved through the implementation of a method for developing and executing software web applications, which contains the steps at which: describe application objects in the form of meta-data stored in the meta-data repository through the meta-data management service and the meta-model service, using the meta-language of the compiling type, while the description of application objects is based on the description of the classes of the meta-model; the described meta-data, represented as a set of meta-objects containing properties, nested objects, as well as the source code of the meta-language that implements the events and procedures of the object, is converted into code in the Erlang language, when At the same time, the source code of the meta-language is compared with the grammar of the language and a list of lexemes of the recognized language is given out; the resulting list of lexemes is parsed; a parse tree of lexemes is obtained; compiling the resulting Erlang code into an executable binary code for the Erlang virtual machine; write the resulting binary code to the system repository; after launching the
  • the meta-model contains classes, sub-classes, attributes, behaviors, types, and sub-types.
  • the description of object classes includes the addition of new classes and the inheritance of existing classes.
  • 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.
  • Fig. 2 illustrates the architecture of the proposed cloud system.
  • Pos. 110 system user, pos. 111 - metadata management service, pos. 112 - Designer web interface, pos. 113 - cross compiler service, pos. 114 - balancer, pos. 115 - session management service, pos. 116 - main session manager, pos. 117- session table main, pos. 118 - additional session manager, pos. 119 - additional session table, pos. 120 - main meta-model service, pos. 121 - additional meta-model service, pos. 122 - main meta-model, pos. 123 - additional metamodel, pos. 124 - the main database of the model, pos.
  • pos. 126 - data provider service pos. 127 - data provider, pos. 128 - connector to the database
  • pos. 129 - external database pos. 130 - web provider service, pos. 131 - web provider, pos. 132 - web connector, pos. 133 - external web service, pos. 134 - contractor's service, pos. 135 - the core of the performer, pos. 136 - meta-data cache, pos. 137 - the process of the web interface of the performer, pos. 138 - executor process.
  • Fig. 3 illustrates an executor service diagram.
  • Pos. 139 - contractor's service pos. 140 - the core of the performer, pos. 141 - main supervisor, pos. 142 - external API, pos. 143 - the main performer, pos. 144- supervisor of performers, pos. 145 - web interface supervisor, pos. 146 - meta-data cache, pos. 147 - the process of the performer, pos. 148 - web interface process.
  • Fig. 4 illustrates a generalized metadata structure.
  • Fig. 5 illustrates the structure of the meta model class description.
  • Fig. 6 illustrates the structure of the meta data object description.
  • Fig. 7 illustrates a metadata object versioning scheme.
  • Pos. 191 - meta-object, pos. 192 - immutable attributes of the object, pos. 193 - version 1 of the object data, pos. 194 - version 2 of this object, pos. 195 - object property value version 1, pos. 196 - implementation of the version 1 object event, pos. 197 - implementation of the version 1 object procedure, pos. 198 - property value of the version 2 object, pos. 199 - implementation of the event of the object version 2, pos. 200 is an implementation of the version 2 object procedure.
  • Fig. 8 illustrates a meta-information demarcation scheme.
  • Pos. 201 - account pos. 202 - scheme 1, pos. 203 - scheme 2, pos. 204 - module, pos. 205 - object, pos. 206 - links between objects, pos. 207 - meta-model, pos. 208 - description of data, pos. 209 - sub-accounts, pos. 210 - roles, pos. 211 - users, pos. 212 - privileges.
  • Fig. 9 illustrates the process of compiling the System Meta-Language source code.
  • Fig. 10 illustrates the algorithm of the meta-language compiler.
  • Pos. 218 meta-language source code
  • pos. 219 lexer
  • pos. 220 parser
  • pos. 221 Erlang code generator
  • pos. 222 list of lexemes
  • pos. 223 syntax tree
  • pos. 224 Erlang source code
  • pos. 225 lexical analysis error
  • pos. 226 parse error
  • pos. 227 compilation error.
  • Fig. 11 illustrates the operation of the meta-language parser.
  • 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 is the number 3.
  • Fig. 13 illustrates the operation of the Erlang code generator.
  • Fig. 14 illustrates the structure of an Erlang module. Pos. 261 - Erlang module, pos. 262
  • Fig. 15 illustrates the user session creation algorithm.
  • Pos. 274 - request to create a session pos. 275 - session manager, pos. 276 - request for the selection of the performer, pos. 277 - check for the presence of an executor with a scheme, pos. 278 - check for the presence of an executor with a module, pos. 279 - check for reaching the maximum limit for the number of users, pos. 281 - check for reaching the maximum cache capacity limit, pos. 280 - instantiation of a new executor service, pos. 282- contractor's service, pos. 283 - initialization of the circuit, pos. 284 - module loading from metadata, pos. 285 - creating an executor process, pos. 286 - creating a web interface process.
  • Fig. 16 illustrates the flow of the business logic procedure.
  • Pos. 287 - web interface process pos. 288 - initiation of the procedure, pos. 289 - the process of the performer, pos. 290 - checking the procedure code in the process, pos. 291 - transfer of the procedure for execution, pos. 292 - Erlang OTP, pos. 293 - calling the functions of the system core, pos. 294 - the main performer, pos. 295 - calling the built-in functions of the meta-language, pos. 296 - loading the code into the meta-data cache, pos. 297 - checking the procedure code in the cache, pos. 298 - loading code from the cache into the executor process, pos. 299 - binary code of the procedure, pos. 300 - system repository, pos. 301 - model service, pos. 302 - binary code of the procedure, pos. 303 - meta-data cache.
  • Fig. 17 illustrates a general diagram of a computing device.
  • the proposed method and cloud system for developing and executing software web applications are based on the presentation of software applications in the form of metamodels stored in the system repository and executed on a computing device.
  • a cloud system for developing and executing software web applications consists of micro-services that interact with each other through the API.
  • the proposed cloud system provides high performance and horizontal scalability with a large number of users working simultaneously.
  • Figure 1 illustrates the generalized architecture of the proposed system for developing and executing software web applications.
  • the architecture involves the division of 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 a relational database management system (DBMS) 104
  • the software core (platform) 101 consists of two large subsystems: an application development platform 102 and an application execution platform 103.
  • the application development platform 102 is responsible for providing tools to the developer to describe the application model in a platform format. Examples of such development tools: system metadata navigator, meta-object attribute editor, object interface form editor, business logic procedure editor.
  • the application execution platform 103 provides mechanisms and resources for launching applications as described in the metadata.
  • the runtime framework uses the application meta information stored in the metadata repository to load and execute applications, including generating the application interface, user interaction, and executing business logic procedures.
  • Description of applications in meta-information 106 consists of three main parts: description of the interface of business objects 107, description of the business logic of objects 108, description of data 109.
  • the interface of business objects of applications is described by a set of attributes and visual forms of objects.
  • the business logic of objects is described using the built-in meta-language of the system, which is compiled for execution into binary modules.
  • the application data description is defined by the data provider and is described a set of data sources, which may include various DBMS or web services.
  • FIG. 2 illustrates the detailed architecture of the proposed system.
  • the basis for the operation of the proposed system is the meta-model service 120, which provides storage and access to meta-data in the system repository.
  • the service consists of a relational database 124, which includes the system repository, and the actual meta-model 122, which provides all operations for working with the system repository and provides an external API to the repository, capable of processing many parallel asynchronous requests.
  • Using the API allows you to abstract from the data structure inside the repository (in a relational database) and provide independence from the way metadata is stored.
  • the main functions of the meta-model service for working with the system repository are: obtaining meta-information on arbitrary requests to the repository; entering new meta-information; changing existing meta-information; removal of meta information.
  • the meta-model ensures the integrity of meta-data in any operations with meta-information.
  • the system provides for building a meta-model configuration according to the “master - slave” scheme, in which the main service (“master”) is supplemented by several “slave” and between all of them can distribute the load on queries.
  • Figure 1 shows a "slave" meta-model service 121 that also has its own relational database 125 that contains a copy of the system repository.
  • the databases of the main service and the "slave” service are synchronized (replicated) automatically, while the operations of changing meta-information are possible only in the main service, and requests to read meta-information are possible in all services.
  • the metadata management service 111 is designed to provide the user of the system with all the necessary resources and tools for developing applications.
  • the main service is the web interface of the Application Designer, which provides a convenient interface for working with meta-data for the developer.
  • the Designer web interface interacts directly with the meta model service through an external API to get meta data and to make changes to the meta data.
  • Web Interface Designer also implements a visual editor for building interface forms of objects; source code editor for business logic procedures and events.
  • the service implements a mechanism for working with versions of metadata objects, and it is also possible to translate business object metadata into other languages for application localization.
  • the Designer's web interface also interacts with the cross-compiler service 113 to translate the source code of the meta-language procedures into executable binary code.
  • the metadata management service ensures the parallel operation of a large number of users at the same time, allocating a separate process for each user session.
  • meta-data management service also implies the possibility of horizontal scaling by launching additional services between which sessions will be distributed using the load balancer 114.
  • the cross-compiler service 113 is used to translate the source code of procedures and events of the business logic of applications (meta-language) into executable binary modules that can be loaded and executed by the application executor service and is part of the application development system together with the metadata management service and is used only from the Designer's web interface.
  • the cross compiler service provides an external API for calling its methods and can process a large number of asynchronous requests at the same time. If it is necessary to scale out to serve even more requests, it is possible to run several compiler services, the requests to which are distributed automatically using the load balancer 114.
  • the cross compiler service 113 contains a lexer, a parser, and an Erlang code generator.
  • the input to the compiler service is the source text of the system's meta-language procedures, as well as additional information necessary for compilation, for example: a module, an object.
  • the compiler provides full parsing and parsing of the input language constructs and issuing compilation errors.
  • the service interacts with the meta model service 120 to obtain additional meta information about the meta data objects that are used in the source code of the procedure, for example, to validate the list and types of arguments of the called application procedure or object.
  • the meta-model service is not available to request from the compiler, the compilation process cannot be completed.
  • the compiler produces a binary code of the compiled procedure compatible with the Erlang virtual machine, which is written by the metadata management service to the system repository.
  • the session management service 115 contains a session manager 116 and a local session table 117.
  • the main function of the session manager is to authenticate a system user and authorize him to use system resources. Authentication and authorization is performed for any user who will use the application development or execution subsystem. That is, before the user can start, for example, the Designer's web interface, the session management service must identify the user by his credentials (for example, using a login and password). For authentication, the session management service makes a request to the meta-model service, where all user accounts are stored. If the authentication is successful, the service should authorize the user to launch the Designer web interface with the parameters requested by the user, e.g. business account, metadata schema.
  • the service creates a session for the user and passes the session to the Designer's web interface, which then processes all incoming requests. If a user launches a business application from the system repository, the session management service, after creating a session, allocates the resources of the application executor and transfers the session to the executor.
  • the process of resource allocation of an executor consists of the following steps: searching for an executor service with the necessary metadata, initiating an additional executor service if necessary, initiating an executor service with the necessary metadata, creating an executor process and a Designer web interface. After a session is created, information about it is written to the session manager's local session table.
  • the session information is removed from the service session table, and the selected processes of the executor and the Designer's web interface stop working.
  • the system provides for building a service configuration according to the "master - slave” scheme, in which the main service (“master”) is supplemented by several "slave” and between all of them it is possible load balancing for requests.
  • the diagram shows a "slave" session manager 118, which also has its own local session table 119, which contains a copy of the master session manager's session table.
  • the session tables of the "master” and "slave” session manager are synchronized automatically.
  • the load balancer 114 serves to automatically distribute the load between the session management services, as well as between the meta model services.
  • the executor service 134 is the basis of the application execution subsystem and provides the launch and execution of business applications, the description of which is stored in the system repository.
  • 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.
  • the executor core (140 FIG. 3) consists of a main supervisor 141 (FIG. 3), an external AP1 module 142, a main executor 143 along with built-in meta-language functions, an executor process supervisor 144, a web interface process supervisor 145.
  • the external API 142 provides a set methods for managing and using the execution service, including methods for initializing the service, loading metadata, 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, and also contains the implementation of the built-in functions of the system meta-language.
  • the worker supervisor 144 is responsible for instantiating and managing worker processes 147.
  • the web interface supervisor 145 is responsible for instantiating and managing web interface processes 148.
  • the metadata cache 146 (FIG. 3) is a program-managed structure in the memory of the execution service process, designed to locally store the meta-information necessary for starting and executing business applications by the execution service.
  • the executor core 140 implements the external API for the service and is also responsible for interacting with the meta model service and the session management service. Also, the executor core manages the internal processes of the service.
  • the meta data cache 146 (FIG. 3) stores meta information associated with the meta data schema (eg, descriptions of providers and data sources) as well as complete information about the business objects of the applications (modules) contained in the schema.
  • a cache can store meta information belonging to only one meta data schema. The use of a local cache during the work of the executor eliminates the need to access meta-data from the meta-model service, which significantly increases performance and reduces the intensity of communications within the system.
  • the web interface process 137 (FIG. 2) and the executor process 138 are designed to serve a single user session that works with a business application on the system.
  • the executor process 147 (FIG. 3) is spawned by the executor supervisor 144 in response to a request to the executor service from the session management service.
  • the web interface process 148 is created by the web interface supervisor 145 when a new user session is created while the business application is running. For each user session, a separate pair of execution processes and a web interface is always created, due to which complete isolation of the execution of business applications for different sessions is achieved.
  • the web interface service 148 interacts with its partner 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 interacts closely with the meta-data cache, for example, when information about a meta-object needs to be retrieved during the execution of a business procedure. At the same time, different executor processes can simultaneously use the same data set in the executor service cache if these are sessions of the same application. Thus, a single executor service can serve a large number of user sessions if they belong to the same set of metadata schema applications.
  • the executor service is completely autonomous and, after initialization, is practically independent of other system services, which allows for almost unlimited horizontal scaling of the application execution system to serve a very large number of simultaneous user sessions. Scaling is achieved through auto-instance of additional worker services required to serve new users, depending on the current system load.
  • the services of external data providers 126 ( Figure 2) and web services 130 are intended.
  • the basis of the service provider 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 provides work with them at a low level data transfer protocol or service API, performing the transfer of data or commands from / to a data source or web service.
  • a data or web service provider provides a unified API for working with data or services for business applications of the system, abstracting from the specifics of specific data sources or web services.
  • Web services data providers are configured using the metadata management service, the provider configuration is stored in metadata in the system repository and can be adjusted by the application developer at any time. Providers interact with the processes of the application executor service executor, accepting commands from them to receive or change data, or transmit the received data.
  • the first stage of the proposed method is the description of arbitrary business objects of the application in metadata stored in the system repository (metamodel) in a relational database.
  • the description is carried out by means of a meta-data management service and a meta-model service using a procedural metalanguage of a compiling type, with support for objects to implement complex application business logic, while the description of application objects is based on the description of meta-model classes.
  • the repository data structure is designed to provide maximum flexibility and no practical restrictions on how business objects can be described, including their set of properties (attributes), behaviors (methods and events), structure, and relationships.
  • a model abstraction level has been introduced in the form of object classes (proto-objects), which define all the structures and data necessary to describe real business objects.
  • Fig. 4 describes the generalized structure of the metadata repository of the proposed system.
  • the main parts of a repository are: meta-model 149, meta-data 150 and configuration 151 .
  • the meta-model 149 is used to describe the composition and structure of metadata proto-objects. This approach provides maximum flexibility and the absence of practical restrictions on the possible ways of describing business objects, allowing you to expand the basic set of meta-model classes if necessary.
  • Class 152 description includes includes a set of attributes 153 and their types 155 (as well as sub-types 156, if necessary); behavior 154 - a set of methods and events of the class; class structure - if the class is complex and contains nested classes.
  • Meta data 150 contains descriptions of business objects 158 that are part of the applications (modules) 157.
  • the description of each object 158 is built on the basis of the description of its class 152 in the meta model 150.
  • the set of properties 159 and their object types is uniquely determined by the set of object class attributes.
  • Object property values can be either scalar values of simple types or references to other objects or their properties.
  • the set of procedures of the Business Logic 160 object is determined based on the behavior (methods and events) described in the class.
  • Object data can be versioned, that is, different versions of object property values created at different points in time can be saved.
  • Configuration 151 contains the structures necessary to organize all meta-information and provide access to it by system users. All meta-information and, in particular, the configuration is divided into accounts 162. An account is a grouping of information based on access and combines roles, users and their privileges, and also includes schemas with all meta-data inside. Scheme 163 is another level of separation of metadata on a semantic basis. The schema determines which meta-model is used within the schema and, accordingly, how the meta-objects in the schema are described.
  • Classes can be one of two kinds: main class 167 or sub class 170.
  • the main class can be used to describe business objects in 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 the main classes.
  • Any class is described by a set of attributes 171 , each of which has a specific type 172 and possibly a sub-type 173.
  • An attribute's value type can be a simple scalar type (for example, numeric, text) or be a reference to: an element of a list of values 174, another basic class 168 or an attribute of the main class.
  • a set of attributes uniquely defines which properties of a business object of a given class should be described and stored in the metadata.
  • a class method is a named predefined procedure that defines the operations possible on an object of a given class.
  • Example of class methods create a new element, write data, delete element.
  • the implementation of the method is assigned to the class itself, that is, the 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 the business object of this class, that is, the implementation of the event procedure is done in the business object, and not in the class.
  • Object event procedures are called for execution as a result of user interaction with the application when certain conditions occur (for example, double-clicking the left mouse button).
  • a class structure is used, which is a hierarchical set of links to sub-classes that make up a given class. Hierarchy here means that each sub-class used in the structure can in turn also have nested sub-classes. In the class structure, you cannot use classes of the main type, only sub-classes are allowed.
  • the class structure determines what components the business object consists of and how the representation of the object in the metadata will be built. An example is the main class "Document”, which may include a sub-class "Form”. 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.
  • Extending the meta-model is possible in two ways: adding new classes or inheriting from an existing class. For a newly created class, it is necessary to define a set of attributes, events and methods, as well as a structure. As soon as a new class is declared, it becomes possible to create business objects of this class. Inheritance is used when a new class largely replicates an already existing class with minor changes. When inheriting, the child class receives all the attributes, methods and events, as well as the structure of the parent class, while it is possible to add its own attributes, methods, events and supplement the class structure. Redefining attributes and methods, as well as the structure of the parent class, is prohibited in the child class.
  • Fig. 6 illustrates a method for describing a meta data meta object based on a meta model class definition.
  • class 171 has two attributes (179) defined: attribute A1 (184) and attribute A2.
  • attribute A1 184
  • attribute A2 182
  • the value type for example, for the property of the object A1 (187) must correspond to the type and sub-type of the attribute of the class A1 (184).
  • the meta-object it is possible (but not required) to define the implementation of the procedures for class events (180).
  • the signatures of the object's procedures must fully correspond to the description of events in the class.
  • the implementation of the event of the object E1 (189) must correspond to the description of the event of the class E1 (185).
  • the implementation of object event procedures occurs through the use of an object of the sub-class "object event" 182 defined in the class structure.
  • class 181 methods must be implemented directly in the class.
  • the class has two methods 186 defined: method 1 and method 2.
  • Fig. 7 describes the meta-object data versioning scheme. At the same time, all data of the meta-object 191 is divided into a non-versioned and a versioned part.
  • the non-versioned part of an object contains immutable attributes 192 such as class, parent object reference, and is used to implement object references and establish relationships between objects.
  • the object data which can change as a result of the development (improvement) of the object, is moved to the versioned part (193, 194).
  • the versioned part contains: property values of object 195, implementation of object events 196, implementation of object procedures 197.
  • An object version is a set of versioned object data stored in the metadata repository with a unique identifier (number) of the version.
  • Each version of a meta object can belong to a particular branch. Within one branch, all versions of an object are saved sequentially, but different versions of objects can be saved in parallel in different branches. Only one version within a single branch can be up-to-date (this is the latest version in the branch). In addition to the sign of the current version, versions can be marked with the sign of a “working” version.
  • a production version is a stable and tested version of an object that can be used for execution in an application. You can install only one working version of an object (it does not have to be the same as the current one).
  • the proposed cloud system and method can operate in SaaS mode.
  • Fig. 8 explains how to differentiate meta-information in the system.
  • An account here refers to a non-personal account of a registered business user of the system. Within the main account, you can create sub-accounts 209 that are subordinate to the main account.
  • the account must contain at least one personal user profile 211 , and the number of user profiles is not limited. 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 in isolation within an account, that is, they are independent of users, roles and privileges of another account.
  • the next level of delimitation of meta-information is the entity designated as “schema” (202, 203).
  • a schema combines related meta-model and meta-data information, such as descriptions of classes, data, and meta-objects. With this approach, each schema contains its own meta-model (a description of classes or proto-objects), which ensures independence from other schemas even within the same account and allows you to safely extend or change the meta-model without the risk of unpredictably changing the description of business objects of another schema.
  • the scheme serves also as a “container” of applications developed and executed on the platform and referred to by the term “module” 204.
  • An application (module) is a collection of business objects 205, each of which can belong to only one module.
  • the mechanism of communication 206 between modules is activated by creating links to objects.
  • Links can only be created between modules within the same schema.
  • the schema also contains a description of the sources of external data 208 that are needed to run the applications. Data sources can be used by any application (module) within the same schema.
  • the modules are grouped according to the schemes according to their functional characteristics (related business objects) and according to the principle of using common data.
  • the general structure of the grammar of a meta-language is represented by three main blocks: syntactic elements of the language, data organization and data processing.
  • Syntactic elements of the language include syntactic constructs such as comments (//, /**/), literals (1 , 's', ''s”), brackets ([],(), ⁇ ) , and keywords , which are used when writing code in the meta language.
  • Data organization includes information about data types (any, integer, string, etc.), data storage structure, and objects.
  • the meta language is a strongly typed language. This means that values of different types cannot be used in expressions without type casting, and only values of the type corresponding to the function definition can be passed as function arguments.
  • the language supports calls to other meta-model procedures as well as recursive calls.
  • the second stage of the proposed method consists in the fact 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 that implements the events and procedures of the object, is converted into Erlang code, which is subsequently compiled into an executable binary code for the Erlang Virtual Machine (BEAM), via the cross compiler service.
  • BEAM Erlang Virtual Machine
  • the compiler receives the source code of the meta-language 215.
  • the meta-language compiler 213 parses it and converts it into text that fully satisfies the syntax of the Erlang language and implements the same logic.
  • the meta-language compiler converts the syntax constructs and function calls into the corresponding Erlang constructs and function calls, producing the resulting Erlang 216 language code.
  • the standard Erlang 214 language compiler is then used to convert the Erlang source code into a binary module in BEAM 217 format.
  • the cross compiler consists of 3 main modules: the lexer 219, the parser 220 and the Erlang code generator 221 .
  • the input to the lexer 219 is the text of the source code of the meta-language 218, the lexer 219 checks the input stream with the grammar of the language and, as a result of the analysis, produces a list of recognized lexemes of the language 222.
  • the lexer 219 parses the meta-language source code input stream based on the grammar rules. Each type of lexeme is described as a pattern - a regular expression. Lexer 219 distinguishes between ignored characters (space, line terminator, comment), string and numeric literals, date and time values, identifiers, comparison operators, logical operators, arithmetic operators, brackets, keywords. The tokens that a lexer produces are represented as tuples. The format of the token returned by the lexer:
  • the lexer If during the analysis of the source code the lexer cannot recognize the token, it generates an error 225 indicating the line number of the source code and the compilation process stops.
  • the lexer If all tokens from the input stream are parsed correctly, then the lexer returns a list of parsed tokens and the compilation process continues.
  • the list of tokens is input to the parser 220, and it parses the tokens by checking the tokens and their order against the syntax definition of the language.
  • the parser (228, FIG. 11) parses the list of tokens 229 from the input stream, converting them into a syntax tree 234, based on the definition of grammar rules.
  • the syntax of meta-language constructs is specified using a context-free grammar 235 or BNF (Backus-Naur Form) notation, in the form of rules for grammatical inference (productions).
  • BNF Backus-Naur Form
  • the parser performs several more important actions:
  • the parser 220 issues an error message 226 indicating the line number of the source code and the compilation process stops. If parsing of the list of tokens was successful, then the parser produces a parse tree of tokens 223, which is fed to the Erlang code generator 221.
  • the code generator 221 performs a downward traversal of the syntax tree 223, performing semantic analysis and various additional checks such as type matching in expressions. For each syntactic construct, the code generator converts it into the code of the target language (Erlang).
  • Code generator 250 takes a tuple syntax tree 251 as input and generates Erlang source code 257 as output.
  • the code generator descends 252 the syntax tree, performing semantic checks 258 at each step.
  • the generator performs compilation of variable declarations 253 or compilation of statements and expressions 254.
  • Semantic checks in the compilation of variable and array declarations include checking initialization expressions.
  • Semantic checks when compiling operators and expressions include additional syntax checks, as well as checking the types of expressions, matching the types of expression operands.
  • function calls are compiled 285, all actual arguments passed are also checked against the function's argument types against the built-in function table 259.
  • Erlang 256 code is generated based on predefined Erlang 260 code templates.
  • the code generator 221 detects an error (for example, a type mismatch in an expression), it issues a compilation error 227 with the line number of the source code and the process stops.
  • an error for example, a type mismatch in an expression
  • the source code in the Erlang 224 language is generated at the output of the code generator 221, which can then be used to compile into a binary format.
  • the generated code module in Erlang 261 is shown in Fig.14.
  • the entire module code consists of two large parts: preliminary declarations 262 and the main function of the module 263.
  • the preliminary declarations include: module declaration 264, declaration of procedure parameters 265, functions for working with variables 266, functions for working with arrays 267, operator processing function RETURN 268.
  • a module declaration contains the name of a meta-language procedure that is translated into an Erlang module.
  • a parameter declaration contains a list of identifiers and types of meta-language procedure parameters that are translated into an Erlang module.
  • Variable functions are helper functions that get or set the value of local variables of a procedure in a module.
  • Array functions are helper functions that get or set the value of local arrays of a procedure in a module, including accessing array elements.
  • the function for processing the RETURN statement is necessary for the correct completion of the main function of the module and the transfer of the return value of the procedure, as well as for setting the value of parameters passed by reference.
  • the main function of a module begins with the registration of 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 according to the actual arguments passed to the procedure (in this case, the main function of the Erlang module) when it is called.
  • the main code section 272 which is generated when the source code of the meta-language procedure is compiled.
  • the function for processing the operator RETURN 273 is called. This function is always called, regardless of whether this function was specified in the source code of the meta-language procedure or not, and even if the meta-language procedure does not return a value.
  • the RETURN 268 processing function sets the values of the input parameters passed by reference, removes the module's variable table, and passes the return value of the procedure (if any) to the calling function.
  • the resulting executable binary code is written to the system repository.
  • the third stage of the proposed method consists in the fact that after launching the received application, a session is created using the session management service and searches for the executor service with the necessary meta-data, initiating the executor service with the necessary meta-data, creating the executor process and the web interface.
  • the session management service 275 Upon receiving a request to create a new session 274 (FIG. 15), the session management service 275 tries to allocate an executor for this session, based on the parameters schema identifier and module (application) identifier according to the algorithm described below.
  • a running worker service with the specified schema is searched (276). If there is no executor service with the desired schema, then a new executor service is instantiated (280, 282), and then the desired schema is initialized in the service (283). If a service with the required schema is found, then it is checked whether the required module is loaded into the metadata cache in this service (278). If the module is loaded, then the next check determines whether the allowed limit on the number of simultaneously served users in the service (279) has been exceeded.
  • a new worker service is instantiated and the schema is initialized. If the limit on the number of users is not reached, then the processes of the executor and the web interface for the session are simply created in this service, since the module in the service is already loaded. If, at the previous step, when checking the module, it turned out that it was not loaded, then it is necessary to check if the service has exceeded the maximum allowable cache capacity limit (281). If the limit is reached, then a new worker service must be instantiated. If not, then it is enough to load the module into the service metadata cache and then create the executor processes and the web interface for the session. This completes the session creation process.
  • the final step of the proposed method consists in launching and executing the binary code from the system repository through the executor service, while the binary code is executed directly on the Erlang virtual machine.
  • the web interface process 287 is the initiator of the procedure call 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 has been loaded into the executor process (290). If the binary is not loaded, the executor process consults the local metadata cache 303, which checks if the procedure binary 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 301 service 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 for execution (291).
  • Fig.17 illustrates the General scheme of the computing device (1700), providing data processing necessary to implement the claimed solution.
  • the device (1700) contains components such as: one or more processors (1701), at least one memory (1702), storage media (1703), input/output interfaces (1704), I/O ( 1705), networking tools (1706).
  • 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 main memory (1702).
  • the memory (1702) is typically in the form of RAM and contains the necessary software logic to provide the desired functionality.
  • the data storage means (1703) can be in the form of HDD, SSD disks, raid array, network storage, flash memory, optical information storage devices (CD, DVD, MD, Blue-Ray disks), etc.
  • the tool (1703) allows long-term storage of various types of information, such as the above-mentioned files with user data sets, a database containing records of time intervals measured for each user, user IDs, and the like.
  • 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.
  • interfaces (1704) depends on the specific implementation of the device (N00), which can be a personal computer, mainframe, server cluster, thin client, smartphone, laptop, and the like.
  • the keyboard must be used.
  • the keyboard hardware can be any known: it can be either a built-in keyboard used on a laptop or netbook, or a separate device connected to a desktop computer, server, or other computer device.
  • the connection can be either wired, in which the keyboard connection cable is connected to the PS / 2 or USB port located on the system unit of the desktop computer, or wireless, in which the keyboard exchanges data via a wireless communication channel, for example, a radio channel, with base station, which, in turn, is directly connected to the system unit, for example, to one of the USB ports.
  • data I/O can also used: joystick, display (touch screen), projector, touchpad, mouse, trackball, light pen, speakers, microphone, etc.
  • Means of networking (1706) are selected from a device that provides network reception and transmission of data, for example, an Ethernet card, WLAN/Wi-Fi module, Bluetooth module, BLE module, NFC module, IrDa, RFID module, GSM modem, etc.
  • a device that provides network reception and transmission of data for example, an Ethernet card, WLAN/Wi-Fi module, Bluetooth module, BLE module, NFC module, IrDa, RFID module, GSM modem, etc.
  • tools (1705) provides the organization of data exchange over a wired or wireless data transmission channel, for example, WAN, PAN, LAN (LAN), Intranet, Internet, WLAN, WMAN or GSM.
  • the components of the device (1700) are coupled via a common data bus (1710).

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Изобретение относится к области разработки и исполнения программных веб-приложений. Заявлена группа объектов, а именно облачная система и способ для разработки и исполнения программных веб-приложений. Облачная система состоит из микро-сервисов, взаимодействующих между Собой посредством программного интерфейса. Микро-сервисы представляют собой: сервис мета-модели; сервис управления мета-данными; сервис кросс - компилятора мета-языка, выполненный с возможностью перевода исходного кода мета-языка, представляющего описание бизнес-логики объекта приложения, в код на языке Erlang, компиляции полученного кода на языке Erlang в бинарный код для виртуальной машины Erlang, который может быть загружен и исполнен сервисом исполнения приложений, сервис управления сессиями; сервис исполнителя приложений; сервис интерфейса с внешними данными, выполненный с возможностью работы с внешними базами данных и веб-сервисами; сервис внешнего API системы. Сервисы мета-модели и управления сессиями выполнены с возможностью дополнения по меньшей мере одним сервисом по схеме «ведущий - ведомый» для распределения нагрузки при запросах. Технический результат заключается в повышении производительности и осуществлении горизонтального масштабирования при разработке и исполнении приложений, а также в упрощении описания бизнес - логики приложений, за счет использования мета-языка.

Description

СИСТЕМА И СПОСОБ СОЗДАНИЯ И ИСПОЛНЕНИЯ ВЫСОКО
МАСШТАБИРУЕМЫХ ОБЛАЧНЫХ ПРИЛОЖЕНИЙ
ОБЛАСТЬ ТЕХНИКИ
Настоящее техническое решение относится к разработке и исполнению программных веб-приложений. Более конкретно, изобретение относится к способам создания высоко масштабируемых облачных приложений, разработанных с использованием программных платформ.
УРОВЕНЬ ТЕХНИКИ
Из источника информации US 10, 324, 690 В2, опубликованного 18.06.2019, известно решение, которое описывает систему и способ для автоматического создания корпоративных программных приложений с минимальным уровнем ручного кодирования. Предпочтительный вариант осуществления предоставляет инструмент графического дизайна, который моделирует приложение с использованием Unified Model Language (UML), проверяет модель UML и автоматически генерирует развертываемое приложение. Предпочтительный вариант осуществления также предоставляет структуру библиотек, из которой может быть построено целевое приложение.
Из источника информации US 7,735,062 В2, опубликованного 08.06.2010 известно решение, которое описывает систему и способ разработки программных приложений. Заявленные система и способ позволяют создавать визуальные модели приложений, сохранять версии программных приложений в централизованном репозитории, автоматически генерировать и развертывать программные приложения, определять зависимости между программными приложениями, а также автоматизируют разработку нескольких, зависимых, программных приложений несколькими разработчиками.
Решения, известные из уровня техники имеют ряд недостатков, а именно использование XML формата для хранения описания моделей, которое может вызывать дополнительные сложности сематического анализа связей с другими моделями и элементами, так как они могут храниться в раздельных XML фрагментах в реляционной базе данных. Известные из уровня техники решения имеют слабую масштабируемость. Также решения, известные из уровня техники, для разработки и исполнения приложений предполагают наличие определенной готовой ИТ инфраструктуры у клиента для работы сгенерированного приложения, что не подходит для использования в режиме SaaS (Software As A Service), а более подходит для разработки и использования в режиме “onpremises” (на территории клиента).
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Технической задачей является создание системы и способа для быстрой разработки высоко масштабируемых облачных приложений, которые можно использовать по модели SaaS. Для решения технической задачи были созданы облачная система и способ разработки и исполнения программных веб-приложений, охарактеризованные в независимых пунктах формулы. Дополнительные варианты реализации настоящего изобретения представлены в зависимых пунктах изобретения.
Технический результат заключается в повышении производительности и осуществлении горизонтального масштабирования при разработке и исполнении приложений, а также в упрощении описания бизнес - логики приложений, за счет использования мета-языка. Дополнительно технический результат заключается в реализации назначения.
Заявленный результат достигается за счет осуществления облачной системы для разработки и исполнения программных веб-приложений, состоящей из микро-сервисов, взаимодействующих между собой посредством программного интерфейса, при этом микро-сервисы представляют собой: сервис мета-модели, включающий репозиторий мета-данных, и сервис интерфейса с мета-моделью, при этом сервис мета-моделей выполнен с возможностью дополнения по меньшей мере одним сервисом по схеме «ведущий - ведомый» для распределения нагрузки при запросах; сервис управления мета-данными, содержащий веб-интерфейс для работы с мета-данными, взаимодействующий с сервисом мета-моделей для получения и изменения мета-данных, выполненный с возможностью предоставления удобных средств работы с мета-данными, составляющими конфигурацию модулей приложений; реализация визуального редактора для построения интерфейсных форм приложения; предоставление визуального редактора исходного кода мета-языка; реализация механизмов работы с версиями описанных на мета-языке мета-данных, предоставление средств перевода мета-данных на другие языки для локализации приложений; сервис кросс - компилятора мета-языка, выполненный с возможностью перевода исходного кода мета-языка, представляющего описание бизнес-логики объекта приложения, в код на языке Erlang, компиляции полученного кода на языке Erlang в бинарный код для виртуальной машины Erlang, который может быть загружен и исполнен сервисом исполнения приложений; сервис управления сессиями, выполненный с возможностью авторизации пользователей, создания сессии, осуществления поиска сервиса исполнителя с необходимыми мета-данными, инициации сервиса исполнителя нужными мета-данными, создания процесса исполнителя и веб-интерфейса, дополнения по меньшей мере одним сервисом по схеме «ведущий - ведомый» для распределения нагрузки при запросах; сервис исполнителя приложений, выполненный с возможностью загрузки и выполнения приложений, сохраненных в системном репозитории в виде набора метаобъектов сложной структуры, включая описание бизнес-логики в виде скомпилированного бинарного кода, в рамках конкретной рабочей сессии пользователя, дополнения по меньшей мере одним сервисом для распределения нагрузки при запросах; сервис интерфейса с внешними данными, выполненный с возможностью работы с внешними базами данных и веб-сервисами; сервис внешнего API системы.
В частном варианте реализации предлагаемой системы, кросс-компилятор метаязыка содержит лексер, парсер и генератор кода Erlang.
В другом частном варианте реализации предлагаемой системы, сервис исполнения приложений содержит ядро исполнителя, кэш мета-данных, веб-интерфейс и процессы исполнения, динамически создаваемые по запросу.
В другом частном варианте реализации предлагаемой системы, сервис интерфейса с внешними данными, выполненный с возможностью работы с внешними базами данных через коннекторы, учитывающие специфику соответствующего источника данных.
В другом частном варианте реализации предлагаемой системы, сервис интерфейса с внешними данными выполненный с возможностью обеспечения унифицированного API работы с данными или веб-сервисами.
Заявленный результат также достигается за счет осуществления способа разработки и исполнения программных веб-приложений, содержащий этапы, на которых: описывают объекты приложений в виде мета-данных, хранящихся в репозитории мета-данных, посредством сервиса управления мета-данными и сервиса мета-модели, с использованием мета-языка компилирующего типа, при этом описание объектов приложений основано на описании классов мета-модели; описанные мета-данные, представленные в виде набора мета-объектов, содержащих свойства, вложенные объекты, а также исходный код мета-языка, реализующий события и процедуры объекта, преобразовывают в код на языке Erlang, при этом осуществляют сравнение исходного кода мета-языка с грамматикой языка и выдают список лексем распознанного языка, осуществляют синтаксический разбор полученного списка лексем, получают синтаксическое дерево разбора лексем, осуществляют семантический анализ синтаксического дерева разбора лексем, получают преобразованный исходный код мета языка на языке Erlang, осуществляют компилирование полученного кода на языке Erlang в исполняемый бинарный код для виртуальной машины Erlang; записывают полученный бинарный код в системный репозиторий; после запуска полученного приложения, посредством сервиса управления сессиями создают сессию и осуществляют поиск сервиса исполнителя с необходимыми мета-данными, инициацию сервиса исполнителя нужными мета-данными, создание процесса исполнителя и веб-интерфейс; осуществляют запуск и выполнение бинарного кода из системного репозитория посредством сервиса исполнителя, при этом исполнение бинарного кода осуществляется непосредственно на виртуальной машине Erlang.
В частном варианте реализации предлагаемой системы, мета-модель содержит классы, суб-кпассы, атрибуты, поведение, типы и суб-типы.
В другом частном варианте реализации предлагаемой системы, описание классов объектов включает добавление новых классов и наследование существующих классов.
ОПИСАНИЕ ЧЕРТЕЖЕЙ
Реализация изобретения будет описана в дальнейшем в соответствии с прилагаемыми чертежами, которые представлены для пояснения сути изобретения и никоим образом не ограничивают область изобретения. К заявке прилагаются следующие чертежи:
Фиг. 1 иллюстрирует обобщенную архитектуру предлагаемой облачной системы. Поз. 101 - программная платформа, поз. 102 - платформа разработки приложений, поз. 103 - платформа исполнения приложений, поз. 104 - реляционная СУБД, поз. 105 - репозиторий мета-данных, поз. 106 - мета-информация, поз. 107 - блок описания интерфейса, поз. 108 - блок описания бизнес-логики, поз. 109 - блок описания данных.
Фиг. 2 иллюстрирует архитектуру предлагаемой облачной системы. Поз. 110 — пользователь системы, поз. 111 - сервис управления мета-данными, поз. 112 - вебинтерфейс Дизайнера, поз. 113 - сервис кросс-компилятора, поз. 114 - балансировщик, поз. 115 - сервис управления сессиями, поз. 116 - менеджер сессий основной, поз. 117 - таблица сессий основная, поз. 118 - менеджер сессий дополнительный, поз. 119 — таблица сессий дополнительная, поз. 120 - сервис мета-модели основной, поз. 121 - сервис мета-модели дополнительный, поз. 122 - мета-модель основная, поз. 123 - метамодель дополнительная, поз. 124 - база данных модели основная, поз. 125 - база данных модели дополнительная, поз. 126 - сервис провайдера данных, поз. 127 - провайдер данных, поз. 128 - коннектор к базе данных, поз. 129 - внешняя база данных, поз. 130 - сервис веб-провайдера, поз. 131 - веб-провайдер, поз. 132 - веб-коннектор, поз. 133 - внешний веб-сервис, поз. 134 - сервис исполнителя, поз. 135 - ядро исполнителя, поз. 136 - кэш мета-данных, поз. 137 - процесс веб-интерфейса исполнителя, поз. 138 - процесс исполнителя.
Фиг. 3 иллюстрирует схему сервиса исполнителя. Поз. 139 - сервис исполнителя, поз. 140 - ядро исполнителя, поз. 141 - основной супервизор, поз. 142 - внешний API, поз. 143 - основной исполнитель, поз. 144- супервизор исполнителей, поз. 145 - супервизор веб-интерфейса, поз. 146 - кэш мета-данных, поз. 147 - процесс исполнителя, поз. 148 - процесс веб-интерфейса.
Фиг. 4 иллюстрирует обобщенную структуру мета-данных. Поз. 149 - мета-модель, поз. 150 - мета-данные, поз. 151 - конфигурация, поз. 152 - описание классов, поз. 153 - описание атрибутов классов, поз. 154 - описание поведения классов, поз. 155 - описание типов, поз. 156 - описание суб-типов, поз. 157 - описание модулей, поз. 158 - описание мета-объектов, поз. 159 - описание свойств объектов, поз. 160 - описание бизнес-логики объектов, поз. 161 - версии мета-объектов, поз. 162 - системные аккаунты, поз. 163 - схемы мета-данных, поз. 164 - роли, поз. 165 - пользователи, поз. 166 - привилегии.
Фиг. 5 иллюстрирует структуру описания класса мета-модели. Поз. 167 - основной класс, поз. 168 - базовый основной класс, поз. 169 - дочерний основной класс, поз. 170 — суб. класс, поз. 171 - атрибуты класса, поз. 172 - типы значений, поз. 173 - суб-типы атрибутов, поз. 174 - списки значений, поз. 175 - события класса, поз. 176 - методы класса.
Фиг. 6 иллюстрирует структуру описания объекта мета-данных. Поз. 177 - основной класс, поз. 178 - мета-объект, поз. 179- атрибуты класса, поз. 180 - события класса, поз. 181 - методы класса, поз. 182 - суб-класс 1 , поз. 183 - суб-класс 2, поз. 184 - атрибут класса А1 , поз. 185 - событие класса Е1 , поз. 186 - реализация метода класса, поз. 187 - свойство и значение объекта для атрибута А1 , поз. 189 - реализация события объекта Е1 , поз. 190 - реализация процедуры объекта Р1.
Фиг. 7 иллюстрирует схему версионирования объекта мета-данных. Поз. 191 - мета-объект, поз. 192 - неизменяемые атрибуты объекта, поз. 193 - версия 1 данных объекта, поз. 194 - версия 2 данных объекта, поз. 195 - значение свойства объекта версии 1 , поз. 196 - реализация события объекта версии 1 , поз. 197 - реализация процедуры объекта версии 1 , поз. 198 - значение свойства объекта версии 2, поз. 199 - реализация события объекта версии 2, поз. 200 - реализация процедуры объекта версии 2.
Фиг. 8 иллюстрирует схему разграничения мета-информации. Поз. 201 - аккаунт, поз. 202 - схема 1 , поз. 203 - схема 2, поз. 204 - модуль, поз. 205 - объект, поз. 206 - связи между объектами, поз. 207 - мета-модель, поз. 208 - описание данных, поз. 209 - суб-аккаунты, поз. 210 - роли, поз. 211 - пользователи, поз. 212 - привилегии.
Фиг. 9 иллюстрирует процесс компиляции исходного кода Мета-языка системы. Поз. 213 - компилятор мета-языка, поз. 214 - компилятор Erlang, поз. 215 - исходный код метаязыка, поз. 216 - исходный код на Erlang, поз. 217 - бинарный модуль в формате BEAM.
Фиг. 10 иллюстрирует алгоритм работы компилятора мета-языка. Поз. 218 - исходный код мета-языка, поз. 219 - лексер, поз. 220 - парсер, поз. 221 - генератор кода Erlang, поз. 222 - список лексем, поз. 223 - синтаксическое дерево, поз. 224 - исходный код на Erlang, поз. 225 - ошибка лексического анализа, поз. 226 - ошибка синтаксического разбора, поз. 227 - ошибка компиляции.
Фиг. 11 иллюстрирует схему работы парсера мета-языка. Поз. 228 - парсер, поз. 229’ - список лексем, поз. 229 - синтаксический разбор, поз. 230 - проверка дубликатов переменных, поз. 231 - проверка обращений к переменным, поз. 232 - проверка обращений к встроенным функциям, поз. 233 - проверка обращений к мета-данным, поз. 234 - синтаксическое дерево, поз. 235 - контекстно-свободная грамматика, поз. 236 - таблица имен (переменных), поз. 237 - таблица встроенных функций, поз. 238 - репозиторий мета-данных.
Фиг. 12 иллюстрирует пример синтаксического дерева. Поз. 239 - переменная N, поз. 240 - оператор присваивания, поз. 241 - оператор вычитания, поз. 242 - функция sin(), поз. 243 - число 100, поз. 244 - оператор умножения, поз. 245 - число 10, поз. 246 - оператор сложения, поз. 247 - функция abs(), поз. 248 - число -1 , поз. 249 - число 3.
Фиг. 13 иллюстрирует схему работы генератора кода Erlang. Поз. 250 - генератор кода, поз. 251 - синтаксическое дерево, поз. 252 - обход синтаксического дерева, поз. 253
- компиляция объявлений переменных, поз. 254 - компиляция операторов и выражений, поз. 255 - проверка аргументов функций, поз. 256 - генерация кода Erlang, поз. 257 - исходный код на Erlang, поз. 258 - семантическая проверка, поз. 259 - таблица встроенных функций, поз. 260 - шаблоны кода Erlang.
Фиг. 14 иллюстрирует структуру модуля Erlang. Поз. 261 - модуль Erlang, поз. 262
- предварительные декларации, поз. 263 - основная функция модуля, поз. 264 - объявление модуля, поз. 265- объявление параметров процедуры, поз. 266 - функции работы с переменными, поз. 267 - функции работы с массивами, поз. 268 - функция обработки RETURN, поз. 269 - регистрация параметров, поз. 270 - инициализация параметров, поз. 271 - регистрация переменных, поз. 272 - основной код процедуры, поз. 273 - вызов функции RETURN.
Фиг. 15 иллюстрирует алгоритм создания сессии пользователя. Поз. 274 - запрос на создание сессии, поз. 275 - менеджер сессий, поз. 276 - запрос на выделение исполнителя, поз. 277 - проверка на наличие исполнителя со схемой, поз. 278 - проверка на наличие исполнителя с модулем, поз. 279 - проверка на достижение максимального предела по кол-ву пользователей, поз. 281 - проверка на достижение максимального предела по емкости кэша, поз. 280 - инстанциация нового сервиса исполнителя, поз. 282- сервис исполнителя, поз. 283 - инициализация схемы, поз. 284- загрузка модуля из метаданных, поз. 285 - создание процесса исполнителя, поз. 286- создание процесса вебинтерфейса.
Фиг. 16 иллюстрирует алгоритм выполнения процедуры бизнес-логики. Поз. 287 - процесс веб-интерфейса, поз. 288 - инициация выполнения процедуры, поз. 289 - процесс исполнителя, поз. 290 - проверка кода процедуры в процессе, поз. 291 - передача процедуры на выполнение, поз. 292 - Erlang OTP, поз. 293 - вызов функций ядра системы, поз. 294 - основной исполнитель, поз. 295 - вызов встроенных функций мета-языка, поз. 296 - загрузка кода в кэш мета-данных, поз. 297 - проверка кода процедуры в кэше, поз. 298 - загрузка кода из кэша в процесс исполнителя, поз. 299 - бинарный код процедуры, поз. 300 - системный репозиторий, поз. 301 - сервис модели, поз. 302 - бинарный код процедуры, поз. 303 - кэш мета-данных.
Фиг. 17 иллюстрирует общую схему вычислительного устройства.
ДЕТАЛЬНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ
В приведенном ниже подробном описании реализации изобретения приведены многочисленные детали реализации, призванные обеспечить отчетливое понимание настоящего изобретения. Однако, квалифицированному в предметной области специалисту, будет очевидно каким образом можно использовать настоящее изобретение, как с данными деталями реализации, так и без них. В других случаях хорошо известные методы, процедуры и компоненты не были описаны подробно, чтобы не затруднять излишне понимание особенностей настоящего изобретения.
Кроме того, из приведенного изложения будет ясно, что изобретение не ограничивается приведенной реализацией. Многочисленные возможные модификации, изменения, вариации и замены, сохраняющие суть и форму настоящего изобретения, будут очевидными для квалифицированных в предметной области специалистов.
Предлагаемые способ и облачная система разработки и исполнения программных веб-приложений основаны на представлении программных приложений в виде метамоделей, хранящихся в системном репозитории и выполняются на вычислительном устройстве.
Облачная система для разработки и исполнения программных веб-приложений состоит из микро-сервисов, взаимодействующих между собой посредством программного интерфейса API. Предлагаемая облачная система обеспечивает высокую производительность и возможность горизонтального масштабирования при одновременной работе большого количества пользователей.
На Фиг.1 , проиллюстрирована обобщенная архитектура предлагаемой системы разработки и исполнения программных веб-приложений.
Архитектура предполагает разделение программных приложений на две большие части - программное ядро (платформу) 101 и прикладную часть (мета-информацию) 106, хранимую в репозитории 105. Мета-информация хранится в системном репозитории, организованном в реляционной системе управления базами данных (СУБД) 104. Программное ядро (платформа) 101 состоит из двух больших подсистем: платформы разработки приложений 102 и платформы исполнения приложений 103.
Платформа разработки приложений 102 отвечает за предоставление инструментов разработчику для описания модели приложений в формате платформы. Пример таких инструментов разработки: навигатор мета-данных системы, редактор атрибутов мета-объектов, редактор форм интерфейса объектов, редактор процедур бизнес-логики.
Платформа исполнения приложений 103 предоставляет механизмы и ресурсы для запуска приложений по описанию в мета-данных. Платформа исполнения использует мета-информацию о приложениях, хранимую в репозитории мета-данных, для загрузки и выполнения приложений, включая генерацию интерфейса приложений, взаимодействие с пользователем и выполнение процедур бизнес-логики.
Описание приложений в мета-информации 106 состоит из трех основных частей: описание интерфейса бизнес-объектов 107, описание бизнес-логики объектов 108, описание данных 109. Интерфейс бизнес-объектов приложений описывается набором атрибутов и визуальных форм объектов. Бизнес-логика объектов описывается с помощью встроенного мета-языка системы, компилируемого для исполнения в бинарные модули. Описание данных приложения определяется провайдером данных и описывается набором источников данных, которые могут включать в себя различные СУБД или вебсервисы.
На Фиг. 2 проиллюстрирована подробная архитектура предлагаемой системы.
Основой для работы предлагаемой системы является сервис мета-модели 120, который обеспечивает хранение и доступ к мета-данным в системном репозитории. Сервис состоит из реляционной базы данных 124, включающей системный репозиторий, и собственно мета-модели 122, которая обеспечивает все операции по работе с системным репозиторием и предоставляет внешний интерфейс API к репозиторию, способный обрабатывать множество параллельных асинхронных запросов. Использование API позволяет абстрагироваться от структуры данных внутри репозитория (в реляционной базе данных) и обеспечить независимость от способа хранения метаданных.
Основными функциями сервиса мета-модели по работе с системным репозиторием являются: получение мета-информации по произвольным запросам к репозиторию; ввод новой мета-информации; изменение существующей метаинформации; удаление мета-информации.
Мета-модель обеспечивает целостность мета-данных при любых операциях с мета-информацией.
Для повышения производительности системы, при большом количестве запросов к репозиторию, а также для улучшения отказоустойчивости, в системе предусмотрено построение конфигурации мета-модели по схеме «ведущий - ведомый», при которой основной сервис («ведущий») дополняется несколькими «ведомыми» и между всеми ними возможно распределение нагрузки при запросах. На Фиг.1 изображен «ведомый» сервис мета-модели 121 , который имеет также свою собственную реляционную базу данных 125, в которой находится копия системного репозитория. Базы данных основного сервиса и «ведомого» сервиса синхронизируются (реплицируются) в автоматическом режиме, при этом операции изменения мета-информации возможны только в основном сервисе, а запросы на чтение мета-информации возможны во всех сервисах. В случае, если основной сервис мета-модели по какой-то причине отказывает, на его место встает один из «ведомых» и становится основным, а все остальные сервисы начинают синхронизироваться с ним. В данной схеме количество «ведомых» сервисов мета-модели практически неограниченно и определяется требованиями масштабирования системы.
Сервис управления мета-данными 111 предназначен для обеспечения пользователя системы всеми необходимыми ресурсами и инструментами для разработки приложений. Основной сервиса является веб - интерфейс Дизайнера приложений, который предоставляет удобный интерфейс работы с мета-данными для разработчика. Веб - интерфейс Дизайнера взаимодействует напрямую с сервисом мета-модели через внешний интерфейс API для получения мета-данных и для выполнения изменений в мета-данных.
Основные функции сервиса: управление бизнес-аккаунтами и суб-аккаунтами, а также доступом к ним; управление пользователями системы, ролями пользователей, списком привилегий; управление схемами мета-данных и доступом к ним; управление мета-информацией (набором классов и их описанием, включая атрибуты и поведение); удобная навигация по приложениям (модулям) и объектам мета-данных в выбранной схеме; предоставление редакторов объектов мета-данных. Веб - интерфейс Дизайнера также реализует визуальный редактор для построения интерфейсных форм объектов; редактор исходного кода процедур и событий бизнес-логики.
В сервисе реализован механизм работы с версиями объектов мета-данных, а также есть возможность перевода мета-данных бизнес-объектов на другие языки для локализации приложений. Веб - интерфейс Дизайнера также взаимодействует с сервисом кросс-компилятора 113 для перевода исходного кода процедур мета-языка в исполняемый бинарный код.
Сервис управления мета-данными обеспечивает параллельную работу большого количества пользователей одновременно, выделяя для каждой сессии пользователя отдельный процесс.
Реализация сервиса управления мета-данными предполагает также возможность горизонтального масштабирования, при помощи запуска дополнительных сервисов, между которыми будет осуществляться распределение сессий с помощью балансировщика нагрузки 114.
Сервис кросс-компилятора 113 служит для перевода исходного кода процедур и событий бизнес-логики приложений (мета-языка) в исполняемые бинарные модули, которые могут быть загружены и исполнены сервисом исполнителя приложений и является частью системы разработки приложений вместе с сервисом управления метаданными и используется только из веб - интерфейса Дизайнера. Сервис кросскомпилятора предоставляет внешний API для вызова своих методов и может обрабатывать большое количество асинхронных запросов одновременно. При необходимости горизонтального масштабирования для обслуживания еще большего количества запросов, возможен запуск нескольких сервисов компилятора, запросы к которым распределяются автоматически с помощью балансировщика нагрузки 114.
Сервис кросс-компилятора 113 содержит лексер, парсер и генератор кода Erlang. На вход сервису компилятора поступает исходный текст процедур мета-языка системы, а также дополнительная информация, необходимая для компиляции, например: модуль, объект. Компилятор обеспечивает полный грамматический разбор и синтаксический анализ конструкций входного языка и выдачу ошибок при компиляции. В процессе компиляции сервис взаимодействует с сервисом мета-модели 120 для получения дополнительной мета-информации об объектах мета-данных, которые используются в исходном коде процедуры, например чтобы валидировать список и типы аргументов вызываемой процедуры приложения или объекта. В случае, если сервис мета-модели недоступен для запроса из компилятора, процесс компиляции не может быть завершен. При успешном завершении компиляции, компилятор выдает бинарный код скомпилированной процедуры, совместимый с виртуальной машиной Erlang, который записывается сервисом управления мета-данными в системный репозиторий.
Сервис управления сессиями 115 содержит менеджер сессий 116 и локальную таблицу сессий 117. Основная функция менеджера сессий - аутентификация пользователя системы и авторизация его для использования ресурсов системы. Аутентификация и авторизация выполняется для любого пользователя, который будет использовать подсистему разработки или исполнения приложений. То есть, прежде чем пользователь сможет запустить, например, веб-интерфейс Дизайнера, сервис управления сессиями должен идентифицировать пользователя по его учетным данным (например, с помощью логина и пароля). Для аутентификации, сервис управления сессиями делает запрос в сервис мета-модели, где хранятся все учетные записи пользователей. Если аутентификация успешна, сервис должен авторизовать пользователя для запуска веб-интерфейса Дизайнера с параметрами, запрошенными пользователем, например, бизнес-аккаунт, схема мета-данных.
В случае, если авторизация прошла успешно, сервис создает сессию для пользователя и передает сессию в веб-интерфейс Дизайнера, который далее обрабатывает все входящие запросы. В случае запуска пользователем бизнес- приложения из системного репозитория, сервис управления сессиями, после создания сессии, выделяет ресурсы исполнителя приложений и передает сессию исполнителю. Процесс выделения ресурсов исполнителя состоит из следующих этапов: поиск сервиса исполнителя с необходимыми мета-данными, инициация дополнительного сервиса исполнителя если необходимо, инициация сервиса исполнителя нужными мета-данными, создание процесса исполнителя и веб-интерфейса Дизайнера. После создания сессии информация о ней записывается в локальную таблицу сессий менеджера сессий. После того, как пользователь завершает работу с приложением, информация о сессии удаляется из таблицы сессий сервиса, а выделенные процессы исполнителя и вебинтерфейса Дизайнера прекращают свою работу. Для повышения производительности сервиса управления сессиями при большом количестве запросов, а также для улучшения отказоустойчивости, в системе предусмотрено построение конфигурации сервиса по схеме «ведущий - ведомый», при которой основной сервис («ведущий») дополняется несколькими «ведомыми» и между всеми ними возможно распределение нагрузки при запросах. На диаграмме изображен «ведомый» менеджер сессий 118, который имеет также свою собственную локальную таблицу сессий 119, в которой находится копия таблицы сессий основного менеджера сессий. Таблицы сессий «ведущего» и «ведомого» менеджера сессий синхронизируются в автоматическом режиме. В случае, если «ведущий» менеджер сессий по какой-то причине отказывает, на его место встает один из «ведомых» и становится основным, а все остальные менеджеры начинают синхронизироваться с ним. Балансировщик нагрузки 114 служит для автоматического распределения нагрузки между сервисами управления сессиями, а также между сервисами мета-модели.
Сервис исполнителя 134 является основой подсистемы исполнения приложений и обеспечивает запуск и выполнение бизнес-приложений, описание которых хранится в системном репозитории.
Основные компоненты сервиса исполнителя: ядро исполнителя 135, кэш метаданных 136, процесс веб-интерфейса 137 и процесс исполнителя 138.
Ядро исполнителя (140 Фиг.З) состоит из основного супервизора 141 (Фиг.З), модуля внешнего AP1 142, основного исполнителя 143 вместе со встроенными функциями мета-языка, супервизор процессов исполнителей 144, супервизор процессов вебинтерфейса 145. Внешний API 142 предоставляет набор методов для управления и использования сервиса исполнения, включая методы для инициализации сервиса, загрузки мета-данных, получения информации о сервисе и его состоянии, выполнения процедур бизнес-логики. Модуль основного исполнителя 143 реализует основные методы работы сервиса, а также содержит реализацию встроенных функций мета-языка системы. Супервизор исполнителей 144 отвечает за инстанциацию и управление процессами исполнителей 147. Супервизор веб-интерфейса 145 отвечает за инстанциацию и управление процессами веб - интерфейса 148.
Кэш мета-данных 146 (Фиг.З) - это программно-управляемые структуры в памяти процесса сервиса исполнения, предназначенные для локального хранения метаинформации, необходимой для запуска и выполнения бизнес-приложений сервисом исполнения. Ядро исполнителя 140 реализует внешний API для сервиса, а также отвечает за взаимодействие с сервисом мета-модели и сервисом управления сессиями. Также, ядро исполнителя управляет внутренними процессами сервиса. Кэш мета-данных 146 (Фиг.З) хранит мета-информацию, связанную со схемой мета-данных (например, описания провайдеров и источников данных), а также полную информацию о бизнес-объектах приложений (модулей), содержащихся в схеме. Кэш может хранить мета-информацию, принадлежащую только одной схеме мета-данных. Использование локального кэша во время работа исполнителя исключает необходимость обращения за мета-данными к сервису мета-модели, что значительно увеличивает производительность и уменьшает интенсивность коммуникаций внутри системы.
Процесс веб-интерфейса 137 (Фиг.2) и процесс исполнителя 138 предназначены для обслуживания отдельной сессии пользователя, который работает с бизнес- приложением в системе.
Процесс исполнителя 147 (Фиг.З) порождается супервизором исполнителей 144 в ответ на запрос к сервису исполнителя со стороны сервиса управления сессиями. Процесс веб-интерфейса 148 создается супервизором веб-интерфейса 145 при создании новой сессии пользователя во время запуска бизнес-приложения на выполнение. Для каждой сессии пользователя всегда создается отдельная пара процессов исполнения и веб-интерфейса, за счет чего достигается полная изоляция выполнения бизнес- приложений для разных сессий. Сервис веб-интерфейса 148 взаимодействует со своим парным сервисом исполнителя 147 во время работы, например, при определенных действиях пользователя приложения, сервис веб-интерфейса может инициировать исполнение процедуры бизнес-логики с помощью процесса исполнителя. Процесс исполнителя 147 также тесно взаимодействует с кэшем мета-данных, например, когда необходимо извлечь информацию о мета-объекте во время выполнения бизнес- процедуры. При этом, разные процессы исполнителя могут одновременно использовать один и тот же набор данных в кэше сервиса исполнителя, если это сессии одного и того же приложения. Таким образом, один сервис исполнителя может обслуживать большое количество сессий пользователя, если они относятся к одному и тому же набору приложений схемы мета-данных.
Сервис исполнителя полностью автономен и после инициализации практически независим от других сервисов системы, что позволяет выполнять практически неограниченное горизонтальное масштабирование системы исполнения приложений для обслуживания очень большого количества одновременных сессий пользователей. Масштабирование достигается посредством авто-инстанциации дополнительных сервисов исполнителей, необходимых для обслуживания новых пользователей, в зависимости от текущей загрузки системы.
Для работы приложения с внешними данными предназначены сервисы провайдеров внешних данных 126 (Фиг.2) и веб-сервисов 130. Основу сервиса провайдера составляет соответствующий провайдер (данных 127 или веб-провайдер 131), а также коннекторы к источникам данных 128 или коннекторы к веб-сервисам 132. Каждый коннектор учитывает специфику соответствующего источника данных 129 или веб-сервиса 133 и обеспечивает работу с ними на низком уровне протокола передачи данных или API сервиса, выполняя передачу данных или команд из/в источник данных или веб-сервис. Провайдер данных или веб-сервиса обеспечивает унифицированный API работы с данными или сервисами для бизнес-приложений системы, абстрагируясь от специфики конкретных источников данных или веб-сервисов. Конфигурирование провайдеров данных веб-сервисов выполняется с помощью сервиса управления метаданными, конфигурация провайдеров хранится в мета-данных в системном репозитории и может быть в любой момент скорректирована разработчиком приложения. Провайдеры взаимодействуют с процессами исполнителя сервиса исполнителя приложений, принимая от них команды на получение или изменение данных или передавая полученные данные.
Далее будет расписан способ разработки и исполнения программных вебприложений.
Первым этапом работы предлагаемого способа является описание произвольных бизнес-объектов приложения в мета-данных, хранимых в системном репозитории (метамодели) в реляционной базе данных. Описание осуществляется посредством сервиса управления мета-данными и сервиса мета-модели с использованием процедурного метаязыка компилирующего типа, с поддержкой объектов для реализации сложной бизнес- логики приложений, при этом описание объектов приложений основано на описании классов мета-модели.
Структура данных репозитория спроектирована таким образом, чтобы обеспечить максимальную гибкость и отсутствие практических ограничений на возможные способы описания бизнес-объектов, включая набор их свойств (атрибутов), поведения (методов и событий), структуры и связей. Для решения данной задачи введен уровень абстракции модели в виде классов объектов (прото-объектов), которые определяют все необходимые для описания реальных бизнес-объектов структуры и данные.
Фиг. 4 описывает обобщенную структуру репозитория мета-данных предлагаемой системы. Основные части репозитория: мета-модель 149, мета-данные 150 и конфигурация 151 .
Мета-модель 149 служит для описания состава и структуры прото-объектов метаданных. Данный подход обеспечивает максимальную гибкость и отсутствие практических ограничений на возможные способы описания бизнес-объектов, позволяя расширять базовый набор классов мета-модели при необходимости. Описание класса 152 включает в себя набор атрибутов 153 и их типов 155 (а также суб-типов 156, при необходимости); поведение 154 - набор методов и событий класса; структуру класса - в случае если класс является сложным и содержит вложенные классы.
Мета-данные 150 содержат описания бизнес-объектов 158, являющихся частью приложений (модулей) 157. Описание каждого объекта 158 строится на основе описания его класса 152 в мета-модели 150. Набор свойств 159 и их типов объекта однозначно определяется набором атрибутов класса объекта. Значениями свойств объектов могут быть как скалярные величины простых типов, так и ссылки на другие объекты или их свойства. Набор процедур бизнес-Логики 160 объекта определяется на основании поведения (методов и событий), описанных в классе. Данные объекта могут версионироваться, то есть могут сохраняться различные варианты значений свойств объекта, созданные в разные моменты времени.
Конфигурация 151 содержит структуры, необходимые для организации всей метаинформации и обеспечения доступа к ней со стороны пользователей системы. Вся метаинформация и, в частности, конфигурация разделена по аккаунтам 162. Аккаунт представляет собой группировку информации по признаку доступа и объединяет роли, пользователей и их привилегии, а также включает в себя схемы со всеми мета-данными внутри. Схема 163 - это еще один уровень разделения метаданных по семантическому признаку. Схема определяет - какая мета-модель используется внутри данной схемы и, соответственно, как описываются мета-объекты в данной схеме.
Фиг.5 иллюстрирует структуру описания класса мета-модели. Классы могут быть одного из двух видов: основной класс 167 или суб-класс 170. Основной класс может использоваться для описания бизнес-объектов в мета-данных. Суб-классы используются для формирования структуры сложных (составных или вложенных) классов и не могут самостоятельно использоваться для описания бизнес-объектов, а только в составе основных классов.
Любой класс описывается набором атрибутов 171 , каждый из которых имеет определенный тип 172, а также возможно суб-тип 173. Тип значения атрибута может быть простым скалярным типом (например, числовым, текстовым) или являться ссылкой на: элемент списка значений 174, другой основной класс 168 или атрибут основного класса. Набор атрибутов однозначно определяет - какие свойства бизнес-объекта данного класса должны быть описаны и сохранены в мета-данных.
Кроме атрибутов, у класса могут быть описаны методы 176 и события 175. Совокупность методов и событий класса определяет его поведение. Метод класса - это именованная предопределенная процедура, которая определяет операции, возможные для объекта данного класса. Пример методов класса: создать новый элемент, записать данные, удалить элемент. Реализация метода возложена на сам класс, то есть процедуры методов должны быть заранее определены для каждого класса. Процедуры методов вызываются на выполнение в результате взаимодействия пользователя с приложением либо программным способом (из других процедур бизнес-логики). Событие класса - это именованная процедура класса, которая определяется для бизнес-объекта в мета-данных. Для каждого класса имеется свой набор событий, который однозначно определяет - какие события могут быть определены для бизнес-объекта данного класса, то есть реализация процедуры события делается в бизнес-объекте, а не в классе. Процедуры событий объектов вызываются на выполнение в результате взаимодействия пользователя с приложением при наступлении определенных условий (например, двойной щелчок левой кнопки мыши).
Для описания сложных (вложенных) классов применяется структура класса, которая является иерархическим набором ссылок на суб-кпассы, которые составляют данный класс. Иерархия здесь означает, что каждый используемый суб-класс в структуре в свою очередь может также иметь вложенные суб-классы. В структуре класса нельзя использовать классы основного вида, допускается использование только суб-классов. Структура класса определяет - из каких составных частей состоит бизнес-объект и как будет строиться представление объекта в мета-данных. В качестве примера можно привести основной класс «Документ», в составе которого может находиться суб-класс «Форма». Используя данную структуру, возможно представить бизнес-объект класса «Документ», как совокупность объектов форм, определяющих визуальное представление данного объекта.
Расширение мета-модели возможно двумя способами: добавление новых классов или наследование из уже существующего класса. Для вновь создаваемого класса необходимо определить набор атрибутов, событий и методов, а также структуру. Как только новый класс описан, становится возможным создание бизнес-объектов данного класса. Наследование используется, когда новый класс в значительной степени повторяет уже существующий класс с небольшими изменениями. При наследовании дочерний класс получает все атрибуты, методы и события, а также структуру родительского класса, при этом возможно добавить собственные атрибуты, методы, события и дополнить структуру класса. Переопределение атрибутов и методов, а также структуры родительского класса, запрещено в дочернем классе.
Фиг. 6 иллюстрирует способ описания мета-объекта мета-данных на основе определения класса мета-модели. В данном примере у класса 171 определены два атрибута (179): атрибут А1 (184) и атрибут А2. В соответствии с данным определением, при создании описания мета - объекта 178, принадлежащего данному классу, должны быть введены значения свойств объекта 187, соответствующих атрибутам А1 и А2. При этом, тип значения, например, для свойства объекта А1 (187) должен соответствовать типу и суб-типу атрибута класса А1 (184). В мета-объекте можно (но необязательно) определить реализацию процедур для событий класса (180). При этом сигнатуры процедур объекта (наименование процедуры, тип возвращаемого значения, список и типы аргументов) должны полностью соответствовать описанию событий в классе. Например, реализация события объекта Е1 (189) должна соответствовать описанию события класса Е1 (185). В объекте можно определить реализацию только тех событий, которые были описаны в классе. Реализация процедур событий объекта происходит посредством использования объекта суб-класса «событие объекта» 182, определенного в структуре класса. Как уже было описано выше, методы класса 181 должны быть реализованы непосредственно в классе. В данном примере у класса определены два метода 186: метод 1 и метод 2. Наконец, согласно определению класса, в данном примере, в мета-объекте возможно (но необязательно) определить сколько угодно процедур бизнес-логики. Процедуры заранее не описываются в классе. Реализация процедур объекта происходит посредством использования объекта суб-класса «процедура объекта» 183, определенного в структуре класса.
Механизм хранения объектов в репозитории мета-данных предполагает возможность версионирования (необязательно). Фиг. 7 описывает схему версионирования данных мета-объекта. При этом, все данные мета-объекта 191 разделяются на неверсионируемую и версионируемую часть.
Неверсионируемая часть объекта содержит неизменяемые атрибуты 192, например, такие как класс, ссылка на родительский объект, и используется для реализации ссылок на объекты и установления связей между объектами. Данные объекта, которые могут изменяться в результате разработки (доработки) объекта, вынесены в версионируемую часть (193, 194).
Версионируемая часть содержит: значения свойств объекта 195, реализацию событий объекта 196, реализацию процедур объекта 197. Версией объекта называется совокупность версионируемых данных объекта, сохраненных в репозитории мета-данных с уникальным идентификатором (номером) версии.
В случае, если система работает в режиме без версионирования, то все изменения в данных объекта записываются с номером версии 0 (старые данные при этом не сохраняются). Если включен режим версионирования, то измененные данные объекта 194 записываются с новым номером версии, при этом старые данные объекта 193 также сохраняются с предыдущим номером версии. Для того чтобы начать изменения объекта в режиме версионирования, необходимо выполнить операцию “check-out” (взятие объекта на редактирование), при этом текущая (актуальная) версия объекта блокируется для изменения другими пользователями и создается новая версия объекта, куда и вносятся изменения. Как только изменения завершены, выполняется операция “check-in”, в результате чего новая версия объекта становится актуальной, а предыдущая версия разблокируется.
Каждая версия мета-объекта может принадлежать той или иной ветке. В рамках одной ветки все версии объекта сохраняются последовательно, однако в разных ветках могут сохраняться параллельно разные версии объектов. Только одна версия в рамках одной ветки может быть актуальной (это последняя версия в ветке). Кроме признака актуальной версии, версии могут быть отмечены признаком “рабочей” версии. Рабочая версия - это стабильная и протестированная версия объекта, которая может быть использована для исполнения в приложении. Можно установить только одну рабочую версию объекта (она необязательно должна совпадать с актуальной).
Предлагаемые облачная система и способ могут работать в режиме SaaS. Для функционирования системы разработки и исполнения приложений в режиме одновременного ее использования многими пользователями, необходимо обеспечить надежный способ разграничения мета-информации, включая мета-модель, мета-данные и конфигурацию. Фиг. 8 поясняет способ разграничения мета-информации в системе.
Основой разграничения является сущность, называемая “аккаунт” 201. Под аккаунтом здесь понимается неличная учетная запись зарегистрированного бизнес- пользователя системы. В рамках основного аккаунта можно создавать суб-аккаунты 209, которые являются подчиненными к основному аккаунту. Аккаунт должен содержать как минимум один личный профиль пользователя 211 , при этом количество профилей пользователя не ограничено. Каждому профилю пользователя может быть назначена определенная роль 210 и набор привилегий 212. Важной особенностью данного способа разграничения является то, что пользователи, их роли и привилегии, определяются изолированно в рамках аккаунта, то есть являются независимыми от пользователей, ролей и привилегий другого аккаунта.
Следующим уровнем разграничения мета-информации является сущность, обозначенная как “схема” (202, 203). Схема объединяет взаимосвязанную информацию мета-модели и мета-данных, такую как описание классов, данных и мета-объектов. При данном подходе каждая схема содержит собственную мета-модель (описание классов или прото-объектов), что обеспечивает независимость от других схем даже в рамках одного аккаунта и позволяет безопасно расширять или изменять мета-модель без риска непредсказуемого изменения описания бизнес-объектов другой схемы. Схема служит также в качестве “контейнера” приложений, разрабатываемых и исполняемых на платформе, и обозначаемых термином “модуль” 204. Приложение (модуль) является совокупностью бизнес-объектов 205, каждый из которых может принадлежать только одному модулю. В целях обеспечения возможности переиспользования бизнес-объектов одного модуля в других модулях задействуется механизм связей 206 между модулями посредством создания ссылок на объекты. Связи (ссылки на объекты) можно создавать только между модулями в рамках одной схемы. Схема также содержит описание источников внешних данных 208, которые нужны для работы приложений. Источники данных могут использоваться любым приложением (модулем) в рамках одной схемы. Таким образом, модули группируются по схемам по функциональному признаку (связанные бизнес-объекты) и по принципу использования общих данных.
Как уже было упомянуто ранее, разработка программных веб-приложений основана на описании произвольных бизнес-объектов приложения в мета-данных, посредством процедурного мета-языка компилирующего типа, с поддержкой объектов для реализации сложной бизнес-логики приложений. Грамматика языка построена таким образом, что позволяет непосредственно работать с объектами мета-данных приложений, а также эффективно использовать данные из внешних источников. Весь код бизнес-логики приложений разбивается на отдельные процедуры или обработчики событий и привязан к бизнес-объектам в мета-данных. Это позволяет использовать контекст мета-объекта в самой процедуре, например, ссылку на текущую форму данных объекта, и получить прямой доступ к данным в форме. Таким образом, с помощью средств языка можно в режиме исполнения манипулировать данными, с которыми работает пользователь приложения, и даже вмешиваться в ход обработки данных или в поведение мета-объекта.
Общая структура грамматики мета-языка представлена тремя основными блоками: синтаксические элементы языка, организация данных и обработка данных.
Синтаксические элементы языка включают синтаксические конструкции, например, комментарии (//, /**/), литералы (1 , ‘s’, ’’s”), скобки ([],(),{}) , а также ключевые слова, которые используются при написании кода на мета-языке.
Организация данных включает информацию о типах данных (any, integer, string и т.д.), структуре хранения данных и объектах. Мета-язык является строго типизируемым языком. Это означает, что значения разных типов не могут использоваться в выражениях без приведения типа, а также в качестве аргументов функции могут передаваться только значения соответствующего определению функции типа.
Обработка данных происходит посредством использования арифметических операций (+, ++, -, --, *, /, л), операторов присвоения (=, +=, -=, *=, /=), операторов ветвления (IF, THEN, ELSE, CHOOSE, CASE, RETURN), логических операций (=, <>, >, <, >=, <=, NOT, AND, OR, ANDALSO, ORELSE), операторов циклов (FOR - NEXT, DO - LOOP, CONTINUE, EXIT), обработки ошибок (THROW, TRY - CATCH, FINALLY), работы c объектами (CREATE, DESTROY, FUNCTION, EVENT, CALL), операторов SQL (CONNECT, DISCONNECT, SELECT, INSERT, UPDATE, DELETE, COMMIT, ROLLBACK, OPEN, CLOSE, FETCH, EXECUTE), а также встроенных функций (встроенные функции, функции преобразования, строковые функции, числовые функции, функции даты-времени, функции массивов, разные функции).
Язык поддерживает вызовы других процедур мета-моделей, а также рекурсивные вызовы.
Второй этап предлагаемого способа заключается в том, что описанные метаданные, представленные в виде набора мета-объектов, содержащих свойства, вложенные объекты, а также исходный код мета-языка, реализующий события и процедуры объекта, преобразовывают в код на языке Erlang, который впоследствии компилируют в исполняемый бинарный код для виртуальной машины Erlang (BEAM), посредством сервиса кросс-компилятора.
Фиг.9 иллюстрирует обобщенный процесс компиляции исходного кода процедур мета-языка системы в бинарные файлы BEAM. На входе компилятору поступает исходный код мета-языка 215. Компилятор мета-языка 213 анализирует его и преобразует в текст, полностью удовлетворяющий синтаксису языка Erlang и реализующий ту же самую логику. Компилятор мета-языка преобразует синтаксические конструкции и вызовы функции в соответствующие конструкции и вызовы функций Erlang, получая результирующий код на языке Erlang 216. Далее используется стандартный компилятор языка Erlang 214 для преобразования исходного кода Erlang в бинарный модуль в формате BEAM 217.
Далее, со ссылкой на Фиг.10, будет описана работа кросс-компилятора мета языка.
Как уже было указано выше, кросс-компилятор состоит из 3 основным модулей: лексер 219, парсер 220 и генератор кода Erlang 221 .
На вход лексеру 219 поступает текст исходного кода мета-языка 218, лексер 219 сверяет входной поток с грамматикой языка и в результате анализа выдает список распознанных лексем языка 222.
Лексер 219 выполняет анализ входного потока исходного кода мета-языка на основе правил грамматики. Каждый вид лексемы описан в виде шаблона - регулярного выражения. Лексер 219 различает игнорируемые символы (пробел, символ завершения строки, комментарий), строковые и числовые литералы, значения даты и времени, идентификаторы, операторы сравнения, логические операторы, арифметические операторы, скобки, ключевые слова. Лексемы, которые продуцирует лексер, представлены в виде кортежей. Формат лексемы, возвращаемой лексером:
{лексема, номер строки, символ(ы)}.
В случае, если в процессе анализа исходного кода лексер не может распознать лексему, он выдает ошибку 225 с указанием номера строки исходного кода и процесс компиляции останавливается.
Если все лексемы из входного потока разобраны корректно, то лексер выдает список разобранных лексем и процесс компиляции продолжается. Список лексем поступает на вход парсеру 220 и он осуществляет синтаксический разбор лексем, сверяя лексемы и их порядок с определением синтаксиса языка.
Парсер (228, Фиг.11) осуществляет синтаксический разбор списка лексем 229 из входного потока, преобразовывая их в синтаксическое дерево 234, на основе определения правил грамматики. Синтаксис конструкций мета-языка задан с помощью контекстно-свободной грамматики 235 или записи BNF (Backus-Naur Form), в виде правил грамматического вывода (продукций). Кроме проверки соответствия порядка лексем правилам грамматического вывода (синтаксису), парсер выполняет еще несколько важных действий:
1 .ведет таблицу переменных 236;
2. проверяет дубликаты при объявлении переменных 230;
3. проверяет что переменная декларирована перед использованием;
4. проверяет размерность массивов при инициализации во время объявления;
5. проверяет правильность обращения к переменной и элементу массива 231 ;
6.валидирует обращение к встроенным функциям, включая количество аргументов 232;
7.валидирует обращение к объектам мета-данных приложения 233.
Если в процессе разбора обнаруживается некорректная синтаксическая конструкция, парсер 220 выдает сообщение об ошибке 226 с указанием номера строки исходного кода и процесс компиляции останавливается. Если синтаксический разбор списка лексем прошел успешно, то парсер выдает синтаксическое дерево разбора лексем 223, которое поступает на вход генератора кода Erlang 221.
Фиг. 12 иллюстрирует способ представления следующего арифметического выражения в виде синтаксического дерева, после обработки парсером мета-языка: n = (abs(-1) + 3 ) * 10 - sin(100),
Результатом выполнения лексического анализа и синтаксического разбора является следующее синтаксическое дерево кортежей:
{2,stmt_assign, {2, var, number, local, write, n,[]}, op_eq,
{2,op_minus,
{2,op_mul,
{2,op_plus,
{2, function, number, abs, [number], [{2, unary_minus, {2, integer, 1}}]},
{2, integer, 3}},
{2, integer, 10}},
{2,function,number,sin,[number],[{2,integer,100}]}}}.
Генератор кода 221 выполняет нисходящий обход синтаксического дерева 223, осуществляя семантический анализ и различные дополнительные проверки, например, соответствие типов в выражениях. Для каждой синтаксической конструкции генератор кода выполняет преобразование ее в код целевого языка (Erlang).
Генератор кода 250 (Фиг.13) получает на вход синтаксическое дерево кортежей 251 и на выходе генерирует исходный код на языке Erlang 257. Генератор кода осуществляет нисходящий обход 252 синтаксического дерева, выполняя семантические проверки 258 на каждом шаге. В процессе обхода синтаксического дерева, генератор выполняет компиляцию объявлений переменных 253 или компиляцию операторов и выражений 254. Семантические проверки при компиляции объявлений переменных и массивов включают проверку выражений инициализации. Семантические проверки при компиляции операторов и выражений включают в себя дополнительные проверки синтаксиса, а также проверку типов выражений, соответствие типов операндов выражений. При компиляции вызовов функций 285 все передаваемые фактические аргументы также проверяются на соответствие типам аргументов функции по таблице встроенных функций 259. Генерация кода Erlang 256 производится на основании заранее заданных шаблонов кода Erlang 260.
Если в процессе обхода синтаксического дерева 223 генератор кода 221 обнаруживает ошибку (например, несоответствие типов в выражении), он выдает ошибку компиляции 227 с указанием номера строки исходного кода и процесс останавливается.
В случае, если обход синтаксического дерева 223 завершился успешно, то на выходе генератора кода 221 образуется исходный код на языке Erlang 224, который далее можно использовать для компиляции в бинарный формат.
Модуль сгенерированного кода на языке Erlang 261 представлен на Фиг.14. Весь код модуля состоит из двух больших частей: предварительных деклараций 262 и основной функции модуля 263. Предварительные декларации включают в себя: объявление модуля 264, объявление параметров процедуры 265, функции работы с переменными 266, функции работы с массивами 267, функция обработки оператора RETURN 268. Объявление модуля содержит имя процедуры мета-языка, которое транслируется в модуль Erlang. Объявление параметров содержит список идентификаторов и типов параметров процедуры мета-языка, которые транслируется в модуль Erlang. Функции работы с переменными - это вспомогательные функции, которые служат для получения или установки значения локальных переменных процедуры в модуле. Функции работы с массивами - это вспомогательные функции, которые служат для получения или установки значения локальных массивов процедуры в модуле, включая обращение к элементам массивов. Функция обработки оператора RETURN необходима для корректного завершения основной функции модуля и передачи возвращаемого значения процедуры, а также для установки значения параметров, переданных по ссылке.
Основная функция модуля начинается с регистрации параметров 269 процедуры в таблице переменных модуля. Далее следует вызов функции инициализации параметров 270. Функция инициализации 270 отвечает за установку значений параметров по фактическим аргументам, переданным в процедуру (в данном случае - в основную функцию модуля Erlang) при ее вызове. Затем идет секция регистрации локальных переменных 271 процедуры в таблице переменных модуля. При регистрации переменные всегда инициализируются значением, либо тем которое указано при объявлении переменной, либо значением по умолчанию для конкретного типа переменной (например, для строковой переменной это - пустая строка, для числовой переменной - 0). Далее следует секция основного кода 272, который генерируется при компиляции исходного кода процедуры мета-языка. В конце функции модуля вызывается функция обработки оператора RETURN 273. Данная функция вызывается всегда, независимо от того - была ли указана данная функция в исходном коде процедуры мета-языка или нет, и даже в том случае, если процедура мета-языка не возвращает значения. Функция обработки RETURN 268 устанавливает значения входных параметров, переданных по ссылке, удаляет таблицу переменных модуля и передает в вызывающую функцию возвращаемое значение процедуры (если оно есть).
Полученный исполняемый бинарный код записывают в системный репозиторий.
Третий этап работы предлагаемого способа заключается в том, что после запуска полученного приложения, посредством сервиса управления сессиями создают сессию и осуществляют поиск сервиса исполнителя с необходимыми мета-данными, инициацию сервиса исполнителя нужными мета-данными, создание процесса исполнителя и вебинтерфейс.
При получении запроса на создание новой сессии 274 (Фиг.15), сервис управления сессий 275 пытается выделить исполнитель для данной сессии, на основе параметров идентификатора схемы и идентификатора модуля (приложения) согласно описанному далее алгоритму. Происходит поиск работающего сервиса исполнителя с указанной схемой (276). Если сервиса исполнителя с нужной схемой нет, то инстанциируется новый сервис исполнителя (280, 282), а затем в сервисе инициализируется нужная схема (283). Если сервис с нужной схемой найден, то далее проверяется - загружен ли в данном сервисе в кэш метаданных нужный модуль (278). Если модуль загружен, то следующая проверка определяет - не превышен ли допустимый предел по количеству одновременно обслуживаемых пользователей в сервисе (279). Если предел уже достигнут, то также выполняется инстанциация нового сервиса исполнителя и инициализация схемы. Если предел по количеству пользователей не достигнут, то в данном сервисе просто создаются процессы исполнителя и веб-интерфейс для сессии, так как модуль в сервисе уже загружен. В случае же, если на предыдущем шаге при проверке модуля оказалось, что он не загружен, то необходимо проверить, не превышен ли в сервисе максимально допустимый предел по емкости кэша (281). Если предел достигнут, то необходимо инстанциировать новый сервис исполнителя. Если же нет, то достаточно загрузить модуль в кэш мета-данных сервиса и далее - создать процессы исполнителя и веб-интерфейс для сессии. На этом процесс создания сессии завершается.
Заключительный шаг работы предлагаемого способа заключается в том, что осуществляют запуск и выполнение бинарного кода из системного репозитория посредством сервиса исполнителя, при этом исполнение бинарного кода осуществляется непосредственно на виртуальной машине Erlang.
На фиг.16 процесс веб-интерфейса 287 является инициатором вызова процедуры на выполнение 288, для чего он обращается с запросом в процесс исполнителя 289. Процесс исполнителя проверяет, загружен ли бинарный модуль (бинарный код) процедуры в процесс исполнителя (290). Если бинарный код не загружен, процесс исполнителя обращается в локальный кэш мета-данных 303, который проверяет, загружен ли бинарный код процедуры в кэш (297). Если бинарный код не загружен в кэш, то сервис исполнителя обращается с запросом к сервису модели 301 для загрузки его из системного репозитория 300, после чего кэш мета-данных может вернуть требуемый код процессу исполнителя. Как только бинарный код процедуры (бинарный модуль) загружен в процесс исполнителя, он передает его на исполнение виртуальной машине Erlang (291). С этого момента исполнение бинарного модуля целиком и полностью контролируется платформой Erlang OTP 292 и кодом бинарного модуля 299. Тем не менее, в коде бинарного модуля могут быть вызовы функций ядра системы 293 или вызовы встроенных функций мета-языка 295, которые обрабатываются основным исполнителем сервиса 294. Фиг.17 иллюстрирует общую схему вычислительного устройства (1700), обеспечивающего обработку данных, необходимую для реализации заявленного решения.
В общем случае устройство (1700) содержит такие компоненты, как: один или более процессоров (1701), по меньшей мере одну память (1702), средство хранения данных (1703), интерфейсы ввода/вывода (1704), средство В/В (1705), средства сетевого взаимодействия (1706).
Процессор (1701) устройства выполняет основные вычислительные операции, необходимые для функционирования устройства (1700) или функциональности одного или более его компонентов. Процессор (1701) исполняет необходимые машиночитаемые команды, содержащиеся в оперативной памяти (1702).
Память (1702), как правило, выполнена в виде ОЗУ и содержит необходимую программную логику, обеспечивающую требуемый функционал.
Средство хранения данных (1703) может выполняться в виде HDD, SSD дисков, рейд массива, сетевого хранилища, флэш-памяти, оптических накопителей информации (CD, DVD, MD, Blue-Ray дисков) и т.п. Средство (1703) позволяет выполнять долгосрочное хранение различного вида информации, например, вышеупомянутых файлов с наборами данных пользователей, базы данных, содержащих записи измеренных для каждого пользователя временных интервалов, идентификаторов пользователей и т.п.
Интерфейсы (1704) представляют собой стандартные средства для подключения и работы с серверной частью, например, USB, RS232, RJ45, LPT, COM, HDMI, PS/2, Lightning, FireWire и т.п.
Выбор интерфейсов (1704) зависит от конкретного исполнения устройства (N00), которое может представлять собой персональный компьютер, мейнфрейм, серверный кластер, тонкий клиент, смартфон, ноутбук и т.п.
В качестве средств В/В данных (1705) в любом воплощении системы, реализующей описываемый способ, должна использоваться клавиатура. Аппаратное исполнение клавиатуры может быть любым известным: это может быть, как встроенная клавиатура, используемая на ноутбуке или нетбуке, так и обособленное устройство, подключенное к настольному компьютеру, серверу или иному компьютерному устройству. Подключение при этом может быть, как проводным, при котором соединительный кабель клавиатуры подключен к порту PS/2 или USB, расположенному на системном блоке настольного компьютера, так и беспроводным, при котором клавиатура осуществляет обмен данными по каналу беспроводной связи, например, радиоканалу, с базовой станцией, которая, в свою очередь, непосредственно подключена к системному блоку, например, к одному из USB-портов. Помимо клавиатуры, в составе средств В/В данных также может использоваться: джойстик, дисплей (сенсорный дисплей), проектор, тачпад, манипулятор мышь, трекбол, световое перо, динамики, микрофон и т.п.
Средства сетевого взаимодействия (1706) выбираются из устройства, обеспечивающий сетевой прием и передачу данных, например, Ethernet карту, WLAN/Wi- Fi модуль, Bluetooth модуль, BLE модуль, NFC модуль, IrDa, RFID модуль, GSM модем и т.п. С помощью средств (1705) обеспечивается организация обмена данными по проводному или беспроводному каналу передачи данных, например, WAN, PAN, ЛВС (LAN), Интранет, Интернет, WLAN, WMAN или GSM.
Компоненты устройства (1700) сопряжены посредством общей шины передачи данных (1710).
В настоящих материалах заявки было представлено предпочтительное раскрытие осуществление заявленного технического решения, которое не должно использоваться как ограничивающее иные, частные воплощения его реализации, которые не выходят за рамки испрашиваемого объема правовой охраны и являются очевидными для специалистов в соответствующей области техники.

Claims

Формула
1 . Облачная система для разработки и исполнения программных веб-приложений, состоящая из микро-сервисов, взаимодействующих между собой посредством программного интерфейса, при этом микро-сервисы представляют собой: сервис мета-модели, включающий репозиторий мета-данных, и сервис интерфейса с мета-моделью, при этом сервис мета-моделей выполнен с возможностью дополнения по меньшей мере одним сервисом по схеме «ведущий - ведомый» для распределения нагрузки при запросах; сервис управления мета-данными, содержащий веб-интерфейс для работы с метаданными, взаимодействующий с сервисом мета-моделей для получения и изменения метаданных, выполненный с возможностью предоставления удобных средств работы с метаданными, составляющими конфигурацию модулей приложений; реализация визуального редактора для построения интерфейсных форм приложения; предоставление визуального редактора исходного кода мета-языка; реализация механизмов работы с версиями описанных на мета-языке мета-данных, предоставление средств перевода мета-данных на другие языки для локализации приложений; сервис кросс - компилятора мета-языка, выполненный с возможностью перевода исходного кода мета-языка, представляющего описание бизнес-логики объекта приложения, в код на языке Erlang, компиляции полученного кода на языке Erlang в бинарный код для виртуальной машины Erlang, который может быть загружен и исполнен сервисом исполнения приложений; сервис управления сессиями, выполненный с возможностью авторизации пользователей, создания сессии, осуществления поиска сервиса исполнителя с необходимыми мета-данными, инициации сервиса исполнителя нужными мета-данными, создания процесса исполнителя и веб-интерфейса, дополнения по меньшей мере одним сервисом по схеме «ведущий - ведомый» для распределения нагрузки при запросах; сервис исполнителя приложений, выполненный с возможностью загрузки и выполнения приложений, сохраненных в системном репозитории в виде набора метаобъектов сложной структуры, включая описание бизнес-логики в виде скомпилированного бинарного кода, в рамках конкретной рабочей сессии пользователя, дополнения по меньшей мере одним сервисом для распределения нагрузки при запросах; сервис интерфейса с внешними данными, выполненный с возможностью работы с внешними базами данных и веб-сервисами; сервис внешнего API системы.
2. Система по п.1 , отличающаяся тем, что кросс- компилятор мета-языка содержит лексер, парсер и генератор кода Erlang.
3. Система по п.1 , отличающаяся тем, что сервис исполнителя приложений содержит ядро исполнителя, кэш мета-данных, веб-интерфейс и процессы исполнения, динамически создаваемые по запросу.
4. Система по п.1 , отличающаяся тем, что сервис интерфейса с внешними данными, выполненный с возможностью работы с внешними базами данных через коннекторы, учитывающие специфику соответствующего источника данных.
5. Система по п.1 , отличающаяся тем, что сервис интерфейса с внешними данными выполненный с возможностью обеспечения унифицированного API работы с данными или веб-сервисами.
6. Способ разработки и исполнения программных веб-приложений, содержащий этапы: описывают объекты приложений в виде мета-данных, хранящихся в репозитории метаданных, посредством сервиса управления мета-данными и сервиса мета-модели, с использованием мета-языка компилирующего типа, при этом описание объектов приложений основано на описании классов мета-модели; описанные мета-данные, представленные в виде набора мета-объектов, содержащих свойства, вложенные объекты, а также исходный код мета-языка, реализующий события и процедуры объекта, преобразовывают в код на языке Erlang, при этом осуществляют сравнение исходного кода мета-языка с грамматикой языка и выдают список лексем распознанного языка, осуществляют синтаксический разбор полученного списка лексем, получают синтаксическое дерево разбора лексем, осуществляют семантический анализ синтаксического дерева разбора лексем, получают преобразованный исходный код мета языка на языке Erlang, осуществляют компилирование полученного кода на языке Erlang в исполняемый бинарный код для виртуальной машины Erlang; записывают полученный исполняемый бинарный код в системный репозиторий; после запуска полученного приложения, посредством сервиса управления сессиями создают сессию и осуществляют поиск сервиса исполнителя с необходимыми мета-данными, инициацию сервиса исполнителя нужными мета-данными, создание процесса исполнителя и веб-интерфейс; осуществляют запуск и выполнение бинарного кода из системного репозитория посредством сервиса исполнителя, при этом исполнение бинарного кода осуществляется непосредственно на виртуальной машине Erlang.
7. Способ по п.6, отличающийся тем, что мета-модель содержит классы, субклассы, атрибуты, поведение, типы и суб-типы.
8. Способ по п.6, отличающийся тем, что описание классов объектов включает добавление новых классов и наследование существующих классов.
PCT/RU2020/000595 2020-11-09 2020-11-10 Система и способ создания и исполнения высоко масштабируемых облачных приложений Ceased WO2022098253A1 (ru)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202080107056.0A CN116391172B (zh) 2020-11-09 2020-11-10 用于创建和执行高度扩展的云应用的系统和方法
EP20960940.3A EP4242830A4 (en) 2020-11-09 2020-11-10 System and method for creating and executing highly scaled cloud applications

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
RU2020136739 2020-11-09
RU2020136739A RU2020136739A (ru) 2020-11-09 Система и способ создания и исполнения высоко масштабируемых облачных приложений

Publications (1)

Publication Number Publication Date
WO2022098253A1 true WO2022098253A1 (ru) 2022-05-12

Family

ID=81458123

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2020/000595 Ceased WO2022098253A1 (ru) 2020-11-09 2020-11-10 Система и способ создания и исполнения высоко масштабируемых облачных приложений

Country Status (3)

Country Link
EP (1) EP4242830A4 (ru)
CN (1) CN116391172B (ru)
WO (1) WO2022098253A1 (ru)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115640045A (zh) * 2022-12-26 2023-01-24 卓望数码技术（深圳）有限公司 基于领域驱动设计的低代码开发平台及业务系统创建方法
CN119166124A (zh) * 2024-11-15 2024-12-20 北方实验室(沈阳)股份有限公司 一种基于bnf范式的数据总线服务代码生成系统

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118296673B (zh) * 2024-04-01 2025-10-24 深圳泊松软件技术有限公司 一种几何建模内核并行编辑方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7735062B2 (en) 2005-01-21 2010-06-08 Outsystems—Software Em Rede, S.A. Software development system and method
US20130104100A1 (en) * 2011-10-21 2013-04-25 Sap Ag Scripting Language for Business Applications
US10324690B2 (en) 2009-10-14 2019-06-18 Vermeg Services Sarl Automated enterprise software development

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8255888B2 (en) * 2003-09-30 2012-08-28 Sap Ag API derivation and XML schema derivation for developing applications
CN101464799A (zh) * 2009-01-16 2009-06-24 天津大学 基于可视化建模的mpi并行程序设计系统及框架代码自动生成方法
CN102063324B (zh) * 2010-12-31 2014-04-02 杭州依赛通信有限公司 一种实现自动化编程的方法及系统
US8997070B2 (en) * 2011-12-15 2015-03-31 Sap Se Extension mechanism for scripting language compiler
EP3049920A1 (de) * 2013-09-27 2016-08-03 Rudolf Markus Petri Verfahren und einrichtung zur automatisierten erzeugung und bereitstellung wenigstens einer softwareanwendung
US11055451B2 (en) * 2015-10-28 2021-07-06 Qomplx, Inc. System and methods for multi-language abstract model creation for digital environment simulations
KR102092721B1 (ko) * 2016-03-23 2020-04-23 포그혼 시스템스 인코포레이티드 실시간 데이터플로우 프로그래밍에서 패턴 구동형 반응의 구성
US20190261433A1 (en) * 2017-06-22 2019-08-22 William Jason Turner Software architecture for iot device collector

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7735062B2 (en) 2005-01-21 2010-06-08 Outsystems—Software Em Rede, S.A. Software development system and method
US10324690B2 (en) 2009-10-14 2019-06-18 Vermeg Services Sarl Automated enterprise software development
US20130104100A1 (en) * 2011-10-21 2013-04-25 Sap Ag Scripting Language for Business Applications

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4242830A4

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115640045A (zh) * 2022-12-26 2023-01-24 卓望数码技术（深圳）有限公司 基于领域驱动设计的低代码开发平台及业务系统创建方法
CN115640045B (zh) * 2022-12-26 2023-04-07 卓望数码技术（深圳）有限公司 基于领域驱动设计的低代码开发平台及业务系统创建方法
CN119166124A (zh) * 2024-11-15 2024-12-20 北方实验室(沈阳)股份有限公司 一种基于bnf范式的数据总线服务代码生成系统

Also Published As

Publication number Publication date
CN116391172A (zh) 2023-07-04
EP4242830A1 (en) 2023-09-13
CN116391172B (zh) 2024-09-06
EP4242830A4 (en) 2024-09-11

Similar Documents

Publication Publication Date Title
US11789715B2 (en) Systems and methods for transformation of reporting schema
US12524217B2 (en) Systems and methods for automated retrofitting of customized code objects
US10698682B1 (en) Computerized software development environment with a software database containing atomic expressions
CN102171679B (zh) 用于声明性编程语言的基于树的有向图编程结构
US8850414B2 (en) Direct access of language metadata
US20100088686A1 (en) Programming language with extensible syntax
US11294665B1 (en) Computerized software version control with a software database and a human database
US11550556B1 (en) Efficient semantic analysis of program code
US20100088672A1 (en) Compact syntax for data scripting language
US20120198416A1 (en) Support for heterogeneous database artifacts in a single project
CN116391172B (zh) 用于创建和执行高度扩展的云应用的系统和方法
US9292586B2 (en) System and method for synchronizing a repository with a declarative defintion
US20090119641A1 (en) Programming language extensions in structured queries
US12182551B2 (en) Using a semantic tree of a compiler to execute a semantic code query against source code
US11921785B2 (en) Inline graph algorithm execution with a relational SQL engine
CN115794858A (zh) 查询语句处理方法、装置、设备及存储介质
EA046340B1 (ru) Система и способ создания и исполнения высокомасштабируемых облачных приложений
Sacco Beginning Spring Data
CN114416050B (zh) Swift代码的处理方法、装置、电子设备及存储介质
CN120266105A (zh) 在rdbms中全面支持json模式的技术
CN121255171A (zh) 一种实现模型与代码双向转换系统
RU2020136739A (ru) Система и способ создания и исполнения высоко масштабируемых облачных приложений
Wen et al. Translation of Java-Embedded Database Queries with a Prototype Implementation for LINQ
Can The evolution of software engineering From FORTRAN to LLMs
Kövári Reactive Data Federation Platform

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20960940

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202317035272

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2020960940

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020960940

Country of ref document: EP

Effective date: 20230609

WWW Wipo information: withdrawn in national office

Ref document number: 2020960940

Country of ref document: EP