idnits 2.17.1 draft-yangcan-core-web-software-built-in-cloud-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2018) is 1983 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6690' is defined on line 1051, but no explicit reference was found in the text == Unused Reference: 'RFC7705' is defined on line 1055, but no explicit reference was found in the text == Unused Reference: 'RFC8206' is defined on line 1060, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 1067, but no explicit reference was found in the text == Unused Reference: 'RFC3347' is defined on line 1071, but no explicit reference was found in the text == Unused Reference: 'RFC6208' is defined on line 1077, but no explicit reference was found in the text == Unused Reference: 'RFC7322' is defined on line 1082, but no explicit reference was found in the text == Unused Reference: 'RFC7491' is defined on line 1086, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Yang, Ed. 3 Internet-Draft SY. Pan, Ed. 4 Intended status: Standards Track South China University of Technology 5 Expires: April 26, 2019 HB. Sun 6 Inspur 7 KM. Qu 8 NetEase,Inc 9 GQ. Han 10 South China University of Technology 11 October 23, 2018 13 The Standards on a Cloud Service Framework and Protocol for 14 Construction, Migration, Deployment,and Publishing of Internet-Oriented 15 Scalable Web Software Systems in Non-Programming Mode 16 draft-yangcan-core-web-software-built-in-cloud-00 18 Abstract 20 This draft mainly focuses on the scalable architecture and publishing 21 protocol standard of REST-based SAAS cloud model Web software in non- 22 programming mode, stipulates the data structure pattern and data 23 exchange protocol for the construction and release of REST-based 24 scalable Web cloud service software systems. Using the standardized 25 framework and protocol, users can easily and quickly design their own 26 software systems in the cloud, transfer and release data, which may 27 make conventional software development so ease to improve the 28 efficiency of complex database construction and server management. 29 Without having to write codes under the standard framework, users can 30 get consistent style background to create service, rapidly develop 31 web application systems with the function of standard data management 32 and data maintenance, and directly publish the software system to the 33 end users of the Internet for access and use. And provide RESTful 34 APIs to facilitate external access to required service resources. 35 The framework can thus greatly shorten the software development life 36 cycle, and save a great deal of development cost and maintenance 37 overhead. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on April 26, 2019. 56 Copyright Notice 58 Copyright (c) 2018 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 4 75 3. Technical Specific Implementation Standards . . . . . . . . . 6 76 3.1. System Architecture Diagram . . . . . . . . . . . . . . . 6 77 3.2. SAAS Cloud Platform Related Implementation Standards . . 8 78 3.2.1. Application Management Module . . . . . . . . . . . . 8 79 3.2.2. End User Management Module . . . . . . . . . . . . . 8 80 3.2.3. Relationship Management Module between the End User 81 and the Application . . . . . . . . . . . . . . . . . 8 82 3.2.4. Resource Management Module . . . . . . . . . . . . . 9 83 3.2.5. Fine-grained Access Rights Management Module . . . . 9 84 3.2.6. Ways of Accessing Cloud Storage Resources . . . . . . 10 85 3.2.7. Format of Describing the Structured Data URI . . . . 10 86 3.2.8. Contents of the Ways of Accessing Cloud Storage 87 Resources . . . . . . . . . . . . . . . . . . . . . . 10 88 3.3. Web Software Framework Related Implementation Standards . 11 89 3.3.1. System Administrator View . . . . . . . . . . . . . . 11 90 3.3.2. User View . . . . . . . . . . . . . . . . . . . . . . 12 91 3.4. Implementation Standards on Construction Methods of Web 92 Software . . . . . . . . . . . . . . . . . . . . . . . . 12 93 3.4.1. System Requirements Table and Data Record Exchange 94 Table . . . . . . . . . . . . . . . . . . . . . . . . 13 95 3.4.1.1. System Requirements Table . . . . . . . . . . . . 13 96 3.4.1.2. Data Record Exchange Table . . . . . . . . . . . 14 98 3.4.2. Steps of Reading System Requirements Table . . . . . 14 99 3.4.3. Steps of Analyzing System Requirements Table . . . . 15 100 3.4.4. Contents of Modules for Users . . . . . . . . . . . . 15 101 3.4.5. Steps of Principle of Constructing Web Software 102 System . . . . . . . . . . . . . . . . . . . . . . . 17 103 3.4.6. Steps of Injecting Data Records into Web Software 104 System . . . . . . . . . . . . . . . . . . . . . . . 19 105 3.4.7. Submission of System Requirements Table . . . . . . . 19 106 3.4.8. Submission of Data Exchange Table . . . . . . . . . . 19 107 3.5. Implementation Standards on Web Software Deployment . . . 20 108 3.5.1. System Deployment . . . . . . . . . . . . . . . . . . 20 109 3.5.2. Model Deployment . . . . . . . . . . . . . . . . . . 20 110 3.5.3. User Deployment . . . . . . . . . . . . . . . . . . . 20 111 3.5.4. User Group Deployment . . . . . . . . . . . . . . . . 21 112 3.6. Implementation Standards on Web Software Migration . . . 21 113 3.6.1. Model Migration . . . . . . . . . . . . . . . . . . . 21 114 3.6.2. User Migration . . . . . . . . . . . . . . . . . . . 21 115 3.6.3. User Group Migration . . . . . . . . . . . . . . . . 22 116 3.6.4. User Group Deployment . . . . . . . . . . . . . . . . 22 117 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 118 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 119 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 120 6.1. Normative References . . . . . . . . . . . . . . . . . . 23 121 6.2. Informative References . . . . . . . . . . . . . . . . . 23 122 6.3. URL References . . . . . . . . . . . . . . . . . . . . . 24 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 125 1. Introduction 127 With the rise of the Internet (especially the mobile Internet), 128 Internet-oriented Web services become the mainstream of software 129 architecture in the information age, but sophisticated web database 130 construction and system management bring great increase of cost of 131 software development, operation and maintenance. Whenever a system 132 needs to be upgraded or updated, a large amount of coding workload is 133 inevitable. With the rapid development of cloud computing and the 134 growing popularity of SAAS, more and more users intend to migrate 135 their software systems and deploy them to the cloud to get the cloud 136 service resources they need. At the same time, there exists a common 137 abstract model in the web information system, the system takes data 138 management and maintenance as the core content, we can therefore 139 extract its common features and provide a series of standards and 140 requirements for the flexible construction and agile release of web 141 software. In conclusion, cloud-oriented software migration and 142 deployment technology has very important theoretical and practical 143 significance. This draft focuses on the implementation standard of a 144 cloud-oriented software migration and deployment technology, through 145 which users can generate their own software system and migrate and 146 deploy to the cloud by simple operation. At the same time, it also 147 provides an open RESTful API for users to obtain the required service 148 resources through requests.From the development point of view, this 149 kind of technology can transfer and deploy the software system 150 conveniently and quickly, subtract the tedious and large number of 151 coding work, and avoid repeated development. From the perspective of 152 use, the convenient operation of this technology reduces the learning 153 cost of users, has a strong usability, and has a unified front-end 154 style. Users can access their own proprietary software system 155 through the Internet, which is easy to promote.It also provides a 156 expressive RESTful API that gives users the flexibility to adapt to 157 complex and changing needs. 159 2. Definitions and Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC 2119 [RFC2119]. 165 The following definitions are for terms used in the context of this 166 document. 168 o "SAAS": SAAS is an abbreviation of Software-as-a-Service.It is a 169 model for providing software over the Internet. The manufacturer 170 deploys the application software on its own server, and customers 171 can purchase the required application services according to their 172 actual needs through the Internet, pay the cost to the 173 manufacturers according to the quantity of service and the length 174 of the order, and obtain the services provided by the 175 manufacturers through the Internet. 177 o "Cloud Computing": Cloud computing is a pay-per-use model that 178 provides available, convenient,on-demand network access, the user 179 enters a configurable computing resource sharing pool(resources 180 include network, server, storage, application software, services), 181 these resources can be provided quickly, with little 182 administrative effort or little interaction with service 183 providers. 185 o "Cloud Services": Cloud services are models of the addition, use, 186 and delivery of Internet-based related services, often involving 187 the provision of dynamically scalable and often virtualized 188 resources over the Internet. 190 o "Cloud Storage": Cloud storage is a network computer data storage 191 model. Data is stored on multiple virtual hosts and is generally 192 held by a third party rather than on a dedicated server. 194 o "Cloud Migration": Cloud migration refers to the migration of 195 enterprises from traditional platforms to cloud platforms. 196 Compared with traditional application platforms, cloud computing 197 platforms have the advantages of powerful computing power, storage 198 capacity, diverse services and high cost performance. 200 o "Software Migration": This draft is aimed at migrating existing 201 software systems that meet user requirements to a lightweight 202 information management software migration cloud service platform. 203 Systems migrated to the platform can be accessed over the 204 Internet. 206 o "Software Deployment": This draft is aimed at rapidly deploying a 207 new software system that meets user requirements on the 208 lightweight information management software migration cloud 209 service platform. The software system can be accessed through the 210 Internet. 212 o "Content Management": Using advanced information technology to 213 help users create, store, transmit, publish, apply and analyze 214 content, and use computer technology to evolve and extract it to 215 create more valuable content for enterprises and individuals. 217 o "NoSQL": Do not use SQL database. Such databases refer to other 218 types of databases other than traditional relational databases. 219 This type of database is more consistent and can handle very large 220 and high concurrent data. The techniques in this draft use NoSQL 221 to provide storage. 223 o "Distributed DataBase": It is a distributed file storage-based 224 database designed to provide a scalable, high-performance data 225 storage solution for web applications. 227 o "Web API": Web Application Programming Interface. An application 228 programming interface is an interface that allows users to access 229 information from another service and integrate the service into 230 its own application. 232 o "REST": Representational State Transfer. A software architecture 233 style,the service is abstracted into a set of discrete resources. 234 Through the HTTP protocol, different request methods(POST, DELETE, 235 PUT, GET) add, delete, modify, and query the resources specified 236 by the URI. 238 o "Restlet Framework": The Restlet project provides a lightweight 239 and comprehensive framework for "building a mapping between REST 240 concepts and Java classes". It can be used to implement any kind 241 of RESTful system, not just RESTful web services. 243 o "Multi-Tenant Technology": A software architecture technology, 244 whose key goal is to share the same system or program components 245 in a multi-user environment and to ensure logical isolation of 246 data between users. 248 o "Privilege Control": The permission control used in this draft 249 refers to adopting the role-based access control principle and the 250 group configuration permission template method to achieve the 251 separation of the authority control from the business logic. 253 o "Certification Security": Authentication security is part of the 254 security of the system. The authentication security system used 255 in this draft adopts the Cookie mechanism on the client side and 256 the Session mechanism on the server side, and uses the MD5 message 257 digest algorithm to achieve the authentication security of the 258 entire session. 260 o "Non-Programming Mode": Non-Programming Mode is defined as a kind 261 of software development mode in this draft, referring to develop a 262 software without any codes. 264 3. Technical Specific Implementation Standards 266 The main goal of this software migration deployment technology is to 267 help users quickly deploy a specific software system of their own on 268 a designated lightweight information management software development 269 and migration cloud service platform, or to migrate the user's 270 traditional software systems to the designated lightweight 271 information management software migration cloud service platform. We 272 propose an implementation standard for this technology so that users 273 who need it can use it for software development, migration, and 274 deployment. 276 Note: The cloud platforms described in the draft are all designated 277 lightweight information management software development and migration 278 cloud service platforms. The cloud platform administrator refers to 279 the administrator of the cloud service platform for the designated 280 lightweight information management software. The system 281 administrator is the administrator of the software system on the 282 cloud platform, also known as the tenant. The user is a normal user 283 under each software system, and is lower than the system 284 administrator level user. 286 3.1. System Architecture Diagram 287 Figure 1 shows the working diagram of the framework. 289 +-------------+ +----------------+ 290 | | | Read | 291 | System | (1) | System | 292 | Requirement |-------->| Requirements | 293 | Information | | |------ 294 | | | +----------+ | | 295 +-------------+ | | GWDI | | | 296 | +----------+ | | 297 (2) +----------------+ | 298 ----------------------------------------------------| 299 | 300 | +---------------------------+ +----------------------+ 301 | | | | | 302 | | Analysis and verification | (3) | Automate the | 303 |---->| of the requirements |----->| construction of the | 304 | information obtained. | | software system and | 305 | | | inject it into the | 306 +---------------------------+ |corresponding software| 307 | framework. | 308 +----------------------+ 310 Figure 1:Reference Architecture 312 The standard requires a general Web Data Interface (GWDI). The 313 system workflow is as follows: 315 Step (1) Requirements Submission: The user fills in the software 316 system requirements information in the software system 317 requirements table, and submits the request to GWDI through the 318 browser. 320 Step (2) Demand Acquisition: GWDI obtains the software system 321 requirements table submitted by the user, and reads the relevant 322 information related to the requirements in the software system 323 requirements table. 325 Step (3) Information Verification: GWDI analyzes and verifies the 326 relevant information about the system requirements obtained. 328 Step (4) System Generation: Automatically construct a Web software 329 system based on the verified requirements related information, and 330 inject the system into the cloud platform. 332 3.2. SAAS Cloud Platform Related Implementation Standards 334 The technology MUST build a SAAS cloud platform that provides content 335 management and data storage capabilities that can be rented to 336 multiple tenants who are application developers. The platform 337 includes the following modules: 339 o Application Management Module 341 o End User Management Module 343 o Relationship Management Module between the End User and the 344 Application 346 o Resource Management Module 348 o Fine-grained Access Rights Management Module 350 3.2.1. Application Management Module 352 The application management module of the platform MUST support 353 applications developed by management tenants, including: 355 o Adding application 357 o Deleting application 359 3.2.2. End User Management Module 361 The end-user management module of the platform MUST support the 362 management of end-user information for all applications of the 363 tenant, including: 365 o End-user registration 367 o The end user changes the password 369 o End-user logout 371 3.2.3. Relationship Management Module between the End User and the 372 Application 374 The relationship management module between the end user of the 375 platform and the application MUST support the management of the use 376 relationship between the end user and the application, including: 378 o Establishment of user relationship 379 o Elimination of the use relationship 381 3.2.4. Resource Management Module 383 The resource management module of the platform MUST include at least: 385 o Structured data resource management module 387 The structured data resource management module is used to 388 manage the tenant's structured data in the cloud platform, 389 including management of structured data table information, 390 management of structured data table data resources. Each row 391 of structured data resources will belong to a unique table, and 392 will also belong to a unique user. 394 o File resource management module 396 The file resource management module is used to manage the file 397 resources of the tenant in the cloud platform. Each file 398 resource will belong to the only application and the only user. 400 3.2.5. Fine-grained Access Rights Management Module 402 The fine-grained access authority management module of the platform 403 MUST support the management of end-user access rights to fine-grained 404 resources within the tenant, including: 406 o Structured form row data resource authority management module 408 The structured form row data resource authority management 409 module includes: 411 + For each structured table, configure the application of the 412 structured table; 414 + For each structured table, configure the access rights of 415 the end user of the application to which the structured 416 table belongs; 418 + For each structured table, configure the access rights of 419 the end user of the application that does not use the 420 structured table; 422 + For each structured table, configure the access rights of 423 the end user to the single-row data resources that do not 424 belong to the structured table. 426 o Single file resource authority management module 427 The single file resource authority management module includes: 429 + For each application, configure the access rights of the end 430 user using the application to file resources within the 431 application; 433 + For each application, configure the access rights of the end 434 user who does not use the application to the file resources 435 within the application; 437 + For each application, configure end-user access to files 438 that are not part of the application. 440 3.2.6. Ways of Accessing Cloud Storage Resources 442 The platform SHOULD be able to access cloud storage resources in the 443 following ways: 445 o Through the POST, DELETE, PUT, GET requests initiated by REST API, 446 the structured data resources specified by structured data URI are 447 added, deleted, modified and queried. 449 o Through the POST, DELETE and GET requests initiated by REST API, 450 the file resources specified by file URI are uploaded, deleted and 451 downloaded. 453 3.2.7. Format of Describing the Structured Data URI 455 The platform adopts the access method of the resources of the cloud 456 storage platform described in 3.2.6, and it SHOULD be able to 457 describe the structured data URI in the following format: 459 o /{structure table name}[/{filtered fields + combined 460 form}/{conditions for filtered fields}]; 462 Where, the structure table name is equivalent to the table name to be 463 operated in the SQL statement. The contents in the brackets ([ ]) 464 are optional: "NONE", which means all resources in the collection are 465 manipulated. "YES", it represents an operation on a particular 466 resource in the collection, equivalent to the WHERE clause in SQL. 468 3.2.8. Contents of the Ways of Accessing Cloud Storage Resources 470 The platform adopts a cloud storage platform resource access method 471 described in 3.2.6, which SHOULD include: 473 o Initiate PUT requests for structured data resources to modify the 474 data resources specified by the URI, including: overwrite and 475 modify the specified fields, incremental changes to specified 476 fields. 478 o Initiate GET requests for structured data resources to query the 479 data resources specified by the URI. Specific return formats can 480 be set for the data resources that are queried, including: return 481 by the specified field, return by the specified information page, 482 and return by the specified field filtering. 484 3.3. Web Software Framework Related Implementation Standards 486 The standard MUST support a Web software framework that supports the 487 software-as-a-service SAAS cloud pattern, where the software systems 488 generated by the Web software framework are automatically deployed 489 and distributed. 491 The Web software framework should specifically include the 492 following views: 494 3.3.1. System Administrator View 496 o User Management 498 This view SHOULD be able to manage the user information of the 499 Web software system, including the functions of adding users, 500 removing users, adding user group information for users, and 501 deleting user group information for users. 503 o User Group Management 505 This view SHOULD be able to manage the user group information 506 of the Web software system, including adding user groups, 507 deleting user groups, adding user information for user groups, 508 and deleting user information for user groups. 510 o Model Management 512 This view SHOULD be able to manage the model information of the 513 Web software system, including adding model information, 514 deleting model information, adding model field information, 515 deleting model field information, modifying model field 516 information, and assigning different access rights to different 517 user groups for the model. 519 3.3.2. User View 521 o Data Management 523 This view SHOULD be able to manage the data table records of 524 the Web software system, including adding data records, 525 deleting data records, modifying data records, searching data 526 records, and obtaining all data records. 528 o Data Statistics 530 This view SHOULD be able to make statistics on the data table 531 records of the Web software system, including functions such as 532 record statistics, maximum statistics, minimum statistics, and 533 average statistics for data table integral fields. 535 o Import Excel and Other Format Tables 537 This view SHOULD be able to import data from Excel tables 538 (sheets) and other format tables into the corresponding tables 539 of the Web software system. 541 o Export Excel and Other Formats 543 This view SHOULD be able to export data from the table of the 544 Web software system to Excel tables (sheets) and tables in 545 other formats. 547 o Advanced Search 549 This view SHOULD be able to perform multiple logical 550 combinatorial searches for multiple fields of the table to 551 query the record information that satisfies the search 552 criteria. 554 3.4. Implementation Standards on Construction Methods of Web Software 556 This standard SHALL support a table-driven software system automatic 557 construction method within cloud mode, which is characterized by 558 table submission, reading and verification, a Web software generation 559 framework and a set of Web software generation workflow, in which the 560 Web software generation framework should be the framework described 561 in requirement 3.3. 563 3.4.1. System Requirements Table and Data Record Exchange Table 565 The table described in this method MUST include the system 566 requirements table and the data record exchange table: 568 3.4.1.1. System Requirements Table 570 The system requirements table MUST include the following parts: 572 o System Administrator Information Section 574 * System administrator ID 576 * System administrator password 578 * System title 580 o User Group Information Section (multiple user groups can be 581 customized in this table according to requirements) 583 * User group ID 585 o User Information Section (multiple users can be customized in this 586 table according to requirements) 588 * User ID 590 * The user name 592 * User password 594 * The user belongs to the group (if filled in, it must be the 595 item contained in the user group ID of the user group 596 information section) 598 o Model Information Section (multiple models can be customized in 599 this table according to requirements) 601 * Read and write permission of the user group to which it belongs 603 Permissions include: readable and writable, readable and 604 unwritable, unreadable and unwritable 606 * Other users' read and write rights 608 Permissions include: readable and writable, readable and 609 unwritable, unreadable and unwritable 611 * Model name 613 * Subscriber ID (must be the item contained in the user ID in the 614 user information section) 616 * Group ID (must be the item contained in the user group ID of 617 the user group information section) 619 * Field type 621 Field types include: Text, Float, Integer, Link, Date, 622 Datetime, Boolean. 624 * Field name 626 * Whether empty is allowed 628 Values include: TRUE and FALSE. Where TRUE means allowed to 629 be empty; 631 3.4.1.2. Data Record Exchange Table 633 The data record exchange table MUST include the following parts: 635 o Field information section (all field names of the model to be 636 exchanged for data records can be set according to requirements) 638 o Data records section (all data records that need to be injected 639 into the model can be added as required) 641 3.4.2. Steps of Reading System Requirements Table 643 In the workflow of the Web software generation principle of this 644 method, it MUST include the following steps: 646 1. Using the traversal unit of system requirements table to read 647 through each cell of the system requirements table. 649 2. Using the reading unit of system administrator information to 650 read system administrator ID, system administrator password, 651 system title and other information when traversing system 652 administrator information. 654 3. Using the reading unit of user group information to read user 655 group ID information when traversing user group information. 657 4. Using the reading unit of user information to read user ID, user 658 name, user password, user group ID (the user group ID must be 659 included in user group information) when traversing user 660 information. 662 5. Using the reading unit of model information to read the 663 information such as the reading and writing rights of the user 664 group to which it belongs, the reading and writing rights of 665 other users, the model name, the inputting ID, the group ID to 666 which it belongs, the field type, the field name and whether it 667 is allowed to be empty, when traversing the model information. 669 3.4.3. Steps of Analyzing System Requirements Table 671 In the workflow of Web software generation of this method, it MUST 672 include the analysis and verification flow of the relevant 673 information about the system requirements acquired by the Web 674 software framework, including the following parts: 676 1. Data type and format validation for information related to system 677 requirements obtained. 679 2. As for the user information part of the system requirements 680 table, if the user's group item is not empty, the framework 681 should judge whether the filled value is included in the user 682 group information part of the system requirements table. 684 3.4.4. Contents of Modules for Users 686 The workflow of the Web software generation principle of this method 687 MUST include the module for users to use in the cloud environment 688 where the corresponding Web software framework is located, which must 689 include the following contents: 691 1. The framework should use the API of dealing with system 692 administrator information in the Read_Demand class to read the 693 system administrator section in the software system requirement 694 table,each cell of which will be read successively, and then 695 register the software system using the super administrator 696 privileges with its ID and password and the system name, and 697 further create relevant database entities of the software system 698 in the underlying database of the Web software framework. At the 699 same time, such four collections should be create in the database 700 as user group, user, schema, and data. 702 2. The framework should use the API of dealing with user group 703 information in the Read_Demand class to read the user group 704 information in the software system requirement table, each cell 705 of which be read successfully, and generate json-formatted 706 strings based on the group ID information obtained, and then 707 insert them into the user group set of database entities created 708 in 1. 710 3. The framework should use the API of dealing with user information 711 in the Read_Demand class to read the user information in the 712 software system requirement table, each cell of each row of which 713 be read successfully, and generate json-formatted strings 714 according to the user information obtained, and then insert them 715 into the user set of database entities created in 1. 717 4. The framework should read the model information section of the 718 system requirements table through the API used to process model 719 information in the requirements table reading class (Read_Demand 720 class), read through the filled content in the model information 721 cells, generate json-formatted strings based on model 722 information, and insert them into the schema set of database 723 entities created in 1. 725 5. The framework should operate the user group data in the group set 726 of database entities in the underlying database through the user 727 group management class (Manage_Group) and return the results to 728 the interface of the Web software framework. The Manage_Group 729 class implements the GManage_Group interface defined in the Web 730 software framework. 732 6. The framework should operate the user data in the user set of the 733 database entity in the underlying database through the user 734 management class (Manage_User) and return the results to the 735 interface of the Web software framework. The Manage_User class 736 implements the GManage_User interface defined in the Web software 737 framework. 739 7. The framework should operate the model data in the schema set of 740 database entities in the underlying database through the model 741 management class (Manage_Schema) and return the results to the 742 interface of the Web software framework. The Manage_Schema class 743 implements the GManage_Schema interface defined in the Web 744 software framework. 746 8. The framework should operate the data records in the data set of 747 database entities in the underlying database through the data 748 management class (Manage_Data) and return the results to the 749 interface of the Web software framework. The Manage_Data class 750 implements the GManage_Data interface defined in the Web software 751 framework. 753 3.4.5. Steps of Principle of Constructing Web Software System 755 This method MUST satisfy the working principle of constructing Web 756 software system automatically according to the system demand table. 757 The principle includes the following steps: 759 1. The customer shall fill in the system requirements form 760 described in 3.4.1.1 according to the requirements. 762 2. The Web software framework obtains the system requirements table 763 uploaded by the customer in 1, and verifies whether the system 764 requirements table conforms to the verification standard. If it 765 does not conform to the verification standard, it prompts the 766 user to have the wrong format, please re-upload it. 768 3. The Web software framework reads the system administrator 769 information in the system requirements table. 771 4. Create a new system in the corresponding Web software framework 772 according to the information read in 3, in which the 773 administrator of the system is the system administrator in 3, 774 and the system name is the system name in 3. 776 5. The Web software framework determines whether there is any part 777 of user group information in the system requirements table. If 778 not, it jumps to 8; if there is, it goes 6. 780 6. The Web software framework reads information about user groups 781 in the system requirements table, including user group IDs. 783 7. According to the user group information read in 6, the user 784 group is generated in the system created in 4, and the relevant 785 information of the user group is the relevant information read 786 in 6. 788 8. The Web software framework determines whether there is any 789 relevant information about users in the system requirements 790 table. If there is no information about users, it will jump to 791 11; if there is, it will go to 9. 793 9. The Web software framework reads relevant information of users 794 in the system requirements table, including user ID, user name, 795 user password, and user group. 797 10. The Web software framework generates users in the system created 798 in 4 according to the user information read in 9, and the 799 relevant information of the users is the information read in 9. 801 11. The Web software framework determines whether the relevant 802 information of the model part exists in the system requirements 803 table. If it does not, it will jump to 20, and if it does, it 804 will go to 12. 806 12. The Web software framework reads the number of models in the 807 system requirements table and assigns a current count of 0, then 808 go to 13. 810 13. The Web software framework reads the relevant information of the 811 model in the system requirements table, including the model 812 name, model entry person, model group ID, group permissions, 813 other user rights and other information. 815 14. According to the information related to the model read in 13, 816 the model is generated in the system created in 4. The model 817 name, model entry person, group ID of the model, group 818 permission and other user rights are the information read in 13. 820 15. The Web software framework determines whether there is any 821 information related to the structural fields in the model in the 822 system requirements table. If there is no information, it will 823 jump to 18; if there is, it will go to 16. 825 16. The Web software framework reads the relevant information of 826 structural fields in the model in the system requirements table, 827 including obtaining the name of structural fields of the model, 828 field types, whether to allow null identification, default 829 values and alternative values, etc. 831 17. The Web software framework creates model fields in the specified 832 model according to the relevant information of structural fields 833 in the model read in 16, and the field information is the 834 information read in 16. 836 18. Current model number +1. 838 19. The Web software framework determines whether the current count 839 is less than the number of models read in 12; if it is less 840 than, it will jump back to 13; if it is not less than, it will 841 go to 20. 843 20. The Web software framework generates the target Web software 844 system. 846 3.4.6. Steps of Injecting Data Records into Web Software System 848 The workflow of the Web software generation principle of this method 849 MUST include the workflow of automatically injecting data records 850 into the Web software system according to the data record exchange 851 table, including the following steps: 853 1. The customer shall fill in the data record exchange form as 854 required. 856 2. The Web software framework gets the data record exchange table 857 uploaded by the customer, and verifies whether the data record 858 exchange form meets the requirements of the data record exchange 859 form. If it does not meet the requirements, it prompts the user 860 to have the wrong format, please re-upload it. 862 3. The Web software framework reads the model field information in 863 the data record exchange table. 865 4. The Web software framework determines the required data exchange 866 model according to the model field information read in 3. 868 5. The Web software framework reads the data record information in 869 the data record exchange table line by line and injects it into 870 the model determined in 4 successively. 872 3.4.7. Submission of System Requirements Table 874 The submission of the system requirements table SHALL include: 876 1. Online submission: according to the Web form format provided by 877 the Web software generation framework, users fill in the system 878 requirements information online and submit it to the Web software 879 generation framework; 881 2. Offline submission: according to the offline form format template 882 agreed by the Web software generation framework, users fill in 883 the required software system demand information offline and 884 submit it to the Web software generation framework by file 885 upload. 887 3.4.8. Submission of Data Exchange Table 889 The submission of the data exchange table SHALL include: 891 1. Online submission: after the user constructs a new Web software 892 system according to the Web software generation framework, the 893 user enters data into the Web page through the newly generated 894 Web software system, enters data information online and delivers 895 it to the generated software system; 897 2. Offline submission: after the user constructs a new Web software 898 system according to the Web software generation framework, the 899 user enters the data record information offline and submits it to 900 the generated software system through the data record exchange 901 table template format provided by the newly generated Web 902 software system by means of file upload. 904 3.5. Implementation Standards on Web Software Deployment 906 This framework MUST support the rapid deployment of a new set of 907 software systems that meet the requirements on the cloud platform, 908 where the deployment of software systems should support the 909 deployment of the following modules: 911 3.5.1. System Deployment 913 This framework SHOULD support two ways to deploy a system: 915 o Supports registering users' own systems through cloud platform 916 administrators to create system administrators belonging to users. 918 o Supports users to register their own system through cloud platform 919 and register their own system administrator. 921 3.5.2. Model Deployment 923 This framework SHOULD enable system administrator users to enter 924 their own software system and deploy the created models on the cloud 925 platform, where the created models are configured as follows: 927 o Model name, input personnel, and user group read and write 928 permission are necessary when the model is created. 930 o Field name, field type, whether the field is allowed to be empty, 931 field default value, and field alternative value in the model are 932 optional fields for creating the model. 934 3.5.3. User Deployment 936 This framework SHOULD support to create new users affiliated to the 937 software system created by a system administrator user on the cloud 938 platform, where the creation of users is configured with user ID, 939 user nickname, and user password. 941 3.5.4. User Group Deployment 943 This framework SHOULD support to create new users affiliated to the 944 software system created by a system administrator user on the cloud 945 platform, where the creation of user groups is configured as follows: 947 o The user group ID is necessary. 949 o It is optional to select many users into the user group, but one 950 user group must have one use at least. 952 3.6. Implementation Standards on Web Software Migration 954 This framework SHOULD support the migration of existing software 955 systems that meet the given requirements to the cloud platform, where 956 the migration of software systems should support the migration of the 957 following modules: 959 3.6.1. Model Migration 961 This framework SHOULD support the migration of the specified model 962 from the source system to the target software system, where the 963 source container of the model includes at least one of the following: 965 1. Relational Database 967 * SQLSERVER 969 * MYSQL 971 * ORACLE 973 2. Excel File. Here, the model migration may support two modes: 975 * Migrating data from source to specify model structure 977 * Migrating data from source to specify the model structure and 978 migrating data within the model 980 3.6.2. User Migration 982 This framework SHOULD support the migration of users in the source 983 system and their access rights to the target software system, where 984 the user's source container includes at least one of the following: 986 1. Relational Database 988 * SQLSERVER 989 * MYSQL 991 * ORACLE 993 2. Excel File 995 3.6.3. User Group Migration 997 This framework SHOULD support the migration of user groups in the 998 source system and their access rights to the target software system, 999 where the user group's source container includes at least one of the 1000 following: 1002 1. Relational Database 1004 * SQLSERVER 1006 * MYSQL 1008 * ORACLE 1010 2. Excel File 1012 3.6.4. User Group Deployment 1014 This framework SHOULD enable system administrator users to enter 1015 their own software systems and create user groups on the cloud 1016 platform, where the creation of user groups is configured as follows: 1018 1. A user group ID created for identifying the user group is of 1019 necessity. 1021 2. It is optional to select many users into a user group, but one 1022 user group must have one use at least. 1024 4. Security Considerations 1026 This draft proposes an implementation standard for software migration 1027 deployment technology for cloud environments, and does not make 1028 special requirements for the security of the technology itself. 1029 However, the security of the cloud platform and the security between 1030 different users in the software system are required. The security of 1031 the cloud platform is mainly authentication security, and can also be 1032 considered as session security to ensure the security of the user 1033 during using software. The security of different users in the system 1034 is called permission control. Data isolation between different 1035 systems, different user groups in the same system, and different 1036 resource access rights between different users should be considered. 1038 5. IANA Considerations 1040 This memo includes no request to IANA. 1042 6. References 1044 6.1. Normative References 1046 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1047 Requirement Levels", BCP 14, RFC 2119, 1048 DOI 10.17487/RFC2119, March 1997, 1049 . 1051 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1052 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1053 . 1055 [RFC7705] George, W. and S. Amante, "Autonomous System Migration 1056 Mechanisms and Their Effects on the BGP AS_PATH 1057 Attribute", RFC 7705, DOI 10.17487/RFC7705, November 2015, 1058 . 1060 [RFC8206] George, W. and S. Murphy, "BGPsec Considerations for 1061 Autonomous System (AS) Migration", RFC 8206, 1062 DOI 10.17487/RFC8206, September 2017, 1063 . 1065 6.2. Informative References 1067 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1068 DOI 10.17487/RFC2629, June 1999, 1069 . 1071 [RFC3347] Krueger, M. and R. Haagens, "Small Computer Systems 1072 Interface protocol over the Internet (iSCSI) Requirements 1073 and Design Considerations", RFC 3347, 1074 DOI 10.17487/RFC3347, July 2002, 1075 . 1077 [RFC6208] Sankar, K., Ed. and A. Jones, "Cloud Data Management 1078 Interface (CDMI) Media Types", RFC 6208, 1079 DOI 10.17487/RFC6208, April 2011, 1080 . 1082 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 1083 DOI 10.17487/RFC7322, September 2014, 1084 . 1086 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1087 Application-Based Network Operations", RFC 7491, 1088 DOI 10.17487/RFC7491, March 2015, 1089 . 1091 6.3. URL References 1093 [idguidelines] 1094 IETF Internet Drafts editor, 1095 "http://www.ietf.org/ietf/1id-guidelines.txt". 1097 [idnits] IETF Internet Drafts editor, 1098 "http://www.ietf.org/ID-Checklist.html". 1100 [ietf] IETF Tools Team, "http://tools.ietf.org". 1102 [ops] the IETF OPS Area, "http://www.ops.ietf.org". 1104 [xml2rfc] XML2RFC tools and documentation, 1105 "http://xml.resource.org". 1107 Authors' Addresses 1109 Can Yang (editor) 1110 South China University of Technology 1111 382 Zhonghuan Road East 1112 Guangzhou Higher Education Mega Centre 1113 Guangzhou, Panyu District 1114 P.R.China 1116 Phone: +86 18602029601 1117 Email: cscyang@scut.edu.cn 1119 Shiying Pan (editor) 1120 South China University of Technology 1121 382 Zhonghuan Road East 1122 Guangzhou Higher Education Mega Centre 1123 Guangzhou, Panyu District 1124 P.R.China 1126 Email: 201721041376@scut.edu.cn 1127 Haibo Sun 1128 Inspur 1129 163 Pingyun Road 1130 Guangzhou, Tianhe District 1131 P.R.China 1133 Email: sunhb@inspur.com 1135 Kemin Qu 1136 NetEase,Inc 1137 Netease Building,Building E,Guangzhou Information Port 1138 16 Keyun Road 1139 Guangzhou, Tianhe District 1140 P.R.China 1142 Email: gzqukemin@corp.netease.com 1144 Guoqiang Han 1145 South China University of Technology 1146 382 Zhonghuan Road East 1147 Guangzhou Higher Education Mega Centre 1148 Guangzhou, Panyu District 1149 P.R.China 1151 Email: csgqhan@scut.edu.cn