The work of inter-system interaction, with the development of information construction, as well as the industry's understanding of SOA and its low TOC (total cost of ownership) and other advantages, has been more and more users of the information level attention.
In this case, we will put aside the architecture plan of SOA, and discuss the agreement of integration between systems.
Inter-system interaction or integration (interconnection), as early as the birth of the information system, has appeared, but not obvious, or because of the early development platform, the development of language, such as the uniqueness of this demand is not very large outbreak out.
With the development of information construction, as well as the development of various development languages, the cross-lingual interaction between different business systems has become a big problem in front of CIOs.
Earlier, in order to ensure that data or messages are passed between different business systems in a secure, efficient and stable way, it is often used for message delivery using MQ-based messages. During this time, IBM's MQ products became an important medium for cross-business system information interaction. However, MQ is used only if MQ has provided API packages for a specific development language, such as MQ is not available, and cannot be used. And, the MQ product itself as a commercial product, its cost is very high. Because MQ supports XA transactions, the effectiveness of its data transfer can be guaranteed.
Later, people began to explore the use of the RDBMS-based "front-end" approach. That is, the two parties that need to interact, use a "intermediate database" that is separated from the respective business system, and read and write the data to the intermediate database, then perform subsequent operations. The advantage of using an RDBMS is that it directly leverages the relational database to support transactional platforms, and the relational database also supports XA transactions to ensure the validity of data transfer between different databases. The disadvantage is that you need to deal with a specific set of intermediate tables or intermediate databases, and sometimes not all of the problems. Moreover, when there are more than 3 systems that need to interact, each system needs to handle more than 1 intermediate table systems, causing a lot of work to the system vendors.
WebService was once thought to be the best solution for the integration of heterogeneous systems, independent of the support of any third-party system (no additional dedicated MQ or RDBMS servers are required), and the data interaction with each other is just the official norm. However, the problem with WebService is that the use of SOAP requires a multi-layered encapsulation of messages, and the efficiency of data interactions between webservice is severely impacted. Although, WebService can interact with a variety of data formats, there is no data format does not support the situation. However, the efficiency of webservice and its webservice-time-out problems still plague the system manufacturers.
With the advent of httpclient, as well as the large-scale use of data formats such as JSON, HTTP-based messaging interfaces have gradually been favored by everyone. On the one hand, the direct use of httpclient can simulate the browser's data manipulation and encapsulation, on the other hand, using HTTP-based messages, you can use HTTP's mature, reliable, open-source web clustering solution to improve overall efficiency. Also, the HTTP-based message format is virtually unlimited, and the various message formats for general applications can be delivered directly using HTTP-based messages. Currently, most PAAs platforms provide API interfaces that actually use HTTP-based JSON messages for data transfer.
For HTTP-based messages and webservice performance issues, the author has done a test.
On a low-profile PC, at the same time open the server and the client, 10,000 data, the use of HTTP-based message-by-article delivery, from the beginning to all receive and processing completed, about 465 seconds, and on the same machine, using WebService to interact, It takes 1180 seconds. The overall performance probably looked close to 60%.
Therefore, the author boldly speculated that in the future with the gradual improvement of the technology based on HTTP messaging, as well as the further improvement of relevant industry standards, a new HTTP-based message format will gradually replace the webservice, become mainstream.
Using HTTP-based messages instead of WebService data interactions