HostExplorer Web-to-Host

(1)

HostExplorer Web-to-Host

The superiority of modular versus server-centric web-to-host

architecture

Open Text Connectivity Solutions Group September 2009

Abstract

This document is comprised of two parts:

Part 1: This section provides an overview of HostExplorer Web-to-Host for those interested in comparing web-to-host solutions. It discusses the history of web-to-host, the different

components of a web-to-host solution, and compares the merits of the current technological alternatives. It then explains why HostExplorer Web-to-Host’s modular architecture is superior to a traditional, server-centric, monolithic solution.

Part 2: This section provides a practical walk-through for some of the main features of HostExplorer Web-to-Host. It explains common tasks, such as connecting to hosts, setting permissions, security, and customizing the user experience. It also examines the benefits of HostExplorer Web-to-Host from a practical standpoint.

(2)

Part 1: About Web-to-Host Terminal

Emulation

History of Web-to-Host

The first time the IT industry uttered the term ―web-to-host‖ was in 1997. In those days, mainframes were in the midst of the SNA to IP transition, AS/400 was becoming the infrastructure of choice for many mid-size businesses, UNIX was at the pinnacle of its popularity, and terminal emulation software had a prominent place in any successful business’ software portfolio.

Needless to say, like many 1.0 versions, the first web-to-host solutions were slow, buggy, heavy on server requirements, and far from feature complete. Any

company switching from a rich desktop client to one of these new ―thin‖ clients had to be ready to sacrifice 50% or more of the speed and features of their desktop client. ―Thin‖ was more of a buzz word than a reality, as most solutions required the download (and installation) of a java virtual machine on the desktop in addition to the heavy applet that was necessary for terminal functionality. Advanced features, such as macros, were not the primary focus of these solutions.

Customers, however, embraced the vision and buzz words that vendors had thrown into the pitch, while in fact looking for something different. While vendors were focusing on the ―thin‖, browser-embedded aspect of their lightweight terminal emulators, customers were searching for a no-manual installation, centrally managed, full-featured product that could be accessed from a browser by zero-privileged users with minimal administrative intervention.

Let’s be honest, vendors didn’t get it right until much later, in fact many still don’t.

Who Needs Web-to-Host?

The value of web-to-host, and the reason it’s still very much alive, is that it fits the following business scenarios:

Internal deployment scenario

Administrative IT overhead is a significant issue for many companies. Much time is spent deploying and updating software and settings to user desktops. With terminal emulation software often deployed to hundreds, or thousands of desktops, web-to-host offers a convenient solution to reduce deployment and administrative costs.

Multi-location deployment scenario

Companies of a certain size likely have offices and employees in multiple locations around the country or the world. Deploying software to these locations

(4)

often requires sending a master image to a local IT resource, internal or outsourced, and praying that everything will work out of the box. Because it requires nothing more than a web browser, which is a standard feature on any user’s desktop, and HTTP access, web-to-host is an ideal solution for distributing a terminal emulation service to remote locations without involving any additional local resources.

Mobile user access scenario

Many organizations have embraced mobility as a work culture, but despite all the benefits they obtain from it, managing mobile users’ desktops remains a difficult task. Again, web-to-host offers a cost-effective and practical alternative to traditional software asset management, offering a central location where mobile users can go to access enterprise legacy systems.

Casual user access scenario

One of our customers had a mainframe that they maintained for the sole purpose of hosting a shared scheduling application they had built years ago that was deeply entrenched in their business processes. The thousands of users they had did not use it for more than ten minutes per day, but this application could not be shut down or migrated without incurring significant risk and cost. Web-to-host technology allowed their casual users to access this business critical application while minimizing the IT overhead and deployment costs.

Third party access scenario

A large number of companies used to be satisfied with deploying desktop clients to their staff, local or remote, but as the economy became more global, some recognized the need to offer a terminal emulation service to their customers or partners. This was the case of one of our healthcare customers who built a set of mainframe-based self-serve applications for their institutional customers. Using HostExplorer Web-to-Host they were able to provide access to the applications at minimal cost with maximum security.

Virtual desktop scenario

Some companies have structured their employees’ lives around a central

enterprise portal. These companies often deploy a minimal set of functionalities to the desktops and rely on the central web-based portal to distribute the services and tools required by employees to perform their duties. Regular desktop-based terminal emulators do not perform well in that scenario, but web-to-host solutions are a natural fit as they integrate nicely with other web-based applications.

Desktop standardization scenario

For years, IT organizations around the world have been looking for ways to standardize desktop images and reduce the number of master images that are needed to suit the needs of any department. Not only is this quest for

standardization motivated by a potential reduction of the IT department’s overhead, but the prospect of reducing license costs while maintaining a firmer

(5)

grip on license compliance has also been a major driver. Web-to-host solves the problem by removing both the software and license from the desktop and moving them to a central location. This allows for complete visibility of the number of licenses in use at any given moment while guaranteeing that no user is trailing 3 or 4 versions behind because his or her desktop has not been updated.

Key Business and Technical Benefits

Web-to-host offers a variety of benefits that appeal both to the business needs and the technical requirements of any organization:

 Reduced license acquisition and license management costs

 Better control over license compliance

 Increased availability of IT staff for strategic projects resulting from shorter deployment time and reduced administrative overhead

 Improved security for both user access control and network traffic

 Standardization of terminal services across all potential users: local users, remote users, mobile users, casual users, and third parties

 Ability to virtualize the user desktop by moving the emulation services to a central web-based location

Deconstructing Web-to-Host

The term web-to-host was coined by vendors, analysts, and the public alike because of the ability of these solutions to enable connections to a host

(mainframe, AS/400, UNIX etc) from a web server accessed through a browser. Despite the limitations of their predecessors, there are now more intricate and modern web-to-host solutions that offer a rich set of functionalities and services in addition to their core terminal emulation capabilities. The table below outlines the fundamental services that should be offered by any modern web-to-host solution.

Client Services

Thin client distribution Distribution and deployment of thin client components to the user desktop

Software update Ability to update thin client components on the user desktop

(6)

Connection Services

Direct connection services TN3270, TN5250, Telnet, SSH, FTP, and SFTP connections to enterprise hosts

HTTP connection services Ability to channel connections over an HTTP data stream

Proxy Services Ability to proxy connections through specific network ports

Traffic security Encryption, authentication, and integrity of connections and administrative traffic

User Control Services

Directory services Management of a user directory or connection to an existing directory.

Repository Storage of settings, user directories, and connection profiles

User Access Rights Ability to manage access to connections and settings for users or groups of users

UI and features lockdown Controlling user access to features

Server Services

Redundancy and failover Services that reduce system exposure to failure and downtime

Usage metering Reporting and auditing of user activity

License management License provisioning and control services

Emulation Services

Terminal

Control over terminal behavior, including terminal type, emulation settings, and output (display type, colors) and input settings (keyboard, mouse, shortcuts)

Printing Ability to create printing sessions and control a variety of print jobs centrally or locally

File Transfer Ability to transfer files using different protocols and mechanisms depending on the nature of the host

Automation Services

Macros Support of macros for environments and languages to help users automate tasks or create custom programs

HLLAPI application support Support for third-party applications using the HLLAPI interface to communicate to the host through the emulator

APIs Support for third- party APIs (COM, .Net, OHIO, OLE, etc)

(7)

Migration Services

Macro conversion Ability to convert macros from other terminal emulation solutions

Settings conversion Ability to convert connection settings (including keyboard and colors) from other terminal emulation solutions

Terminal environment replication

Ability to replicate the user environment from other terminal emulation solutions to minimize the learning curve

Thin Client Does Not Mean No Client

The term thin client has been given various meanings. In the hardware world, a thin client often designates a basic PC that requires a connection to a central system in order to obtain the capabilities (primarily software and storage) that make it functional.

In the software world, a thin client is software with the following characteristics:

 It is deployed through a web browser

 It does not require a traditional installation procedure on the desktop or require users to have administrative rights to their machines

 It is centrally managed and configured

 It is more modular and weighs less on system resources (CPU, memory, and hard disk) than a desktop-based client

A thin client can be just as powerful as a desktop-based client. Why should users settle for less?

A thin client requires code to be executed on the target machine in order to function, regardless of whether that code is native or sandboxed, for example .Net, Java, Silverlight, or Flash. Software that does not require code on the client side cannot be called a thin client; in fact, the term ―client‖ does not apply at all. DHTML, AJAX or javascript-based solutions are not thin clients but web clients. In the world of terminal emulation, there is no such zero-footprint solution available that fulfills all the functional requirements. All web-to-host solutions that have achieved even a modest level of customer adoption require code running on the client, regardless of the nature of that code.

Dispelling the Java and ActiveX Myths

Myth #1: ActiveX lacks security

For many years, proponents of thin clients have been fighting over whether, from a security standpoint, Java is a better technical solution than ActiveX. Let’s face it; it is hard not to see higher interests at play here, particularly when considering that, when these debates began, a fierce battle was raging between the

(8)

proponents of open source and Microsoft. Unfortunately for a lot of good solutions, Microsoft lost the PR battle on that one. All of this occurred at a time when security was an afterthought for Microsoft.

It was not that ActiveX was intrinsically unsecure, it was that the whole operating system was unsafe. ActiveX was nothing more than a name that designated the method for native Windows applications to integrate and interact with Internet Explorer. The underlying code of any ActiveX component is just a regular Windows application, packaged as a COM object that can be driven and controlled from IE.

What most people ignore is that they are already using thousands of ActiveX controls in their day-to-day interaction with the Windows operating system, even if they never open a browser. For example, Windows Explorer is an ActiveX container application that has been built by assembling dozens of components. Has this stopped people from using Windows altogether? Of course not! Everyone happily continues using the exact same objects that have been deemed unsecure when embedded inside a browser.

Are these objects harmless when they are not inside the browser? Of course not! HTTP requests and browsers are far from the only ways that Windows sends and receives information on a network. Anyone with the right skills is capable of exploiting the security breaches of the model. An obvious example is in emails. Does anyone question the ability of an email program to transmit executable attachments and allow users to launch them? Certainly not, but the principles at work are the same.

Microsoft has come a long way in addressing security, and their structural (system architecture) and tactical (reaction to security breaches) modifications have paid off. Unfortunately for them, they will never totally recover from the mistake they permitted years ago by deciding to brand and single out a

technology that, at its core, was nothing more than a way to run otherwise native code inside their browser.

Myth #2: Java ―superiority‖

Back in the early days of web-to-host, proponents of the Java language were extremely forceful in claiming that Java was a technically better solution for web-to-host solutions. Although Java is an excellent language, and to this day constitutes one of the greatest innovations to come out of Sun’s laboratories, it’s not without problems, and many of these issues are show stoppers in the context of a web-to-host terminal emulation solution.

1. Slow: Java is an ideal language to use when creating portable server-side applications, but it has always been, and will always be, slow on the desktop. Because they are hosted inside a virtual machine, Java applications have to traverse more interpretation layers before a command hits the processor than native applications. Regardless of how fast your machine is, the delay will always occur. That’s just how the model works.

(9)

2. Resource intensive: A corollary to the above is that Java applications are much more likely to consume more memory and CPU resources than native applications. This can be trivial for server-side applications, because Java can compensate by offering a more efficient threading or memory management model. Desktop applications, however, rarely require running hundreds or thousands of threads and, therefore, do not get that benefit. The additional payload that’s imposed by the Java virtual machine takes a toll on the desktop resources, and users notice the effects.

3. More code running: To many people’s understanding, java-based solutions are closer to the ―thin client‖ concept, because they do not require code running on the client. Nothing could be further from the truth. In fact, java-based solutions are further from the thin client concept than their native counterparts. Not only do they require code to be downloaded and executed on the client (applet or application), they also require twice the code - the virtual machine itself and the java application. 4. Client-side code install: Some people argue that in the case of java applets, the code does not stay on the machine which makes it less vulnerable. The reality is that customers are not happy with downloading a new client every time they want to start a connection. No matter how fast their networks are, even 10 seconds is an eternity from a user standpoint. That’s why Java, like any other sandboxed technology, supports client-side code installation (caching), which keeps code permanently on the users’ machines and is now standard practice. 5. Administration nightmare: One more problem with Java is the

limitations of virtual machines. Considering that virtual machines are self-contained systems, which offer limited exposure to the underlying system, administrators now have two duties: maintaining the underlying OS, and maintaining the virtual machine itself. In addition, updates that get published on a regular basis need to be distributed to users’ desktops. There is also the risk that these updates could cause problems, either on the OS side or on the java application side. In conclusion, maintaining a clean Java environment requires significantly more effort, because it is required in addition to maintaining the host operating system.

The Failure of Traditional Architectures

You would expect that, with more than 10 years of history in building web-to-host solutions, IT vendors would have reached a certain level of product maturity. Alas, many vendors, including some of the most prominent, have completely

disengaged their development resources from these solutions.

Most web-to-host solutions rely on the same type of architecture - a distinct set of client components, different from their desktop-based client. These client

components are distributed by a monolithic, middle-tier server that hosts all the web-to-host services including, but not limited to, client services, directory services, security services, access control services, and emulation services.

(10)

Figure 1 – Architecture of a traditional web-to-host solution Here’s a quick overview of the key problems related to this architecture:

 No desktop-to-thin migration path: Because the desktop client and the web client components are based on different code, organizations have no easy way to transition from one to another. Settings and macros are often incompatible from one world to the other. In fact, some vendors have started to provide their own migration tools to move users between their own solutions.

 New licenses equal higher acquisition costs: For many well established vendors, releasing a web-to-host solution is an opportunity for them to charge their clients for seats they paid for when they purchased their desktop clients years before. These vendors have come up with all kinds of maintenance renewal schemes that force customers to open their wallets in order to access a technology that they already own in another form.

 Single point of failure: Setting up a monolithic, middle-tier server that is the only method to provide user access to host applications is a recipe for disaster that leaves administrators with 2 options: either build the web-to-host system around a single point of failure, or set up redundant systems in case of malfunction. The net result is an increase in

(11)

11 | W h it e P a p e r

acquisition and operating costs that reduces the ROI of the web-to-host solution.

 Hardware intensive solutions: A lot of traditional web-to-host solutions require more than a web server to function. Often, they come with their own suite of services that add to the CPU and memory load on the server and limit the system’s scalability. Why should you have to run another directory or repository service when your Windows Server OS already comes optimized to offer these services?

 Higher TCO: Whether it’s license acquisition, system configuration, or additional hardware acquisition and administration costs, traditional web-to-host solutions are often more costly than their desktop-based counterparts from the standpoint of Total Cost of Ownership.

 Separate directories and account provisioning: Not all traditional web-to-host solutions have this problem, but a number of them require their own user database. Needless to say, these solutions don’t integrate well with account provisioning systems. Why should you incur the cost to maintain a separate directory of users and groups when your IT staff is already doing that job with your Enterprise directory?

 Access control double-duty: Even if they happen to integrate with Enterprise directories, traditional web-to-host solutions always come with their own permission model, which can prove a bit frustrating and very expensive when you consider that Windows Operating Systems already integrate ACLs and provide a wide range of tools to manage them.

 Services interdependency: One consequence of the ―one server to rule them all‖ approach is that every piece of the architecture depends on another. Should a piece fail, the whole ensemble falls like a deck of cards, leaving users with no possibility to access the hosts unless a significant amount of money has been invested in purchasing additional servers to set up a strong fail-proof cluster (and not all solutions support clustering).

(12)

 Prohibitive learning curve: A different code base for desktop-based and web-based clients translates into different UI and user paradigms, and everyone knows that changing user habits is one of the most counter-productive things that a company can do. One of the failures of traditional solutions is that by creating a separate web-to-host solution that is vastly different from their desktop solution, they are forcing users to adopt another product, which causes these products to lose much of their initial appeal. Why should you be loyal to a company if their solution is as different to your existing users as one offered from another vendor?

HostExplorer Modular Web-to-Host Architecture

Where all traditional web-to-host solutions offer a monolithic approach by providing all of their services in one single server software, HostExplorer Web-to-Host provides a completely different architecture built on a set of independent modular services that rely on a common code base with the desktop client.

(13)

1 3 | W h it e P a p e r

Separation of duties improves reliability and scalability

The first thing that clearly distinguishes HostExplorer Web-to-Host from other web-to-host solutions is that all the web-to-host services are completely isolated from each other. HostExplorer Web-to-Host does not rely on a single server to handle all of its components; instead, each component is isolated in a standalone service that can be deployed independently from the others.

This approach offers several benefits:

 No single point of failure

 More scalability

 More flexibility in distributing server resources

 No need to dedicate hardware to a web-to-host server

Re-using system components: why reinvent the wheel?

Most web-to-host solutions offer their own repository, directory (or they replicate the enterprise directory), and most importantly, their own ACL (Access Control List). But why reinvent the wheel when the Windows Operating System already offers all of these components for free?

HostExplorer Web-to-Host leverages the investment that organizations have already made by reusing as many system components as possible instead of replacing them with their own:

 Access to the thin client is controlled from any standard Enterprise web server (Windows or not) that can be linked to the Enterprise Active Directory or LDAP directory.

 Connection settings are stored in profile spaces, which can be any combination of network file systems (shared drives, UNC), local file system as well as Enterprise directories themselves (LDAP and AD). The number of profile spaces is unlimited. HostExplorer Web-to-Host

presents a single, unified view of all its connection profiles to the user, regardless of the number of profile spaces created.

 Access to the connections and their settings is controlled by the

Enterprise Directory ACLs that have been assigned to the objects in the profile spaces — files and directories for file-system based profile spaces and nodes in the LDAP tree for AD or LDAP based profile spaces. This approach ensures that HostExplorer Web-to-Host not only minimizes the work of the administrator when it comes to managing users and assigning rights, it also fully respects the Windows security model by not replacing it with a model of its own. Finally, HostExplorer Web-to-Host also guarantees that Enterprise resources (directories & file systems) as well as Enterprise policies (security, rights, users, and groups) are fully leveraged.

A single code base for both the thin desktop clients ensures complete interoperability, maximum feature availability, and equivalent speed

Contrary to traditional web-to-host solutions, the HostExplorer Web-to-Host thin client uses the exact same native code base as HostExplorer.

(14)

The two solutions share the following aspects:  Features  Speed  Settings  Macros  User Interface

This enormously benefits the desktop administrator who can cover both the desktop-based and web-based users with a single solution without doing double the work. Even better, HostExplorer can leverage the repository distributed by HostExplorer Web-to-Host to manage all users under the same policies.

In terms of speed and features, the two solutions run at the same speed and use the same minimal memory footprint on the machine. In addition, administrators have several options to select which features of the thin client are deployed to users.

Economic considerations

HostExplorer Web-to-Host also distinguishes itself from its competitors when it comes to cost. The main advantages are:

 No need to purchase new licenses: HostExplorer Web-to-Host and HostExplorer desktop are covered under the same license.

 Reduced hardware requirements: By re-using existing enterprise servers, HostExplorer Web-to-Host diminishes acquisition costs.

 Reduced learning curve: Users of HostExplorer automatically know how to use HostExplorer Web-to-Host without any additional training.

 Reduced administrative overhead: Using the same settings and

administrative tools for both HostExplorer Web-to-Host and HostExplorer results in increased productivity. Many productivity tools that are included with HostExplorer let users perform routine and repetitive tasks in less time.

(15)

Part 2: HostExplorer Web-to-Host – A

Practical Guide

Accessing a Terminal Emulator from a Web Server

Distributing Connections to Users

HostExplorer Web-to-Host takes a simple, non server-centric approach to distributing connections to user:

Step 1: Decide what to distribute

Administrators choose whether they want to distribute a single connection (useful for casual users), or deploy one or several shared repositories. It is useful to deploy shared repositories when administrators want to distribute a mix of global and private connections to different groups of users in a single batch.

Step 2: Launch the HostExplorer Web-to-Host wizard

Once the connections (see Emulation Services on page 37) and profiles spaces (see Repository Models on page 24) have been configured, the administrator launches the HostExplorer Web-to-Host Wizard and selects the profile spaces he wants to distribute.

Figure 3 – Deploying a single profile or a profile space through HostExplorer Web-to-Host Wizard

Step 3: Specify deployment options

When deploying a single connection or an entire profile repository, administrators have the ability to specify many different options depending on their goals.

(16)

Figure 4 – Choosing the language and auxiliary files to deploy with the thin client

Figure 5 – Creating custom packages of third party files to deploy along with the thin client

(17)

Step 4: Copy files to the web server

Once the wizard has prepared the HostExplorer Web-to-Host package, the administrator needs to copy only the newly created files to any web server (on any platform) from which the user needs to access the Enterprise hosts. Q: How can I select which users have access to the thin client?

A: The recommended practice is to leverage the web server authentication and security settings, which allow administrators to protect certain locations with authentication schemes that can be tied to their Enterprise directory.

Q: Protecting access to the thin client is good, but how can I restrict access to certain connections while allowing access to others if I deploy a single client?

A: Profile access rights are not managed by the client deployment settings. Profile access rights are managed though the repositories (profile space) and the ACL (Access Control List) that has been set on the profiles or their components. For more information, refer to ―User Access Rights‖ on page 28.)

Updating and Refreshing Components

One of the main benefits of web-to-host is to offer a central location where the thin client is constantly up-to-date and can be automatically refreshed by the desktop administrator without requiring manual deployment to the desktops. Updating thin client components on HostExplorer Web-to-Host is a snap. Using the HostExplorer Web-to-Host wizard, administrator only needs to select which project to update and let the web-to-host wizard do the rest. Once finished, administrators will need to copy the newly updated projects to their web server. The next time they’ll launch a connection to the host, users will get their thin client automatically refreshed without any prompt or question. Of course, running connections are not interrupted and updates only take place when users have disconnected from the hosts.

(18)

Connecting to Hosts

Server-centric solutions have traditionally offered different methods of connection to the host. HostExplorer Web-to-Host offers the same methods and more. The key difference with server-centric solutions lies in the HostExplorer’s ability to deploy these connection bridges without requiring a central server that would also manage the rest of the web-to-host services.

This is a tremendous benefit to the administrator:

 Ability to deploy HTTP or proxy bridges only where needed in his network infrastructure

 Isolation of communications by network origin or groups of users

 Ability to scale or cluster the underlying system infrastructure to adapt to the volume of traffic

 Absence of a central web-to-host server reduces exposure to security breaches

 Lightweight standalone communication services can coexist with other services without requiring heavy duty server infrastructure

Direct Connections

HostExplorer Web-to-Host manages the following direct connections:

Telnet SSH SNA Server Netware for SAA

TN3270 Terminal

●

TN3270 Printer

●

TN5250 Terminal

●

TN5250 Printer

●

VT Terminal1

●

In addition, HostExplorer Web-to-Host supports the following file transfer protocols:  FTP  SFTP  IND$File  5250 data transfer 1

(19)

HTTP Connections

HTTP connections are a mechanism that allows users who are connecting to their host to communicate through HTTP to a middle-tier server on their network. The main benefit of HTTP connections is that they make it easy for administrators to manage connections that need to go through firewalls. By using an

HTTP/HTTPS connection, administrators do not need to open the telnet port on their firewall and they can quickly secure the communication over HTTPS.

Figure 8 – A HostExplorer Web-to-Host connection through the HTTP Proxy HostExplorer Web-to-Host supports 2 types of proxies:

 Generic HTTP proxies

 The HostExplorer Web-to-Host HTTP Proxy (included with the product)

Generic HTTP Proxies

HostExplorer Web-to-Host supports generic HTTP proxies and allows

administrators to configure connection and authentication modes. Authentication can be accomplished by specifying username and password, or by re-using the existing Windows Authentication credentials, transparently passing the login information to the Proxy Server.

(20)

HostExplorer Web-to-Host HTTP Proxy

Optionally, HostExplorer Web-to-Host comes with its own HTTP Proxy in the form of an IIS plug-in that’s easy to install and configure (the proxy is included in the product license):

1. Install the HTTP Proxy on IIS (follow the instructions in the Installer Media directory of your HostExplorer program directory)

2. Configure the session properties (Session Properties -> Connection ->

Connection Type -> Edit Host Info) with the same host address that you

would normally specify for a direct connection, and add the address of the HTTP proxy server in the appropriate field.

Figure 10 – Specifying an HTTP proxy address in HostExplorer Web-to-Host connection profile

Proxied Connections

SOCKS support

HostExplorer Web-to-Host supports SOCKS V4 and SOCKS v5 proxy servers. Administrators have the ability to configure connection as well as authentication settings. Both username/password and Kerberos authentication are supported. If using Kerberos, tickets can be imported directly from Windows, and traffic can be encrypted and checked for integrity.

(21)

The HostExplorer Web-to-Host proxy server

HostExplorer offers its own network traffic proxy server for setting up connection gateways wherever appropriate on the network. On the contrary to the HTTP proxy, which dynamically redirects users based on the information contained in the connection profiles, the generic proxy allows administrators to specify pre-established routes to the Enterprise host. By pointing Connection profiles to the address where the proxy service is running, administrators conceal the real address and port of their host, adding another layer of security to the connections.

Figure 12 – The HostExplorer Proxy Server Console Note: The proxy server can be used to redirect any network traffic, not just HostExplorer Web-to-Host or HostExplorer connections.

Securing Traffic

HostExplorer Web-to-Host offers many different ways of security traffic to the host. Administrators have the choice to use the following methods:

SSL Support

HostExplorer Web-to-Host natively supports SSL encryption for all type of connections. This setting is controlled in the connection profile dialog.

(22)

HostExplorer Web-to-Host also includes full support for PKI (Public Key

Infrastructure), which allows administrators to set up host authentication through public/private keys or X509 certificates.

Figure 14 – HostExplorer Web-to-Host Certificates and Keys Management Console

Kerberos support

HostExplorer Web-to-Host comes with a full Kerberos client or can leverage third-party Kerberos clients such as the MIT Kerberos client. Kerberos can be used, for instance, to provide single sign-on capabilities between Windows and UNIX or mainframes. HostExplorer Web-to-Host offers comprehensive support for Kerberos 5 and Kerberos 4 tickets.

Figure 15 – The HostExplorer Web-to-Host Kerberos configuration dialogs

SSH

HostExplorer Web-to-Host offers SSH support through its security add-on Open Text Secure Shell. This add-on needs to be installed only on the administrator’s desktop. Once it has been installed, the administrator has the ability to create SSH and SFTP connections to any host.

(23)

HostExplorer Web-to-Host SSH is full featured and includes:

 Granular control of network settings

 Support for terminal, secure file transfer, remote tasks, and X11 and generic port forwarding (incoming and outgoing)

 Support for both SOCKS and HTTP proxies

 Multiple authentication schemes (Password, User Key, User Certificate, Kerberos, Keyboard Interactive, Kerberos Key Exchange)

 Granular control of encryption, MAC and key exchange algorithms For customers who are looking to deploy only an SSH-based thin client, Open Text offers its Secure Terminal product, which uses the same code base as HostExplorer Web-to-Host. This product is a full-featured terminal and file transfer product that offers both a desktop-based and a web-based environment to perform SSH connections. It has all the features of HostExplorer Web-to-Host with the exception of mainframe and AS/400 connection support.

Figure 16 – HostExplorer Web-to-Host SSH configuration

HTTPS connections

As discussed in the HTTP Connections section (see page 19), HostExplorer Web-to-Host also supports securing traffic through the host using an HTTPS proxy.

FIPS 140-2 support

FIPS 140-2 is a standard established by NIST (National Institute of Standards and Technology) and CSE (Communications Security Establishment). FIPS 140-2 pertains to cryptographic modules in software or hardware products. FIPS 140-2 is used by government and industry to establish more secure systems and networks by developing, managing, and promoting security assessment tools, techniques, services, and supporting programs for testing, evaluation and validation.

(24)

All US Federal Government departments or agencies are mandated to purchase and use cryptographic products meeting the FIPS 140 standard to protect their unclassified, but sensitive data. The Canadian Communications Security Establishment encourages Canadian Government departments to use products with FIPS 140 certified cryptographic modules.

Private sector companies in North America, Europe, and Asia have started expressing interest in purchasing software that is FIPS 140-2 certified. It is expected that FIPS 140- 2 will gain wider acceptance outside of the US government in the future.

The HostExplorer Web-to-Host cryptographic module has been FIPS 140-2 validated. Its certificate is available online from the Open Text Connectivity web site (http://connectivity.opentext.com/)

User Control

It’s All About the Directory

Because it is not built on a central administration server model, HostExplorer Web-to-Host does not require its own directory. Instead, it integrates easily with Enterprise directories such as Active Directory or LDAP.

Directory functionalities can be used to:

 Manage the distribution of the thin client from the web server (controls who see what page and potential credentials before accessing the page)

 Manage ACLs on connection profiles that have been created in the various file-based profiles spaces

 Store connection profiles (directory-based profiles spaces)

 Automatically authenticate users to the hosts (single sign-on) when using Kerberos

Repository Models

Traditional web-to-host solutions rely on a central server that hosts a common repository containing the connection settings as well as other configuration parameters. HostExplorer Web-to-Host offers a decentralized approach to repository management by allowing administrators to set up as many ―spaces‖ as necessary where connection profiles are hosted.

Note: it is important to understand that the same repository can be used by the desktop-based version of HostExplorer as well as the web-to-host version. From an administrative standpoint, this is the equivalent of managing a unified

(25)

Profile Space Models

HostExplorer Web-to-Host profile spaces allow administrators to manage and deploy profiles from central or distributed repositories. HostExplorer Web-to-Host users can have read or write access to profiles in a Profile Space. There is no limit to the number of Profile Spaces that a particular user can access, and there is no limit to the number of profile spaces that can be set up. Profile Spaces are extremely flexible and allow administrators to adapt the repository architecture to suit their needs.

Some useful Profile Space scenarios include:

Single profile space: Users do not have any profiles stored on their desktops. All profiles are located in a central repository, which makes it easy for the

administrator to create new profiles or modify existing ones without having to redeploy them.

Multiple profile spaces: Users are split by group (by business unit for instance). Each group has its own Profile Space and cannot access another group’s spaces. This kind of architecture helps the administrator specialize profiles by publishing them only to the relevant group of users.

Combined profile spaces: Multiple Profile Spaces, with specialized profiles included in them, are created, and users are given access one or more of these spaces. This model presents the advantage of keeping profiles organized and secured by specialization (line of business or geography for instance), while letting users access them seamlessly.

Combined and personal profile spaces: In addition to providing access to global repositories, administrators can also allocate a personal space where users can store, retrieve, and modify their own profiles and settings. This setup constitutes the ultimate Profile Space experience, providing users with

(26)

Figure 17 – Example of profile spaces architectures

Profile Space Types

Contrary to other terminal emulation software solutions, Open Text designed Profile Spaces to leverage existing IT infrastructure without introducing a proprietary repository.

Profile Spaces can be set up on four different types of repositories:

 Local storage: This includes hard drives, removable drives, and any other fixed or removable media that is physically connected to the user desktop.

 Network storage: This includes network drives, UNC paths, NFS shares, and any remote location that can be accessed from the operating system.

 LDAP Directories: Any directory service that supports the Lightweight Directory Access Protocol.

 Active Directory: Microsoft’s directory service for use in Windows environments is tightly integrated with all Microsoft Operating Systems, Management Tools, and Security Policies.

(27)

Figure 18 – Different types of Profile Space repositories

Managing Profile Spaces

Administrators can manage multiple Profile Spaces with easy, powerful tools that are included with HostExplorer Web-to-Host. Profile Space Editor allows

administrators to add, edit, and remove Profile Spaces. Each Profile Space can be assigned a name and a distinct icon to help users identify it easily.

A particular Profile Space can contain references to multiple locations. If the first location is not available, HostExplorer automatically looks for the next online location. This ability allows administrators to set up fault-tolerant Profile Spaces and guarantees that users can always access their profiles.

When choosing the location for a particular Profile Space, the administrator is also allowed to use system replacers (in the form of $KeyWord$). Those replacers are transparently converted into real values when using the Profile Space. For instance the $USERNAME$ replacer is converted to the Windows user name of the currently logged in user.

Figure 19 – Creating a new Profile Space with multiple failover repositories in HostExplorer Web-to-Host The Profile Publishing Wizard is an administrative tool that allows profiles stored locally on a desktop to be published to an existing Profile Space. Administrators

(28)

who use this tool can set up the profiles and test them locally on their desktop before making them available to the user community. This tool can also be used to publish modifications to already-published profiles in a Profile Space.

Example

The major advantage of Profile Spaces is their versatility and flexibility. The following example illustrates the versatility of Profile Spaces in an organization: ACME Inc. is a typical multi-department company with employees working in 3 departments: Finance, Sales, and Production. Terminal emulation is in varying capacities by all employees:

 All users need to access the enterprise scheduling application, which resides on a mainframe.

 Finance users need to access applications residing on the company’s mainframe.

 Sales users need to access their CRM application on an AS/400.

 Production uses UNIX servers to manage the production cycle.

 Finally, all employees have access to specific mainframe and UNIX applications depending on their roles and use FTP file transfer to save their personal data.

In a classic decentralized management environment, these varied configurations would be challenging to use without creating a multitude of desktop images to suit each group’s requirements. With HostExplorer Web-to-Host, the

administrator can easily configure different profiles in a shared Profile Space where the connection profiles for each application are stored. Then, using the directory ACL, the administrator can decide who is granted access to each profile by user or by group. Finally, using the HostExplorer Web-to-Host Wizard, he can quickly set up a thin client distribution point on a web server, which points to the shared Profile Space. Upon accessing the Profile Space, users are presented with a single view of the profiles in that space that they have access to depending on their ACL settings.

Figure 20 – Example of a shared Profile Space for employees with different access permissions

(29)

Profile Spaces have been designed to leverage the existing IT infrastructure and policies in place. Profile Spaces take advantage of the native Access Control Lists (ACLs) available for each Profile Space type. Using the native rights

management system for each Profile Space type offers a number of advantages both for the administrator and the users.

Administrators

 Retain full administrative control over users’ rights: Profile Spaces obey the ACL rules and grant users read or write access to profiles only when authorized by the ACLs.

 No paradigm shift: No proprietary (i.e. different) users and group management system is required, which would create administrative overhead.

 No need to learn new administrative tools: User rights can be managed with the same tools that are used to manage the file system, or the directory rights.

Figure 21 – A view of a directory-based Profile Space from the Active Directory administration console

Users

 Transparency: Contrary to proprietary profile management systems, user see no difference between accessing profiles stored in Profile Spaces or traditional profiles.

 No unnecessary login: Since Windows credentials are used to determine Profile Space rights, there is no need for additional authentication before users can access the profiles.

 Easier access to profiles: With multiple Profile Spaces, users can see only the profiles they have access to, which reduces the risk of error while simplifying the user interface.

Managing Rights on Different Parts of the Connection Profile

Multiple Profile Spaces offer total control over the profile repositories and the methods in which users access them. In addition to these benefits, multiple

(30)

Profile Spaces can also be used to offer more granular access to the various elements of the profile.

A typical profile is usually a collection of different settings, such as connection information, keyboard map, color scheme, and security information. Many administrators want to provide their users with the ability to modify some of these settings (keyboard and colors for instance) while locking down others (such as connection and security).

Achieving such a level of granularity is usually not an easy task with traditional profile management systems but become a trivial operation with multiple Profile Spaces. Every settings of a profile are stored in schemes. Each scheme exists as its own independent file. Every scheme can be stored in a different Profile Space and has its own ACL.

The requirements described above can easily be fulfilled by storing Connection and Security schemes in a global read-only Profile Space while Keyboard and Colors can be distributed to every user in through a personal read-write Profile Space.

(31)

UI and Feature Lockdown

HostExplorer Web-to-Host offers many mechanisms for administrators to lock down the features of the product and its UI so that users can access only certain features.

HostExplorer Web-to-Host Feature Access Manager

Most system administrators do not allow their users to modify multiple settings on their desktop for fear that they might disrupt the software. With HostExplorer, administrators have the ability to lockdown certain features of the software. Regardless of the feature accessibility through menus, dialogs, shortcuts, or toolbars, the locked-down features are totally inaccessible to the user, thus preventing involuntary mistakes and saving considerable time for helpdesk.

Menu Manager

HostExplorer Web-to-Host gives administrators the flexibility to customize the users’ work environments. The Menu Customization feature allows administrators to design their own menu layout or to choose an existing preset layout.

Administrators that are looking for complete control over the user desktop can selectively disable menu items, thus improving the overall user experience while reducing the risk of mistakes. Menus are comprised of all HostExplorer Web-to-Host system commands, as well as host functions, editing keys, macro

commands, and QuickScripts.

(32)

Connection Settings Interface Manager

The user settings interface manager provides users with the ability to create and use a custom interface for the session settings. Administrators are able to provide only a selected list of modifiable settings to their user, thus eliminating the risks associated with the haphazard modification of sensitive parameters.

Additionally, organizations that migrate from alternative terminal emulation solutions reduce the learning curve by presenting groups of settings that are more familiar to their users.

Figure 24 – Customizing connection properties in HostExplorer Web-to-Host

Server Services

Scalability, Redundancy, and Failover

One of the immediate benefits of HostExplorer Web-to-Host architecture is that because it is not tied to a central server, it is much easier to manage and scale.

 Directory: The existing Enterprise directory (AD or LDAP) already provides these functionalities.

 Web Server: HostExplorer Web-to-Host can be used with any web server on any platform, thus allowing administrators to leverage the web server’s scalability, redundancy, and failover services.

 Repository: Whether it is a file or directory-based repository or a combination of both, organizations can leverage their existing system infrastructure to guarantee maximum up time and availability for the user. In addition, administrators have the ability to specify additional locations for HostExplorer Web-to-Host to look for profiles when the main location is unavailable.

 Other services: Additional services, such as proxies or metering, all rely on standalone components that can be deployed separately from each other. Setting up redundancy or failover systems for these services can be achieved through the tools that are provided with the Operating System or the web server they are installed on.

(33)

Event Monitoring and License Management

HostExplorer Web-to-Host includes event monitoring capability. This allows each thin client to report automatically to an Event Monitoring Server.

Note: Event monitoring works in the same way for both HostExplorer Web-to-Host and the Web-to-HostExplorer desktop client.

When a HostExplorer Web-to-Host session is launched, the event monitoring feature sends an update to the event monitoring server with the following information: user IP address, workstation name, user name, authentication domain, product installed and version of the product. Additionally, event

monitoring functionality sends detailed information about the components, name of the thin client, and its specific patch level.

Because it is deployed as an ISAPI dll for Internet Information Server, Event Monitoring Server does not require administrators to dedicate a specific machine for event monitoring purposes. It helps organizations keep track of their licenses while giving them an accurate picture of the different versions deployed.

Administrators can download a spreadsheet containing all event monitoring data and use any spreadsheet processor to analyze the information in the license report.

By logging into Event Monitoring Server, administrators are able to download a CSV file that contains all the event monitoring data for the organization. This file can then be opened in Excel and worked out through a PivotTable report. Thanks to the powerful features of the Excel PivotTable, administrators can manipulate the event monitoring data in any way they want and present it in the light that meets their information requirements.

Administrators can use any browser to access Event Monitoring Server online reports. Online reports can group the data based on several criteria, thus allowing the administrator to obtain a customized view of license usage and repartition if necessary.

Migration Services

Migration is Simple with HostExplorer Web-to-Host

Every migration project goes through a number of steps and begins with listing the project requirements and ends with maintaining the newly deployed solution. HostExplorer Web-to-Host has been developed from the ground up as an alternative to existing emulation software. It has benefited from the company’s many years of experience in replacing other terminal emulators. HostExplorer Web-to-Host offers significant benefits to organizations undertaking similar projects, including:

(34)

Step HostExplorer Web-to-Host Benefits

1. Listing Requirement Support for a wide range of standards

Unbeatable financial approach Unmatched features

2. Evaluating Access to Open Text resources: professional services, technical support, and R&D

Fast turn-around on requests

3. Recreating Environments

Ability to mimic other emulation look & feel: toolbars, menus, colors, keyboards

Ease of use

Rational User Interface

4. Switching Automatic Macro Conversion API-level compatibility

Profile, Keyboards, and Settings Migration

5. Securing Support for SSL, Kerberos, and Secure Shell Ability to lock-down every feature or menu

6. Deploying Windows Installer Support (desktop client)

Integrated Packaging Tool (desktop client) Web Deployment (thin client)

Citrix/TSE/SMS support (desktop and thin client)

7. Maintaining 24/7 Technical Support Quick Patch turn-around Easy migration to new versions

8. Minimizing Disruption Proven track record Low risk deployment Non-invasive migration

(35)

Migration at a Glance

Migration Capabilities Attachmate Extra Attachmate Reflection NetManage Rumba IBM PComm Colors ● ● ● ● Fonts ● ● ● ● Keyboard ● ● ● ● HotSpots ● ● ● ●

File Transfer N/A ● N/A N/A

Toollbar ● ● ● ●

Menu ● ● ● ●

Mouse Actions ● ● ● ●

Events N/A ● N/A N/A

Right-Click Menu ● ● ● ● Session Properties ● ● ● ● Macro Automatic Conversion ● ● ● ● Similar Language/Paradigm

● (same) ● (same) ● (same)

Similar Macro Editor ● (same) ● (same)

Similar OLE Library ● (same) HLLAPI

32-bit HLLAPI ● ● ●

(36)

HostExplorer Web-to-Host Migration Wizard

HostExplorer Web-to-Host Migration Wizard has been created to reduce the migration overhead. HostExplorer Web-to-Host Migration Wizard is a user-friendly powerful utility that automatically (or selectively) migrate users settings and macros from other terminal emulation software to HostExplorer Web-to-Host. HostExplorer Web-to-Host Migration Wizard can be used the following way: • Automatic: HostExplorer Web-to-Host Migration Wizard automatically scans

the user’s My Documents folder, locates the profiles to migrate, checks their dependencies on additional files, and converts all files to HostExplorer Web-to-Host profiles in the default Profile Space.

• Custom: This mode allows users to specify the types of profiles and additional files to migrate and the Profile Space in which to place these files. In custom mode, the Migration Wizard also stops at every step of the process to allow users to modify their choices.

• Command Line: HostExplorer Web-to-Host Migration Wizard can also be used as a command line tool. Command line mode offers a very effective method for administrators to perform migration tasks through scripts (for example, at the end of the software installation).

The migration wizard automatically converts the following information from other products:

Attachmate Extra! NetManage Rumba IBM PComm

HotSpot Schemes .ehs HotSpot Files .hsp Profiles .ws

Toolbar Files .etb Keyboard Map Files .map Macro Files .mac

Keyboard Map .ekm Macro Files .rmc Keyboard Files .kmp

3270 Color Schemes .e3c 3270 Profiles .wdm Toolbar Files .bar

5250 Color Schemes .e5c 5250 Profiles .wda

VT Color Schemes .edc 5250 Printer Profiles .wpa

Macro Script Files .EBM VT Profiles .wdu

Extra Session Files .edp

Printer Session Doc Files .epp

FTP Transfer Lists .etl

(37)

Attachmate Extra! NetManage Rumba IBM PComm

Schemes & Lists .eil

HLLAPI Compatibility

Although HLLAPI was originally designed to provide a common standard for third- party applications to communicate with any terminal emulation software, subtle differences exist in each implementation. HostExplorer Web-to-Host guarantees maximum compatibility with your existing HLLAPI application—even if it’s been customized for a particular emulator. HostExplorer Web-to-Host offers HLLAPI compatibility layers with the most current emulation software.

Mimicking Other Emulators

HostExplorer includes a powerful theme engine that allows administrators to quickly switch the emulator’s look and feel to mimic the user interface of other terminal emulation solutions. Themes affect a number of the user interface functions such as menus, colors, keyboards, fonts, and toolbars.

HostExplorer comes with pre-packaged themes for Attachmate, NetManage, IBM, and WRQ. Administrators can easily modify existing themes or create new ones and distribute them to their user base.

Emulation Services

Because it is built on the same code base as the HostExplorer desktop client, HostExplorer Web-to-Host shares the same emulation features. A detailed explanation of each feature is available in the HostExplorer technical whitepaper that is available on our web site at http://connectivity.opentext.com. The table below describes the following categories of features:

 Connection

 Security

 Terminal Settings

 Terminal Experience

 User Environment

 Look & Feel

 Productivity

 File Transfer

 Printing

 Automation

(38)

Group Feature Description

Connection Connecting to Enterprise Hosts

For a detailed description of the connection capabilities, please refer to the ―Connecting

to Hosts‖ section on page 18. Advanced Connection

properties

Specification of one or multiple LUs Specification of one or multiple hosts for

failover

Retries, keep alive and timeout settings

Support for Express Logon ATTN Key definition Support for NVT mode

Auto-start macro Power Management settings

Security SSL See page 21

Kerberos See Page 22

SSH See Page 22

HTTP/HTTPS Proxy See Page 23

SOCKS Proxy See Page 20

Generic Proxy See Page 19

Terminal Settings

3270 Terminal 3278 & 3279 – Model 2 to 5 and custom model – Extended attributes support Graphic Terminal 3179G, 3192G, 3472G, 3270 PCG – Cursor

and Cell size configuration – Support for Program Symbols, APL, and lightpen

Character set Support for Unicode and UTF-8 characters

5250 Terminal Model 2 and 5 – Color display VT Terminal VT52, VT100, VT101, VT102, VT220,

VT320, VT420, Ansi, SCO Ansi, IBM 3151, Linux Console – 7 and 8 bit support –

Custom width and height

Advanced VT settings Auto-wrap - local echo – interpreted or displayed control codes – Answer back

(39)

Display Settings Blinking control – Scrollback buffer configuration – Cursor mode and type configuration – Crosshair cursor support Terminal

Experience

Colors Ability to define a different color for each attribute – Support for color sets – Custom color palette – Support for third-party color

palette files

Fonts Choice of TrueType or Bitmap fonts including custom fonts

Keyboard Graphical drag-and-drop keyboard mapper – Ability to map all software functions, characters, action keys, editing keys, APL

characters, macros – Support for key modifiers, keyboard map printing – Support

for third-party keyboard files – Advanced settings for special keys

Editing Advanced editing functions – Support for smart insert, keyboard lock mode, cut and copy settings, multiple paste mode – Multiple

clipboard formats: text, bitmap, link, RTF, Table – Entry assistant

Terminal Windows Customizable window title – Window auto-lockout – Auto-sizing of terminal following

window sizing

User Environment

Mouse Customizable mouse actions – Ability to map all software functions, characters, action keys, editing keys, APL characters, macros –

Support for key modifiers

HotSpots Ability to create clickable area based on terminal text and region settings – Ability to map all software functions, characters, action

keys, editing keys, APL characters, macros

QuickKeys Ability to create keyboard shortcuts – Ability to map all software functions, characters, action keys, editing keys, APL characters,

macros – Support for key modifiers. Track Menu Ability to create a custom menu that can be

mapped to the right-mouse click – Ability to map all software functions, characters, action

(40)

Events Ability to map any terminal or software event to automatically trigger a software function,

characters, action keys, editing keys, APL characters, macros.

Sound Ability to create custom sound schemes to respond to different terminal events

Look and Feel Menu Ability to create custom menu sets and map software function, characters, action keys,

editing keys, APL characters, macros – Comes with pre-packaged 3rd party menus.

Toolbars Ability to create custom toolbar sets and map software function, characters, action keys,

editing keys, APL characters, macros. Comes with pre-packaged 3rd party toolbars.

Themes Ability to package all terminal environment, user environment and look and feel settings

in a comprehensive theme that can be distributed to users. Comes with pre-packaged themes for 3rd party emulator.

Productivity Features

Screen History Ability to auto-record screen flow and recall any previous screen. Cut and paste between

past screens and live screen.

Shortcuts Ability to manage lists of words that will be expanded automatically by the terminal when

typed.

Glossaries Ability to maintain list of terms and their descriptions, as well as shortcuts to these terms. Great for assisting input operations with professional or technical references.

Report Wizard Ability to define navigation rules between screens with similar content and create a unified report with selected data captured on those screens to be sent to a printer, a word

document, or an excel spreadsheet.

Workspaces Ability to record list and position of several terminal windows and recall them through a

(41)

File Transfer FTP See the HostExplorer technical whitepaper for details on file transfer. IND$File

SFTP

5250 file transfer

XModem, YModem, ZModem, Kermit

Printing 3270 Printer Session See the HostExplorer technical whitepaper for details on file transfer.

5250 Printer session

Print Screen

Multiple Print Screen

3270 and 5250 Print Server Gateway

Automation Basic development studio

HostExplorer Web-to-Host offers its own Basic-based development studio. The language is fully compatible with Attachmate

basic language and provides the ability to record and edit macros.

Macro studio The HostExplorer Web-to-Host macro studio offers a simple interface that allows the non-programming user to record and create their

own automation workflow

API Support for DDE, COM, OLE, OHIO – Support for Attachmate API calls

HLLAPI Support for HLLAPI, WINHLLAPI, EHLLAPI – Support for third-party API compatibility

layer (Extra, PCOMM, Irma, Rumba)

Migration Migration Wizard Graphical or command line tool allow HostExplorer Web-to-Host to scan the user’s disk and convert third-party software settings

(42)

Attachmate Extra Automatic conversion of macros, settings (keyboard, colors, terminal …), HLLAPI compatibility, included theme to replicate look and feel (colors, keyboards, toolbars, menus, settings), same macro language and

studio, compatible API calls

MicroFocus Rumba (formerly Netmanage

Rumba)

Automatic conversion of macros, settings (keyboard, colors, terminal …), HLLAPI compatibility, included theme to replicate look and feel (colors, keyboards, toolbars,

menus, settings), similar macro studio

IBM PCOMM Automatic conversion of macros, settings (keyboard, colors, terminal …), HLLAPI compatibility, included theme to replicate look and feel (colors, keyboards, toolbars,

menus, settings)

HostExplorer Web-to-Host

HostExplorer Web-to-Host

The superiority of modular versus server-centric web-to-host

architecture

Contents

Part 1: About Web-to-Host Terminal

Emulation

History of Web-to-Host

Who Needs Web-to-Host?

Key Business and Technical Benefits

Deconstructing Web-to-Host

Thin Client Does Not Mean No Client

Dispelling the Java and ActiveX Myths

Myth #1: ActiveX lacks security

Myth #2: Java ―superiority‖

The Failure of Traditional Architectures

HostExplorer Modular Web-to-Host Architecture

Part 2: HostExplorer Web-to-Host – A

Practical Guide

Accessing a Terminal Emulator from a Web Server

Distributing Connections to Users

Updating and Refreshing Components

Connecting to Hosts

Direct Connections

●

●

●

●

●

●

●

●

●

HTTP Connections

Proxied Connections

Securing Traffic

User Control

It’s All About the Directory

Repository Models

Profile Space Models

Profile Space Types

Managing Profile Spaces

Managing Rights on Different Parts of the Connection Profile

UI and Feature Lockdown

Server Services

Scalability, Redundancy, and Failover

Event Monitoring and License Management

Migration Services

Migration is Simple with HostExplorer Web-to-Host

Migration at a Glance

HostExplorer Web-to-Host Migration Wizard

HLLAPI Compatibility

Mimicking Other Emulators

Emulation Services