Methods and systems for program migration

[0001] This application claims the benefit of, and incorporates by reference in its entirety, Provisional Application Serial No. 60/366,831 titled Methods and Systems for Program Migration, filed Mar. 22, 2002.

[0002] This invention relates to providing compatibility for a pre-existing program (e.g., a word processor application) in a new data processing environment. In particular, the present invention relates to migrating a program from the server environment in which the program was originally developed to a new server environment.

[0003] A software developer typically writes a program under the assumption that the program will run in a particular server environment. The server environment includes, for example, the support and resources available to programs running in that server environment. As an example, the server environment may include a user-interface run-time library that implements windowing functions or a core library of Java routines.

[0004] Knowing the server environment, the developer may then incorporate features provided by that server environment into the program under development. Thus, for example, the developer may include in the program a call to the user-interface run-time library to open a window on a display.

[0005] In many instances, server environments provide a core set of common functionality regardless of the specific server environment or the machine on which the server environment runs. Thus, for example, most server environments that support the Java programming language implement a common core set of support libraries. For that reason, a Java program written for one server environment will often run without modification in a different server environment.

[0006] However, server environments commonly provide proprietary extensions to, for example, common core support libraries. A developer will often incorporate one or more of the proprietary extensions into the program under development in order to enhance the functionality of the program. There are few drawbacks in doing so, as the program remains targeted for execution in the server environment that supports the proprietary extensions.

[0007] In many instances, however, the developer needs to move the program to a new server environment. For example, the program may become quite popular, and marketing opportunities may therefore exist if the program could be sold to a wider audience than only those individuals running the original server environment for which the program was initially developed. Unfortunately, when the program incorporates proprietary extensions, or, more generally, any server environment specific support or functionality, it can be quite difficult to migrate the program to the destination server environment.

[0008] Migrating the program to the destination server environment requires a detailed knowledge of the incompatibilities between the source server environment and the destination server environment. It further requires a great deal of effort to resolve every incompatibility while still giving the program the functionality it was intended to have. Thus, a substantial investment in time, developer resources, and money may be required to migrate the program to the destination server environment.

[0009] Therefore, a need has long existed for a program migration tool that overcomes the problems noted above and others previously experienced.

[0010] Methods and systems consistent with the present invention provide program migration from a source server environment to a destination server environment. The program migration typically saves substantial developer time and resources that would otherwise be required to support the program in the destination server environment. Thus, programs may be made available to many more potential customers in a shorter period of time, for less cost.

[0011] According to one aspect of the present invention, such methods and systems, as embodied and broadly described herein, include migrating a source project file-by-file to a destination project. For each file, the migration program determines incompatibilities in the file between the source server environment and the destination server environment. The migration program then makes appropriate substitutions (e.g., by replacing proprietary function calls) to render the file compatible with the destination server environment. Thus, the methods and systems eliminate significant developer time and attendant expense that would otherwise be necessary to migrate a program to the destination server environment.

[0012] Methods and systems consistent with the present invention overcome the shortcomings of the related art, for example, by maintaining a mapping database of proprietary extensions used in a source server environment with corresponding compatibility replacements for a destination server environment. Furthermore, the methods and systems provide conversion of deployment descriptor files from the source server environment to the destination server environment. Thus, developer time and resources are not unduly expended in an attempt to migrate a program manually.

[0013] In accordance with methods consistent with the present invention, a method is provided for migrating programs. The method migrates a source program written for a source server environment to a destination server environment. The method includes the steps of obtaining an input selection of at least one file of the source program, and, for each source file in the input selection, determining a file type for the source file and creating a corresponding destination program file compatible with the destination server environment based on the file type.

[0014] In accordance with systems consistent with the present invention, a data processing system is provided. The data processing system includes a memory comprising a program migration tool. The program migration program tool obtains an input selection of at least one file of a source program, and for each source file in the input selection, determines a file type for the source file, and creates a corresponding destination program file compatible with a destination server environment based on the file type. The data processing system further includes a processor that runs the migration program.

[0015] In accordance with articles of manufacture consistent with the present invention, a computer-readable medium is provided. The computer-readable medium contains instructions that cause a data processing system to perform a method for program migration of a source program written for a source server environment to a destination server environment. The method includes the steps of obtaining an input selection of at least one file of the source program, and, for each source file in the input selection, determining a file type for the source file; and creating a corresponding destination program file compatible with the destination server environment based on the file type.

[0016] Other apparatus, methods, features and advantages of the present invention will be or will become apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the present invention, and be protected by the accompanying drawings.

[0017] FIG. 1 depicts a block diagram of a data processing system suitable for practicing methods and implementing systems consistent with the present invention.

[0018] FIG. 2 depicts a flow diagram showing processing performed by the program migration tool running in the memory of the data processing system of FIG. 1.

[0019] FIG. 3 depicts an exemplary deployment script created by the program migration tool running the memory of the data processing system of FIG. 1.

[0020] FIG. 4 depicts a flow diagram of the steps taken by the program migration tool running in the memory of the data processing system of FIG. 1 in order to provide compatibility in a destination server environment for proprietary extensions of a source server environment.

[0021] FIG. 5 depicts a flow diagram of the steps taken by the program migration tool running in the memory of the data processing system of FIG. 1 in order to provide compatibility in a destination server environment for deployment descriptor files from a source server environment.

[0022] FIG. 6 depicts an exemplary document type definition for migrating a deployment descriptor file from a source server environment to a destination server environment by the migration program 116 running in the memory of the data processing system of FIG. 1.

[0023] FIG. 7 depicts a data structure accessed by the migration program running in the data processing system shown in FIG. 1 that stores proprietary extension entries paired with corresponding compatibility replacements accessed by the migration program during creation of a destination program file that is compatible with a destination server environment.

[0024] Reference will now be made in detail to an implementation in accordance with methods, systems, and products consistent with the present invention as illustrated in the accompanying drawings. The same reference numbers may be used throughout the drawings and the following description to refer to the same or like parts.

[0025] FIG. 1 depicts a block diagram of a data processing system 100 suitable for practicing methods and implementing systems consistent with the present invention. The data processing system 100 comprises a central processing unit (CPU) 102, an input/output I/O unit 104, a memory 106, a secondary storage device 108, and a video display 110. The data processing system 100 may further include input devices such as a keyboard 112 or a mouse 114.

[0026] The memory 106 contains a migration program 116 that operates on one or more files in a source project 118. The source project 118 comprises the files (e.g., source code files, configuration files, libraries, makefiles, deployment descriptors, and the like) that implement a program for a source server environment (e.g., the IBM Websphere Application Server). As an example, the source project 118 may implement an on-line bank application or other web based application.

[0027] The migration program 116 creates the destination project 120. The destination project 120 comprises the files that implement the program for the destination server environment (e.g., the Sun Microsystems iPlanet Application Server). To that end, the migration program 116 includes a deployment descriptor mapper 122 and an extension difference mapper 124 that will be described in more detail below. As an initial matter, however, it is noted that in the course of generating the destination program 120, the migration program 116 accesses the mapping database 126 to match a proprietary extension 128 (e.g., a call to a proprietary function in the source server environment) to a compatibility replacement 130 in the destination server environment.

[0028] The proprietary extension 128 is typically a call to a proprietary function, a Java Server Page (JSP) extension, or the like, supported by the source server environment. The compatibility replacement 130 is a mapping database 126 entry that specifies a function, extension, or the like that provides similar or identical functionality in the destination server environment. The compatibility library 132 stores the object, routines, and the like that provide compatibility as indicated by the mapping database 126.

[0029] Although aspects of the present invention are depicted as being stored in memory 106, one skilled in the art will appreciate that all or part of systems and methods consistent with the present invention may be stored on or read from other computer-readable media, for example, secondary storage devices such as hard disks, floppy disks, and CD-ROMs; a signal received from a network such as the Internet; or other forms of ROM or RAM either currently known or later developed. Thus, for example, the mapping database 126 may be stored either in main memory 106 or on the secondary storage device 108. Further, although specific components of data processing system 100 are described, one skilled in the art will appreciate that a data processing system suitable for use with methods, systems, and articles of manufacture consistent with the present invention may contain additional or different components.

[0030] The overview provided below gives a summary of the steps taken by the migration program 116 for migrating a program from the IBM Websphere Application Server to the Sun Microsystems iPlanet Application Server running the Java 2 Enterprise Edition (J2EE) platform. The migration program 116 is not limited to any specific source or destination server or server software, however. Rather, the migration program 116 may generally be used to replace proprietary elements in a program with compatible replacements for a selected execution environment.

[0031] With regard to the IBM Websphere Application Server and the Sun Microsystems iPlanet Application Server, for example, incompatibilities can arise from proprietary Java API extensions, custom JSP tag extensions, application server specific deployment descriptors, and application server specific configuration parameters. As will be explained in more detail below, the migration program 116 initially accepts a selection of source project 118 files, or a selection of a directory containing the source project 118 files, as well as a selection for an output or destination directory. The migration program 116 then proceeds to migrate the source program 118 file-by-file to create the destination project 120 in the destination directory.

[0032] The types of files that the migration program 116 works with include, as examples, source files for Java application components, JSPs, servlets, Enterprise Java Beans (EJBs), Java helper files, Java application server deployment descriptors, eXstensible Markup Language (XML) deployment descriptors, application server configuration files, and the like. The migration program 116 may recognize the foregoing files, for example, according to their file extensions (e.g., .java, .jsp, .xml, .xmi). The migration program 116, for unsupported types of files, or files that do not need special processing (e.g., a file of text messages), may copy the file directly to the destination directory without modification. A migration report generated by the migration program 116 specifies which files were copied without modification, which files were migrated successfully, and which files were migrated unsuccessfully. In addition, the migration program 116 generates a deployment script that includes instructions for assembling the destination project 120 on the iPlanet Application Server.

[0033] The migration program 116 replaces proprietary extensions supported by the source server environment with compatible extensions supported by the destination server environment. In particular, the data processing system 100 provides the compatibility library 132 that includes functions specifically implemented for compatibility between the source and destination server environments. Furthermore, the migration program 116 maps custom JSP tag extensions supported by the source server environment to compatible tag extensions for the destination server. A further mapping converts XML deployment descriptor files (e.g., standard files such as ejb-jar.xml, weblogic-ejb-jar.xml, ibm-ejb-jar-bnd.cmi, and ibm-ejb-jar-ext.xmi) to corresponding destination server environment files (e.g., ias-ejb-jar.xml). Yet another mapping performed by the migration program 116 maps CMP deployment descriptor files with finder methods (e.g., in weblogic-cmp-rdbms-jar.xml) to corresponding XXX-ias-cmp.xml files (where XXX is the name of the EJB).

[0034] The operation of the migration tool 116 is described in more detail next, starting with FIG. 2.

[0035] Turning to FIG. 2, that figure depicts a flow diagram showing processing performed by the migration program 116 running in the memory of the data processing system of FIG. 1. The migration program 116 obtains an input selection for files in the source project 118 (step 202). The input selection may be, for example, a directory selection, or a specific selection of one or more files. When the input selection is a directory selection, the migration program 116 migrates files from the directory one-by-one into a selected output directory. The migration program 116 then retrieves the first file specified by the input selection (step 204).

[0036] Having retrieved the first file, the migration program 116 determines the type of the file, for example, by examining the file name extension or reading a portion of the file itself (step 206). For example, an html file may be identified by reading a line in the file that includes the <html> tag. Deployment descriptor files may be identified by a .xml or .xmi extension, for example, while extension files (e.g., source code and server page) files may be identified by a .java or .jsp extension.

[0037] The migration program 116 determines whether the file is a deployment descriptor file (step 208). If so, the migration program 116 converts the file into a format compatible with the destination server in a manner described in more detail below (step 210). The migration program 116 then determines whether there are more files to be migrated (step 212). If so, the migration tool obtains the next file (step 214) and continues at step 206.

[0038] Instead of a deployment descriptor file, the file may be one that possibly includes proprietary extensions. For example, the file may be a Java source code file with calls to proprietary functions, or a JSP file that uses proprietary tag extensions. The program migration tool determines if the current file is one that may include proprietary extensions (step 216). If so, the migration program 116 converts the file by replacing the proprietary extensions with a compatibility replacement in a manner described in more detail below (step 218). The migration program 116 then determines whether there are more files to be migrated (step 212).

[0039] The input file may be a configuration file (determined at step 220), for example weblogic.properties for the WebLogic Application Server 5.1. The migration program 116 recognizes the file names of configuration files and translates the configuration files for the destination application server (step 222) as described in more detail below.

[0040] When the input file is not any of the above types, or does not need any special processing (determined at step 224), the migration program 116 typically copies the input file (for example, a file of text messages or an .html file) without modification to the destination directory (step 226).

[0041] The migration program 116 also creates a script for the destination project 120 (step 228). In one embodiment, the script is a Unix shell script using Ant (which is a Java based tool that serves as an alternative to the Unix make command). The script includes commands for compiling and assembling the destination project 120 in the destination server environment. An exemplary script is shown in FIG. 3.

[0042] After the migration program 116 has processed each file in the input selection, the migration program creates a migration report (step 230). The migration report may include, as examples, entries that specify which files migrated successfully, which files failed to migrate, and which files were copied without modification. With regard to a file that includes proprietary extensions, the file migrates successfully when each proprietary extension can be substituted for a compatibility replacement. With regard to deployment descriptor files, the file migrates successfully when (as described in more detail below) the file can be made consistent with the Document Type Definition (DTD) format of the destination server environment. Such files may not migrate successfully, as examples, when the source file is not well formed, does not conform to a source DTD format, or when the source file requires other files that cannot be found in the input selection. The migration report may also include a list of generated scripts.

[0043] As noted above with regard to FIG. 2 and step 218, the migration program 116 (and in particular, the extension difference mapper 124 of the migration program 116) provide compatibility in a destination server environment for proprietary extensions of a source server environment. With regard next to FIG. 4, that figure depicts a flow diagram of the steps taken by the extension difference mapper 124.

[0044] The mapper 124 scans each input file for proprietary extensions (step 402). To that end, the mapper 124 compares statements in the input file against entries in the mapping database 126 to identify proprietary extensions. The mapping database 126 may be implemented, for example, as an XML file containing mapping pairs of proprietary extensions 128 and corresponding compatibility replacements 130. For example, an exemplary mapping pair for an API extension is shown below in Table 1.

TABLE 1
Proprietary Extension Name	Compatibility Replacement Name
weblogic.db.jdbc.Column	sun.iasmt.compat.weblogic_5_1_0.weblogic.db.jdbc.Column

[0045] An exemplary mapping pair for a JSP extension is shown below in Table 2:

TABLE 2
Proprietary Extension Name	Compatibility Replacement Name
<wl:repeat>	wl/taglib.tld
	In taglib.tld, there is a mapping of the name
	repeat to the tagclass
	sun.iasmt.compat.weblogic_5_1_0.weblogic.jsp.Repeat

[0046] The compatibility replacements 130 are functions, objects, tag extensions, and the like for the destination server that are created (prior to migration) and stored in the compatibility library 132. When the mapper 124 finds a proprietary extension, the mapper 124 then searches the mapping database 126 for a compatibility replacement (step 404). Next, the mapper 124 replaces the proprietary extension in the source file with the compatibility replacement 130 specified by the mapping database 126 (step 406). The mapper 124 continues until it finds no more proprietary extensions in the source file.

[0047] Referring again to FIG. 2, at step 210, the migration program 116 (and in particular the deployment descriptor mapper 122) migrates deployment descriptor files. In one embodiment, the mapper 122 uses Java Architecture for XML Binding (JAXB) to assist the migration process. JAXB provides an API and a tool that allow two-way mapping between XML documents and Java objects. With a given Document Type Definition (DTD), the JAXB compiler generates Java classes that allow developers to build applications that can read, manipulate and recreate XML documents without writing any logic to process XML elements. Typically, the source server environment and the destination server environment specify predetermined file names for required deployment descriptor files. For that reason, the mapper 122 typically generates specific files given the input files from the source server environment. An example of the deployment descriptor files for the WebLogic 5.1 server and WebSphere 4.0 server and their counterparts in the iPlanet server (iAS 6.5) is shown below in Table 3:

	TABLE 3
	WebLogic 5.1	iAS 6.5
	weblogic-ejb-jar.xml	ias-ejb-jar.xml
	ejb-jar.xml
	weblogic-cmp-rdbms-jar.xml	<EJB_NAME>-ias-cmp.xml
	ejb-jar.xml
	weblogic.xml	ias-web.xml
	web.xml
	WebSphere 4.0	iAS 6.5
	ejb-jar.xml	ias-ejb-jar.xml
	ibm-ejb-jar-bnd.xmi
	ibm-ejb-jar-ext.xmi
	ejb-jar.xml	<EJB_NAME>-ias-cmp.xml
	ibm-ejb-jar-bnd.xmi
	ibm-ejb-jar-ext.xmi
	server-cfg.xml	ias-web.xml
	ibm-web-ext.xmi
	ibm-web-bnd.xmi
	web.xml

[0048] FIG. 5 depicts a flow diagram of the steps taken by the mapper 122 to migrate deployment descriptor files for the source destination server environment (in the example in FIG. 5, ejb-jar.xml and weblogic-ejb-jar.xml) to the deployment descriptor file for destination server environment file (ias-ejb-jar.xml). Note that for each XML file in Table 3, an appropriate DTD file for JAXB is available with the iPlanet Application Server installation in the <iAS_install>/ias/dtd/ directory. For example, IASPersistence_manager10.dtd (shown in FIG. 6) provides a DTD specification for migrating the <EJB_NAME>-ias-cmp.xml file.

[0049] The mapper 122 first generates an ejb-jar class using the JAXB tool (step 501), then instantiates an object of the class ejb-jar (step 502). The mapper 122 then uses JAXB to unmarshal the ejb-jar.xml file (step 504). In other words, the mapper 122 populates the JAXB generated class object with data in the corresponding XML document. Similarly, the mapper 122 generates a weblogic-ejb-jar class using the JAXB tool (step 505), instantiates an object of the class weblogic-ejb-jar (step 506) and unmarshals the weblogic-ejb-jar file to populate the instantiated object (step 508).

[0050] Next, the mapper 122 generates an ias-ejb-jar class using the JAXB tool (step 509) and instantiates an object of the class ias-ejb-jar (step 510). Once instantiated, the mapper 122 then initializes members of the ias-ejb-jar object using data from the ejb-jar and weblogic-ejb-jar objects (step 512). In other words, the mapper 122 copies the data out of the objects corresponding to the source server environment deployment descriptor files into an object that is compatible with the destination server environment. The mapper 122 then marshals the ias-ejb.jar object to the ias-ejb-jar.xml file (step 514).

[0051] The marshalling process creates the .xml file with data from the Java object according to the DTD file defining the .xml file. In other words, the mapper 122, using JAXB generates a deployment descriptor file (ias-ejb-jar.xml) for the destination server environment based on the deployment descriptor files (ejb-jar.xml and weblogic-ejb-jar.xml) for the source server environment. Additional details of the operation of JAXB may be found, for example, at: http://developer.java.sun.com/.

[0052] The mapper 124 may also use the mapping database 126 when converting configuration files. When the mapper 124 encounters a proprietary extension in the configuration file, the mapper 124 retrieves a compatibility extension from the mapping database 126 and uses the compatibility extension in the output file. For example, the Weblogic 5.1 server uses a file named weblogic.properties that includes configuration information with regard to databases. The mapper 124 recognizes the introductory fixed syntax weblogic.jdbc.connectionPool.ExampleApplication and a following database driver specification (e.g., driveroracle.jdbc.driver.OracleDriver). The mapper 124 retrieves mapping information for the corresponding database from the mapping database 126 in order to generate the migrated file and may optionally create a script to register the database with the iPlanet Application Server. The source configuration file and an exemplary migrated file is shown below in Table 4:

TABLE 4
WebLogic 5.1 weblogic.properties file
weblogic.jdbc.connectionPool.ExampleApplication
	urljdbc:oracle:thin:129.145.x.y:1521:orcl,
	driveroracle.jdbc.driver.OracleDriver,
	initialCapacity2,
	maxCapacity8,
	capacityIncrement1,
	allowShrinkingtrue,
	shrinkPeriodMins15,
	refreshMinutes10,
	propsusertmb_user;passwordtmb_user,
	testTableCUSTOMER
iAS 6.5 application.xml migrated file
<ias-resource>
<resource>
<jndi-name>jdbc/ExampleApplication</jndi-name>
<jdbc>
<driver-type>oracle.jdbc.driver.OracleDriver</driver-type>
<database-url>jdbc:oracle:thin10.100.a.b:1521:SUNLAB</database-url>
<username>tmb_user</username>
<password>tmb_user</password>
</jdbc>
</resource>
</ias-resource>

[0053] Turning briefly to FIG. 7, that figure illustrates a data structure 700 that stores the mapping pairs of proprietary extensions 702, 706, 710, 714 and corresponding compatibility replacements 704, 708, 712, 716. For example, FIG. 7 shows the <wl:repeat> tag mapped to the wl/taglib.tld file that provides a mapping to the tagclass specified above in Table 2. The mapping pairs may be, for example, entries in an XML text file.

[0054] The compatibility replacements 130 are functions, objects, tag extensions, and the like for the destination server that are created (prior to migration) and stored in the compatibility library 132. When the mapper 124 finds a proprietary extension, the mapper 124 then searches the mapping database 126 for a compatibility replacement (step 404). Next, the mapper 124 replaces the proprietary extension in the source file with the compatibility replacement 130 specified by the mapping database 126 (step 406). The mapper 124 continues until it finds no more proprietary extensions in the source file.

[0055] In one embodiment, the migration program 116 is designed in accordance with the Model-View-Controller (MVC) software architecture. The MVC architecture is described, for example, in Chapter 3 of Definitive Guide to Swing for Java 2, Second Edition, by John Zukowski, Apress 2000. Generally, the MVC architecture is an architecture for interactive programs that partitions the program so that it is scalable, maintainable, and re-usable. The Model section segments out underlying information (e.g., data structures) that the program manipulates. The View section provides the code that produces output on a display. The Controller section provides the code that handles user interaction and determines how to respond.

[0056] The foregoing description of an implementation of the invention has been presented for purposes of illustration and description. It is not exhaustive and does not limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practicing of the invention. For example, the described implementation includes software but the present invention may be implemented as a combination of hardware and software or in hardware alone. Note also that the implementation may vary between systems. The invention may be implemented with both object-oriented and non-object-oriented programming systems.