US20050216896A1 - Data communication via tanslation map exchange - Google Patents
Data communication via tanslation map exchange Download PDFInfo
- Publication number
- US20050216896A1 US20050216896A1 US10/809,963 US80996304A US2005216896A1 US 20050216896 A1 US20050216896 A1 US 20050216896A1 US 80996304 A US80996304 A US 80996304A US 2005216896 A1 US2005216896 A1 US 2005216896A1
- Authority
- US
- United States
- Prior art keywords
- component
- data structure
- structure format
- native
- data
- 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.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
Definitions
- Inter-operability and the ability to communicate between legacy and newer versions of software applications are required in many systems.
- many redundant systems require consistency between active system data and standby (or “redundant”) system data, although the standby system may be populated with an older or newer version of the software in the active system.
- employing different software versions or applications within a system or network invariably leads to inconsistencies.
- newer software versions may contain data structures that do not exist in older software versions.
- data structures that exist in both new and old software versions may contain different variables or fields. Properties of variables in data structures appearing in different software versions may also vary therebetween. Similar inconsistencies can also exist between data structures of different applications between which communication is desired.
- FIG. 1 is a schematic view of one embodiment of a processing system according to aspects of the present disclosure.
- FIG. 2 is a flow-chart representing one embodiment of an initialization method according to aspects of the present disclosure.
- FIG. 3 is a flow-chart representing one embodiment of a method for encoding and decoding messages according to aspects of the present disclosure.
- FIG. 4 is a block diagram of one embodiment of at least a portion of a database that may be generated by a component of the system shown in FIG. 1 .
- FIG. 5 is a block diagram of another embodiment of at least a portion of a database that may be generated by a component of the system shown in FIG. 1 .
- FIG. 6 is a block diagram of one embodiment of at least a portion of a map that may be exchanged between components of the system shown in FIG. 1 .
- FIG. 7 is a block diagram of another embodiment of at least a portion of a map that may be exchanged between components of the system shown in FIG. 1 .
- the present disclosure relates generally to electronic data sharing and, more specifically, to data communication between first and second applications having different native data structure formats.
- the system 100 includes a component 110 operable to process data 115 having a native data structure format (NDSF).
- the system 100 also includes a second component 120 configured for processing data 125 having an NDSF that is different from the NDSF of the component 110 .
- the system 100 may also include components in addition to the components 110 , 120 , and these additional components may also be operable to communicate with the components 110 and/or 120 , and may each have an NDSF that is similar to or different from the NDSF of the components 110 , 120 .
- NDSF data 115 contemplates data arranged according to the NDSF of the component 110
- NDSF data 125 contemplates data arranged according to the NDSF of the component 120 . Similar convention may also be employed herein with subsequently introduced NDSFs.
- the component 110 is configured at least to transmit NDSF data 115 , if not also data in other formats, to the component 120 .
- the component 120 is configured at least to perform functions employing NDSF data 125 translated from NDSF data 115 and received from the component 110 .
- the components 110 , 120 may be or comprise primary and redundant components, or active and standby components, within a common system.
- the components 110 , 120 may be integral to or comprise primary and back-up servers employed with or in a networking switch.
- the components 110 , 120 may also comprise different applications within a common system.
- the component 110 may be integral to or comprise Microsoft WINDOWS (a product of Microsoft Corp.
- the component 120 may be integral to or comprise TURBO-TAX (a product of Intuit, Inc. of Mountain View, Calif.).
- the components 110 , 120 need not be located in a common node of a system.
- the components 110 , 120 may be integral to or comprise different nodes of a network.
- the NDSF data 115 and the NDSF data 125 have different data structure formats.
- the NDSF data 115 may include six concatenated variables 115 a - f having bit lengths of 6, 2, 6, 2, 2, 2, respectively, and the NDSF data 125 may include five concatenated variables 125 a - e having bit lengths of 6, 3, 4, 2, 2, respectively.
- the component 110 may perform functions with six variables, whereas the component 120 may perform related functions with five variables, and the NDSF data 115 variables and NDSF data 125 variables may have different sequences and lengths.
- the present disclosure does not limit the size, type, or arrangement of bits or variables within a data structure or bundle native to the components 110 , 120 .
- the data types of the variables 115 a - f and/or 125 a - e may be long integers, short integers, floating point numbers, characters, words, strings, concatenations, arrays, signed or unsigned, Boolean, and/or other types.
- the component 110 may bundle NDSF data 115 for transmission to the component 120 , such that the component 120 may perform functions or operations with the data. However, because the NDSF data 115 is different from the NDSF data 125 , the NDSF data 115 is translated into NDSF data 125 . Although this translation may be performed by either of the components 110 , 120 , or a third component (not shown), in this example the component 120 performs the task of translation.
- the component 110 may transmit a translation map 150 to the component 120 with or after the transmission of the NDSF data 115 .
- the component 110 may repeatedly send the map 150 to the component 120 prior to sending each individual NDSF data 115 message or a group thereof.
- the component 110 may also send the map 150 to the component 120 prior to sending any NDSF data 115 to the component 120 , such that the component 120 may then store the map 150 for use each time NDSF data 115 is subsequently received from the component 110 .
- the component 110 may send the map 150 to the component 120 substantially immediately after establishing a communication link with the component 110 , such that the map 150 may be stored for use in subsequent translations of received NDSF data 115 until the communication link is broken, or even thereafter.
- the component 120 may also send a map 160 to the component 110 after the communication link is established, such that the component 110 may store the map 160 for use in subsequent translations of received NDSF data 125 .
- the components 110 , 120 may also exchange more translation maps of other components if the components 110 , 120 are operable to send and process data in more than one NDSF.
- Each map 150 , 160 may also include translation information for more than one NDSF.
- the component 120 may reference the map 150 (possibly in conjunction with the internal map 160 ) to translate the NDSF data 115 into NDSF data 125 for subsequent operations therewith.
- the component 120 employs five variables during a data processing operation but receives six variables in the NDSF data 115 from the component 110 .
- information in the maps 150 , 160 indicates to the component 120 that the first variable 125 a that the component 120 needs to find in the NDSF data 115 corresponds to the variable 115 a .
- the component 120 may store the value of the variable 115 a for the variable 125 a .
- the maps 150 , 160 may also indicate that the variable 125 b corresponds to the variable 115 c . However, the variable 115 c comprises six bits, whereas the variable 125 b requires only three bits. Thus, the maps 150 , 160 may also indicate which of the six bits in the variable 115 c that the component 120 should store as the variable 125 b . For example, the maps 150 , 160 may indicate that the first three of the six bits in the variable 115 c should be stored for the variable 125 b , or that the last three of the six bits in the variable 115 c should be stored. Thus, the maps 150 , 160 may also indicate to the component 120 whether data is stored with the most-significant byte first or last, for example.
- the maps 150 , 160 may also indicate to the component 120 that the variables 115 e and 115 f correspond to the variables 125 d and 125 e , and that the remaining variables ( 115 b and 115 d ) in the NDSF data 115 do not correspond to any of the variables 125 a - e .
- the variables 115 b and 115 d may be disregarded or discarded.
- the maps 150 , 160 have not indicated to the component 120 what to store from the NDSF data 115 for the variable 125 c .
- the component 120 may call an initialization or other type of routine or function to populate the missing variable 125 c with data required for subsequent operations.
- the variables in the NDSF data 125 that do not correspond to variables in the NDSF data 115 may be populated with a default value, such as 0 or 1, which may be globally changed by a system or user.
- the component 120 may also include a user-interface by which a user may indicate a value to store or otherwise initialize these unpopulated variables, individually or by groups of variables. For example, the user may indicate that each unpopulated variable corresponding to a specific operation, application, function, class, object, or other common characteristic may have the same type and be populated with the same value.
- Each of the maps 150 , 160 include a global ID for each variable employed therein.
- the global IDs may comprise a concatenation or combination, or may otherwise be based on, one or more characteristics of the corresponding variable.
- each global ID may be based on the application from or for which a variable was created, the message or other data bundle in which the variable is transmitted, and an identification (name, number, etc.) of the variable within the message.
- object-oriented programming OOP
- OOP object-oriented programming
- the global ID for the variable 115 e may be “C1.M4.P5,” wherein “C1” may indicate that the variable 115 e was originated or is employed in a particular class or component (such as component 110 ), “M4” may indicate the particular message or construct in which the variable is being transmitted, and “P5” may indicate the position of variable 115 e within the message “M4.”
- the components 110 , 120 may exchange maps 150 , 160 upon the establishment of a communication link.
- the maps 150 , 160 may be employed to compare the global IDs of the variables 115 a - f and the variables 125 a - e to determine how to populate the variables 125 a - e with data transmitted by the variables 115 a - f , default values, initialization values, or user-input values.
- Each of the global IDs may also carry a descriptor of the corresponding variable.
- the descriptor may indicate that the variable type is long integer, short integer, floating point, character, word, string, concatenation, array, signed or unsigned, Boolean, and/or other types.
- the descriptor may also indicate the length of the variable.
- an aspect of one embodiment of system 100 entails giving each variable a global ID and associating with this ID one or more dynamic parameters that describe the variable type and length in the component 110 , 120 to which it belongs.
- the global IDs and descriptors in the NDSF data 115 , 125 and the maps 150 , 160 may be static once a load is created, or once a communication link between the components 110 , 120 is established.
- the component 120 can employ the maps 150 , 160 to understand how the component 110 encodes the NDSF data 115 and, consequently, translate the NDSF data 115 into NDSF data 125 for subsequent operations.
- object-oriented programming may be employed to implement the system 100 and/or one or more of the components 110 , 120 . Since some embodiments described herein do not distinguish between class and structure, the construct concept is used from this point forward, and it is meant to indicate either a class or structure.
- constructs struct myData ⁇ int w; int x; ⁇ ; struct myRoot ⁇ int xx; struct myData y; ⁇ z; the redundancy variable x belongs to myData, and myData is included in myRoot. Either may change in size, and the variable x may also change location within myData.
- the variable x may also change property or storage format (e.g., most-significant byte first or last, character or integer, signed or unsigned, etc.) while serving the same function within myData and myRoot. These changes may affect the storage location for the variable x value within the constructs. However, once the constructs are defined, the offset location may remain fixed in the construct in which the data originates. Objectives for a receiving component, such as the component 120 in FIG. 1 , include: (1) correctly locating variable x; (2) obtaining the assigned value for variable x; and then (3) passing the value to a variable serving the same purpose in its own native structure. Locating the variable x may be handled by employing a global ID that ties the variable x in a sending component, such as component 110 in FIG.
- a global ID that ties the variable x in a sending component, such as component 110 in FIG.
- Additional information can be attached to the global ID that specifies the encoding attribute of the variable (such as size, offset, repeatability, etc.) in the sending and receiving components. These additional attributes may allow a receiving component to locate the variable x in the message text, and to correctly transfer the information to an equivalent native variable.
- variable ID, type, offset, length, and value from the encoding system may be communicated to a receiving component.
- the global ID and the encoding attributes assigned to the variable may be arranged into a structure which may be known as a translation map element.
- the collection of the translation map elements may be referred to as a translation map, such as the maps 150 , 160 .
- variable definitions and/or other information contained in the maps 150 , 160 may be exchanged only once at the start of a communication cycle. That is, the information exchanged in the maps 150 , 160 may be saved internally by each component 110 , 120 and consulted when new data is received.
- the system 100 may also include tags to assist the component 120 with decoding the data received from the component 110 , such as by pointing the component 120 to the definition of the variables 125 a - e .
- each tag is a combination of a global class number and a local class construct number.
- a class number may be a unique number given to a class when the class is added to a system, such as during coding time.
- the construct number is internal to the class and is assigned when new structures are added to the class (1, 2, 3, etc.).
- the receiving component is able to locate the class and the construct descriptors specific to the messages in the descriptors provided in the maps 150 , 160 .
- the construct definitions for the corresponding variables e.g., global IDs, types, offsets, and/or lengths
- the receiving component can then search the local descriptors for the same tag. If a local construct description is found, each variable's global ID can be matched to one of the received variable's global ID. If a match is found, the value of the received field can be copied into the local variables.
- All variables that did not have a match to any of the received variables may be processed afterwards, as this implies that they are newly defined or no longer supported. If these undefined variables did not specify default-initializers, they may be set to zero. Otherwise, the initializers may be called. This decoding operation can be highly recursive, because structures tend to include other structures. Once the conversion is complete, the newly formed message can be passed to a unique class registered function to process the contents.
- Macros and/or other coding techniques may be employed to define the description of each variable within each construct. For example, all global IDs may be assigned in a single file using one or more macros. Such macros may use the structure name as a parameter and concatenate additional characters to provide global references. The following macros may be employed in at least one embodiment within the scope of the present disclosure.
- the macro The macro:
- the macro The macro:
- the macro The macro:
- the macro The macro:
- the macro The macro:
- the macro The macro:
- the macro The macro:
- the macro #define element( name, variable, type, callback) ⁇ COMPONENT::describRedElement( ⁇ COMPONENT::RType_##type, ⁇ offset(name,variable), ⁇ name::LVN_##variable, ⁇ sizeof(RStorage_##type), ⁇ 1,callback) defines storage for “variable” of type “type” in construct “name” with convert function “callback”. Default conversion for these variables follows the standard conversion types (e.g., short to long or long to short).
- the macro #define elementStruct( name, variable, callback) ⁇ COMPONENT::describRedElement( ⁇ COMPONENT::RedObject_sequenced, ⁇ offset(name,variable), ⁇ name::LVN_##variable, ⁇ rsize(name,variable), ⁇ 1,callback) defines storage for “variable” of type structure in construct “name” with convert function “callback”. This call is used to define elements that need to remain intact and to be treated as a sequence of memory locations. Default conversion for these variables include right-most truncation or padding with zeros.
- the macro #define elementArray( name, variable, type, repeat, callback) ⁇ COMPONENT::describRedElement ( ⁇ COMPONENT::RType_##type, ⁇ offset(name,variable), ⁇ name::LVN_##variable, ⁇ sizeof(RStorage##type), ⁇ repeat,callback)
- This macro defines storage for “variable” of type array in construct “name” of type “type” with an array bound of “repeat” and default conversion “callback”.
- This macro is used to define an array element of standard type (char, short, long, uchar, ushort, etc.). Default conversion is applied to each element of the array, array size may be truncated, or larger arrays may be filled with zeros for the additional array elements.
- the macro The macro:
- This macro defines storage for “variable” as an array of structures in construct “name” with an array bound of “repeat” and default conversion “callback”.
- This macro is used to define an array element of non-standard type (memory area). Default conversion is applied to each element of the array (each element may be padded with zeros or truncated from the right), array size may be truncated, or larger arrays may be filled with zeros for the additional array elements.
- the macro #define construct( owner, vclass, vstrct, variable) ⁇ COMPONENT::describRedConstruct( ⁇ ClassEnum(vclass), ⁇ vclass::StrctNum_##vstrct, ⁇ owner::LVN_##variable, ⁇ offset(owner,variable),1 ) defines storage for “variable” as defined in “owner by a previously defined construct with global ID of ⁇ vclass> ⁇ vstruct>.
- the macro #define constructArray( owner, vclass, vstruct, variable, repeat ) ⁇ COMPONENT::describRedConstruct( ⁇ ClassEnum(vclass), ⁇ vclass::StrctNum_##vstruct, ⁇ owner::LVN_##variable, ⁇ offset(owner,variable), repeat ) defines storage for “variable” as an array of size “repeat” in “owner”.
- Each array element is defined by a previously defined construct with global ID ⁇ vclass> ⁇ vstruct>.
- control_type ⁇ COMPONENT::describRedControl ( ⁇ name::LVN_##controler, ⁇ name::LVN_##controled, ⁇ control_type ) defines a relation ship between two variables with in a construct “name”.
- the controller controls the “control_type” aspect of the “controlled” variable.
- the macro #define redClass( rclass, callback ) ⁇ COMPONENT::defineRedClassDesc( ⁇ ClassEnum(rclass), callback ) defines a function to call when construct “rclass” message is received and converted.
- implementation may be split into imbedded code in each class that is employed in the system (“imbedded code”) and generic code.
- imbedded code imbedded code
- System A is a newer system that has evolved and has redefined some of its variables to accommodate additional requirements. This evolution caused the structures in System A to change in size and element count. Consequently, after taking System A offline to accomplish this update, System A needs to be brought online with the data from system B, which is still operating online. System B has been online or in the field for some time, and includes the original structures requiring updating. System B may also be considered a legacy component, such that System A may comprise an upgrade to the legacy component.
- Systems A and B may be analogous to components 110 and 120 , respectively, in the system 100 of FIG. 1 .
- Each class that belongs to Systems A or B has a class number that is globally defined. This class number may not be reused by other classes or changed by this class.
- the class defines an initializing method that may be called to get the constructs the class wishes to use.
- the next method that each class may have is a function that processes the construct received on its behalf. This function may be registered when the class descriptor is instantiated. The data received by this function should have been already in the correct position according to the defined local constructs.
- a “controlling” variable is a variable that controls some aspect of other “controlled” variables.
- the controlling variable may specify the number of elements in an array that are passed in a message. Consequently, a construct may be defined with the maximum number of allowed records but may only populate one or more.
- the Systems A and B need to know this information to encode outgoing messages and, for incoming messages, to locate the control field and extract its value before encountering the controlled variable.
- the generic code can be categorized into three sections: translation map database, initialization, and operation.
- the initialization section is involved at the start-up of a system and when a communication link is established with another system.
- the translation map database refers to the data that has to be saved by a system to allow a system to translate between local and remote message structures.
- the operation section is involved in encoding and decoding messages traveling between the application and communication layers of a system.
- the translation map database consists of translation map elements that are linked together to form one or more tables or arrays.
- the tables/arrays may be indexed by the global ID of the elements. For example, in each system, a local table containing local or native descriptors may be created, as well as one or more remote tables containing remote descriptors native to other system(s).
- the descriptor header may be: typedef struct ⁇ // total 4 bytes header...
- the size of the descriptor header may be kept at thirty-two bits to minimize memory usage.
- the descriptor Version is used to specify the version of the descriptor. As stated before, these descriptors should rarely change, such that a range of 0-15 may be sufficient, but not mandatory.
- the descriptor length specifies the descriptor size in words.
- the descriptor type specifies the type of the descriptor as either a class, a construct or a variable.
- the version states the version of element using this descriptor. Each class and each construct may set the version value independently. Variables may not have a version.
- the reference number is the global ID assigned to variable using this descriptor.
- the class descriptor may be: typedef struct ⁇ RedDescHdr mHdr; ulong mConstCount; // total number of constructs assigned // by this class.. // private Additional data for house keeping ⁇ RedClassElm;
- This descriptor is defined once per class, and contains the total number of internal/local constructs defined by this class. In a house keeping section which may be private to each system, a link to each construct is saved. Since all constructs may be defined at initialization, the constructs can be allocated sequentially. In one embodiment, a single reference may be kept for each construct, the cumulative references thereafter accessible as elements in an array. Other variables are saved in the private data that are used for optimization, statistics, and other functions.
- the construct descriptor may be: typedef struct ⁇ RedDescHdr mHdr; ulong mVarCount; // total number of Variables assigned // by this construct.. // Additional data for house keeping ⁇ RedConstElm;
- This descriptor may be defined once per class construct, and may contain the total number of variables defined by the construct.
- a link to each variable descriptor may be saved in the housekeeping section. Since all variables in a construct may be defined sequentially at initialization, the variable descriptors may be allocated sequentially. In one embodiment, a single reference may be kept for each variable, the cumulative references thereafter accessible as elements in an array. Other variables may be saved in the private data that are used for optimization, statistics and other functions.
- variable descriptors may be: typedef struct ⁇ RedDescHdr mHdr; ulong mObjectType:4, // signed/unsigned struct ..etc mControlType:4, // control type (on-off, arry index, .. mSpare:8, // not used..
- This descriptor may be defined once per variable in a construct, and may contain description of the variable as defined by the owning system.
- the object type refers to the type of variable this descriptor is trying to describe.
- Valid types include signed, unsigned, sequenced, or RedConstruct. Signed and unsigned have the normal standard meaning (truncation and padding is done on the left, and the sign bit must remain intact). Sequenced variables may be considered raw memory, and may be truncated from the right or padded on the right with zeros. No meaning may be attached to sequenced variables. RedConstruct variables refer to a predefined construct, and a system should search the table for their definition.
- Control reference may be set to zero unless this variable is controlled by another variable in the same construct, in which case the control reference may refer to the variable reference number.
- the array count is set to how many times this variable repeats, such as being set to one.
- Two 16-bit data values may also be saved with this descriptor to be used depending on the descriptor type.
- additional storage may be used to keep track of variable correlation between the local system descriptors and the remote system descriptors.
- the storage may be used for optimization.
- the local system may initialize an internal local system table that holds the description of all pertinent variables, as well as a remote system table. However, a remote system table within the local system may remain empty as long as a communication link with a remote system is down.
- the descriptions of the variables may be obtained by calling all classes' describeRedConstructs( ) method. This method makes repeated calls to define the local constructs and the variables within these constructs, such as with the function implementation above.
- the method may include a step 210 in which construct variables are individually defined until each variable within the construct is defined, as determined by a decisional step 215 .
- a decisional step 220 may be repeated for each individual local construct until each construct is defined, as determined by a decisional step 220 .
- Each call may thus add an element to the local system table.
- the local system When the communication link is established with the remote system, the local system sends its internal descriptors to the remote system in a step 230 .
- the local system may also expect the remote system to send its own definitions in a step 235 .
- the message is parsed according to the system internal structure and the definitions are saved into the remote system link list and/or inserted into the remote system table in a step 240 .
- the definitions may be sent such that each message contains an integral number of class-constructs. That is, in one embodiment, no partial constructs may be sent in any message.
- the initialization method may then hibernate in a step 250 .
- the initialization stage may be reactivated if the communication link between the two systems is lost, which is depicted as a step 255 in the method 200 , although this is more of an occurrence than a process step to be executed by the method.
- the remote system table may be cleared in a step 260 , and the process of establishing the communication link and exchanging descriptors may be repeated.
- Messages received before substantially completed reception of the remote system descriptors may be ignored. Moreover, messages may not be allowed to leave a system before a communication link is established between the local system and one or all remote systems with which the local system may potentially communicate.
- the remote system descriptors may be correlated to the local system descriptors, such that the local system can determine if a received variable has a corresponding local definition. If the remote descriptor has no correlating local variable descriptor, it is marked as such. If the remote construct descriptor is found to be identical to the local construct descriptor, the construct is marked identical, and when such construct is received it is passed as-is to the application.
- the method 200 may not include each step illustrated in FIG. 2 , may include steps in addition to those illustrated, and may perform the illustrated and other steps in sequences other than described above.
- descriptors may not be transmitted in both directions. That is, one of the systems may generate only the local descriptor table and not generate the remote descriptor table. Messages sent to such a system may require translation prior to transmission.
- the operation stage deals with the interface between the application and the system communication link, including message encoding and decoding.
- the application fills in the structure with the required data and calls system operation methods to send the data, as depicted in a step 305 of the method 300 .
- the operation section receives the data from the application and encodes the data according to the local system descriptors one variable at a time in a step 310 .
- system attaches a system tag to the message in a step 315 , and the message is sent to the remote system in a step 320 .
- the system tag allows the remote system to decode the message correctly.
- An exemplary structure for the system tag is: typedef struct ⁇ ushort mClassRef; ushort mConstRef; ⁇ RedDataSyncHdr;
- the class reference is the globally assigned class reference number (in the present example it is 23) and the construct reference number is the reference number of the construct within that class (in the present example it is 1). This information is sufficient to allow the remote system to locate the relevant description.
- the remote system receives the message in a step 325 and, using the system tag, locates the construct descriptor in the remote system table in a step 330 . If the construct descriptor cannot be located, as determined in a decisional step 335 , the message is ignored (step 340 ). With the construct descriptor in hand, the remote system attempts to locate the local description from the local system table in a step 345 . If a local descriptor is not found, as determined in a decisional step 350 , the message is ignored (step 340 ).
- the remote system moves the data from the message space into the local space one variable at a time in a step 355 .
- conversion, truncation, and padding of the variable value may take place.
- the local construct descriptor is scanned in a step 360 for any variable that has not been defined by the message source system. If an un-initialized variable is found, the variable descriptor is consulted for a default initializer. If an initializer is found, as determined in a decisional step 365 , the initializer function is called in a step 370 .
- the variable is initialized to zero or some other default value in a step 375 .
- the constructed buffer is sent to a processing function, such as the class registered processing function (processMsgFromActiveCpu( )), for content manipulation in a step 380 .
- the method 300 may not include each step illustrated in FIG. 3 , may include steps in addition to those illustrated, and may perform the illustrated and other steps in sequences other than described above.
- a system can be configured to keep data from several remote systems.
- all transmitted data may be relative to its own system definitions, such that the burden of conversion lies with the receiving system.
- the order of the variables is handled by matching the remote system variable to a variable in the local system.
- the value of the variable “w” (with ID of 23.1.3) may be set correctly from the received “w” (also with an ID of 23.1.3).
- the name change from “RedOldStuff” to “REDEnhancedOldStuf” may be correctly handled by the global ID (23.2), since both constructs have the same ID and the name is, therefore, irrelevant.
- Some embodiments of the present disclosure may be useful in removing the burden of keeping track of individual variables and structures, as well as assisting in the definition of standardized processes, methods, and systems for achieving less complicated addition and/or removal of variables between systems having different native data structure formats or that are otherwise incompatible.
- Some aspects of the present disclosure may also provide users the flexibility to include predefined structures within messages and the ability to change imbedded structures as such a need arises.
- Aspects of the present disclosure may also provide the ability to automatically reformat remote variables to match the format of local variables, such as between big Endian and little Endian formats, or among character, short, long, etc.
- automatic conversion routines may be provided internal to one or more components in a system or systems, which can enhance transparency and relieve users from such conversion tasks.
- System B is one that has been online or in the field for some time, and includes original structures requiring updating in response to the upgrade of System A.
- the database 400 includes a class definition array 410 , a construct definition array 420 , and a variable definition array 430 .
- the class definition array 410 includes an entry “ClassRefId” for the class_syncThis and having the value “23,” an associated “Construct_count” having the value “2,” and an associated “Construct_Refindex” having the value “962.”
- the “ClassRefId” is unique to the class.
- the “Construct_count” indicates the number of construct definitions in an instance of “ClassRefId.”
- the class_syncThis includes the constructs RedSyncThis and RedOldStuff.
- the “Construct_Refindex” indicates the location of the first construct definition in the construct definition array 420 .
- the construct RedSyncThis is element 962 in the construct definition array 420 , has an ID “ConstructRefId” of “1,” and includes four variables per the “Variable_count,” wherein the first variable is element 1234 in the variable definition array 430 , per the “Variable_Refindex.”
- the 4 variables in the RedSyncThis construct are “z,” “old,” “w,” and “stuff,” which agrees with the code described above.
- each of these variables may include or have associated therewith a “VariableRefId” indicating the variable's position within the construct, a “VariableSize” indicating the length of the variable, a “VariableRepeat” indicating the number of times the variable is to be repeated within the construct, and a “VariableType” indicating the type of the variable.
- Each variable definition may also include one or more pointers to locations in which other data is stored, as indicated by the “VarData1” and “VarData2” also illustrated in FIG. 4 .
- FIG. 5 illustrated is a block diagram of a portion of one embodiment of a database 500 for System A, continuing with the above example.
- System A is a newer system that has evolved and has redefined some of its variables to accommodate additional requirements.
- the database 500 includes a class definition array 510 , a construct definition array 520 , and a variable definition array 530 .
- the class definition array 510 includes an entry “ClassRefId” for the class_syncThis and having the value “23,” an associated “Construct_count” having the value “3,” and an associated “Construct_Refindex” having the value “980.”
- the class_syncThis includes the constructs RedSyncThis, RedEnhancedOldStuff (partially corresponding to the construct RedOldStuff in System B), and RedNewStuff.
- the construct RedSyncThis is element 980 in the construct definition array 520 , has an ID “ConstructRefId” of “1,” and includes five variables per the “Variable_count,” wherein the first variable is element 1543 in the variable definition array 530 , per the “Variable_Refindex.”
- the five variables in the RedSyncThis construct are “z,” “w,” “old,” “new,” and “stuff,” which also agrees with the code described above.
- each of these variables may have definitions similar to those in the variable definition array 430 , although they may not be in the same sequence. For example, the order of the variables “w” and “old” are different in the variable definition arrays 430 , 530 .
- the “VariableReFId” of these variables remains constant in the variable definition arrays 430 , 530 , and the additional variable “new” introduced by the upgraded System A has been assigned the next available “VariableRefId” (5).
- FIG. 6 illustrated is a block diagram of a portion of one embodiment of a descriptor message or map 600 that older System B may send to newer System A to assist System A with translation of messages received from System B.
- map 600 may include descriptors for multiple classes, only the descriptors for the class syncThis are shown in FIG. 6 .
- the map 600 includes a “ClassRefId” of 23 indicating that the immediately following information pertains to the class “syncThis.”
- the map 600 also includes a “Construct_count” of 2, indicating that “syncThis” includes two constructs.
- the first construct “RedSyncThis” has a “ConstructRefId” of 1, and includes four variables, per the “Variable_count”.
- the map 600 then lists the definitions for each of the variables “z,” “old,” “stuff,” and “w” included in the construct “RedSyncThis.”
- the second construct “RedOldStuff” has a “ConstructRefId” of 2, and includes two variables, per the “Variable_count.”
- the two variables in the construct “RedOldStuff” include “x” and “y[5],” which is an array of five elements.
- the map 600 then lists the definitions for “x” and “y[5],” and continues to the next class (having a “ClassRefId” of 26).
- System A may consult the map 600 to gather information pertaining to the format/structure of the class “syncThis,” the constructs “RedSyncThis” and “RedOldStuff,” and the variables “z,” “old,” “stuff,” “w,” “x,” and “y[5]” to process messages and/or data received from System B. Moreover, System B may continue to send such information in its native format, regardless of the format System A uses for native operations.
- FIG. 7 illustrated is a block diagram of a portion of one embodiment of a descriptor message or map 700 that System A may send to System B to assist System B with translation of messages received from System A.
- map 700 may include descriptors for multiple classes, only the descriptors for the class syncThis are shown in FIG. 7 .
- the map 700 includes a “ClassRefId” of 23 indicating that the immediately following information pertains to the class “syncThis.”
- the map 700 also includes a “Construct_count” of 3, indicating that “syncThis” includes three constructs.
- the first construct “RedSyncThis” has a “ConstructRefId” of 1, and includes five variables, per the “Variable_count”.
- the map 700 then lists the definitions for each of the variables “z,” “w,” “old,” “new,” and “stuff” included in the construct “RedSyncThis.”
- the second construct “RedEnhancedOldStuff” has a “ConstructRefId” of 2, and includes two variables, per the “Variable_count.”
- the two variables in the construct “RedEnhancedOldStuff” include “x” and “y[10],” which is an array often elements.
- the map 700 then lists the definitions for “x” and “y[10].”
- the third construct “RedNewStuff” has a “ConstructRefId” of 3, and includes two variables, per the “Variable_count.”
- the two variables in the construct “RedNewStuff” include “x” and “y.”
- the map 700 then lists the definitions for “x” and “y,” and continues to the next class (having a “ClassRefId” of 26).
- the variables “x” and “x” are similarly named.
- global IDs such as those based on the class number, the construct number within the class, and the variable number within the construct, the similar names may not be problematic.
- the global ID for the variable “x” in the construct “RedEnhanced OldStuff” may be 23.2.1
- the global ID for the variable “x” in the construct “RedNewStuff” may be 23.3.1.
- System B may consult the map 700 to gather information pertaining to the format/structure of the class “syncThis,” the constructs “RedSyncThis,” “redEnhancedOldStuff,” and “RedNewStuff,” and their variables to process messages and/or data received from System A. Moreover, System A may send such information in its native format, regardless of the format System B uses for native operations.
- the present disclosure introduces a method of exchanging data between first and second components having first and second native data structure formats, respectively.
- the method includes exchanging native data structure format information between the first and second components, generating data in the first native data structure format, and transmitting the generated data between the first and second components.
- the generated data is translated into the second native data structure format based on the exchanged native data structure format information.
- a processing system for exchanging messages between first and second components having first and second native message formats, respectively, is also introduced in the present disclosure.
- the processing system includes means for exchanging native data structure format information between the first and second components, means for generating data in the first native data structure format, and means for transmitting the generated data between the first and second components.
- Such an embodiment also includes means for translating the generated data into the second native data structure format based on the exchanged native data structure format information.
- the exchanging means, generating means, transmitting means, and translating means may be included in one or more processors or other components of a computer or network, such as the components 110 , 120 shown in FIG. 1 .
- the method of exchanging messages between first and second components having first and second native message formats, respectively may also be implemented or embodied in a program product according to aspects of the present disclosure.
- a program product may include means recorded on a computer-readable storage medium for exchanging native data structure format information between first and second components having first and second native message formats, respectively.
- the program product also includes means recorded on the medium for generating data in the first native data structure format, and means recorded on the medium for transmitting the generated data between the first and second components.
- Means also recorded on the medium are configured to translate the generated data into the second native data structure format based on the exchanged native data structure format information.
- the storage medium may be or comprise a magnetic recording medium, an optical recording medium, or a network distribution recording medium, such as may be employed to distribute the program product over (or “post”) a LAN, a WAN, the Internet, and/or other networks.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
- Inter-operability and the ability to communicate between legacy and newer versions of software applications are required in many systems. For example, many redundant systems require consistency between active system data and standby (or “redundant”) system data, although the standby system may be populated with an older or newer version of the software in the active system. However, employing different software versions or applications within a system or network invariably leads to inconsistencies. For example, newer software versions may contain data structures that do not exist in older software versions. Additionally, even data structures that exist in both new and old software versions may contain different variables or fields. Properties of variables in data structures appearing in different software versions may also vary therebetween. Similar inconsistencies can also exist between data structures of different applications between which communication is desired.
- At least in the case of upgrading legacy systems, such inconsistencies are often handled by patches or other types of special software having the operational behavior knowledge of the older system so that the revisions in the newer systems do not affect the older system. This is fairly easy to accomplish if the differences between the systems are small. However, as systems grow and additional features are added, the differences between legacy and upgraded systems become large and, in some cases, unmanageable.
- Aspects of the present disclosure are best understood from the following detailed description when read with the accompanying figures. It is emphasized that, in accordance with the standard practice in the industry, various features are not drawn to scale. In fact, the dimensions of the various features may be arbitrarily increased or reduced for clarity of discussion.
-
FIG. 1 is a schematic view of one embodiment of a processing system according to aspects of the present disclosure. -
FIG. 2 is a flow-chart representing one embodiment of an initialization method according to aspects of the present disclosure. -
FIG. 3 is a flow-chart representing one embodiment of a method for encoding and decoding messages according to aspects of the present disclosure. -
FIG. 4 is a block diagram of one embodiment of at least a portion of a database that may be generated by a component of the system shown inFIG. 1 . -
FIG. 5 is a block diagram of another embodiment of at least a portion of a database that may be generated by a component of the system shown inFIG. 1 . -
FIG. 6 is a block diagram of one embodiment of at least a portion of a map that may be exchanged between components of the system shown inFIG. 1 . -
FIG. 7 is a block diagram of another embodiment of at least a portion of a map that may be exchanged between components of the system shown inFIG. 1 . - The present disclosure relates generally to electronic data sharing and, more specifically, to data communication between first and second applications having different native data structure formats.
- It is to be understood that the following disclosure provides many different embodiments, or examples, for implementing different features of various embodiments. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting. In addition, the present disclosure may repeat reference numerals and/or letters in the various examples. This repetition is for the purpose of simplicity and clarity and does not in itself dictate a relationship between the various embodiments and/or configurations discussed.
- Referring to
FIG. 1 , illustrated is a schematic view of one embodiment of asystem 100. Thesystem 100 includes acomponent 110 operable to processdata 115 having a native data structure format (NDSF). Thesystem 100 also includes asecond component 120 configured forprocessing data 125 having an NDSF that is different from the NDSF of thecomponent 110. Thesystem 100 may also include components in addition to thecomponents components 110 and/or 120, and may each have an NDSF that is similar to or different from the NDSF of thecomponents - For the sake of simplicity, the convention “NDSF
data 115” employed herein contemplates data arranged according to the NDSF of thecomponent 110, and “NDSFdata 125” contemplates data arranged according to the NDSF of thecomponent 120. Similar convention may also be employed herein with subsequently introduced NDSFs. - The
component 110 is configured at least to transmit NDSFdata 115, if not also data in other formats, to thecomponent 120. Thecomponent 120 is configured at least to perform functions employing NDSFdata 125 translated from NDSFdata 115 and received from thecomponent 110. Thecomponents components components component 110 may be integral to or comprise Microsoft WINDOWS (a product of Microsoft Corp. of Redmond, Wash.) and thecomponent 120 may be integral to or comprise TURBO-TAX (a product of Intuit, Inc. of Mountain View, Calif.). Thecomponents components - The NDSF
data 115 and the NDSFdata 125 have different data structure formats. For example, the NDSFdata 115 may include six concatenatedvariables 115 a-f having bit lengths of 6, 2, 6, 2, 2, 2, respectively, and theNDSF data 125 may include five concatenatedvariables 125 a-e having bit lengths of 6, 3, 4, 2, 2, respectively. Thus, in the illustrated embodiment, thecomponent 110 may perform functions with six variables, whereas thecomponent 120 may perform related functions with five variables, and theNDSF data 115 variables andNDSF data 125 variables may have different sequences and lengths. - Of course, the present disclosure does not limit the size, type, or arrangement of bits or variables within a data structure or bundle native to the
components variables 115 a-f and/or 125 a-e may be long integers, short integers, floating point numbers, characters, words, strings, concatenations, arrays, signed or unsigned, Boolean, and/or other types. - In one embodiment, the
component 110 may bundle NDSFdata 115 for transmission to thecomponent 120, such that thecomponent 120 may perform functions or operations with the data. However, because the NDSFdata 115 is different from the NDSFdata 125, the NDSFdata 115 is translated into NDSFdata 125. Although this translation may be performed by either of thecomponents component 120 performs the task of translation. - To facilitate the translation, the
component 110 may transmit atranslation map 150 to thecomponent 120 with or after the transmission of theNDSF data 115. However, in one embodiment, thecomponent 110 may repeatedly send themap 150 to thecomponent 120 prior to sending eachindividual NDSF data 115 message or a group thereof. Thecomponent 110 may also send themap 150 to thecomponent 120 prior to sending anyNDSF data 115 to thecomponent 120, such that thecomponent 120 may then store themap 150 for use each time NDSFdata 115 is subsequently received from thecomponent 110. In one embodiment, thecomponent 110 may send themap 150 to thecomponent 120 substantially immediately after establishing a communication link with thecomponent 110, such that themap 150 may be stored for use in subsequent translations of received NDSFdata 115 until the communication link is broken, or even thereafter. In such an embodiment, thecomponent 120 may also send amap 160 to thecomponent 110 after the communication link is established, such that thecomponent 110 may store themap 160 for use in subsequent translations of received NDSFdata 125. Thecomponents components map - Upon receipt of NDSF
data 115, thecomponent 120 may reference the map 150 (possibly in conjunction with the internal map 160) to translate the NDSFdata 115 intoNDSF data 125 for subsequent operations therewith. For example, in the illustrated embodiment, thecomponent 120 employs five variables during a data processing operation but receives six variables in the NDSFdata 115 from thecomponent 110. Thus, information in themaps component 120 that thefirst variable 125 a that thecomponent 120 needs to find in theNDSF data 115 corresponds to thevariable 115 a. Thus, thecomponent 120 may store the value of thevariable 115 a for thevariable 125 a. Themaps variable 115 c. However, thevariable 115 c comprises six bits, whereas the variable 125 b requires only three bits. Thus, themaps variable 115 c that thecomponent 120 should store as the variable 125 b. For example, themaps maps component 120 whether data is stored with the most-significant byte first or last, for example. - Continuing with the illustrated embodiment, the
maps component 120 that thevariables variables NDSF data 115 do not correspond to any of thevariables 125 a-e. Thus, thevariables - However, the
maps component 120 what to store from theNDSF data 115 for the variable 125 c. Thus, thecomponent 120 may call an initialization or other type of routine or function to populate the missing variable 125 c with data required for subsequent operations. In one embodiment, the variables in theNDSF data 125 that do not correspond to variables in theNDSF data 115 may be populated with a default value, such as 0 or 1, which may be globally changed by a system or user. Thecomponent 120 may also include a user-interface by which a user may indicate a value to store or otherwise initialize these unpopulated variables, individually or by groups of variables. For example, the user may indicate that each unpopulated variable corresponding to a specific operation, application, function, class, object, or other common characteristic may have the same type and be populated with the same value. - Each of the
maps components - As described above, the
components maps component 110 transmitsNDSF data 115 to thecomponent 120, themaps variables 115 a-f and thevariables 125 a-e to determine how to populate thevariables 125 a-e with data transmitted by thevariables 115 a-f, default values, initialization values, or user-input values. - Each of the global IDs may also carry a descriptor of the corresponding variable. For example, the descriptor may indicate that the variable type is long integer, short integer, floating point, character, word, string, concatenation, array, signed or unsigned, Boolean, and/or other types. The descriptor may also indicate the length of the variable.
- Thus, an aspect of one embodiment of
system 100 entails giving each variable a global ID and associating with this ID one or more dynamic parameters that describe the variable type and length in thecomponent NDSF data maps components component 120 can employ themaps component 110 encodes theNDSF data 115 and, consequently, translate theNDSF data 115 intoNDSF data 125 for subsequent operations. - As described above, object-oriented programming may be employed to implement the
system 100 and/or one or more of thecomponents struct myData { int w; int x; }; struct myRoot { int xx; struct myData y; } z;
the redundancy variable x belongs to myData, and myData is included in myRoot. Either may change in size, and the variable x may also change location within myData. The variable x may also change property or storage format (e.g., most-significant byte first or last, character or integer, signed or unsigned, etc.) while serving the same function within myData and myRoot. These changes may affect the storage location for the variable x value within the constructs. However, once the constructs are defined, the offset location may remain fixed in the construct in which the data originates. Objectives for a receiving component, such as thecomponent 120 inFIG. 1 , include: (1) correctly locating variable x; (2) obtaining the assigned value for variable x; and then (3) passing the value to a variable serving the same purpose in its own native structure. Locating the variable x may be handled by employing a global ID that ties the variable x in a sending component, such ascomponent 110 inFIG. 1 , to a variable serving the same purpose in the receiving component. Additional information can be attached to the global ID that specifies the encoding attribute of the variable (such as size, offset, repeatability, etc.) in the sending and receiving components. These additional attributes may allow a receiving component to locate the variable x in the message text, and to correctly transfer the information to an equivalent native variable. - In this manner, the variable ID, type, offset, length, and value from the encoding system (
component 110 in this case) may be communicated to a receiving component. The global ID and the encoding attributes assigned to the variable may be arranged into a structure which may be known as a translation map element. The collection of the translation map elements may be referred to as a translation map, such as themaps - Moreover, because the type, offset, and length of each variable may remain constant within a
component maps maps component - The
system 100 may also include tags to assist thecomponent 120 with decoding the data received from thecomponent 110, such as by pointing thecomponent 120 to the definition of thevariables 125 a-e. In one embodiment, each tag is a combination of a global class number and a local class construct number. A class number may be a unique number given to a class when the class is added to a system, such as during coding time. The construct number is internal to the class and is assigned when new structures are added to the class (1, 2, 3, etc.). - Using the above tags in messages transmitted between the
components maps - Macros and/or other coding techniques, possibly including those supported by one or more C++ ANSI compilers, may be employed to define the description of each variable within each construct. For example, all global IDs may be assigned in a single file using one or more macros. Such macros may use the structure name as a parameter and concatenate additional characters to provide global references. The following macros may be employed in at least one embodiment within the scope of the present disclosure.
- The macro:
-
- #define ClassEnum(name) Class_##name
returns a global redundancy class name that is used to assign a global ID to a root construct name. The reference to root implies that this Assigned ID is a part of all construct IDs defined for this class. The combined ID of this class and the ID of any local construct may be sent as a message or tag to the receiving component. All internal definitions may use Class_##name as an internal variable.
- #define ClassEnum(name) Class_##name
- The macro:
-
- #define ConstructEnum(y,x) y::LocalConstruct_##x
returns an enumerated value that defines the local constructs (protected) ID within a root construct. Inherited classes may use this construct in their own constructs.
- #define ConstructEnum(y,x) y::LocalConstruct_##x
- The macro:
-
- #define offset(x,y) ((ushort) &((x *)0)−>y)
returns the offset of variable y in construct x.
- #define offset(x,y) ((ushort) &((x *)0)−>y)
- The macro:
-
- #define rsize(x,y) sizeof(((x *)0)−>y)
returns the size of variable y, in construct x, in bytes.
- #define rsize(x,y) sizeof(((x *)0)−>y)
- The macro:
-
- #define RedEnum(variable) LVN_##variable
defines a global redundancy name for “variable”.
- #define RedEnum(variable) LVN_##variable
- The macro:
-
- #define DefRedConstruct(version,name) StrctVer_##name=version, StrctNum_##name
defines a global variable version and name for construct “name”.
- #define DefRedConstruct(version,name) StrctVer_##name=version, StrctNum_##name
- The macro:
-
- #define defconstruct(name) newConstruct(StrctNum_##name,StrctVer_##name)
defines storage for construct “name”.
- #define defconstruct(name) newConstruct(StrctNum_##name,StrctVer_##name)
- The macro:
#define element( name, variable, type, callback) \ COMPONENT::describRedElement( \ COMPONENT::RType_##type, \ offset(name,variable), \ name::LVN_##variable, \ sizeof(RStorage_##type), \ 1,callback)
defines storage for “variable” of type “type” in construct “name” with convert function “callback”. Default conversion for these variables follows the standard conversion types (e.g., short to long or long to short). - The macro:
#define elementStruct( name, variable, callback) \ COMPONENT::describRedElement( \ COMPONENT::RedObject_sequenced, \ offset(name,variable), \ name::LVN_##variable, \ rsize(name,variable), \ 1,callback)
defines storage for “variable” of type structure in construct “name” with convert function “callback”. This call is used to define elements that need to remain intact and to be treated as a sequence of memory locations. Default conversion for these variables include right-most truncation or padding with zeros. - The macro:
#define elementArray( name, variable, type, repeat, callback) \ COMPONENT::describRedElement ( \ COMPONENT::RType_##type, \ offset(name,variable), \ name::LVN_##variable, \ sizeof(RStorage##type), \ repeat,callback) - defines storage for “variable” of type array in construct “name” of type “type” with an array bound of “repeat” and default conversion “callback”. This macro is used to define an array element of standard type (char, short, long, uchar, ushort, etc.). Default conversion is applied to each element of the array, array size may be truncated, or larger arrays may be filled with zeros for the additional array elements.
#define elementStructArray( name, variable, repeat, callback) \ COMPONENT::describRedConstruct ( \ COMPONENT::RedObject_sequenced, \ offset(name,variable), \ name::LVN_##variable, \ rsize(name,variable)/repeat, \ repeat,callback) - The macro:
- defines storage for “variable” as an array of structures in construct “name” with an array bound of “repeat” and default conversion “callback”. This macro is used to define an array element of non-standard type (memory area). Default conversion is applied to each element of the array (each element may be padded with zeros or truncated from the right), array size may be truncated, or larger arrays may be filled with zeros for the additional array elements.
- The macro:
#define construct( owner, vclass, vstrct, variable) \ COMPONENT::describRedConstruct( \ ClassEnum(vclass), \ vclass::StrctNum_##vstrct, \ owner::LVN_##variable, \ offset(owner,variable),1 )
defines storage for “variable” as defined in “owner by a previously defined construct with global ID of <vclass><vstruct>. - The macro:
#define constructArray( owner, vclass, vstruct, variable, repeat )\ COMPONENT::describRedConstruct( \ ClassEnum(vclass), \ vclass::StrctNum_##vstruct, \ owner::LVN_##variable, \ offset(owner,variable), repeat )
defines storage for “variable” as an array of size “repeat” in “owner”. Each array element is defined by a previously defined construct with global ID<vclass><vstruct>. - The macro:
#define control( name, controler, controled, control_type )\ COMPONENT::describRedControl ( \ name::LVN_##controler, \ name::LVN_##controled, \ control_type )
defines a relation ship between two variables with in a construct “name”. The controller controls the “control_type” aspect of the “controlled” variable. - The macro:
#define redClass( rclass, callback ) \ COMPONENT::defineRedClassDesc( \ ClassEnum(rclass), callback )
defines a function to call when construct “rclass” message is received and converted. - Using the above macros, implementation may be split into imbedded code in each class that is employed in the system (“imbedded code”) and generic code. To demonstrate an embodiment of such implementation, consider two systems, System A and System B, in which System A is a newer system that has evolved and has redefined some of its variables to accommodate additional requirements. This evolution caused the structures in System A to change in size and element count. Consequently, after taking System A offline to accomplish this update, System A needs to be brought online with the data from system B, which is still operating online. System B has been online or in the field for some time, and includes the original structures requiring updating. System B may also be considered a legacy component, such that System A may comprise an upgrade to the legacy component. In one embodiment, Systems A and B may be analogous to
components system 100 ofFIG. 1 . - The following structures may be defined in System A:
struct newStuff { int x; int y; }; struct enhancedOldStuf { int x; int y[10]; } struct syncThis { int z; int w; struct enhancedOldStuf old; struct newStuff new; struct other_stuff stuff; }; - The following structures may be defined in System B:
struct oldStuf { int x; int y[5]; } struct syncThis { int z; struct oldStuf old; int w; struct other_stuff stuff; }; -
- Notice that the upgrades to System A, via one or more revisions, has changed the syncThis construct drastically. The above example is referenced in the following discussions. However, those skilled in the art will appreciate that this example is presented merely to demonstrate aspects of
system 100, and is not scope-limiting in nature. That is, there are myriad ways to accomplish the data translation via map exchange according to aspects of the present disclosure other than the specific code provided herein. Thus, any absolutes employed to describe the code particular to the present example in no way limit the scope of applicability and/or adaptability ofsystem 100 to other scenarios.
- Notice that the upgrades to System A, via one or more revisions, has changed the syncThis construct drastically. The above example is referenced in the following discussions. However, those skilled in the art will appreciate that this example is presented merely to demonstrate aspects of
- Each class that belongs to Systems A or B has a class number that is globally defined. This class number may not be reused by other classes or changed by this class. The class defines an initializing method that may be called to get the constructs the class wishes to use.
- The following definitions may be found in System B, including the global class syncThis, which may be maintained across several systems, including Systems A and B.
Enum // class global IDs { // other classes.. ClassEnum(syncThis) = 23, // define syncThis globally as 23 // more classes.. }; - In the implementation of the syncThis class, the class definition may include:
Class syncThis // system B definition of class syncThis { // Redundancy descriptors.... structures that are // passed between the standby and the active systems // can have a definition here... //--------------------------------------------------- struct RedOldStuf { enum RedOldStuff_Objects { RedEnum(x) = 1, RedEnum(y) = 2, EndofRedOldStuff_Objects }; int x; int y[5]; }; Struct RedSyncThis // message sent to other COMPONENT that has syncThis Class { enum RedSyncThis_Objects { RedEnum(z) = 1, RedEnum(old) = 2, RedEnum(w) = 3, RedEnum(stuff) = 4, EndofRedSyncThis_Objects }; int z; RedOldStuff old; int w; struct other_stuff stuff; }; // construct number control enum LocalRedConstructs { DefRedConstruct(0, RedSyncThis) = 1, DefRedConstruct(0, RedOldStuff) = 2, EndofLocalRedConstructs }; public: static PASSFAIL describeRedConstructs( ); // called by COMPONENT only private: // COMPONENT call back... static PASSFAIL processMsgFromActiveCpu(ushort pDataConstNum, void *pMsgData); // other stuff for this class.. }; - An implementation method that describes the construct for the class syncThis is provided below. As described above, this method may only be called once, such as at initialization. An internal structure may then be built and exchanged with another system, which may use this description to parse an incoming RedSyncThis message from System B.
//static PASSFAIL syncThis::describeRedConstructs( ) { PASSFAIL rc = FAIL; RedTypeDefs::RedClassDesc *classptr; classptr = redClass(syncThis,processMsgFromActiveCpu); if ( classptr ) { do { // now define the redundancy constructs RedTypeDefs::RedConstructDesc *consptr; consptr = classptr->defConstruct(RedSyncThis); if ( consptr ) { // define the construct consptr->element(RedSyncThis,z,int,0); consptr->construct(RedSyncThis,syncThis,RedOldStuff,old); consptr->element(RedSyncThis,w,int,0); consptr->elementStruct(RedSyncThis,stuff,0); } else break; consptr = classptr->defConstruct(RedOldStuff); if ( consptr ) { // define the construct consptr->element(RedOldStuff,x,int,0); consptr->elementArray(RedOldStuff,y,int,5,0); } else break; rc = PASS; }while(0); } return rc; }; - Note that, from the description, all the described variables may rely on a default conversion function of a system to handle missing variables or variables of different type and size. Also note that this class registers its callback function (processMsgFromActiveCpu( )) used to process any message that is marked with this class tag.
- The next method that each class may have is a function that processes the construct received on its behalf. This function may be registered when the class descriptor is instantiated. The data received by this function should have been already in the correct position according to the defined local constructs.
PASSFAIL syncThis::processMsgFromActiveCpu ( ushort pDataConstNum, void *pMsgData ) { PASSFAIL rc = pass; switch(pDataConstNum) { case RedTypeId(RedSyncTis): // process the received data break; default: error (“syncThis: Invalid Construct Id(%d) received”, pDataConstNum ); rc = fail; break; } return rc; } - Now examine the definition used by system A. Since system A is a modification of the old system, some of the data has the same meaning but has additional storage to handle new requirements. The following is the class syncThis definition in system A:
Class syncThis // system A definition of class syncThis { // redundancy descriptors....All structures that are // passed between the standby and the active systems // must have a definition here... //--------------------------------------------------- struct RedEnhansedOldStuff // renamed { enum RedEnhansedOldStuff_Objects { RedEnum(x) = 1, RedEnum(y) = 2, Endof RedEnhansedOldStuff_Objects }; int x; int y[10]; // changed the size... }; struct RedNewStuff // new data { enum RedNewStuff_Objects { RedEnum(x) = 1, RedEnum(y) = 2, EndofNewOldStuff_Objects }; int x; int y[5]; }; Struct RedSyncThis // message sent to other COMPONENT that has syncThis Class { enum RedSyncThis_Objects { RedEnum(z) = 1, RedEnum(old) = 2, RedEnum(w) = 3, RedEnum(stuff) = 4, RedEnum(new) = 5, EndofRedSyncThis_Objects }; int z; int w; // location moved to save storage RedEnhansedOldStuff old; RedNewStuff new; struct other_stuff stuff; }; // construct number control enum LocalRedConstructs { DefRedConstruct(1, RedSyncThis) = 1, // version 0 07/01/02 // version 1 11/01/02 DefRedConstruct(1, RedEnhansedOldStuff) = 2, // version 0 07/01/02 // version 1 12/08/02 DefRedConstruct(0, RedNewStuf) = 3, // version 0 08/08/03 EndofLocalRedConstructs }; static PASSFAIL describeRedConstructs( ); static PASSFAIL processMsgFromActiveCpu(ushort pDataConstNum,void *pMsgData); // other stuff for this class.. }; - Note that, from the above definition, the RedOldStuff has been renamed but its ID remains the same (2). Also, the variable “w” has changed its place relative to the old definition but its ID remains the same (3). The new structure “NewStuff” has been added and is assigned a new ID (5) not present in system B. The remaining task is to code in the description of the variables. The following is the implementation of construct descriptions in system A.
//static PASSFAIL syncThis::describeRedConstructs( ) { PASSFAIL rc = FAIL; RedTypeDefs::RedClassDesc *classptr; classptr = redClass(syncThis,processMsgFromActiveCpu); if ( classptr ) { do { // now define the redundancy consructs RedTypeDefs::RedConstructDesc *consptr; consptr = classptr->defConstruct(RedSyncThis); if ( consptr ) { // define the construct consptr->element(RedSyncThis,z,int,0); consptr->element(RedSyncThis,w,int,0); consptr->construct(RedSyncThis,syncThis,RedEnhansedOldStuff, old); consptr->construct(RedSyncThis,syncThis,RedNewStuff,new); consptr->elementStruct(RedSyncThis,stuff,0); } else break; consptr = classptr->defConstruct(RedEnhancedOldStuf); if ( consptr ) { // define the construct consptr->element(RedEnhancedOldStuf,x,int,0); consptr->elementArray(RedEnhancedOldStuf,y,int,10,0); } else break; consptr = classptr->defConstruct(RedNewStuf); if ( consptr ) { // define the construct consptr->element(RedNewStuf,x,int,0); consptr->element(RedNewStuf,y,int, initialize_y); } else break; rc = PASS; }while(0); } return rc; };
Note that the new “<RedNewStuf><y>” element specifies an initializer that may be called when a message is received from a remote system that does not have a definition for this variable. - Note also that classes specify how data is saved into an outgoing message by the order of the variables described. Thus, in encoding the “RedSyncThis” for a system B message, the value of variable “z” is placed first in the message, followed by the value of construct “old,” and so on. Similarly, in System A, the message is filled first with the value of variable “z,” followed by the value of variable “w,” and so on. This implies that, for any variables that have a controlled/controlling relationship, the “controlling” variables should be described before any of “controlled” variables. Thus, when parsing a message, a system will obtain the value of the “controlling” variable before the “controlled” variable is encountered, thus providing a correct parsing algorithm.
- A “controlling” variable is a variable that controls some aspect of other “controlled” variables. For example, the controlling variable may specify the number of elements in an array that are passed in a message. Consequently, a construct may be defined with the maximum number of allowed records but may only populate one or more. Thus, the Systems A and B need to know this information to encode outgoing messages and, for incoming messages, to locate the control field and extract its value before encountering the controlled variable.
- The generic code can be categorized into three sections: translation map database, initialization, and operation. The initialization section is involved at the start-up of a system and when a communication link is established with another system. The translation map database refers to the data that has to be saved by a system to allow a system to translate between local and remote message structures. The operation section is involved in encoding and decoding messages traveling between the application and communication layers of a system.
- The translation map database consists of translation map elements that are linked together to form one or more tables or arrays. The tables/arrays may be indexed by the global ID of the elements. For example, in each system, a local table containing local or native descriptors may be created, as well as one or more remote tables containing remote descriptors native to other system(s). There are three types of descriptors which may populate the local and/or remote tables/arrays: class descriptors, construct descriptors, and variable descriptors. All the descriptors share a common header that defines their type, version, and length, etc. The descriptor header may be:
typedef struct { // total 4 bytes header...ulong mDescVer:4, // descriptor version.. 0-15 mDescLength:4, // size in words... mDescRefType:4, // enum RedDescRefType mDescRefVersion:4, // Ref version.. mDescRefNum:16; // Ref number } RedDescHdr; - The size of the descriptor header may be kept at thirty-two bits to minimize memory usage. The descriptor Version is used to specify the version of the descriptor. As stated before, these descriptors should rarely change, such that a range of 0-15 may be sufficient, but not mandatory. The descriptor length specifies the descriptor size in words. The descriptor type specifies the type of the descriptor as either a class, a construct or a variable. The version states the version of element using this descriptor. Each class and each construct may set the version value independently. Variables may not have a version. The reference number is the global ID assigned to variable using this descriptor.
- The class descriptor may be:
typedef struct { RedDescHdr mHdr; ulong mConstCount; // total number of constructs assigned // by this class.. // private Additional data for house keeping } RedClassElm; - This descriptor is defined once per class, and contains the total number of internal/local constructs defined by this class. In a house keeping section which may be private to each system, a link to each construct is saved. Since all constructs may be defined at initialization, the constructs can be allocated sequentially. In one embodiment, a single reference may be kept for each construct, the cumulative references thereafter accessible as elements in an array. Other variables are saved in the private data that are used for optimization, statistics, and other functions.
- The construct descriptor may be:
typedef struct { RedDescHdr mHdr; ulong mVarCount; // total number of Variables assigned // by this construct.. // Additional data for house keeping } RedConstElm; - This descriptor may be defined once per class construct, and may contain the total number of variables defined by the construct. A link to each variable descriptor may be saved in the housekeeping section. Since all variables in a construct may be defined sequentially at initialization, the variable descriptors may be allocated sequentially. In one embodiment, a single reference may be kept for each variable, the cumulative references thereafter accessible as elements in an array. Other variables may be saved in the private data that are used for optimization, statistics and other functions.
- The variable descriptors may be:
typedef struct { RedDescHdr mHdr; ulong mObjectType:4, // signed/unsigned struct ..etc mControlType:4, // control type (on-off, arry index, .. mSpare:8, // not used.. mControlRef:16; // controled by Variable #mControlRef ulong mArrayCount:16, // array max index value.. mLength:16; ulong mVarData1:16, mVarData2:16; // Additional data for house keeping } RedVarElm; - This descriptor may be defined once per variable in a construct, and may contain description of the variable as defined by the owning system. The object type refers to the type of variable this descriptor is trying to describe. Valid types include signed, unsigned, sequenced, or RedConstruct. Signed and unsigned have the normal standard meaning (truncation and padding is done on the left, and the sign bit must remain intact). Sequenced variables may be considered raw memory, and may be truncated from the right or padded on the right with zeros. No meaning may be attached to sequenced variables. RedConstruct variables refer to a predefined construct, and a system should search the table for their definition. Control reference may be set to zero unless this variable is controlled by another variable in the same construct, in which case the control reference may refer to the variable reference number. The array count is set to how many times this variable repeats, such as being set to one. Two 16-bit data values may also be saved with this descriptor to be used depending on the descriptor type.
- In the house keeping section, additional storage may be used to keep track of variable correlation between the local system descriptors and the remote system descriptors. The storage may be used for optimization.
- Referring to
FIG. 2 , illustrated is a flow-chart representing one embodiment of aninitialization method 200 according to aspects of the present disclosure. At aninitial step 205, the local system may initialize an internal local system table that holds the description of all pertinent variables, as well as a remote system table. However, a remote system table within the local system may remain empty as long as a communication link with a remote system is down. The descriptions of the variables may be obtained by calling all classes' describeRedConstructs( ) method. This method makes repeated calls to define the local constructs and the variables within these constructs, such as with the function implementation above. For example, the method may include astep 210 in which construct variables are individually defined until each variable within the construct is defined, as determined by adecisional step 215. This process may be repeated for each individual local construct until each construct is defined, as determined by adecisional step 220. Each call may thus add an element to the local system table. Once all the classes have been called, which indicates that all descriptions are now available, astep 225 is performed to establish a communication link with a remote system. - When the communication link is established with the remote system, the local system sends its internal descriptors to the remote system in a
step 230. The local system may also expect the remote system to send its own definitions in astep 235. For example, when a message from the remote system containing the descriptors arrives, the message is parsed according to the system internal structure and the definitions are saved into the remote system link list and/or inserted into the remote system table in astep 240. The definitions may be sent such that each message contains an integral number of class-constructs. That is, in one embodiment, no partial constructs may be sent in any message. Once the remote descriptors are received, verification of the contents of each descriptor is attempted and a correlation is created between the remote and local classes, constructs, and variables in astep 245. - The initialization method may then hibernate in a
step 250. However, the initialization stage may be reactivated if the communication link between the two systems is lost, which is depicted as astep 255 in themethod 200, although this is more of an occurrence than a process step to be executed by the method. In such case, the remote system table may be cleared in astep 260, and the process of establishing the communication link and exchanging descriptors may be repeated. - Messages received before substantially completed reception of the remote system descriptors may be ignored. Moreover, messages may not be allowed to leave a system before a communication link is established between the local system and one or all remote systems with which the local system may potentially communicate.
- To speed up parsing described above, the remote system descriptors may be correlated to the local system descriptors, such that the local system can determine if a received variable has a corresponding local definition. If the remote descriptor has no correlating local variable descriptor, it is marked as such. If the remote construct descriptor is found to be identical to the local construct descriptor, the construct is marked identical, and when such construct is received it is passed as-is to the application.
- Moreover, in some embodiments the
method 200 may not include each step illustrated inFIG. 2 , may include steps in addition to those illustrated, and may perform the illustrated and other steps in sequences other than described above. For example, descriptors may not be transmitted in both directions. That is, one of the systems may generate only the local descriptor table and not generate the remote descriptor table. Messages sent to such a system may require translation prior to transmission. - Referring to
FIG. 3 , illustrated is a flow-chart representing one embodiment of amethod 300 for encoding and decoding messages according to aspects of the present disclosure. The operation stage deals with the interface between the application and the system communication link, including message encoding and decoding. When the application has changed a structure and the change must be sent to the remote system, the application fills in the structure with the required data and calls system operation methods to send the data, as depicted in astep 305 of themethod 300. The operation section receives the data from the application and encodes the data according to the local system descriptors one variable at a time in astep 310. Once encoding is complete, system attaches a system tag to the message in astep 315, and the message is sent to the remote system in astep 320. - The system tag allows the remote system to decode the message correctly. An exemplary structure for the system tag is:
typedef struct { ushort mClassRef; ushort mConstRef; } RedDataSyncHdr; - The class reference is the globally assigned class reference number (in the present example it is 23) and the construct reference number is the reference number of the construct within that class (in the present example it is 1). This information is sufficient to allow the remote system to locate the relevant description.
- The remote system receives the message in a
step 325 and, using the system tag, locates the construct descriptor in the remote system table in astep 330. If the construct descriptor cannot be located, as determined in adecisional step 335, the message is ignored (step 340). With the construct descriptor in hand, the remote system attempts to locate the local description from the local system table in astep 345. If a local descriptor is not found, as determined in adecisional step 350, the message is ignored (step 340). - Using the local construct descriptor, the remote construct descriptor, and the message data section, the remote system moves the data from the message space into the local space one variable at a time in a
step 355. At this time, conversion, truncation, and padding of the variable value may take place. Once all incoming variables are moved into the local buffer, the local construct descriptor is scanned in astep 360 for any variable that has not been defined by the message source system. If an un-initialized variable is found, the variable descriptor is consulted for a default initializer. If an initializer is found, as determined in adecisional step 365, the initializer function is called in astep 370. Otherwise, the variable is initialized to zero or some other default value in astep 375. After the construct descriptor has been decoded, the constructed buffer is sent to a processing function, such as the class registered processing function (processMsgFromActiveCpu( )), for content manipulation in astep 380. In some embodiments, themethod 300 may not include each step illustrated inFIG. 3 , may include steps in addition to those illustrated, and may perform the illustrated and other steps in sequences other than described above. - In one embodiment, such as that in which a system or network has N:M redundancy, a system can be configured to keep data from several remote systems. However, in such an embodiment, all transmitted data may be relative to its own system definitions, such that the burden of conversion lies with the receiving system.
- Looking back at the example above, note that the order of the variables is handled by matching the remote system variable to a variable in the local system. Thus, the value of the variable “w” (with ID of 23.1.3) may be set correctly from the received “w” (also with an ID of 23.1.3). Similarly, the name change from “RedOldStuff” to “REDEnhancedOldStuf” may be correctly handled by the global ID (23.2), since both constructs have the same ID and the name is, therefore, irrelevant.
- For the variables “y[5]” and “y[10],” if the data is moving from System B to System A, then the remaining elements (y[5]-y[9]) are set to zero. However, if the data is moving from System A to System B, then the extra elements may be truncated. The new construct “newStuf” is not defined in System B and, therefore, has no description in the remote system table in System A. After the remote COMPONENT construct variables in System A have been processed, the “newStuf” storage space is initialized. To initialize this space, the system initializes each variable within the construct such that, in this case, variable x is set to zero while y is set by calling initialize_y( ) defined by the variable descriptor. The resulting buffer is then passed to the class registered processing function (processMsgFromActiveCpu( )).
- Some embodiments of the present disclosure may be useful in removing the burden of keeping track of individual variables and structures, as well as assisting in the definition of standardized processes, methods, and systems for achieving less complicated addition and/or removal of variables between systems having different native data structure formats or that are otherwise incompatible. Some aspects of the present disclosure may also provide users the flexibility to include predefined structures within messages and the ability to change imbedded structures as such a need arises. Aspects of the present disclosure may also provide the ability to automatically reformat remote variables to match the format of local variables, such as between big Endian and little Endian formats, or among character, short, long, etc. Moreover, in some embodiments, automatic conversion routines may be provided internal to one or more components in a system or systems, which can enhance transparency and relieve users from such conversion tasks.
- Referring to
FIG. 4 , continuing with the example above, illustrated is a block diagram of a portion of one embodiment of adatabase 400 for System B. As discussed above, System B is one that has been online or in the field for some time, and includes original structures requiring updating in response to the upgrade of System A. Thedatabase 400 includes aclass definition array 410, aconstruct definition array 420, and avariable definition array 430. - For example, the
class definition array 410 includes an entry “ClassRefId” for the class_syncThis and having the value “23,” an associated “Construct_count” having the value “2,” and an associated “Construct_Refindex” having the value “962.” The “ClassRefId” is unique to the class. The “Construct_count” indicates the number of construct definitions in an instance of “ClassRefId.” For example, in the illustrated embodiment, the class_syncThis includes the constructs RedSyncThis and RedOldStuff. The “Construct_Refindex” indicates the location of the first construct definition in theconstruct definition array 420. - Continuing with this example, the construct RedSyncThis is element 962 in the
construct definition array 420, has an ID “ConstructRefId” of “1,” and includes four variables per the “Variable_count,” wherein the first variable iselement 1234 in thevariable definition array 430, per the “Variable_Refindex.” The 4 variables in the RedSyncThis construct are “z,” “old,” “w,” and “stuff,” which agrees with the code described above. As shown in thevariable definition array 430, each of these variables may include or have associated therewith a “VariableRefId” indicating the variable's position within the construct, a “VariableSize” indicating the length of the variable, a “VariableRepeat” indicating the number of times the variable is to be repeated within the construct, and a “VariableType” indicating the type of the variable. Each variable definition may also include one or more pointers to locations in which other data is stored, as indicated by the “VarData1” and “VarData2” also illustrated inFIG. 4 . - Referring to
FIG. 5 , illustrated is a block diagram of a portion of one embodiment of adatabase 500 for System A, continuing with the above example. As described above, System A is a newer system that has evolved and has redefined some of its variables to accommodate additional requirements. Thedatabase 500 includes aclass definition array 510, aconstruct definition array 520, and avariable definition array 530. - For example, the
class definition array 510 includes an entry “ClassRefId” for the class_syncThis and having the value “23,” an associated “Construct_count” having the value “3,” and an associated “Construct_Refindex” having the value “980.” In the illustrated embodiment, the class_syncThis includes the constructs RedSyncThis, RedEnhancedOldStuff (partially corresponding to the construct RedOldStuff in System B), and RedNewStuff. - The construct RedSyncThis is
element 980 in theconstruct definition array 520, has an ID “ConstructRefId” of “1,” and includes five variables per the “Variable_count,” wherein the first variable iselement 1543 in thevariable definition array 530, per the “Variable_Refindex.” The five variables in the RedSyncThis construct are “z,” “w,” “old,” “new,” and “stuff,” which also agrees with the code described above. As shown in thevariable definition array 530, each of these variables may have definitions similar to those in thevariable definition array 430, although they may not be in the same sequence. For example, the order of the variables “w” and “old” are different in thevariable definition arrays variable definition arrays - Referring to
FIG. 6 , illustrated is a block diagram of a portion of one embodiment of a descriptor message or map 600 that older System B may send to newer System A to assist System A with translation of messages received from System B. Although themap 600 may include descriptors for multiple classes, only the descriptors for the class syncThis are shown inFIG. 6 . - The
map 600 includes a “ClassRefId” of 23 indicating that the immediately following information pertains to the class “syncThis.” Themap 600 also includes a “Construct_count” of 2, indicating that “syncThis” includes two constructs. The first construct “RedSyncThis” has a “ConstructRefId” of 1, and includes four variables, per the “Variable_count”. Themap 600 then lists the definitions for each of the variables “z,” “old,” “stuff,” and “w” included in the construct “RedSyncThis.” - The second construct “RedOldStuff” has a “ConstructRefId” of 2, and includes two variables, per the “Variable_count.” The two variables in the construct “RedOldStuff” include “x” and “y[5],” which is an array of five elements. The
map 600 then lists the definitions for “x” and “y[5],” and continues to the next class (having a “ClassRefId” of 26). - Thus, System A may consult the
map 600 to gather information pertaining to the format/structure of the class “syncThis,” the constructs “RedSyncThis” and “RedOldStuff,” and the variables “z,” “old,” “stuff,” “w,” “x,” and “y[5]” to process messages and/or data received from System B. Moreover, System B may continue to send such information in its native format, regardless of the format System A uses for native operations. - Referring to
FIG. 7 , illustrated is a block diagram of a portion of one embodiment of a descriptor message or map 700 that System A may send to System B to assist System B with translation of messages received from System A. Although themap 700 may include descriptors for multiple classes, only the descriptors for the class syncThis are shown inFIG. 7 . - The
map 700 includes a “ClassRefId” of 23 indicating that the immediately following information pertains to the class “syncThis.” Themap 700 also includes a “Construct_count” of 3, indicating that “syncThis” includes three constructs. The first construct “RedSyncThis” has a “ConstructRefId” of 1, and includes five variables, per the “Variable_count”. Themap 700 then lists the definitions for each of the variables “z,” “w,” “old,” “new,” and “stuff” included in the construct “RedSyncThis.” - The second construct “RedEnhancedOldStuff” has a “ConstructRefId” of 2, and includes two variables, per the “Variable_count.” The two variables in the construct “RedEnhancedOldStuff” include “x” and “y[10],” which is an array often elements. The
map 700 then lists the definitions for “x” and “y[10].” - The third construct “RedNewStuff” has a “ConstructRefId” of 3, and includes two variables, per the “Variable_count.” The two variables in the construct “RedNewStuff” include “x” and “y.” The
map 700 then lists the definitions for “x” and “y,” and continues to the next class (having a “ClassRefId” of 26). Note that the variables “x” and “x” are similarly named. However, by using global IDs, such as those based on the class number, the construct number within the class, and the variable number within the construct, the similar names may not be problematic. For example, the global ID for the variable “x” in the construct “RedEnhanced OldStuff” may be 23.2.1, whereas the global ID for the variable “x” in the construct “RedNewStuff” may be 23.3.1. - Thus, System B may consult the
map 700 to gather information pertaining to the format/structure of the class “syncThis,” the constructs “RedSyncThis,” “redEnhancedOldStuff,” and “RedNewStuff,” and their variables to process messages and/or data received from System A. Moreover, System A may send such information in its native format, regardless of the format System B uses for native operations. - The present disclosure introduces a method of exchanging data between first and second components having first and second native data structure formats, respectively. In one embodiment, the method includes exchanging native data structure format information between the first and second components, generating data in the first native data structure format, and transmitting the generated data between the first and second components. The generated data is translated into the second native data structure format based on the exchanged native data structure format information.
- A processing system for exchanging messages between first and second components having first and second native message formats, respectively, is also introduced in the present disclosure. In one embodiment, the processing system includes means for exchanging native data structure format information between the first and second components, means for generating data in the first native data structure format, and means for transmitting the generated data between the first and second components. Such an embodiment also includes means for translating the generated data into the second native data structure format based on the exchanged native data structure format information. The exchanging means, generating means, transmitting means, and translating means may be included in one or more processors or other components of a computer or network, such as the
components FIG. 1 . - The method of exchanging messages between first and second components having first and second native message formats, respectively, may also be implemented or embodied in a program product according to aspects of the present disclosure. In at least one embodiment, such a program product may include means recorded on a computer-readable storage medium for exchanging native data structure format information between first and second components having first and second native message formats, respectively. The program product also includes means recorded on the medium for generating data in the first native data structure format, and means recorded on the medium for transmitting the generated data between the first and second components. Means also recorded on the medium are configured to translate the generated data into the second native data structure format based on the exchanged native data structure format information. The storage medium may be or comprise a magnetic recording medium, an optical recording medium, or a network distribution recording medium, such as may be employed to distribute the program product over (or “post”) a LAN, a WAN, the Internet, and/or other networks.
- The foregoing has outlined features of several embodiments according to aspects of the present disclosure. Those skilled in the art should appreciate that they may readily use the present disclosure as a basis for designing or modifying other processes and structures for carrying out the same purposes and/or achieving the same advantages of the embodiments introduced herein. Those skilled in the art should also realize that such equivalent constructions do not depart from the spirit and scope of the present disclosure, and that they may make various changes, substitutions and alterations herein without departing from the spirit and scope of the present disclosure.
Claims (53)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/809,963 US20050216896A1 (en) | 2004-03-26 | 2004-03-26 | Data communication via tanslation map exchange |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/809,963 US20050216896A1 (en) | 2004-03-26 | 2004-03-26 | Data communication via tanslation map exchange |
Publications (1)
Publication Number | Publication Date |
---|---|
US20050216896A1 true US20050216896A1 (en) | 2005-09-29 |
Family
ID=34991666
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/809,963 Abandoned US20050216896A1 (en) | 2004-03-26 | 2004-03-26 | Data communication via tanslation map exchange |
Country Status (1)
Country | Link |
---|---|
US (1) | US20050216896A1 (en) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070189196A1 (en) * | 2005-04-12 | 2007-08-16 | Santera Systems, Inc. | Dynamic loading for signaling variants |
US7676605B1 (en) * | 2005-04-06 | 2010-03-09 | Teradici Corporation | Methods and apparatus for bridging a bus controller |
US7908335B1 (en) | 2005-04-06 | 2011-03-15 | Teradici Corporation | Methods and apparatus for bridging a USB connection |
US20150012912A1 (en) * | 2009-03-27 | 2015-01-08 | Optumsoft, Inc. | Interpreter-based program language translator using embedded interpreter types and variables |
US9626417B1 (en) * | 2013-05-08 | 2017-04-18 | Amdocs Software Systems Limited | System, method, and computer program for automatically converting characters from an ISO character set to a UTF8 character set in a database |
US11354312B2 (en) * | 2019-08-29 | 2022-06-07 | International Business Machines Corporation | Access-plan-based querying for federated database-management systems |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6351750B1 (en) * | 1998-10-16 | 2002-02-26 | Softbook Press, Inc. | Dynamic conversion of byte ordering for use on different processor platforms |
US20030233397A1 (en) * | 2002-06-12 | 2003-12-18 | Seapass Solutions Inc. | Interface development environment and interface for connecting systems having different data structures |
US20040031030A1 (en) * | 2000-05-20 | 2004-02-12 | Equipe Communications Corporation | Signatures for facilitating hot upgrades of modular software components |
US20040044793A1 (en) * | 2002-08-29 | 2004-03-04 | Heinz Pauly | Isolated mappping point |
US6772320B1 (en) * | 2000-11-17 | 2004-08-03 | Intel Corporation | Method and computer program for data conversion in a heterogeneous communications network |
US20050033822A1 (en) * | 2003-08-05 | 2005-02-10 | Grayson George Dale | Method and apparatus for information distribution and retrieval |
US20050114853A1 (en) * | 2003-11-26 | 2005-05-26 | Glider Joseph S. | Software upgrade and downgrade in systems with persistent data |
-
2004
- 2004-03-26 US US10/809,963 patent/US20050216896A1/en not_active Abandoned
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6351750B1 (en) * | 1998-10-16 | 2002-02-26 | Softbook Press, Inc. | Dynamic conversion of byte ordering for use on different processor platforms |
US20040031030A1 (en) * | 2000-05-20 | 2004-02-12 | Equipe Communications Corporation | Signatures for facilitating hot upgrades of modular software components |
US6772320B1 (en) * | 2000-11-17 | 2004-08-03 | Intel Corporation | Method and computer program for data conversion in a heterogeneous communications network |
US20030233397A1 (en) * | 2002-06-12 | 2003-12-18 | Seapass Solutions Inc. | Interface development environment and interface for connecting systems having different data structures |
US20040044793A1 (en) * | 2002-08-29 | 2004-03-04 | Heinz Pauly | Isolated mappping point |
US20050033822A1 (en) * | 2003-08-05 | 2005-02-10 | Grayson George Dale | Method and apparatus for information distribution and retrieval |
US20050114853A1 (en) * | 2003-11-26 | 2005-05-26 | Glider Joseph S. | Software upgrade and downgrade in systems with persistent data |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7676605B1 (en) * | 2005-04-06 | 2010-03-09 | Teradici Corporation | Methods and apparatus for bridging a bus controller |
US7908335B1 (en) | 2005-04-06 | 2011-03-15 | Teradici Corporation | Methods and apparatus for bridging a USB connection |
US20070189196A1 (en) * | 2005-04-12 | 2007-08-16 | Santera Systems, Inc. | Dynamic loading for signaling variants |
US8228926B2 (en) | 2005-04-12 | 2012-07-24 | Genband Us Llc | Dynamic loading for signaling variants |
US20150012912A1 (en) * | 2009-03-27 | 2015-01-08 | Optumsoft, Inc. | Interpreter-based program language translator using embedded interpreter types and variables |
US9262135B2 (en) * | 2009-03-27 | 2016-02-16 | Optumsoft, Inc. | Interpreter-based program language translator using embedded interpreter types and variables |
US9626417B1 (en) * | 2013-05-08 | 2017-04-18 | Amdocs Software Systems Limited | System, method, and computer program for automatically converting characters from an ISO character set to a UTF8 character set in a database |
US11354312B2 (en) * | 2019-08-29 | 2022-06-07 | International Business Machines Corporation | Access-plan-based querying for federated database-management systems |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7043686B1 (en) | Data compression apparatus, database system, data communication system, data compression method, storage medium and program transmission apparatus | |
US7526769B2 (en) | Message translation and parsing of data structures in a distributed component architecture | |
US5941978A (en) | Method for comparing attribute values of controllable object expressions in a network element | |
CN101246486B (en) | Method and apparatus for improved process of expressions | |
US5787147A (en) | Test message generator in a telecommunications network | |
CN113691486B (en) | Method, device, equipment and storage medium for modifying message | |
US5418963A (en) | Protocol encoding/decoding device capable of easily inputting/referring to a desired data value | |
CN100389572C (en) | System and method for long-distance calling communication assembly | |
US20070112810A1 (en) | Method for compressing markup languages files, by replacing a long word with a shorter word | |
WO2004046963A1 (en) | Method and device for defining objects allowing to establish a device management tree for mobile communication devices | |
WO2012126301A1 (en) | Processing method and device for message transmission and reception | |
CN113381870B (en) | Message processing method and device | |
US20100306414A1 (en) | Transferring of SNMP Messages Over UDP with Compression of Periodically Repeating Sequences | |
US6233730B1 (en) | Revision compatibility between programs | |
US7440408B1 (en) | Method and system for inventorying a network | |
CN111324619A (en) | Object updating method, device, equipment and storage medium in micro service system | |
US20050216896A1 (en) | Data communication via tanslation map exchange | |
US8954400B2 (en) | Method, system and program product for managing structured data | |
US7506068B2 (en) | Method, apparatus and system for transforming, converting and processing messages between multiple systems | |
US20050010595A1 (en) | System and method for automating an identification mechanism and type information configuration process for a real-time data feed to a database | |
KR102087272B1 (en) | Method for transforming data for low volume transmission of meta model base protocol, and data transmitting system for low volume transmission of meta model base protocol | |
CN108509187B (en) | Method and system for automatically generating MIB function code of software platform | |
CN117170908A (en) | Data exchange method, system and device based on heterogeneous data of network system | |
US7769896B2 (en) | Method, apparatus and system for dispatching messages within a system | |
CN113949438B (en) | Unmanned aerial vehicle communication method, device, equipment and storage medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SANTERA SYSTEMS, INC., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:DOLEH, AHMED;REEL/FRAME:015151/0940 Effective date: 20040318 |
|
AS | Assignment |
Owner name: SANTERA SYSTEMS, LLC, TEXAS Free format text: MERGER;ASSIGNOR:SANTERA SYSTEMS, INC.;REEL/FRAME:020723/0150 Effective date: 20061031 Owner name: SANTERA SYSTEMS, LLC,TEXAS Free format text: MERGER;ASSIGNOR:SANTERA SYSTEMS, INC.;REEL/FRAME:020723/0150 Effective date: 20061031 |
|
AS | Assignment |
Owner name: SANTERA SYSTEMS, LLC, TEXAS Free format text: MERGER;ASSIGNOR:SANTERA SYSTEMS, INC.;REEL/FRAME:020741/0943 Effective date: 20061031 Owner name: SANTERA SYSTEMS, LLC,TEXAS Free format text: MERGER;ASSIGNOR:SANTERA SYSTEMS, INC.;REEL/FRAME:020741/0943 Effective date: 20061031 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: GENBAND, INC., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SANTERA SYSTEMS, LLC;REEL/FRAME:023471/0754 Effective date: 20091105 Owner name: GENBAND, INC.,TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SANTERA SYSTEMS, LLC;REEL/FRAME:023471/0754 Effective date: 20091105 |
|
AS | Assignment |
Owner name: GENBAND US LLC, TEXAS Free format text: RELEASE AND REASSIGNMENT OF PATENTS;ASSIGNOR:COMERICA BANK, AS AGENT;REEL/FRAME:039280/0467 Effective date: 20160701 |