WO2011150600A1

WO2011150600A1 - Enterprise service bus and message processing method for enterprise service bus

Info

Publication number: WO2011150600A1
Application number: PCT/CN2010/076364
Authority: WO
Inventors: 虞钢
Original assignee: 西本新干线股份有限公司
Priority date: 2010-06-04
Filing date: 2010-08-26
Publication date: 2011-12-08
Also published as: CN102025653B; CN102025653A

Abstract

An enterprise service bus and a message processing method for enterprise service bus are provided in the present invention. The enterprise service bus comprises: a message receiving unit including multiple message receiving channels, each of which is used for receiving a message including at least one service request; a message queue unit for receiving messages from said multiple message receiving channels and queuing according to a predetermined rule; a processing thread group for receiving a predetermined number of queued messages from said message queue unit; a request processing unit for obtaining the service requests in said messages from said processing thread group and processing the service requests. Because various application programs are integrated into an electric business platform and an invoking among various application programs is implemented by the enterprise service bus of the present invention, the service user does not need to perform a complicated asynchronous invoking and the switch from synchronization mode to asynchrony mode is performed by the enterprise service bus.

Description

Message processing method for enterprise service bus and enterprise service bus

This application claims priority to Chinese Patent Application No. 201010197480.7, entitled "Enterprise Service Bus and Enterprise Service Bus Message Processing Method", submitted to the Chinese Patent Office on June 4, 2010, the entire contents of which are incorporated by reference. In this application.

Technical field

The present invention relates to the field of electronic commerce transaction technology, and in particular to an enterprise service bus and an enterprise service bus message processing method applied to an e-commerce transaction platform.

Background technique

At present, application integration services between large enterprise networks are becoming more and more complex, and traditional point-to-point system integration is stretched. In order to solve this problem, the concept of enterprise service bus (ESB) is proposed. The subsystems that make up the enterprise network access a public information platform in a manner similar to the connector. Relatively independent, the scheduling engine performs unified data scheduling to efficiently integrate data and business processes. According to the definition given by the well-known IT research and consulting organization Gartner, the enterprise service bus is an architecture, which is realized by using enterprise web services, message middleware, intelligent routing and conversion technology. It is a traditional intermediate technology with XML and Web. The product combines technologies such as services, and ESB provides the most basic connectivity hub in the network. The goal of enterprise service bus technology is to implement enterprise application integration in a standardized way, and to complete the interconnection, interoperability and interoperability of enterprise application systems. The standardization work includes connector standardization, management standardization, service message standardization and message standardization.

The emergence of ESB has changed the traditional software architecture, providing a cheaper solution than traditional intermediate software products, while also eliminating the technical differences between different application services, allowing different applications Coordinating operations with services to achieve communication and integration between different services. Functionally, ESB provides event-driven and document-oriented processing modes, as well as a distributed management mechanism that supports content-based routing and filtering, has the ability to transfer complex data, and provides a range of standard interfaces. For example, Chinese Patent Application No. 200810227316.9 discloses an implementation method of an enterprise service bus.

In the existing e-commerce transaction platform, the service user directly calls the service provider is many-to-many, disorderly, and it is difficult to maintain and manage the service in the line; the coupling between the service caller and the background service is passed. High, often led by the whole body, how many callers in the background service, what services are called by the application, resulting in maintenance difficulties, reliability between service consumers and service providers, transaction processing, synchronous/asynchronous communication, Security authentication management needs to be implemented separately between the two, lacking a common infrastructure; and lacking a unified way to monitor, count, and provide analytical data for back-end services, not convenient for Service-Oriented Architecture (Service-Oriented Architecture) , the application of the cylinder called SOA) for maintenance management.

Summary of the invention

The problem solved by the present invention is to provide an enterprise service bus. When applied to an enterprise electronic transaction platform, different application programs can be integrated, and the service user does not have to perform complex asynchronous calls, and the service bus completes the synchronization. Conversion of asynchronous mode.

To solve the above problems, the present invention provides an enterprise service bus, including:

a message receiving unit, comprising: a plurality of message receiving channels, each message receiving channel for receiving a message including at least one service request;

a message queue unit, configured to receive messages from the plurality of message receiving channels, and sort according to a predetermined rule; Processing a thread group, configured to receive a predetermined number of sorted messages from the message queue unit; a request processing unit, configured to acquire a service request in the message from the processing thread group, and process the service request.

Optionally, the sorting according to a predetermined rule means sorting according to a time sequence in which the message is sent or received.

Optionally, the message includes at least two service requests;

The enterprise service bus further includes: a request splitting unit, configured to split the message into a service request and send the message to the message receiving unit.

Optionally, the message includes at least two service requests;

The enterprise service bus further includes: a request splitting unit, configured to split the message received by the message receiving unit into a service request and send the message to the message queue unit.

Optionally, the message includes at least two service requests;

The enterprise service bus further includes: a request splitting unit, configured to split the message received by the message queue unit into a service request and send the message to the processing thread group.

Optionally, the request processing unit includes multiple request processing pipelines, and each request processing pipeline correspondingly processes a service request.

Optionally, the request processing unit processing the service request includes generating at least one access request according to a predetermined process, and invoking a corresponding application service based on the access request.

Optionally, the method further includes: requesting a transmission channel, configured to send an access request generated by the request processing unit to a corresponding application service.

Optionally, the message including the at least one service request is encrypted, and the enterprise service bus further includes a decryption unit, configured to: before the request processing unit processes the service request according to a predetermined process The message is decrypted.

To solve the above technical problem, the present invention also provides a message processing method for an enterprise service bus, including:

Receiving a message, each message including at least one service request;

Sorting the received messages according to a predetermined rule;

Process a service request in a predetermined number of sorted messages.

Optionally, the message includes at least two service requests;

The message processing method further includes: splitting the message into a service request.

Optionally, the processing service request includes: generating at least one access request according to a predetermined process, and invoking a corresponding application service based on the access request.

Optionally, the message including the at least one service request is encrypted;

The decrypting of the message is also included prior to the processing of the service request.

Compared with the prior art, the present invention has the following advantages: When the enterprise service bus provided by the present invention is applied to an electronic transaction platform, the service user does not have to directly invoke the service provided by the service provider, and the service user and the service provider pass the standard interface. Connected with an electronic trading platform, integrate various applications into an electronic trading platform, and realize calls between various applications through the enterprise service bus of the present invention, and the service user does not have to make complex asynchronous calls, and is performed by the enterprise service bus. Synchronous to asynchronous mode conversion.

Moreover, the enterprise service bus of the present invention limits the number of messages that the electronic transaction platform can process by processing the thread group, does not respond to messages exceeding the number, and avoids excessive pressure on the call of a certain service, causing the electronic transaction platform to crash. BRIEF DESCRIPTION OF DRAWINGS FIG. 1 is a schematic diagram of an internal architecture of an enterprise service bus according to a specific embodiment of the present invention; FIG. 2 is a schematic structural diagram of a request processing unit; FIG. 3 is a block diagram of a processing flow of an access request according to a specific embodiment; A schematic diagram of an embodiment of an enterprise service bus applied to an electronic transaction platform.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS When an enterprise service bus according to a specific embodiment of the present invention is applied to an electronic transaction platform, a service user does not have to directly call a service provider, and a service user and a service provider connect to an electronic transaction platform through a standard interface, and various application services are provided. Integrating into an electronic transaction platform, and implementing a call to each application service through the enterprise service bus of the present invention, the service user does not have to perform complex asynchronous calls, and the synchronization to asynchronous mode is performed by the enterprise service bus; and the enterprise of the present invention The service bus limits the number of messages that the electronic trading platform can process by processing the thread group, does not respond to messages exceeding the number, and avoids excessive pressure on the calling of a certain service (application service), causing the electronic trading platform to crash.

Referring to FIG. 1, an enterprise service bus 100 according to an embodiment of the present invention includes: a message receiving unit 110, configured to receive a message sent by multiple service users, including multiple message receiving channels, respectively, a message receiving channel 1, and a message receiving Channel 2 ······ message receiving channel η, each message receiving channel receives a message including at least one service request; in order to reduce the service user to operate separately for different service requests, at least one is included in one message receiving channel The service request, the service user can make multiple service requests at a time; when the service user makes multiple service requests at a time, the package request unit packs the multiple service requests made by the user and sends them in the form of a message, in the form of the message of the present invention. In this embodiment, the message includes at least two service requests, and the enterprise service bus further includes a request for teardown. a subunit (not shown), configured to split the message into a service request and send the message to the message receiving unit 110. In a specific embodiment of the present invention, the message receiving channel also sends a message by calling an encryption unit. The message received by the receiving channel is encrypted.

The message queue unit 120 is configured to receive a message from the message receiving unit 110, and queue multiple messages from multiple message receiving channels according to chronological order, and the message with the preceding time is prioritized compared with the message with the time. The time sequence here corresponds to the order in which the service user requests the operation, or may be the sequence in which the message queue unit 120 receives the message. Referring to FIG. 1, the queued message queue is the message queue 10 and the message queue 20 respectively. ···· message queue ηθ; and before the message enters the message queue unit 120, the message queue unit 120 calls the request split unit (not shown), and the package split message is split into service requests by the request split unit. The number of service requests corresponds to the number of service requests made by the service user. Referring to Figure 1, the message in the message queue 10 is split into a service request 11, a service request 12, a service request 13, and the message in the message queue 20 is split. Divided into service request 21, service request 22, service request 23, message in message queue ηθ is split As a service request nl, a service request n2, a service request n3, it should be noted that each message in this example is split into three service requests, only exemplary, in a specific embodiment, each message includes The number of service requests depends on the specific situation (ie, the operation of the server user); it should be noted that in the specific embodiment of the invention, the messages in the message queue unit are queued according to the chronological order, in the other aspects of the present invention. In the embodiment, the messages in the message queue unit may also be queued according to other predetermined rules, for example, the messages in the message queue unit are queued according to the priority (importance) of the message.

In another embodiment of the present invention, splitting the packaged message may also include at least two service requests before the message receiving channel receives the message; the enterprise service bus further includes: requesting a splitting unit, For splitting the message including the at least one service request into a service request and sending The message queue is received by the unit. In other embodiments of the present invention, splitting the packaged message may also include at least two service requests before the processing thread group receives the message; the enterprise service bus further includes: requesting the splitting unit, Receiving a message from the message queue unit, and splitting the message including the at least one service request received by the message queue unit into a service request, and sending the message to the processing thread group.

Processing thread group 130, comprising a predetermined number of processing threads, respectively processing thread 1, processing thread 2, ... processing thread n, for receiving a predetermined number of sorted messages from the message queue unit 120; The number of processing threads in the thread group 130 is a predetermined number, which is set according to the processing capability of the electronic trading platform. For example, the number of processing threads in the processing thread group 130 is 200, and the electronic trading platform can only be used at the same time. Responding to 200 messages, for the 200th and subsequent messages, the electronic trading platform does not respond, avoiding the phenomenon that the electronic trading platform is down due to too many service users, thus ensuring the normal operation of the electronic trading platform. The processing thread 1 stores the service request 11, the service request 12, the service request 13 in the message queue 10, the processing thread 2 stores the service request 21 in the message queue 20, the service request 22, the service request 23, ... the processing thread n stores Service request nl, service request n2, service request n3 in message queue ηθ.

The request processing unit 140 is configured to obtain a service request in the message from the processing thread group 130, and process the service request. In the specific embodiment, the request processing unit 140 includes multiple request processing pipelines, each of which The request processing pipeline includes a plurality of request processing pipelines, and each of the request processing pipelines correspondingly processes a service request. Referring to FIG. 2, the request processing unit 140 includes a plurality of request processing pipelines, respectively being the first request processing pipeline 10, Two request processing pipelines 20... The Nth request processing pipeline ηθ, each request processing pipeline includes a plurality of request processing pipelines, and each request processing pipeline can process a plurality of service requests of the same type, which are processed by the first request Pipe 10 as an example, the first A request processing pipeline 10 includes a plurality of request processing pipelines for request processing pipeline 11, request processing pipeline 12, ... request processing pipeline In; the processing thread group 130 obtains a message from the message queue unit 120, and acquires The message that has been split into the service request is processed and sent to the corresponding request processing pipeline. It should be noted that the type of the request processing pipeline has a corresponding relationship with the service type request, and each service request corresponds to the same kind of request. Processing the pipeline, the service request included in each message will enter the corresponding kind of request processing pipeline, and the request processing pipeline processes the service request. In this specific embodiment, each request processing pipeline includes a decryption stage and a processing stage. When the decryption stage receives a message corresponding to the message receiving channel, the encryption unit is invoked to encrypt the message, and the encrypted message is sent. By decrypting the decryption unit, in other embodiments, each of the request processing pipelines may include different phases, such as may also include a decompression phase. In this specific embodiment of the present invention, the processing stage processing the service request includes: generating at least one access request according to a predetermined process, and invoking a corresponding application service based on the access request. The application service is provided by the service provider, and the application service is invoked by the access request. In the processing stage of the request processing pipeline, an access request is generated according to a predetermined predetermined process, and the application service is invoked by the access request, and the application service processes according to the access request. Generate the processing result of the access request.

In a specific embodiment of the present invention, the enterprise service bus further includes: a request delivery channel, configured to address, and send an access request generated from the request processing unit to a corresponding application service.

The process of sending a message to the application service for the service user is described above, and the processing result of the application service generating the access request according to the access request is returned to the service user. In this specific embodiment of the present invention, the process of generating an access request by the application service according to the access request is returned to the service user, and the process of the service user sending the message to the application service is reversed. First, the application is invoked through the request delivery channel. The information after the service is sent to the corresponding request processing pipeline, and the information is processed by the request processing pipeline. After being encrypted, it is sent to the corresponding processing thread, and the request processing thread sends the result of the received service request to the corresponding message queue, and then sends it to the corresponding message receiving channel, and all the service request results included in one message are returned to the same. When the corresponding message receiving channel is received, the message receiving channel calls the requesting packaging unit, and all the messages included in one message are packaged and sent to the corresponding service user, and the user can obtain the processing result of the sent message. It should be noted that the term "corresponding" is used herein to mean that the returned message and the request are returned via the path.

The message in the present invention may be a transaction message of various commodities, taking an e-commerce transaction of steel as an example, the commodity is steel, and the transaction message includes a transaction message for releasing the spot of the steel (corresponding to the outbound storage and storage of the steel). The transaction information of the contract (corresponding to the purchase and sales intention), including the registration message (corresponding to the member registered as the electronic trading platform), updating the product message, canceling the message (corresponding to the member who canceled the electronic trading platform), updating the registration message (corresponding to updating member information), point inquiry, credit inquiry, etc.

The service user needs to query the information related to the user information such as points and credits as an example. The service user sends the query user information, and the message receiving channel in the message receiving unit receives the message for querying the user information, because the user information includes points, credits, etc. Information, the message for querying the user information includes a point service request, a credit service request, etc., and the point service request corresponding to the user information, the credit service request, etc. are packaged, and then sent to the message receiving channel of the message receiving unit; the message receiving channel receives the query After the message of the user information, the encryption module is invoked to encrypt the query user message, and then the message for querying the user information is sent to the message queue unit, or the message queue unit can obtain the message for querying the user information from the message receiving channel. When the message queue unit receives the message, the request split unit is called, and the query user information is split into corresponding point service requests, credit service requests, etc., so the query user message entering the message queue unit is the split service request, 1, if the query with The user message corresponds to the message 10, the point service request corresponds to the service request 11, and the credit service request corresponds to the service request 12; after that, the point service request, the credit service request, etc. enters the request processing pipeline corresponding to the service request via the processing thread, and the point service Requesting to enter the request processing pipeline corresponding to the credit service request, the credit service request enters the request processing pipeline corresponding to the credit service request, for example, the credit service request enters the request processing pipeline 11 in the first type of request processing pipeline 10, and the credit service request enters the second The request processing pipeline in the request processing pipeline 20 is processed by the corresponding request processing pipeline to process the credit service request and the credit service request to generate an access request. Taking the integral service request as an example, the request processing pipeline corresponding to the integral service request is first The decryption phase decrypts the encrypted integral service request, and after decryption, enters the processing stage of the integral service request to generate an access request to call the integral database, and queries the integral from the database.

The processing stage of the point service request of the specific embodiment described above does not involve a specific service, but is a query of the points of the bill, and therefore does not involve a business process. The electronic trading platform involves a specific trading business, and there must be a business process. According to the predetermined business process, the business can be smoothly carried out, and the predetermined process will determine the kind of message required to complete a transaction.

The specific implementation of the electronic transaction platform using the enterprise service bus of the present invention must rely on a specific business process to ensure the smooth progress of the electronic transaction, and different business processes can be set according to the specific transaction, the business process corresponding to the predetermined process, and The business process is stored in the process unit, and when the service request is specifically executed, the business process is invoked according to the requirements of the processing stage of the service request.

Take the contract transaction in e-commerce transaction as an example to illustrate the role of business process in the processing stage. 3 is a business process of a specific embodiment of completing a contract transaction. According to the business process of the specific embodiment shown in FIG. 3, the contract transaction is divided into four types of messages: a standard contract is issued 200, corresponding to the first message; Applying settlement unit association 300, corresponding to the second message; contract execution 400, corresponding to The third message; the contract performance application 500, corresponding to the fourth message; First, the member issues the standard contract, and then apply for the binding settlement unit, after the company is approved, the contract will take effect, enter the effective contract, and then the contract can be executed. During the execution of the contract phase, after the contract is executed or executed to a certain extent, the member can apply for performance and enter the contract in the performance contract. After the contract is fulfilled, the contract is executed and the contract is executed. Here, the release contract is taken as an example for description. For other types of transactions, depending on the type of transaction, different types of messages can be classified according to a predetermined process.

The implementation process of executing a contract transaction in accordance with the predetermined process will be described in detail with reference to FIG.

When the service consumer executes the standard contract release 200, this message is a service request, no need to split it, and the request processing pipeline calls the graph from the process unit when the standard contract release message is processed in the request processing pipeline. In the business process shown in FIG. 3, the request processing pipeline divides the service request into multiple steps according to a predetermined rule in the business process related to the standard contract release, specifically: Step 201, checking whether the contract price passes, and requesting the processing pipeline Calling the contract price in the database, if the contract price is passed, proceed to step 202 to check whether the publisher member credit is sufficient. At this time, the request processing pipeline calls the credit module. If the member credit is insufficient, the contract cannot be issued. If the member credit is sufficient, Publish the contract, and generate the standard contract member credit occupation, modify the credit of the standard contract member through the credit module, then proceed to step 203, generate a standard contract, and feedback the result of generating the standard contract to the service user, complete the service request of the standard contract release .

With continued reference to Figure 3, the administrator of the electronic trading platform sees the published standard contract and wants to purchase the published standard contract to make it an effective contract, and execute the application settlement unit (corresponding to the real customer) association 300, which is The second message, the message is a service request, and no need to split it. The request processing pipeline divides the service request into multiple steps according to a predetermined rule in the business process, specifically: Step 301, Service Management Personnel Review, where the content of the review is based on actual needs If the audit fails, the contract cannot be associated with the settlement unit, and the result of the unresolved settlement unit is sent to the service user; if the approval is passed, proceed to step 302, the business management personnel manually input the contract expected loss occupation, and generate an association. Contract risk credit occupation (corresponding to member credit), at this time, the credit module is called at the same time, the member credit is changed by the credit module, and then proceeds to step 303, the business management personnel uploads a scanned copy of the contract text, establishes a real customer contract, and simultaneously puts the real customer contract The scanned piece is attached as an associated contract, and then proceeds to step 304 to generate an associated contract credit occupation (corresponding to the transaction credit), and at the same time release the standard contract credit occupation (corresponding to the member credit), and at this time, the credit module is used to complete the occupation of the transaction credit. The release of the member credit, proceeds to step 305, the associated contract is successfully generated, the result of the effective contract is generated, and the result is returned.

Continuing to refer to FIG. 3, when the contract execution 400 is performed, corresponding to the third message, the message is a service request, and no need to split it, the request processing pipeline will execute the effective contract according to the predetermined rule of the predetermined process. For: Step 401, find the goods, after the goods are found, the contract enters the execution contract from the effective contract. At this time, the credit module can be called to release some or all of the associated contract credits according to the ratio of the execution amount and the contract amount, and the result is passed the message. The receiving channel is sent to the service consumer.

When the service user delivers the goods in stock and the consignee receives the goods, the contract performance application 500 will be executed, corresponding to the fourth message, which is a service request, no need to split it, request processing pipeline The service request is divided into multiple steps according to a predetermined rule of the predetermined process: Step 501, the company audit, if the audit fails, the output result cannot be fulfilled, if the audit is passed, the contract is not fulfilled, the credit module is called, and the credit module is released. If the contract does not fulfill the credit, after completing the contract, proceed to step 502, and the contract in the performance contract is converted into the contract for performance. At this point, the integral module can be called to perform the contract integral assessment. When the enterprise service bus provided by the present invention described above is applied to an electronic transaction platform, the service user does not have to directly invoke the service provided by the service provider, and the service user and the service provider connect with the electronic transaction platform through a standard interface, and various The application is integrated into the electronic transaction platform, and the calling between the respective applications (in the specific embodiment, the credit module is taken as an example) is implemented by the enterprise service bus of the present invention, and the service user does not have to perform complex asynchronous calls. The synchronization to asynchronous mode conversion is performed by the enterprise service bus.

In the specific embodiment described above, only a single contract information is taken as an example. In a specific example, multiple different clients send information at the same time, and the thread group is set by processing the number of threads in the thread group. Only a certain number of threads of messages can be processed at a time, avoiding excessive pressure on the call of a service, causing the electronic trading platform to crash.

The enterprise service bus of the present invention exists in a JVM (Java Virtual Machine). The nodes outside the Enterprise Service Bus are external service consumers and service providers that represent the external entities that the enterprise service bus is to integrate with. These external entities can interact with the service modules bound to the enterprise service bus through a variety of technologies.

Figure 4 is a schematic diagram of the framework of an enterprise service bus applied to an electronic trading platform.

The enterprise service bus 100 is connected to the process unit 600, and the process unit 600 is configured to provide a service flow corresponding to the service request to the service bus. Moreover, on the electronic trading platform, a user interface 801 is provided, which can be used for the user 1, the user 2, the user n to access the electronic transaction platform, and the user who needs to be registered as the electronic transaction platform is managed by the user management unit 803. Management registration, the user who wants to register as an electronic transaction platform must be authenticated by the user management unit 803 before becoming a user of the electronic transaction platform; and the enterprise service bus has a server interface, a supply service 1, an application service 2... The application service n accesses the electronic transaction platform. When the service provider provides the application service to the electronic transaction platform, the application service must be verified by the service management unit 804, and the application service verified by the service management unit 804 can be published to the electronic transaction through the enterprise service bus. platform.

Corresponding to the enterprise service bus described above, the present invention further provides a message processing method for an enterprise service bus, including: receiving a message, each message including at least one service request;

Sorting the received messages according to a predetermined rule;

Process a service request in a predetermined number of sorted messages.

The message includes at least two service requests. The message processing method further includes: splitting the message into service requests.

The processing service request includes: generating at least one access request according to a predetermined process, and invoking a corresponding application service based on the access request.

The message including the at least one service request is encrypted; the message is also decrypted prior to the processing the service request.

The present invention has been disclosed in the preferred embodiments as described above, but it is not intended to limit the invention, and the present invention may be utilized by the method and technical contents disclosed above without departing from the spirit and scope of the invention. The technical solutions make possible changes and modifications, and therefore, the scope of protection of the technical solutions of the present invention is not deviated from the present invention.

Claims

Rights request

1. An enterprise service bus, characterized by comprising:

a message queue unit, configured to receive messages from the plurality of message receiving channels, and sort according to a predetermined rule;

Processing a thread group, configured to receive a predetermined number of sorted messages from the message queue unit; a request processing unit, configured to acquire a service request in the message from the processing thread group, and process the service request.

2. The enterprise service bus according to claim 1, wherein the sorting according to a predetermined rule means sorting in a time sequence in which the message is transmitted or received.

3. The enterprise service bus of claim 1, wherein the message comprises at least two service requests;

4. The enterprise service bus of claim 1, wherein the message comprises at least two service requests;

5. The enterprise service bus of claim 1, wherein the message comprises at least two service requests;

The enterprise service bus further includes: a request splitting unit, configured to receive the message queue unit The message is split into a service request and sent to the processing thread group.

6. The enterprise service bus of claim 1, wherein the request processing unit comprises a plurality of request processing pipelines, each of which processes a service request.

7. The enterprise service bus of claim 1, wherein the request processing unit processing the service request comprises generating at least one access request in a predetermined flow and invoking a corresponding application service based on the access request.

8. The enterprise service bus of claim 7, further comprising: a request delivery channel, configured to send an access request generated from the request processing unit to a corresponding application service.

9. The enterprise service bus of claim 1, wherein the message including the at least one service request is encrypted, the enterprise service bus further comprising a decryption unit, configured to be predetermined at the request processing unit The process decrypts the message before processing the service request.

10. A message processing method for an enterprise service bus, characterized by comprising:

Receiving a message, each message including at least one service request;

Sorting the received messages according to a predetermined rule;

Process a service request in a predetermined number of sorted messages.

11. The message processing method of an enterprise service bus according to claim 10, wherein the message comprises at least two service requests;

The message processing method of the enterprise service bus according to claim 10, wherein the processing the service request comprises: generating at least one access request according to a predetermined process, and invoking a corresponding application service based on the access request.

The message processing method of an enterprise service bus according to claim 10, wherein the packet is The message including the at least one service request is encrypted; the message is also decrypted prior to the processing the service request.