The present application relates generally to data architectures, in particular, the present application relates generally to a data bus architecture arrangement providing for systems for efficient inter-database data distribution.
In traditional system architectures, an operating system executes on computing hardware, and can host a particular database management system and database storage arrangement. For example, selected computer hardware having a particular system architecture (e.g., compliant with the x86, x86-64, IA64, PowerPC, ARM, or other system architectures) can host an operating system specifically written for or compiled for that architecture. That operating system (e.g., Windows, Linux, etc.) can then host a corresponding database and associated database management system.
Within this construct, various database architectures have emerged. For example, relational databases have been developed, in which data requests, such as queries, can be submitted in a relational query structure (e.g., using SQL or some similar language). Generally, data in such relational databases are stored in records, with interrelationships across table entries in one or more tables, with query results returned in terms of row and table references. In other examples, hierarchical databases have also been developed which store data in records, but generally query results are returned in record and set references. Still other database architectures are implemented using different access procedures, such as storage in columns, records, streams, or other structures.
Increasingly, a number of limitations of computing infrastructure have begun to affect these database arrangements. For example, some relational and hierarchical database management systems assume all data is to be stored on a particular partition or computing system, and as such are either unable to or are inefficient at obtaining data stored in separate memories or memory partitions. Furthermore, existing application level programs may be written for use with a relational system when data is stored in a hierarchical database, or vice versa, thereby complicating data access issues. In such situations, it may be the case that separate transactional and relational database instances must be maintained, leading to data consistency and replication difficulties. Or, hierarchical database commands must be translated to a relational database language, accounting for the difference between such data models. In both circumstances, inefficiencies exist in storage and retrieval of data, and limitations as to methods (i.e., database commands and query languages) persist. This issue is exacerbated by the fact that many organizations wish to maintain many different types of databases, for example transactional databases for managing sales or operational transactions, relational databases for maintaining company records, and multidimensional databases for analytics.
For these and other reasons, improvements are desirable.
In accordance with the following disclosure, the above and other issues are addressed by the following:
In a first aspect, a system for maintaining data across heterogeneous data storage environments is disclosed. The system includes a first database interface having a first data model type associated with a data storage environment storing first data. The system further includes a first agent capable of inspecting the data and data relationships within the data storage environment, wherein the first agent is configured to detect changes in the first data and in the data model. The system also includes a second agent associated with a second database interface having a second data model type and associated with a second data storage environment, the second data storage environment including a database storing second data, and wherein the second agent is configured to detect changes in the second data stored in the database and in the data model, wherein the first and second data models are different. The system further includes a partition executing on a computing system separate from the first database interface, first agent, or second agent, the partition including a data bus application executing thereon and configured to coordinate with the first and second agents to automatically maintain synchronization between the first and second data and maintain analogous first and second data models across the first and second data storage environments.
In a second aspect, a computer-implemented method for maintaining data among a plurality of heterogeneous data storage environments is disclosed. The method includes detecting, by a first agent, changes in data and in a data model of a first database interface, the first database interface associated with a data storage environment storing data and data relationships. The method further includes detecting, by a second agent, changes in data and in a second data model of a second database interface, the second database interface associated with a second data storage environment including a database and residing separate from the data storage environment, and wherein the first and second data models represent heterogeneous data models. The method also includes coordinating the first and second agents to automatically maintain synchronization between data in the data storage environment and data in the second data storage environment through a partition executing on a computing system separate from the first or second database management systems.
In a third aspect, a computer-readable storage medium comprising computer-executable instructions which, when executed by a computing system, cause the computing system to perform a method of maintaining data among a plurality of heterogeneous data storage environments is disclosed. The method includes detecting, by a first agent, changes in data and in a data model of a first database interface, the first database interface associated with a data storage environment storing data and data relationships. The method further includes detecting, by a second agent, changes in data and in a second data model of a second database interface, the second database interface associated with a second data storage environment including a database and residing separate from the data storage environment, and wherein the first and second data models represent heterogeneous data model. The method also includes coordinating the first and second agents to automatically maintain synchronization between data in the data storage environment and data in the second data storage environment through a partition executing on a computing system separate from the first or second database management systems.
Various embodiments of the present invention will be described in detail with reference to the drawings, wherein like reference numerals represent like parts and assemblies throughout the several views. Reference to various embodiments does not limit the scope of the invention, which is limited only by the scope of the claims attached hereto. Additionally, any examples set forth in this specification are not intended to be limiting and merely set forth some of the many possible embodiments for the claimed invention.
The logical operations of the various embodiments of the disclosure described herein are implemented as: (1) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a computer, and/or (2) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a directory system, database, or compiler.
In general, the present disclosure relates to database and data bus architectures. In particular, the present application relates generally to a data bus architecture arrangement providing for systems for efficient data distribution. The data bus architectures disclosed herein represent systems in which a unified, data model neutral data storage arrangement can be used as a data layer, with existing database management systems operating to provide different views into a unified, data model neutral data layer. In example embodiments, the data model neutral layer can maintain descriptions of the data models associated with each database interface to provide a definition that allows replication of data across different data models of different data model types. In other example embodiments, the data model neutral layer can maintain both descriptions of the data models associated with each database interface and a data model neutral data layer, thereby avoiding some replication of data but rather maintaining a single data model neutral set of data, upon which various views can be generated for each of a plurality of database interfaces having different data model types.
In particular, and as discussed below,
In general, and as discussed herein, a data model corresponds to a particular arrangement of data for use in a database. For example, the data model can correspond to a particular database structure or schema that is specific to the data stored in a database. Analogously, a data model type, as referred to herein, corresponds to a particular type of arrangement of data, whether it be a relational, hierarchical, multidimensional, object oriented, columnar, network, record, or stream arrangements for data, or any other data model type. Accordingly, data model neutral data corresponds to data that is not stored in a manner that relies upon a particular data structure, but rather can be described across a variety of such structures. Examples of each of these concepts are generally provided in further detail below in conjunction with the various embodiments of the present disclosure.
Referring now to
In the embodiment shown, the data storage system 100 includes a virtualization space 101 executable on a hardware layer 102. The hardware layer 102 supports secure partition services 104. The hardware layer 102 generally corresponds to a large, multiprocessor, networked arrangement including a plurality of computing systems. As further discussed below in connection with
The secure partition services 104 provides a low-level software layer above the hardware layer 102, and generally corresponds to a virtualization layer useable to host various types of operating systems that may or may not be compatible with the hardware layer 102. For example, the secure partition services 104 can correspond to a hypervisor software layer installed on one or more computing systems, capable of collectively partitioning available hardware resources available within a computing system into a plurality of partitions. As discussed below in connection with
In the embodiment shown, the secure partition services 104 host a set of architecture attributes 106 and a common data bus 108. The architecture attributes 106 reside in a layer above the secure partition services 104, in that they are published to various partitions 110 (shown as partitions 110a-d). In various embodiments, the architecture attributes 106 can include, for example, emulated processing, memory, networking and/or other attributes made available to the partitions 110.
The common data bus 108 hosts and supports data exchange across the plurality of partitions 110, to allow for cross-pollination of data between the partitions, for use by the operating systems and software installed thereon. In particular, the common data bus 108 stores metadata describing, for example, a particular file system and/or database structure or schema used in a particular partition, such that when data is stored or altered in that partition, the common data bus 108 detects the data change and replicates that change of data across the other partitions. In various embodiments, the common data bus 108 can be configured to detect changes in data in virtual file systems or virtual database files in the various partitions 110, and replicate data between those systems based on known interrelationships between those data structures. For example, the common data bus 108 can be implemented using one or more transforms developed between source and target computing system file systems and/or database systems, and includes the software necessary to support export of data from each partition (e.g., from the file system within a particular partition, or within a database having a schema hosted within the partition). Details regarding implementation of the common data bus 108 are provided in further detail in
In the embodiment shown, each of the partitions 110 supported by the secure partition services 104 and common data bus 108 are configured to support any of a variety of operating systems and/or database management systems and database architectures. In the example depicted, a first partition 110.a hosts a first operating system, depicted as an MCP operating system provided by Unisys Corporation of Blue Bell, Pa. Similarly, other partitions within the system may host different types of systems; in the embodiment shown, a second partition 110b hosts a second operating system, shown as the OS2200 operating system, also from Unisys Corporation of Blue Bell, Pa. A third operating system simply illustrated as a coprocessor, or “CP” is also illustrated as associated with a third partition 110c. Other partitions, such as partitions maintaining third party operating systems (e.g., Linux, Windows-based, or other operating systems) could be incorporated as welt.
Within each of the partitions 110a-c, each partition may include one or more data personalities 112. Data personalities 112 generally refer to structures or arrangements by which data is accessed and understood. For example, data personalities may correspond to a data model type of a database, such as a relational, hierarchical, multidimensional, columnar, network, record, stream or object oriented data model type. Data personalities generally describe the expected operation of an interface to data, rather than the specific structure of a given data set. Such a specific structure, or data model, corresponds to a particular schema of that data set as may be designed within the data model type.
In the example embodiment shown, the first partition 110a including the MCP operating system hosts two data personalities, a relational data personality 112a (such as would be expected of a SQL or other relational database) and a DMSII personality 112b, useable with DMSII database management system from Unisys Corporation of Blue Bell, Pa. Similarly, the second partition 110b is illustrated as supporting an RDMS personality 112c, a DMS personality 112d, and indexed files in a file system (i.e., a file-based data personality 112e).
In the arrangement shown, each of the partitions 110a-c can be made available to a further partition or application executing within one of those partitions, illustrated as a data access application 114. The application 114 can access one or more APIs 116, shown as traditional APIs 116a and third party APIs 116b for accessing data stored using nonstandard third party data personalities. The APIs 116 are published for use with each of the variety of data personalities 112, for accessing data in the various partitions. As such, the application can access data as needed from each of the various data personalities—e.g., in a relational format from a relational database personality such as personality 112a, or hierarchical data from a hierarchical database personality (e.g., the DMSII personality 112), or other data access arrangements.
Use of a common data bus 108 to provide data synchronization across partitions, in particular in an example arrangement such as that depicted in
As illustrated in system 100, a remote system 120, such as a client system or other remote server, can be communicatively connected to the virtual system 101, e.g., for communication with the application 114, or application development environment 118. For example, the application 114 or application development environment can have a web interface, either directly supported within one of the partitions in which the application or application development environment reside, or in a separate partition, managing access to that system.
It is noted that, as illustrated, other third party systems can be incorporated into the overall system 100. In the embodiment shown, one such third party system 122 can be included within the overall virtualized system 101, hosted by secure partitioning services 104, and a further third party system 124 is remote from the overall system 100, and communicatively connected to the system by the common data bus 108. These third party systems are shown to illustrate example interoperability of the common data bus 108 with third party systems. In connection with third party system 122, the common data bus 108 can be extended, on a case-by-case basis, to such third party systems by establishing a relationship between known data personalities of the supported systems and those developed by third parties. In the example shown, both third party systems 122, 124 operate third party operating systems 126, 128, respectively, and have specific third party data personalities 130, 132. These may be the same, or different, operating systems and/or data personalities. Further, as illustrated in
Although the system 100 of
In the particular embodiment shown, the common data store 202 is configured to provide an interface between each of a plurality of data personalities 112 and the underlying data by providing a conduit for data storage from each of the supported partitions 110. In the embodiment shown, the common data store 202 is interfaced to partitions 110a-c, and provides data to data personalities 112a-f. As such, data personalities 112a-f rather than representing database systems as in
The common data store 202 can be interfaced to a common data bus 204, which acts analogously to the common data bus 108 of
In the embodiment shown, it is noted that additional features can be incorporated in the common data store 202, in addition to those managed in the common data bus 204. For example, functionalities that are related to database functions but which are not part of a particular data model can entirely be managed within the common data store; for example, transaction management, recovery, backup, and other data functions can be managed within the common data store 202. Other functionalities typically associated with database management systems could be incorporated into a common data store as well.
It is noted that this overall systems depicted in
Referring now to
In general, each of the logical computing systems 302a-d hosts secure partition services 304, which define the set of physical computing resources available to higher-layer software, as well as providing an interface between that higher-layer software and the physical computing resources allocated to the particular logical computing system 302. Furthermore, the partition services 304 provide virtualization and security services, as well as backup and recovery services, for each partition.
In the embodiment shown, the arrangement 300 includes a control partition 306, guest partitions 308a-b, and a services partition 310. The control partition 406 schedules allocation of additional partitions to various guest processes as desired. For example, the control partition 306 can execute a console application configured to allow reservation of resources for various guest partitions and/or service partitions. The guest partitions 308a-b can execute any of a variety of guest applications. For example, the guest partitions 308a-b can host separate database management systems or data personalities on different hosted operating systems. Still further guest partitions (not shown) could host data storage partitions, or an implementation of the common data bus or common data store, a map-reduce service operation useable by the common data store, or other types of services discussed above. A services partition 310 hosts one or more services useable by the guest partitions, such as for remote systems communications, data management/replication, or other services.
When implementing a system such as that shown in
Referring now to
In the example of
The processing system 404 includes one or more processing units. A processing unit is a physical device or article of manufacture comprising one or more integrated circuits that selectively execute software instructions. In various embodiments, the processing system 404 is implemented in various ways. For example, the processing system 404 can be implemented as one or more processing cores. In another example, the processing system 404 can include one or more separate microprocessors. In yet another example embodiment, the processing system 404 can include an application-specific integrated circuit (ASIC) that provides specific functionality. In yet another example, the processing system 404 provides specific functionality by using an ASIC and by executing computer-executable instructions.
The secondary storage device 406 includes one or more computer storage media. The secondary storage device 406 stores data and software instructions not directly accessible by the processing system 404. In other words, the processing system 404 performs an I/O operation to retrieve data and/or software instructions from the secondary storage device 406. In various embodiments, the secondary storage device 406 includes various types of computer storage media. For example, the secondary storage device 406 can include one or more magnetic disks, magnetic tape drives, optical discs, solid state memory devices, and/or other types of computer storage media.
The network interface card 408 enables the computing device 400 to send data to and receive data from a communication network. In different embodiments, the network interface card 408 is implemented in different ways. For example, the network interface card 408 can be implemented as an Ethernet interface, a token-ring network interface, a fiber optic network interface, a wireless network interface (e.g., WiFi, WiMax, etc.), or another type of network interface.
The video interface 410 enables the computing device 400 to output video information to the display unit 412. The display unit 412 can be various types of devices for displaying video information, such as a cathode-ray tube display, an LCD display panel, a plasma screen display panel, a touch-sensitive display panel, an LED screen, or a projector. The video interface 410 can communicate with the display unit 412 in various ways, such as via a Universal Serial Bus (USB) connector, a VGA connector, a digital visual interface (DVI) connector, an S-Video connector, a High-Definition Multimedia Interface (HDMI) interface, or a DisplayPort connector.
The external component interface 414 enables the computing device 400 to communicate with external devices. For example, the external component interface 414 can be a USB interface, a FireWire interface, a serial port interface, a parallel port interface, a. PS/2 interface, and/or another type of interface that enables the computing device 400 to communicate with external devices. In various embodiments, the external component interface 414 enables the computing device 400 to communicate with various external components, such as external storage devices, input devices, speakers, modems, media player docks, other computing devices, scanners, digital cameras, and fingerprint readers.
The communications medium 416 facilitates communication among the hardware components of the computing device 400. In the example of
The memory 402 stores various types of data and/or software instructions. For instance, in the example of
Although particular features are discussed herein as included within an electronic computing device 400, it is recognized that in certain embodiments not all such components or features may be included within a computing device executing according to the methods and systems of the present disclosure. Furthermore, different types of hardware and/or software systems could be incorporated into such an electronic computing device.
In accordance with the present disclosure, the term computer readable media as used herein may include computer storage media and communication media. As used in this document, a computer storage medium is a device or article of manufacture that stores data and/or computer-executable instructions. Computer storage media may include volatile and nonvolatile, removable and non-removable devices or articles of manufacture implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. By way of example, and not limitation, computer storage media may include dynamic random access memory (DRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), reduced latency DRAM, DDR2 SDRAM, DDR3 SDRAM, solid state memory, read-only memory (ROM), electrically-erasable programmable ROM, optical discs (e.g., CD-ROMs, DVDs, etc.), magnetic disks (e.g., hard disks, floppy disks, etc.), magnetic tapes, and other types of devices and/or articles of manufacture that store data. However, such computer readable media, and in particular computer readable storage media, are generally implemented via systems that include at least some non-transitory storage of instructions and data that implements the subject matter disclosed herein.
Communication media may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term “modulated data signal” may describe a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.
Referring now to
In the embodiment shown, each of the database partitions 502a-c hosts one or more applications 510a-c, respectively, as well as an agent 512a-c and associated database 514a-c. Each of the applications 510a-c, agents 512a-c, and databases 514a-c can be hosted within an operating system. It is noted that, in varying embodiments, varying operating systems and associated databases 514a-c and/or applications 510a-c can be used. For example, one or more of the partitions 502a-c could include an OS2200 operating system, and a DMSII database system, while another of the internal partitions could use an MCP operating system and a DMSII database system. Alternatively, one of the internal partitions 502a-c could include a. Windows operating system and SQL Server database system, or a Linux operating system and associated Oracle or other third party database system. Applications useable to access data in the associated database system, and operable within the operating system associated with that database system, could be used as applications 510a-b as well. In still further embodiments, the databases 514a-c can correspond any data model type, such as relational, hierarchical, multidimensional, columnar, network, record, stream, or object oriented data model type.
The databases 514a-c provide, for example, a view on an underlying database, such as are provided by the various data personalities 112 of
In some embodiments, the agent 512 associated with each of the database interfaces is generally configured to (1) monitor that database interface for changed data or a changed database schema, and (2) initiate propagation of any such changes to other databases present within the overall system 500. In particular, the agents 512a-c are configured to determine a schema associated with the database 514 in the associated partition in which they reside, and capture changed data in that associated database. The agents 512a-c are further configured to persist changed data and/or schemas from other databases into the database with which they are associated. In some embodiments, the agents 512a-c can accomplish this task by monitoring transaction logs of the database with which they are associated. The agents 512a-c communicatively connect to the data bus partition 504, which provides definitions of transforms to be performed to ensure synchronization of data between databases having, for example, different data models, different data types, and different data.
In some embodiments each agent 512 is implemented such that it captures data by monitoring an audit log of the database with which it is associated. This allows the agent to minimize its performance impact on the database it is monitoring for changed data. In this case, the delay in replication of data from the database is constrained by the speed that the agent 512 reads and processes the audit entries.
The data bus partition 504 hosts a data bus application, including a data bus developer application 516a and a data bus runtime application 516b. The data bus developer application 516a includes a user interface portion configured to allow a user to define one or more transformations between selected source and target databases. As discussed in further detail below, the data bus developer application 516a is configured to generate one or more runtime modules that can be used to provide data transformations between two databases, including transformations of data structures and data types, as applicable. The data bus developer application 516a can, in some embodiments, generate modules including data bus runtime applications 516b, that can be used to perform transformations between database types. The data bus runtime application 516b is configured to provide such transformations, either on a one-to-one or one-to-many basis, among databases. In some embodiments, data bus runtime application 516b is generated by the data bus developer application 516a in the form of a DLL, JAR file, or other low-level executable file that can operate on data received at the data bus partition 504 from a particular source, and in particular from a specific, designated agent 512 associated with that source.
In some example embodiments, the data bus partition 504, and in particular the data bus runtime application 516b (after its generation by data bus developer application 516a), coordinates with a first agent at a source (e.g., agent 512a) associated with a database (e.g., database 514a), as well as a second agent (e.g., agent 512b) and associated database (e.g., database 514b) to automatically maintain synchronization between the data within each database and maintain analogous data models and data across the storage environments of the partitions 502a-b. The interconnection between the data bus partition 504 and the various agents 512a-c can take a variety of forms. In some embodiments, the interconnection is accomplished using the S-Par secure partitioning hypervisor and interconnect software previously incorporated by reference, which passes data between the agents and a corresponding ADO.NET software interface at the data bus partition.
It is noted further that, in operation, the data bus partition 504 must be able to propagate data changes in the order received, for example in the case of conflicting data changes. In such cases, a message queue 518 can be integrated at the data bus partition 504, for example as integrated with the data bus developer application 516a which can act as a supervisory application to the various data bus runtime applications 516b during operation of the data bus. The message queue 518 provides first-in, first-out message ordering, and can be implemented using, for example, a lightweight MQ for Unisys-based partitions implementing the data bus, or alternatively the MSMQ service if the data bus partition 602 is implemented using a Windows-based solution (e.g., in which the data bus runtime application 516b is implemented as one or more DLL files).
In some embodiments, the data bus developer application 516a allows a user to define schema mappings between source and target databases that will be propagated to a resulting data bus runtime application 516b generated by the developer application 516a. For example, definitions may include a source database table update that results in updates to multiple destinations (target databases). In such cases, the data bus runtime application 516b may be implemented as multiple separate DLL files.
To formulate the appropriate transformations, the data bus developer application 516a maintains a metadata repository of database schemas. The data bus developer application 516a includes its own metastore format, such as the CWM (Common Warehouse Metamodel) standard, and can also store schemas sourced from proprietary data managers (DMSII, RDMS 2200 and DMS 2200 from Unisys Corporation, or other data managers from third party database providers). The data bus developer application 516a loads schema definitions of particular databases from agents, such as agents 512, using any of a variety of protocols. For example, for an MCP-based database, a DASDL description file can be received at the metastore of the data bus developer application 516a, while in the case of an OS2200 database, a specific interface is developed to receive schema definitions from the UREP schema repository. Schema information from SQL Server and Oracle will be retrieved by the data bus developer application 516a using standard SQL interfaces.
Referring now to
In the embodiment shown, the data bus partition 602 includes a data bus application 612, which can, in some embodiments, correspond to the data bus developer application 516a of
It is noted that, in cases where data changes in both databases 606, 610, although multiple agents may not be required, it is recognized that multiple runtime services 612 may be used. For example, using the arrangement of
In addition, it is noted that various applications can be associated with the different databases 606, 610. In the embodiment shown, a first application 620 is associated with database 606, and a second application 622 is associated with database 610. These applications may be, in various embodiments, specifically configured to operate with the types of databases (and corresponding data models supported by those databases) that are provided at the different partitions 604, 608. For example, it is likely the case that, if databases 606, 610 support different data models, application 620 would be incompatible with database 610, and application 622 would be incompatible with database 606. This would at least mean that the applications would be configured to expect to receive data having a format different from the one that would be provided by that different database. However, by maintaining data across the databases 606, 610, either application could be used to query, analyze, and modify that same data, since the data would be maintained across those otherwise incompatible database types.
Referring now to
Referring now to
As compared to the process shown in
In particular the data replication process involves the agent 616, at the source database 606, detecting a change in the source database 606, for example by inspecting a transaction log associated with the source database. The agent 616 is constructed to transmit that changed data to a data bus runtime service 614 at the data bus partition 602. The data definition operation of
Referring now to
In this scenario, the database 610, and in particular change tables within the database, (e.g., a SQL Server and Oracle Change tables) will have been configured for capturing database updates. One or more monitor processes (e.g., the change data capture module 804) will interrogate the change tables for updates whereby the data bus runtime service 614 will apply the transformation(s) that have been defined for use of that data in the target database(s), such as database 606. It is noted that, as received, the transformed data will be posted to a message queue, as noted in
Referring now to
In embodiments where the data bus partition 602 is implemented in a Windows-based environment, the administration tool 1102 can be implemented using a WPF graphical user interface via a Windows Communication Foundation. In alternative embodiments, including those where non-Windows systems are used to implement the data bus partition 602, other types of implementations of user interfaces and message/status handling systems could be used.
In various embodiments, the administration tool 1102 is configured to control deployment of the data bus runtime services 614, and can transmit control messages (as illustrated) to the data bus runtime services, for example to control operation of those services. The administration tool 1102 can also communicate messages to the agents, such as agent 616. For example, in the embodiment shown, the administration tool 1102 directs a control message to the agent 616 via the data bus runtime service 614 associated with that agent. In alternative embodiments, the administration tool 1102 can directly communicate with the agent 616. For example, the administration tool 1102 can be configured to track last “known good” status of data bus runtime services 614 and agents 616, control deployment of the data bus runtime services 614 once the transformations and operations of each data bus runtime service 614 is defined in the data bus application 612.
Referring to
Referring now to
The method 1200 of
In the embodiment shown, the data bus partition can also detect a change in data in a second database interface (step 1204) located external to the first database. The database can detect a change in data, for example, by receiving a notification from an agent associated with the second database, or via another interface to that second database in the case that the second database is an external database, e.g. via a change data capture module 804. In response to a detected change in the data, the common data bus partition coordinates the first and second agents to automatically maintain synchronization between data (step 1206). This can be performed, for example, using the message queue 518 of
The example method 1300 of
The example method 1400 of
Referring to
The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.
Number | Date | Country | |
---|---|---|---|
61786966 | Mar 2013 | US |