Seamless importation of data

[0002] 1. Field of the Invention

[0003] The present invention relates to the importation of data from a source database to a target database. More particularly, the present invention relates to a data transfer interface for importing data from an existing information system having a source database to a new information system having a target database.

[0004] 2. The Background

[0005] Many companies, such as telephone companies and Internet Service Providers (ISPs), rely on subscriber management systems, such as those provided, for example, by Portal Software, Inc. of Cupertino, Calif., and Solect Technology Group of Toronto, Ontario, Canada. A subscriber management system enables companies to store and retrieve subscriber information, such as account type, personal information, password, and the like, when needed. Subscriber information is stored in one or more databases having a database schema and in a format compatible with one or more applications or components that use subscriber information. (A schema is the definition of an entire database).

[0006] The cost of entering and maintaining subscriber information in these systems is expensive, representing a sizable investment. Thus, many companies wishing to add a new component or system to their business enterprise often seek to leverage their subscriber information by integrating the new system with their subscriber management system. However, integrating new and old systems involves significant technical issues because the new system may use a database having a schema that differs from the existing database schema, data formats may be different, and there may be other differences as well.

[0007] Traditionally, companies have relied on systems integrators to resolve such compatibility issues but this increases integration costs, requires divulging sensitive subscriber information, business practices, and models to the systems integrators, affects the productivity of employees engaged in supporting the integration effort, and potentially compromises database security—all without any guarantee that the integration effort will be successful.

[0008] Consequently, a need exists for a uniform scheme for importing data from an existing system to a new system which decreases the cost of integrating a new system that uses the imported data, reduces the need to reveal information used in the existing system, reduces the need to access the exiting system's database, and avoids dependence on existing data formats.

[0009] A data transfer interface for importing data from a source system to a target system, including a source data adapter having an attribute definition transcriber for generating transcribed data, and a target data adapter having a data format converter for converting the transcribed data from a first format to a second format. The data transfer interface may include a data validator to ensure that the data selected for importation is valid before the data is transcribed. The source data adapter and the target data adapter may be configured for use with a communications architecture that allows the source data adapter and the target data adapter to receive and transmit user data as events on a data communications network.

[0010] FIG. 1 is a system block diagram of a data transfer interface for importing data from a source database to a target database in accordance with a presently preferred embodiment of the present invention.

[0011] FIG. 2 is a diagram of a storage format for data stored in a source location in accordance with a presently preferred embodiment of the present invention.

[0012] FIG. 3 is a diagram of an attribute definition in accordance with a presently preferred embodiment of the present invention.

[0013] FIG. 4 is a diagram of a storage format for data stored in a target location in accordance with a presently preferred embodiment of the present invention.

[0014] FIG. 5 is a flow diagram of a process for importing data from a source location to a target location in accordance with a presently preferred embodiment of the present invention.

[0015] In the following description, preferred embodiments of the invention are described with regard to preferred components, process steps, and data structures. Those skilled in the art will recognize, after a perusal of this application, that embodiments of the invention may be implemented using at least one general purpose computer operating under program control, and that modification of the general purpose computer to implement the components, process steps, and data structures described would not require undue invention.

[0016] In accordance with a presently preferred embodiment of the present invention, the components, process steps, and data structures may be implemented using C++ programs running on an Enterprise 2000 server™ running Sun Solaris™ as its operating system unless otherwise described. The Enterprise 2000 server™ and Sun Solaris™ operating system are available from Sun MicroSystems, Inc. of Mountain View, Calif. This implementation is not intended to be limiting in any way. Different implementations may be used and may include other types of operating systems, computing platforms, and/or computer programs. In addition, those of ordinary skill in the art will readily recognize that devices of a less general purpose nature, such as hardwired devices, devices relying on FPGA or ASIC technology, and the like, may also be used without departing from the scope and spirit of the inventive concepts disclosed.

[0017] FIG. 1 is a system block diagram of a data transfer interface 10 for importing data from a source location, such as source database 12, to a target location, such as target database 14. For the purposes of this application, a database is any electronically stored collection of data, such as a set of interrelated files created and managed by a DBMS (database management system). Those of ordinary skill in the art will readily appreciate that source database 12 has a database definition or schema suitable for use with the applications, protocols, and the like associated with a system, such as source system 16. Similarly, target database 14 has a database definition suitable for use in another system, such as target system 18.

[0018] Source system 16 may be a subscriber management system that holds system data, such as user data including a user's name, address, telephone number, account type, and the like, in source database 12. Target system 18 may include applications, protocols, and functions that require all or portions of the user data stored in source database 12 to be in a format that is more than likely different from the format defined by the schema of source database 12. For example, the user data stored in source database 12 may have a record structure that is different from the record structure used in target database 14. The record fields needed by target system 18 may also be in separate tables and/or in databases. Equivalent field content may also have different field labels, e.g., a field holding a user's first name may have a field name of “fname” or “first_name”. Equivalent field content expected by target system 18 may also be in more than one field, e.g., a user's name might be stored in source database 12 in two different fields, a field for the first name and a field for the last name. Equivalent field content may also have mismatched values. For example, an IP address value may be stored in numerical form, e.g., 111.222.333.444 in source system 16 but target system 18 may require the same IP address to be stored as a domain name in the form of a string, e.g., www.company.com, or vice versa.

[0019] Data transfer interface 10 includes a source data adapter 20 and a target data adapter 22, which use a communications architecture 24 to transfer data among themselves, source database 12, and target database 14. Communications architecture 24 includes a source-interface 26, a target interface 28, and an information broker 30 and operates by relaying events among clients over an intranet, the Internet, or equivalent data communications network 32 which may also be known by the term “information bus”. Clients transmit and/or receive events from information broker 30 and have subscribing and/or publishing elements. A client transmits data by using a publishing element to transmit the data as an event on data communications network 32, while a client receives data by using a subscribing element to receive the data as an event published on data communications network 32. Each event is defined according to an event type, which enables clients to distinguish between events by their event types. Each publishing element associated with a client and the type of events that are to be published by the client must be registered with information broker 30. Similarly, each publishing element associated with a client and the type of events that are to be received by the client must be registered with information broker 30.

[0020] Information broker 30 delivers published events to subscribing elements according to event type. For each event received, information broker 30 determines the event type of the received event and whether a subscribing element exists that is registered to receive events with that event type. If so, information broker 30 delivers the event to the subscribing element. Otherwise, information broker 30 drops the event and proceeds to process the next available event. For example, if a subscribing element is registered to receive an event of an event type “data transfer” (data transfer event) then that subscribing element will receive each data transfer event published to and received by information broker 30. In accordance with a presently preferred embodiment of the present invention, source data adapter 20, target data adapter 22, source interface 26, and target interface 28 are clients of information broker 30 and are registered (through their respective publishing and subscribing elements) with information broker 30.

[0021] Using the above approach provides the following advantages. First, the number of publishing elements and subscribing elements is easily scalable. Neither adding or deleting subscribing elements has an affect on publishing elements, nor does adding or deleting publishing elements have an affect on subscribing elements (unless, of course, no publishing element remains that transmits an event subscribed to and required by a subscribing element). For example, adding a new publishing element does not require modifying existing subscribing elements that subscribe to the events published by the new publishing element. Similarly, adding a new subscribing element to receive an existing event does not require updating the publishing element that publishes the existing event. Instead, the new publishing or subscribing element may be added simply by registering the event to be transmitted or received with an information broker. Second, because an information broker manages event delivery, an unavailable subscribing element will not delay a publishing element and will only receive events when the subscribing element can do so.

[0022] Communications architecture 24 may preferably be implemented using a Common Object Request Broker Architecture (CORBA)-based system and an Enterprise Application Integration (EAI) system, such as the Active Web product from Active Software of Santa Clara, Calif. Using the Active Web product is not intended to be limiting in any way. Other equivalent products or equivalent designs may be used to provide the functionality described.

[0023] Source interface 26 and target interface 28 are application interfaces that enable an application to transmit and/or receive data as an event on communications architecture 24. The application supported by source interface 26 is a DBMS 34 (database management system) managing source database 12, while the application supported by target interface 28 is a DBMS 36 managing target database 14. DBMS 34 and DBMS 36 correspond to source system 16 and target system 18, respectively. Source interface 26 translates user data, which is received by source interface 26 from a database trigger 38, into an event, enabling the transmission of the user data to a client that subscribes to that event.

[0024] Source interface 26 relies on database trigger 38, which is part of DBMS 34, to obtain user data held by source database 12 within a database record 40. The user data is stored in the form of a user record, which has a format and description defined by a source table 42. Database trigger 38 transmits the user record to source interface 26 each time a record location within source table 42 is populated or filled with user data. Populating a record location within source table 42 may be performed manually or by any means known by those of ordinary skill in the art.

[0025] Upon receiving the user record, source interface 26 transmits the user record to source data adapter 20. In accordance with a presently preferred embodiment of the present invention, source interface 26 transmits the user record by publishing the user record as an event having an event type that is the same as the event type that source data adapter 20 has registered to receive from information broker 30. For example, source interface 26 may transmit each user record as a data transfer event on communications architecture 24, while source data adapter 20 may receive each user record as a data transfer event. The use of a data transfer event type is not intended to be limiting in any way. Other event types may be used as long as the event type used by source interface 26 to publish the user record corresponds to the event type used by source data adapter 20 to receive the user record.

[0026] Upon receipt of the event containing the user record by source data adapter 20, source data adapter 20 preferably validates the contents of the user record. If source data adapter finds the contents of the user record valid, source data adapter 20 transcribes the contents and transmits the validated and transcribed user record to target data adapter 22. If source data adapter 20 does not find the contents valid, source data adapter 20 drops the user record, sends an alert message to an operator, and waits for another event containing a user record to process. These actions performed by source data adapter 20 are further discussed below.

[0027] Target interface 28 receives the user record processed by target data adapter 22. In accordance with a presently preferred embodiment of the present invention, target interface 28 receives the user record as an event that has the same event type as the events published by target data adapter 22. Upon receipt of each event, target interface 28 strips the user record from the event and provides it to DBMS 36 by using a language or protocol compatible with DBMS 36, such as SQL (structured query language). Target interface 28 and target data adapter 22 are further discussed below.

[0028] Source interface 26 and target interface 28 are implemented using the dbAdapter product from Active Software. The dbAdapter product is compatible with a variety of popular database products from Informix Corporation of Menlo Park, Calif.; Oracle Corporation of Redwood Shores, Calif.; Microsoft Corporation of Redmond, Wash.; IBM of Poughkeepsie, N.Y.; and Sybase Corporation, of Emeryville, Calif. The dbAdapter product may be installed on source system 16 if source system 16 supports a UNIX or Windows NT® operating system. If source system 16 does not support either operating system, the dbAdapter product may be installed on a separate platform (not shown) running UNIX or Windows NT® with the platform coupled via a network to the platform running the database. Other applications operating on other operating systems are also within the scope of the present invention.

[0029] Database trigger 38 is triggered by DBMS 34 on the direction of source interface 26. Once triggered, database trigger 38 monitors source table 42 so that each time data corresponding to a user is stored in a record within source table 42, database trigger 38 transmits the user record to source interface 26. Database trigger 38 may be implemented using a stored procedure in a database DBMS, such as those available from the companies listed above.

[0030] As shown in FIG. 2, source table 42 has a storage format that includes at least one “row” 44 having at least one keyword “column” 46 and at least one attribute definition column 48. Each row in source table 42 provides a memory location or record for holding data corresponding to a user according to the format defined by the columns. Each “intersection” of a row 44 and a keyword column provides a memory location for holding a keyword value, such as keyword values 50(1), 50(2), 50(3), and 50(n) and a corresponding field name, such as field names 52(1), 52(2), 52(3), and 52(n). Similarly, attribute definition column 48 provides a memory location for holding a variable number of attribute definitions for each row 44, such as attribute definitions 54(1) through 54(n), with each attribute definition separated by a delimiter 55, such as a semicolon or equivalent delimiter.

[0031] As shown in FIG. 3, in accordance with a presently preferred embodiment of the present invention, each attribute definition, such as attribute definition 54(1), includes four attribute definition locations that each holds a value describing the attribute definition. The four attribute definition locations include a dictionary name location 56, an attribute name location 58, an attribute value location 60, and an attribute type location 62. The locations are separated by a semicolon, or equivalent delimiter, and hold values in human readable form, facilitating the process of transferring user records from source database 12 to source table 42. Dictionary name location 56 holds a name of a dictionary that defines a protocol used by target system 18. Attribute name location 58 holds an attribute name of one of the attributes defined by the dictionary listed in dictionary name location 56, while attribute value location 60 holds the value of the attribute listed in attribute name location 58. Attribute type location 62 holds the name of the attribute type of the attribute listed in attribute name location 58.

[0032] The storage format shown in FIGS. 2 and 3 provides a record format that is of sufficient flexibility to support many types of data record formats from different types of database schemas. Yet, it is also sufficiently uniform to allow data transfer interface 10 to obtain and process the necessary data required for proper importation. For example, source system 16 may be a subscriber management system used by an ISP, and target system 18 may be a system that offers unified authentication, authorization, and accounting (AAA) services across a wide-array of network access points, such as the 4User Control Point (UCP) product available from Cisco Systems, Inc. of San Jose. The subscriber management system may have a source location, such as source database 12, for holding and maintaining user data. The user data may include a user's name that corresponds to one of the ISP's applications, such as a stand-alone network accounting system based on the RADIUS (Remote Authentication Dial-In Service) protocol, the user's password that corresponds to that user name, and the user's service profile containing configuration information unique to the user and the network accounting system.

[0033] Using the storage format described above, a set of user data elements may be selected as keywords, such as user name and password. (A keyword is commonly used as a search index in an information repository, such as a database.) Attributes or information that relate to the configuration of the network accounting system and the user that are required by the target system are stored as attribute definitions. For example, dictionary name location 56 may be used to specify the protocol used by the target system, such as the RADIUS (remote access dial-in user service) protocol. Since there may be more than one type of RADIUS protocol, the dictionary name may also include the type of protocol. For instance, the RADIUS protocol having the extensions supported by a vendor A may be listed within the dictionary name location as “VendorA-Radius.” Similarly, the RADIUS protocol having the extensions supported by a vendor B may be listed within the dictionary name location as “VendorB-Radius”, and the like.

[0034] In the same example, attribute name location 58 may hold an attribute name corresponding to an attribute defined in the dictionary listed in dictionary name location 56, such as “IP address”. Since attribute name location 58 holds the term “IP address”, attribute value location 60 holds the actual value of the IP address. Attribute type location 62 holds the value of the attribute type associated with the IP address attribute in a human-readable format. Attribute type location 62 may be defined to include one of two types of attribute values: “reply_attribute” or “check_item.” Those of ordinary skill in the art will readily recognize that the attribute values of reply_attribute and check_item are specific to the attributes defined for the RADIUS protocol and thus, will not require further description other than to describe how the attributes may be included in an attribute definition.

[0035] This approach of defining attributes using an attribute definition, such as attribute definition 54(1) may be followed for each attribute defined by a protocol that an integrator seeks to use with target system 18. Moreover, those of ordinary skill in the art will readily recognize that the above approach may also be used for defining configuration information for an application, or equivalent, that requires configuration information to be imported from a source location.

[0036] Referring again to FIG. 1, source data adapter 20 is shown having a subscribing element 80, a data validator 82, an attribute definition transcriber 84, and a publishing element 86. Subscribing element 80 and publishing element 86 receive and transmit events, respectively, on communications architecture 24. Subscribing element 80 is registered with information broker 30 to receive the events published by source interface 26, enabling source data adapter 20 through subscribing element 80 to receive user records stored in source table 42 that are each published as an event.

[0037] Upon the receipt of each event carrying a user record, data validator 82 validates each user record received. Data validator 82 validates the user record by determining whether an attribute definition includes an attribute name and an attribute type having the proper values, and whether the attribute definition contains a complete set of values. These determinations are based on the specific application or protocol listed in a dictionary name associated with each attribute definition. For example, if an attribute definition defines an attribute of a particular protocol then the attribute name, attribute value, and attribute type listed within the attribute definition must conform to the attribute dictionary of that particular protocol in order to be found valid. An attribute dictionary defines the attribute names, values, and types for a particular protocol, e.g., an attribute dictionary exists for the RADIUS protocol and its variations implemented by various vendors.

[0038] For instance, if attribute name location 58 in FIG. 3 contains the string “password,” and if the attribute dictionary listed in dictionary name location 56 defines an attribute name of “password”, data validator 82 will deem the value held in attribute name location 58 valid because the value held by attribute name location 58 corresponds to one of the attributes used by the protocol defined by dictionary name location 56. In another example, if attribute name location 58 holds the string “pword,” and the attributes used by the protocol defined by dictionary name location 56 does not include an attribute name of “pword”, data validator 82 will deem the value of attribute name location 58 invalid.

[0039] Data validator 82 also validates the content of attribute value location 60 by determining whether the listed attribute value is of the proper value type for the attribute name held in attribute name location 58. For example, if attribute name location 58 contains the term “phone_number” and if the protocol listed in dictionary name location 56 defines a phone number attribute having a numerical value type rather than a string value type, data validator 82 will deem the content within attribute value location 60 invalid because it has a value type that does not match the value type required by the protocol listed for the attribute name.

[0040] Data validator 82 also checks for completeness by checking whether a value exists in each attribute definition location that requires a value by the protocol listed in dictionary name location 56. For example, if dictionary name location 56 contains the value “VendorA-Radius”, and attribute name location 58 contains an IP address, data validator 82 will determine whether a value exists within attribute type location 62 because the VendorA-Radius value pertains to a protocol that requires an attribute type in addition to an attribute name and attribute value corresponding to the attribute name.

[0041] If data validator 82 finds any of the values held by attribute name location 58 or attribute value location 60 invalid, or the attribute definition incomplete, data validator 82 drops the corresponding user record, sends an alert message to an operator, and waits for another event containing another user record to process. Otherwise, data validator 82 repeats the above validation process for each attribute definition listed in a user record.

[0042] If data validator 82 finds all attribute definitions valid within a given user record, then the user record is transferred to attribute definition transcriber 84. Attribute definition transcriber 84 converts the human readable form of the dictionary name, attribute name, and attribute type into descriptions that comply with the descriptions that have been standardized for, or are required by, a particular application or protocol used by target system 18. Thus, attribute definition transcriber 84 converts the each attribute definition from a first description, e.g., human readable form, into a second description.

[0043] For example, if target system 18 uses the User Control Point product available from Cisco Systems, then attribute definition transcriber 84 will transcribe the value in dictionary name location 56 into a dictionary ID, which consists of a numerical value. If dictionary name location 56 contains “VendorA-Radius”, a dictionary ID of “1” may be used, or if dictionary name location 56 contains “VendorB-Radius”, a dictionary ID of “2” may be used, and so on. Attribute definition transcriber 84 will also transcribe the value in attribute name location 58 into an attribute name ID. If attribute name location 58 contains the attribute name of “password”, attribute transcriber 84 will change the value “password” to the number “8” because in the RADIUS protocol, regardless of version, attribute IDs are used instead of attribute names. Hence, the number “8” is used to indicate that a corresponding attribute value is a password.

[0044] Attribute definition transcriber 84 may also transcribe the attribute type value in attribute type location 62 from a human-readable form to an encoded numerical form. For example, if the attribute type value is reply_attribute, which is in human-readable form, attribute definition transcriber 84 will transcribe the-attribute type value to an 10 encoded numerical indicator of “0.” Similarly, if the attribute type value is check_item, attribute definition transcriber 84 will transcribe the attribute type value to an encoded numerical indicator of “1”.

[0045] After attribute definition transcriber 84 transcribes all of the attribute definitions in the user record received from data validator 82, source data adapter 20 sends the transcribed data record to target data adapter 22. In accordance with a presently preferred embodiment of the present invention, source data adapter 20 uses publishing element 86 to publish the transcribed data record as an event that can be received by target data adapter 22. As seen in FIG. 1, target data adapter 22 includes a subscribing element 100, a format converter 102 and a publishing element 104. Target data adapter 22 uses subscribing element 100 to receive events of the same event type as the event sent by publishing element 86, enabling target data adapter 22 to receive validated and transcribed data records from source data adapter 20.

[0046] Upon receiving an event from source data adapter 20 through subscribing element 100, target data adapter 22 uses format converter 102 to convert the validated and transcribed data record encapsulated by the event from the format described above to a target format. The target format selected should be suitable with the database schema required by target system 18. In accordance with one presently preferred embodiment of the present invention, the target format has the format 106 shown in FIG. 4 and is suitable for a target system, such as the User Control Point product available from Cisco. Systems. Format 106 includes a user keyword 108 equated with the actual name of the user, which is followed by a delimiter such as a left curly bracket 110. After user keyword 108, the dictionary name of an attribute definition within a corresponding validated and transcribed user record is parsed into two parts: protocol name 112 and version name 114. Format 106 also includes a; section for holding information associated with the attributes listed in the user record having the same dictionary name described by protocol name 112 and version name 114. All attributes that have an attribute type value of “reply-attribute” (hereinafter, “reply attributes”) are placed after a delimiter such as a left curly bracket 116, which follows a reply attribute header 118. Each reply attribute is then listed starting with the attribute ID set equal to the name of the attribute. For example, a reply attribute may include an attribute ID 120 of “8” and an attribute name 122 of “password.”

[0047] After all reply attributes have been listed, a right curly bracket 124 is placed after the last reply attribute listed, and all attributes that have an attribute type value of “check_item” (hereinafter “check item attributes”) are then listed. All check item attributes are placed after a delimiter such as a left curly bracket 128, which follows a check attribute header 130. Each check item attribute is then listed starting with the attribute ID set equal to the name of the attribute. For example, a check item attribute may include an attribute ID 132 of “2” and an attribute value 134 of “IP address.” After the check item attributes have been listed for a particular user record, two delimiters such as a pair of right curly brackets 136 and 138 are placed after the last check item attribute listed. Delimiter/right curly bracket 1*36 corresponds to delimiter/left curly bracket 128 and delimiter/right curly bracket 138 corresponds to delimiter/left curly bracket 110. Format 106 is followed for each user record received for importation. Those of skill in the art will see that other formats could also be used.

[0048] FIG. 5 is a process flow for importing data from a source location to a target location, in accordance with a preferred embodiment of the present invention is shown.

[0049] At reference number 200, the components of data transfer interface 10 and communications architecture 24 are initialized. Initialization includes registering the components that transmit or receive events with information broker 30, triggering database trigger 38, or equivalent stored procedure, and storing user data as a user record in a source area, such as storage table 42.

[0050] At reference number 202, database trigger 38 sends a user record stored in the source area to source data adapter 20. Since, in a preferred embodiment, a user record is transmitted and received using events, database trigger 38 does not transmit the user record to source data adapter 20 directly. Instead, database trigger 38 relies on source interface 26 to receive the user record and to transmit the user record as an event on communications architecture 24. The event has an event type that corresponds to an event that source data adapter 20 has registered to receive with information broker 30, enabling source data adapter 20 to receive the database record as an event through subscribing element 80.

[0051] At reference number 204, source data adapter 20 receives the database record as an event that was published by source interface 26 through information broker 30 and validates the contents of the user record.

[0052] At reference number 206, if the contents of the user record are found valid, the process flow proceeds to reference number 208.

[0053] If at reference number 206, the contents of the user record are found not valid, reference number 216 is performed. At reference number 216, source data adapter 20 drops the user record and sends an alert message to an operator. Control then passes to reference number 218.

[0054] At reference number 218, source data adapter 20 waits to receive another user record.

[0055] At reference number 220, if another user record is available for processing, such as a user record published as an event by source interface 26, the process flow returns to reference number 204. Otherwise, source data adapter 20 continues to wait for another user record by returning to reference number 218.

[0056] At reference number 208, source data adapter 20 transcribes each attribute definition that may be in the validated user record. The validity analysis and transcription performed by source data adapter 20 for a user record is described above.

[0057] At reference number 210, source data adapter 20 transmits the validated and transcribed user record as an event to target data adapter 22 using publishing element 86. The event has an event type that matches an event that target data adapter 22 has registered to receive with information broker 30, enabling target data adapter 22 to receive the validated and transcribed user record as an event through subscribing element 100.

[0058] At reference number 212, target data adapter 22 converts the format of the validated and transcribed user record into a format suitable for use by target system 18 using format converter 102. The format conversion performed by format converter 102 for a user record is described above.

[0059] At reference number 214, target data adapter 22 transmits the converted user record to target system 18 for storage at a target location, such as target database 14. In accordance with a preferred embodiment of the present invention, the transmission of the converted user record includes using an event. Thus, target data adapter 22 uses publishing element 104 to transmit the converted user record as an event on communications architecture 24. The event has an event type that matches an event that target interface 28 has registered to receive with information broker 30, enabling target interface 28 to receive the converted user record. Target interface 28 receives the event published by target data adapter 22, strips the converted user record from the event, and provides it to DBMS 36 for storage in a target location, such as target database 14, using a protocol or language compatible with DBMS 36, such as SQL.

[0060] Those of ordinary skill in the art will readily recognize that the acts listed in the process flow disclosed above do not have to be performed in a lock step manner with each other but may be performed independently. For example, information broker 30 may queue published events it receives so that it may receive the events at a rate independent from the rate it transmits the events to corresponding subscribing elements. In another example, source data adapter 20 and target data adapter 22 may also queue each user record received, enabling each adapter to process each user record at a rate independent from the rate that they receive each user record.

[0061] While embodiments and applications of this invention have been shown and described, it would be apparent to those skilled in the art after a perusal of this disclosure that many more modifications than mentioned above are possible without departing from the inventive concepts disclosed. The invention, therefore, is not to be restricted except in the spirit of the appended claims.