Chapter 10 - Developing: Applications - Introduction

Article
12/05/2007

Introduction and Goals

The focus of Chapters 10 through 17 is connecting existing Oracle applications in the UNIX environment to the migrated Microsoft® SQL Server™ database. This chapter serves as an introduction to the application-oriented development chapters.

The following list provides an overview of the content in each of the application-oriented development chapters:

Chapter 11, Developing: Applications — Oracle SQL and PL/SQL. This chapter provides a detailed discussion of the SQL usage differences between Oracle and SQL Server. Transformation of PL/SQL to T-SQL is also covered.
Chapter 12, Developing: Applications — Perl. This chapter discusses the strategies available for migrating a Perl application for use with the SQL Server environment.
Chapter 13, Developing: Applications — PHP. This chapter discusses the strategies available for migrating a PHP application for use with the SQL Server environment.
Chapter 14, Developing: Applications — Java. This chapter discusses the strategies available for migrating a Java application for use with the SQL Server environment.
Chapter 15, Developing: Applications — Python. This chapter discusses the strategies available for migrating a Python application for use with the SQL Server environment.
Chapter 16, Developing: Applications — Oracle Pro*C. This chapter discusses the strategies available for migrating a Pro*C application for use with the SQL Server environment.
Chapter 17, Developing: Applications — Oracle Forms. This chapter discusses the strategies available for migrating an Oracle Forms application for use with the SQL Server environment.

No application migration will be successful without a clear understanding of the Oracle technologies that are factors during an Oracle database migration to SQL Server. An overview of these basic technologies and specific migration considerations is discussed in the following two sections. The application ecosystem can be broken into the following two tiers:

Data access
Programming language and connectivity tier

Data access comprises the components of the application that interact with the database data. SQL is the language used for retrieving and manipulating the database data. The application developer is responsible for ensuring that applications designed for the Oracle source database work the same way with the migrated SQL Server target database. The changes required vary based on the programming language support and the API libraries available for SQL Server. The migration of SQL and PL/SQL components to T-SQL forms a common requirement, irrespective of the changes to the rest of the application. The migrated applications then have to be tested against the migrated SQL Server database to ensure their original functionality.

From an application developer's perspective, Oracle and SQL Server manage data in similar ways. The internal differences between Oracle and SQL Server are significant, but if managed properly, these differences will have minimal impact on a migrated application.

Application Migration Strategies

There are four different strategies for application migration that are discussed throughout the development chapters. These strategies include:

Interoperation. The application components remain in the UNIX environment.
Port or rewrite the application to the Microsoft .NET platform. The application is migrated to run on the .NET framework.
Port or rewrite the application to the Microsoft Win32® platform. The application is migrated to run on the Windows® environment using the Win32 API.
Quick port using Windows Services for UNIX 3.5. The application is ported to use Interix within the Windows environment.

Each of the four strategies is discussed in more detail under the following headings. One, some, or all of these solution design strategies forms the basis of the solution concept that was completed during the Envisioning Phase. Even when the goal is to standardize on the Windows platform, some of these strategies may be employed as intermediary steps in a multi-phased migration.

In general, .NET development is favored over Win32, but a number of recommendations in the following chapters provide guidance on migrating to a Win32 solution. This information is provided in cases where a Win32 migration is the most cost-effective and straightforward development route.

For more information on these migration strategies, see "Application and Database Migration Solution Design Strategy" in Chapter 2, "Envisioning Phase."

Interoperation

In this strategy, the application remains on the UNIX platform, while only the database is migrated to SQL Server on the Windows platform. This strategy is employed when minor changes can be made to the source code, connection strings, or the connectivity layer to allow for the change in the back end database.

Often, an interoperation strategy is used as an interim step in a phased migration. This strategy allows for the application to be quickly connected to the solution's SQL Server database with minimal risk or effort. However, this would not be an adequate solution if one of the business requirements for the migration project is elimination of the UNIX environment.

Port or Rewrite to .NET Framework

The .NET framework is the next generation platform from Microsoft for building, deploying, and running Windows applications. It provides a highly productive, standards-based, multi-language environment for integrating existing investments with next-generation applications and services. When porting or rewriting, migration to the .NET platform is preferred because it is the current development platform for Windows applications.

When migrating an application to the .NET framework, there are two different options. One is to perform a full port of the application, and the other is to rewrite the application using the .NET application programming interfaces (APIs).

As of this writing, with the increased adoption of the .NET Framework in the industry, the availability of the .NET APIs for application porting are expanding. For some of the languages, the drivers are in beta with support being improved to include all functionality. Verify the stability of the library and the support for all the function calls needed for SQL Server when picking a driver.

A rewrite of the application is required when there is no support on the .NET platform for the language in use. An example of this would be an application based on Oracle Forms. The best option in this case would be to rewrite the application on Windows using Visual Basic® .NET.

Rewriting an application can potentially pose challenges. It can be a time-consuming, risky, and costly option. The risk inherent in a rewrite is that the business logic or an important functionality is inadvertently changed while rewriting the code. Careful testing and stabilizing of the rewritten application needs to be conducted to ensure proper business logic and functionality. The following chapters provide detailed information on database connectivity and the code changes needed to migrate to the SQL Server solution. Rewriting an application requires additional knowledge beyond the scope of this guide. Where appropriate, this guide provides references to more information about rewriting.

Port or Rewrite to Win32

The Win32 API is the primary programming interface to the Windows operating system family, including Windows® 2003. The Win32 API provides functions for processes, memory management, security, windowing, and graphics.

Considering the benefits of migration to the .NET Framework, the only reason to migrate to the Win32 platform is that migration to .NET is not technically feasible for your organization. As with the previous strategy, two migration options are available when moving to a Win32-based platform. The first is to perform a port of the application, and the other is to rewrite the application using the Win32 APIs.

A port can be used for most applications that have been developed in Java, Perl, PHP, or Python, which are available on both the UNIX and Windows platforms. APIs are available for SQL Server in a majority of cases. A port requires minimum changes to be done to the source code, and a port uses UNIX-standard compatible libraries and utilities that exist on the Windows platform. Compared to a port, the source code in a rewrite requires considerable changes to operate in the new environment. When possible, consider rewriting the application using .NET instead of Win32.

Quick Port Using Windows Services for UNIX

Applications on UNIX can be rehosted to an environment on Windows (Interix) that is similar to UNIX. Interix is a complete, POSIX-compliant (Portable Operating System Interface) development environment that is tightly integrated with the Windows kernel. It is a part of the Windows Services for UNIX 3.5 product suite from Microsoft.

One of the quickest migration paths possible is to port the code directly to Windows Services for UNIX. Interix allows native UNIX applications and scripts to work alongside Windows applications. The best way to view Interix is to understand it as a POSIX-compliant version of UNIX built on top of the Windows kernel. Importantly, Interix is not an emulation of the UNIX environment on the Windows APIs. Migration using Windows Services for UNIX involves obtaining the source code, installing it in the Interix development environment, modifying the configuration scripts and makefiles, and recompiling the application. This strategy is referred to as a quick port. As with any other migration strategies, the data access (SQL, PL/SQL) has to be migrated to target a SQL Server database. A quick port is preferred if the client application is closely tied to UNIX utilities that are not available on Windows. This approach cannot rely on special libraries for which the source code is not available. Also, quick ports using Windows Services for UNIX cannot take advantage of most standard Windows functionality.

The ported application may be successful immediately, or it may require modifications to account for the new hardware platform, the target operating systems, and local configuration information. It may not be possible to determine whether a quick port is possible without actually conducting the port. Extensive testing of the application is essential after the port to ensure that all features have been migrated successfully.

Scenarios and Cases

In the following chapters, these migration strategies are discussed in relation to common application languages. All four strategies may not be available, feasible, or desirable for each of the languages. For example, performing a quick port using Windows Services for UNIX is not discussed in the Perl chapter because Perl can run natively on the Windows platform. Because the facilities available to Perl on Windows are much richer (including .NET) than those available to Perl on Windows Services for UNIX, migrating Perl applications to a Windows environment is preferred.

Throughout Chapters 11 through 17, the migration strategies are divided into specific scenarios that may be similar to existing situations that you will encounter. Each scenario may be split into individual cases that detail the various options available for a given scenario. For example, the migration strategy of porting may best apply to your situation. In porting PHP applications to run in the Windows environment scenario, there are three cases that are discussed based on the database driver being utilized. These individual cases include detailed information regarding the use of ORA, OCI8, or ODBC database drivers to maintain connectivity in the solution.