System, method, and computer program for aggregating fragments of data objects from a plurality of devices

A system, method, and computer program product are provided for aggregating fragments of data objects from a plurality of devices. In use, a first data fragment associated with a first data object to be migrated from at least one first device associated with a legacy code to a second device associated with a target code is received, the first data fragment including at least a first portion of the first data object. Additionally, it is determined that the first data fragment is one of a plurality of data fragments that comprise the first data object. In response to determining that the first data fragment is one of a plurality of data fragments that comprise the first data object, the first data fragment is stored in a memory. Further, the memory is monitored to determine whether all of the plurality of data fragments that comprise the first data object are present in the memory. In response to determining that all of the plurality of data fragments that comprise the first data object are present in the memory, the first data object is assembled from the plurality of data fragments. Moreover, the first data object is automatically migrated to the second device associated with the target code.

FIELD OF THE INVENTION

The present invention relates to computer infrastructures, and more particularly to updating such computer infrastructures.

BACKGROUND

Many telecommunications providers are investing significant effort to simplify and consolidate their software infrastructure, often replacing multiple legacy applications with a single COTS (Commercial Off-The-Shelf) application. Part of the consolidation process involves migrating data from legacy applications (i.e. source applications) to new target applications, and then capturing subsequent changes to the data in the legacy applications and replicating those changes to the target application in near real-time.

Aggregating fragments of data associated with a data object before the data object can be re-assembled and processed is a challenge encountered during the near real-time replication process. There is thus a need for addressing these and/or other issues associated with the prior art.

SUMMARY

A system, method, and computer program product are provided for aggregating fragments of data objects from a plurality of devices. In use, a first data fragment associated with a first data object to be migrated from at least one first device associated with a legacy code to a second device associated with a target code is received, the first data fragment including at least a first portion of the first data object. Additionally, it is determined that the first data fragment is one of a plurality of data fragments that comprise the first data object. In response to determining that the first data fragment is one of a plurality of data fragments that comprise the first data object, the first data fragment is stored in a memory. Further, the memory is monitored to determine whether all of the plurality of data fragments that comprise the first data object are present in the memory. In response to determining that all of the plurality of data fragments that comprise the first data object are present in the memory, the first data object is assembled from the plurality of data fragments. Moreover, the first data object is automatically migrated to the second device associated with the target code.

DETAILED DESCRIPTION

FIG. 1illustrates a network architecture100, in accordance with one possible embodiment. As shown, at least one network.102is provided. In the context of the present network architecture100, the network102may take any form including, but not limited to a telecommunications network, a local area network (LAN), a wireless network, a wide area network (WAN) such as the Internet, peer-to-peer network, cable network, etc. While only one network is shown, it should be understood that two or more similar or different networks102may be provided.

Coupled to the network102is a plurality of devices. For example, a server computer104and an end user computer106may be coupled to the network102for communication purposes. Such end user computer106may include a desktop computer, lap-top computer, and/or any other type of logic. Still yet, various other devices may be coupled to the network102including a personal digital assistant (PDA) device108, a mobile phone device110, a television112, etc.

FIG. 2illustrates an exemplary system200, in accordance with one embodiment. As an option, the system200may be implemented in the context of any of the devices of the network architecture100ofFIG. 1. Of course, the system200may be implemented in any desired environment.

As shown, a system200is provided including at least one central processor201which is connected to a communication bus202. The system200also includes main memory204[e.g. random access memory (RAM), etc.]. The system200also includes a graphics processor206and a display208.

The system200may also include a secondary storage210. The secondary storage210includes, for example, a hard disk drive and/or a removable storage drive, representing a floppy disk drive, a magnetic tape drive, a compact disk drive, etc. The removable storage drive reads from and/or writes to a removable storage unit in a well known manner.

Computer programs, or computer control logic algorithms, may be stored in the main memory204, the secondary storage210, and/or any other memory, for that matter. Such computer programs, when executed, enable the system200to perform various functions (to be set forth below, for example). Memory204, storage210and/or any other storage are possible examples of tangible computer-readable media.

FIG. 3illustrates a method300for aggregating fragments of data objects from a plurality of devices, in accordance with one embodiment. As an option, the method300may be carried out in the context of the details ofFIGS. 1and/or2. Of course, however, the method300may be carried out in any desired environment. Further, the aforementioned definitions may equally apply to the description below.

As shown, a first data fragment associated with a first data object to be migrated from at least one first device associated with a legacy code to a second device associated with a target code is received, the first data fragment including at least a first portion of the first data object. See operation302.

In the context of the present description, legacy code refers to any computer code, computer program, software application, and/or combination thereof, that is associated with a software infrastructure. In one embodiment, the legacy code may represent applications or code associated with a current or past software infrastructure, which is to be updated to anew software infrastructure.

Similarly, target code may refer to any computer code, computer program, software application, and/or combination thereof, that is associated with a software infrastructure. In one embodiment, the target code may represent applications or code associated with a new software infrastructure that is to be updated from a current or past software infrastructure. For example, in one embodiment, the legacy code may represent multiple legacy applications and the target code may represent a single COTS (Commercial Off-The-Shelf) application.

The first device and the second device may include a variety of devices. For example, in various embodiments, the first device and/or the second device may include server devices, client devices, databases, cache memory, and/or various other types of devices.

Furthermore, the data objects may include any data object associated with the legacy code and/or the target code. For example, in one embodiment, the data objects may include data objects generated by the legacy code.

As shown further inFIG. 3, it is determined that the first data fragment is one of a plurality of data fragments that comprise the first data object. See operation304. The first data fragment may include any portion of the data object. In one embodiment, the plurality of data fragments comprising the first data object may be stored across a plurality of devices associated with the legacy code. For example, the first data fragment may be stored in the first device and a second data fragment may be stored in another device associated with the legacy code.

Furthermore, in one embodiment, the first data fragment associated with the first data may be received at an aggregation component capable of combining the aggregate fragments to reform the first object. In this case, the aggregate component may include any hardware, software, and/or device.

It may be determined that the first data fragment is one of a plurality of data fragments that comprise the first data object utilizing a variety of techniques. In one embodiment, the first data fragment may be marked or associated with a number that identifies the first data fragment as a portion of the first data object (e.g. 1 of 4, etc.).

For example, each of plurality of data fragments that comprise the first data object may be assigned a unique part number, where the part number corresponds to a unique number out of a total number of the plurality of data fragments that comprise the first data object. In this case, determining that the first data fragment is one of the plurality of data fragments that comprise the first data object may include identifying a first unique part number associated with the first data fragment.

In another embodiment, each of plurality of data fragments that comprise the first data object may be assigned a unique key. In this case, determining that the first data fragment is one of the plurality of data fragments that comprise the first data object may include identifying the first data object is associated with more than one unique key.

In response to determining that the first data fragment is one of a plurality of data fragments that comprise the first data object, the first data fragment is stored in a memory. See operation306. For example, in one embodiment, the first data fragment may be stored in a cache associated with the aggregation component.

Further, the memory is monitored to determine whether all of the plurality of data fragments that comprise the first data object are present in the memory. See operation308. For example, the memory may be monitored for data fragment arrival. Upon arrival of a data fragment, it may be determined whether the plurality of data fragments that comprise the first data object are present in the memory. In another embodiment, the memory may be monitored on a periodic basis to be determine whether the plurality of data fragments that comprise the first data object are present in the memory.

In response to determining that all of the plurality of data fragments that comprise the first data object are present in the memory, the first data object is assembled from the plurality of data fragments. See operation310. Moreover, the first data object is automatically migrated to the second device associated with the target code. See operation312.

In one embodiment, at least one of the plurality of data fragments may be converted to a common internal format before assembling the first data object from the plurality of data fragments. Additionally, in one embodiment, the first data object may be migrated to the second device associated with the target code in the common internal format.

Additionally, in one embodiment, the method300may include determining a type of operation associated with the first data object, in response to receiving the first data fragment associated with the first data object. For example, the type of operation associated with the first data object may include an insert operation, an update operation, or a delete operation.

As an example, it may be determined that the type of operation associated with the first data object includes an insert operation. In this case, responsive to determining that the first data fragment is one of the plurality of data fragments that comprise the first data object, a number of the plurality of data fragments that comprise the first data object may be determined. Further, the number may be stored as a value with the first data fragment in the memory. In this way, the number of fragments needed to assemble the data object may be determined.

As another example, the type of operation associated with the first data object may be determined to include a delete operation. In this case, existing keys associated with the first data object may be identified in an ID cache. If more than one existing key associated with the first data object is identified, it may he determined that the first data fragment is one of the plurality of data fragments that comprise the first data object.

In various embodiments, in response to identifying more than one existing key associated with the first data object, the delete operation may be performed on the first data fragment, the delete operation may be performed on the first data fragment if the first data fragment is marked with particular information (e.g. indicating the data fragment is a primary source of the first data object, etc.), or the delete operation may be performed on the first data fragment after determining that all of the plurality of data fragments are present in the memory. In this case, delete operation execution may be defined by a system operator, etc.

In certain circumstances, object instances may exist in fragments across some, or all, source applications. If a change to a unique object instance is detected in one or more source applications, all fragments of the object instance must he aggregated before the object instance can be re-assembled and replicated to a target application. Aggregation refers to the process of gathering fragments of data that relate to a particular object instance, assembling these fragments into a single representation of that object, before writing it into the target application.

Elapsed time is another reason for the need to aggregate fragments. Objects may not have been created or updated on all source applications at the same point in time, thereby introducing cross-system delays before the object can be assembled and replicated to a target application. In one embodiment, the aggregation technique/component described in the context ofFIG. 3may function to resolve such issues of elapsed time by caching related fragments until the complete object can he assembled.

More illustrative information will now be set forth regarding various optional architectures and uses in which the foregoing method may or may not be implemented, per the desires of the user. It should be strongly noted that the following information is set forth for illustrative purposes and should not he construed as limiting in any manner. Any of the following features may be optionally incorporated with or without the exclusion of other features described.

FIG. 4illustrates a flow diagram400showing an example of multiple source devices storing slightly different information about a data object to he migrated to a target device, in accordance with one embodiment. As an option, the flow diagram400may be implemented in the context of the details ofFIGS. 1-3. Of course, however, the flow diagram400may be implemented in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

FIG. 4provides one example of the different table structures406and410in a source and a target application and the entity instances holding the data. An aggregation component402is responsible for ultimately bridging the gap between source and target applications. In operation, the aggregation component402may assemble data fragments from multiple sources404, where the sources404are storing slightly different information about a data object “cards”. All of the information maintained in the three sources404must be replicated into a target system408, the replicated data being represented by a single table410in this example.

FIG. 5illustrates a flow diagram500showing how entity instances from a source application are transformed in to a common internal format before being processed, in accordance with one embodiment. As an option, the flow diagram500may be implemented in the context of the details ofFIGS. 1-4. Of course, however, the flow diagram500may be implemented in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

FIG. 5shows one example of how a plurality of entity instances504from at least one source application are transformed in to a common internal format before being processed by an aggregation component502. The same common internal format may also be used to represent a combined set of data that is written to a target system508. In one embodiment, each object from a source application may be assigned a part number out of the total number of parts needed to assemble the output object (e.g. see fragments506). The part number and total number of parts may be used together to determine whether the object is a fragment of a larger object.

FIG. 6illustrates a flow diagram600showing how primary keys of objects in source and target applications are linked by an ID cache, in accordance with one embodiment, As an option, the flow diagram600may be implemented in the context of the details ofFIGS. 1-5. Of course, however, the flow diagram600may be implemented in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

FIG. 6details how primary keys of objects in source and target applications are linked by an ID cache602. In one embodiment, the purpose of the ID (identity, or primary key) cache may be to maintain relationships between source keys associated with data object fragments604and target keys associated with data objects606. An object that has two or more source keys may be processed by the aggregation component602.

Aggregation may be implemented when the same object exists in two or more source applications and the object is to be replicated to a target as one combined unit. Accordingly, in one embodiment, an ID cache component may be utilized to manage relationships between keys of associated objects across system boundaries.

FIG. 7illustrates a flow diagram700showing the processing of an insert operation associated with a data object, in accordance with one embodiment. As an option, the flow diagram700may be implemented in the context of the details ofFIGS. 1-6. Of course, however, the flow diagram700may be implemented in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below,

As shown, when new data in source applications is detected, input objects containing the captured changed data are passed to an aggregation component. In operation, an input object is submitted to the aggregation component, See step1.

Further, the type of operation (e.g. insert, update, or delete, etc.) is verified. See step2. An insert operation is assumed for the context ofFIG. 7.

If more than one part is required to create the output object, the input object is ascertained to be a fragment of a larger object. See step3. The number of parts needed to create the output object is stored as a value in the input object, and is set prior to the fragment being passed to the aggregation component.

The fragment \input object is then passed to the aggregation caching component. See step4. The input object is added to cache, awaiting arrival of the remaining parts needed to create the output object.

FIG. 8illustrates a flow diagram800showing the processing of an update operation associated with a data object, in accordance with one embodiment. As an option, the flow diagram800may be implemented in the context of the details ofFIGS. 1-7. Of course, however, the flow diagram800may be implemented in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

As shown, an input object including the updated data is submitted to the aggregation component. See step1. The type of operation (e.g. insert, update, or delete) is verified. See step2, If the operation is an update operation, no further processing is needed by the aggregation component, since updates rely on the create operation, which has previously assembled and processed the combined object.

FIG. 9illustrates a flow diagram900showing the processing of a delete operation associated with a data object, in accordance with one embodiment. As an option, the flow diagram900may be implemented in the context of the details ofFIGS. 1-8. Of course, however, the flow diagram900may be implemented in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

As shown, an input object including the object to be deleted is submitted to the aggregation component, See step1. The type of operation (e.g. insert, update, or delete) is verified. See step2. A delete operation is assumed for the context ofFIG. 9.

The existing key associations for the input object are looked up in the ID cache component using the input object primary key. See step3. If there are two or more source keys available in the key associations, the object being processed is a fragment See step4. If there is only a single source key in the key associations, this is not a fragment and no further processing by the aggregation component is necessary.

The input object is passed to an Aggregation Delete Policy component. See step5. This component may be configured with various algorithms for deciding how to process the delete request of a fragment. There are several options for algorithms to decide how to process delete requests.

For example, the delete request may be processed on the target object, irrespective of the number of existing source applications also referencing the target object. As another example, the delete request may be processed only if the input object is marked with particular information, such as being the “primary source” of the target object. As another example, the delete request may be processed only after a defined number of fragments arrive, all of which fragments requesting the target object are to be deleted. This implies the individual delete requests will need to be cached while waiting for further delete requests to arrive. If, or when, the delete request is executed, the source and target key associations are deleted from the ID cache. See step6.

The aggregation cache deduces if there are target objects for which all fragments have been received, in which case the fragments are combined and passed to the target for processing.

FIG. 10illustrates a flow diagram1000for determining if there are target objects in an aggregation cache for which all fragments have been received, in accordance with one embodiment. As an option, the flow diagram1000may be implemented in the context of the details ofFIGS. 1-9. Of course, however, the flow diagram1000may be implemented in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

As shown, processing by the aggregation cache is triggered, either by the arrival of a new fragment, or by a timer. See step1. All fragments associated with the same target object are retrieved from the cache. See step2.

Further, it is determined how many fragments are available, and how many fragments constitute the target object by inspecting the total number of parts needed in one of the fragments. See step3. If the number of fragments needed is equal to the number of fragments available, the operation can be processed.

The fragments are passed to an assembler component that takes responsibility for merging the content of the fragments into a single target object. See step4. The fragments are then removed from the aggregation cache. The process moves on to the next target object and its available fragments until all target objects have been traversed.