serializing structured data in a standardized serialized data structure

Abstract

A method (500) for storing serialized structured data in a standardized serialized data structure in general. The method includes obtaining structured data (110) comprising one or more field pairs (112), and encoding the structured data into serialized self-describing data (160). Each field pair includes a respective field identifier (114) and a field value (116) associated with the respective field identifier. The serialized self-describing data includes one or more self-describing data portions (161), each self-describing data portion representing a respective one of the one or more field pairs. Each self-describing portion of the one or more self-describing portions includes a first bit string (162) representing the respective field identifier, and a second bit string (164) representing the field value associated with the respective field identifier. The method further includes sending the serialized self-describing data to a remote entity (32).

Description

Technical Field

[0001] This invention relates to storing serialized structured data in a standardized serialized data structure in general. Background Technology

[0002] Structured data is widely used to provide information between different software applications. Typically, data must be serialized into a series of bits before communication between different entities. Usually, the serialized data structure is not self-describing. That is, the serialized data does not include the information necessary to understand or decode the message; instead, the receiver must access a separate specification containing the information in order to decode the message. Summary of the Invention

[0003] One aspect of this disclosure provides a computer-implemented method that, when executed on data processing hardware, causes the hardware to perform operations for generally storing serialized structured data in a standardized serialized data structure. The operations include obtaining structured data comprising one or more field pairs and transcoding the structured data into serialized self-describing data. Each field pair includes a corresponding field identifier and a field value associated with the corresponding field identifier. The serialized self-describing data includes one or more self-describing data portions, each self-describing data portion representing a corresponding field pair from the one or more field pairs. Each of the one or more self-describing portions includes a first bit string representing the corresponding field identifier and a second bit string representing the field value associated with the corresponding field identifier. The operation also includes sending the serialized self-describing data to a remote entity.

[0004] Implementations of this disclosure may include one or more of the following optional features. In some implementations, the operation further includes obtaining a data specification for a specified field pair of serialized non-self-describing data, receiving the serialized non-self-describing data, and encoding the serialized non-self-describing data into structured data using the data specification. In these implementations, sending serialized self-describing data to a remote entity may cause the remote entity to: determine a routing path based on each of one or more self-describing data portions, each of the one or more self-describing data portions representing a corresponding field pair in one or more field pairs of structured data; encode the serialized self-describing data into serialized non-self-describing data; and send the serialized non-self-describing data based on the determined routing path. Optionally, sending serialized self-describing data to a remote entity may cause the remote entity to: transform the serialized self-describing data based on each of one or more self-describing data portions, each of the one or more self-describing data portions representing a corresponding field pair in one or more field pairs of structured data; encode the transformed serialized self-describing data into new serialized non-self-describing data; and send the new serialized non-self-describing data to a second remote entity. In some examples, serializing non-self-describing data includes a protocol buffer. Here, serializing self-describing data may include encoding the protocol buffer of the non-self-describing data into another protocol buffer.

[0005] In some implementations, the field identifier in each of one or more field pairs includes a length-delimited variable-length integer and / or the field value in each of one or more field pairs includes at least one variable-length integer. In some examples, encoding structured data into serialized self-describing data includes, for each field pair, selecting a field type representing the corresponding field value. The field type may include one of the following: a 32-bit integer, a 64-bit integer, a Boolean, or a string. The serialized self-describing data may further include metadata. Here, the metadata may include a checksum to verify the integrity of the serialized self-describing data.

[0006] Another aspect of the present invention provides a system for generally storing serialized structured data in a standardized serialized data structure. The system includes data processing hardware and memory hardware communicating with the data processing hardware and storing instructions that, when executed on the data processing hardware, cause the data processing hardware to perform an operation. The operation includes obtaining structured data comprising one or more field pairs and encoding the structured data into serialized self-describing data. Each field pair includes a corresponding field identifier and a field value associated with the corresponding field identifier. The serialized self-describing data includes one or more self-describing data portions, each self-describing data portion representing a corresponding field pair from the one or more field pairs. Each of the one or more self-describing portions includes a first bit string representing the corresponding field identifier and a second bit string representing the field value associated with the corresponding field identifier. The operation also includes transmitting the serialized self-describing data to a remote entity.

[0007] This aspect of the disclosure may include one or more of the following optional features. In some embodiments, the operation further includes obtaining a data specification for a specified pair of field pairs of serialized non-self-describing data, receiving the serialized non-self-describing data, and encoding the serialized non-self-describing data into structured data using the data specification. In these embodiments, sending serialized self-describing data to a remote entity may cause the remote entity to: determine a routing path based on each of one or more self-describing data portions, each of the one or more self-describing data portions representing a corresponding field pair in one or more field pairs of structured data; encode the serialized self-describing data into serialized non-self-describing data; and send the serialized non-self-describing data based on the determined routing path. Optionally, sending serialized self-describing data to a remote entity may cause the remote entity to: transform the serialized self-describing data based on each of one or more self-describing data portions, each of the one or more self-describing data portions representing a corresponding field pair in one or more field pairs of structured data; encode the transformed serialized self-describing data into new serialized non-self-describing data; and send the new serialized non-self-describing data to a second remote entity. In some examples, serializing non-self-describing data includes a protocol buffer. Here, serializing self-describing data may include encoding the protocol buffer of the non-self-describing data into another protocol buffer.

[0008] In some implementations, the field identifier in each of one or more field pairs includes a length-delimited variable-length integer and / or the field value in each of one or more field pairs includes at least one variable-length integer. In some examples, encoding structured data into serialized self-describing data includes, for each field pair, selecting a field type representing the corresponding field value. The field type may include one of the following: a 32-bit integer, a 64-bit integer, a Boolean, or a string. The serialized self-describing data may further include metadata. Here, the metadata may include a checksum to verify the integrity of the serialized self-describing data.

[0009] Details of one or more embodiments of this disclosure are set forth in the accompanying drawings and the following description. Other aspects, features, and advantages will become apparent from the specification, the drawings, and the claims. Attached Figure Description

[0010] Figure 1 This is a schematic diagram of an example system for standardizing serialized data structures.

[0011] Figure 2 This is a schematic diagram of an example system that receives non-self-describing serialized data and external specifications.

[0012] Figure 3 This is a schematic diagram of a remote entity that routes and serializes self-describing data.

[0013] Figure 4 This is a schematic diagram of a block diagram used for protocol conversion buffers.

[0014] Figure 5 This is a flowchart illustrating an exemplary arrangement of operations for storing serialized structured data in a standardized serialized data structure.

[0015] Figure 6 This is a schematic diagram of an example computing device that can be used to implement the systems and methods described in this paper.

[0016] In the various figures, the same reference numerals denote the same elements. Detailed Implementation

[0017] In an increasingly computerized and networked world, structured data is frequently used to transfer information between systems and applications. Transmitting messages to other systems (e.g., via a network) typically requires serialization. Once serialized, the data can be self-describing or non-self-describing. Messages with self-describing data include all the information necessary to describe the message's format and meaning (i.e., data and metadata). For example, self-describing data includes, for instance, pairs of field identifiers and field values. Conversely, messages with non-self-describing data lack the information necessary to determine the message's format and meaning. For example, if a message includes the field identifier "Employee ID" and the field value "101," non-self-describing data might only include the value "101," without the context provided by the field identifier "Employee ID." Non-self-describing data is often used, for example, to reduce bandwidth requirements. However, self-describing data can be important for reducing coupling between systems or facilitating independent evolution.

[0018] For example, protocol buffering is a common method for serializing structured data. Because protocol buffers are language-neutral and platform-neutral, they are very useful for transferring information or data storage between different applications over a wire. Protocol buffers effectively encode the values ​​of structured data but not the associated field identifiers. Therefore, protocol buffers produce non-self-describing serialized data. That is, there is no way to tell the identifiers, meanings, or full data types of fields without an external specification. However, in some cases, sending self-describing messages is beneficial. For example, a self-describing message can be inspected to determine the message's routing destination based on its content. While protocol buffers can be serialized to generate, for example, strings to become self-describing, this technique is not type-safe and is fragile.

[0019] The embodiments described herein pertain to a system that generally stores serialized structured data in a standardized serialized data structure (e.g., a protocol buffer). The system acquires structured data comprising one or more field pairs. Each field pair includes a corresponding field identifier and a field value associated with the field identifier. The system encodes the structured data into serialized self-describing data comprising one or more self-describing portions, each self-describing portion including a first bit string representing the corresponding field identifier and a second bit string representing the field value associated with the corresponding field identifier. The serialized self-describing data is then sent to a remote entity.

[0020] refer to Figure 1In some implementations, example system 100 includes processing system 10. Processing system 10 may be a single computer, multiple computers, or a distributed system (e.g., a cloud environment) having fixed or scalable / elastic computing resources 12 (e.g., data processing hardware) and / or storage resources 14 (e.g., storage hardware). Processing system 10 executes data structure encoding converter 150 to obtain structured data 110. Data structure encoding converter 150 receives structured data 110 from another processing system (via wired or wireless communication), via the execution of program routines stored on memory hardware 14 of processing system 10, and / or via user input (e.g., keyboard and mouse, touchscreen, etc.) to processing system 10.

[0021] A software application (i.e., a software resource) can refer to computer software that instructs a computing device to perform a task. In some examples, a software application may be referred to as an "application," "program," or simply a "program." Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and gaming applications.

[0022] Structured data 110 includes one or more field pairs 112, 112an. Each field pair includes a field identifier 114 and an associated field value 116. The field identifier 114 identifies the field pair 112, while the field value 116 quantizes the field pair 112. A data structure encoder 150 encodes the structured data 110 into serialized self-describing data 160. In some examples, the data structure encoder 150 selects the field type representing the corresponding field value 116. For example, the "true" field value 116 can be represented as a Boolean field type. Field types include, for example, 32-bit integers, 64-bit integers, Boolean, strings, integer arrays, etc.

[0023] For each field pair 112, the serialized self-describing data 160 includes corresponding self-describing data portions 161, 161an. Each self-describing data portion 161 includes the first string 162, 162an representing the field identifier 114 of the corresponding field pair 112, and the second string 164, 164an representing the field value 116 of the associated field identifier 114. Because the field identifier 114 describes the field pair 112, the serialized data 160 is self-describing and does not require an external specification to understand the field values.

[0024] Processing system 10 sends serialized self-describing data 160 to remote entity 30 via, for example, network 20. Remote entity 30 can decode and process serialized self-describing data 160 without extracting external specifications (e.g., from processing system 10).

[0025] Now for reference Figure 2 In some examples, processing system 10 receives non-self-describing serialized data 210 from a remote entity (e.g., another computer or server connected to processing system 10 via a network). Because data 210 is non-self-describing, processing system 10 obtains a data specification 220 that specifies the field pairs 112 of the serialized non-self-describing data 210. For example, data specification 220 may specify the location and field identifier 114 associated with the field value 116 of the non-self-describing serialized data 210. Processing system 10 may retrieve data specification 220 from another remote entity (e.g., the remote entity that sent the non-self-describing serialized data 210). Processing system 10 may obtain data specification 220 from a user (e.g., via user input). Ideally, processing system 10 obtains data specification 220 before receiving non-self-describing serialized data 210 and uses data specification 220 to decode all received or acquired messages associated with data specification 220. The processing system 10 can establish the association between the non-self-describing serialized data 210 and the data specification 220 based on the identification information (e.g., metadata) within the non-self-describing serialized data 210 itself and / or based on the sender.

[0026] The processing system can use data specification 220 to encode and convert non-self-describing serialized data 210 into... Figure 1 The serialized self-describing data 160 is shown. The processing system 10 can send the self-describing serialized data 160 to the remote entity 30.

[0027] In some examples, processing system 10 includes additional metadata 230 to the serialized self-describing data 160. This metadata can help remote entity 30 (or any other receiver) transform and / or verify the serialized self-describing data 160. For example, metadata 230 includes checksums, cyclic redundancy check (CRC), hashes, signatures, etc. Remote entity 30 can use metadata 230 to help transform the serialized self-describing data 160 into another form. Additionally or alternatively, remote entity 30 uses metadata 230 to verify the self-describing data 160 (e.g., to verify that the data has not been altered or corrupted). If an error is detected, remote entity 30 can notify processing system 10 (e.g., request a retransmission).

[0028] Now for reference Figure 3In some implementations, the processing system 10 encodes acquired data 110 (e.g., from user input) or received data 210 (e.g., from another networked computing device) into serialized self-describing data 160 and sends the serialized self-describing data 160 to a remote entity 30. In this example, the remote entity 30 may be a router or an intermediate box or another entity configured to route received messages to different destinations. Here, the remote entity 30 determines the routing path 310 for data 110, 210 based on field pairs 112. That is, the remote entity 30 may examine the contents of the serialized self-describing data 160 (i.e., field identifier 114 and field value 116 of field pairs 112) to determine the destination of data 110, 210. For example, when the field value 116 of field identifier 114 and / or field pair 112 meets a specific criterion (e.g., including a specific field pair 112, including a specific field value 116, one or more field values ​​116 meeting one or more thresholds, etc.), remote entity 30 can route data 110, 210 to a second remote entity 32a. When the field value 116 of field identifier 114 and / or field pair 112 fails to meet a threshold, remote entity 30 can route data 110, 210 to a different second entity 32b. Additionally or alternatively, remote entity 30 can utilize the received messages to perform other tasks (e.g., filtering, checking, etc.).

[0029] In some examples, remote entity 30 encodes the serialized self-describing data 160 back into serialized non-self-describing data 210 before transmitting the message to the second remote entities 32a-b based on the determined routing path 310. For example, the second remote entities 32a-b may perform legacy applications that expect or require serialized non-self-describing data 210 (e.g., sending data that does not include field identifier 114). In this way, system 100 allows for inspection, routing, filtering, and other messaging services that are typically non-self-describing (e.g., protocol buffering). In other examples, remote entity 30 transmits the self-describing serialized data 160 to the second remote entities 32a-b without encoding the data back into a non-self-describing format (i.e., transmitting data that includes both field identifier 114 and field value 116 of field pair 112).

[0030] In other examples, remote entity 30 transforms the serialized self-describing data 160 before transmitting the data to the second remote entities 32a-b. The remote entities may also encode the transformed serialized self-describing data 160 into new serialized non-self-describing data 320. Remote entity 30 may then send the new serialized non-self-describing data 320 to the second remote entities 32a-b. That is, alternatively, or in addition to encoding the serialized self-describing data 160 into serialized non-self-describing data 210, remote entity 30 may first transform the serialized self-describing data 160. For example, remote entity 30 may change one or more field identifiers 114 or field values ​​116 of field pair 112, and / or remote entity 30 may add or subtract field pair 112. After transformation, remote entity 30 may send the transformed data 160, or alternatively, encode the transformed data 160 into new serialized non-self-describing data 320.

[0031] Now for reference Figure 4 Block diagram 400 illustrates how, in some implementations, system 100 transforms a specific serialized data structure, such as processing a protocol buffer received by system 100 from another remote entity or application (i.e., serializing non-self-describing data 210). In some examples, at 410, the system receives a protocol buffer. The protocol buffer is not self-describing. At 420, the system transforms the protocol buffer into a self-describing intermediate representation using the data specification associated with the protocol buffer. The intermediate representation can be another protocol buffer configured to define other protocol buffers (i.e., a protocol buffer configured to encapsulate another protocol buffer). That is, the system can encode a protocol buffer into another protocol buffer that is configured to generally define other protocol buffers.

[0032] At 430, a system or remote entity can transform an intermediate representation into another intermediate representation. In some examples, the system utilizes configuration rather than code (i.e., data-driven rather than language-specific encoding) to perform the transformation. The transformed intermediate representation can be mediated (e.g., a routing service) and optimally inspected or filtered during the transition. At 440, a remote entity can transform the transformed intermediate representation back into a binary protocol buffer (i.e., a non-self-describing protocol buffer) before it is transmitted to its final destination. When the system receives the protocol buffer's response, these steps can be reversed to inform any top-level service of the result of any underlying operation.

[0033] Therefore, system 100 can represent a protocol buffer within a protocol buffer. This allows the system to create and transmit ad-hoc protocol buffers, as well as manipulate and / or transform protocol buffers, via a common interface. The system also allows for manipulation and / or transformation of protocol buffers during flight (e.g., while traveling from a source to a destination).

[0034] Figure 5 This is a flowchart illustrating an exemplary arrangement of operations for a method 500 for generally storing serialized structured data in a standardized serialized data structure. In operation 502, method 500 includes obtaining structured data 110 on data processing hardware 12. The structured data 110 includes one or more field pairs 112. Each field pair 112 includes a corresponding field identifier 114 and a field value 116 associated with the corresponding field identifier 114. In some examples, each field identifier 114 includes a length-delimited variable-length integer. Each field value 116 may include at least one variable-length integer. Variable-length integers allow the system to efficiently encode the field identifier 114 and / or the field value 116 when serializing the data 110, 210.

[0035] In step 504, method 500 includes encoding the structured data 110 into serialized self-describing data 160 by the data processing hardware 12. The serialized self-describing data 160 includes one or more self-describing data portions 161, each representing a corresponding field pair in one or more field pairs 112. Each of the one or more self-describing portions 161 includes a first bit string 162 representing a corresponding field identifier 114 and a second bit string 164 representing a field value 116 associated with the corresponding field identifier 114. In step 506, method 500 includes transmitting the serialized self-describing data 160 to the remote entity 30 by the data processing hardware 12.

[0036] Figure 6 This is a schematic diagram of an example computing device 600 that can be used to implement the systems and methods described in this document. The computing device 600 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the inventions described and / or claimed in this document.

[0037] Computing device 600 includes: a processor 610 (e.g., data processing hardware), a memory 620, a storage device 630, a high-speed interface / controller 640 connected to the memory 620 and a high-speed expansion port 650, and a low-speed interface / controller 660 connected to a low-speed bus 670 and the storage device 630. Each component 610, 620, 630, 640, 650, and 660 is interconnected using different buses, and each component can be mounted on a common motherboard or otherwise installed as needed. The processor 610 can process instructions that execute within the computing device 600, including instructions stored in the memory 620 or the storage device 630 to display graphical information of a graphical user interface (GUI) on an external input / output device, such as a display 680 coupled to the high-speed interface 640. In other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple types of memory, if desired. Similarly, multiple computing devices 600 can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).

[0038] Memory 620 stores information non-temporarily within computing device 600. Memory 620 may be a computer-readable medium, volatile memory cells(s), or non-volatile memory cells(s). Non-volatile memory 620 may be a physical device for storing programs (e.g., instruction sequences) or data (program state information) used by computing device 600 on a temporary or permanent basis. Examples of non-volatile memory include, but are not limited to: flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electrically erasable programmable read-only memory (EEPROM) (e.g., commonly used for firmware such as bootloaders). Examples of volatile memory include, but are not limited to: random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase-change memory (PCM), and optical discs or magnetic tapes.

[0039] Storage device 630 provides massive storage for computing device 600. In some embodiments, storage device 630 is a computer-readable medium. In various embodiments, storage device 630 may be a floppy disk device, hard disk device, optical disk device, magnetic tape device, flash memory or other similar solid-state storage device, or device array, including devices in a storage area network or other configuration. In additional embodiments, the computer program product is tangibly embodied as an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer-readable or machine-readable medium, such as memory 620, storage device 630, or memory on processor 610.

[0040] High-speed controller 640 manages bandwidth-intensive operations of computing device 600, while low-speed controller 660 manages lower bandwidth-intensive operations. This functional allocation is merely exemplary. In some embodiments, high-speed controller 640 is coupled to memory 620, display 680 (e.g., via a graphics processor or accelerator) is coupled to high-speed expansion port 650, which can accept various expansion cards (not shown). In some embodiments, low-speed controller 660 is coupled to storage device 630 and low-speed expansion port 690. Low-speed expansion port 690 may include various communication ports (e.g., USB, Bluetooth, Ethernet, and wireless Ethernet) and may be coupled to one or more input / output devices, such as keyboards, pointing devices, scanners, or network devices such as switches or routers, for example, via a network adapter.

[0041] As shown in the figure, the computing device 600 can be implemented in various forms. For example, it can be implemented as a standard server 600a, or multiple times in a group of such servers 600a, or as a laptop computer 600b, or as part of a rack server system 600c.

[0042] Various implementations of the systems and techniques described herein can be implemented in digital electronic circuit systems and / or optical circuit systems, integrated circuit systems, application-specific integrated circuits (ASICs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be dedicated or general-purpose, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transferring data and instructions to the storage system, the at least one input device, and the at least one output device.

[0043] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to any computer program product, non-transitory computer-readable medium, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term “machine-readable signal” refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0044] The processes and logic flows described herein can be executed by one or more programmable processors, which execute one or more computer programs to perform functions by manipulating input data and generating output. Processes and logic flows can also be executed by special-purpose logic circuits such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). Processors suitable for executing computer programs include, for example, general-purpose microprocessors, special-purpose microprocessors, and any type of digital computer processor. Generally, the processor receives instructions and data from read-only memory or random access memory, or both. Essential components of a computer are: a processor for executing instructions, and one or more memory devices for storing instructions and data. Generally, a computer will also include one or more mass storage devices for storing data, or the computer may be operatively coupled to receive data from or transfer data to or both of these mass storage devices, such as magnetic disks, magneto-optical disks, or optical disks. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, including, for example, semiconductor storage devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by or incorporated into a dedicated logic circuit system.

[0045] To provide interaction with a user, one or more aspects of this disclosure can be implemented on a computer having: a display device for displaying information to the user, such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, or a touchscreen, and optionally including a keyboard and pointing device (e.g., a mouse or trackball), through which the user provides input to the computer. Other types of devices can be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including sound input, voice input, or tactile input. Additionally, the computer can interact by sending documents to and receiving documents from the device used by the user, for example, by sending a webpage to a web browser on the user's client device in response to a request received from a web browser.

[0046] Several embodiments have been described. However, it is understood that various modifications can be made without departing from the spirit and scope of this disclosure. Therefore, other embodiments are within the scope of the appended claims.

Claims

1. A computer-implemented method (500), characterized in that, When executed on the data processing hardware (12), the data processing hardware (12) is caused to perform operations, the operations including: Get the data specification (220) of the field pair (112) of the specified serialized non-self-describing data (210); Receive the serialized non-self-describing data (210); and Using the data specification (220), the serialized non-self-describing data (210) is encoded into structured data (110); the structured data (110) includes one or more field pairs (112), each field pair (112) including a corresponding field identifier (114) and a field value (116) associated with the corresponding field identifier (114); The structured data (110) is encoded and converted into serialized self-describing data (160), the serialized self-describing data (160) comprising one or more self-describing data portions (161), each of the self-describing data portions (161) representing a corresponding field pair in the one or more field pairs (112), each of the one or more self-describing portions (161) comprising: The first string (162) represents the corresponding field identifier (114); and The second bit string (164) represents the field value (116) associated with the corresponding field identifier (114); and The serialized self-description data (160) is sent to the remote entity (30).

2. The method (500) according to claim 1, characterized in that, Send the serialized self-describing data (160) to the remote entity (30), such that the remote entity (30): Based on each of the one or more self-describing data portions (161), a routing path (310) is determined, wherein each of the one or more self-describing data portions (161) represents a corresponding field pair in the one or more field pairs (112) of the structured data (110); The serialized self-describing data (160) is encoded and converted into the serialized non-self-describing data (210); and The serialized non-self-describing data (210) is sent based on the determined routing path (310).

3. The method (500) according to claim 1 or 2, characterized in that, Send the serialized self-describing data (160) to the remote entity (30), such that the remote entity (30): Based on each of the one or more self-describing data portions (161), the serialized self-describing data (160) is transformed, each of the one or more self-describing data portions (161) representing a corresponding field pair in the one or more field pairs (112) of the structured data (110); The converted serialized self-describing data (160) is encoded into new serialized non-self-describing data (210); and The new serialized non-self-describing data (210) is sent to the second remote entity (30).

4. The method (500) according to claim 3, characterized in that, The serialized non-self-describing data (210) includes a protocol buffer.

5. The method (500) according to claim 4, characterized in that, The serialization of self-describing data (160) includes encoding the non-self-describing data into a protocol buffer and converting it into another protocol buffer.

6. The method (500) according to claim 5, characterized in that, The field identifier (114) in each of the one or more field pairs (112) includes a length-bound variable-length integer.

7. The method (500) according to claim 6, characterized in that, The field value (116) in each of the one or more field pairs (112) includes at least one variable-length integer.

8. The method (500) according to claim 7, characterized in that, Encoding the structured data (110) into serialized self-describing data (160) includes, for each pair of fields (112), selecting a field type that represents the corresponding field value (116).

9. The method (500) according to claim 8, characterized in that, The field type includes one of the following: 32-bit integer, 64-bit integer, boolean, or string.

10. The method (500) according to claim 9, characterized in that, The serialized self-describing data (160) also includes metadata (230).

11. The method (500) according to claim 10, characterized in that, The metadata (230) includes a checksum that verifies the integrity of the serialized self-describing data (160).

12. A system (100), characterized in that, include: Data processing hardware (12); and Storage hardware (14) communicating with the data processing hardware (12), the storage hardware (14) storing instructions that, when executed on the data processing hardware (12), cause the data processing hardware (12) to perform the following operations: Get the data specification (220) of the field pair (112) of the specified serialized non-self-describing data (210); Receive the serialized non-self-describing data (210); as well as The serialized non-self-describing data (210) is encoded into structured data (110) using the data specification (220); the structured data (110) includes one or more field pairs (112), each field pair (112) including a corresponding field identifier (114) and a field value (116) associated with the corresponding field identifier (114); The structured data (110) is encoded and converted into serialized self-describing data (160), the serialized self-describing data (160) comprising one or more self-describing data portions (161), each of the self-describing data portions (161) representing a corresponding field pair in the one or more field pairs (112), each of the one or more self-describing portions (161) comprising: The first string (162) represents the corresponding field identifier (114); and The second bit string (164) represents the field value (116) associated with the corresponding field identifier (114); and The serialized self-description data (160) is sent to the remote entity (30).

13. The system (100) according to claim 12, characterized in that, Sending the serialized self-describing data (160) to the remote entity (30) causes the remote entity (30) to: A routing path (310) is determined based on each of the one or more self-describing data portions (161), each of the one or more self-describing data portions (161) representing a corresponding field pair in the one or more field pairs (112) of the structured data (110); The serialized self-describing data (160) is encoded and converted into the serialized non-self-describing data (210); and The serialized non-self-describing data (210) is sent based on the determined routing path (310).

14. The system (100) according to claim 12 or 13, characterized in that, Sending the serialized self-describing data (160) to the remote entity (30) causes the remote entity (30) to: The serialized self-describing data (160) is transformed based on each of the one or more self-describing data portions (161), each of the one or more self-describing data portions (161) representing a corresponding field pair in the one or more field pairs (112) of the structured data (110); The converted serialized self-describing data (160) is encoded into new serialized non-self-describing data (210); and The new serialized non-self-describing data (210) is sent to the second remote entity (30).

15. The system (100) according to claim 14, characterized in that, The serialized non-self-describing data (210) includes a protocol buffer.

16. The system (100) according to claim 15, characterized in that, The serialization of self-describing data (160) includes encoding the non-self-describing data into a protocol buffer and converting it into another protocol buffer.

17. The system (100) according to claim 16, characterized in that, The field identifier (114) in each of the one or more field pairs (112) includes a length-bound variable-length integer.

18. The system (100) according to claim 17, characterized in that, The field value (116) in each of the one or more field pairs (112) includes at least one variable-length integer.

19. The system (100) according to claim 18, characterized in that, Encoding the structured data (110) into serialized self-describing data (160) includes, for each pair of fields (112), selecting a field type that represents the corresponding field value (116).

20. The system (100) according to claim 19, characterized in that, The field type includes one of the following: 32-bit integer, 64-bit integer, boolean, or string.

21. The system (100) according to claim 20, characterized in that, The serialized self-describing data (160) also includes metadata (230).

22. The system (100) according to claim 21, characterized in that, The metadata (230) includes a checksum that verifies the integrity of the serialized self-describing data (160).

Images