This white paper discusses developing cross-platform Web applications using Chili!Soft ASP and Active Server Pages (ASP) technology. It also discusses using Chili!Soft ASP with advanced technologies for distributed applications, such as DCOM, Enterprise JavaBeans, and CORBA. This paper is intended primarily for application developers and architects and assumes the reader is familiar with operating system, Web server, and database fundamentals.
In this white paper:
· Introduction
· Operating System Considerations
Case Sensitivity
File System Differences
· Web Server Considerations
Security
Server Variables
· Database Considerations
File-based Databases
Client-Server Databases
· Distributed Object Technology Considerations
Programming Languages
COM/DCOM
Enterprise JavaBeans (EJB)
CORBA
· Conclusion
· Company and Product Overview
About ASP
About Chili!Soft
Corporations and software companies alike have struggled for years to develop applications that are portable between different computing environments. Different technologies for solving the problem have met with differing levels of success. UNIX and "open computing" was one of the first technologies that attempted to tackle the problem, but the effort splintered into different factions. The advent of the Web, however, has brought real hope to the fight for a simpler method for building cross-platform applications. The Web takes the client-side platform out of the picture in many cases, or at least minimizes its impact. But the problem on the server-side still can be difficult: different operating systems, different web servers, different databases, and different techniques for building Web applications.
With Chili!Soft ASP, Chili!Soft brings a viable solution to the cross-platform Web application problem. Chili!Soft ASP delivers the entire Active Server Pages (ASP) framework to a multitude of different Web servers and different operating systems (including Linux, Sun Solaris, IBM-AIX, HP-UX, 0S/390, and Windows NT). With this framework available everywhere, developers now have a stable platform for application development that remains consistent for different Web servers and operating systems. While idiosyncrasies will continue to exist between different systems, the ASP framework gives you strategies for dealing with these issues.
This paper discusses the considerations present as applications move from platform to platform, and how application developers can write ASP applications that run unchanged on the platform of choice.
When designing an ASP application that can be moved from one operating system to another, there are a few important issues to keep in mind. The most significant issues are those that arise due to differences between Windows NT and a UNIX or Linux platform.
One of the most frustrating differences that application developers encounter between Windows NT and UNIX/Linux is case sensitivity. UNIX is case sensitive for everything, while Windows NT 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 might 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 Windows NT and UNIX or Linux change the capitalization of file names in transit. An application that was working perfectly on NT 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 (such as 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 recommend using all lowercase letters for all names.
The file system differences between Windows NT 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 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:
OS = Request.ServerVariables("ASP_OS")
If InStr(OS,"WINDOWS") > 0 Then
Application("OS_Slash") = "\”
Else
Application("OS_Slash") = "/"
End If
Then use the following in your ASP pages:
Dim sSlash, sFile
sSlash = Application("OS_Slash")
…
sFile = "dir" & sSlash & "subdir" & "afile.asp"
The FileSystem object is the other location that developers must deal with differences between the Windows NT 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, and so forth, do not exist in the UNIX environment and are therefore not implemented in the Chili!Soft ASP 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 do not rely on Windows NT concepts such as mapped drives, drive letters, or UNC to reach remote file systems.
Security is often an important consideration when building a full-featured Web application. It is also an area where there is significant divergence in implementations between different Web servers. IIS, Netscape, Apache, and Lotus all differ in how they handle security. There are, however, strategies for dealing with security that will enable your applications to 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 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 using Basic Authentication. In addition, for "highly-paranoid" applications, use the Web server’s built-in SSL encryption to safeguard credentials.
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 Chili!Soft ASP 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 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.
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 or 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, leaving dBase as the only real choice for file-based databases on both Windows NT and UNIX. (Access databases can be "accessed" from Chili!Soft ASP running on UNIX, but the Access database itself must reside on a Windows system).
The capabilities of the dBase ODBC drivers across Windows and UNIX differ somewhat. First of all, dBase does not support joins; you must use a query and nested subquery instead to achieve the same effect. Secondly, you should 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 dBase as your file-based database, and avoid the use of table joins.
For more sophisticated, higher-volume applications, you really need to use a client-server database such as Oracle, Sybase, 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 data types and features like stored procedures.
Many interesting ASP applications make use of custom components to build distributed multi-tier applications. Custom components are useful for encapsulating special code that is especially complex, performance-oriented, or needs to be used for multiple purposes. For example, the modular architecture of ASP lends itself well to development where your highest-skilled developers are building business logic into ASP components, while junior developers use simple script for presenting the user interface and calling the ASP components.
Technologies for building distributed applications have been on the scene for a while (CORBA is a good example), but widespread use of distributed applications has only recently started to become commonplace. Web applications in particular are driving this new approach. The first Web applications were distributed in a sense, with the Web browser (client), database, and Web server/Web application server forming three tiers. Now, with technologies such as DCOM, Java and Enterprise JavaBeans, and CORBA, web applications are becoming even more distributed, with the Web application server becoming the focal point for presenting the entire application to the user.
Web developers especially like the Active Server Pages architecture that makes it very easy for them to create components that add new functionality or encapsulate business logic. They use simple scripting languages to access the components, while the components themselves can be written in any number of languages. Previously, however, the components themselves had to be running on the same machine as Chili!Soft ASP. With the new features of Chili!Soft ASP, developers can create components using technology such as DCOM, Enterprise JavaBeans, and CORBA, and distribute those anywhere on the corporate network.
Your language choices for developing cross-platform ASP components are either C/C++ or Java. Which one you choose depends on a lot of factors. C/C++ yields the greatest performance, and you may have a great deal of C/C++ code to reuse. The downside is that a C/C++ component needs to be re-compiled for each platform you want to support, using component tools that Chili!Soft can provide. Your other option is to use Java to build all of your components. By using Chili!Beans, a feature of Chili!Soft ASP, you can build your custom components as Java classes and script to them as if they were "traditional" ASP components (COM objects). You do not need to recompile your class(es) as you move them to new platforms. The downside is that Java components today do not perform as well as C/C++ components.
Chili!Soft ASP support for custom components varies depending upon the operating system. Support for specific technology/programming language combinations hinges upon the availability of runtime libraries for the given combination. For example, since there are no runtime libraries available for Visual Basic on UNIX/Linux, we can offer no support for Visual Basic COM objects in environments outside of Windows NT.
Currently, COM and DCOM support is available on Windows and UNIX systems. On Linux platforms, full support for COM/DCOM is under development. Visit the Chili!Soft Web site (http://www.chilisoft.com) for up to date information about the availability of run time libraries and custom components for Linux. Java classes (including JavaBeans and EJBs) can be accessed from ASP on all of our platforms, including Linux, by using our Chili!Beans technology.
COM (the Component Object Model) is the Chili!Soft ASP native object model, on both Windows NT and UNIX. DCOM (for Distributed COM), is Microsoft’s enhancement to COM that lets a COM object running on another machine appear to the calling application as if it were running locally. Chili!Soft ASP 3.0 on UNIX (IBM-AIX, Sun Solaris, HP-UX) supports DCOM to a limited extent. Due to limitations in the DCOM mechanism, only DCOM objects written in C/C++ will work with Chili!Soft ASP.
With DCOM, ASP developers access the capabilities of a custom object as always, by using the Server.CreateObject call. On the computer running Chili!Soft ASP, the custom object is registered with COM as a DCOM object, with all of the information regarding the object’s location (the object’s name, the hostname of the remote machine, etc.) On the remote computer, the object is registered with DCOM, with security information regarding who is allowed to access the object. Any calls to this object from an ASP page are sent by COM to the remote object via RPC (Remote Procedure Calls). The remote object completes the request and sends the results back to be used in the ASP page. The following diagram demonstrates how DCOM components are used in an ASP application.
With DCOM capability delivered as part of the Chili!Soft ASP package on UNIX, developers can immediately create distributed ASP applications that use DCOM to access remote objects and systems. (DCOM is already available as part of the operating system on Windows NT.) For example, a Chili!Soft ASP application on UNIX could use DCOM to access a remote COM object running on a Windows NT system. This capability can promote code re-use, allowing ASP applications to re-use COM objects from pre-existing applications that are running on other systems. Chili!Soft also has tools available that enable developers to create COM objects to run on UNIX, that may be accessed remotely using DCOM by Chili!Soft ASP.
The Sun Microsystems new Enterprise JavaBeans (EJB) specification has captured a significant amount of attention in the Web application development world. EJB holds the promise of a robust, cross-platform architecture for the creation of component-based, distributed applications. Even though the EJB specification has only recently been finalized, the number of vendors providing application servers based on EJB has grown dramatically.
With the introduction of Chili!Beans in Chili!Soft ASP 3.0, ASP developers can take immediate advantage of using EJB servers to host transactional ASP components. The following diagram illustrates how Chili!Soft ASP would work in conjunction with an EJB application server, such as Persistence Power tier for EJB. (Because the EJB specification is still relatively new, different EJB application servers have somewhat different implementations, but the core methods for implementing distributed component functionality are relatively consistent.)
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 Chili!Soft ASP, the stub class stays on the same machine as Chili!Soft ASP, and is registered as a COM object with the Chili!Beans cbreg tool. Chili!Soft ASP 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 Chili!Soft ASP 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 easy, yet powerful 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 (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 Chili!Soft ASP’s new Chili!Beans technology, and the Java IDL features of Sun Microsystems’ new Java2 platform, means that Chili!Soft ASP developers can use CORBA as one of their distributed application technologies. It also means that Chili!Soft ASP applications now have a means to connect to existing corporate CORBA services. The diagram below provides an example of how Chili!Soft ASP 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 that 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 Chili!Soft ASP 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, Chili!Soft ASP developers can now use new and existing CORBA objects as key components in Web applications.
ASP is not only a good Web application platform because of its flexibility and ease of use, but because it is a great platform for cross-platform Web applications. One of the most important characteristics of the ASP architecture is its extensibility. In the past, it was easy to combine the rapid development characteristics of the scripting environment with new custom objects that resided locally. Now with support for DCOM and the addition of Chili!Beans, Chili!Soft ASP provides ASP developers with a wealth of options for creating scalable, cross-platform ASP applications that leverage all of the latest Internet development technologies, while providing links to critical legacy systems. By following a few simple guidelines, corporate developers as well as ISVs will be able to build Web applications that can run unchanged on a wide variety of platforms.
ASP is an open, compile-free Web application environment that combines scripting, HTML, custom server components and robust database publishing to create dynamic Web-based business applications. With ASP, developers can build browser-independent Web solutions and publish legacy databases to the Web using tools such as Microsoft’s Visual InterDev™ and FrontPage2000™, Macromedia™ Drumbeat™, NetObjects ScriptBuilder™, or Sybase™ PowerSite. ASP is widely known for accommodating developers of varying skill sets and expertise, and for allowing corporate IT managers to more effectively allocate scarce developer resources. There are more than 1,000,000 ASP developers, over 500 companies producing ASP components and applications, and approximately 25,000 public Web sites using ASP.
Chili!Soft, Inc., a wholly owned subsidiary of Sun Microsystems, Inc. (NASDAQ: SUNW), is a provider of enabling technologies and applications for Active Server Pages. Chili!Soft's award-winning flagship product, Chili!Soft ASP, extends the ASP framework to major Web servers and operating systems including Microsoft Windows NT and Windows 2000, Sun Solaris, IBM AIX, Hewlett Packard HP-UX, and Linux. Chili!Soft was incorporated in 1997 with headquarters in Bellevue, Washington. For more information about the company, please visit the Chili!Soft Web site at http://www.chilisoft.com or call (425) 957-1122.
Copyright 2001 Sun Microsystems, Inc. All rights reserved. Legal Notice.