Both AppView™ and AppViewXS™ provide industry-leading tools for interface re-engineering of legacy applications. By " interface re-engineering" we mean:
Access of the functionality embedded within terminal-based applications through graphical user interfaces that utilize modern controls and communication protocols to allow a rejuvenated look and feel for the application plus the ability to extend and build upon the legacy application for workflow and interface optimization as well as multi-host, multi-application data integration.
Both products include the Studio development environment that provides drag-and-drop conversion of legacy application screens to graphical interfaces. A re-engineered interface to your host application that includes new functionality and optimized workflow can be created without any programming using the tools included with either AppView or AppViewXS.
The following table outlines some of the key differences between AppView and AppViewXS and should serve as a guide to help determine which product is best suited to your specific environment and business need:
| Category |
AppView uses a distributed processing model in that logic executes within applets downloaded into java virtual machines at the end-user PCs. Best used within Intranet environments, where user community is known and configuration (such as jvm level) is controllable.
|
Centralized processing model in that logic executes in servlets within a web application server layer. End-user activity is strictly via browser, e.g. Internet Explorer. Reduced installation and implementation footprint for end-users due to this portal architecture. Recommended solution for Internet environments, where user community is indeterminate or outside of control sphere.
|
| Deployment |
Requires installation of administration and development tools (WebStation) to developer’s workstation and emulation components to a web server. Optional tunneling and metering components are also installed at the web server and require a servlet runner.
If a Security Proxy is implemented (HTTP/HTTPS tunneling is the preferred security method), it should be installed on a machine other than the web server. This machine must also be reachable by end users. This architecture allows the Security Proxy to listen on port 443, a “well-known” port for SSL communication.
Developers and administrators require ability to write files to folders on web server (e.g., FTP).
Client workstations require a compatible browser and JVM. The initial connection will require a java applet download of around 7MB of to the client’s workstation. These applets are cached locally eliminating this step for subsequent accesses. The security settings for client workstations must allow download and execution of Java applets.
Emulation components may also be directly installed at the end-user’s workstation eliminating single point of failure (web server). |
All components (Administrator, Studio, Rendition Engine) are installed to the web server. A compatible servlet runner is required.
Developers and administrators require ability to download Java applets from web server and rights to modify files at web server.
Client workstations require only a compatible browser. No Java applets are required at the client. |
| Development |
The developer accesses and executes Studio locally to customize screen map files. Completed maps must be published to the web server. |
The developer accesses the AppViewXS server and logs onto a Studio session. The Studio applet downloads to the developer’s workstation allowing customization of screen maps. These screen maps may be exported as HTML and further customized using standard HTML editors and techniques (e.g., style sheets and javascript). |
| Infrastructure |
The web server serves HTML session startup pages, Java applets and map files to client workstations via HTTP (or HTTPS). Implementation of Tunneling will incur minor resource requirements on the server. The server requirements for Metering are minimal. Many end-users can be served by a single web server. |
Performance can, of course, vary due to many factors. Conservative performance testing results indicate an average web server should readily handle 500 or more active users. Some of our customers support over 3000 users per server. Contact us for performance estimates for your specific environment.
Since no local storage is required, AppViewXS may be used to deliver host access with enhanced functionality to users equipped with diskless workstations (with a compatible browser). |
| Security |
If Tunneling is implemented, the channel between the client workstation and Tunneling servlet takes advantage of any security methods provided by the hosting server and client browser. This channel can be encrypted as long as HTTPS communication is supported between the client workstation and the server hosting the Tunneling servlet. Server and client authentication can be achieved with standard certificates. The communication protocol between the Tunneling servlet and the host can be Telnet, SSl or SSH2.
If the Security Proxy method is implemented, the client workstations must be able to establish an SSL connection to the Security Proxy IP address and port. The channel between the client workstation and Security Proxy is encrypted. Server authentication (DSA) is provided, but client authentication must be provided through other means (e.g., LDAP).
Host application fields may be hidden through customization in AppView. These hidden fields and their data are still transmitted to the client workstation but are not displayed. |
If Tunneling is implemented, the channel between the client workstation and Tunneling servlet takes advantage of any security methods provided by the hosting server and client browser. This channel can be encrypted as long as HTTPS communication is supported between the client workstation and the server hosting the Tunneling servlet. Server and client authentication can be achieved with standard certificates. The communication protocol between the Tunneling servlet and the host can be Telnet, SSl or SSH2.
Host application fields may also be hidden during customization in AppViewXS. These hidden fields and their data are not included in the HTML page sent to the client browser. Screens with sensitive data may be customized to securely deliver only the desired access to particular data. |
| Integration |
Nearly any data source accessible by the client workstation may be integrated into the AppView presentation. Desktop applications can be opened and data exchanged with those applications.
Remote databases may also be accessed via a remote database servlet hosted on a server with connectivity to the target database. Communication between this servlet and the client workstation is compatible with any security methods provided by the client browser and server hosting the database servlet. |
Nearly any data source accessible by the web server hosting AppViewXS may be integrated into the user interface. Functionality within the host application may be encapsulated and published as web services.
Through its Struts Framework, AppViewXS can tightly integrate Legacy applications with Java applications, to add Java functionality to the legacy application, blend java modules with legacy modules, or facilitate an incremental migration of a legacy application to a java environment. |
| Performance |
All processing for AppView sessions occurs at the client workstation. The response time when moving between screens is determined mainly by the resources available at that workstation. As the number of users accessing the host application increases, the performance is determined by the scalability of the host application.
To support the response time expected by experienced users, type-ahead is supported in AppView. A Tandem 6530 terminal will lock the keyboard during screen transitions. Most terminal emulators (including AppView) support caching of keystrokes during the period the keyboard is locked and transmit those keystrokes once the new screen has been received. With this feature, an experienced user can operate in the “heads down” mode to which they are accustomed and are not required to wait for screen updates. |
With AppViewXS, the host data stream is interpreted by a terminal emulator, screen signatures are calculated and any customization maps are applied. Screens submitted by the users then receive any post-processing defined in the customization such as Get-to-the-Point. These steps are very similar to the process which occurs in AppView. However, the rendition engine of AppViewXS must also translate the incoming data stream from the host to HTML and submitted HTML pages from the client back to a terminal data stream.
The screen presented to the end-user by AppViewXS is an HTML form. Submitting this form (by sending the appropriate function key) transmits the data back to the AppViewXS rendition engine, which then formats and forwards that data to the host application. Any keystrokes typed to the browser before the next screen arrives are ignored.
Performance can, of course, vary due to many factors. Conservative performance testing results indicate an average web server should readily handle 500 or more active users. |
