SCO Tarantella runs, not crawls, over the Web

Years ago, Netscape's dream was to make its Web browser the complete interface and operating system for the desktop computer. The idea was simple: make applications on the Net indistinguishable from local applications. It was a concept similar to Sun Microsystems's mantra, "The network is the computer" -- and was a bit far-fetched, given the emergence of Microsoft as the major software superpower. And it was Microsoft, of course, that went on to produce Internet Explorer 4 and Windows 98, software that added Web functionality directly to the Windows desktop.

Yet these products merely grant access to the same applications the OS itself gives you. A number of companies, including Citrix, Microsoft, and NCD, have attempted to realize Netscape's goal in their thin-client application server products, with moderate success. Citrix's WinFrame and MetaFrame products are still the leaders, although Microsoft is catching up. Other vendors from the Web application server and Web portal fronts have developed products that access applications running on a centralized Web server; but when it comes to management and Unix access, they don't beat the ensemble SCO has created with Tarantella.

SCO is marketing Tarantella as a way to build an enterprise portal for your intranet, but I see it as more than that. Tarantella can provide a powerful clustering methodology that is independent of any particular variety of OS or server hardware. By providing access to Unix and Windows accounts at the same time, it's suitable for Internet kiosks and extranet services. In this review, I'll look at the various elements of the Tarantella system, then identify the few missing components of this otherwise elegant computing architecture.

What is a Webtop?

Tarantella is a true Webtop -- all its applications are accessible directly through the Web browser to users in any location, as long as there is a route between the two machines. Thus, users may roam about from computer to computer within the company, or even access Tarantella from home or elsewhere, just as they would from their own desktops. The protocol implements encryption and security, and because only graphics information is being passed between the machines, it's hard to peek into someone's ongoing session.

Tarantella can also be configured to connect to any number of application servers via the Tarantella server itself. For example, the user can log in to Tarantella, then launch an application, either from the same server or anywhere else on the network. To communicate with graphical applications between servers, Tarantella uses the X Windows protocol, so any X application on any type of Unix server can be displayed on the desktop, without installing Tarantella on any other servers. And, if you use a Windows thin-client server such as NCD WinCenter, this platform independence goes one step further. Because the NCD package uses the X protocol to display Windows applications on remote desktops, the Webtop user can access Windows software as well.

Tarantella servers are also double-duty specialists: if users run the application themselves, they're also application servers. To avoid confusion between connectivity and application servers, I'll mainly use the three-tier model in this article.

Installing Tarantella

Once you run the install script, this software installs fairly automatically; after this is complete, everything but the link to the Web server is in place. SCO chose not to include a Web server with the package -- it's left to your discretion. You should keep in mind, however, that the Web server should support directory and script aliasing, so that the software can be accessed through the server wherever you install it.

I installed the latest Apache Web server, version 1.3.9, on my Sun Ultra 10 Solaris system. The configuration in Apache involves adding in exact order the following two lines to the httpd.conf file:

ScriptAlias /tarantella/cgi-bin /opt/tarantella/cgi-binAlias /tarantella /opt/tarantellaUsers having an open account on the Unix server where Tarantella is installed can log on to their own Webtop. The default application set will be the only thing available to them through the portal, but they'll be ready to go, as quick as that.

The administrator account for Tarantella is of course root, but you can create additional Tarantella operators and administrators as necessary. You can also create groups for users and modify available applications.

Using the Webtop

Tarantella's first task upon accessing the site is to download a piece of Java code and install it as part of the browser. Next, confirm the security message to allow the installation of this code locally -- the code will be used each time you access the portal. After the code is installed, close the browser and restart your computer.

Logging in as a regular user will load the default user interface and application set in the browser (see Figure 2). This includes two terminal emulators (VT420 and SCO Terminal), an xterm window, the clock, and a help screen. The browser window is subdivided into four parts: the login/logout window, the icons window, the printer window, and the main application window.

To end up on the same user account, log into the connectivity server via your browser, create a new window (but not a new instance), then go to the connectivity server again. For example, after you launch Netscape and go to the Webtop on a Windows OS, hit Ctrl-N to start a second window from Netscape to go into the Webtop -- both windows will be connected to the same account. This is because the user's account and password are cached. On a Unix system with multiple users, each user can log into his or her private Webtops through the browser, but additional child browser windows will go into the same Webtop -- that is, until you log out of the Webtop.

Be warned: logging off the Webtop will terminate all browser windows running, not just the one you logged off of. As long you have at least one Webtop left, you can close a single window by clicking on the X in the top right corner. You can also close all your Webtop windows, and the connectivity server will still leave you logged on to the Webtop. This can come in handy on Windows machines that crash and have to be rebooted.

Clicking on an application icon will launch the application on the remote machine. If you select another icon, the first application is still running; it's merely hidden from view. By clicking on the first icon again, the system reverts to that one, which saves you the time and hassle of continually beginning a new application.

There are three settings for session resumability. Some applications are set to be never resumable, in which case clicking on the icon always starts a new instance. This comes in handy for applications that don't support resumability, and small noninteractive applications that won't benefit from it, such as the X Windows clock, biff, etc.

Most applications are set as Tarantella sessions, in which case the application is detachable and resumable while users are logged into their Webtops. This setting is useful for most interactive applications, including terminal applications, mail reader programs, login shells, etc.

The last setting is always resumable, wherein the application remains running even when users log off their Webtops. This setting is useful for interactive applications users may want to leave running on a long-term basis, that have a long restart period, or that take time to place in the state they need. This setting can be expensive to maintain because it continually uses system resources, even when users aren't logged in.

Kiosk mode

Tarantella can also be helpful in building independent kiosk-based systems. By using a Web browser or native mode client, one can set up a PC as a kiosk to a portal. The Web browser needs to point to the URL http://servername/tarantella/kiosk.html instead of the default home page, and the native client should be set to log in anonymously. The connectivity server then needs to be set to allow anonymous logins and have a password defined for the anonymous user, which is passed on to the Unix or Windows host for authentication.

Kiosk mode works just like the regular Webtop, with the difference that it is associated with an anonymous user account. Since kiosks can automatically log in, be careful about what applications you provide the kiosk users -- don't make available applications that grant access to other components of the site, like login shells or terminal windows. If you link them directly to an internal Web site, take care that the links are intended for public use only.

You might not want the default Tarantella Webtop to be your kiosk's layout, in which case the software lets you redefine icons and descriptions for better flow. You can also redefine the system's frame layout to hide the printer and login/logout frames from public eyes. SCO gives detailed explanations on how to alter everything from the login window to the Webtop itself. It takes some familiarity with HTML programming, but isn't too difficult.

The administrator's view

The Tarantella administrator uses the Control Center Java applet to connect to the Tarantella management system, which, interestingly enough, follows an object-based methodology for creating groups, applications, and users. Each entity is defined by a certain object type (e.g., user, group, application), which has specific attributes (e.g., username, group name, application options). When creating the object, enter the values for the different attributes.

To define an application, you need to specify the host on which it's located, the full path to the executable program, the program's options, the application's window size, environment variables, icons, application-specific attributes, and so on. By dragging and dropping a defined application object in a user object, you've effectively given the user access to that application. Similarly, creating a group and then dragging-and-dropping a user into it will make that user a member of that group.

Tarantella uses a hierarchical directory naming model, known as Tarantella Federated Naming (TFN), that is a tree-like naming system not unlike LDAP or X.500 directory services. Users can be hierarchically arranged into groups, then departments, divisions, sites, etc., in any form the administrator desires, as long as they fit somewhere in the tree. Each group can also have different rights and application sets to use. Every user or group can thus be identified by its TFN, which starts at the very top of the organization and works its way down through the various groups to the user, as is the case with a file's full path name on a Unix system.

Clustering Tarantella

Tarantella will also support load-balancing users over multiple connectivity servers, so each user is automatically sent to the least-loaded Tarantella server when he logs in. You do this by creating an array of Tarantella servers -- each may run on different operating or hardware systems, but all must run the same version of Tarantella. Thus, you can link together Solaris, HP-UX, or other servers. Tarantella may be the first practically useful cross-platform clustering system for user load-distribution and high availability.

This load balancing can be customized for each user's account. By default, users are allowed access to every server in the array, but each can be designated by his or her TFN to be load-balanced to a particular set of servers within the array. While one user might be directed to only Solaris servers, other users may be allowed access only to machines where they can run a particular application. You can also specify a preferential order to the server they should log on to. This allows you to place more powerful servers ahead of weaker ones to carry more of the load.

Unfortunately, Tarantella can't guarantee that the same applications will be available on every server, unless all are installed on each. To truly support platform independence, you'll need applications available for both platforms. There is even an advantage to this -- you could use Tarantella to migrate an application from one server type to another, without changing the user's interface to the application. Since both the old and new servers run the same application, the migration is transparent to the user.

What's not there

Tarantella doesn't fall too far short of being an application service provider's dream product. ASP users don't need to install software on their machines because they can access it from any browser, rather than from just that specific machine with the installed client. They can also obtain access to any number of applications on Windows and Unix platforms, which avoids the complication of trying to manage cross-platform user licenses on a network.

It is true that not all applications work perfectly through thin-client servers. Graphically intensive applications require a high-speed connection to the server and probably won't work too well within the confines of the browser. Regular business and office productivity applications, on the other hand, should run like a charm.

Tarantella also needs to account for an application or server's usage and be able to transfer that information to a billing or accounting database. Although it has a centralized user account database (the accounts on the application server), each server maintains separate accounts that need to be managed separately from Tarantella.

Finally, Tarantella's TFN doesn't use and isn't compatible with LDAP, even though the two act in very similar fashions. SCO should consider replacing TFN with LDAP in order to make the package compatible with some of the enterprise management products and directory service packages out there. This way, administrators wouldn't have to maintain two separate directories.

Crawling around with Tarantella

Tarantella uses the X protocol and its own Webtop protocol to communicate with clients and application servers, which imposes overhead in user access to applications. I didn't find the user interactivity through the Webtop to be any slower than a directly connected session -- the only slowdown occurs when you first connect to the application. Connecting remotely with a 56 Kbps modem will provoke a slower response from some applications (e.g., displaying a jpeg using the Unix xv tool), but the lag will not be noticeable for others (e.g., terminal application, mail reader).

Still, the main focus of the product is to provide the three-tier architecture of connecting users to applications, without having to rewrite them to a new type of Web application server. This provides access to thousands of existing applications and tools in both Unix and Windows areas. Most of Tarantella's competitors lack flexibility because they're limited to either one platform for the application server (either Unix or Windows, but not both), or require special software to be installed on the client machine.

For those of you who have numerous legacy applications on IBM mainframes, there is also a 3270 emulator option for Tarantella that can be added. However, if you have legacy Unix applications and servers, Tarantella can give them a new life and still keep up with the needs of the new Web-enabled enterprise. The product could use a reduction in pricing -- $395 per user is much higher than any other product in this category -- and several of the features I described earlier could be added to make it more acceptable to the enterprise network and ASP market. Even as it is, though, Tarantella is still one of the best products in the category of thin-client servers.

Copyright 2019 IDG Communications. ABN 14 001 592 650. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of IDG Communications is prohibited.