Administrators easily overlook the benefits of application launching and embedding. ALE lets you run Windows NT Server 4.0, Terminal Server Edition (with the Citrix MetaFrame add-on) or Citrix WinFrame 1.7 applications from an Independent Computing Architecture (ICA)-enabled Web browser via the Internet or corporate intranets. ALE has potential as a viable alternative to costly Java rewrites of Web-bound Windows applications, so the more IS directors learn about ALE, the more they'll sing its praises. In this article, we'll help you understand ALE, guide you through its implementation, and offer solutions to some limitations inherent in the current ICA Web clients. For more information about how you can use ALE, see the sidebar "Put ALE to Work," page 94.
Several ICA Web clients are available for Windows, UNIX, Macintosh, and Java platforms. This article will focus on the most common Windows-based ICA Web clients, Netscape Navigator 3.0 or later with the WinFrame Web Client plugin and Microsoft Internet Explorer (IE) 3.0, which uses an ActiveX control to enable ALE. For more information about how to install the ICA Web client, see the sidebar "Installing the ICA Web Client," page 95. We will mention the ICA Java client's main features and limitations, but exploring the many Java client implementations is beyond the scope of this article. ALE uses a simple process to activate an ICA connection to an application, whether the browser that you use to request the application is IE, Navigator, or a Java applet running from a Web browser that isn't ICA-compliant. When a user clicks an ALE hyperlink on a Web page that references an ICA application, the ICA file in turn directs the user request to a designated Terminal Server (with MetaFrame) system or WinFrame server for execution. (We provide more information about ICA applications and files later.)
WinFrame and MetaFrame provide a Win32 ICA client, which uses the WinFrame Win32 Client Remote Application Manager utility. The ICA Web client provides a subset of the Win32 ICA client capabilities. This article will also address the additional features that the Win32 ICA client offers that the ICA Web client doesn't support.
Launching and Embedding Applications
The thin-client application server can run the ICA application in two ways: as a launched application or as an embedded application. To decide between launching and embedding your application, consider the behavior of each option. A launched application produces a browser-independent window and appears to run on the client's local desktop. You can close the browser or browse another site while running the application without affecting the running Web-enabled application. You use the application's ICA file to control features of the launched application window such as screen size, color density, and seamless windows.
An embedded application runs in the browser's window, and the application depends on the Web browser's presence. An embedded application closes with the browser. Loading another Web page closes both a user's connection to the ICA server and the embedded application. When users scroll the page up or down on a browser Web page, the embedded application window will scroll with the page.
The ICA File
The ICA file is a text file that includes the parameters necessary for defining an ICA connection to an application server. Listing 1 shows sample ICA code. After you understand the ICA file format, you can create ICA files using any text editor. However, tools that facilitate the creation of ICA files come with MetaFrame and WinFrame.
The Application Configuration utility (a standard utility on WinFrame and MetaFrame servers) includes a Write ICA File option. After selecting the application you want to publish using ALE, you choose the Write ICA File option on the Application drop-down menu to define four ALE parameters: window size (an absolute size in pixels or a percentage of the client display resolution), color density (16 or 256 colors), encryption level (the basic encryption level is sufficient for intranet applications, but we recommend a higher level for Internet access), and the directory in which ALE writes the ICA file. For more information about how to use the Application Configuration utility, see the sidebar "Application Configuration, Step by Step," page 98. After you create an ICA file, you must load the file on your Web server to make it available for Web client downloads.
Citrix's ICA File Editor offers a GUI for creating and editing ICA files. You can install this 32-bit utility on any Windows 95 or NT system from disks you create by using Client Disk Creator, which you find under the MetaFrame Tools menu of a Terminal Server (with MetaFrame) system or the Administrative Tools menu of a WinFrame 1.7 server.
Win32 ICA Clients
Although the Application Configuration utility writes a functional ICA file for Web clients, Citrix's Win32 ICA client offers additional features. ICA Web clients don't support seamless windows for embedded applications, or client LPT-port and COM-port mapping. However, you can use the ICA file format to exploit these features on Win32 ICA clients.
LPT-port and COM-port mapping, which aren't available to ICA Web clients, are inherent in the Win32 ICA client and available to users running a session via a Win32 client. Win32 ICA clients can also run seamless windows for launched applications. Listing 2 shows code that will launch the Calculator application in a seamless window. The TWIMode=On command line and the ScreenPercent=100 setting tell the ICA file to launch a published application in a seamless window. (Transparent Windows Interface—TWI—was the original name of the seamless windows interface technology.)
Despite the Win32 ICA client's LPT-port and COM-port mapping and seamless window functionality, using an ICA file to launch ICA connections on the Win32 client has some limitations. Advanced client features such as sound support, persistent bitmap caching, and keyboard and mouse event queuing aren't available through an ICA file.
Web Server Requirements
You can configure any server that supports application MIME types to accept ICA requests. Just register ICA as an application MIME type, and your Web server will use the ICA file to connect inquiring browsers to the application server. Figure 1, page 99, illustrates the relationship between the ALE components. The Web server contains the HTML file with the hyperlink that references the ICA file. Although you can use the same machine as the Web server and the application server, we recommend that you use separate machines for tighter security and better performance.
The Web Clients
The Web server automatically downloads and installs Microsoft's ActiveX control when an IE 3.0 or later browser accesses an ALE hyperlink on a Web page. You need to include code in the HTML page to perform this initial ActiveX control download.
The WinFrame Web Client for Navigator plugin doesn't automatically download or install, so users must download and install the plugin before accessing ICA hyperlinks on a Web page. You need to include downloading and installation instructions, and a link to the plugin on your page to notify Navigator users of the plugin's necessity and to help them obtain it.
You can use a Java applet to give users access to your ICA applications if your environment lacks support for non-Windows Web clients or prevents the spontaneous ActiveX download necessary for IE to run an ALE-enabled application. The Java client supports only embedded applications. The Java applet initializes when a browser accesses an ALE hyperlink in a Web page and the Web server downloads the ICA file to the user's browser. The Java applet performs the same function as the Windows-based ICA client's executable file (wficax.exe).
Implementing the Java Web client is more involved than using IE or Navigator and is outside the scope of this article. Because of Java's network security restrictions, you need to place Web server software on the application server to provide the Java client to users. The Java Web client has many configurable parameters and options, so we suggest you reference the MetaFrame Administration Guide or the Citrix ICA Client Users Guide before configuring a Java Web client.
The HTML File
The complexity of the HTML file that hosts an ALE hyperlink depends on the amount of intelligence you build into the code. Fortunately, the Application Configuration utility simplifies HTML file creation for MetaFrame (but not for WinFrame, which relies on you to write your own HTML file), just as the utility writes ICA files. You can use the Write HTML File option under the Application drop-down menu and select the appropriate options to prepare an HTML page for the browser to access the HTML file's ICA link and react accordingly. The Application Configuration utility lets you choose embedded or launched application support; IE, Navigator, or Java applet clients; embedded window size (the default size is 640 x 480); verbose or terse HTML code; and filename and file directory.
For each ALE application, you need to create an ICA file and an HTML document that contains the ALE hyperlink. You need to store both files in the same directory on the Web server. The HTML file must use the <A HREF> tag to reference the ICA file, just as the HTML page would reference any other object. Listing 3 is an example of HTML code with an embedded hyperlink that references an ICA file. For ALE, the <A HREF> tag is the code's most important section. The <A HREF> tag places the ICA hyperlink on the page and references the correct ICA file and optional .gif. For more information about how to create ICA and HTML files using the Application Configuration utility, see the sidebar "Creating ICA and HTML Files," page 100.
The Application Server
The final component in this Web-publication strategy is the ICA application server, either a Terminal Server system (with MetaFrame) or a WinFrame system. Until February 1999, Terminal Server licensing limited Internet users from accessing MetaFrame applications because Terminal Server required each user to have an NT Workstation 4.0 license and an NT Client Access License (CAL). The licensing did not preclude you from using Terminal Server-based ALE on your corporate intranet or on the Internet if you used passwords to limit usage to specific user accounts. Potential Terminal Server customers who wanted to use ALE over the public Internet had to use WinFrame, which supports licensing of concurrent users. (WinFrame is based on NT 3.51.)
Early this year, Microsoft made significant changes to Terminal Server licensing and created the Terminal Server CAL, which gives users a less expensive alternative to the NT Workstation CAL requirement. (A Terminal Server CAL costs less than half the price of an NT Workstation 4.0 license.) In addition, Microsoft created the Internet Connector (IC) for Terminal Server, which licenses as many as 200 concurrent anonymous Internet users and eliminates the NT Workstation CAL requirement altogether. The Terminal Server CAL and IC licenses are not interchangeable because the IC supports only anonymous users and eliminates an important layer of control and security.
An application server must meet a few requirements to support numerous anonymous connections or specific user accounts. These requirements vary depending on which platform you implement. The documentation that accompanies each product covers the configuration steps you must take to meet these prerequisites. The Terminal Server and MetaFrame combination requires you to purchase both pieces of software. To use the solution for local LAN applications, you need NT Workstation licenses or Terminal Server CALs for all your clients and NT CALs for all users with server access. To use the solution over the Internet, you need an IC license for every 200 anonymous users that you expect to run the application concurrently.
The WinFrame solution requires that you purchase the WinFrame OS and WinFrame licenses for the number of connections you need. You also need to configure TCP/IP WinStations, anonymous or explicit user accounts equal to the number of licenses available, and adequate licenses for the application you publish.
When you've properly configured your environment to support ALE, you can give users access to any application over the Internet or intranet without installing the application on your desktops or rewriting it in Java. Beyond the cost savings, an advantage to this approach is the freedom to modify the Internet or intranet landscape of your enterprise without facing major development or deployment obstacles. ALE lets an organization respond with agility to the changing needs of its users and the marketplace it serves.