US20190324798A1 - Method and system for migrating xml schemas in application releases - Google Patents
Method and system for migrating xml schemas in application releases Download PDFInfo
- Publication number
- US20190324798A1 US20190324798A1 US15/955,829 US201815955829A US2019324798A1 US 20190324798 A1 US20190324798 A1 US 20190324798A1 US 201815955829 A US201815955829 A US 201815955829A US 2019324798 A1 US2019324798 A1 US 2019324798A1
- Authority
- US
- United States
- Prior art keywords
- version
- xml document
- migration
- xml
- document
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
- G06F9/4856—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/51—Source to source
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
- G06F16/84—Mapping; Conversion
-
- G06F17/30914—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/31—Programming languages or programming paradigms
- G06F8/316—Aspect-oriented programming techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/36—Software reuse
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Definitions
- the instant disclosure relates generally to computing applications involving Extensible Markup Language (XML) documents, and in particular to methods and systems for migrating XML schemas between releases of computing applications.
- XML Extensible Markup Language
- a markup language is a computer language designed for the processing, definition and presentation of text.
- a markup language specifies code for formatting, both the layout and style, within a text file.
- the code used to specify formatting and define elements within a document are called tags.
- a markup language is human-readable, rather than typical computer language programming syntax.
- One of the two most popular markup languages is Extensible Markup Language (XML).
- XML is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable.
- XML provides a lightweight and strongly typed way to persist the data and state of a computing application, i.e., to have the computing application data and the computing application state survive after the process with which they were created has ended.
- the schema i.e., the organization and structure
- the schema of an XML document may change between releases of a computing application. If the schema of the XML document changes, then the current release of the computing application likely will not be able to access the application data from a previous release, thereby creating an incompatibility between releases of the same computing application.
- the method includes providing a first version of an XML document by the computing application, in which the first version of the XML document has a first schema.
- the method also includes providing at least one second version of an XML document by the computing application, in which the second version of the XML document has a second schema that is different than the first schema.
- the method also includes migrating the first version of the XML document to the second version of the XML document using a migration step.
- the method also includes using a Dependency Injection Framework to abstract the characteristics of the at least one migration step.
- the method also includes transforming the first schema to the second schema, based on the abstracted characteristics of the at least one migration step, in such a way that the first version of the XML document is migrated into the second version of the XML document.
- the method migrates the first version of the XML document into the second version of the XML document in such a way that the second version of the XML document can access application data from the first version of the XML document.
- FIGS. 1 a and 1 b are schematic views of example schema changes between two releases of an Extensible Markup Language (XML) document;
- XML Extensible Markup Language
- FIG. 2 is a schematic view of the transformation of an XML document using Extensible Stylesheet Language Transformation (XSLT);
- XSLT Extensible Stylesheet Language Transformation
- FIG. 3 is a schematic view of an XML Migration Manager, according to an embodiment
- FIG. 4 is a schematic view of a class diagram illustrating the relationship between the different objects that are used in FIG. 3 , according to an embodiment
- FIG. 5 is a schematic view of an example migration path used by the XML Migration Manager, according to an embodiment.
- FIG. 6 is a schematic view of a portion of an example migration involving a later released Interim Correction (IC) using the XML Migration Manager, according to an embodiment.
- IC Interim Correction
- FIGS. 1 a and 1 b are schematic views of example schema changes between two releases of an Extensible Markup Language (XML) document (or object) 10 , i.e., a document or object whose data is formatted in the XML language.
- XML Extensible Markup Language
- FIG. 1 a illustrates a first version (e.g., release version 1.0) of the XML document 10 .
- FIG. 1 b illustrates a second version (e.g., release version 2.0) of the XML document 10 .
- the XML document 10 includes a number of lines of data 12 in XML format.
- a first highlighted portion or node 14 of the data 12 shown in FIG. 1 a and a second highlighted portion or node 16 of the program data 12 shown in FIG. 1 b note the changes that have occurred between the first version (e.g., release version 1.0) of the XML document 10 and the second version (e.g., release version 2.0) of the XML document 10 . All of the remaining data 12 is the same in both the first version (e.g., release version 1.0) of the XML document 10 and the second version (e.g., release version 2.0) of the XML document 10 .
- serialization is a process by which the state of an object (e.g., an XML document) is transformed or converted into a form (e.g., a serial data format or data stream) that can be readily transported.
- the serialized data stream is converted back into its object form (i.e., deserialized).
- deserializing the XML document 10 serialized from the first version (e.g., release version 1.0) of the XML document 10 into the second version (e.g., release version 2.0) of the XML document 10 using conventional data format conversions or transformations will fail.
- problems associated with the incompatibility of releases of the same XML document are overcome by abstracting a layer of interfaces of the XML schema migration and then using a Dependency Injection Framework to manage or fulfill all of the dependencies that are needed for the XML migration to be performed.
- the XML migration involves one or more migration steps that use an Extensible Stylesheet Language Transformation (XSLT) to convert the structure of the XML document.
- XSLT Extensible Stylesheet Language Transformation
- FIG. 2 is a schematic view 20 of the transformation of an XML document by applying Extensible Stylesheet Language Transformation (XSLT), i.e., using an XSLT document 24 and an XSLT processor 26 .
- Extensible Stylesheet Language Transformation is an XML-related technology that provides a way to automatically transform an XML document from one format or version to another format or version. As shown in FIG.
- a first version (e.g., release version 1.0) of an XML document (shown as a source XML document 22 ) and the XSLT document 24 are input to the XSLT processor 26 , and the XSLT processor 26 generates a second version (e.g., release version 2.0) of the XML document (shown as a target XML document 28 ).
- a first version e.g., release version 1.0
- a second version e.g., release version 2.0
- the XSLT processor 26 contains a set of rules to transform the source XML document 22 into the target XML document 28 . Using the XSLT processor 26 , the pattern of the element (i.e., the structure of the source XML document 22 ) is identified in the source XML document 22 . The XSLT processor 26 then applies an appropriate template from the XLST document 24 to create the target XML document 28 . As the target XML document 28 is being generated, the XML elements/structure in the source XML document 22 are filtered and reordered, and an arbitrary structure is added.
- FIG. 3 is a schematic view of an XML Migration Manager 30 , according to an embodiment.
- the XML Migration Manager 30 includes a Migration Step Container component 32 and a Migration Step Executor component 34 .
- the XML Migration Manager 30 also includes or works with a Dependency Injection Framework (DIF) 36 .
- DIF Dependency Injection Framework
- the XML Migration Manager 30 works with a plurality of Migration Steps 38 (e.g., Migration Step 1, Migration Step 2, Migration Step 3, Migration Step n).
- the Migration steps 38 are an abstraction of the migration processing unit(s) coupled between two adjacent versions of the XML document.
- the XML Migration Manager 30 can be a standalone computing device, machine or system, or a group of standalone computing devices, machines or systems. That is, one or more of the Migration Step Container component 32 , the Migration Step Executor component 34 and the Dependency Injection Framework 36 can be a standalone computing device, machine or system, or a group of standalone computing devices, machines or systems. Regardless of the particular configuration of the XML Migration Manager 30 , it should be understood that the relationship between the Migration Step Container component 32 , the Migration Step Executor component 34 and the Dependency Injection Framework 36 is a machine-to-machine connection, and involves machine-to-machine communications, i.e., the exchange of data between machines.
- Each of the Migration Steps 38 contains an XSLT script or program (e.g., XSLT script 1, XSLT script 2, XSLT script 3, XSLT script n) to transform the XML document from one version to the next version, and each Migration Step 38 exports itself to the XML Migration Manager 30 via the Dependency Injection Framework (DIF) 36 .
- the XML Migration Manager 30 is the core component that collects all of the Migration Steps 38 , and then processes the migration.
- Dependency Injection is a design pattern (i.e., a general, reusable template or approach) that decouples dependencies between a first object and a second object that is dependent on the first object.
- a dependency is a reliance of one data document, application or object on another data document, application or object.
- the Dependency Injection Framework 36 uses Dependency Injection principles to manage, e.g., remove, the dependencies between the XML Migration Manager 30 and the Migration Steps 38 so that the XML Migration Manager 30 does not need to know the Migration Steps 38 beforehand.
- the Dependency Injection Framework 36 manages the dependencies between the XML Migration Manager 30 and the Migration Steps 38 using Dependency Injection, the XML Manager 30 manages the information for each migration in a future release of the XML document without needing to know the XML schema beforehand.
- the XML Migration Manager 30 has two core components: the Migration Step Container component 32 and the Migration Step Executor component 34 .
- the Migration Step Container component 32 stores all of the migration steps that are collected by the Dependency Injection Framework 36 .
- the Migration Step Container component 32 also determines a migration path from the first or begin version of the XML document to the last or end version of the XML document.
- the Migration Step Executor component 34 communicates with the Migration Step Container component 32 to fetch the migration path.
- the Migration Step Executor component 34 then executes the migration path step-by-step.
- the Migration Step Executor component 34 uses the XSLT processor 26 ( FIG. 2 ) to transform the XML document from one version to the next version.
- the Migration Step Container component 32 and the Migration Step Executor component 34 depend on a set of Interfaces (shown in FIG. 4 ), which abstract all of the logic associated with the migration. Meanwhile, all of the migration steps also inherit the properties and methods from the same set of interfaces and provide concrete migration logic. Therefore, although the XML Migration Manager 30 does not have any knowledge about the concrete migration steps, the XML Migration Manager 30 can still execute the migration steps when an application is running.
- FIG. 4 is a schematic view of a class diagram 50 illustrating the relationship between the different objects that are used in FIG. 3 , according to an embodiment.
- Each of the Migration Steps 38 shown in FIG. 3 i.e., Migration Steps 1-N
- XMLUpgrade Steps 39 in FIG. 4 i.e., XMLUpgradeStep1, XMLUpgradeStep2, XMLUpgradeStepx
- an XMLUpgradeStep 41 is a base class that represents the upgrade migration step.
- the migration method supports both the upgrade of an XML document (e.g., release version 1.0 of an XML document to release version 2.0 of the XML document) as well as the downgrade of an XML document (e.g., release version 2.0 of an XML document to release version 1.0 of the XML document).
- An IXMLUpgradeStep box 56 is an interface that represents the upgrade migration step.
- An IXMLDowngradeStep box 58 is an interface that represents the downgrade migration step. It should be understood that although only the upgrade migration step is shown in detail, both the upgrade migration step and the downgrade migration step are similarly executed.
- the Migration Step Container component 32 is a sub-component of the XML Migration Manager 30 , as discussed hereinabove.
- the Migration Step Container component 32 declares its dependencies through the Dependency Injection Framework 36 .
- the Migration Step Container component 32 then fills in these dependencies with all of the migrations steps 38 .
- the Migration Step Container component 32 stores the migration steps 38 into a dictionary for calculating the migration path from one version of the XML document to another version of the XML document.
- Each migration step has two properties: a CurrentVersion 52 and a NextVersion 54 .
- the CurrentVersion 52 is the version of the XML document 10 on which the migration step is applied.
- the NextVersion 54 is the version of the XML document 10 that is generated after executing the migration step.
- the CurrentVersion 52 and the NextVersion 54 are included within an IXMLMigrationStep 59 , which is an interface that represents an abstraction of the migration step, which can be either an upgrade migration step or a downgrade migration step.
- each migration step 38 performs similarly to a singly linked list, in which one step points to the next step.
- the Migration Step Container component 32 is able to determine a migration path, which is a sequence of migration steps from the first or begin version of the XML document 10 to the last or end version of the XML document.
- FIG. 5 is a schematic view of an example migration path 70 used by the XML Migration Manager 30 , according to an embodiment.
- the example migration path 70 is a migration path from an XML document version 2.1 to an XML document version 3.0.
- the migration path 70 includes a first migration step 72 (i.e., Migration Step 1), in which the Current Version is XML document version 2.1 and the Next Version is XML document version 2.2.
- the migration path 70 also includes a second migration step 74 (i.e., Migration Step 2), in which the Current Version is XML document version 2.2 and the Next Version is XML document version 2.3.
- the migration path 70 also includes a third migration step 76 (i.e., Migration Step 3), in which the Current Version is XML document version 2.3 and the Next Version is XML document version 2.4.
- the migration path 70 also includes a fourth migration step 78 (i.e., Migration Step 4), in which the Current Version is XML document version 2.4 and the Next Version is XML document version 3.0
- the Migration Step Executor component 34 is another sub-component of the XML Migration Manager 30 .
- the main responsibility of the Migration Step Executor component 34 is to query the Migration Step Container component 32 to retrieve the migration path. After retrieving the migration path, the Migration Step Executor component 34 iterates through each migration step to execute its migrate method, which uses the XSLT processor 26 ( FIG. 2 ) to perform the transformation. When the migration is completed, the Migration Step Executor component 34 reports the migration status and/or any handle errors.
- One of the features of the Migration Manager 30 and its migration method is greater extensibility (i.e., the ability to accommodate future growth) compared to conventional migration methods.
- the improved extensibility of the Migration Manager 30 and its migration method is the result of several features. First, all of the migration steps performed by the Migration Manager 30 are pluggable in the Migration Manager 30 with the help of the Dependency Injection Framework 36 , as shown in FIG. 3 .
- the Migration Step Container component 32 and the Migration Step Executor component 34 do not depend on any of the concrete migration steps.
- the Migration Step Container component 32 and the Migration Step Executor component 34 apply the Inversion of Control (loc) Principle. That is, the flow of control, i.e., the functions performed by the Migration Step Container component 32 and the Migration Step Executor component 34 as part of the migration method, is received from a generic framework, i.e., the Dependency Injection Framework 36 .
- the use of the Inversion of Control (loc) Principle increases modularity of the migration method, and thus makes the migration method more extensible.
- an XSLT script is embedded within each migration step.
- the embedded XSLT script is processed by the XSLT processor 26 ( FIG. 2 ).
- the XML Migration Manager 30 eliminates a lot of duplicate source code for the XML document processing.
- the migration method described herein demonstrate improved extensibility compared to conventional migration methods.
- the migration method described herein not only supports the upgrade of an XML document, but also supports the downgrade of an XML document by providing downgrade migration steps.
- the downgrade migration steps are performed by the Migration Step Container component 32 and the Migration Step Executor component 34 in the same manner as the upgrade steps are performed.
- the migration method described herein reduces the effort involved in modifying the source code for a migration between chronological releases. According to an embodiment, only one new migration step is added, but no other modifications are required to the migration method.
- FIG. 6 is a schematic view of a portion of an example migration 80 using the XML Migration Manager 30 , according to an embodiment, in which an Interim Correction (IC) is released later than the earlier released higher version.
- the example migration path 80 is a migration path from an XML document version 2.3 to an XML document version 3.1.
- the migration path 80 includes a migration step 82 (i.e., Migration Step 3), in which the Current Version is XML document version 2.3 and the Next Version is XML document version 2.4.
- the migration path 80 also includes another migration step 84 (i.e., Migration Step 4), in which the Current Version is XML document version 2.4 and the Next Version is XML document version 3.0.
- the migration path 70 also includes another migration step 86 (i.e., Migration Step 5), in which the Current Version is XML document version 3.0 and the Next Version is XML document version 3.1.
- the migration path 80 includes a new migration step 88 , 89 (i.e., Migration Step 4a and Migration Step 4b) as a patch.
- the new migration step 88 the Current Version is XML document version 2.4 and the Next Version is XML document version 2.5 (IC)
- the new migration step 89 the Current Version is XML document version 2.5 (IC) and the Next Version is XML document version 3.0.
- the migration method described herein can be used to migrate other data, with relatively little modification to the migration method.
- the XSLT script is replaced with a Structured Query Language (SQL) script.
- SQL Structured Query Language
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- Document Processing Apparatus (AREA)
Abstract
Description
- The instant disclosure relates generally to computing applications involving Extensible Markup Language (XML) documents, and in particular to methods and systems for migrating XML schemas between releases of computing applications.
- A markup language is a computer language designed for the processing, definition and presentation of text. A markup language specifies code for formatting, both the layout and style, within a text file. The code used to specify formatting and define elements within a document are called tags. A markup language is human-readable, rather than typical computer language programming syntax. One of the two most popular markup languages is Extensible Markup Language (XML). XML is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable.
- XML provides a lightweight and strongly typed way to persist the data and state of a computing application, i.e., to have the computing application data and the computing application state survive after the process with which they were created has ended. The schema (i.e., the organization and structure) of an XML document may change between releases of a computing application. If the schema of the XML document changes, then the current release of the computing application likely will not be able to access the application data from a previous release, thereby creating an incompatibility between releases of the same computing application.
- There is a need for a method and system for migrating XML schemas between releases of computing applications.
- Disclosed is a method and system for migrating Extensible Markup Language (XML) schemas between releases of a computing application. The method includes providing a first version of an XML document by the computing application, in which the first version of the XML document has a first schema. The method also includes providing at least one second version of an XML document by the computing application, in which the second version of the XML document has a second schema that is different than the first schema. The method also includes migrating the first version of the XML document to the second version of the XML document using a migration step. The method also includes using a Dependency Injection Framework to abstract the characteristics of the at least one migration step. The method also includes transforming the first schema to the second schema, based on the abstracted characteristics of the at least one migration step, in such a way that the first version of the XML document is migrated into the second version of the XML document. The method migrates the first version of the XML document into the second version of the XML document in such a way that the second version of the XML document can access application data from the first version of the XML document.
-
FIGS. 1a and 1b are schematic views of example schema changes between two releases of an Extensible Markup Language (XML) document; -
FIG. 2 is a schematic view of the transformation of an XML document using Extensible Stylesheet Language Transformation (XSLT); -
FIG. 3 is a schematic view of an XML Migration Manager, according to an embodiment; -
FIG. 4 is a schematic view of a class diagram illustrating the relationship between the different objects that are used inFIG. 3 , according to an embodiment; -
FIG. 5 is a schematic view of an example migration path used by the XML Migration Manager, according to an embodiment; and -
FIG. 6 is a schematic view of a portion of an example migration involving a later released Interim Correction (IC) using the XML Migration Manager, according to an embodiment. - 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.
-
FIGS. 1a and 1b are schematic views of example schema changes between two releases of an Extensible Markup Language (XML) document (or object) 10, i.e., a document or object whose data is formatted in the XML language. For example, as discussed hereinabove, the schema of an XML document may change between releases of an application.FIG. 1a illustrates a first version (e.g., release version 1.0) of the XMLdocument 10.FIG. 1b illustrates a second version (e.g., release version 2.0) of the XMLdocument 10. - The XML
document 10 includes a number of lines ofdata 12 in XML format. A first highlighted portion ornode 14 of thedata 12 shown inFIG. 1a and a second highlighted portion ornode 16 of theprogram data 12 shown inFIG. 1b note the changes that have occurred between the first version (e.g., release version 1.0) of the XMLdocument 10 and the second version (e.g., release version 2.0) of the XMLdocument 10. All of theremaining data 12 is the same in both the first version (e.g., release version 1.0) of the XMLdocument 10 and the second version (e.g., release version 2.0) of the XMLdocument 10. - Because of the changes made between the first version (e.g., release version 1.0) of the XML
document 10 and the second version (e.g., release version 2.0) of the XMLdocument 10, conventional data format conversions or transformations become problematic. For example, using conventional data format conversions or transformations, deserializing the XMLdocument 10 serialized from the first version (e.g., release version 1.0) of the XMLdocument 10 into the second version (e.g., release version 2.0) of the XMLdocument 10 will be unsuccessful. Serialization is a process by which the state of an object (e.g., an XML document) is transformed or converted into a form (e.g., a serial data format or data stream) that can be readily transported. Once the serialized object has been transported, the serialized data stream is converted back into its object form (i.e., deserialized). However, because of a mismatch between the representation of the data structures of the two versions of the XMLdocument 10, deserializing the XMLdocument 10 serialized from the first version (e.g., release version 1.0) of the XMLdocument 10 into the second version (e.g., release version 2.0) of the XMLdocument 10 using conventional data format conversions or transformations will fail. - As will be discussed in greater detail hereinbelow, according to an embodiment, problems associated with the incompatibility of releases of the same XML document are overcome by abstracting a layer of interfaces of the XML schema migration and then using a Dependency Injection Framework to manage or fulfill all of the dependencies that are needed for the XML migration to be performed. According to an embodiment, the XML migration involves one or more migration steps that use an Extensible Stylesheet Language Transformation (XSLT) to convert the structure of the XML document.
-
FIG. 2 is aschematic view 20 of the transformation of an XML document by applying Extensible Stylesheet Language Transformation (XSLT), i.e., using anXSLT document 24 and anXSLT processor 26. Extensible Stylesheet Language Transformation is an XML-related technology that provides a way to automatically transform an XML document from one format or version to another format or version. As shown inFIG. 2 , a first version (e.g., release version 1.0) of an XML document (shown as a source XML document 22) and the XSLTdocument 24 are input to the XSLTprocessor 26, and the XSLTprocessor 26 generates a second version (e.g., release version 2.0) of the XML document (shown as a target XML document 28). - The XSLT
processor 26 contains a set of rules to transform the source XMLdocument 22 into the target XMLdocument 28. Using the XSLTprocessor 26, the pattern of the element (i.e., the structure of the source XML document 22) is identified in the source XMLdocument 22. The XSLTprocessor 26 then applies an appropriate template from theXLST document 24 to create the target XMLdocument 28. As the target XMLdocument 28 is being generated, the XML elements/structure in the source XMLdocument 22 are filtered and reordered, and an arbitrary structure is added. -
FIG. 3 is a schematic view of an XMLMigration Manager 30, according to an embodiment. The XMLMigration Manager 30 includes a MigrationStep Container component 32 and a MigrationStep Executor component 34. The XML Migration Manager 30 also includes or works with a Dependency Injection Framework (DIF) 36. According to an embodiment, the XMLMigration Manager 30 works with a plurality of Migration Steps 38 (e.g.,Migration Step 1,Migration Step 2,Migration Step 3, Migration Step n). TheMigration steps 38 are an abstraction of the migration processing unit(s) coupled between two adjacent versions of the XML document. - The XML
Migration Manager 30 can be a standalone computing device, machine or system, or a group of standalone computing devices, machines or systems. That is, one or more of the MigrationStep Container component 32, the MigrationStep Executor component 34 and theDependency Injection Framework 36 can be a standalone computing device, machine or system, or a group of standalone computing devices, machines or systems. Regardless of the particular configuration of theXML Migration Manager 30, it should be understood that the relationship between the MigrationStep Container component 32, the MigrationStep Executor component 34 and theDependency Injection Framework 36 is a machine-to-machine connection, and involves machine-to-machine communications, i.e., the exchange of data between machines. - Each of the
Migration Steps 38 contains an XSLT script or program (e.g.,XSLT script 1,XSLT script 2,XSLT script 3, XSLT script n) to transform the XML document from one version to the next version, and eachMigration Step 38 exports itself to theXML Migration Manager 30 via the Dependency Injection Framework (DIF) 36. TheXML Migration Manager 30 is the core component that collects all of theMigration Steps 38, and then processes the migration. - Dependency Injection is a design pattern (i.e., a general, reusable template or approach) that decouples dependencies between a first object and a second object that is dependent on the first object. A dependency is a reliance of one data document, application or object on another data document, application or object. By decoupling dependencies between a first object and a second dependent object, Dependency Injection allows changes to be made to the first object without requiring changes to be made to the dependent second object just because changes were needed to the first object.
- According to an embodiment, the
Dependency Injection Framework 36 uses Dependency Injection principles to manage, e.g., remove, the dependencies between theXML Migration Manager 30 and theMigration Steps 38 so that theXML Migration Manager 30 does not need to know theMigration Steps 38 beforehand. Conventionally, when an application designs an XML document migration mechanism, the application must know how the XML schema within the XML document will be changed in future releases of the XML document. However, according to an embodiment, by having theDependency Injection Framework 36 manage the dependencies between theXML Migration Manager 30 and theMigration Steps 38 using Dependency Injection, theXML Manager 30 manages the information for each migration in a future release of the XML document without needing to know the XML schema beforehand. This is possible by using an abstract layer to abstract all of the characteristics of the migration (i.e., the current/source XML version, the target XML version and the XSLT document used to perform the XML transformation), so that when a new migration is executed, the only thing needed is to instruct theXSLT processor 26 how to convert the XML document. - As discussed hereinabove, the
XML Migration Manager 30 has two core components: the MigrationStep Container component 32 and the MigrationStep Executor component 34. The MigrationStep Container component 32 stores all of the migration steps that are collected by theDependency Injection Framework 36. The MigrationStep Container component 32 also determines a migration path from the first or begin version of the XML document to the last or end version of the XML document. - The Migration
Step Executor component 34 communicates with the MigrationStep Container component 32 to fetch the migration path. The MigrationStep Executor component 34 then executes the migration path step-by-step. As the MigrationStep Executor component 34 executes each migration step, the MigrationStep Executor component 34 uses the XSLT processor 26 (FIG. 2 ) to transform the XML document from one version to the next version. - The Migration
Step Container component 32 and the MigrationStep Executor component 34 depend on a set of Interfaces (shown inFIG. 4 ), which abstract all of the logic associated with the migration. Meanwhile, all of the migration steps also inherit the properties and methods from the same set of interfaces and provide concrete migration logic. Therefore, although theXML Migration Manager 30 does not have any knowledge about the concrete migration steps, theXML Migration Manager 30 can still execute the migration steps when an application is running. -
FIG. 4 is a schematic view of a class diagram 50 illustrating the relationship between the different objects that are used inFIG. 3 , according to an embodiment. Each of theMigration Steps 38 shown inFIG. 3 (i.e., Migration Steps 1-N) are represented asXMLUpgrade Steps 39 inFIG. 4 (i.e., XMLUpgradeStep1, XMLUpgradeStep2, XMLUpgradeStepx). Also, anXMLUpgradeStep 41 is a base class that represents the upgrade migration step. - According to an embodiment, the migration method supports both the upgrade of an XML document (e.g., release version 1.0 of an XML document to release version 2.0 of the XML document) as well as the downgrade of an XML document (e.g., release version 2.0 of an XML document to release version 1.0 of the XML document). An
IXMLUpgradeStep box 56 is an interface that represents the upgrade migration step. AnIXMLDowngradeStep box 58 is an interface that represents the downgrade migration step. It should be understood that although only the upgrade migration step is shown in detail, both the upgrade migration step and the downgrade migration step are similarly executed. - The Migration
Step Container component 32 is a sub-component of theXML Migration Manager 30, as discussed hereinabove. The MigrationStep Container component 32 declares its dependencies through theDependency Injection Framework 36. The MigrationStep Container component 32 then fills in these dependencies with all of the migrations steps 38. After receiving all of the migration steps 38, the MigrationStep Container component 32 stores the migration steps 38 into a dictionary for calculating the migration path from one version of the XML document to another version of the XML document. - Each migration step has two properties: a
CurrentVersion 52 and aNextVersion 54. TheCurrentVersion 52 is the version of theXML document 10 on which the migration step is applied. TheNextVersion 54 is the version of theXML document 10 that is generated after executing the migration step. TheCurrentVersion 52 and theNextVersion 54 are included within anIXMLMigrationStep 59, which is an interface that represents an abstraction of the migration step, which can be either an upgrade migration step or a downgrade migration step. By abstracting theMigration Steps 38, the Dependency Injection Framework 36 (and thus the XML Migration Manager 30) is no longer dependent on theMigration Steps 38. Instead, the Dependency Injection Framework 36 (and the XML Migration Manager 30) becomes dependent on theIXMLMigrationStep 59, as do theMigration Steps 38. - According to an embodiment, each
migration step 38 performs similarly to a singly linked list, in which one step points to the next step. When two versions of anXML document 10 are input into the MigrationStep Container component 32, the MigrationStep Container component 32 is able to determine a migration path, which is a sequence of migration steps from the first or begin version of theXML document 10 to the last or end version of the XML document. -
FIG. 5 is a schematic view of anexample migration path 70 used by theXML Migration Manager 30, according to an embodiment. Theexample migration path 70 is a migration path from an XML document version 2.1 to an XML document version 3.0. As shown, themigration path 70 includes a first migration step 72 (i.e., Migration Step 1), in which the Current Version is XML document version 2.1 and the Next Version is XML document version 2.2. Themigration path 70 also includes a second migration step 74 (i.e., Migration Step 2), in which the Current Version is XML document version 2.2 and the Next Version is XML document version 2.3. Themigration path 70 also includes a third migration step 76 (i.e., Migration Step 3), in which the Current Version is XML document version 2.3 and the Next Version is XML document version 2.4. Themigration path 70 also includes a fourth migration step 78 (i.e., Migration Step 4), in which the Current Version is XML document version 2.4 and the Next Version is XML document version 3.0 - As discussed hereinabove, the Migration
Step Executor component 34 is another sub-component of theXML Migration Manager 30. The main responsibility of the MigrationStep Executor component 34 is to query the MigrationStep Container component 32 to retrieve the migration path. After retrieving the migration path, the MigrationStep Executor component 34 iterates through each migration step to execute its migrate method, which uses the XSLT processor 26 (FIG. 2 ) to perform the transformation. When the migration is completed, the MigrationStep Executor component 34 reports the migration status and/or any handle errors. - One of the features of the
Migration Manager 30 and its migration method is greater extensibility (i.e., the ability to accommodate future growth) compared to conventional migration methods. The improved extensibility of theMigration Manager 30 and its migration method is the result of several features. First, all of the migration steps performed by theMigration Manager 30 are pluggable in theMigration Manager 30 with the help of theDependency Injection Framework 36, as shown inFIG. 3 . - Second, the Migration
Step Container component 32 and the MigrationStep Executor component 34 do not depend on any of the concrete migration steps. According to an embodiment, the MigrationStep Container component 32 and the MigrationStep Executor component 34 apply the Inversion of Control (loc) Principle. That is, the flow of control, i.e., the functions performed by the MigrationStep Container component 32 and the MigrationStep Executor component 34 as part of the migration method, is received from a generic framework, i.e., theDependency Injection Framework 36. The use of the Inversion of Control (loc) Principle increases modularity of the migration method, and thus makes the migration method more extensible. - Third, an XSLT script is embedded within each migration step. The embedded XSLT script is processed by the XSLT processor 26 (
FIG. 2 ). By using XLST technology, theXML Migration Manager 30 eliminates a lot of duplicate source code for the XML document processing. - According to an embodiment, other features of the migration method described herein demonstrate improved extensibility compared to conventional migration methods. For example, the migration method described herein not only supports the upgrade of an XML document, but also supports the downgrade of an XML document by providing downgrade migration steps. According to an embodiment, the downgrade migration steps are performed by the Migration
Step Container component 32 and the MigrationStep Executor component 34 in the same manner as the upgrade steps are performed. - Also, the migration method described herein reduces the effort involved in modifying the source code for a migration between chronological releases. According to an embodiment, only one new migration step is added, but no other modifications are required to the migration method.
- Also, the migration method described herein reduces the effort involved in delivering a patch for a migration from an Interim Correction (IC) released later to a higher version, which is released earlier.
FIG. 6 is a schematic view of a portion of anexample migration 80 using theXML Migration Manager 30, according to an embodiment, in which an Interim Correction (IC) is released later than the earlier released higher version. Theexample migration path 80 is a migration path from an XML document version 2.3 to an XML document version 3.1. As shown, themigration path 80 includes a migration step 82 (i.e., Migration Step 3), in which the Current Version is XML document version 2.3 and the Next Version is XML document version 2.4. Themigration path 80 also includes another migration step 84 (i.e., Migration Step 4), in which the Current Version is XML document version 2.4 and the Next Version is XML document version 3.0. Themigration path 70 also includes another migration step 86 (i.e., Migration Step 5), in which the Current Version is XML document version 3.0 and the Next Version is XML document version 3.1. - However, according to an embodiment, if an Interim Correction (IC) is later released, the
migration path 80 includes anew migration step 88, 89 (i.e.,Migration Step 4a andMigration Step 4b) as a patch. In thenew migration step 88, the Current Version is XML document version 2.4 and the Next Version is XML document version 2.5 (IC), and in thenew migration step 89, the Current Version is XML document version 2.5 (IC) and the Next Version is XML document version 3.0. - According to an embodiment, the migration method described herein can be used to migrate other data, with relatively little modification to the migration method. For example, for database migration, the XSLT script is replaced with a Structured Query Language (SQL) script.
- It will be apparent to those skilled in the art that many changes and substitutions can be made to the embodiments described herein without departing from the spirit and scope of the disclosure as defined by the appended claims and their full scope of equivalents.
Claims (18)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/955,829 US20190324798A1 (en) | 2018-04-18 | 2018-04-18 | Method and system for migrating xml schemas in application releases |
US16/907,467 US11157310B2 (en) | 2018-04-18 | 2020-06-22 | Method and system for migrating XML schemas in application releases |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/955,829 US20190324798A1 (en) | 2018-04-18 | 2018-04-18 | Method and system for migrating xml schemas in application releases |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/907,467 Division US11157310B2 (en) | 2018-04-18 | 2020-06-22 | Method and system for migrating XML schemas in application releases |
Publications (1)
Publication Number | Publication Date |
---|---|
US20190324798A1 true US20190324798A1 (en) | 2019-10-24 |
Family
ID=68236931
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/955,829 Abandoned US20190324798A1 (en) | 2018-04-18 | 2018-04-18 | Method and system for migrating xml schemas in application releases |
US16/907,467 Active US11157310B2 (en) | 2018-04-18 | 2020-06-22 | Method and system for migrating XML schemas in application releases |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/907,467 Active US11157310B2 (en) | 2018-04-18 | 2020-06-22 | Method and system for migrating XML schemas in application releases |
Country Status (1)
Country | Link |
---|---|
US (2) | US20190324798A1 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112883008A (en) * | 2019-11-29 | 2021-06-01 | 阿里巴巴集团控股有限公司 | Data migration method, device, system and storage medium |
US11178005B2 (en) | 2020-04-13 | 2021-11-16 | Oracle International Corporation | Methods, systems, and computer readable media for managing multiple software defined wide area network (SD-WAN) software versions |
US20220164223A1 (en) * | 2020-11-25 | 2022-05-26 | International Business Machines Corporation | Anticipated containerized infrastructure used in performing cloud migration |
US11374887B2 (en) * | 2019-10-29 | 2022-06-28 | Google Llc | Automated assistant architecture for preserving privacy of application content |
US11502918B2 (en) | 2014-12-23 | 2022-11-15 | Talari Networks Incorporated | Methods and apparatus for providing adaptive private network database schema migration and management processes |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040044965A1 (en) * | 2002-04-30 | 2004-03-04 | Haruhiko Toyama | Structured document edit apparatus, structured document edit method, and program product |
US20070079282A1 (en) * | 2005-09-30 | 2007-04-05 | Pawan Nachnani | Browser based designer and player |
US20100077380A1 (en) * | 2008-09-25 | 2010-03-25 | International Business Machines Corporation | Framework for automatically merging customizations to structured code that has been refactored |
US7818665B1 (en) * | 2006-06-22 | 2010-10-19 | Advanced Micro Devices, Inc. | Method and system for schema version transform verification |
US20170048314A1 (en) * | 2014-02-21 | 2017-02-16 | Hewlett Packard Enterprise Development Lp | Migrating cloud resources |
-
2018
- 2018-04-18 US US15/955,829 patent/US20190324798A1/en not_active Abandoned
-
2020
- 2020-06-22 US US16/907,467 patent/US11157310B2/en active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040044965A1 (en) * | 2002-04-30 | 2004-03-04 | Haruhiko Toyama | Structured document edit apparatus, structured document edit method, and program product |
US20070079282A1 (en) * | 2005-09-30 | 2007-04-05 | Pawan Nachnani | Browser based designer and player |
US7818665B1 (en) * | 2006-06-22 | 2010-10-19 | Advanced Micro Devices, Inc. | Method and system for schema version transform verification |
US20100077380A1 (en) * | 2008-09-25 | 2010-03-25 | International Business Machines Corporation | Framework for automatically merging customizations to structured code that has been refactored |
US20170048314A1 (en) * | 2014-02-21 | 2017-02-16 | Hewlett Packard Enterprise Development Lp | Migrating cloud resources |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11502918B2 (en) | 2014-12-23 | 2022-11-15 | Talari Networks Incorporated | Methods and apparatus for providing adaptive private network database schema migration and management processes |
US11374887B2 (en) * | 2019-10-29 | 2022-06-28 | Google Llc | Automated assistant architecture for preserving privacy of application content |
US11750544B2 (en) | 2019-10-29 | 2023-09-05 | Google Llc | Automated assistant architecture for preserving privacy of application content |
CN112883008A (en) * | 2019-11-29 | 2021-06-01 | 阿里巴巴集团控股有限公司 | Data migration method, device, system and storage medium |
US11178005B2 (en) | 2020-04-13 | 2021-11-16 | Oracle International Corporation | Methods, systems, and computer readable media for managing multiple software defined wide area network (SD-WAN) software versions |
US20220164223A1 (en) * | 2020-11-25 | 2022-05-26 | International Business Machines Corporation | Anticipated containerized infrastructure used in performing cloud migration |
US11748153B2 (en) * | 2020-11-25 | 2023-09-05 | International Business Machines Corporation | Anticipated containerized infrastructure used in performing cloud migration |
Also Published As
Publication number | Publication date |
---|---|
US11157310B2 (en) | 2021-10-26 |
US20200319920A1 (en) | 2020-10-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11157310B2 (en) | Method and system for migrating XML schemas in application releases | |
US8887135B2 (en) | Generating test cases for functional testing of a software application | |
US8286132B2 (en) | Comparing and merging structured documents syntactically and semantically | |
US7689582B2 (en) | Data flow system and method for heterogeneous data integration environments | |
US7739267B2 (en) | Classification and sequencing of mixed data flows | |
US9218137B2 (en) | System and method for providing data migration services | |
US8381176B1 (en) | Software build orchestration framework | |
US8583413B2 (en) | Computer method and apparatus for chaining of model-to-model transformations | |
EP1657649A2 (en) | System and method for transforming legacy documents into XML documents | |
US7689947B2 (en) | Data-driven finite state machine engine for flow control | |
US10824968B2 (en) | Transformation of logical data object instances and updates to same between hierarchical node schemas | |
US20110153562A1 (en) | Error prevention for data replication | |
US8346725B2 (en) | Evolution of XML schemas involving partial data copy | |
US8738569B1 (en) | Systematic verification of database metadata upgrade | |
CN110083617B (en) | DDL statement processing method and device, electronic device and medium | |
US7831955B2 (en) | Development and execution platform | |
US20090204953A1 (en) | Transforming data structures between different programming languages | |
US20130086013A1 (en) | System and method of saving files to a version control system ("vcs") repository | |
CN105488170B (en) | A kind of approaches to IM and device of ERP system | |
AU2016100156A4 (en) | Data Structure, Model for Populating a Data Structure and Method of Programming a Processing Device Utilising a Data Structure | |
JP2009175854A (en) | Program, method and computer system for securing data consistency | |
CN116226066B (en) | Low code platform code synchronization method and device, electronic equipment and storage medium | |
CN110196965A (en) | The method and device of XML file conversion Word file | |
Candillon et al. | XQuery Design Patterns | |
JP4120879B2 (en) | Program generation system and method and program thereof |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
AS | Assignment |
Owner name: WELLS FARGO BANK NA, NEW YORK Free format text: SECURITY INTEREST;ASSIGNOR:UNISYS CORPORATION;REEL/FRAME:046860/0832 Effective date: 20180827 |
|
AS | Assignment |
Owner name: UNISYS CORPORATION, PENNSYLVANIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ZOU, ZHONGHUI BEN;TANG, YUANZHI MICHAEL;WANG, CHAOSONG;REEL/FRAME:047136/0056 Effective date: 20180419 |
|
AS | Assignment |
Owner name: JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT, ILLINOIS Free format text: SECURITY INTEREST;ASSIGNOR:UNISYS CORPORATION;REEL/FRAME:051685/0561 Effective date: 20180827 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS |
|
AS | Assignment |
Owner name: WELLS FARGO BANK, NATIONAL ASSOCIATION, MINNESOTA Free format text: SECURITY INTEREST;ASSIGNOR:UNISYS CORPORATION;REEL/FRAME:054481/0865 Effective date: 20201029 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE |