Creating Cross-Platform ASP Applications

ASP developers that create cross-platform ASP applications will find a greater market for their applications and better job opportunities. Just check out Netcraft for the latest statistics on Apache Web Server usage or any IDC report on the use of Linux or UNIX in an organization. To create applications that can be moved to various UNIX or Linux environments (or even back to Windows NT/2000) with minimal effort, requires making the ASP application and its dependencies portable.

There are 4 key areas of consideration:

1. Operating System: Case sensitivity and file system considerations.

2. Database: Using ODBC drivers and database types.

3. Application: Using JavaBeans, EJBs, or CORBA.

4. Web Server: Security and server variables.

For more information continue below or Download the PDF version of Creating Cross-Platform ASP Applications.

Operating System Considerations

When designing an ASP application that can be moved from one operating system to another, the most significant issues are those that arise due to differences between Windows NT/2000 and a UNIX/Linux platform.

Case sensitivity

One of the most frustrating differences that application developers encounter between Windows NT/2000 and UNIX/Linux is case sensitivity. UNIX is case sensitive for everything, while Windows NT/2000 isn?t case sensitive for anything (except passwords). In ASP terms, this means that file names, URLs, database names, table names, and field names all must use the proper capitalization if an application is to be truly cross-platform.

This difference is not frustrating because it is hard to deal with, but more so because it can be difficult to figure out the problem. When an application is moved to UNIX, it may be very difficult to realize that a URL has a different case than a filename, or a fieldname has a different case in the database than in your SQL statement (case problems like this usually only occur with dBase databases). Further, your utilities can conspire against you since many utilities for moving files between NT/2000 and UNIX or Linux change the capitalization of file names in transit. An application that was working perfectly on NT/2000 can fail when moved to UNIX or Linux if case sensitivity problems are not dealt with up-front.

The best strategy for coping with this issue is to be rigorous when naming the different elements that make up your ASP applications. Only by developing a standard methodology for naming, and sticking to it, will you be able to address the case-sensitivity problem in an efficient manner. And keep some UNIX utilities handy (like ToLower) that let you undo the file name damage that file transfer utilities can cause.

Strategy: Develop a standard for naming ASP files, HTML files, databases, tables, and fields and stick to it. We highly recommend using all-lower-case for all names.

File system differences

The file system differences between Windows NT/2000 and UNIX are very significant when developing a cross-platform ASP application, and must be dealt with up-front. The most common places for a developer to need to interact with the file system are in Include statements, with Server.MapPath, and in the FileSystem object.

Include and Server.MapPath statements are easy to deal with. Because both of these statements support standard URL path descriptions, forward-slashes can be consistently used in paths given to these statements. Remember, however, that values returned from Server.MapPath are different depending on the underlying operating system. The key differences are that Windows NT/2000 will return a path containing a drive letter (and colon, like C:) and back-slashes (""), while a UNIX path will have no drive letter and use forward slashes ("/"). It is important to remember this if you need to parse the value returned from Server.MapPath (or from the http server variable PATH_INFO). An easy way to deal with this problem is to programmatically determine the "slash-style" in your Global.asa file, and set it to an Application variable. For example, place the following in your Global.asa file:

Then use the following in your asp pages:

The FileSystem object is the other location that developers must deal with differences between the Windows NT/2000 and UNIX/Linux file systems. One issue is the same "slash problem" addressed above. The other key issue is related to Windows concepts of "drives". Drives, mapped drives, drive letters, UNC (Universal Naming Convention) names, etc. do not exist in the UNIX environment and are therefore not implemented in Sun Chili!Soft?s FileSystem object for UNIX. Developers should structure their applications such that all application files are accessible from the root of the local file system.

Strategy: Set an application constant that contains the appropriate "slash" to use, and don?t rely on NT/2000 concepts like mapped drives, drive letters, or UNC to reach remote file systems.

Database Considerations

Sun ONE Active Server Pages includes ODBC drivers for most major databases, including the two most popular OpenSource databases, MySQL and PostgreSQL. These ODBC drivers are different then the ones that are supplied by Microsoft on Windows, and their functionality may be different in some areas. While all ODBC drivers must conform to the ODBC specification, there are various levels of support for this specification. The most common areas that you may encounter a difference in driver behavior are Stored Procedures and supported CursorTypes. Sun Chili!Soft ASP includes the ActiveX Data Objects (ADO). The ODBC layer of the ADO objects as been implemented only. What this really means to you, as a developer, is that you cannot use a database connection string that uses OLE DB syntax. Both DSN (Data Source Name) and DSN-less connection strings are supported, however. For a full listing of the correct connection string syntax, you should take a look at the Sun ONE Active Server Pages on-line documentation. When designing and developing the ASP Application, it?s most important to design and deploy against the same database. Doing this one thing, will save you an incredible amount of time and frustration. Trying to make adjustments for SQL syntax differences and ODBC driver differences, after you have the ASP Application completed and working smoothly in one environment, can be extremely frustrating.

File-based Databases

Developing an application that uses a file-based database (as opposed to a client-server database) can often be quite useful. While file-based databases such as Microsoft Access and dBase are not appropriate for high-volume applications, they can be quite adequate for simple, self-contained applications that require a minimum of setup. However, it is important to remember that Microsoft Access is not available for any version of UNIX or Linux (Access databases can be "accessed" from Sun ONE Active Server Pages running on UNIX, but the Access database itself must reside on a Windows system). There are tools available that can assist in migrating the data and table structures of a Microsoft Access database to another database.

The capabilities of the dBase ODBC drivers across Windows and UNIX differ somewhat. First of all, dBase does not support joins; use a query and nested subquery instead to achieve the same effect. Secondly, do not use the TableName.FieldName syntax in your SQL statements when specifying fieldnames. Simply use the fieldname. Other file-based databases may have other requirements that you should take into consideration.

Strategy: Use a cross-platform file-based database, and avoid the use of table joins. 

Client-Server Databases

For more sophisticated, higher-volume applications, you really need to use a client-server database such as Oracle, DB2, or Microsoft SQL Server. When it comes to developing Web applications that can use different databases on the back-end, ASP provides you with some powerful tools. Because ASP relies on ODBC and ADO (Active Data Objects), you can write your application with these two models in mind, and let them worry about the inconsistency between databases.

Even when using ADO and ODBC, however, there may be differences between databases that you will need to deal with. For example, some databases consider an empty field to have the value "", while others use the value "NULL". You should write your code to handle both contingencies. In some cases, a database will have a distinct data type that may not exist in other databases. You should use standard ODBC data types as often as possible. Lastly, more sophisticated database features like stored procedures are supported by ADO and ASP, but work differently in different databases, and should be avoided if the application needs to be portable.

Strategy: For maximum portability across databases, keep things simple. Avoid the use of unusual datatypes and features like stored procedures.

Application Considerations

When looking to develop custom components to be used within your ASP application, you will need to make sure that the language that you?re going to write those components in, is actually supported on the operating system that you are going to deploy to. For this reason, it is never wise to use Visual Basic as your programming language. If you do so, you immediately lock yourself into a Windows-only solution. At this time, Java is the preferred cross-platform language for component development. Sun ONE Active Server Pages has built-in support for communicating with Java class files directly from your asp script.

JavaBeans and Enterprise JavaBeans (EJB)

Sun?s JavaBean and Enterprise JavaBeans (EJB) specification has captured significant attention in the Web application development world. JavaBeans and EJBs provide robust, cross-platform architecture for the creation of component-based, distributed applications.

With the introduction of Chili!Beans in Sun ONE Active Server Pages v3.0, ASP developers can take immediate advantage of using local JavaBeans or EJB servers to host ASP components. The following diagram illustrates how Sun Chili!Soft ASP would work in conjunction with an EJB application server.

The EJB component is first developed, then registered with the EJB Server. Then the Java RMI (Remote Method Invocation) Stub compiler is used to create stub and skeleton classes that implement the remote communications between the calling application and the remote object. When used in conjunction with Sun ONE Active Server Pages, the stub class stays on the same machine as Sun Chili!Soft ASP, and is registered as a COM object with the Chili!Beans cbreg tool. Sun ONE Active Server Pages scripts are then able to create and use the stub class as they would a local object. Any requests for methods and properties of the object are passed from Sun ONE Active Server Pages to the stub class, which is responsible for using RMI to communicate with the remote skeleton class. The remote skeleton class contains methods that dispatch calls to the actual implementation of the object running in the EJB application server.

There is significant interest today in EJB application servers because of the capabilities they provide. For example, system-level services such as transactions, security, life-cycle management, threading, persistence, etc. are automatically managed for the EJB component by the EJB server. The combination of ASP?s object model and scripting languages, with the application server capabilities of EJB, makes a great environment for rapid development of scalable and secure transaction-oriented Web applications.

CORBA

CORBA (Common Object Request Broker Architecture) was one of the original technologies that created interest in the possibilities of creating distributed applications made up of independent objects. Since CORBA 1.1 came out in 1991, there have been enough implementations of CORBA-based solutions that CORBA is a significant part of the "legacy" system landscape. Furthermore, the release of a new version of CORBA in 1994 and the use of CORBA in many vendors? implementations of application servers has led to the CORBA resurgence that is currently underway.

The combination of Sun ONE Active Server Pages Chili!Beans technology, and the Java IDL features of Sun new Java2 platform, means that Sun Chili!Soft ASP developers can use CORBA as one of their distributed application technologies. It also means that Sun ONE Active Server Pages applications now have a means to connect to existing corporate CORBA services. The diagram below provides an example of how Sun ONE Active Server Pages might connect to a CORBA object, using Chili!Beans and Java2.

To access a CORBA object via Chili!Beans and Java2, the developer first creates a Java class which will act as a stub. The Java IDL ORB (Object Request Broker) contains an idltojava compiler tool which translates IDL definitions into Java constructs according to the IDL-Java language mapping, and generates the stub class. This stub class is then registered on the Sun ONE Active Server Pages machine by using the Chili!Beans cbreg tool. After an ASP page creates an instance of the stub class (using the usual Server.CreateObject call), properties and methods of the remote CORBA object may then be called. The stub uses the Java IDL ORB to locate the remote object and set up a network connection to it using IIOP (Internet Inter-ORB Protocol). At the other end, the CORBA object uses the ORB and skeleton to which it is bound to receive the method requests from the ASP page. An individual instance of a running CORBA object is called a servant. The CORBA object and skeleton may be implemented in any language that has a CORBA IDL (Interface Definition Language) mapping. Through the use of Chili!Beans and Java2?s Java IDL, Sun ONE Active Server Pages developers can now use new and existing CORBA objects as key components in Web applications.

Web Server Considerations

The previous three areas cover the most common issues found when developing cross platform ASP application, however the issues below may also be of concern to you.

Security

Code Red and Nimda highlighted the weak security of Microsoft?s IIS Web server. Because IIS, Sun ONE Web Server, and Apache all differ in how they handle security, it is best to understand and plan the appropriate security strategy if you plan to have your ASP application work across different Web servers. The original Active Server Pages specification was developed by Microsoft to work in conjunction with Internet Information Server (IIS) on Windows NT. In spite of this, ASP is relatively server-neutral when it comes to the security features it provides. ASP does not interfere with the Web server?s native security, and it may sometimes be useful to rely on the server?s built-in security. However, any reliance on a server?s built-in security will affect portability. The most portable ASP security solution is to initially collect the user?s credentials via an HTML form, validate the credentials against the application?s own database, and assign a session variable to the user that says they have been authenticated. For each subsequent page in the application, the page can verify the presence of the session variable for authentication and to look-up authorization data in the application?s database. For higher-security applications, the above technique can be combined with SSL encryption between the browser and server to avoid session hi-jacking and replay attacks. This approach is available with any combination of popular Web browsers and servers.

Strategies: Use an HTML form and Session variables to collect and maintain user credentials instead of Basic Authentication. In addition, for "highly-paranoid" applications, use the Web server?s built-in SSL encryption to safeguard credentials.

Server variables

In the early days of Web development, when CGI was king, server variables were critical. All of the useful information collected by the Web server was exposed to application developers via server variables. But with the advent of other Web application frameworks, particularly ASP, server variables are less critical to the application developer. However, in certain cases, server variables are very useful when they contain important information that cannot be obtained otherwise. Different Web servers have different sets of server variables, and Sun ONE Active Server Pages makes all of the server variables available via the Request.ServerVariable ("VAR_NAME") construct. However, it?s not a good idea to develop an application that relies heavily on a specific server variable if that variable does not exist on other Web servers. Therefore, for maximum portability, developers should only use server variables that are "standard" across all Web servers. These standard server variables came out of the original NCSA and CERN Web servers. The most useful standard server variables in Web applications include SERVER_NAME, SERVER_PORT, PATH_INFO, REMOTE_HOST, and REMOTE_ADDR, and should all be available on today?s popular Web servers.

Strategy: Avoid the use of server variables where possible, and only use standard server variables that appear across all Web servers.