Data Exchange Protocol in Software System Development

When one person wants to tell another person one thing, we can communicate by phone, email, text message, IM tool or in a face-to-face manner. This method is similar to the systemData ExchangeIt must be implemented through tcp, udp, and pipelines. When two people communicate, we need a common language to understand the meaning of each other. Similarly, to exchange data between the two systems, we also need to define an agreement that both parties understand, we call it "Data Exchange Protocol ".

Data Exchange Protocol

The purpose of the Data Exchange protocol is to allow correct data interaction between two systems. Therefore, almost all development languages provide easy-to-use data exchange functions. For example, a system developed using the JAVA language uses a MySQL database to store data, that is, data exchange with MySQL through the MySQL Data Exchange Protocol; the RMI of JAVA can facilitate distributed data exchange across machines. RMI is also a data exchange protocol.

Generally, when we exchange data between different systems and languages, we will choose a Common Exchange Protocol or define an easy-to-use exchange protocol. WebService has been very popular. In the Web 2.0 era, lightweight REST protocols have been sought after again. So what protocol should we choose in our system?

How to select a Data Exchange Protocol

The protocol we choose has a lot to do with our application scenarios. We need to consider whether our development is convenient, whether interfaces are easy to publish, whether we need to consider bandwidth occupation costs, serialization and deserialization performance, interface protocol scalability, and so on. Next we will look at several common exchange protocol implementations.

The table above lists some features of some common data exchange protocols. There is no good or bad here, just to explain that different data exchange protocols are different, so we need to select in our application scenarios.

Open

Open platforms like Weibo and SNS and systems that provide javascript interface calls to static html pages all belong to this type. This type features:

1. The caller is not completely controllable and is directed to the public network. You may not know who the caller is, what language it is, and how it is calling your data interface;

2. The interface traffic is usually very large and requires high performance and throughput;

3. Security issues need to be considered. Data Submitted externally may not be legal.

In this case, you need to consider the bandwidth consumption of data transmission, the ease of use of data exchange protocols, and the degree of multi-language support. In the past, javascript interface calls for html pages were generally in XML format. In recent years, they have almost all been converted to json format, because json transmission is smaller and easier to use than XML.

For open platforms, there are many application scenarios, So multiple exchange protocol formats are required. XML and json are basically provided. To improve the performance of the platform and the client, you can also provide the protobuf binary Exchange Protocol and increase compression support to save the performance consumption of bandwidth transmission and resolution.

Internal Services

For a large system, internal service data exchange is everywhere. From the basic and common database data exchange, memcached cache data exchange, Message Queue data exchange to the RPC service framework used between systems, and so on, it can be counted as the data exchange of internal services. Internal Services are characterized by no firewall considerations, no openness, fast speed, and no bandwidth cost ).

Data exchange protocols for internal services have a large selection space. Generally, consider the following:

1. Data Exchange Protocol Performance

2. Whether cross-language support is required

3. Message Body Size of the Data Exchange Protocol

Persistent Storage

For persistent storage, each data exchange protocol can actually be implemented. Generally, you need to consider the following based on the Application Scenario:

1. Whether manual reading is available

2. Storage space consumption

3. serialization and deserialization Performance

4. Compression?

Cross-language

Assume that the front-end page display layer of our website is developed in PHP and the intermediate business logic is developed in JAVA. This involves cross-language data exchange. As long as the system is not simply using a language, you must consider this issue. In fact, considering future expansion and demand changes, it is best to consider cross-language data interaction protocols.

Data Exchange Protocol can be upgraded

When selecting the Data Exchange Protocol, we also need to consider what is similar to the database table? Scalability during schema design. For example, a data exchange protocol interface that provides user information now contains the user name, gender, and address information. During the upgrade, an IP address information for the last logon is added. If you do not consider the impact of the Data Exchange Protocol upgrade, it is likely that the previous client encountered an exception or the old data could not be correctly parsed.

Clever Use of compatible protocols

The clever use of compatible protocols is very useful. New Product compatibility provides existing mature data exchange protocols, which can reduce the use threshold and product development speed. For example, Sina's open-source memcacheQ uses the memcached protocol.

Summary

There are many common open-source implementations of the Data Exchange Protocol. The data exchange protocol is just a very broad saying. In fact, as long as data serialization and deserialization are realized, it can be said that it is a protocol that can exchange data. The performance of the Data Exchange Protocol is actually the serialization and deserialization performance. If RPC is added, the performance of the RPC implementation is also very significant.