CN113645251A - Data transmission method and device suitable for cross-regional service - Google Patents

Data transmission method and device suitable for cross-regional service Download PDF

Info

Publication number
CN113645251A
CN113645251A CN202110977550.9A CN202110977550A CN113645251A CN 113645251 A CN113645251 A CN 113645251A CN 202110977550 A CN202110977550 A CN 202110977550A CN 113645251 A CN113645251 A CN 113645251A
Authority
CN
China
Prior art keywords
service
middleware
target
domain
subordinate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202110977550.9A
Other languages
Chinese (zh)
Other versions
CN113645251B (en
Inventor
陈德贵
张玉兵
邓雅硕
杜江
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Yingchuangsi Information Technology Co ltd
Original Assignee
Beijing Yingchuangsi Information Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Yingchuangsi Information Technology Co ltd filed Critical Beijing Yingchuangsi Information Technology Co ltd
Priority to CN202110977550.9A priority Critical patent/CN113645251B/en
Publication of CN113645251A publication Critical patent/CN113645251A/en
Application granted granted Critical
Publication of CN113645251B publication Critical patent/CN113645251B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/133Protocols for remote procedure calls [RPC]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/546Message passing systems or structures, e.g. queues
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/562Brokering proxy services
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/547Messaging middleware

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The embodiment of the specification provides a data transmission method and device suitable for cross-regional service. The method is applied to a first middleware adopting an enterprise service bus technology, the first middleware is any middleware in a plurality of middleware corresponding to a plurality of mechanisms with a superior-subordinate relationship, the first middleware stores routing configuration information, and the routing configuration information comprises a first service domain configured for the first mechanism corresponding to the first middleware and service information of each service under the first service domain, and the method comprises the following steps: receiving a service calling request, wherein the service calling request comprises a service identifier of a target service to be called; determining whether the target service belongs to a first service domain or not according to the service identification and the routing configuration information; if so, calling the target service according to the service calling request and the service information of the target service in the route configuration information; if not, responding to the first mechanism that the upper mechanism has no lower mechanism, and forwarding the service calling request to a second middleware corresponding to the upper mechanism.

Description

Data transmission method and device suitable for cross-regional service
Technical Field
The embodiment of the specification relates to the technical field of computers, in particular to a data transmission method and device suitable for cross-regional service.
Background
With the continuous development of enterprise informatization, the number of information systems in an enterprise is gradually increased, and the information systems generally have the problems of mutual information sharing, system integration and the like, so that a Service-Oriented Architecture (SOA) is developed.
The SOA solves the interface standard of the service call of the system in the enterprise. However, when the number of enterprise information systems reaches a certain number, the enterprise can have a spider-web system structure, which causes obstacles for further upgrading of enterprise informatization. Then, an Enterprise Service Bus (ESB) is born. The ESB is a key part of an infrastructure used when an SOA-based solution is constructed, provides the most basic connection center in a network, and is an essential middleware for system integration of enterprises.
When the enterprise develops to a group scale, the informatization requirement is higher, each sub-enterprise generally has an own information system group, and information sharing requirements exist between the parent enterprise and the sub-enterprise as well as between the sub-enterprise and the sub-enterprise. In practice, in a plurality of enterprises having parent-child relationships, the services provided by information system groups of different enterprises are generally located in different areas, which may be physical areas or virtual areas. Typically, services located in different areas are generally not able to communicate directly.
It should be noted that the parent enterprise may be regarded as a superior organization, and the child enterprises of the parent enterprise may be regarded as subordinate organizations. In addition to enterprises, other organizations (such as schools or government organizations) with a hierarchical relationship have the problem that information sharing needs exist but services cannot be directly communicated.
Therefore, a reasonable and reliable scheme is urgently needed, which can realize data transmission among the cross-regional services, so that the cross-regional services can share information.
Disclosure of Invention
The embodiment of the specification provides a data transmission method and device suitable for cross-regional service, which can realize data transmission among the cross-regional service, so that the cross-regional service can share information.
In a first aspect, an embodiment of the present specification provides a data transmission method suitable for a cross-regional service, which is applied to a first middleware adopting an enterprise service bus technology, where the first middleware is any middleware in multiple middleware corresponding to multiple organizations having a hierarchical relationship, and the first middleware stores routing configuration information, where the routing configuration information includes a first service domain configured for a first organization corresponding to the first middleware and service information of each service in the first service domain, and each service includes all services provided by multiple service systems of the first organization, and the method includes: receiving a service calling request, wherein the service calling request comprises a service identifier of a target service to be called; determining whether the target service belongs to the first service domain according to the service identifier and the routing configuration information; under the condition that the target service is determined to belong to the first service domain, calling the target service according to the service calling request and the service information of the target service in the routing configuration information; in an instance in which it is determined that the target service does not belong to the first service domain, in response to the first authority having a superior authority without a subordinate authority, forwarding the service invocation request to a corresponding second middleware of the superior authority among the plurality of middleware.
In some embodiments, the service invocation request is received from any of: one of the services, the second middleware, and a third middleware corresponding to any lower-level mechanism of the first mechanism among the plurality of middleware.
In some embodiments, the service invocation request is specifically a request for obtaining data from the target service, or a request for sending data to the target service.
In some embodiments, the routing configuration information further comprises a communication address of the second middleware; and forwarding the service invocation request to a second middleware corresponding to the superior authority in the plurality of middleware, including: and forwarding the service calling request to the second middleware according to the communication address.
In some embodiments, when the first organization has subordinate organizations, the routing configuration information further includes association information of each subordinate organization of the first organization, the association information including a second service domain configured for its corresponding subordinate organization and service information of services opened to other organizations by a plurality of business systems of the subordinate organization; and in the event that it is determined that the target service does not belong to the first service domain, further comprising: determining whether the target service belongs to a second service domain of one of the subordinate organizations according to the service identification and the routing configuration information in response to the first organization having subordinate organizations; and in the case that the target service is determined to belong to a second service domain of one of the subordinate agencies, forwarding the service invocation request to a third middleware corresponding to the target subordinate agency in the plurality of middleware, wherein the target subordinate agency is a subordinate agency corresponding to the second service domain to which the target service belongs.
In some embodiments, after said determining whether said target service belongs to a second service domain of one of said respective subordinate enterprises, further comprising: in an instance in which it is determined that the target service does not belong to a second service domain of one of the respective subordinate enterprises, forwarding the service invocation request to the second middleware in response to the first enterprise having a superior enterprise.
In some embodiments, after said determining whether said target service belongs to a second service domain of one of said respective subordinate enterprises, further comprising: in a case where it is determined that the target service does not belong to the second service domain of one of the respective subordinate authorities, feeding back a service abnormality notification message to an original sender of the service invocation request in response to the first authority not having a superior authority.
In a second aspect, an embodiment of the present specification provides a data transmission apparatus suitable for a cross-regional service, which is applied to a first middleware that uses an enterprise service bus technology, where the first middleware is any middleware in a plurality of middleware corresponding to a plurality of organizations having a hierarchical relationship, and the first middleware stores routing configuration information, where the routing configuration information includes a first service domain configured for a first organization corresponding to the first middleware and service information of each service in the first service domain, and each service includes all services provided by a plurality of service systems of the first organization, and the apparatus includes: a receiving unit configured to receive a service invocation request including a service identification of a target service to be invoked; a determining unit configured to determine whether the target service belongs to the first service domain according to the service identifier and the routing configuration information; a first processing unit, configured to, in a case where the determining unit determines that the target service belongs to the first service domain, invoke the target service according to the service invocation request and service information of the target service in the routing configuration information; a second processing unit configured to forward the service invocation request to a corresponding second middleware of the superior authority among the plurality of middleware in response to the first authority having a superior authority without a subordinate authority if the determining unit determines that the target service does not belong to the first service domain.
In a third aspect, the present specification provides a computer-readable storage medium, on which a computer program is stored, wherein when the computer program is executed in a computer, the computer is caused to execute the method described in any implementation manner in the first aspect.
In a fourth aspect, the present specification provides a computing device, including a memory and a processor, where the memory stores executable code, and the processor executes the executable code to implement the method described in any implementation manner of the first aspect.
In a fifth aspect, the present specification provides a computer program, wherein when the computer program is executed in a computer, the computer is caused to execute the method described in any implementation manner of the first aspect.
The data transmission method and apparatus suitable for the cross-regional service provided by the above embodiments of the present specification can enable the first middleware adopting the ESB technology to store the routing configuration information including the following contents: the first service domain configured by the first mechanism corresponding to the first middleware and the service information of each service in the first service domain are aimed at, so that after the first middleware receives the service invocation request, whether the target service to be invoked belongs to the service domain (namely the first service domain) is judged according to the routing configuration information. The first middleware may invoke the target service upon determining that the target service belongs to the local service domain. When it is determined that the target service does not belong to the service domain, if the first mechanism has a higher-level mechanism and does not have a lower-level mechanism, the first middleware may forward the service invocation request to a second middleware corresponding to the higher-level mechanism, so that the second middleware processes the service invocation request. For example, when the target service is a service under the service domain of the superior authority, the second middleware may call the target service; when the target service is a service under a service domain of a certain subordinate of the superior authority (e.g., a certain sibling of the first authority, etc.), the second middleware may forward the service invocation request to a middleware corresponding to the subordinate, so that the middleware invokes the target service. Therefore, data transmission among the cross-regional services can be realized through the plurality of cascaded middleware, so that the cross-regional services can share information.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments disclosed in the present specification, the drawings needed to be used in the description of the embodiments will be briefly introduced below, it is obvious that the drawings in the following description are only embodiments disclosed in the present specification, and it is obvious for those skilled in the art to obtain other drawings based on the drawings without creative efforts.
FIG. 1 is an exemplary system architecture diagram to which some embodiments of the present description may be applied;
FIG. 2 is a schematic diagram of one embodiment of a data transmission method suitable for cross-region services;
fig. 3 is a schematic diagram of a data transmission apparatus suitable for cross-region service.
Detailed Description
The present specification will be described in further detail with reference to the accompanying drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the relevant invention and not restrictive of the invention. The described embodiments are only a subset of the embodiments described herein and not all embodiments described herein. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step are within the scope of the present application.
It should be noted that, for convenience of description, only the portions related to the related invention are shown in the drawings. The embodiments and features of the embodiments in the present description may be combined with each other without conflict.
As described above, there is a problem that services cannot be directly communicated with each other, although there is a need for information sharing between organizations having a hierarchical relationship.
Based on this, some embodiments of the present specification provide a data transmission method suitable for a cross-regional service, by which data transmission between cross-regional services can be implemented, so that the cross-regional service can perform information sharing. In particular, FIG. 1 illustrates an exemplary system architecture diagram suitable for use with these embodiments.
As shown in fig. 1, a service domain configured for each of a plurality of organizations having a hierarchical relationship (e.g., the parent enterprise a shown in fig. 1 and the child enterprise B, C of the parent enterprise a), each service under the service domain, and a plurality of pieces of middleware corresponding to the plurality of organizations are shown.
The service domain is generally used to distinguish physical areas or virtual areas where different system services are located. Typically, different organizations have different service domains.
For any one of the plurality of organizations, each service under the service domain of the organization may include all services provided by the plurality of business systems of the organization. In practice, the plurality of business systems of an organization may include various systems used within the organization. Taking an enterprise as an example, the plurality of business systems of the enterprise may include, for example, a plurality of systems in an employee management system, a financial management system, a project management system, an attendance system, a security system, and the like used inside the enterprise.
Any one of the above plural middleware uses the ESB technology, and can communicate with each service under the service domain of the corresponding organization, and can communicate with the middleware corresponding to the upper organization and the lower organization of the organization. It is to be noted that the upper mechanism generally refers to a direct upper mechanism, and the lower mechanism generally includes a direct lower mechanism and an indirect lower mechanism (e.g., a lower mechanism of a lower mechanism). In addition, any one of the above-described plurality of middleware may be referred to as an ESB middleware.
In practice, routing configuration is generally required before data transmission between cross-regional services is realized. Specifically, for any one of the plurality of organizations, for example, the sub-enterprise B shown in fig. 1, the service domain of the sub-enterprise B and the service information of all the services provided by the plurality of business systems of the sub-enterprise B may be registered in the ESB middleware corresponding to the sub-enterprise B. The service information may include, for example, a service identifier of a service corresponding to the service, an adopted protocol, a field name of externally provided data, a communication address, and the like, which are not specifically limited herein. The communication address may include, for example, an IP (Internet Protocol) address, a port number, and the like. Optionally, the system identifications of the plurality of business systems may also be registered with the ESB middleware corresponding to the sub-enterprise B.
When the subsidiary B has a subordinate organization, the association information of each subordinate organization of the subsidiary B may be registered in the ESB middleware corresponding to the subsidiary B. The related information may include, for example, a service domain configured for a corresponding subordinate organization and service information of a service opened to another organization by a plurality of business systems of the subordinate organization. Optionally, the association information may further include, but is not limited to, a communication address of ESB middleware corresponding to the subordinate organization, and/or a system identifier of the plurality of service systems.
In some embodiments, the communication address and the like of the ESB middleware corresponding to the superior organization of the child enterprise B (e.g., the parent enterprise a) may also be registered with the ESB middleware corresponding to the child enterprise B.
In some embodiments, a routing policy may also be configured in the ESB middleware corresponding to the sub-enterprise B, and the routing policy may be used to instruct, for example, forwarding a call request for a service satisfying a specific condition to an upper-level organization of the local organization (e.g., the sub-enterprise B). The specific condition may include, for example, a service domain belonging to neither the own service domain nor a service domain of a subordinate organization of the own organization. Optionally, the routing policy may also be used to instruct that a call request for a service under a service domain of any subordinate entity of the local entity is forwarded to the ESB middleware corresponding to the subordinate entity.
It should be noted that the information registered and configured in the ESB middleware described above may form the routing configuration information of the ESB middleware.
After the routing configuration of the middleware is completed, data transmission between the cross-regional services can be implemented.
Taking parent enterprise a and child enterprise B, C shown in fig. 1 as an example, the individual services under the service domain of parent enterprise a include services a1, a2, A3. Child enterprise B and child enterprise C are the same level of enterprise, i.e., siblings. Each service under the service domain of sub enterprise B includes services B1, B2, B3, and each service under the service domain of sub enterprise C includes services C1, C2, C3.
When the service B1 of the child enterprise B wants to obtain data from the service C1 of the child enterprise C, or send data to the service C1, a call request for the service C1 may be sent to the ESB middleware corresponding to the child enterprise B, as indicated by reference numeral 102. Then, the ESB middleware corresponding to the sub-enterprise B may recognize that the service C1 is not a service in the service domain according to the stored routing configuration information, so as to forward the invocation request for the service C1 to the ESB middleware corresponding to the parent enterprise a, as indicated by reference numeral 104. Then, the ESB middleware corresponding to the parent enterprise a may identify that the service C1 is a service under the service domain of the child enterprise C according to the stored routing configuration information, so as to forward the invocation request for the service C1 to the ESB middleware corresponding to the child enterprise C as indicated by reference numeral 106. The ESB middleware corresponding to the child enterprise C may then invoke service C1 in accordance with the invocation request for service C1, as indicated by reference numeral 108.
By adopting the above data transmission procedure, data transmission between the cross-regional services B1 and C1 can be realized, thereby realizing information sharing between the service B1 and the service C1. For example, when the call request for the service C1 is actually a request to acquire data from the service C1, through the above data transfer process, the data acquisition request of the service B1 may be sent to the service C1, so that the service C1 provides the corresponding data to the service B1 with a similar process to the data transfer process. When the call request for the service C1 is actually a request to send data to the service C1, data required by the service C1 in the service B1 can be sent to the service C1 through the above data transfer procedure.
Note that, for convenience of description, only one superior organization (parent enterprise a) and two immediate subordinate organizations (child enterprises B, C) of the superior organization are shown in fig. 1. It should be understood that the superordinate mechanism may have indirect subordinate mechanisms in addition to the direct subordinate mechanisms.
The following describes specific implementation steps of the above method with reference to specific examples. For convenience of description, in any of the above-described plurality of middleware, the middleware is hereinafter referred to as a first middleware, a mechanism corresponding to the first middleware is referred to as a first mechanism, a service domain of the first mechanism is referred to as a first service domain, a middleware corresponding to an upper mechanism of the first mechanism is referred to as a second middleware, and a service domain of an arbitrary lower mechanism of the first mechanism and the corresponding middleware are referred to as a second service domain and a third middleware, respectively.
Referring to fig. 2, a schematic diagram of one embodiment of a data transmission method suitable for a cross-region service is shown. The execution subject of the method may be the first middleware as described above. The method comprises the following steps:
step 202, receiving a service invocation request, wherein the service invocation request comprises a service identifier of a target service to be invoked;
step 204, determining whether the target service belongs to the first service domain according to the service identifier and the routing configuration information;
step 206, under the condition that the target service is determined to belong to the first service domain, calling the target service according to the service calling request and the service information of the target service in the route configuration information;
step 208, under the condition that the target service is determined not to belong to the first service domain, determining whether the first mechanism has an upper mechanism and a lower mechanism;
and 210, responding to the first mechanism having the upper mechanism and not having the lower mechanism, forwarding the service calling request to a second middleware corresponding to the upper mechanism in the plurality of middleware.
The above steps are further explained below.
In step 202, the first middleware may receive a service invocation request including a service identification of a target service to be invoked. Optionally, the service invocation request may also include the related information of the original sender, and the system identification of the business system to which the target service belongs, and so on. As an example, when the original sender is a certain service under the service domain of a certain organization of the plurality of organizations as described above, the related information may include a system identification of a business system to which the service belongs, a service identification of the service, and the like.
The service invocation request may specifically be a request for acquiring data from the target service, or a request for sending data to the target service. Additionally, the service invocation request may be received from any of: one of the services in the first service domain, the second middleware, and a third middleware corresponding to any lower authority of the first authority among the plurality of middleware as described above.
It should be noted that, if the service invocation request is received from one of the services under the first service domain, the service is usually the original sender of the service invocation request. If the service invocation request is received from the second middleware or the third middleware, the service invocation request is typically forwarded by the second middleware or the third middleware to the first middleware.
Next, in step 204, the first middleware may determine whether the target service belongs to the first service domain according to the service identifier of the target service and the stored routing configuration information.
The routing configuration information may include a first service domain configured for a first mechanism corresponding to the first middleware, and service information of each service in the first service domain. The individual services may include all services provided by a plurality of business systems of the first organization. Optionally, the routing configuration information may further include system identifications of a plurality of business systems of the first organization, and the system identifications correspond to the first service domain and service information of respective services under the first service domain. The service information may include, for example, a service identifier of a service corresponding thereto, an adopted protocol, a field name of externally provided data, a communication address, and the like.
As an example, in the routing configuration information stored by the first middleware, the first middleware may search, in each piece of service information corresponding to the first service domain, for service information including a service identifier of the target service. If the target service is found, determining that the target service belongs to the first service domain; otherwise, it may be determined that the target service is not affiliated with the first service domain.
As another example, if the service invocation request further includes a system identifier (hereinafter referred to as a first system identifier) of a service system to which the target service belongs, and the routing configuration information further includes system identifiers of a plurality of service systems of the first organization, the first middleware may first search for the first system identifier in each system identifier corresponding to the first service domain. If not found, it may be determined that the target service does not belong to the first service domain. If the target service is found, the target service can be determined to belong to the first service domain.
Optionally, in order to improve the accuracy of the determination result, after the first system identifier is found, the service information including the service identifier of the target service may be further found in each piece of service information corresponding to the first system identifier. If the service information is not found, it can be determined that the target service does not belong to the first service domain. If the service information is found, it can be determined that the target service belongs to the first service domain.
Next, in the case that the determination result of step 204 is yes, the first middleware may invoke the target service according to the service invocation request and the service information of the target service in the routing configuration information by executing step 206. Specifically, the target service may be invoked according to the service invocation request and the communication address in the service information.
In the event that the determination of step 204 is negative, the first middleware may determine whether the first mechanism has an upper mechanism and a lower mechanism by performing step 208. By way of example, the first middleware may maintain organizational structure information, for example, that describes relationships between the plurality of organizations at which the first organization is located. The first middleware may determine whether the first organization has an upper organization and a lower organization according to the organizational structure information.
If it is determined in step 208 that the first enterprise has a superordinate enterprise without subordinate enterprises, the first middleware may forward the service invocation request to a second middleware corresponding to the superordinate enterprise by performing step 210. Thereafter, the second middleware may process the service invocation request using a process similar to the data transfer process performed by the first middleware.
In some embodiments, the routing configuration information may also include a communication address of the second middleware. In step 210, the first middleware may forward the service invocation request to the second middleware according to the communication address.
In some embodiments, when the first organization has subordinate organizations, the routing configuration information may also include association information for the respective subordinate organizations of the first organization. The association information may include a second service domain configured for its corresponding subordinate organization, and service information of services that are open to other organizations by a plurality of business systems of the subordinate organization, and so on. If it is determined in step 208 that the first mechanism has subordinate mechanisms, the first middleware may determine whether the target service belongs to the second service domain of one of the respective subordinate mechanisms according to the service identification and the routing configuration information of the target service by performing step 212. It should be noted that the specific implementation manner of step 212 is similar to that of step 204, and reference may be made to the related description of step 204, which is not described herein again.
In the event that the determination of step 212 is yes, the first middleware may forward the service invocation request to a third middleware corresponding to the target subordinate authority by performing step 214. Wherein the target subordinate mechanism is a subordinate mechanism corresponding to a second service domain to which the target service belongs. Thereafter, the third middleware may invoke the target service according to the received service invocation request.
In some embodiments, the association information may further include a communication address of a third middleware corresponding to a lower authority corresponding to the association information, and the like. Based on this, in the routing configuration information, the association information of the target subordinate entity may further include a communication address of the third middleware corresponding to the target subordinate entity. In step 214, the first middleware may forward the service invocation request to the third middleware according to the communication address.
In some embodiments, in the case that the determination result in step 212 is no, if the first organization also has a superior organization, the first middleware may forward the service invocation request to a second middleware corresponding to the superior organization by executing step 216.
In some embodiments, in the event the determination of step 212 is negative, the first middleware may feed back a service exception notification message to the original sender of the service invocation request if the first authority does not have a superior authority.
As an example, the first middleware may generate a first service invocation request including a service exception notification message, identification information of the first middleware, and related information of the original sender. Thereafter, the first middleware may process the first service invocation request by using a process similar to the data transmission process described in the foregoing as the target service to be invoked.
In some embodiments, the routing configuration information may further include the routing policy described above, and the steps 210, 214, and 216 may be performed by the first middleware according to the routing policy.
The data transmission method applicable to the cross-regional service provided in the embodiment corresponding to fig. 2 can implement data transmission between cross-regional services through a plurality of cascaded middleware, so that the cross-regional service can perform information sharing.
With further reference to fig. 3, the present specification provides one embodiment of a data transfer device suitable for cross-regional service that may be applied to a first middleware that employs ESB technology. The first middleware is any one of a plurality of middleware corresponding to a plurality of mechanisms having a hierarchical relationship. The first middleware stores routing configuration information, wherein the routing configuration information comprises a first service domain configured for a first mechanism corresponding to the first middleware and service information of each service in the first service domain. The individual services include all services provided by the plurality of business systems of the first organization.
As shown in fig. 3, the data transmission apparatus 300 suitable for the cross-region service of the present embodiment includes: a receiving unit 301, a determining unit 302, a first processing unit 303 and a second processing unit 304. Wherein, the receiving unit 301 is configured to receive a service invocation request, which includes a service identification of a target service to be invoked; the determining unit 302 is configured to determine whether the target service belongs to the first service domain according to the service identification and the routing configuration information; the first processing unit 303 is configured to, in a case where the determining unit 302 determines that the target service belongs to the first service domain, invoke the target service according to the service invocation request and the service information of the target service in the routing configuration information; the second processing unit 304 is configured to, in case the determining unit 302 determines that the target service is not attributed to the first service domain, forward the service invocation request to a second middleware corresponding to the superior authority among the above plurality of middleware in response to the first authority having the superior authority without the inferior authority.
In some embodiments, the service invocation request may be received from any of: one of the services, the second middleware, and a third middleware corresponding to any lower-level mechanism of the first mechanism among the plurality of middleware.
In some embodiments, the service invocation request may be embodied as a request to obtain data from a target service or a request to send data to a target service.
In some embodiments, the routing configuration information may also include a communication address of the second middleware; the second processing unit 304 may be further configured to: and forwarding the service calling request to the second middleware according to the communication address.
In some embodiments, when the first organization has subordinate organizations, the routing configuration information may further include association information of each of the subordinate organizations of the first organization, the association information including a second service domain configured for its corresponding subordinate organization and service information of services opened by a plurality of business systems of the subordinate organization to other organizations; and the second processing unit 304 may be further configured to: in a case where the determining unit 302 determines that the target service is not assigned to the first service domain, in response to the first mechanism having subordinate mechanisms, it is determined whether the target service is assigned to a second service domain of one of the subordinate mechanisms based on the service identifier and the routing configuration information; and forwarding the service invocation request to a third middleware corresponding to the target subordinate mechanism in the plurality of middleware when the target service belongs to the second service domain of one of the subordinate mechanisms, wherein the target subordinate mechanism is the subordinate mechanism corresponding to the second service domain to which the target service belongs.
In some embodiments, the second processing unit 304 may be further configured to: in the case where it is determined that the target service does not belong to the second service domain of one of the respective subordinate authorities, the service invocation request is forwarded to the second middleware in response to the first authority having a superior authority.
In some embodiments, the second processing unit 304 may be further configured to: in a case where it is determined that the target service does not belong to the second service domain of one of the respective subordinate authorities described above, a service abnormality notification message is fed back to the original sender of the service invocation request in response to the first authority not having a superior authority.
In the embodiment of the apparatus corresponding to fig. 3, the detailed processing of each unit and the technical effect thereof can refer to the related description in the embodiment corresponding to fig. 2, and are not repeated herein.
The present specification further provides a computer-readable storage medium, on which a computer program is stored, wherein when the computer program is executed in a computer, the computer is caused to execute the data transmission method suitable for the cross-regional service, which is respectively described in the above method embodiments.
The embodiment of the present specification further provides a computing device, which includes a memory and a processor, where the memory stores executable code, and when the processor executes the executable code, the data transmission method suitable for the cross-region service, which is respectively described in the above method embodiments, is implemented.
Embodiments of the present specification further provide a computer program, where the computer program, when executed in a computer, causes the computer to execute the data transmission method suitable for the cross-regional service described in the above method embodiments respectively.
Those skilled in the art will recognize that, in one or more of the examples described above, the functions described in the embodiments disclosed herein may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium.
In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
The above-mentioned embodiments, objects, technical solutions and advantages of the embodiments disclosed in the present specification are further described in detail, it should be understood that the above-mentioned embodiments are only specific embodiments of the embodiments disclosed in the present specification, and are not intended to limit the scope of the embodiments disclosed in the present specification, and any modifications, equivalent substitutions, improvements and the like made on the basis of the technical solutions of the embodiments disclosed in the present specification should be included in the scope of the embodiments disclosed in the present specification.

Claims (10)

1. A data transmission method suitable for cross-regional service is applied to a first middleware adopting an enterprise service bus technology, the first middleware is any middleware in a plurality of middleware corresponding to a plurality of organizations with a hierarchical relationship, the first middleware stores routing configuration information, the first middleware comprises a first service domain configured for a first organization corresponding to the first middleware and service information of each service in the first service domain, and each service comprises all services provided by a plurality of service systems of the first organization, and the method comprises the following steps:
receiving a service calling request, wherein the service calling request comprises a service identifier of a target service to be called;
determining whether the target service belongs to the first service domain according to the service identifier and the routing configuration information;
under the condition that the target service is determined to belong to the first service domain, calling the target service according to the service calling request and the service information of the target service in the routing configuration information;
in an instance in which it is determined that the target service does not belong to the first service domain, in response to the first authority having a superior authority without a subordinate authority, forwarding the service invocation request to a corresponding second middleware of the superior authority among the plurality of middleware.
2. The method of claim 1, wherein the service invocation request is received from any of: one of the services, the second middleware, and a third middleware corresponding to any lower-level mechanism of the first mechanism among the plurality of middleware.
3. The method according to claim 1, wherein the service invocation request is specifically a request for obtaining data from the target service or a request for sending data to the target service.
4. The method of claim 1, wherein the routing configuration information further comprises a communication address of the second middleware; and
the forwarding the service invocation request to a second middleware corresponding to the superior authority in the plurality of middleware comprises:
and forwarding the service calling request to the second middleware according to the communication address.
5. The method of claim 1, wherein, when the first organization has subordinate organizations, the routing configuration information further includes association information of each subordinate organization of the first organization, the association information including a second service domain configured for its corresponding subordinate organization and service information of services opened to other organizations by a plurality of business systems of the subordinate organization; and
in a case that it is determined that the target service does not belong to the first service domain, further comprising:
determining whether the target service belongs to a second service domain of one of the subordinate organizations according to the service identification and the routing configuration information in response to the first organization having subordinate organizations;
and in the case that the target service is determined to belong to a second service domain of one of the subordinate agencies, forwarding the service invocation request to a third middleware corresponding to the target subordinate agency in the plurality of middleware, wherein the target subordinate agency is a subordinate agency corresponding to the second service domain to which the target service belongs.
6. The method of claim 5, wherein after said determining whether the target service belongs to a second service domain of one of the respective subordinate enterprises, further comprising:
in an instance in which it is determined that the target service does not belong to a second service domain of one of the respective subordinate enterprises, forwarding the service invocation request to the second middleware in response to the first enterprise having a superior enterprise.
7. The method of claim 5, wherein after said determining whether the target service belongs to a second service domain of one of the respective subordinate enterprises, further comprising:
in a case where it is determined that the target service does not belong to the second service domain of one of the respective subordinate authorities, feeding back a service abnormality notification message to an original sender of the service invocation request in response to the first authority not having a superior authority.
8. A data transmission device suitable for cross-regional service is applied to a first middleware adopting an enterprise service bus technology, the first middleware is any middleware in a plurality of middleware corresponding to a plurality of organizations with a hierarchical relationship, the first middleware stores routing configuration information, the routing configuration information comprises a first service domain configured for a first organization corresponding to the first middleware and service information of each service in the first service domain, and each service comprises all services provided by a plurality of service systems of the first organization, and the device comprises:
a receiving unit configured to receive a service invocation request including a service identification of a target service to be invoked;
a determining unit configured to determine whether the target service belongs to the first service domain according to the service identifier and the routing configuration information;
a first processing unit, configured to, in a case where the determining unit determines that the target service belongs to the first service domain, invoke the target service according to the service invocation request and service information of the target service in the routing configuration information;
a second processing unit configured to forward the service invocation request to a corresponding second middleware of the superior authority among the plurality of middleware in response to the first authority having a superior authority without a subordinate authority if the determining unit determines that the target service does not belong to the first service domain.
9. A computer-readable storage medium, on which a computer program is stored, wherein the computer program causes a computer to carry out the method of any one of claims 1-7 when the computer program is carried out in the computer.
10. A computing device comprising a memory and a processor, wherein the memory has stored therein executable code that when executed by the processor implements the method of any of claims 1-7.
CN202110977550.9A 2021-08-24 2021-08-24 Data transmission method and device suitable for cross-regional service Active CN113645251B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110977550.9A CN113645251B (en) 2021-08-24 2021-08-24 Data transmission method and device suitable for cross-regional service

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110977550.9A CN113645251B (en) 2021-08-24 2021-08-24 Data transmission method and device suitable for cross-regional service

Publications (2)

Publication Number Publication Date
CN113645251A true CN113645251A (en) 2021-11-12
CN113645251B CN113645251B (en) 2023-05-23

Family

ID=78423675

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110977550.9A Active CN113645251B (en) 2021-08-24 2021-08-24 Data transmission method and device suitable for cross-regional service

Country Status (1)

Country Link
CN (1) CN113645251B (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114489686A (en) * 2021-12-08 2022-05-13 浙江大学 Middleware decoupling method, device and equipment under multi-cloud deployment
CN115002228A (en) * 2022-05-31 2022-09-02 杭州数梦工场科技有限公司 Service cascade calling method and device, electronic equipment and storage medium

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108093147A (en) * 2016-11-23 2018-05-29 海能达通信股份有限公司 A kind of distributed multi-stage dispatching method and equipment
CN108200110A (en) * 2016-12-08 2018-06-22 杭州海康威视系统技术有限公司 A kind of data processing method, apparatus and system
CN108234261A (en) * 2017-12-15 2018-06-29 国家电网公司 For the service bus dispatching method of electric control system network supervision
CN108683722A (en) * 2018-05-10 2018-10-19 中国银行股份有限公司 A kind of method of data transmission, ESB platforms and client
CN109167819A (en) * 2018-08-13 2019-01-08 苏州科达科技股份有限公司 Data synchronous system, method, apparatus and storage medium
CN110233865A (en) * 2018-03-06 2019-09-13 阿里巴巴集团控股有限公司 Trans-regional service calling method, device and system
CN110336753A (en) * 2019-06-19 2019-10-15 腾讯科技(深圳)有限公司 A kind of service calling method, device, equipment and the storage medium in across a network region

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108093147A (en) * 2016-11-23 2018-05-29 海能达通信股份有限公司 A kind of distributed multi-stage dispatching method and equipment
CN108200110A (en) * 2016-12-08 2018-06-22 杭州海康威视系统技术有限公司 A kind of data processing method, apparatus and system
CN108234261A (en) * 2017-12-15 2018-06-29 国家电网公司 For the service bus dispatching method of electric control system network supervision
CN110233865A (en) * 2018-03-06 2019-09-13 阿里巴巴集团控股有限公司 Trans-regional service calling method, device and system
CN108683722A (en) * 2018-05-10 2018-10-19 中国银行股份有限公司 A kind of method of data transmission, ESB platforms and client
CN109167819A (en) * 2018-08-13 2019-01-08 苏州科达科技股份有限公司 Data synchronous system, method, apparatus and storage medium
CN110336753A (en) * 2019-06-19 2019-10-15 腾讯科技(深圳)有限公司 A kind of service calling method, device, equipment and the storage medium in across a network region

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114489686A (en) * 2021-12-08 2022-05-13 浙江大学 Middleware decoupling method, device and equipment under multi-cloud deployment
CN115002228A (en) * 2022-05-31 2022-09-02 杭州数梦工场科技有限公司 Service cascade calling method and device, electronic equipment and storage medium
CN115002228B (en) * 2022-05-31 2023-12-26 杭州数梦工场科技有限公司 Service cascade calling method and device, electronic equipment and storage medium

Also Published As

Publication number Publication date
CN113645251B (en) 2023-05-23

Similar Documents

Publication Publication Date Title
Aksakalli et al. Deployment and communication patterns in microservice architectures: A systematic literature review
US8751626B2 (en) Model-based composite application platform
Meier et al. Taxonomy of distributed event-based programming systems
US7945860B2 (en) Systems and methods for managing conversations between information technology resources
AU2014278314B2 (en) Distributed lock management in a cloud computing environment
US8122427B2 (en) Decentralized system services
US20090165021A1 (en) Model-Based Composite Application Platform
JP2019200580A (en) Decentralized ledger system, decentralized ledger subsystem, and decentralized ledger node
CN106663033B (en) System and method for supporting a wraparound domain and proxy model and updating service information for cross-domain messaging in a transactional middleware machine environment
US20140019616A1 (en) Systems and methods for business network management discovery and consolidation
CN113645251B (en) Data transmission method and device suitable for cross-regional service
US8380787B2 (en) Federation of master data management systems
US8250185B2 (en) Semantic matching of federation intents and services capabilities in a planning system for automatic service federation
US9503351B1 (en) Deployment feedback for system updates to resources in private networks
US8010608B2 (en) Locked receive locations
Chihani et al. Programmable context awareness framework
CN114866416A (en) Multi-cluster unified management system and deployment method
Terazono et al. Service oriented architecture realized by a messaging network
CN115988080B (en) Micro-service resource calling method and system based on proxy middleware
CN114944960B (en) Password application method, device, equipment and storage medium
Surianarayanan Microservices architecture for edge computing environments
Gurewitz et al. Parallel algorithms for one and two-vehicle navigation
US7613814B2 (en) Discovering transactions silently propagated off-machine
Rajendra Prasad et al. An Integrated Methodology of TsF-KNN-Based Automated Data Classification and Security for Mobile Cloud Computing
Satapathi et al. Build a Web API to Send Messages to Azure Service Bus

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant