Patent Publication Number: US-2010125606-A1

Title: Data structures and methods of forming the same

Description:
FIELD OF THE INVENTION 
     This invention relates generally to data structures and more specifically, to data structures used within a computing system. 
     BACKGROUND OF THE INVENTION 
     Conventional software programming languages that are utilized within a computing system often include a number of native data types, classes, and structures. The native data types of a programming language, for example, integers, floating point number, boolean values, etc.) are utilized to build various classes and structures. The building of classes and structures from the native data types, however, often leads to inefficient transfer of the classes and structures within a network system. Specifically, in order to be transferred within a network or between software modules within a computer system, the classes and structures must often undergo a serialization process that converts the classes and structures into their native data types. This serialization process is often an inefficient process that leads to delays in the transfer of the data. 
     Accordingly, there is a need for data structures and methods of forming data structures that may be transferred within a system or over a network efficiently at relatively high speeds. 
     BRIEF DESCRIPTION OF THE INVENTION 
     According to one embodiment of the invention, there is disclosed a data structure that may be stored in a suitable memory of a computer system. The data structure may include a first data array and a second data array. The first data array may include respective identifiers of a plurality of data types that are included in the data structure. The second data array may include data formatted in accordance with the plurality of data types. The data structure may facilitate relatively high speed communication of the data included in the data structure. 
     According to another embodiment of the invention, there is disclosed a method for forming a data structure. The method may include determining a plurality of data types to include in the data structure. A first data array including respective identifiers of the plurality of data types may be generated. A second data array including data formatted in accordance with the plurality of data types may also be generated in order to form the data structure. 
     According to another embodiment of the invention, there is disclosed a method for storing data in a data structure for communication within a computer system. Data to include in the data structure may be identified, wherein the identified data includes data formatted in accordance with a plurality of data types. The plurality of data types may be identified. A first data array of the data structure may be generated that includes respective identifiers of the plurality of data types. A second data array of the data structure may be generated that includes the identified data. 
     Other embodiments, aspects, and features of the invention will become apparent to those skilled in the art from the following detailed description, the accompanying drawings, and the appended claims. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Having thus described the invention in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein: 
         FIG. 1  is a block diagram of one example data hub system, according to an illustrative embodiment of the invention. 
         FIG. 2  is a depiction of one example routing table that may be utilized by a data hub in accordance with various embodiments of the invention. 
         FIG. 3  is a depiction of one example transport packet that may be communicated through a data hub in accordance with various embodiments of the invention. 
         FIG. 4  is a flowchart illustrating one example method for routing data through a data hub, according to an illustrative embodiment of the invention. 
         FIG. 5  is a depiction of one example generic data structure that may be communicated through a data hub in accordance with various embodiments of the invention. 
         FIG. 6  is a flowchart of one example method for forming a generic data structure, according to an illustrative embodiment of the invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     Illustrative embodiments of the invention now will be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments of the invention are shown. Indeed, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like numbers refer to like elements throughout. 
     Disclosed are data structures and methods for forming the data structures. A data structure in accordance with embodiments of the invention may be referred to as a generic data structure. The generic data structure may include a first data array that includes respective identifiers of a plurality of data types included in the generic data structure. The identifiers may be respective integer values associated with the plurality of data types. Additionally, the generic data structure may include a second data array that includes data formatted in accordance with the plurality of data types. The generic data structure may be scalable and may include any amount of data. Additionally, by including the first data array that identifies the data types included in the data structure, the data structure may be self describing. For example, when a data structure is transferred, the data type array may be utilized to identify the various data values associated with the data structure in an efficient manner. There is no need to break the data structure down into its native data types prior to transfer by utilizing a serialization process. Thus, relatively high speed communication or transfer of the data structure may be achieved. 
     Turning to the figures,  FIG. 1  is a block diagram of one example data hub system  100 , according to an illustrative embodiment of the invention. The data hub system  100  may be one example of a system or environment in which data structures in accordance with embodiments of the invention may be utilized.  FIG. 1  illustrates an example software architecture for communicating data between any number of clients, such as clients  102   a - n  and/or any number of DHPs, such as DHPs  104   a - n,  through a data hub  106 . For purposes of this disclosure, the clients  102   a - n  and DHPs  104   a - n  may be collectively referred to as modules. According to an aspect of the invention, the software architecture provides a generic command set based protocol that allows for the data to be exchanged or communicated at relatively high speed. In order to achieve relatively high speed data communication, the software architecture may be a point-to-point architecture, i.e., the data hub  106  may pass data from a source to one or more intended destination(s) in a one-to-one manner. Therefore, modules in the data hub system  100  that are not supposed to get the data remain unaffected. The data hub  106  may be a software module, integrated into or otherwise in communication with a computer system  108 , and the data hub  106  may act as a router for the computer system  108  by facilitating communication or data transfers between different components (or modules) in the computer system  108 . The various components or modules of the computer system  108  may include software and/or hardware components or modules. 
     Further, according to an aspect of the invention, the DHPs  104   a - n  may be loosely coupled plug-in modules associated with the computer system  108 . The loose coupling among these modules may facilitate addition, replacement, and/or removal of the plug-in modules without affecting existing modules in the data hub system  100 . In accordance with one embodiment of the invention, each DHP, such as the DHPs  104   a - n,  may be a process, program, memory location, memory device interface (for example, to a hard drive) etc. that can facilitate the processing of commands received and/or sent in the various communications between the DHPs  104  and/or the clients  102  through the data hub  106 . Furthermore, a client may be a software module, inside the computer system  108 , which facilitates the collection and/or processing of data. For example, a client may include a graphical user interface (GUI) that allows a user of the computer system  108  to set configuration values and/or display data in graphical representation. As another example, a client may include a software application that is executed on the computer system  108  and that processes various data, such as a kernel process, a user application, etc. 
     According to an aspect of the invention, at least one of the DHPs  104   a - n  or one of the clients  102   a - n  may act as a source for a command and/or data that is routed through the data hub  106  to a destination. Similarly, at least one of the clients  102   a - n  and/or the DHPs  104   a - n  may act as intended destinations for the routed commands and/or data. For purposes of this disclosure, the term “data source” may refer to a module or component that sends a data command or request to one or more intended destinations that may be another module or component in the data hub system  100 . In an example embodiment of the invention, a client, such as the client  102   a  may send a data request to a DHP, such as the DHP  104   a  as a destination. The DHP  104   a  may process the data request and may respond with the requested data. According to an aspect of the invention, the destination may be either a client application executing on the computer system  108 , a data storage application on the computer system  108  (e.g., a database or other software-based data storage application), an interface to a data storage devices (e.g., a hard drive, disk drive, or other memory device), an interface to a data acquisition server, or an interface to data collection hardware on the computer system  108 . Additionally, although a data request is described as a command that may be routed through the data hub  106 , a wide variety of different commands may be routed by the data hub  106  as desired in various embodiments of the invention. 
     According to an aspect of the invention, the data hub  106  may include an interface module  110  that operates as an interface to receive an electronic communication such as a data request from the data source (for example, the client  102   a  or the DHP  104   a ). Additionally, various clients  102   a - n  may each include a respective client interface  112   a - n.  The client interfaces  112   a - n  may operate as interfaces that facilitate sending and receiving electronic communications to and from the data hub  106 . Similarly, various DHPs  104   a - n  may each include a respective DHP interface  114   a - n.  These DHP interfaces  114   a - n  may operate as interfaces that facilitate sending and receiving electronic communications to and from the data hub  106 . As desired in various embodiments of the invention, the client interfaces  112   a - n  and/or the DHP interfaces  114   a - n  may receive data request(s) and/or other commands from the data hub  106 . Additionally, as desired in various embodiments of the invention, the client interfaces  112   a - n  and/or the DHP interfaces  114   a - n  may communicate response(s) for the received data request(s) and/or other commands to the data hub  106 . Moreover, in various embodiments of the invention, any number of the client interfaces  112   a - n,  and/or the DHP interfaces  114   a - n  may be destination interface modules associated with the intended one or more destinations. 
     The data hub system  100  may further include a routing module  116  as a component of the data hub  106  or otherwise in communication with the data hub  106 . According to an aspect of the invention, the routing module  116  may determine the intended one or more destinations of a communication. In certain embodiments, the determination of the one or more destinations may be facilitated by using one or more suitable routing tables associated with the routing module  116 . Following the determination of one or more destinations, the routing module  116  may route the electronic communication, received at the interface module  110  of the data hub  106 , to the one or more intended destinations. In one example embodiment of the invention, a client, such as the client  102   b,  may send a request to the interface module  110  for a DHP, such as the DHP  104   b.  The routing module  116  may route the communication received at the interface module  110  to the destination DHP  104   b.  According to an aspect of the invention, the routing module  116  may route the electronic communication, received from the data source, to an intended destination in a one-to-one or point to point manner. 
     The data communication described above discusses data transfer within a single computer (i.e., the computer system  108 ). However, the data transfer is not limited to a single computer, and may be extended to multiple computers and/or computer-based devices or systems. The design and architecture of the data hub  106  makes it a flexible module that may be used for remote communication between various computers. For example, as shown in  FIG. 1 , the data hub system  100  may include a second computer system  118  that communicates with the computer system  108  via one or more suitable networks  120 . The second computer system  118  may be located remotely from the computer system  108 , and hence the second computer system  118  may be referred to as the remote computer system  118 . Although only a single remote computer  118  is illustrated in  FIG. 1 , any number of remote computers  118  may be utilized as desired in various embodiments of the invention. Additionally, the one or more suitable networks  120  may be any wired and/or wireless networks that connect the two or more computer systems, such as a local area network, a wide area network, etc. The communication between the computer system  108  and the remote computer system  118  may be via any suitable communication protocol or communication protocols as desired in various embodiments of the invention, for example, a Transmission Control Protocol/Internet Protocol (TCP/IP) protocol. 
     In order to facilitate communication between the computer system  108  and the remote computer system  118 , remote communicating DHPs may be utilized in the computer system  108  and the remote computer system  118 . For example, as shown in the  FIG. 1 , a first remote communicating DHP  122  may be included in the computer system  108 , and a second remote communicating DHP  124  may be utilized in the remote computer system  118 . The first remote communicating DHP  122  may be a plug-in module that is connected to the data hub  106  and to the one or more networks  120  via one or more suitable network interface devices  126 . Each of the one or more network interface devices may transmit and receive data over at least one of the one or more networks  120 . The first remote communicating DHP  122  may include an interface (not shown in the  FIG. 1 ) operable to send and/or receive data from and to the remote computer system  118 . Similarly, the second remote communicating DHP  124  may include an interface (not shown in the  FIG. 1 ) operable to receive data from and to the computer system  108 . The functionalities of the first remote communicating DHP  122  (or the second remote communicating DHP  124 ) and its interface may be same as the functionalities of the DHPs  104   a - n  and its respective interfaces  114   a - n.    
     Further, as shown in the  FIG. 1 , the second remote communicating DHP  124  may be in communication with a remote network interface device  128  that may transmit and receive data over the one or more suitable networks  120 . In certain embodiments of the invention, the network interface device  126  and the remote network interface device  128  may be hardware components with associated software. One example of the network interface device  126  (or the network interface device  128 ) may be an Ethernet card. 
     Embodiments of the invention may include at least one data hub in each computer system  108  and  118 . For example, as shown in the  FIG. 1 , the computer system  108  may include the data hub  106 , and the remote computer system  118  may include a remote data hub  130  that interfaces with the second remote communicating DHP  124  in order to send and receive data to and from the computer system  108  via the first remote communicating DHP  122 . Each DHP may register with its corresponding data hub, in accordance with various embodiments of the invention. Moreover, a data hub, such as the data hub  106 , may have access to client and/or DHP addresses for clients and/or DHPs in direct communication with the data hub  106  or in indirect communication with the data hub  106  via the remote data hub  130 . As one example, the first remote communicating DHP  122  may communicate with the second remote communication DHP  124  in order to identify the DHPs that are in communication with the remote data hub  130 . The data hub  106  and/or the first remote communicating DHP  122  may then assign unique DHP addresses to the identified DHPs in communication with the remote data hub  130 , and the unique DHP addresses may be communicated to the second remote communicating DHP  124  and the remote data hub  130 . The remote communicating DHP  124  may then register with the remote data hub  130  with all of the DHP addresses on the remote computer system  118 . Thus, the remote data hub  130  may have unique identifiers as assigned by the data hub  106  for itself and any component connected to it. In an example embodiment of the invention, when the second remote communicating DHP  124  receives a message from the first remote communicating DHP  122 , the second remote communicating DHP  124  and/or the remote data hub  130  may identify which computer system (i.e., the computer system  108  in this case) and which remote communicating DHP (i.e., the first remote communicating DHP  122  in this case) sent this message. The second remote communicating DHP  124  and/or the remote data hub  130  may then determine one or more desired destinations for the message, and the remote data hub  130  may route the message. 
     Because remote communicating DHPs  122  and  124  are registered modules, the software architecture shown in the  FIG. 1  may facilitate secured communication between remotely located computer systems  108  and  118 . Thus, the first remote communicating DHP  122  may act as a single point for adjustment in the computer system  108  and may facilitate communication with the remote computer system  118 . Similarly, the second remote communicating DHP  124  may act as a single point for adjustment in the remote computer system  118  and may facilitate communication with the computer system  108 . In an example embodiment of the invention, any DHP  104   a - n  (or the remote communicating DHP  122  or  124 ), connected to the data hub  106  (or the remote data hub  130 ) may be replaced or removed. Moreover, in accordance with one embodiment of the invention, additional DHP(s) may be added to the data hub system  100 . 
       FIG. 2  is a depiction of one example routing table  200  that may be utilized by a data hub in accordance with various embodiments of the invention. The routing table  200  may include information associated with various modules connected to a data hub, such as the data hub  106  illustrated in  FIG. 1 . In an embodiment of the invention, these various modules may exchange data through the data hub  106 . For example, as shown in  FIG. 2 , the routing table  200  may include information associated with modules DHP A, DHP B, client A and client B that are all connected to the data hub  106 . The routing table  200  may also define an entity identifier (ID) for each of these modules. In one embodiment of the invention, a respective unique entity ID may be provided for each of the modules. For example, as shown in  FIG. 2 , the modules DHP A, DHP B, client A and client B have unique entity IDs  001 ,  002 ,  003 , and  004  respectively. In an example embodiment of the invention, the entity IDs  001 ,  002 ,  003 , and  004  may be stored source/destination identifiers. 
     According to an aspect of the invention, a routing module, such as the routing module  116  shown in  FIG. 1  associated with the data hub  106  may determine one or more intended destinations to which a command, such as a data request (received from a data source), is to be transmitted by accessing the routing table  200 . In an embodiment of the invention, a data request may include a destination identifier that refers to a unique ID for the intended destination. Upon receiving the data request from the data source, the data hub  106  may compare the destination identifier received in the data request with the stored destination identifiers included in the routing table  200 . In one example embodiment of the invention, the DHP A  104   a  (data source) may send a data request to the data hub  106 , destined for the client A  102   a  (intended destination) that has  003  as the destination ID. Thereafter, the routing module  116  may determine the intended destination by comparing the received destination identifier (i.e.,  003  in this case) and the stored destination identifiers included in the routing table  200 . According to an aspect of the invention, if a match is found, then the destination associated with the matched destination identifier may be determined as the intended destination. Thus, the routing module  116  may route the command present in the data request to the intended destination. 
     Although the above example embodiment considers the client as the intended destination and the DHP as the data source, any module of software component of a data hub system or a remote data hub system may be a data source or an intended destination as desired in various embodiments of the invention. Additionally, in accordance with an aspect of the invention, the routing table  200  may include identifiers for modules within the computer  108  and/or for modules situated remotely to the computer  108 , for example, modules associated with the remote computer  118 . In this regard, communication between a data source and a destination may be facilitated regardless of the location of the destination. There is no requirement that the data source identify a destination as a remote destination. Provided that the destination is identified by its unique ID, the data hub  106  will route the command. Thus, the routing of commands may be facilitated across multiple platforms. In certain embodiments of the invention, more than one routing table may be utilized as desired. 
       FIG. 3  is a depiction of one example transport packet  300  that may be communicated through a data hub, such as the data hub  106  illustrated in  FIG. 1 , in accordance with various embodiments of the invention. As described earlier, a data source may communicate a command, such as a request for data to one or more intended destinations by sending the command to the data hub  106 . In various embodiments of the invention, the command may include a data packet similar to the transport packet  300  illustrated in  FIG. 3 . The transport packet  300  may include one or more destination identifiers  302  that represent respective unique Identifiers (IDs) of one or more destinations to whom the transport packet  300  is to be sent, a source identifier  304  that represents a unique ID of the data source that originates the sending of the transport packet  300 , a command identifier (or a sequence ID)  306  that identifies a command  308  that is to be sent in the transport packet  300  and is to be executed, and a payload or data  310  associated with the command  308 . The data  310  may be a generic data structure in accordance with various embodiments of the invention. 
     In accordance with an example embodiment of the invention, a data hub, such as the data hub  106  shown in  FIG. 1 , may receive the transport packet  300  from the data source, and the data hub  106  may determine the one or more intended destinations by comparing the one or more destination identifiers  302  received in the transport packet  300  with stored destination identifiers in one or more routing tables, such as the routing table  200  shown in  FIG. 2 . In case a match for the destination identifier  302  is found in a stored list of destination identifiers, the data hub  106  may route the transport packet  300  to a destination associated with the matched destination identifier  302 . 
     In an embodiment of the invention, the data hub  106  may use data normalization concepts to format the data originating from a DHP or client into a homogeneous format. Data normalization may help to reduce and eliminate data redundancy. According to an aspect of the invention, a command set may be defined and supported by the data hub  106 . In one embodiment of the invention, the command set may provide commands to facilitate finding and managing DHPs and/or clients connected to the data hub  106 . The command set may refer to a list or series of commands such as, but not limited to, getting data, setting data and updating data. 
     According to an aspect of the invention, a command passed in an electronic communication from a data source to an intended destination (through the data hub  106 ) may be a part of the command set defined and supported by the data hub  106 . According to another aspect of the invention, information associated with the command set may be stored in one or more memory location(s) accessible by a destination interface module associated with the intended destination. In an example embodiment of the invention, if a DHP, such as the DHP  104   a,  is an intended destination, an interface at the DHP, such as the DHP interface  114   a,  may access the memory location(s) to identify the command passed in the electronic communication. Further, each DHP and/or client may support one or more command sets, in accordance with various embodiments of the invention. 
     Standardizing the command sets may facilitate interaction between the DHPs and/or clients in a relatively expected and standardized manner. Thus, the data hub  106 , which communicates point-to-point data, may pull data from any of these sources (i.e., DHPs) and communicate with them because the interfaces are normalized. In a conventional system, different hardware devices in a computer system often have different communication interfaces. In accordance with an embodiment of the invention, a command set may be created to normalize data from all of the hardware devices and/or software components having different communication interfaces. The command set normalizes data so that the components in the computer system can communicate with components with different interfaces. Moreover, the creation of the command set allows for high speed routing of data between the data source and the destination via the data hub. 
     Various embodiments of the invention enable protocol compatibility between various DHPs and/or clients. Although the DHPs and/or clients may typically utilize different communication protocols, communications may be facilitated between various DHPs and/or clients using a data hub system  100  as described earlier in conjunction with the  FIG. 1 . The DHP interfaces, client interfaces, and data hub may facilitate the standardization of commands and, therefore, communication between various devices and/or software components even in the event that different protocols may typically be utilized by the various devices and/or software components. 
     Different types of data sources (for example, DHPs) may be used as desired for data communications that are routed through a data hub, such as the data hub  106 . Each of these data sources may have some functionality layered on top of them to facilitate the data communication. In an embodiment of the invention, the communication layer that is utilized may be abstracted so that the data sources may be replaced without affecting existing modules in a system where data communication occurs. According to an aspect of the invention, data in a data packet sent from a data source to an intended destination via the data hub, may include information such as, but not limited to, command set data and generic data. A transport mechanism may be used to assemble the command set and generic data into the data packet and provide a way to move data from one point to another. In accordance with an embodiment of the invention, a communication link may exist between each client and the data hub  106 , and between each DHP and the data hub  106 . The data hub  106  may then manage the routing and/or transportation of data from one point to another. 
     In an example embodiment of the invention, a DHP, such as DHP  104   a,  may send a command, such as, a connect command, to the data hub  106 . In accordance with an embodiment of the invention, the connect command establishes connection with the data hub  106  using a randomly generated universally unique identifier (UUID) as the key to the routing table  200 . In an example embodiment of the invention, a client, such as the client  102   a  may send a connect command with the randomly generated UUID to the data hub  106 . In accordance with another embodiment of the invention, the connect command establishes connection with the data hub  106  using a provided UUID as the key to the routing table  200 . In an example embodiment of the invention, a client, such as the client  102   a  and/or a DHP, such as the DHP  104   a,  may send a connect command with the provided UUID to the data hub  106  so as to register with the data hub  106  with their respective unique IDs. In accordance with yet another embodiment of the invention, the connect command establishes connection with the data hub  106  using an entity ID of the module as the key to the routing table  200 . As described earlier in conjunction with  FIG. 2 , the entity IDs may be stored source/destination identifiers, for example,  001  may be a destination ID of a client A,  002  may be a source ID of a DHP A and so on. In an example embodiment of the invention, a DHP, such as the DHP  104   a,  may send a connect command with its entity ID to the data hub  106  so as to register with the data hub  106  with the DHP  104 &#39;s entity ID. In an embodiment of the invention, the entity ID may be specified in the command set. 
     Further, for each command, an ID of the source is assigned and sent to the destination. According to an aspect of the invention, the data hub  106  may check for one or more destinations of a message that received at the data hub  106 , and then the data hub  106  may route the received message. However, the data hub  106  may not need to check the source end from where the message arrives. Once an intended destination, such as a DHP, receives the message from the data hub  106 , the received message may be checked for an included command. 
     In one embodiment of the invention, a command set library may be accessible by each DHP and/or client in the computer system  108 . This command set library may include command set implementation information associated with various commands. In this regard, a specification of command sets may be provided and followed in order to facilitate the sending and/or receiving of data from clients and/or DHPs. Further, in accordance with one embodiment of the invention, a rule may be built in the data hub to validate all DHPs so as to ensure that every DHP works correctly when they are plugged in the computer system. In an example embodiment of the invention, a DHP, such as the DHP  104   b,  may register using a unique entity ID ‘X’ with a data hub, such as the data hub  106 , before initiating data exchange with the data hub  106 . Thus, when the data hub  106  receives data request from the entity ID ‘X’, the data hub  106  recognizes that a sender of the data request is already registered and hence validates the sender. 
     In an embodiment of the invention, as a part of data normalization the data hub architecture may utilize data models, which include distinct information associated with various commands that can be performed, routed, and/or processed. The command set may specify the actions that may be performed and the data models may be utilized to store data that is associated with processing a command and with the data returned from the processing. 
     Further, as a part of data normalization, a proxy component connected to the data hub may perform serialization and/or de-serialization of data exchanged between the data source and one or more intended destinations. Serialization refers to a process of converting an object into a stream of bytes. In order to move data models through the data hub, the data models may be serialized. In this regard, the data hub may route a byte stream as a communication packet, including a command and the payload associated with a command. Serialization may also facilitate cross platform interoperability. For example, data may originate from a DHP in C++ format, and be routed to a .NET client. Further, using each data model, the proxy component may break down the data to a byte stream and then de-serialize from that stream. 
       FIG. 4  is a flowchart illustrating one example method  400  for routing data through a data hub, such as data hub  106 , according to an illustrative embodiment of the invention. According to various embodiments of the invention, data is routed through the data hub at high speed. 
     The method  400  may begin at block  405 , in which a data hub  160  may receive an electronic communication or data from a data source. The data source may be a client or a DHP. In accordance with an embodiment of the invention, the data source may communicate a command, such as a request for data from one or more intended destination(s), to the data hub  106 . The command may be included in a transport or data packet, in accordance with various embodiments of the invention. The transport packet, such as transport packet  300  illustrated in  FIG. 3 , may include a destination identifier that represents a unique ID of a destination to which the transport packet is to be sent, a source identifier that represents a unique ID of the data source that originates the sending of the transport packet, a command identifier (or a sequence ID) that describes a command that is sent in the transport packet and is to be executed, and a payload or data associated with the command. In an embodiment of the invention, if there are multiple intended destinations, then there will be multiple destination identifiers associated with each of these destinations. The electronic communication may be either within a single computer or between multiple computers located remotely. 
     Block  405  may be followed by block  410 , in which the data hub  106  may determine one or more destinations for the electronic communication received from the data source. The data hub may use one or more routing tables stored in association with the data hub  106  to determine the intended destination(s). The routing table may include information associated with modules, such as DHPs and/or clients that are in communication with the data hub  106  and may also include entity IDs that may be unique for each of these modules. Upon receiving the electronic communication from the data source, the data hub  106  may compare the destination identifier(s) received in the electronic communication with the destination identifiers (i.e., entity IDs) stored in the routing table. In one example embodiment of the invention, a DHP A (data source) may send a data request, destined for a client A (intended destination), with  001  as the destination ID to the data hub  106 . The data hub may determine the intended destination by comparing the received destination identifier (i.e.,  001  in this case) and the stored destination identifiers (for example,  001  and  002 ) associated with modules in communication with the data hub  106 . 
     Block  410  may be followed by decision block  415 , in which the data hub  106  may check whether the destination ID in the received electronic communication is present in the destination IDs stored in the one or more routing tables. This allows the data hub to validate the one or more destination module(s). 
     In the event the destination ID in the received electronic communication is found in the destination IDs stored in the one or more routing table at block  415 , then operation may continue at block  420 . At block  420 , the data hub  106  may validate the intended destination(s), and may route the electronic communication or a command present in the electronic communication to the intended destination(s). According to an aspect of the invention, the data hub  106  may route the electronic communication, received from the data source, to the intended destination(s) in a one-to-one manner. 
     Alternatively, in the event the destination ID in the received electronic communication is not found in the destination IDs stored in the one or more routing table at block  415 , then operation may continue at block  425 . At block  425 , the data hub  106  may send an error message to the data source indicating that the electronic communication could not be routed. In an embodiment of the invention, the error message may indicate that the destination ID specified in the electronic communication (by the data source) is incorrect. In an example embodiment of the invention, the data source may re-send the electronic communication following the receipt of an error message. In accordance with one embodiment of the invention, the process of re-sending the electronic communication may be repeated until the data source receives a response command (from the data hub) with the sequence ID that is same as the sequence ID sent earlier by the data source in the electronic communication to the data hub. 
     Further, when the destination receives the command from the data hub  106 , the destination may process the command. In an example embodiment of the invention, the destination may send a response command back to the data source through the data hub. In this example, the sequence ID may be the same as that received by the destination in the command routed to the destination by the data hub  106 . For example, in one embodiment of the invention, the destination may receive data requests three times in a row by the same or different data sources via the data hub  106 . In this example, sequence IDs may be defined for each of these data requests. Thus, the destination can respond for each of the data request to the data source via the data hub with the sequence IDs specified in the response commands. These sequence IDs may be the same as that received at the destination during the three data requests from the data hub. 
     The operations of the method  400  shown in  FIG. 4  may end following block  420  or block  425 . 
     The operations described in the method  400  of  FIG. 4  do not necessarily have to be performed in the order set forth in  FIG. 4 , but instead may be performed in any suitable order. Additionally, in certain embodiments of the invention, more or less than all of the elements or operations set forth in  FIG. 4  may be performed. 
     Embodiments of the invention may facilitate communicating data through the data hub without changing any of the command sets on the data hub. Moreover, data may be communicated such that it can be expanded and different data types may be communicated as desired in various embodiments of the invention. 
     In various embodiments of the invention, a wide variety of different data types and/or combinations of data types may be communicated through a data hub  106 . In an example embodiment of the invention, a generic data structure may be utilized to facilitate the communication or routing of data between a data source and one or more intended destinations. The generic data structure may facilitate the inclusion of any number of data types in the generic data structure in a manner that facilitates the relatively high speed routing of the included data.  FIG. 5  is a depiction of one example generic data structure  500  that may be communicated through a data hub  106  in accordance with various embodiments of the invention. According to an aspect of the invention, data associated with a command, which is passed as an electronic communication from a data source to an intended destination (through the data hub), may include a data object. In certain embodiments of the invention, the data object may be a generic data structure  500  that stores any number of different data types as desired. The generic data structure  500  may be stored in any suitable memory device or any suitable memory location within a computer. Additionally, the generic data structure  500  may be a data model that organizes data in a manner that facilitates its relatively high speed communication. The generic data structure  500  may include a first integer data array  505  that includes one or more integers that define respective type IDs to identify the types of data included in the generic data structure. Additionally, the generic data structure  500  may include a second data array  510  that includes the data itself. The data may be an array of data values  510 , according to an aspect of the invention. According to an aspect of the invention, any type of data may be included in the generic data structure  500  as desired in various embodiments of the invention. Example data types may include standard data types, such as, integers, booleans, floating point numbers, strings, etc. Example data types may also include more complex data types, such as user defined arrays, user defined records, etc. 
     For example, as shown in the  FIG. 5 , in one generic data structure, data values, such as 04, 40, 55, 80, 12, 2008, 4 and 17 may be included as data in the data array  510  of a generic data structure  500  that may be routed through the data hub  106 . Moreover, the data values may be of the same native type or of different native types. For data parameters associated with a day, minute, second, millisecond, month, year, day of week and hour, the data types associated with the parameters may be any suitable data type that facilitates the storage of the corresponding data values in the data array  510 . Each of the types of data may be identified by an integer value associated with the data type. For example, each of the data parameters may be an integer. In this example, an integer value associated with an integer data type would be included in the data type array  505  of the generic data structure  500 . For example, as shown in  FIG. 5 , the data type array  505  includes values of “01” for each data type, and the “01” may represent an integer data type. In another example, other data types may be included in the generic data structure  500 . For example, the day of the week data type may be a string data type (e.g., “Monday,” “Tuesday,” “Wednesday,” etc.). In this example, the data type array  510  of the generic data structure  500  may include an integer value associated with a string data type in the cell or block of the data type array associated with the day of the week. For example, the integer “03” may be utilized to represent a string data type, and the integer “03” may be included in the data type array  510  to identify the day of the week parameter as a string. As discussed above, any number of data types may be included in a generic data structure  500  as desired in various embodiments of the invention, and each of the various data types may be identified by a respective integer value associated with a data type. Additionally, any number of digits may be utilized in the integers stored in the data type array  505  as desired in various embodiments of the invention. 
     The data within a generic data structure  500  may be communicated between various modules (for example, a client or a DHP) through a data hub, for example, data hub  106 . In an example embodiment of the invention, the generic data structure  500  may pass configuration information, historical data, current data, alarm statuses, request parameters etc. The generic data structure  500  may facilitate the inclusion of any amount of data in a data payload. In this regard, the amount of data that is included may be scalable or expandable as desired. Furthermore, the data type array  505  of the generic data structure may facilitate the identification of the data that is included in the generic data structure  500 . In this regard, the generic data structure  500  may be self-describing. An intended destination or other recipient of the generic data structure  500  may utilize the data type array  505  to identify the data types that are included in the generic data structure  500  and, accordingly, the number of bytes allocated to each item of data included in the generic data structure  500 . In this regard, the generic data structure  500  may be routed to a destination as a serialized data stream and easily separated out into its various components after it is received. 
     In one embodiment of the invention, the generic data structure  500  may be utilized to enable communication. The generic data structure  500  may also facilitate generic functions that may be utilized within a computer system. The generic functions may include a single command and any amount of data associated with the command. For example, the data hub  106  may communicate the example generic structure  500  to an intended destination that will process a command associated with the generic data structure  500 . An example of the generic data structure may be as follows: 
                                            GenericDataStructure           {            INT[ ] DataParameterType;            OBJECT[ ] DataValue;           }                        
Where, DataParameterType specifies what the corresponding DataValue represents and the OBJECT type represents a generic type that may hold any native or complex data type.
 
Following is an example pseudo code for using the GenericDataStructure:
 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 stTimeStructure 
               
               
                   
                 { 
               
               
                   
                  int Millisecond; 
               
               
                   
                  int Second; 
               
               
                   
                  int Minute; 
               
               
                   
                  int Hour; 
               
               
                   
                  int Day; 
               
               
                   
                  int DayOfWeek; 
               
               
                   
                  int Month; 
               
               
                   
                  int Year; 
               
               
                   
                 } 
               
               
                   
                 100 - TYPE_MILLISECOND 
               
               
                   
                 101 - TYPE _SECOND 
               
               
                   
                 102 - TYPE_MINUTE 
               
               
                   
                 103 - TYPE_HOUR 
               
               
                   
                 104 - TYPE_DAY 
               
               
                   
                 105 - TYPE_DAY_OF_WEEK 
               
               
                   
                 106 - TYPE_MONTH 
               
               
                   
                 107 - TYPE_YEAR 
               
               
                   
                 1:26:34.324PM June 15, 2007 
               
               
                   
                 stTimeStructure object; 
               
               
                   
                 object.Millisecond = 324; 
               
               
                   
                 object.Second = 34; 
               
               
                   
                 object.Minute = 26; 
               
               
                   
                 object.Hour = 13; 
               
               
                   
                 object.Day = 15; 
               
               
                   
                 object.DayOfWeek = 5; 
               
               
                   
                 object.Month = 6; 
               
               
                   
                 object.Year = 2007; 
               
               
                   
                 SetTime (stTimeStructure); 
               
               
                   
                 GenericDataStructure object; 
               
               
                   
                 object.DataParameterType = new INT[8]; 
               
               
                   
                 object.DataValue = new OBJECT[8]; 
               
               
                   
                 object.DataParameterType[0] = TYPE_MILLISECOND; 
               
               
                   
                 object.DataParameterType[1] = TYPE_SECOND; 
               
               
                   
                 object.DataParameterType[2] = TYPE_MINUTE; 
               
               
                   
                 object.DataParameterType[3] = TYPE_HOUR; 
               
               
                   
                 object.DataParameterType[4] = TYPE_DAY; 
               
               
                   
                 object.DataParameterType[5] = TYPE_DAY_OF_WEEK; 
               
               
                   
                 object.DataParameterType[6] = TYPE_MONTH; 
               
               
                   
                 object.DataParameterType[7] = TYPE_YEAR; 
               
               
                   
                 object.DataValue[0] = (INT)324; 
               
               
                   
                 object.DataValue[1] = (INT)34; 
               
               
                   
                 object.DataValue[2] = (INT)26; 
               
               
                   
                 object.DataValue[3] = (INT)13; 
               
               
                   
                 object.DataValue[4] = (INT)15; 
               
               
                   
                 object.DataValue[5] = (INT)5; 
               
               
                   
                 object.DataValue[6] = (INT)6; 
               
               
                   
                 object.DataValue[7] = (INT)2007; 
               
               
                   
                 SetTime(GenericDataStructure); 
               
               
                   
                   
               
            
           
         
       
     
     In the above example of GenericDataStructure, a SetTime command may be utilized to return a generic data structure including a requested time. The command and associated data may be returned to a requesting module in response to a command that requests the data, for example, a GetTime command. In this example, a destination may return 1:26:34.324 PM June 15, 2007 as a response to a requesting module. The data values included in the returned generic data structure may include 324, 34, 26, 13, 15, 5, 6 and 2007 and their corresponding types include millisecond, second, minute, hour, day of week, month and year, respectively. The data type array of the generic data structure may include integer values of, 100, 101, 102, 103, 104, 105, 106 and 107 as identifiers of the various data types. The integers provided in this example may be specific to the various data types as opposed to utilizing a common data type for all integer values of data, as set forth in the example described above with reference to  FIG. 5 . Both approaches, a combination of the approaches, or other approaches may be utilized as desired in example generic data structures. 
     In accordance with an aspect of the invention, functions may become generic as the associated generic data structures are self-describing. Instead of using several functions to facilitate data commands, a single function may be used where the data sent and received is self-describing. The generic data structure may even handle complex data, in accordance with various embodiments of the invention. An example of handling of complex data using the generic data structure may be as follows: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 Object.DataParameterType = new int[8]; 
               
               
                 Object.DataParameterType[0] = TYPE_DATA_TYPE; 
               
               
                 Object.DataParameterType[1] = TYPE_2D_ARRAY_OF_TIMESTAMPS; 
               
               
                 Object.DataParameterType[2] = TYPE_ARRAY_OF_NODE_IDS; 
               
               
                 Object.DataParameterType[3] = TYPE_2D_ARRAY_OF_MODE_VALUES; 
               
               
                 Object.DataParameterType[4] = TYPE_2D_ARRAY_OF_DATA_STATUS; 
               
               
                 Object.DataParameterType[5] = TYPE_2D_ARRAY_OF_WAVEFORM_VALUES; 
               
               
                 Object.DataParameterType[6] = TYPE_2D_ARRAY_OF_RPM; 
               
               
                 Object.DataParameterType[7] = TYPE_2D_ARRAY_OF_KPH_HIT_INDICES; 
               
               
                 Object.Data = new Object[8]; 
               
               
                 Object.DataValue[0] = (ENUM)DYNAMIC_DATA; 
               
               
                 Object.DataValue[1] = new (DATE[ ])[n]; (2D Array of Timestamps) 
               
               
                 Object.DataValue[1][0] = new Date[x]; (Array of Timestamps for 200) 
               
               
                 Object.DataValue[1][0][0] = (DATE)Now; 
               
               
                 Object.DataValue[1][0][1] = (DATE)Now−5; 
               
               
                 Object.DataValue[1][0][x] = (Date)Now − 1; 
               
               
                 Object.DataValue[1][1] = new Date[y]; (Array of Timestamps for 201) 
               
               
                 Object.DataValue[1][1][0] = (DATE)Now; 
               
               
                 Object.DataValue[1][1][1] = (DATE)Now−5; 
               
               
                 Object.DataValue[1][1][y] = (Date)Now − 1; 
               
               
                 Object.DataValue[1][n] = new Date[z]; (Array of Timestamps for 202) 
               
               
                 Object.DataValue[1][n][0] = (DATE)Now; 
               
               
                 Object.DataValue[1][n][1] = (DATE)Now−5; 
               
               
                 Object.DataValue[1][n][z] = (Date)Now − 1; 
               
               
                 Object.DataValue[2] = new Int[n]; (Array of Node Ids) 
               
               
                 Object.DataValue[2][0] = (int)200; 
               
               
                 Object.DataValue[2][1] = (int)201; 
               
               
                 Object.DataValue[2][n] = (int)202; 
               
               
                 Object.DataValue[3] = new (Int32[ ])[n]; (2D Array of Mode Values) 
               
               
                 Object.DataValue[3][0] = new Int32[x]; (Array of Mode Values for 200) 
               
               
                 Object.DataValue[3][0][0] = (int)8; (Mode 8 =Synchronous) 
               
               
                 Object.DataValue[3][0][1] = (int)8; (Mode 8 = Synchronous) 
               
               
                 Object.DataValue[3][0][x] = (int)0; (Mode 0 =TimeBased) 
               
               
                 Object.DataValue[3][1] = new Int32[y]; (Array of Mode Values for 201) 
               
               
                 Object.DataValue[3][1][0] = (int)8; (Mode 8 =Synchronous) 
               
               
                 Object.DataValue[3][1][1] = (int)8; (Mode 8 = Synchronous) 
               
               
                 Object.DataValue[3][1][y] = (int)0; (Mode 0 =TimeBased) 
               
               
                 Object.DataValue[3][n] = new Int32[z]; (Array of Mode Values for 202) 
               
               
                 Object.DataValue[3][n][0] = (int)8; (Mode 8 =Synchronous) 
               
               
                 Object.DataValue[3][n][1] = (int)8; (Mode 8 = Synchronous) 
               
               
                 Object.DataValue[3][n][z] = (int)0; (Mode 0 =TimeBased) 
               
               
                 Object.DataValue[4] = new (Int32[ ])[n]; (2D Array of Data Status) 
               
               
                 Object.DataValue[4][0] = new Int32[x]; (Array of Data Statuses for 200) 
               
               
                 Object.DataValue[4][0][0] = (int32)OK; (Status Data for 200) 
               
               
                 Object.DataValue[4][0][1] = (int32)NOT_OK; (Status Data for 200) 
               
               
                 Object.DataValue[4][0][x] = (int32)OK; (Status Data for 200) 
               
               
                 Object.DataValue[4][1] = new Int32[y]; (Array of Data Statuses for 201) 
               
               
                 Object.DataValue[4][1][0] = (int32)OK; (Status Data for 201) 
               
               
                 Object.DataValue[4][1][1] = (int32)NOT_OK; (Status Data for 201) 
               
               
                 Object.DataValue[4][1][y] = (int32)OK; (Status Data for 201) 
               
               
                 Object.DataValue[4][n] = new Int32[z]; (Array of Data Statuses for 202) 
               
               
                 Object.DataValue[4][n][0] = (int32)OK; (Status Data for 200) 
               
               
                 Object.DataValue[4][n][1] = (int32)NOT_OK; (Status Data for 200) 
               
               
                 Object.DataValue[4][n][z] = (int32)OK; (Status Data for 200) 
               
               
                 Object.DataValue[5] = new (Int32[ ][ ])[n]; (3D Array of Samples) 
               
               
                 Object.DataValue[5][0] = new (Int32[ ])[x]; (2D Array of Samples for 200) 
               
               
                 Object.DataValue[5][0][0] = new Int32[1024]; (Array of wf Samples at Timestamp 1) 
               
               
                 Object.DataValue[5][0][0][0] = (int32){Sample 1 value for 200 at Timestamp 1} 
               
               
                 Object.DataValue[5][0][0][1] = (int32){Sample 2 value for 200 at Timestamp 1} 
               
               
                 ....... 
               
               
                 Object.DataValue[6] = new (Float[ ][ ])[n]; (3D Array of RPMs) 
               
               
                 ..... 
               
               
                 Object.DataValue[7] = new (Int32[ ][ ])[n]; (3D Array of KPH Hit Indices) 
               
               
                   
               
            
           
         
       
     
     In the above example of a GenericDataStructure, eight integer values may be included in a data type array that define the data included in the generic data structure. Each of the defined data types may be an array that is stored in the data value array of the generic data structure. These arrays may be either single dimensional, two dimensional or three dimensional arrays. Moreover, data values may be defined for the cells of each of the various arrays stored in the data value array of the generic data structure. 
       FIG. 6  is a flowchart of one example method  600  for forming a generic data structure, according to an illustrative embodiment of the invention. The method  600  may begin at block  605 , in which the data types to be included in a generic data structure may be determined or otherwise identified. In an example embodiment of the invention, the data types may be hour, minute, second and millisecond. 
     Block  605  may be followed by block  610 , in which a definitional array for the generic data structure may be generated. The definitional array, also referred to as a data type array, may identify the types of data (or data values) that are included within the generic data structure. According to an aspect of the invention, each data value of the definitional array may be an integer value associated with a respective data type that is included within the generic data structure. The data values included in the returned generic data structure may include 324, 34, 26, 13, 15, 5, 6 and 2007 and their corresponding types include millisecond, second, minute, hour, day of week, month and year, respectively. The data type array of the generic data structure may include integer values of, 100, 101, 102, 103, 104, 105, 106 and 107 as identifiers of the various data types. 
     Block  610  may be followed by block  615 , in which a data array for the generic data structure may be generated. The data array may include data associated with each of the data types included in the generic data structure. In the example above with data types of hour, minute, second and millisecond, the generated data array may be an array of four data values. In an example embodiment of the invention, the data values for the corresponding hour, minute, second and millisecond may be 17, 45, 30 and 200. 
     The operations described in the method  600  of  FIG. 6  do not necessarily have to be performed in the order set forth in  FIG. 6 , but instead may be performed in any suitable order. Additionally, in certain embodiments of the invention, more or less than all of the elements or operations set forth in  FIG. 6  may be performed. 
     The data structures of the invention may facilitate relatively high speed transfer of data within a single computer and/or between multiple computers. Additionally, the data structures may be utilized in a data hub architecture that may provide data termination knowledge and may resolve issues with cross-protocol compatibility between different hardware devices. 
     The technical effect of the invention is that data structures may be provided that facilitate the communication of any amount of data between different modules, through a data hub, within a single computer or between multiple computers at a relatively high speed. 
     Embodiments of the invention are described above with reference to block diagrams and schematic illustrations of methods and systems according to embodiments of the invention. It will be understood that each block of the diagrams and combinations of blocks in the diagrams can be implemented by computer program instructions. These computer program instructions may be loaded onto one or more general purpose computers, special purpose computers, or other programmable data processing apparatus to produce machines, such that the instructions which execute on the computers or other programmable data processing apparatus create means for implementing the functions specified in the block or blocks. Such computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement the function specified in the block or blocks. 
     Certain embodiments of the invention are applicable for use with any device that communicates, transfers, or routes electronic data. Some examples of such devices include, but are not limited to, a network routing device within a computer, a software-based router within a computer, an enterprise service bus, other types of routers, a network switch, a server, etc. It will be apparent that any example taken provided in the foregoing specification is merely provided for explanation purposes and does not limit the scope of the invention by any means. 
     While the invention has been described in connection with what is presently considered to be the most practical and various embodiments, it is to be understood that the invention is not to be limited to the disclosed embodiments, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims. 
     This written description uses examples to disclose embodiments of the invention, including the best mode, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of embodiments of the invention is defined in the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal languages of the claims.