Bsoc hybrid cloud dynamic deployment system and design method

Abstract

This invention relates to a BSoC hybrid cloud dynamic deployment system and its design method. Based on the BSoC cloud architecture design, it implements a hybrid cloud dynamic deployment mechanism. Due to limitations such as security, performance response, continuous service, and heavy data exchange loads, cloud application systems cannot deploy all services and data to the public cloud and need to migrate some services and data to a private cloud within a firewall. Throughout the entire lifecycle of a hybrid cloud business system, many services and data objectively require dynamic adjustment of their deployment distribution across both ends of the hybrid cloud as internal and external environments and needs change. By constructing a BSoC homogeneous cloud on the private cloud and employing the dynamic deployment mechanism designed in this invention, near real-time flexible allocation of services and data between hybrid clouds can be quickly achieved without changing the code. This avoids the risks and huge costs associated with traditional hybrid cloud reconstruction methods, achieving the optimal balance between economic benefits, performance, and security requirements of the hybrid cloud at different times.

Description

Technical Field

[0001] This invention belongs to the field of software architecture, specifically SOA and BSoC cloud architecture design. It utilizes a hybrid cloud dynamic deployment mechanism to enable the dynamic deployment and operation of SOA services and data within a BSoC structure on a hybrid cloud. Two systems running on the BSoC mechanism are deployed at opposite ends of the hybrid cloud. This dynamic deployment mechanism coordinates the distribution of services and data between the public and private clouds in real time, ensuring that enterprise users' business systems can continuously adapt to changes in the internal and external environment throughout their entire lifecycle, considering key indicators such as economy, maintainability, security, and operational efficiency. This allows the system to consistently achieve optimal configuration. Background Technology

[0002] BSoC is a PaaS system architecture design for the public cloud. This architecture does not provide specific business systems, but rather serves as a platform container with a centralized control mechanism to host SaaS systems that provide industry-specific business solutions. The aim of this architecture design is to move SOA systems out of the enterprise's firewall and deploy them to the public cloud, enabling services to reach the entire industry and provide standardized business solutions to more enterprises. This fully leverages the enormous potential of the SOA architecture, serving enterprises of all sizes within the industry in a richer, faster, higher-quality, and more economical way.

[0003] This system architecture incorporates comprehensive control and data decoupling design across numerous stages. It allows companies at different levels involved in the design to focus on their own technical and business expertise, pooling their collective wisdom. This enables these companies to independently enrich the services running within the system, solidify service quality, and significantly reduce the risks of service and system refactoring. It also improves service reusability and quality, creating a virtuous cycle and continuously evolving ecosystem among numerous upstream and downstream design companies. This promotes the transformation of business software design and service systems from an enterprise-oriented approach to an industry-oriented one.

[0004] BSoC deploys services to the public cloud, which is the only way for SOA technology systems to fully realize their potential value. However, in many cases, such deployment will encounter insurmountable difficulties in reality, requiring some compromises in technical design. The problems mainly lie in the following aspects:

[0005] Security: Moving services and data outside the firewall and having a neutral organization responsible for system security and maintenance is generally trustworthy. However, since a public cloud is interconnected throughout the internet, any security oversight can lead to significant losses. For data and services with extremely high security requirements, relying solely on the security mechanisms provided by public clouds is far from sufficient. Furthermore, national laws and regulations have begun to strictly restrict the storage of certain critical data on public clouds.

[0006] Performance Response: Some time-sensitive application services need to ensure a response within a real-time and controllable time frame. Currently, the Internet mainly uses the TCP / IP protocol, which lacks a quality of service guarantee design and has a large fluctuation range in network response latency, making it impossible to meet the near real-time response requirements of specific application services.

[0007] Continuous Service: While internet hardware has greatly improved, complex external factors still make it difficult to avoid unexpected events that can lead to network connection failures or cloud service interruptions. For business operations that require uninterrupted service, entrusting such a service to the public cloud carries too much risk.

[0008] Frequent heavy data exchange: Despite the increasing speed and reliability of the Internet, network latency and data transmission errors still occur frequently in situations that require frequent and large-volume data exchange with users, which can lead to untimely and unreliable service processing.

[0009] Maintainability: Although BSoC maximizes service reuse as much as possible, enterprise-customized services are still unavoidable. Some customized services that require frequent iterations need to go through relatively complicated deployment procedures when deployed to the public cloud, which will affect the iteration speed of services and is not conducive to the healthy operation and evolution of application systems.

[0010] The aforementioned problems arise from the deployment of services and data on the public cloud, and are also issues that the public cloud cannot objectively solve better. Therefore, it is necessary to introduce the private cloud into the entire design and operation system, adopt a hybrid cloud design, and move some services and data into the enterprise's firewall to solve the aforementioned difficulties. This will allow the services and data deployed on the public cloud to work together to construct a complete application system based on hybrid cloud technology.

[0011] An application system's lifecycle, from its initial release and operation to its eventual decommissioning, is a complete lifecycle. Many systems undergo continuous iteration and evolution throughout this lifecycle, with services and data deployed on public and private clouds respectively. As time changes, internal and external environments evolve, and the focus shifts. For example, new regulations on service and data security may necessitate migrating services and data from public clouds to private clouds, or, from an economic perspective, moving some services and data out of the public cloud. This means that the deployment of services and data in a hybrid cloud cannot remain static, and readjusting deployments is not a simple matter. Because the BSoC system architecture needs to be built as an ecosystem, a single application system is developed independently by different companies in different environments and at different levels, ultimately integrating together.

[0012] Service and data deployment adjustments involve the deployment details from the user to the underlying services and data. In BSoCs, these technical details are mostly implemented by low-level developers and shielded from the top-level business flow developers facing the end user. However, service and data deployment changes are often proposed by users and implemented by these top-level developers. Traditional deployment methods require one or more closely collaborating companies to bridge the gap between top-level user needs and low-level technical implementation, which is practically impossible in the BSoC ecosystem. This tightly coupled working model disrupts the normal workflow of the BSoC ecosystem and means that traditional hybrid cloud deployment methods cannot respond to such flexible and dynamic deployment adjustment needs. Therefore, a new approach and a new structural framework are needed to allow top-level developers to dynamically implement relevant deployment adjustments based on user needs without the involvement of low-level developers or knowledge of the specific deployment details of the underlying services and data, while maintaining the integrity of the BSoC ecosystem. This invention addresses these requirements by proposing a new mechanism for dynamic hybrid cloud deployment. Summary of the Invention

[0013] The initial design of BSoC could only run on public clouds. While this greatly improved the reusability of SOA application systems, many application scenarios still required customized extensions on private clouds. This invention deploys the BSoC application platform simultaneously on both public and private clouds, and through a dynamic control mechanism, achieves near real-time redeployment scheduling of application services and data in this hybrid cloud system. This balances various design concerns, thereby greatly expanding the application scope of the BSoC architecture.

[0014] The technical solution adopted by the present invention to achieve the above objectives is as follows: BSoC hybrid cloud dynamic deployment system, comprising:

[0015] The system data layer in the public cloud, which is geared towards the hybrid cloud, is used to store the list of data and logical services that need to be migrated and synchronized between the public cloud and the private cloud, the direction and operation method of migration and synchronization, and the current status information of migration and synchronization.

[0016] The system service layer of the public cloud is designed for a dynamic deployment mechanism for hybrid clouds, and is used to migrate and synchronize data and services between the public cloud and the private cloud.

[0017] The system data layer of the private cloud is used to register the mapping relationship between the logical service name and the entity service name of the private cloud, the mapping relationship between the logical data source and the entity data source, the local logical service list, and the access authorization information of enterprise users, for the system service layer of the private cloud to parse and call.

[0018] The system service layer of the private cloud is used to locate the cloud where the logical service requested by the user is located; when the logical service belongs to the private cloud, the logical service is parsed and invoked; when migration and synchronization are required, it works with the system service layer of the public cloud for the dynamic deployment mechanism of hybrid cloud to realize the migration and synchronization of data and services between hybrid clouds.

[0019] The public cloud-oriented system data layer for hybrid cloud includes:

[0020] The synchronized data list, deployed on the public cloud, is used to register the list of entity data that can be migrated and synchronized, the direction and operation method of migration and synchronization, and the status information of the data currently being migrated and synchronized.

[0021] The synchronization service list, deployed on the public cloud, is used to register the list of logical services that can be migrated and synchronized, the direction and operation method of migration and synchronization, and the status information of the logical services currently being migrated and synchronized.

[0022] The system service layer of the public cloud for the hybrid cloud dynamic deployment mechanism includes:

[0023] The synchronization server, deployed on the public cloud, consists of a set of services for data and service migration and synchronization between the public and private clouds. It adopts a BSoC hybrid cloud dynamic deployment mechanism, that is, after setting the services to be migrated, their migration direction, and migration method in the synchronization service list, and setting the data list to be migrated, their migration direction, and migration method in the synchronization data list, the set of services obtains the entity service and entity data source information from the public cloud based on the service registration and enterprise registration information, or obtains the entity data source information from the autonomous application server in the private cloud, thereby realizing the migration and synchronization of application services and data from the public cloud to the private cloud, or from the private cloud to the public cloud.

[0024] The system data layer of the private cloud includes:

[0025] The local logical service list, deployed on a private cloud, provides information on all logical services deployed locally and their current status. It is automatically generated by the autonomous application server after the migration and synchronization operation is completed, and the service status is maintained and modified manually.

[0026] The autonomous application server stores local service registration information, user authorization information, and a mapping table between logical data sources and entity data sources.

[0027] The local service registration information is used to provide the mapping relationship between logical services and entity services, as well as the calling and authorization attributes. It is migrated and synchronized between the service registration information of the autonomous application server and the public cloud. The user authorization information is maintained locally and is not migrated and synchronized.

[0028] The mapping table between the logical data source and the entity data source is configured such that the logical data source name is migrated and synchronized from the corresponding content in the enterprise registration information in the autonomous application server and the public cloud. The mapping relationship between the entity data source and the logical data source is manually reconfigured locally without migration and synchronization.

[0029] The system service layer of the private cloud includes:

[0030] The service-oriented server is deployed in a private cloud. Only when the BSoC hybrid cloud dynamic deployment mechanism is adopted, the service-oriented server is deployed on the user's front end. The local logical service list and service status are used to locate the cloud where the logical service for each user request is located, and the application service request is sent to the cloud where it is located by the identity proxy of the virtual user.

[0031] The autonomous application server, deployed in a private cloud, includes construction services, login services, interface services, parameter conversion services, scheduling services, data services, and application services. It implements the same BSoC system functions as the public cloud and provides services to work in conjunction with the public cloud synchronization server to complete the migration and synchronization of application services and data.

[0032] The BSoC hybrid cloud dynamic deployment system is a PaaS-oriented system architecture, with one complete BSoC system deployed on both a public cloud and a private cloud. Each BSoC system includes:

[0033] The system data layer is used to register the mapping relationship between logical services and entity services, and to store enterprise user information, registration information of callable services, and access authorization information.

[0034] The system service layer is used to achieve enterprise-wide user security management, standardization and optimization of user and cloud service requests, parsing and scheduling of service requests, and parsing of service access to data sources through interaction with the system data layer and application service layer; it initiates requests to entity services through parsing of logical services to achieve decoupling of access to entity services; and it decouples access to entity data sources through data access in the form of logical data sources.

[0035] The application service layer is used to respond to the service scheduling of the cloud system and provide actual application service processing for users between enterprises.

[0036] The system data layer includes:

[0037] Service registration is used to register all services called by users, provide relevant service attribute information, group services, and define the mapping relationship between users' logical service names and entity service names;

[0038] Enterprise registration is used to store enterprise and user registration information, role group authorization status, and a mapping table between logical data source names and entity data source names.

[0039] The authorization domain is used to store the access security policy of the logged-in user during the current session, the mapping table of all logical services and entity services for authorization operations, and the mapping table of logical data source names and entity data source names, for the scheduling service to retrieve.

[0040] The system service layer includes:

[0041] The construction service is used to obtain authorized user information through the login service, construct the authorization domain for the user session based on the information in the service registration and enterprise registration, and notify the user to process subsequent business requests through the login service.

[0042] The scheduling service receives logical service requests from users from the interface service, then redirects the logical service requests to entity service requests through the authorization domain, and performs normalization processing on the parameter sequence passed from the logical service through the parameter transformation service to obtain the entity service parameter list, and sends a call request to the entity service. Finally, the processing result obtained by the entity service in performing business processing according to the call request is fed back to the requesting user.

[0043] The parameter conversion service is used to convert the list of logical service parameters into the parameter call relationship of the corresponding entity service based on the parameter conversion relationship obtained from the authorized domain, and return it to the scheduling service.

[0044] The data service is used to obtain the mapping table between logical data source names and entity data source names from the authorized domain, convert the entity service's access request to the logical data source into an access request to the entity data source, and provide conversion between different database access formats.

[0045] The application service layer includes:

[0046] The login service is a non-schedulable service. Upon receiving a user login request, it retrieves the corresponding enterprise and user registration information from the enterprise registration and the authorization information from the enterprise authorization to verify the legitimacy of the user's login operation on the application system. The legitimate user sends the user information to the construction service.

[0047] The interface service is a non-schedulable service used to interact with users, receive user access requests, convert user operation sequences into logical service requests and send them to the scheduling service, obtain processing results from the scheduling service and send them back to the user, and also provide users with pre-set operable business interfaces.

[0048] The business service is a schedulable service. After receiving a call request from the scheduling service, it performs business logic processing, and after the processing results are transformed by the parameter conversion service and the scheduling service, they are sent back to the user who made the call request.

[0049] Shadow services are unschedulable services used for business logic processing. They are isolated from the user's service call relationship. The calling methods between a group of shadow services are directly called using the entity service name.

[0050] Services are schedulable services that provide a unified external calling interface for shadow services; standard services are either schedulable or unschedulable services that are used to standardize business processes so that other business services can directly call them.

[0051] The present invention has the following beneficial effects and advantages:

[0052] 1. To supplement the BSoC public cloud architecture with a hybrid cloud-based technical design, while maintaining homogeneity between the public and private clouds.

[0053] 2. The deployment status and coding of hybrid cloud are decoupled, and deployment changes do not require changes to the coding of services and business flows at all levels, so that the original operation and maintenance ecosystem remains unchanged.

[0054] 3. Deployment changes do not require knowledge of the detailed deployment details of services and data, making maintenance convenient and meeting the requirements for agile deployment throughout the entire software lifecycle.

[0055] 4. Provide enterprise users with the best balance of various indicators such as economy, security, performance response, and maintainability.

[0056] 5. Help enterprise users achieve a coordinated and unified approach to service sharing and personalized customization.

[0057] 6. By upgrading services and making customized services more public, the industry knowledge and experience accumulated by enterprise users can be gathered together, and the improvement and development of industry-oriented business systems can be continuously promoted. Attached Figure Description

[0058] Figure 1 Business SOA over Cloud Hybrid Cloud Architecture Hierarchy Diagram;

[0059] Figure 2 Business SOA over Cloud Hybrid Cloud Overall Framework Diagram;

[0060] Figure 3.1 List of local logical services;

[0061] Figure 3.2 Local entity service registration;

[0062] Figure 4 Synchronization service list;

[0063] Figure 5.1 Data source mapping table for synchronization;

[0064] Figure 5.2 List of methods for extracting synchronized data.

[0065] Figure 6 Business SOA over Cloud architecture hierarchy diagram;

[0066] Figure 7 Business SOA over Cloud Overall Framework Diagram;

[0067] Figure 8 Construct a sequence diagram for service startup and regular business service scheduling;

[0068] Figure 9 Data service call sequence diagram;

[0069] Figure 10a Service attributes during service registration;

[0070] Figure 10b Service registration: service groups;

[0071] Figure 10c Company information;

[0072] Figure 10d Enterprise application systems;

[0073] Figure 10e Enterprise data source definition;

[0074] Figure 10f Enterprise role definition;

[0075] Figure 10g Enterprise user information;

[0076] Figure 10h Enterprise user authorization;

[0077] Figure 10i Registration of physical services. Detailed Implementation

[0078] The present invention will now be described in detail with reference to the accompanying drawings.

[0079] The BSoC hybrid cloud dynamic deployment system requires the deployment of a series of system services and system data responsible for application services and data migration and synchronization on both public and private clouds, including:

[0080] The system data layer in the public cloud, which is geared towards the hybrid cloud, is used to store the list of data and logical services that need to be migrated and synchronized between the public cloud and the private cloud, the direction and operation method of migration and synchronization, and the current status information of migration and synchronization.

[0081] The public cloud-oriented system service layer for hybrid clouds is used to migrate and synchronize data and services between public and private clouds.

[0082] The system data layer of the private cloud is used to register the mapping relationship between the logical service name and the entity service name of the private cloud, the mapping relationship between the logical data source and the entity data source, the local logical service list, and the access authorization information of enterprise users, for the system service layer of the private cloud to parse and call.

[0083] The private cloud system service layer is used to locate the cloud where the logical service requested by the user resides; when the logical service belongs to the private cloud, the logical service is parsed and invoked; when migration and synchronization are required, it works with the public cloud system service layer to realize the migration and synchronization of data and services between hybrid clouds.

[0084] The system data layer of the public cloud includes:

[0085] The synchronized data list, deployed on the public cloud, is used to register the list of entity data that can be migrated and synchronized, the direction and operation method of migration and synchronization, and the status information of the data currently being migrated and synchronized.

[0086] The synchronization service list, deployed on the public cloud, is used to register the list of logical services that can be migrated and synchronized, the direction and operation method of migration and synchronization, and the status information of the logical services currently being migrated and synchronized.

[0087] The system service layer of the public cloud includes:

[0088] The synchronization server, deployed on the public cloud, consists of a set of services for data and service migration and synchronization between the public and private clouds. After the services to be migrated, their migration direction, and migration method are set in the synchronization service list, and the data list to be migrated, its migration direction, and migration method are set in the synchronization data list, the set of services obtains the entity service and entity data source information from the public cloud based on the service registration and enterprise registration information, or obtains the entity data source information from the autonomous application server in the private cloud. This enables the migration and synchronization of services and data from the public cloud to the private cloud, or from the private cloud to the public cloud.

[0089] The system data layer of the private cloud includes:

[0090] The local logical service list, deployed on a private cloud, provides information on all logical services deployed locally and their current status. It is automatically generated by the autonomous application server after the migration and synchronization operation is completed, and the service status is maintained and modified manually.

[0091] The autonomous application server stores local service registration information, user authorization information, and a mapping table between logical data sources and entity data sources.

[0092] The local service registration information is used to provide the mapping relationship between logical services and entity services, as well as the calling and authorization attributes. It is migrated and synchronized between the service registration information of the autonomous application server and the public cloud. The user authorization information is maintained locally and is not migrated and synchronized.

[0093] The mapping table between the logical data source and the entity data source is configured such that the logical data source name is migrated and synchronized from the corresponding content in the enterprise registration information in the autonomous application server and the public cloud. The mapping relationship between the entity data source and the logical data source is manually reconfigured locally without migration and synchronization.

[0094] The system service layer of the private cloud includes:

[0095] The service-oriented server is deployed on a private cloud. Only when the BSoC hybrid cloud dynamic deployment mechanism is adopted, the service-oriented server is deployed on the user's front end. It locates the cloud where the logical service of each user request is located through the local logical service list and service status, and will interact with the public cloud and send the application service request to the cloud where it is located as a virtual user's identity proxy.

[0096] The autonomous application server, deployed in a private cloud, includes construction services, login services, interface services, parameter conversion services, scheduling services, data services, and application services. It implements the same BSoC system functions as the public cloud and provides services to work in conjunction with the public cloud synchronization server to complete the migration and synchronization of application services and data.

[0097] The design of the BSoC hybrid cloud dynamic deployment mechanism needs to meet the following key points:

[0098] Both public and private clouds adopt the BSc architecture to ensure that they are equivalent to each other from the user's perspective.

[0099] Dynamic deployment and business flow coding are effectively isolated, mainly by adjusting the service and data lists. Changes in deployment status and cloud information are transparent to business flow coding.

[0100] Implementing dynamic deployment should ensure the continuity of user application system services during the redeployment process;

[0101] Dynamic deployment allows for migration from public cloud to private cloud, and vice versa.

[0102] The list of dynamically deployed services can only be schedulable logical services, and similar data lists can only be logical data sources;

[0103] The dynamic deployment mechanism should adopt a non-coded form;

[0104] Since the BSoC implementation is primarily aimed at the public cloud, the list of services and data that need to be dynamically scheduled is stored only on the public cloud.

[0105] like Figure 1The diagram shows the hierarchical structure of a BSoC hybrid cloud architecture. Based on the existing public cloud BSoC, a synchronization server is deployed on the public cloud. By reading the synchronization service list and synchronization data list also on the public cloud, it communicates with the BSoC system deployed on the private cloud, enabling the migration of services and data between the two clouds, thus realizing a hybrid cloud application system. This migration process allows for dynamic switching during application system runtime, achieving near real-time dynamic system transformation with minimal transition time. Furthermore, these changes in cloud deployment status are transparent to service code and business process code, requiring no modification to these codes.

[0106] The autonomous application server in the private cloud integrates a simplified version of the BSoC service architecture. Since this private cloud is only responsible for application services within a single enterprise, the complex authorization management and isolation mechanisms for application services and data between industries can be removed. It only provides mapping and resolution functions for logical services to entity services and logical data sources to entity data sources.

[0107] When a private cloud is deployed, client applications need to know which cloud the application service is deployed on before calling it. Therefore, service redirection needs to be set up on the private cloud. All services configured locally are stored as a list in the local logical service list. When the business logic calls a service, it first checks the service redirection to determine if the service is already configured locally. If it is configured locally and is in an ACTIVE state, the service request is forwarded to the local autonomous server; otherwise, the request is sent to the public cloud. Therefore, locally deployed services have high access priority.

[0108] like Figure 2 As shown, compared to the BSoC public cloud architecture, the new hybrid cloud dynamic deployment mechanism adds some services and system architecture data, which can be summarized as follows:

[0109] The system data layer in the public cloud includes: a Synchronizing Services List and a Synchronizing Data List.

[0110] System service layer in public cloud: Synchronizing Server;

[0111] The system data layer in the private cloud: Local Services List;

[0112] The system service layer of the private cloud includes: Service Positioning Service and Autonomous Application Server.

[0113] The following is a detailed explanation of the system services and system data mentioned above.

[0114] System data

[0115] Synchronizing Data List

[0116] Deployed in the public cloud, including data source mapping tables (see...) Figure 5.1 ) and a list of data extraction methods (see Figure 5.2 The data mainly includes database data and file data.

[0117] The data source mapping table describes the mapping relationship between the logical name of the data source and the physical data sources in the public and private clouds. Based on this, the storage target address and connection parameters of the physical data sources at both ends of the hybrid cloud can be resolved from the logical data source. The parameters of the physical data source in the private cloud can be configured in either the public or private cloud.

[0118] The data extraction list allows synchronization in either the public cloud to private cloud (P2C, i.e., Public to Customer) or the private cloud to public cloud (C2P). All data sources involved are logical data sources. The data source mapping table can be used to resolve the respective entity data sources for the two clouds being synchronized. When the entity data parameters are configured on the private cloud, only P2C synchronization migration is possible. The data source mapping table indicates the data types to be synchronized, categorized as databases and files.

[0119] Data type is database:

[0120] Data extraction methods include SQL query statements or services.

[0121] If the target cloud data table already contains data, there are three possible synchronization methods:

[0122] REPLACE: This is equivalent to deleting all existing data and then inserting it.

[0123] APPEND: For data with the same keyword, retain the original data; for new synchronized data with different keywords, perform an insert operation.

[0124] INSERT: Records with the same key are replaced with new records; new synchronized data with different keys are inserted.

[0125] After synchronization is complete, the source cloud data can be processed in three ways:

[0126] KEEP: Data remains unchanged;

[0127] DELETE: Deletes data based on extraction criteria;

[0128] REMOVE: The data, including the table structure, is completely deleted.

[0129] The data type is a file:

[0130] Data extracted completely as a file

[0131] Depending on whether the file already exists, the target cloud can take two actions:

[0132] REPLACE: Replaces existing files with synchronized files, without retaining the original files;

[0133] BACKUP: Existing filenames at the destination are renamed and saved with timestamps appended; files synchronized there retain their original filenames.

[0134] After synchronization is complete, the source cloud files can be processed in two ways:

[0135] KEEP: File retention;

[0136] DELETE: File deletion

[0137] Synchronizing Services List

[0138] Deployed in the public cloud, see below. Figure 4 The services mentioned here refer to logical services. Since logical services may directly or indirectly reference shadow services and standard services, when migrating a logical service, the related shadow services and standard services need to be processed simultaneously. These shadow services and standard services need to retrieve the entity service registration information table in the source cloud and construct the complete entity service reference chain of the logical service through a recursive algorithm.

[0139] When performing service synchronization, the target cloud can use three different methods for service synchronization:

[0140] KEEP: The target cloud already has the corresponding entity service (including the corresponding shadow service and standard service). Add the missing ones, leave the existing ones unchanged, and leave the target cloud unchanged if it has the service but the source cloud does not.

[0141] REPLACE: Regardless of the existence of the target cloud entity service (including the corresponding shadow service and standard service), the original target cloud entity service (including the corresponding shadow service and standard service) is deleted and then replaced with the source cloud entity service (including the corresponding shadow service and standard service).

[0142] REFRESH: If the target cloud already has the corresponding entity service (including the corresponding shadow service and standard service), add the missing ones, update the existing ones with the entity service (including the corresponding shadow service and standard service) from the source cloud, and leave the target cloud unchanged if it already exists but the source cloud does not.

[0143] After service synchronization is complete, the entity services in the source cloud need to be processed. Two operations can be used:

[0144] KEEP: Source entity service (including corresponding shadow service) is retained.

[0145] REMOVE: Delete the source entity service (including its corresponding shadow service).

[0146] Since the standard service is not provided to a single customer, the standard service on the public cloud remains unchanged during the synchronization of all related entity services. However, with authorization, the standard service can be copied from the public cloud to the private cloud. In this case, the standard service synchronization flag is 'Y', providing a faster, more reliable, and secure service response for the private cloud. Local entity service registration on the private cloud ( Figure 3.2 In this context, based on the synchronization standard service identifier, the corresponding standard service can be directed to either the private cloud (identified as 'Y') or the public cloud (identified as 'N').

[0147] Local Services List

[0148] List of local logical services deployed on a private cloud ( Figure 3.1 ) to coordinate with the registration of local entity services migrated synchronously from the autonomous server ( Figure 3.2 When a service call request occurs, the local entity service corresponding to the logical service is parsed based on the user's authorization. This list is automatically generated by the autonomous application service system after the synchronization migration is completed.

[0149] The local logical service list displays all logical services deployed locally, but only those in the ACTIVE state can run locally. It's important to note that all entity services corresponding to a logical service must be registered in the local entity service registry. Standard services involved may not have undergone local migration and synchronization; in this case, the corresponding standard service address should point to the public cloud.

[0150] System services

[0151] Synchronizing Server

[0152] Deployed on the public cloud, it consists of a set of services for migrating and synchronizing data and services between the public and private clouds, enabling the migration and synchronization of services and data from the public cloud to the private cloud, or from the private cloud to the public cloud.

[0153] When services and data are migrated from the public cloud to the private cloud, the services to be migrated are located from the service registration information in the public cloud based on the synchronized service list; the data to be migrated is located based on the synchronized data list. With the cooperation of the autonomous servers in the private cloud, the migration and synchronization process of services and data from the public cloud to the private cloud is realized.

[0154] When services and data are migrated from a private cloud to a public cloud, the services that need to be migrated are located based on the synchronized service list and the service registration information of the private cloud; the data that needs to be migrated is located based on the synchronized data list and the local entity data source information configured in the private cloud. With the cooperation of the autonomous server in the private cloud, the migration and synchronization process of services and data from the public cloud to the private cloud is realized.

[0155] Service positioning service

[0156] Deployed on a private cloud. This targeted service is only needed when using the BSoC hybrid cloud dynamic deployment mechanism to locate the cloud where the logical service for each user request resides. The service retrieves the local list of logical services. If the logical service is in the list and is in the ACTIVE state, the service request is sent to the autonomous application server in the private cloud, which then resolves the required entity service and its location based on the local entity service registration information. If the logical service is not in the list or is in the INACTIVE state, it means the logical service is not in the private cloud, and the service request is sent to the public cloud.

[0157] Autonomous application server

[0158] Deployed on a private cloud, it is a simplified version of BSoC service group, removing the complex authorization management and isolation mechanisms between enterprises. It mainly includes scheduling services, data services, and services that work in conjunction with public cloud synchronization servers.

[0159] When a service-oriented service forwards a local logical service request to an autonomous server, the server parses the logical service, locates the entity service that can provide the service, and forwards the service request to that entity service. After processing, the server returns the result to the client that requested the service. The data service works in the same way as BSoC.

[0160] Migration and synchronization require collaboration between autonomous servers and synchronization servers in the public cloud.

[0161] When performing a synchronous migration from a public cloud to a private cloud, the first step is to locate, transfer, and deploy the services to be migrated according to the local service location configuration file. Simultaneously, local service registration is performed based on the service registration information from the public cloud and the current service location information. Before data migration, it is necessary to ensure that the target data source has been installed and authorized. Then, according to the information in the synchronization data list, all compressed and encrypted data transferred from the target source is loaded into the local data target.

[0162] When performing a synchronized migration from a private cloud to a public cloud, the first step is to locate, transfer, and deploy the services to be migrated according to the public cloud service location configuration file. Simultaneously, the public cloud services are registered based on the service registration information from the private cloud and the public cloud service location information. Before data migration, it is necessary to ensure that the target data source has been installed and authorized. Then, according to the information in the synchronized data list, all compressed and encrypted data transferred from the public cloud is loaded into the target data repository.

[0163] After the synchronization migration is complete, the autonomous application server updates the local logical service list, local service registration information, and synchronization data source mapping table. After migrating from a private cloud to a public cloud, additional access authorization management for related services is required.

[0164] Complete the migration of a logical service from the public cloud to the private cloud:

[0165] In a BSoC hybrid cloud system, services and data can be migrated from the public cloud to the private cloud and vice versa. This process can be repeated to meet the various rigid requirements of the application system and to continuously balance and optimize various indicators. During this process, no coding changes are required; only necessary configuration information needs to be filled in some configuration tables. The migration process can achieve near-seamless migration or minimize migration time gaps to avoid data inconsistencies and service interruptions. The following example of migrating a logical service from the public cloud to the private cloud illustrates the implementation of the dynamic deployment mechanism.

[0166] Using the BSoC public cloud system example, let's take a very simple SMS system (APP_SMS) as an example. The system was initially deployed on the BSoC public cloud, and now it is necessary to migrate one of the logical services, "Receive SMS (SV_ReceiveSMS)," to a private cloud.

[0167] Preparations before relocation:

[0168] The tasks that need to be completed in the private cloud include:

[0169] Complete the initial private cloud deployment, including a simplified localized BSoC system and the creation of necessary database tables, and define the access permissions and configuration information related to services and data involved in the migration.

[0170] Configure a service targeting service to intercept all logical service requests sent by business flow encoding, build a local logical service list and initialize it.

[0171] The tasks that need to be completed in the public cloud include:

[0172] Configure a synchronization service list, registering the migration information of the logical service SV_ReceiveSMS to be migrated in the synchronization service list. Its synchronization method is REPLACE, and the source service is processed as REMOVE after synchronization. Standard services involved, due to frequent calls, also need to be synchronized and replicated to the private cloud. See [link / reference]. Figure 4 .

[0173] Setting up the synchronized data list requires configuring the relevant data source mapping tables separately (see...). Figure 5.1 ) and a list of data extraction methods (see Figure 5.2 The data source mapping table lists the access attributes of the public and private clouds corresponding to the two logical names DV_AUTH & DV_LOG of the data source. The data extraction method list requires retrieving data from the public cloud according to the logical name of the data source and the syntax for extracting data. The data is then migrated to the private cloud according to the REPLACE setting of the target data source synchronization method, completely replacing the original data with the new data. After the source data is migrated, the data on the original public cloud remains unchanged according to the KEEP setting.

[0174] Perform migration

[0175] 1. Start the synchronization server and read the synchronization service list. Figure 4 & Synchronized Data List ( Figure 5.1 & Figure 5.2 );

[0176] 2. Based on the logical service SV_ReceiveSMS in the synchronization service list, search the service registration information on the public cloud for all directly and indirectly called entity services corresponding to this logical service and the private cloud company. Figure 3.2 This logical service corresponds to a Facade service SR_ReceiveSMS, through which the following shadow services and standard services are indirectly invoked:

[0177] SR_ReceiveSMS_CMCC: Receive SMS - Mobile, Shadow Service

[0178] SR_ReceiveSMS_CUCC: Receive SMS - China Unicom, Shadow Service

[0179] SR_ReceiveSMS_CTCC: Receive SMS - Telecom, Shadow Service

[0180] SR_Encrypt: Encryption, standard service

[0181] SR_Decrypt: Decryption, standard service

[0182] 3. The synchronization server in the public cloud packages, compresses, and encrypts the aforementioned entity services and transmits them to the private cloud;

[0183] 4. The autonomous application server in the private cloud will decrypt, decompress, and unpack the received services, and deploy them to the designated location according to the service configuration information;

[0184] 5. The autonomous application server updates the local entity service registration based on the received service list. Figure 3.2 )

[0185] 6. The public cloud synchronization server extracts data from the public cloud based on the data source information and data extraction list in the synchronization data list, and then transmits the data to the private cloud after packaging, compression, and encryption.

[0186] 7. The autonomous application server in the private cloud decrypts, decompresses, and unpacks the received data. It places file-type data in the storage location specified by the data source and loads database-type data into the database in the private cloud according to the synchronization method of the destination data source (REPLACE in this example).

[0187] 8. The autonomous application server updates the list of data sources in the private cloud based on the received data.

[0188] Post-migration processing

[0189] The tasks that need to be completed in the private cloud include:

[0190] If it is confirmed that the logical service SV_ReceiveSMS to be migrated needs to run on the private cloud, then add this logical service to the local logical service list. Figure 3.1 )

[0191] If the logical service SV_ReceiveSMS is still running on the public cloud, there is no need to add this service to the local logical service list.

[0192] The tasks that need to be completed in the public cloud include:

[0193] In the public cloud synchronization service list, if the value of the source service processing field after synchronization for the logical service SV_ReceiveSMS is set to REMOVE, then after migration, the synchronization server needs to remove the entity services directly or indirectly called by this logical service. It should be noted that standard services belong to the public service category and are not included in the removal list. The entity services that need to be removed include:

[0194] SR_ReceiveSMS: Receives SMS messages via Facade service.

[0195] SR_ReceiveSMS_CMCC: Receive SMS - Mobile, Shadow Service

[0196] SR_ReceiveSMS_CUCC: Receive SMS - China Unicom, Shadow Service

[0197] SR_ReceiveSMS_CTCC: Receive SMS - Telecom, Shadow Service

[0198] In the data extraction list of the public cloud synchronized data list, the source data processing field after synchronization sets the operation to be performed on the source data after migration. In this example, the value is KEEP, and all data will remain unchanged.

[0199] Through the above stages, the process of synchronizing and migrating a logical service SV_ReceiveSMS and related data from the public cloud to the private cloud has been completed. After the migration, requests for this logical service can be directly directed to the private cloud through service redirection. The migration process from the private cloud to the public cloud is similar and can be applied to other similar scenarios. It is important to note that all operations on synchronizing the service list and data list are performed only on the public cloud.

[0200] The initial design goal of BSoC was to liberate SOA systems from enterprise firewalls, enabling service architectures to provide services to numerous companies across the industry. This improves service reusability, ensures service quality, meets the needs of agile business operations, and reduces the construction and maintenance costs of application systems. It can be said that the BSoC platform, built on a public cloud, is a solid guarantee for achieving these goals.

[0201] When users need to make various trade-offs regarding security, rapid response, continuous service, heavy-load data exchange, and ease of customization, providing a hybrid cloud PaaS platform design solution can meet the needs of more users and application scenarios.

[0202] Throughout the complete lifecycle of an application system, changes in various requirements and environments necessitate continuous optimization and balancing designs. This objectively requires the provision of a hybrid cloud-based service and data deployment mechanism that is flexible and dynamic. Furthermore, this dynamic deployment mechanism must be secure and reliable, easy to operate, reduce technical dependence, and reflect business logic.

[0203] Furthermore, many critical application systems require uninterrupted service and necessitate system disaster recovery. Periodically replicating critical services and data to a private cloud ensures that the differences between critical business services and data in the private and public clouds remain at minimal time intervals. In the event of an incident in either cloud, the service request can be quickly switched to the next available cloud, thereby minimizing the risk of service interruption while optimizing operating costs.

[0204] This invention is a design of a dynamic deployment mechanism to achieve the above objectives.

[0205] The BSoC design model framework is as follows:

[0206] See Figure 6 (BSoC architecture hierarchy diagram) and Figure 7 (BSoC overall framework diagram) The entire structure is roughly divided into two parts: the upper part is the enterprise end inside the firewall, and the lower part is the public cloud.

[0207] On the enterprise side, when a user logs in, the request is sent to the login service, which and the construction service perform user security authorization verification and extract runtime environment information. The relevant information is then transferred to the scheduling service and the data service for building the runtime environment for the user's subsequent operations.

[0208] When users perform routine business operations, they communicate with the underlying cloud-based interface services through a customized UI. These services then forward access requests to a scheduling service as logical services. The scheduling service maps these logical services to entity services based on the user's runtime environment information and is responsible for discovering entity service providers and forwarding service requests to them. The entity service provides the specific business processing flow, and the execution result is returned to the requesting user.

[0209] The entity service accesses data using logical data. It sends the data access request to the data service, which maps the logical data to entity data based on the user's runtime environment information, and then extracts the data on behalf of the entity service and returns the result to the requesting entity service.

[0210] from Figure 8 and Figure 9 This allows us to understand the relationship between the specific service scheduling sequence and the data access sequence.

[0211] Entity services are categorized into schedulable and unschedulable services based on their accessibility to the user. Unschedulable services do not have a corresponding logical service. Entity services can be nested, forming schedulable services of varying granularity through encapsulation. Microservices that prioritize technical reuse are unschedulable and must be encapsulated and combined into coarse-grained, business-oriented schedulable services. For more detailed classifications of service types and data types, please refer to [link to relevant documentation]. Figure 7 In summary, the main services and system architecture data in the cloud primarily include:

[0212] System data layer: Services Register, Enterprise Register, Enterprise Authority, Authorized operation space;

[0213] System service layer: Constructor Service, Dispatching Service, Parm conversion Service, Data Service;

[0214] Application service layer: Login Service, Interface Service, Business Service, Shadow Service, Standard Service.

[0215] Let me introduce the roles of different system data and services in the system.

[0216] System data

[0217] Services Register

[0218] This includes only all schedulable services, primarily reflecting the mapping relationship between service logical names and service entity names, as well as the parameter attributes and mapping relationships of their respective calls. Different services can correspond to the same logical name, or the same logical name can correspond to different services; that is, the relationship between logical names and entity service names is many-to-many. Service calls involved in business flow coding must and are only allowed to use the service's logical name. The scheduling service resolves the entity service to be called. To facilitate authorization management, services need to be appropriately grouped, and authorization can only be performed by service group.

[0219] Enterprise Registration

[0220] It includes all legitimate enterprises and their users, describing the basic attributes of the enterprises and their users, the role information assigned to users, and the resource request allocation for the corresponding application system. This includes a list of correspondences between data source logical names and data source names. All user requests to access data can only be made through the data source logical name. The cloud system can use this registration information to regulate the resource allocation for enterprises and users.

[0221] Enterprise Authority

[0222] This is part of the enterprise registration information, including the authorized access information of all legitimate enterprise users. The login service and the construction service retrieve this information to confirm the service permissions of the accessing customer and construct an authorization domain to describe the user's operating environment information at the current session stage.

[0223] Authorized operation space

[0224] It includes a mapping table of all logical services and entity services authorized during the current session of the logged-in user. The main contents include the various attributes and parameter lists of logical services and entity services, as well as the mapping relationship between logical services and entity services. In addition, it also includes a mapping table of logical data sources and entity data sources.

[0225] When an enterprise user logs in, the construction service extracts the user's authorization information from the enterprise registration and, together with the service registration information, constructs a mapping set space of operable services and data sources for this session. The former is handled by the scheduling service, which locates the entity service providing the actual processing based on the logical service requested by the user, and performs parameter normalization processing by the relevant parameter transformation service; the latter, when an entity service retrieves data using a logical data source, is handled by the data service, which locates the detailed information of the entity data source based on the data source mapping table.

[0226] System services

[0227] Constructor Service

[0228] The construction service is a standardized system service. Once a user logs in and confirms that their registration information has granted permissions to the application system, this non-scheduled service is initiated. This service obtains authorized user account information from the login service and constructs the authorized domain for the user's session from service registration and enterprise registration information. This domain represents the user's set of operational capabilities for the currently logged-in system, forming a mapping table between logical services and actual application services, as well as a mapping table between logical data sources and entity data sources. This establishes the initial runtime environment for the logged-in user during this session.

[0229] Dispatching Service:

[0230] The scheduling service is a standardized system service used to dynamically decouple call requests between logical services and entity services. After receiving a logical service request from a user, it redirects the request to the optimal entity service request through the authorization domain. In specific cases, the parameter sequence passed from the logical service is normalized by the parameter conversion service, transforming it into the standardized parameter sequence required by the entity service, and then sent as a call request to the entity service layer. The processing result is then analyzed, filtered, and fed back to the requesting user along the original path. Because the parameter sequence and format of the data returned by the logical service may differ from those of the entity service, the returned data still needs to be converted by the parameter conversion service.

[0231] The scheduling service provides a central control mechanism for application systems and is one of the core designs of the BSoC architecture, essentially acting as the brain of the PaaS platform. The scheduling service requires secondary optimization of the authorization domain, caching the entire group of access services in its mapping buffer to reduce frequent calls to the large datasets in the authorization domain. It can also have multiple running replicas, serving as a runtime load balancer.

[0232] Parameter conversion service

[0233] The system call service, acting as a scheduling service, functions as a soft bus. After locating the entity service, the scheduling service needs to transmit the parsed logical service and entity service information to this service. This service, based on the parameter attribute lists of the logical and entity services, obtains information on parameter conversion, standardizes the parameter order and format of the logical service data exchange, converts it into parameter call relationships for the entity service, and then sends the standardized parameter table back to the scheduling service, which then forwards the scheduling request to the entity service. After the entity service finishes processing, it receives the standardized result data returned by the scheduling service, restores it to the logical service's return result data format, and sends it back to the scheduling service, which then sends it back to the requesting user through the interface service. This service should have authorized access to the scheduling service's mapping buffer, but does not need to access the authorized domain. Data Service:

[0234] Due to considerations such as security, performance, and cost, different enterprises and application systems may use different database types and storage locations. To achieve decoupled data access, client requests for data access must use the logical name of the data source, and the entity service layer must also use the logical name of the data source to access data. This is so that the same entity service can handle data access requests from different enterprises / application systems without modifying the code.

[0235] The data service retrieves a mapping list of data source logical names and data source entity names from the authorized domain. It then transforms the entity service's access requests to the data source logical names into access requests to the actual data sources, shielding the complexity and variability of the data sources and achieving dynamic decoupling of data access. The data service also provides conversion between different database access formats and converts non-standard data requests into standardized data access formats. The data extracted by the data service proxy undergoes reverse format conversion and data security verification before returning the processing results to the calling entity service.

[0236] Data services are also a core design feature of the BSoC architecture. They can perform secondary optimizations on the authorized domain, caching the mapping table of the logical name and entity name of the currently accessed data source in the mapping buffer of this service, reducing frequent calls to the large dataset in the authorized domain, and can also have multiple running replicas to play a role in runtime load balancing.

[0237] Application services

[0238] It is the entity service of all companies and all application systems in the cloud, including login service, interface service and the collection of entity services that actually perform business processing, the latter can also be called entity service layer.

[0239] Login Service

[0240] The system can provide standardized system services to facilitate the rapid construction of a working system, or it can provide customized services to meet the individual requirements of different users.

[0241] Upon receiving a user login request, the system extracts relevant enterprise and user registration information and authorization details from the enterprise registration information based on the requested user information to verify the legitimacy of the user's login operation. For legitimate users, the system sends their information to the configuration service to deploy the runtime environment for the current session. After successful environment setup, the system sets the user's online status and generates a unique session identifier for authentication and secure information transmission between the user and the cloud service. The login service then sends a login success message back to the user. For users who fail to log in, a login rejection message will be returned.

[0242] Interface Service

[0243] The interface service interacts directly with the user, is responsible for receiving the user's access request, can convert the user's operation into a service request and send it to the cloud for subsequent services, such as scheduling services, and send the processing result back to the user. In addition, it also needs to collect the system's dynamic control information and feed it back to the user.

[0244] Interface services can be standardized system services provided by the system to facilitate the rapid construction of a working system, or they can be customized services to meet the personalized requirements of different users.

[0245] Business Service

[0246] Entity services that implement or assist in implementing specific business processes are collectively referred to as business services, including both schedulable and non-schedulable services. Business services can provide standardized business processes for different companies across the industry, which helps improve service quality and reduce costs, or they can be customized for specific enterprises.

[0247] A business service may be a standalone service or a system. Upon receiving a call request from the scheduling service, it performs relevant business logic processing. The business service accesses data using the logical name of the data source, achieving decoupling of data access. After sending a data access request to the data service, it waits for the data service to parse the logical name of the data source and extract the required data, returning it to the business service. The business service's processing result is then sent back to the scheduling service according to a standard data exchange format. Further, the data is transformed by a parameter conversion service before being sent back to the user who made the request.

[0248] Shadow Service

[0249] As it is an unschedulable service, the client-side business flow encoding and service registration will not contain any information about the shadow service.

[0250] To complete a business operation, you can either call a business service or a series of sub-services. The latter typically uses a facade pattern. A shadow service is a sub-service within this facade, performing specific business processing. It is not schedulable, requires no registration, and is indirectly accessed by users through the facade service. It is a transparent service to the user and forms a tight coupling with the facade service.

[0251] The facade service is a special schedulable service that does not perform actual business processing; it merely provides an entry point for users to handle business logic. The shadow service can access data either by sending requests to the data service through the facade service proxy or directly to the data service. The processing results of the shadow service are also returned to the user by the scheduling service through the facade service. It is important to note that both the shadow service and the facade service must use the logical name of the data source when accessing data to ensure data decoupling.

[0252] Standard Service

[0253] It is a highly reusable and coded service used for standardized transaction processing. It can be either a schedulable or unschedulable service, and is usually open to all authorized services in the cloud. It can be commercially managed and is the most important commercial asset of SOA systems for industries.

[0254] Business services can invoke any authorized standard service using entity services. However, when the standard service is a callable service, the client still needs to invoke it using the service logical name.

[0255] Many standard services in the system are microservices, providing standardized, composable processing units. Patterned business services can also be gradually iterated and solidified into standard services, which not only generates commercial benefits but also promotes continuous improvement and evolution of the overall system performance.

[0256] To gain a clearer understanding of how the BSoC platform works, it is necessary to analyze the operation process of a simple SOA application system. Specifically, this involves analyzing the working process of the two core system services, scheduling service and data service, to reveal the dynamic operation mechanism of the BSoC platform.

[0257] This is a very simple SMS system (APP_SMS) that provides basic customer information maintenance and SMS sending / receiving functions for enterprises. The example demonstrates the mapping, lookup, and implementation process between logical services and entity services. It shows how multiple user roles can achieve different entity service mappings under the same business flow coding, as well as the mapping from logical data to entity data. The description of these dynamic execution processes clearly demonstrates the decoupling logic between services and data. The coding modifications between entity services and business flows are independent and do not interfere with each other. This forms an ecosystem where different development vendors can work independently yet collaborate with each other. Furthermore, different users and enterprises can maximize service reuse while ensuring the security of operational permissions and data isolation.

[0258] The parsing process of scheduling services

[0259] The BSoC system decouples user service requests from control logic through a scheduling service, which utilizes information related to service registration and enterprise registration. User-initiated service requests are isolated from the actual services in the business flow coding by the service logical name. This enables stability and polymorphism in the business flow coding, reduces coding maintenance, and separates application service upgrades and modifications, forming two isolated layers: business flow coding and entity services. This truly leverages the full flexibility and reusability offered by the SOA architecture.

[0260] Figures 10a to 10i Define the enterprise, services, and data for an SMS system APP_SMS. Before making a service request, the enterprise user must first log in. The construction service is responsible for establishing the set of authorized operation services for the user, which is provided to the scheduling service as the user's runtime environment information. The scheduling service then parses the services based on the authorization information of this user's runtime environment.

[0261] Under the BSoC architecture, taking a service request from this application system as an example, a typical business flow accessing a service involves four elements: Enterprise (COM_SS), Application (APP_SMS), User (User_MANAGER), and Logical Service (SV_SendSMS). When a user requests service processing from the cloud according to the coding process, the scheduling service is responsible for resolving the logical service into an entity service and redirecting the request to the actual application service. The processing result is then returned to the requesting user along the original path. The timing logic of the operation can be seen in Figure 3. It is important to note that this SOA system demonstration is not a customized enterprise system, but rather one that can serve multiple enterprises simultaneously. Furthermore, multiple applications from a single enterprise can run on this platform. Therefore, each service call request will carry information about the enterprise (COM_SS) and application (APP_SMS). For simplicity, the enterprise and application information will not be repeated. The specific steps are described below:

[0262] 1. The user (User_MANAGER) sends a logical service (SV_SendSMS) request to the cloud-based interface service through business flow coding.

[0263] 2. Upon receiving the request, the UI service forwards it to the parameter transformation service for parameter normalization verification and processing, and then forwards the normalization request to the scheduling service.

[0264] 3. The scheduling service checks the validity of the user's (User_MANAGER) request to the logical service (SV_SendSMS):

[0265] Retrieve the user's roles. A user can have multiple roles: User_MANAGER has been authorized to have the role Role_MANAGER (see attached). Figure 10h );

[0266] Retrieve the service groups authorized by the user's role. Each role can have multiple groups: The role_MANAGER is authorized to access three service groups: SG_COMMON, SG_MAINTAIN, and SG_SMS (see attached). Figure 10f );

[0267] Retrieve the group to which the logical service to be accessed belongs, and intersect it with the authorized service groups obtained from the user previously. This will give you a list of all authorized groups: Logical service (SV_SendSMS) belongs to SG_MAINTAIN, SG_SMS (attached) Figure 10a Therefore, User_MANAGER confirms that there is access authorization for the logical service (SV_SendSMS).

[0268] 4. Based on the list of authorized service groups obtained in step 3, in Figure 10a The service registry is used to locate the set of records related to the requested logical service in the corresponding authorized service group. These records are then sorted in descending order by service level. The first record whose service level is no higher than the user level is the most suitable entity service for the logical service. The scheduling service will then send a call request to this entity service.

[0269] Confirm the logical service (SV_SendSMS) corresponding to the entity service (SR_SendSMS). Figure 10a );

[0270] Location and invocation parameters of the Entity Retrieval Service (SR_SendSMS) (see appendix) Figure 10i );

[0271] Send a call request to the entity service (SR_SendSMS).

[0272] 5. The entity service (SR_SendSMS) is a facade service (see attached). Figure 10i It does not directly process business requests. Instead, it determines whether the number belongs to China Telecom, China Mobile, or China Unicom based on the phone number in the input parameters. For example, if the number belongs to China Telecom, the entity service (SR_SendSMS) will forward the business processing request to the shadow service (SS_SendSMS_CTCC).

[0273] 6. The shadow service (SS_SendSMS_CTCC) performs business processing and sends the results back to the facade service (SR_SendSMS).

[0274] 7. The facade service (SR_SendSMS) returns the processing result to the scheduling service.

[0275] 8. The scheduling service returns the results to the user User_MANAGER through the interface service.

[0276] It should be noted that before users on the enterprise side can issue logical services, a login security verification process must be completed. The relevant timing procedures can be found in [reference needed]. Figure 8 Furthermore, the construction service builds the runtime environment for subsequent logical services, and the operations performed in step 4 above can be pre-optimized by the construction service. However, the security verification process involves details of sensitive operations, and each enterprise will formulate its own operation sequence. In principle, BSoC does not mandate a unified secure login mechanism, but only specifies the standard for runtime environment information that needs to be established after the security test is completed. Therefore, the detailed operation process of the login process will not be described here.

[0277] Data service parsing process

[0278] In the example above, the entity service (SR_SendSMS) processing involves data access. The entity service's code handles data access requests using a logical data source. The same logical data source can correspond to different entity data sources in different companies and applications. This ensures that the same entity service can access different data sources without modifying the code, thus decoupling the code from the data. For details on the mapping relationship between logical data sources and entity data sources, please refer to [link to documentation / reference]. Figure 10e .

[0279] In addition to calling logical services, business flow coding also includes requests to access data. Similar to entity services, these data access requests are also handled using logical data sources in the coding, and access to entity data is achieved through the same logical mapping relationship with entity data sources. The parsing and translation process from logical data sources to entity data sources described above is handled by the data service. For a complete sequence of operations involving calling the data service, please refer to [reference needed]. Figure 9 .

[0280] Data sources are broadly categorized into two types: data files and databases. Each enterprise and each application system corresponds to one or more logical data sources. Each data source belongs to one or more service groups; conversely, each service group can also have one or more logical data sources. When a user requests an entity service and attempts to access data corresponding to a logical data source, the authorized service group can be obtained based on the user's role. (See [link to relevant documentation]). Figure 10f This also grants access authorization to the logical data source corresponding to the authorized service group. See [link / reference] Figure 10d .

[0281] Using the service request example above, we will examine the basic working principle of data services by analyzing the parsing of two data types. When the enterprise user's logical service (SV_SendSMS) request is parsed into the entity service (SR_SendSMS), it is assumed that an access operation will be performed on a data file and a database respectively (in the previous example, this should be the actual operation performed by the shadow service SS_SendSMS_CTCC). The following discussion addresses these two scenarios separately.

[0282] The data service operates on data files, with the logical data source name being DV_LOG and the file name being SMSLOG.TXT.

[0283] 1. Retrieve Service Group List: Based on the user's (User_MANAGER) role (Role_MANAGE), locate all authorized groups (SG_COMMON, SG_MAINTAIN, SG_SMS). See [link / description]. Figure 10f .

[0284] 2. Confirm authorized access to the logical data source: Based on the enterprise (COM_SS), application system (APP_SMS), and logical data source (DV_LOG), retrieve the authorized service groups (SG_COMMON, SG_MAINTAIN, SG_SMS). See [link / reference] Figure 10d If there is an overlap between the logical data source authorization and the service group list from the first step, then the logical data source authorization is confirmed.

[0285] 3. Locating the entity data source from the logical data source: Based on the logical data source (DV_LOG), locate the corresponding entity data source (DR_LOG) and related data source attribute information, including the IP address (132.178.5.202) and storage directory (BUSINESS / Enterprise / COM_SS / LOG). See [link / details]. Figure 10e .

[0286] 4. Accessing data files: Combine the file name (SMSLOG.TXT) and storage directory (BUSINESS / Enterprise / COM_SS / LOG) to form complete file and path information. After locating the specific data server via IP (192.168.5.202), perform the actual file access operation through the path file information.

[0287] 5. Return the file operation results to the shadow service (SS_SendSMS_CTCC)

[0288] 6. The shadow service (SS_SendSMS_CTCC) returns the result to the facade service (SR_SendSMS).

[0289] The data service operates on the database, and the logical data source name is DV_DATA.

[0290] 1. Same as step 1 for data file types;

[0291] 2. For the same data file type, in step 2, change the logical data source to (DV_DATA);

[0292] 3. Locating the entity data source from the logical data source: Based on the logical data source (DV_DATA), locate the corresponding entity data source (DR_DATA) and related data source attribute information, including the IP address (132.178.1.10:80) and the database connection parameter file (BUSINESS / Enterprise / COM_SS / DATACONNECT.INI) containing the storage path. See [link / details]. Figure 10e .

[0293] 4. Read the parameters from the database connection parameter file and attach network connection information to different types of database operation commands to enable them to access network databases.

[0294] 5. Send the processed database operation commands to the entity database and receive the results returned by the database processing.

[0295] 6. Return the database processing results to the shadow service (SS_SendSMS_CTCC)

[0296] 7. The shadow service (SS_SendSMS_CTCC) returns the result to the facade service (SR_SendSMS).

[0297] It's important to note that the logical data source definition described above refers to a data source customized by the enterprise in the cloud. Similarly, the cloud will also provide public data sources and system-level data sources. A public data source is a logical data source accessible to all companies and can be referenced in business flow coding and customized service coding. A system-level data source does not publicly expose its data interface; only standard services can reference this logical data source. Both public and system-level data sources have similar parameter definitions to enterprise-level data sources, and their definitions and specific operational procedures are largely the same, so they will not be repeated here.

[0298] The above analysis of the scheduling and data service processes is only a principle analysis of the feasibility of two key services or service clusters. The specific implementation requires comprehensive consideration of many aspects such as cloud network hardware structure, load balancing, distributed processing and storage, and more complex instantiation design based on the basic principle of decoupling.

Claims

1. A BSoC hybrid cloud dynamic deployment system, characterized in that, include: The system data layer in the public cloud, which is geared towards the hybrid cloud, is used to store the list of data and logical services that need to be migrated and synchronized between the public cloud and the private cloud, the direction and operation method of migration and synchronization, and the current status information of migration and synchronization. The system service layer of the public cloud is designed for a dynamic deployment mechanism for hybrid clouds, and is used to migrate and synchronize data and services between the public cloud and the private cloud. The system data layer of the private cloud is used to register the mapping relationship between the logical service name and the entity service name of the private cloud, the mapping relationship between the logical data source and the entity data source, the local logical service list, and the access authorization information of enterprise users, for the system service layer of the private cloud to parse and call. The system service layer of the private cloud is used to locate the cloud where the logical service requested by the user resides; when the logical service belongs to the private cloud, the logical service is parsed and invoked; when migration and synchronization are required, it works with the system service layer of the public cloud to achieve data and service migration and synchronization between the hybrid cloud in accordance with the dynamic deployment mechanism of the hybrid cloud. The public cloud-oriented system data layer for hybrid cloud includes: The synchronized data list, deployed on the public cloud, is used to register the list of entity data that can be migrated and synchronized, the direction and operation method of migration and synchronization, and the status information of the data currently being migrated and synchronized. The synchronization service list, deployed on the public cloud, is used to register the list of logical services that can be migrated and synchronized, the direction and operation method of migration and synchronization, and the status information of the logical services currently being migrated and synchronized. The system service layer of the public cloud for the hybrid cloud dynamic deployment mechanism includes: The synchronization server, deployed on the public cloud, consists of a set of services for data and service migration and synchronization between the public and private clouds. It adopts the BSoC hybrid cloud dynamic deployment mechanism. That is, after setting the services to be migrated, their migration direction, and migration method in the synchronization service list, and setting the data list to be migrated, their migration direction, and migration method in the synchronization data list, the set of services obtains the entity service and entity data source information from the public cloud based on the service registration and enterprise registration information, or obtains the entity data source information from the autonomous application server in the private cloud. This enables the migration and synchronization of application services and data from the public cloud to the private cloud, or from the private cloud to the public cloud. The system data layer of the private cloud includes: The local logical service list, deployed on a private cloud, provides information on all logical services deployed locally and their current status. It is automatically generated by the autonomous application server after the migration and synchronization operation is completed, and the service status is maintained and modified manually. The autonomous application server stores local service registration information, user authorization information, and a mapping table between logical data sources and entity data sources. The local service registration information is used to provide the mapping relationship between logical services and entity services, as well as the calling and authorization attributes. It is migrated and synchronized between the service registration information of the autonomous application server and the public cloud. The user authorization information is maintained locally and is not migrated and synchronized. The mapping table between the logical data source and the entity data source has the logical data source name migrated and synchronized by the corresponding content in the enterprise registration information in the autonomous application server and the public cloud. The mapping relationship between the entity data source and the logical data source is manually reconfigured locally without migration and synchronization. The system service layer of the private cloud includes: The service-oriented server is deployed in a private cloud. Only when the BSoC hybrid cloud dynamic deployment mechanism is adopted, the service-oriented server is deployed on the user's front end. The local logical service list and service status are used to locate the cloud where the logical service for each user request is located, and the application service request is sent to the cloud where it is located by the identity proxy of the virtual user. The autonomous application server, deployed in a private cloud, includes construction services, login services, interface services, parameter conversion services, scheduling services, data services, and application services. It implements the same BSoC system functions as the public cloud and provides services to work in conjunction with the public cloud synchronization server to complete the migration and synchronization of application services and data.

2. The BSoC hybrid cloud dynamic deployment system according to claim 1, characterized in that, The BSoC system, deployed on a private cloud, shares the same PaaS system architecture as the public cloud, including: The system data layer is used to register the mapping relationship between logical services and entity services, and to store enterprise user information, registration information of callable services, and access authorization information. The system service layer is used to achieve enterprise-wide user security management, standardization and optimization of user and cloud service requests, parsing and scheduling of service requests, and parsing of service access to data sources through interaction with the system data layer and application service layer; it initiates requests to entity services through parsing of logical services to achieve decoupling of access to entity services; and it decouples access to entity data sources through data access in the form of logical data sources. The application service layer is used to respond to the service scheduling of the cloud system and provide actual application service processing for users between enterprises.

3. The BSoC hybrid cloud dynamic deployment system according to claim 2, characterized in that, The system data layer includes: Service registration is used to register all services called by users, provide relevant service attribute information, group services, and define the mapping relationship between users' logical service names and entity service names; Enterprise registration is used to store enterprise and user registration information, role group authorization status, and a mapping table between logical data source names and entity data source names. The authorization domain is used to store the access security policy of the logged-in user during the current session, the mapping table of all logical services and entity services for authorization operations, and the mapping table of logical data source names and entity data source names, for the scheduling service to retrieve.

4. The BSoC hybrid cloud dynamic deployment system according to claim 2, characterized in that, The system service layer includes: The construction service is used to obtain authorized user information through the login service, construct the authorization domain for the user session based on the information in the service registration and enterprise registration, and notify the user to process subsequent business requests through the login service. The scheduling service receives logical service requests from users from the interface service, then redirects the logical service requests to entity service requests through the authorization domain, and performs normalization processing on the parameter sequence passed from the logical service through the parameter transformation service to obtain the entity service parameter list, and sends a call request to the entity service. Finally, the processing result obtained by the entity service in performing business processing according to the call request is fed back to the requesting user. The parameter conversion service is used to convert the list of logical service parameters into the parameter call relationship of the corresponding entity service based on the parameter conversion relationship obtained from the authorized domain, and return it to the scheduling service. The data service is used to obtain the mapping table between logical data source names and entity data source names from the authorized domain, convert the entity service's access request to the logical data source into an access request to the entity data source, and provide conversion between different database access formats.

5. The BSoC hybrid cloud dynamic deployment system according to claim 2, characterized in that, The application service layer includes: The login service is a non-schedulable service. Upon receiving a user login request, it retrieves the corresponding enterprise and user registration information from the enterprise registration and the authorization information from the enterprise authorization to verify the legitimacy of the user's login operation on the application system. The legitimate user sends the user information to the construction service. The interface service is a non-schedulable service used to interact with users, receive user access requests, convert user operation sequences into logical service requests and send them to the scheduling service, obtain processing results from the scheduling service and send them back to the user, and also provide users with pre-set operable business interfaces. The business service is a schedulable service. After receiving a call request from the scheduling service, it performs business logic processing, and after the processing results are transformed by the parameter conversion service and the scheduling service, they are sent back to the user who made the call request. Shadow services are unschedulable services used for business logic processing. They are isolated from the user's service call relationship. The calling methods between a group of shadow services are directly called using the entity service name. The Façade service is a schedulable service used to provide a unified external calling interface for shadow services; Standard services, which can be scheduled or unschedulable, are used to standardize business processes so that other business services can directly call them.

Images