A design method of PaaS cloud system facing industry SOA

Abstract

This invention proposes a cloud-based PaaS architecture design, providing an intelligent SOA solution for various industries with a centralized control mechanism. The system, through two core services—scheduling and data services—and meticulous design arrangements and constraints on data exchange, isolates and decouples application-side code from the cloud system at various data and control levels. This provides a platform for constructing a widely applicable, highly flexible, scalable, and easily maintainable SOA system. Leveraging the scalability and global accessibility of cloud resources, application services can be moved outside of enterprise firewalls, potentially enabling a commercially viable SOA service system for various industries. As the system evolves, it fosters a virtuous cycle of interaction among numerous upstream and downstream service companies, significantly reducing users' hardware and software costs and development time, improving service quality, and unlocking the immense potential of the SOA system, thus driving a transformation in software design and service architecture.

Description

Technical Field

[0001] This invention belongs to the field of SOA and cloud computing platforms, specifically a PaaS cloud architecture design method and system for providing a running platform for SOA systems oriented towards industries. Background Technology

[0002] Currently, numerous service-oriented and microservice architectures derived from the service-based SOA architecture have become the mainstream of current Internet and cloud technologies.

[0003] SOA architecture promises higher levels of service encapsulation, loose coupling, statelessness, high reusability, composability, and maintainability, among other advantages. However, fulfilling these promises means that the complexity of service coding far exceeds traditional coding models. Therefore, implementing a complete business system using SOA will significantly exceed the budget and cause project delays, especially when SOA business systems are customized for specific users. These problems are particularly pronounced, and the costs may far outweigh the benefits. Thus, through continuous trial and error, service architectures have gradually developed into independent, highly reusable, general-purpose services and service systems. However, SOA has reached a dead end due to the lack of a suitable technological development path.

[0004] However, the advantages of SOA are obvious, and to date, no better service architecture for building business systems can match it. Therefore, how to distribute the increased costs and delivery delays caused by this complexity is a fundamental technical starting point for breaking through the cocoon.

[0005] First, SOA needs to be moved out of the enterprise's firewall and onto the cloud. By reusing services, SOA can serve more enterprises instead of a single user, thereby reducing the cost of building a single project. To achieve this goal, effective static and dynamic management of industry-oriented SOA services is required. By introducing various static service layering and grouping management mechanisms, and using centralized control technology, a dynamic management mechanism for service operation can be provided. This allows services to be organized, forming a synergy, enabling the system to run and iterate continuously and orderly.

[0006] By introducing logical services and logical data sources at the user level, the relationships between various business services and service combinations are further decoupled from both the control flow and data flow perspectives. The benefits include that the coding on the enterprise side and the cloud side can achieve their own independence, allowing coding work at different levels to not interfere with each other and to iterate independently. Different types of teams can collaborate and divide tasks, laying a good foundation for building an SOA ecosystem service system. Through continuous service iteration and upgrades from customized to generalized, the system gains the ability to continuously optimize and evolve, thereby obtaining potential commercial benefits. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention provides a PaaS cloud system platform for industry-oriented SOA application systems. To ensure the stable operation of PaaS, it is necessary to propose some principled design specifications, a hierarchical grouping management model, and a dynamic central control mechanism for the coding of cloud-based services and enterprise-side business flows. This invention combines the initial design concepts of SOA with cloud computing to construct a PaaS platform running in the cloud.

[0008] The technical solution adopted by the present invention to achieve the above objectives is as follows:

[0009] A PaaS cloud system running industry-oriented SOA includes:

[0010] 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.

[0011] 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.

[0012] 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.

[0013] The system data layer includes:

[0014] 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;

[0015] 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.

[0016] 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.

[0017] The system service layer includes:

[0018] 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.

[0019] 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.

[0020] 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.

[0021] 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.

[0022] The application service layer includes:

[0023] 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.

[0024] 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.

[0025] 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.

[0026] 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.

[0027] The service is a schedulable service used to provide a unified external calling interface for shadow services;

[0028] Standard services, which can be scheduled or unschedulable, are used to standardize business processes so that other business services can directly call them.

[0029] An implementation method for running a PaaS cloud system oriented towards industry SOA includes the following steps:

[0030] The system data layer registers the mapping relationship between logical services and entity services, and stores enterprise user information, registration information of callable services, and access authorization information;

[0031] The system service layer, through interaction with the system data layer and application service layer, enables 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; it initiates requests to entity services through parsing of logical services, thereby decoupling access to entity services; and it decouples access to entity data sources through data access in the form of logical data sources.

[0032] The application service layer responds to the service scheduling of the cloud system, providing actual application service processing for users between enterprises.

[0033] The system data layer performs the following steps:

[0034] The service registration registers all services invoked by users, provides attribute information of the relevant services, groups the services, and defines the mapping relationship between the logical service name and the entity service name of the user;

[0035] The enterprise registration storage includes enterprise and user registration information, role grouping and authorization details, as well as a mapping table between logical data source names and entity data source names.

[0036] The authorized domain stores the access security policy of the logged-in user during the current session, a mapping table of all logical services and entity services for authorized operations, and a mapping table of logical data source names and entity data source names, for the scheduling service to retrieve.

[0037] The system service layer performs the following steps:

[0038] The construction service obtains authorized user information through the login service, constructs the authorization domain for the user session based on the information in service registration and enterprise registration, and notifies the user to process subsequent business requests through the login service.

[0039] 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 entity service performs business processing based on the call request and feeds back the processing result to the requesting user.

[0040] The parameter conversion service converts the logical service parameter list into the parameter call relationship of the corresponding entity service based on the parameter conversion relationship obtained from the authorization domain, and returns it to the scheduling service;

[0041] The data service obtains the mapping table between logical data source names and entity data source names from the authorized domain, converts the entity service's access request to the logical data source into an access request to the entity data source, and provides conversion for different database access formats.

[0042] The application service layer performs the following steps:

[0043] After receiving a user login request, the login service extracts the corresponding enterprise and user registration information from the enterprise registration and the authorization information from the enterprise authorization, and verifies the legitimacy of the user's login operation on the application system. The legitimate user sends the user information to the construction service.

[0044] The interface service interacts with users, receives user access requests, converts user operation sequences into logical service requests, sends them to the scheduling service, obtains processing results from the scheduling service, sends them back to the user, and also provides users with pre-set operable business interfaces.

[0045] After receiving the call request from the scheduling service, the business service performs business logic processing, and then sends the processing results back to the user who made the call after passing through the parameter conversion service and the scheduling service in sequence.

[0046] Shadow services handle business logic and 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.

[0047] The service provides a unified external API for shadow services;

[0048] Standard services standardize business processes, allowing other business services to directly call upon them.

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

[0050] 1. This invention emphasizes service orientation towards business and achieves a fully loosely coupled design.

[0051] 2. This invention provides appropriate service design and information exchange standards.

[0052] 3. The business-oriented services of this invention meet the requirements of business agility.

[0053] 4. Safety and service quality are guaranteed.

[0054] 5. The size and budget of the enterprise system are effectively controlled.

[0055] 6. Balance enterprise data load response with security concerns.

[0056] 7. Data-driven test automation can be adopted, which facilitates the integration of development, testing and operation.

[0057] 8. Separate service coding, testing, data organization and business process system development, so that companies focused on business and those focused on technology can fully leverage their expertise and create a healthy collaborative ecosystem. Attached Figure Description

[0058] Figure 1 Business SOA over Cloud architecture hierarchy diagram;

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

[0060] Figure 3 Construct a sequence diagram for service startup and regular business service scheduling;

[0061] Figure 4 Data service call sequence diagram;

[0062] Figure 5a Service attributes during service registration;

[0063] Figure 5b Service registration: service groups;

[0064] Figure 5c Company information;

[0065] Figure 5d Enterprise application systems;

[0066] Figure 5e Enterprise data source definition;

[0067] Figure 5f Enterprise role definition;

[0068] Figure 5g Enterprise user information;

[0069] Figure 5h Enterprise user authorization;

[0070] Figure 5i Registration of physical services. Detailed Implementation

[0071] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.

[0072] BSoC Design Model Framework

[0073] See Figure 1 (BSoC architecture hierarchy diagram) and Figure 2 (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.

[0074] 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.

[0075] 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.

[0076] 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.

[0077] from Figure 3 and Figure 4 This allows us to understand the relationship between the specific service scheduling sequence and the data access sequence.

[0078] 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 2 In summary, the main services and system architecture data in the cloud primarily include:

[0079] System Data Layer

[0080] –Services Register

[0081] – Enterprise Registration

[0082] –Enterprise Authority

[0083] –Authorized operation space

[0084] System service layer

[0085] –Constructor Service

[0086] –Dispatching Service

[0087] – Parameter conversion service

[0088] – Data Service

[0089] Application service layer

[0090] Login Service

[0091] – Interface Service

[0092] –Business Service

[0093] – Shadow Service

[0094] Standard Service

[0095] We will introduce the roles of different system data and services in the system one by one.

[0096] System data

[0097] Services Register

[0098] 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.

[0099] Enterprise Registration

[0100] 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.

[0101] Enterprise Authority

[0102] 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.

[0103] Authorized operation space

[0104] 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.

[0105] 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.

[0106] System services

[0107] Constructor Service

[0108] 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.

[0109] Dispatching Service:

[0110] 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.

[0111] 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.

[0112] Parameter conversion service

[0113] 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:

[0114] 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.

[0115] 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.

[0116] 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.

[0117] Application services

[0118] 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.

[0119] Login Service

[0120] 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.

[0121] 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.

[0122] Interface Service

[0123] 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.

[0124] 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.

[0125] Business Service

[0126] 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.

[0127] 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.

[0128] Shadow Service

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

[0130] 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.

[0131] 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.

[0132] Standard Service

[0133] 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.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] 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.

[0138] The parsing process of scheduling services

[0139] 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.

[0140] Figures 5a to 5i 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.

[0141] In a 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 this operation can be found in [reference needed]. Figure 3It's 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 enterprise (COM_SS) and application (APP_SMS) information. For simplicity, the enterprise and application information will not be repeated. The specific steps are described below:

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

[0143] 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.

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

[0145] • 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 5h )

[0146] • 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,

[0147] SG_MAINTAIN, SG_SMS (attached) Figure 5f )

[0148] • Obtain the group to which the logical service to be accessed belongs, and find the intersection with the authorized service group obtained from the user earlier. This will give you a list of all authorized groups: the logical service (SV_SendSMS) belongs to SG_MAINTAIN,

[0149] SG_SMS (with appendix) Figure 5a Therefore, User_MANAGER confirms that there is access authorization for the logical service (SV_SendSMS).

[0150] 4. Based on the list of authorized service groups obtained in step 3, in Figure 5a 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.

[0151] • Confirm the logical service (SV_SendSMS) corresponding to the entity service (SR_SendSMS) ( Figure 5a )

[0152] • Location and invocation parameters for the Entity Retrieval Service (SR_SendSMS) (see appendix) Figure 5i )

[0153] • Send a call request to the entity service (SR_SendSMS)

[0154] 5. The entity service (SR_SendSMS) is a facade service (see attached). Figure 5i 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).

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

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

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

[0158] 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 3 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.

[0159] Data service parsing process

[0160] 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 5e .

[0161] 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 4 .

[0162] 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 5f This also grants access authorization to the logical data source corresponding to the authorized service group. See [link / reference] Figure 5d .

[0163] 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.

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

[0165] 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 5f .

[0166] 2. Confirm that the logical data source has authorized access: based on the enterprise (COM_SS) and application system (APP_SMS)...

[0167] And logical data source (DV_LOG), retrieve authorized service groups (SG_COMMON, SG_MAINTAIN, SG_SMS), see [link / reference] Figure 5d 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.

[0168] 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 (192.168.5.202) and storage directory (BUSINESS / Enterprise / COM_SS / LOG). See [link / details]. Figure 5e .

[0169] 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.

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

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

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

[0173] 1. Same as step 1 for data file types

[0174] 2. Similar to step 2 of the data file type, change the logical data source to (DV_DATA).

[0175] 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 (192.168.1.10:80) and the database connection parameter file (BUSINESS / Enterprise / COM_SS / DATACONNECT.INI) containing the storage path. See [link / details]. Figure 5e .

[0176] 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.

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

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

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

[0180] 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.

[0181] 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 PaaS cloud system running industry-oriented SOA, characterized in that, include: 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. 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. 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. 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.

2. The method for implementing a PaaS cloud system for industry-oriented SOA according to claim 1, characterized in that, Includes the following steps: The system data layer registers the mapping relationship between logical services and entity services, and stores enterprise user information, registration information of callable services, and access authorization information; The system service layer, through interaction with the system data layer and application service layer, enables 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; it initiates requests to entity services through parsing of logical services, thereby decoupling 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 responds to the service scheduling of the cloud system, providing actual application service processing for users between enterprises.

3. The method for implementing a PaaS cloud system for industry-oriented SOA as described in claim 2, characterized in that, The system data layer performs the following steps: The service registration registers all services invoked by users, provides attribute information of the relevant services, groups the services, and defines the mapping relationship between the logical service name and the entity service name of the user; The enterprise registration storage includes enterprise and user registration information, role grouping and authorization details, as well as a mapping table between logical data source names and entity data source names. The authorized domain stores the access security policy of the logged-in user during the current session, a mapping table of all logical services and entity services for authorized operations, and a mapping table of logical data source names and entity data source names, for the scheduling service to retrieve.

4. The method for implementing a PaaS cloud system for industry-oriented SOA according to claim 2, characterized in that, The system service layer performs the following steps: The construction service obtains authorized user information through the login service, constructs the authorization domain for the user session based on the information in service registration and enterprise registration, and notifies 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 entity service performs business processing based on the call request and feeds back the processing result to the requesting user. The parameter conversion service converts the logical service parameter list into the parameter call relationship of the corresponding entity service based on the parameter conversion relationship obtained from the authorization domain, and returns it to the scheduling service; The data service obtains the mapping table between logical data source names and entity data source names from the authorized domain, converts the entity service's access request to the logical data source into an access request to the entity data source, and provides conversion for different database access formats.

5. The method for implementing a PaaS cloud system for industry-oriented SOA according to claim 2, characterized in that, The application service layer performs the following steps: After receiving a user login request, the login service extracts the corresponding enterprise and user registration information from the enterprise registration and the authorization information from the enterprise authorization, and verifies 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 interacts with users, receives user access requests, converts user operation sequences into logical service requests, sends them to the scheduling service, obtains processing results from the scheduling service, sends them back to the user, and also provides users with pre-set operable business interfaces. After receiving the call request from the scheduling service, the business service performs business logic processing, and then sends the processing results back to the user who made the call after passing through the parameter conversion service and the scheduling service in sequence. Shadow services handle business logic and 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 provides a unified external calling interface for shadow services; Standard services standardize business processes, allowing other business services to directly call upon them.

Images