CN102025653B - Enterprise service bus and message processing method thereof - Google Patents
Enterprise service bus and message processing method thereof Download PDFInfo
- Publication number
- CN102025653B CN102025653B CN201010197480.7A CN201010197480A CN102025653B CN 102025653 B CN102025653 B CN 102025653B CN 201010197480 A CN201010197480 A CN 201010197480A CN 102025653 B CN102025653 B CN 102025653B
- Authority
- CN
- China
- Prior art keywords
- message
- request
- service
- esb
- service request
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/216—Handling conversation history, e.g. grouping of messages in sessions or threads
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention relates to an enterprise service bus and a message processing method thereof. The enterprise service bus comprises a message receiving unit, a message array unit, a processing thread group and a request processing unit, wherein the message receiving unit comprises a plurality of message receiving channels, and each message receiving channel is used for receiving a messages including at least one service request; the message array unit is used for receiving the messages from the message receiving channels and sorting the messages according to the predetermined rule; the processing thread group is used for receiving the sorted messages of the predetermined number from the message array unit; and the request processing unit is used for acquiring the service requests in the messages from the processing thread group and processing the service requests. Various application programs are integrated into an electronic transaction platform, and the call among all the application programs is implemented through the enterprise service bus; a service user does not need to carry out complicated asynchronous call, and the conversion from a synchronous mode to an asynchronous mode is carried out through the enterprise service bus.
Description
Technical field
The present invention relates to the e-commerce transaction technical field, relate in particular to a kind of a kind of ESB of E-commerce transaction platform and message treatment method of ESB of being applied to.
Background technology
At present, the application integration service between Large enterprise network is day by day complicated, and the system integration of traditional point-to-point formula seems awkward.In order to address this problem, people have proposed ESB (enterprise service bus, abbreviation ESB) concept, the subsystems that forms enterprise network accesses a public information platform in the mode that is similar to connector, relatively independent each other, carry out unified data dispatch by scheduling engine, with high effective integration data and operation flow.The definition of giving according to famous IT research and Gartner company of consulting firm, ESB is a kind of architecture, utilize Web service, message-oriented middleware, intelligent route and the switch technology of enterprise to realize, be the product that traditional intermediate technology is combined with technology such as XML, Web services, ESB provides connection maincenter the most basic in the network.The target of Enterprise Service Bus Technology is to realize enterprise's application integration in standardized mode, complete interconnected, intercommunication and the interoperability of business-to-business application system, standardization effort wherein comprises connector standards, management standardization, service message standardization and message criteria etc.
The appearance of ESB has changed traditional software architecture, can provide than the more cheap solution of traditional middleware software product, simultaneously it can also eliminate the technological disparity between the different application service, allows different application service coordinate operation, has realized communication and integration between different services.From function, ESB provides the tupe of event-driven and document guiding, and distributed administrative mechanism, and it supports content-based route and filtration, has possessed the transmittability of complex data, and a series of standard interface is provided.For example, the Chinese patent application that application number is " 200810227316.9 " discloses a kind of implementation method of ESB.
Existing E-commerce transaction platform, it is multi-to-multi that the service user directly calls the ISP, mixed and disorderly unordered, is difficult to the service in row is carried out to maintenance management; Between the realization of service call person and background service, the degree of coupling is too high, often pull one hair and move the whole body, background service has how many callers actually, application call what sundry services does unclear cause difficult in maintenance, reliability between service user and ISP, transaction, synchronous/asynchronous communication, safety certification management all need to realize separately between the two, lack a public architecture; And, lack background service is monitored, added up and the unified approach of analyzing data is provided, be not easy to the application of the architecture (Service-Oriented Architecture, J is called for short SOA) towards service is carried out to maintenance management.
Summary of the invention
The problem that the present invention solves is to provide a kind of ESB, while being applied to enterprise's electronic trade platform, can realize integrating between different application programs, the service user needn't carry out complicated asynchronous call, is completed the conversion that is synchronized to asynchronous mode by service bus.
For addressing the above problem, the invention provides a kind of ESB, comprising:
The message sink unit, comprise a plurality of message sink passages, and each message sink passage is for receiving the message that comprises at least one service request;
The message queue unit, for from described a plurality of message sink passage receipt messages, and sorted by pre-defined rule;
The processing threads group, for receiving the ordering message of predetermined quantity from described message queue unit;
Requesting processing, for from described processing threads group, obtaining the service request described message, and process this service request.
Optionally, describedly by pre-defined rule, sort and refer to that the time sequencing that sends or receive by message is sorted.
Optionally, described message comprises at least two service requests;
Described ESB also comprises: the request split cells sends to described message sink unit after described message being split into to service request.
Optionally, described message comprises at least two service requests;
Described ESB also comprises: the request split cells sends to described message queue unit after splitting into service request for the message that described message sink unit is received.
Optionally, described message comprises at least two service requests;
Described ESB also comprises: the request split cells sends to described processing threads group after splitting into service request for the message that described message queue unit is received.
Optionally, the described request processing unit comprises multiple request processing pipeline, and a kind of service request of pipeline alignment processing is processed in each request.
Optionally, described request processing unit processes service request comprises by predetermined flow process and generates at least one access request, and calls corresponding application service based on described access request.
Optionally, also comprise: the request Transfer pipe sends to corresponding application service for the access request that will generate from the described request processing unit.
Optionally, describedly comprise that the message of at least one service request is encrypted, described ESB also comprises decryption unit, for before the described request processing unit is by predetermined flow processing service request, described message being decrypted.
For solving the problems of the technologies described above, the present invention also provides a kind of message treatment method of ESB, comprising:
Receipt message, each message comprises at least one service request;
Message by pre-defined rule to described reception is sorted;
Service request in the ordering message of processing predetermined quantity.
Optionally, described message comprises at least two service requests;
Described message treatment method also comprises: described message is split into to service request.
Optionally, described processing service request comprises: generate at least one access request by predetermined flow process, and call corresponding application service based on described access request.
Optionally, describedly comprise that the message of at least one service request is encrypted;
Also comprise described message is decrypted before described processing service request.
Compared with prior art, the present invention has the following advantages:
When ESB provided by the invention is applied to electronic trade platform, the service user needn't directly call the service that the ISP provides, the service user is connected with electronic trade platform by standard interface with the ISP, various application programs are integrated in to electronic trade platform, and realize calling between each application program by ESB of the present invention, the service user needn't carry out complicated asynchronous call, is synchronized to the conversion of asynchronous mode by ESB.
And ESB of the present invention limits the quantity of the manageable message of electronic trade platform by the processing threads group, the message that surpasses this quantity is not responded, and avoids excessive to the pressure called of certain service, causes electronic trade platform to work as machine.
The accompanying drawing explanation
Fig. 1 is the inside structure schematic diagram of the ESB of the specific embodiment of the invention;
Fig. 2 is the configuration diagram of requesting processing;
Fig. 3 is the process flow block diagram of the access request of specific embodiment;
Fig. 4 is the schematic diagram that the ESB of the specific embodiment of the invention is applied to electronic trade platform.
Embodiment
When the ESB of the specific embodiment of the invention is applied to electronic trade platform, the service user needn't directly call the ISP, the service user is connected with electronic trade platform by standard interface with the ISP, various application services are integrated in to electronic trade platform, and realize calling each application service by ESB of the present invention, the service user needn't carry out complicated asynchronous call, is synchronized to the conversion of asynchronous mode by ESB; And ESB of the present invention limits the quantity of the manageable message of electronic trade platform by the processing threads group, the message that surpasses this quantity is not responded, avoid excessive to the pressure called of certain service (application service), cause electronic trade platform to work as machine.
With reference to figure 1, the ESB 100 of the specific embodiment of the invention, comprise: message sink unit 110, the message sent for receiving a plurality of service users, comprise a plurality of message sink passages, be respectively message sink passage 1, message sink passage 2 ... message sink passage n, each message sink passage receives the message that comprises at least one service request; In order to reduce the service user, different service requests is operated respectively, in a message sink passage, comprise at least one service request, the service user can once propose a plurality of service requests; When the service user once proposes a plurality of service request, form with message after a plurality of service request packings of the user being carried out by the request packaged unit sends, in this specific embodiment of the present invention, described message comprises at least two service requests, described ESB also comprises request split cells (not shown), after described message being split into to service request, sends to described message sink unit 110; In specific embodiments of the invention, the message sink passage is also by calling ciphering unit, by the message encryption of message sink passage reception.
In another embodiment of the present invention, the message of packing is split also can be before message sink passage receipt message, and described message comprises at least two service requests; Described ESB also comprises: the request split cells sends to described message queue receiving element after the described message that comprises at least one service request is split into to service request.In other embodiments of the invention, the message of packing is split also can be before processing threads group receipt message, and described message comprises at least two service requests; Described ESB also comprises: the request split cells, for from described message queue unit receipt message, and the message that comprises at least one service request that described message queue unit is received sends to described processing threads group after splitting into service request.
Requesting processing 140, for from described processing threads group 130, obtaining the service request described message, and process this service request; In this specific embodiment, requesting processing 140 comprises multiple request processing pipeline, and each request is processed pipeline and comprised a plurality of requests processing pipelines, a kind of service request of each request processing pipeline alignment processing; With reference to figure 2, requesting processing 140 comprises multiple request processing pipeline, be respectively the first request and process pipeline 10, the second request processing pipeline 20 ... pipeline n0 is processed in the request of N kind, each request is processed pipeline and is comprised a plurality of requests processing pipelines, the service request that pipeline can be processed a plurality of same types is processed in every kind of request, it is example that pipeline 10 is processed in the first request of take, and this first request is processed pipeline 10 and comprised that pipeline 11 is processed in the request of being respectively of a plurality of requests processing pipeline, pipeline 12 is processed in request ... pipeline 1n is processed in request; Described processing threads 130 obtains message from described message queue unit 110, and after the Message Processing that splits into service request that will obtain, sends to corresponding request to process pipeline; It should be noted that, there is corresponding relation in the kind that described request is processed pipeline with the kind request of service, pipeline is processed in the request of the corresponding identical type of each service request, the service request that each message comprises will enter the request of corresponding kind and process in pipeline, by request, processes the line treatment service request.Wherein, in this specific embodiment, each request is processed pipeline and is comprised the deciphering stage (stage), the processing stage (stage), this during corresponding message sink passage receipt message, is called ciphering unit to message encryption in deciphering stage, the message of encryption is deciphered by calling decryption unit, in other embodiments, pipeline is processed in each request can comprise the different stages, for example also can comprise decompression phase.In this specific embodiment of the present invention, process service request processing stage of described and comprise: generate at least one access request by predetermined flow process, and call corresponding application service based on described access request.Wherein, application service is provided by the ISP, call application service by access request, processing stage pipeline is processed in request, be to generate access request according to predetermined predetermined flow process, call application service by access request, application service is processed according to access request, generates the result of access request.
In specific embodiments of the invention, ESB also comprises: the request Transfer pipe, for addressing, the access request that will generate from the described request processing unit sends to corresponding application service.
The above sends a message to the processing procedure of application service for the service user, and the result that application service generates access request according to access request will return to the service user.In this specific embodiment of the present invention, it is contrary with processing procedure that the service user sends a message to application service that the result that application service generates access request according to access request returns to service user's process, at first the information that will call after application service by the request Transfer pipe sends to corresponding request to process pipeline, process pipeline by request and will send to corresponding processing threads after information encryption, request processing thread sends to corresponding message queue by the result of the service request that receives, send to afterwards corresponding message sink passage, when all service request results that comprise when a message are all returned to its corresponding message sink passage, message sink passage call request packaged unit, send to corresponding service user after all message packings that a message is comprised, now the user can obtain the result of sent message.It should be noted that, in the meaning of this use " correspondence " word be, the message of returning, the path of request when origin are returned.
Described message in the present invention can be the transaction message of extensive stock, the e-commerce transaction of steel of take is example, commodity are steel, transaction message comprises the transaction message (corresponding to outbound, the warehouse-in of steel) of issue steel stock, the Transaction Information of contract (corresponding to the purpose of buying, sale), also comprise registration message (corresponding to the member who is registered as electronic trade platform), new commodity message more, logout message (corresponding to the member who nullifies electronic trade platform), new registration message (corresponding to upgrading membership information) more, integration inquiry, credit inquiry etc.
It is the example explanation with information relevant with user profile such as credits that the service user of take need to inquire about integration, the service user sends searching user's information, in the message sink unit, the message sink passage receives the message of searching user's information, comprise the information such as integration, credit due to user profile, the message of searching user's information comprises the integration service request, credit services request etc., the packing such as corresponding integration service request, credit services request by searching user's information, send to the message sink passage of message sink unit afterwards, after the message sink passage receives the message of searching user's information, call encrypting module, to this inquiring user message encryption, afterwards the message of this searching user's information is sent to the message queue unit, also can be obtained by the message queue unit message of searching user's information from the message sink passage, call request split cells when message queue unit receipt message, searching user's information is split into to corresponding integration service request, credit services request etc., therefore the inquiring user message entered in the message queue unit is the service request after splitting, with reference to figure 1, if inquiring user message is corresponding to message 10, the integration service request is corresponding to service request 11, the credit services request is corresponding to service request 12, integration service request afterwards, credit services requests etc. are processed pipeline via entering request corresponding to service request after processing threads, the integration service request enters request corresponding to integration service request and processes pipeline, the credit services request enters request corresponding to credit services request and processes pipeline, for example, the integration service request enters the first request and processes the request processing pipeline 11 in pipeline 10, the credit services request enters the second request and processes the request processing pipeline in pipeline 20, process pipeline to the integration service request by each self-corresponding request, rear generation access request is processed in the credit services request, take the integration service request as example, request corresponding to integration service request processed pipeline and at first through the deciphering stage, the integration service request of encrypting deciphered, the access request in integration data storehouse is called in the processing stage generation that enters the integration service request after deciphering, inquire about integration from database.
The integration service request of above-described specific embodiment the processing stage, do not relate to concrete business, be the inquiry of simple integration, therefore do not relate to operation flow.Electronic trade platform relates to concrete transaction business, must have operation flow, according to predetermined operation flow, just can make business carry out smoothly, and predetermined flow process will determine the kind of the message that a transaction needs.
Utilize the concrete enforcement of the electronic trade platform of ESB of the present invention must rely on concrete operation flow, to guarantee carrying out smoothly of electronic transaction, can set different operation flows according to concrete transaction, this operation flow is corresponding to intended flow, and this operation flow is stored in the flow process unit, concrete while carrying out service request, according to service request the processing stage demand call operation flow.
The contract transaction of take in e-commerce transaction as example explanation operation flow the processing stage effect.The operation flow of the specific embodiment that Fig. 3 has been a contract transaction, according to the operation flow of the specific embodiment shown in Fig. 3, be divided into four kinds of message by the contract transaction: be respectively standard contract issue 200, corresponding to the first message; Application closing unit association 300, corresponding to the second message; Contract carries out 400, corresponding to the third message; Contract is honoured an agreement and is applied for 500, corresponding to the 4th kind of message; At first the member issues standard contract, and then closing unit is bound in application, after company's audit is passed through, contract just comes into effect, enter the contract that comes into force, then can carry out contract, enter the contract stage in execution, after contract is finished or carries out to a certain extent, the member can apply for honouring an agreement, and enters the middle contract of honouring an agreement, after contract is fulfiled, enter the contract of honouring an agreement, now contract is finished.At this, the issue contract of take describes as example, and for the transaction of other kinds, the kind according to transaction, can be divided into according to predetermined flow process the message of different kinds.
Describe the implementation process of the flow performing contract transaction predetermined according to this in detail with reference to figure 3.
When service user's operative norm contract issue 200, this message is a service request, without again it being split, in the time of processing stage in request processing pipeline, the operative norm contract gives out information, pipeline operation flow shown in calling graph 3 from the flow process unit is processed in request, request is processed pipeline, according to the predetermined rule of issuing in relevant operation flow with standard contract, this service request is divided into to a plurality of steps, be specially: step 201, check whether contract price is passed through, the contract price in pipeline calling data storehouse is processed in now request, if contract price is passed through, carry out step 202, check that whether publisher member's credit is enough, now request is processed pipeline and is called credit block, can not issue contract if member's credit is not enough, if member's credit is enough, can issue contract, and generation standard contract member credit takies, credit by credit block Standard modification contract member, carry out step 203 afterwards, generate standard contract, and the result feedback that will generate standard contract is to the service user, complete the service request of standard contract issue.
Continuation is with reference to figure 3, the manager of electronic trade platform sees the standard contract of issue, want to buy the standard contract of this issue, make it to become while coming into force contract, application for execution closing unit (corresponding to real client) associated 300, this is the second message, this message is a service request, without again it being split, request is processed pipeline, according to the predetermined rule in operation flow, this service request is divided into to a plurality of steps, be specially: step 301, service management personnel audit, wherein the content of audit is stipulated according to the actual needs, if audit is not passed through, contract can not associated closing unit, and the result that this can not associated closing unit is sent to the service user, if audit is passed through, carry out step 302, the service management personnel input by hand contract and estimate that loss takies, and produce associated Contract risk credit and take (corresponding member's credit), now call credit block simultaneously, change member's credit by credit block, enter afterwards step 303, the service management personnel upload contract textual scan part, set up real client contract, and simultaneously using actual customer contract scanned copy as associated contract annex, next enter step 304, produce associated contract credit and take (corresponding transaction credit), release standard contract credit takies (corresponding to member's credit) simultaneously, now by calling credit block, complete the release with member's credit that takies to transaction credit, enter step 305, associated contract generates successfully, the come into force result of contract of generation, and this result is returned.
Continuation is with reference to figure 3, carry out 400 o'clock carrying out contract, corresponding the third message, this message is a service request, without again it being split, request is processed pipeline and according to the predetermined rule of intended flow, the execution contract that comes into force specifically is divided into: step 401, find goods, after finding goods, contract enters contract in execution by the contract that comes into force, now can call credit block, according to the ratio release portion of execution amount and contract amount or whole associated contract credit, and result be sent to the service user by the message sink passage.
When the service user delivers stock, after the consignee receives goods, to carry out contract honour an agreement the application 500, corresponding to the 4th kind of message, this message is a service request, without again it being split, request is processed pipeline and according to the pre-defined rule of intended flow, this service request is divided into to a plurality of steps and is specially: step 501, company's audit, if audit is not passed through, Output rusults can not be honoured an agreement, if audit is passed through, the release contract is not honoured an agreement and is taken credit, call credit block, complete and discharge contract and do not honour an agreement and take credit, after completing the fulfiling of contract, enter step 502, the middle contract of honouring an agreement is converted into the contract of honouring an agreement, now can call integration module, carry out the examination of contract integration and distribute.
When above-described ESB provided by the invention is applied to electronic trade platform, the service user needn't directly call the service that the ISP provides, the service user is connected with electronic trade platform by standard interface with the ISP, various application programs are integrated in to electronic trade platform, and realize calling between each application program (take credit block describe for example) by ESB of the present invention in this specific embodiment, the service user needn't carry out complicated asynchronous call, be synchronized to the conversion of asynchronous mode by ESB.
Above-described specific embodiment, the independent contract information of only take describes as example, in instantiation, can there be a plurality of different clients to send information simultaneously, quantity by set handling sets of threads thread, make sets of threads once can only process the message of some threads, avoid excessive to the pressure called of certain service, cause electronic trade platform to work as machine.
ESB of the present invention is present in JVM (Java Virtual Machine, Java Virtual Machine).The node of ESB outside is external service user and ISP, has represented that ESB wants integrated external entity, and the service module that these external entities can be bound by various technology and ESB is mutual.
Fig. 4 is the framework schematic diagram that ESB is applied to electronic trade platform,
Corresponding with above-described ESB, the present invention also provides a kind of message treatment method of ESB, comprising: receipt message, and each message comprises at least one service request;
Message by pre-defined rule to described reception is sorted;
Service request in the ordering message of processing predetermined quantity.
Wherein, described message comprises at least two service requests; Described message treatment method also comprises: described message is split into to service request.
Described processing service request comprises: generate at least one access request by predetermined flow process, and call corresponding application service based on described access request.
Describedly comprise that the message of at least one service request is encrypted; Also comprise described message is decrypted before described processing service request.
Although the present invention with preferred embodiment openly as above; but it is not for limiting the present invention; any those skilled in the art without departing from the spirit and scope of the present invention; can utilize method and the technology contents of above-mentioned announcement to make possible change and modification to technical solution of the present invention; therefore; every content that does not break away from technical solution of the present invention; any simple modification, equivalent variations and the modification above embodiment done according to technical spirit of the present invention, all belong to the protection range of technical solution of the present invention.
Claims (10)
1. an ESB is characterized in that comprising:
The message sink unit, comprise a plurality of message sink passages, and each message sink passage is for receiving the message that comprises at least one service request;
The message queue unit, for from described a plurality of message sink passage receipt messages, and sorted by pre-defined rule;
The processing threads group, for receiving the ordering message of predetermined quantity from described message queue unit;
Requesting processing, for from described processing threads group, obtaining the service request described message, and process this service request, and described request processing unit processes service request comprises by predetermined flow process and generates at least one access request;
The request Transfer pipe, for service addressing, the access request that will generate from the described request processing unit sends to corresponding application service, to call corresponding application service;
Realize calling of each application service by described ESB, the service user needn't carry out complicated asynchronous call.
2. ESB as claimed in claim 1, is characterized in that, describedly by pre-defined rule, sorts and refer to that the time sequencing that sends or receive by message is sorted.
3. ESB as claimed in claim 1, is characterized in that, when described message comprises plural service request,
Described ESB also comprises: the request split cells sends to described message sink unit after described message being split into to service request.
4. ESB as claimed in claim 1, is characterized in that, when described message comprises plural service request,
Described ESB also comprises: the request split cells sends to described message queue unit after splitting into service request for the message that described message sink unit is received.
5. ESB as claimed in claim 1, is characterized in that, when described message comprises plural service request,
Described ESB also comprises: the request split cells sends to described processing threads group after splitting into service request for the message that described message queue unit is received.
6. ESB as claimed in claim 1, is characterized in that, the described request processing unit comprises multiple request processing pipeline, and a kind of service request of pipeline alignment processing is processed in each request.
7. ESB as claimed in claim 1, it is characterized in that, describedly comprise that the message of at least one service request is encrypted, described ESB also comprises decryption unit, for before the described request processing unit is by predetermined flow processing service request, described message being decrypted.
8. the message treatment method of an ESB is characterized in that comprising:
From a plurality of message sink passage receipt messages, each message comprises at least one service request, and described message sink passage is for receiving the message that comprises at least one service request;
Message by pre-defined rule to described reception is sorted;
Receive the ordering message of predetermined quantity;
Obtain the service request in the message that sorts of described predetermined quantity;
Service request in the ordering message of processing predetermined quantity, wherein processing service request comprises: by predetermined flow process, generate at least one access request, and carry out service addressing based on described access request utilization request Transfer pipe, to call corresponding application service;
By described message treatment method, ESB is realized calling of each application service, and the service user needn't carry out complicated asynchronous call.
9. the message treatment method of ESB as claimed in claim 8, is characterized in that, when described message comprises plural service request,
Described message treatment method also comprises: described message is split into to service request.
10. the message treatment method of ESB as claimed in claim 8, is characterized in that, describedly comprises that the message of at least one service request is encrypted;
Also comprise described message is decrypted before described processing service request.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201010197480.7A CN102025653B (en) | 2010-06-04 | 2010-06-04 | Enterprise service bus and message processing method thereof |
| PCT/CN2010/076364 WO2011150600A1 (en) | 2010-06-04 | 2010-08-26 | Enterprise service bus and message processing method for enterprise service bus |
| US12/935,239 US8805938B2 (en) | 2010-06-04 | 2010-08-26 | Enterprise service bus and message processing method thereof |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201010197480.7A CN102025653B (en) | 2010-06-04 | 2010-06-04 | Enterprise service bus and message processing method thereof |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN102025653A CN102025653A (en) | 2011-04-20 |
| CN102025653B true CN102025653B (en) | 2014-01-08 |
Family
ID=43866525
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201010197480.7A Expired - Fee Related CN102025653B (en) | 2010-06-04 | 2010-06-04 | Enterprise service bus and message processing method thereof |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN102025653B (en) |
| WO (1) | WO2011150600A1 (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8805938B2 (en) | 2010-06-04 | 2014-08-12 | Xiben New Line Stock Co., Ltd. | Enterprise service bus and message processing method thereof |
| CN106375173A (en) * | 2016-08-31 | 2017-02-01 | 中车青岛四方机车车辆股份有限公司 | Method and device for accessing information system to enterprise service bus |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103455366A (en) * | 2012-06-01 | 2013-12-18 | 阿里巴巴集团控股有限公司 | Method and device for calling services of external system |
| CN102868608A (en) * | 2012-09-04 | 2013-01-09 | 江苏大学 | Message mechanism-based enterprise service bus system |
| CN107277780B (en) * | 2016-04-07 | 2020-11-20 | 中兴通讯股份有限公司 | Broadcast message sending method and device and mobile terminal |
| CN105978968A (en) * | 2016-05-11 | 2016-09-28 | 山东合天智汇信息技术有限公司 | Real-time transmission processing method, server and system of mass data |
| CN105872094B (en) * | 2016-05-31 | 2019-01-01 | 山东大学 | A kind of service robot cloud platform interface system and method based on SOA |
| CN107102905B (en) * | 2017-04-13 | 2020-08-11 | 华南理工大学 | Artifect-based big data service platform and platform processing method |
| CN108805379A (en) * | 2017-05-03 | 2018-11-13 | 北京京东尚科信息技术有限公司 | Support that multi-mode is honoured an agreement the system and method for flow |
| CN107632894A (en) * | 2017-08-09 | 2018-01-26 | 中国电力科学研究院 | A kind of implementation method and device for power market transaction service call |
| CN108966190A (en) * | 2018-06-25 | 2018-12-07 | 北京旅居四方科技有限公司 | Water power stake and method, equipment and storage medium for process instruction |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1740974A (en) * | 2005-09-14 | 2006-03-01 | 艾默生网络能源有限公司 | A threading scheduling management method and system |
| CN101656659A (en) * | 2008-08-19 | 2010-02-24 | 中兴通讯股份有限公司 | Method for caching mixed service flow and method and device for storing and forwarding mixed service flow |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20080076633A (en) * | 2007-02-16 | 2008-08-20 | 삼성전자주식회사 | Method and system for providing service communication in a communication system |
| US8079033B2 (en) * | 2007-02-20 | 2011-12-13 | Amadeus Sas | System and method for balancing information loads |
| US8488448B2 (en) * | 2007-09-26 | 2013-07-16 | Verizon Patent And Licensing Inc. | System and method for message sequencing in a broadband gateway |
| CN101651631B (en) * | 2008-08-12 | 2013-01-30 | 新奥特（北京）视频技术有限公司 | Method for message access in system integration of global station network of television station |
-
2010
- 2010-06-04 CN CN201010197480.7A patent/CN102025653B/en not_active Expired - Fee Related
- 2010-08-26 WO PCT/CN2010/076364 patent/WO2011150600A1/en active Application Filing
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1740974A (en) * | 2005-09-14 | 2006-03-01 | 艾默生网络能源有限公司 | A threading scheduling management method and system |
| CN101656659A (en) * | 2008-08-19 | 2010-02-24 | 中兴通讯股份有限公司 | Method for caching mixed service flow and method and device for storing and forwarding mixed service flow |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8805938B2 (en) | 2010-06-04 | 2014-08-12 | Xiben New Line Stock Co., Ltd. | Enterprise service bus and message processing method thereof |
| CN106375173A (en) * | 2016-08-31 | 2017-02-01 | 中车青岛四方机车车辆股份有限公司 | Method and device for accessing information system to enterprise service bus |
| CN106375173B (en) * | 2016-08-31 | 2019-08-27 | 中车青岛四方机车车辆股份有限公司 | A kind of method and device of information system access Enterprise Service Bus |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2011150600A1 (en) | 2011-12-08 |
| CN102025653A (en) | 2011-04-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102025653B (en) | Enterprise service bus and message processing method thereof | |
| US8805938B2 (en) | Enterprise service bus and message processing method thereof | |
| CN102025649A (en) | Message processing method of enterprise service bus | |
| CN102025650A (en) | Message processing system and message processing method of enterprise service bus | |
| Korpela et al. | Digital supply chain transformation toward blockchain integration | |
| US20150379510A1 (en) | Method and system to use a block chain infrastructure and Smart Contracts to monetize data transactions involving changes to data included into a data supply chain. | |
| CN102024234B (en) | Electronic transaction service platform | |
| CN102025651B (en) | Event-driven method applied to enterprise service bus | |
| CN102663009A (en) | Web-service integration method supporting data privatization of enterprise users | |
| CN110189229A (en) | Insure core business system in internet | |
| CN111538757A (en) | Data storage method, query method, device, server and medium | |
| CN102263809A (en) | Method for realizing service safety control based on enterprise service bus and apparatus thereof | |
| CN111127211A (en) | Block chain based transaction method, system, device and computer readable storage medium | |
| CN102024233A (en) | Transaction processing system | |
| CN109985390B (en) | Virtual asset management method and system | |
| CN104240049A (en) | Comprehensive order handling platform | |
| CN1170404C (en) | System and method for provider to transmit data | |
| CN103150171A (en) | Product combination engine device and system and service method | |
| CN113609531A (en) | Block chain based information interaction method, device, equipment, medium and product | |
| CN115086429B (en) | Request integration system and request integration method | |
| CN113067885B (en) | Application system, request processing method, electronic device and storage medium | |
| Schulz et al. | Architecting cross-organisational B2B interactions | |
| Bakraouy et al. | Autonomous SLAs Negotiation Based on Agreement-Broker: Services Availability | |
| Lam et al. | Cooperative brokerage integration for transaction capacity sharing: A case study in Hong Kong | |
| Pokraev et al. | Business level service-oriented enterprise application integration |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| ASS | Succession or assignment of patent right |
Owner name: XIBEN NEW LINE E-COMMERCE CO., LTD. Free format text: FORMER OWNER: XIBEN NEW LINE CO., LTD Effective date: 20120202 |
|
| C41 | Transfer of patent application or patent right or utility model | ||
| C53 | Correction of patent of invention or patent application | ||
| CB02 | Change of applicant information |
Address after: 200437, room 990, 309 East Sports Club Road, Shanghai, Hongkou District Applicant after: West Ben Shinkansen Ltd. Address before: 200437, room 990, 309 East Sports Club Road, Shanghai, Hongkou District Applicant before: XiBen New Line Stock Co.,Ltd. |
|
| COR | Change of bibliographic data |
Free format text: CORRECT: ADDRESS; FROM: 200437 HONGKOU, SHANGHAI TO: 215434 SUZHOU, JIANGSU PROVINCE |
|
| TA01 | Transfer of patent application right |
Effective date of registration: 20120202 Address after: 215434 No. 88 Binjiang Avenue, Taicang Port Development Zone Applicant after: XiBen New Line Stock Co.,Ltd. Address before: 200437, room 990, 309 East Sports Club Road, Shanghai, Hongkou District Applicant before: West Ben Shinkansen Ltd. |
|
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20140108 Termination date: 20180604 |