using thin-client technologies - · pdf filethin-client technologies direxions, august 2002 4...

Thin-Client Technologies Direxions, August 2002

1

Partnersin Success

Using Thin-Client Technologies

WindX, JavX, and Client/Server

Presented by: Brett Condy

Copyright © 2002 Best Software Canada Ltd. All rights reserved. No part of this publication may be reproduced, or transmitted in any form or by any means, electronic, mechanical, photocopied, recorded or other, without prior written consent of Best Software Canada Ltd.


2

Overview

Review of WindX Features and Functions

JavX Overview and Demonstration

WindX vs. JavX Feature Comparison

Implication of WindX Applications

Implication of JavX Applications

WindX Client/Server Option

The purpose of this presentation is to review ProvideX's Thin-Client WindX and JavX, and their features and functions. During the course of this session we will cover:

• A review of WindX

• A look at what JavX really is

• The advantages of using JavX and WindX --more than just providing a graphical interface!

• Comparing the advantages of JavX's platform independence vs WindX'saccess to the client machine

• How to identify if JavX or WindX is running

• The inner workings of ProvideX's Thin-Clients including 'Turbo Mode'

• How to configure WindX including Script processing

• Remote access and processing features

• The WindX utility program *WINDX.UTL

• Direct TCP vs Telnet

• Client/Server implementation

• Launching WindX from a web browser

• Running JavX as an Applet in a web browser


3

WindX Features

WindX allows remote execution of graphical applications.

UNIX and/or Windows hosts supported.Communication via RS232 or TCP/IP.

ProvideX is aware the terminal is WindX.Terminal type either WINTERM or ANSI.Graphical commands routed automatically.

Fundamentally, WindX is an enhanced graphical terminal emulator that provides a 'Thin-client' interface to ProvideX in order to run a graphical application while connected to a remote computer. Along with the graphical terminal emulation feature, it provides for local file access and processing.

Built into WindX is an ANSI/WYSE50 terminal emulator with support for both standard serial (RS232) communication or LAN (TCP/IP) communication using the Telnet protocol.

Normally, the host computer is a UNIX system which uses a serial or Telnet connection; but, there is a specialized client/server facility that allows WindX to connect to a Windows host.

Rounding out the the WindX feature set are WindX utility programs to handle functions such as file transfer, remote command processing, and task initiation.


4

JavX Features

Java implementation of WindX

Developed to run on the web

Requires nothing but Java Virtual Machine

Written in Java 2Runs on Windows, Linux, Solaris, and Apple's Mac OS X

Fundamentally, JavX is a Java version of WindX. While WindX is written in ProvideX (which is written in C), JavX is written entirely in Java. Rewriting much of ProvideX and all of WindX in Java, has given us the ability to take advantage of Java's platform independence, as well as Java's well known ability to run on World Wide Web pages.

To replicate ProvideX's complex graphical environment, JavX utilizes Java2 with the Swing Library of GUI components. This means that it runs as an application or in any web browser as an applet on any machine with a Java2-compliant Virtual Machine (JVM). If the client machine does not have the appropriate Java Runtime Environment (JRE), then the Java Plug-in is a one-time download which is incorporated seamlessly into the loading of the web page containing JavX.

ProvideX developers that currently deploy WindX can use JavX instead. Many of their applications can be taken with little or no changes and run over the web, on Windows, Apple's OS X, Linux, and Solaris machines.


5

Thin-Client TechnologyAdvantages

The Obvious:Graphical UNIX EnvironmentSeamless Integration with Application

The Not-So-Obvious:Improved Transmission SpeedsBetter Data Integrity over Data/File ServersTrue Distributed Processing Capability

ProvideX's Thin-Client technologies provide the ability to create a true graphical application which runs on either Windows or UNIX interchangeably.

No special software on the host, apart from ProvideX, is required to run on the UNIX system. This minimizes the amount of system resources required to service a large application and/or user installation.

ProvideX applications can use JavX or WindX with minimal code changes. System calls and functions that require access to the graphics engine are routed to the client station automatically.

The complete Thin-Client functionality has been integrated directly into ProvideX to create a seamless environment in which to create and run applications. All graphical directives and functions invoked by the application are tokenized and sent to the Client PC for processing.


6

Identifying a Thin-Client Session

ProvideX Recognizes the Terminal TypeIn UNIX, normally set TERM="winterm".For dynamic detection, set TERM="ansi".Special sequence is sent during ANSI initialization.

Application Can Detect WindX If:DEC(MID(MSE, 22,1)) > 0.TCB(88) is non-zero if WindX (ver 4.10 req'd).

Special Command Mode Prompt: '-}'

A WindX or JavX station is recognized by ProvideX when the terminal type is set to either winterm or ansi. These are the only two terminal types that are recognized as potential client stations.

The type winterm uniquely identifies the terminal as a ProvideX client. However, most UNIX systems will not recognize this terminal type which means that no other UNIX application can use it. To resolve this issue, the ProvideX ansi device driver sends a unique escape sequence to the terminal during its initialization process. If the terminal is a ProvideX client, then a special response will be generated. However, if the request times out, then ProvideX carries on under the assumption that the terminal is really an ansi device.

Once the ProvideX session on the server recognizes the terminal as a ProvideX client station, it changes the internal settings which allows the graphical requests to be routed correctly. Graphical requests are tokenized and forwarded to JavX or WindX for processing.


7

How ProvideX Thin-Clients Work

Standard mnemonics are transmitted "as is".'ESC' ($1B$) is followed by a two-character code.

'WINDOW' mnemonics are processed locally.No screen redrawing is required to 'POP' windows.File names in 'PICTURE' must be accessible locally in WindX but not in JavX .

This design minimizes network traffic.

WindX responds directly to the internal form of all mnemonics. Therefore, unlike conventional terminals, no translation table is required. Mnemonics, such as 'CS', are transmitted as $1B$ + "CS" and screen position commands, such as @(1,2), are sent as $1B$ + "@2" + CHR(1) + CHR(2). Long-form mnemonics, such as 'WINDOW' and 'DROP', are sent in their native form as well.

Since WindX is a ProvideX program, a lot of the functionality regarding screen refreshing is done by the local copy of ProvideX. This means that less data needs to be sent to a WindX station to handle functions such as window manipulation.

On a normal terminal when a window is created, the characters that make up the window border are transmitted from the Host to the terminal. Additionally, when a Window is removed, then all of the data that was hidden behind the window must be redrawn. These two functions are processed locally by JavX and WindX which reduces the traffic on the line and improves system performance.

If using the 'PICTURE' mnemonic, then the file name specified must exist (or at least be accessible) from the WindX PC. Make sure that the pathname of the bitmap is correct for the PC.

With JavX, the 'PICTURE' mnemonic takes either a URL or path on the local machine (e.g., www.pvx.com/some.jpg or c:\ some.jpg ).

If JavX is running in a web browser as an applet, it cannot access local files. All image sources (button, picture etc.) must be URLs. If not, JavX will add the source of the page on which it is embedded to the beginning of the path (e.g., "some.jpg" would become"www.thesource/some.jpg").


8

Terminal input/function keys are sent unchanged.

Graphical control requests are tokenized.ProvideX directives are tokenized and sent to JavX or WindX for local processing.New control attributes are forwarded to JavX or WindX for processing.

How ProvideX Thin-Clients Work

All input entered at the ProvideX client keyboard is sent directly to the host. Function keys and CTL events generated by graphical controls are included in the data stream as well.

ProvideX tokenizes all graphical directives and references, then forwards them to JavX or WindX for processing. These tokenized commands are then passed to the local copy of ProvideX for processing. Additionally, access to the new control attributes (e.g., BackColour$, Height, Enabled) is tokenized as well and forwarded to the client for processing.

In many instances, it is better to use directives rather than attributes when interfacing with controls under WindX. Each reference to anattribute involves a packet being sent to the WindX PC. For example, setting Grid values would involve setting three (3) attributes but only one directive.


9

Turbo Mode

Provides greater throughput.Controlled by the 'TU' system parameter at host.Reduces acknowledgement of messages.Means loss of error detection at the host end.

Normal Mode Turbo Mode

Write Request 1

Write Request 2Acknowledgment

Write Request 1

Write Request 2

During normal operation, each tokenized message sent by the host to the client requires an acknowledgment. While this process guarantees that the application and client are synchronized fully, it can slow down overall transmission speeds.

JavX and WindX support a Turbo mode which allows them to receive and process many requests locally without the need to acknowledge each transmission from the Host. To enable Turbo mode, set the system parameter 'TU' on the host system. While in Turbo mode, acknowledgments are not sent by WindX for directives and functions that do not return a value, for example, a write command for a graphical control. If an error occurs, it is reported locally or can be ignored depending on the configuration option.

While Turbo mode improves performance, any code that relies on error detection may not work as expected. For example, relying on an error branch to detect a bad value when issuing a WRITE command to a control will not work. Either change the application logic or turn off the 'TU' system parameter to avoid this situation.


10

JavX vs. WindX

JavX runs on World Wide Web Pages.WindX can access local files.JavX is platform independent.WindX supports Telnet.JavX has graphical enhancements. JavX does not require local copy of ProvideX.

JavX will run as an applet and requires nothing on the client machine but a web browser and a Java Virtual Machine (JVM). A user simply navigates to a web page which contains JavX and the Applet is sent to the browser. If the browser is closed, then the JavX session is terminated.

WindX can be launched by a browser on a Windows PC. However, it is not tied to that browser in any way. Instead, WindX requires a local copy of ProvideX.

WindX is a ProvideX program and can run local ProvideX applications, as well as access Windows DLLs and applications such as Notepad.exe. JavX, as an unsigned Applet, runs in a browser and cannot access local files. Furthermore, because JavX can run on such a large variety of platforms, there is no guarantee that a Notepad.exe will exist. Applications running JavX run everything on the server.

JavX does not support Telnet.

JavX has improved upon the 'FILL' mnemonic to permit the use of gradients. JavX supports jpgs and gifs and allows the source of an image to be an URL (e.g., www.thelouvre/monalisa.jpg ).These additions, along with a different "look and feel", offer greater flexibility for improved appearance. The developer can choose from:

• Metal (the default look and feel for JavX)

• Windows (the system default for Windows)

• CDE/Motif (the system default for Linux)

• Mac (only available on the Apple's Mac)


11

WindX Configuration

Two Connection Types:Telnet Using TCP/IP• Variations on the standard environmentsSerial on a Communications Port• Control over Baud rate and wiring options

Automatic EXIT on QuitLocal Reporting of Turbo Mode Errors

Configuration Settings

Pressing ALT-C allows the user to configure WindX. The configuration screen allows the user to choose the type of connection (Serial COM port or Telnet) and set a variety of operational parameters. The connection type determines which options are available:

Options are saved on the file WindX.CFG or on the file specified in ARG(1), if set. Multiple configuration files can be used as required.

Connecting Via COM Port

When selecting any of the COM ports, the user must specify the port speed and disable the hardware flow control, if necessary.

Continued…


12

WindX Configuration (Continued)

Connecting Via Telnet

When selecting the Telnet protocol, the user is required to enter the name and/or IP address of the targeted host computer. Several other configuration options are available:

Port

Normally, port 23 is used with Telnet communication; however, this can be changed if necessary.

Terminal Type

The ability to specify a Terminal Type when connecting to a UNIX server was introduced in version 5.01.

Translate CR / Send CR as LF

The Translate CR and Send CR as LF options handle minor variations in the protocol that have been found to exist between vendor implementations.

Force ACKs

The option to Force ACKs (Forced Communications Acknowledgments) may help improve the performance of WindX when in Telnet mode. It periodically adds a few bytes of data to the packets sent by WindX in an attempt to force the Telnet daemon (telnetd) on the server to communicate faster if it is using the Nagle algorithm (which produces delays in transmission). Most telnetd servers are configured to use this algorithm automatically.

By enabling this feature, WindX sends a few bytes that force an immediate response from the server, which triggers any pending data on the server to be sent immediately. Not all Operating System Telnet Daemons support this feature. Whether this option will have a positive or negative impact on performance can only be determined through testing.

Encrypt w/SSL

The option to Encrypt with SSL allows WindX to communicate with Telnet daemons which have SSL support, such as those using an SSL wrapper on the server or SSH encrypted Telnet shells.

Note: Stand-Alone WindX must be activated for SSL before this feature can be used. The WindX Plug-In does not require any special activation for itself, but it does require that ProvideX on the server be activated for SSL.

Exit on Quit / Ignore Turbo Mode Errors

This option causes WindX to auto-terminate once the connection with ProvideX is severed. Local reporting of Turbo mode errors can be suppressed as well.


13

WindX Script Processing

Built-in Sign-on Script FacilitySimple script language includes:R:xxxxx Wait to receive xxxxx from hostS:xxxxx Send xxxxx to hostW:nnnn Wait nnnn millisecondsT:nnnn Set receive timeout to nnnn msM:xxxxx Set message line to xxxxx

There is a built-in script processor within WindX. This script facility can be used to generate a host sign-on sequence.

The script text consists of a series of lines which start with a single character code followed by a colon. A typical sign-on script for UNIX might be:

R:login wait to receive 'login'

S:Stitch send the user ID 'Stitch' and CR

R:Password wait to receive 'Password'

S:Lilo send the password 'Lilo'

R:$ wait to receive command prompt

S:/pvx/pvx MYMENU send the command to start application

The T: command can be used to change the default timeout value (5 seconds) used for a R: (receive) function. W: causes the script to wait the number of milliseconds specified. M: is used to display progress messages on the message bar.

If the first directive of a WindX script is M:, then all terminal output is suppressed allowing for a 'hidden' signon. Terminal output resumes automatically at the end of script.


14

WindX Logon Programwindx.sgn

Enabled through configuration screen.Called by WindX to build/edit the script.

Calling sequence:call "windx.sgn",Script$

Script$ contains sign-on script with each line separated by a SEP character.

Able to modify script as required.

While the script processor is satisfactory in a wide variety of situations, the windx.sgnprogram can be used to alter the script sequence dynamically.

If the option Use WINDX.SGN is enabled on the configuration screen, then WindX issues a CALL to the program named windx.sgn just prior to processing the signon script. This program can alter the script as desired.

For example, assume we have a NOMADS screen (call it Signon in Mylib) that requests the Userid and Password of the user and returns these values in the first and second arguments. Then, we can use the windx.sgn program to alter the Userid and Password fields in a script:

0010 enter s$

0020 process "Signon", "Mylib.en",u$,p$

0030 u=pos("$user$"=s$)

0040 if u<>0 s$=s$(1,u-1)+u$+s$(u+6)

0050 p=pos("$pswd$"=s$)

0060 if p<>0 s$=s$(1,p-1)+p$+s$(p+6)

9000 exit

This example assumes that the value $user$ and $pswd$ exist as placeholders in the script and will be replaced with the true Userid and Password.


15

WindX Remote File Access

Host can access WindX station files.Opening with a prefix of "[WDX]" causes I/O to be routed to the WindX station.READ, WRITE, REMOVE, and CLOSEdirectives, and all functions, are supported.DIR= and TIM= options are not supported.

Host can access local disk drives.

The host application can use the WindX connection to gain access to any of the files on the client PC. By prefixing the pathname on any OPEN directive with "[WDX]", the file is opened on the Client PC and all file I/O requests are forwarded for processing by WindX.

Example:

open lock (1) "[wdx]a:\Payroll.dat"

read record (1,end=end_data) r$

…

end_data: close (1)

In the above example, the remote file access facility is being used to allow the host application to read a file from a diskette on the client workstation.

At present, the DIR=, TIM=, PURGE, REFILE, LOCK, and file creation directives are not supported by WindX. Applications attempting to use these features should create programs to run remotely. (Refer to the following pages.)


16

WindX Remote Command Processing

Initiating remote tasksWindX supports remote INVOKE directivesPrefix the string with "[WDX]"

Executing code on the WindX PCSupport of remote EXECUTE directivesUsed to set parameters, directories, etc..

Both INVOKE and EXECUTE support the ability to be processed on the WindX PC. If the string parameter passed to either of these directives starts with the sequence "[WDX]", then the rest of the command is passed to WindX to be executed locally.

Example:

invoke "[wdx]notepad.exe c:\autoexec.bat"

execute "set_param 'cd' "

The most common uses for issuing remote EXECUTE directives include:

• Changing local directory

• Changing system parameters

• Changing the Prefix

• File creation

Be aware that when using the EXECUTE directive remotely, it is possible that the local PC could be running a ProvideX with a different set of syntax tables, resulting in the directives not being correct.


17

WindX Remote Procedure Call

CALL can run a sub-program on WindX PC.Program name must be prefixed with "[WDX]".

Program needs to exist on the PC.All arguments (20 max) are passed to/from PC.

Files and Global variable are not accessible.

By far, the most powerful feature of WindX is its ability to execute ProvideX sub-programs remotely. Since WindX itself is a ProvideX program, it is capable of calling and passing parameters to a local sub-program.

Like the OPEN directive, the file name passed to a CALL directive can be prefixed with [WDX]. This indicates that the specified sub-program is to be run on the local PC, not the host system. The sub-program must exist on, or be accessible from, the client PC.

Any arguments specified in the CALL are sent to the WindX PC and any changes are passed back as per normal CALL processing. There is a limit of twenty (20) arguments that can be specified in a remote CALL.

Remember that the called program is actually running on the client workstation, not on the host system that initiated the CALL. Only the variables that have been passed specifically on the CALL argument list are accessible. Global variables and files are not accessible to called programs.


18

WindX Utility Program*windx.utl

Included with WindX.Provides a variety of functions.Prefixed with [WDX] in CALL; e.g.,CALL "[WDX]*windx.utl;xxxxx"

Includes spawn function that initiates tasks on both the host and client.

The WindX utility program *windx.utl provides a variety of functions that simplify the development of applications that make use of WindX. The following functions are supplied by this module:

call "[WDX]*windx.utl;get_addr", x$

Returns the IP address of the WindX PC.

call "[WDX]*windx.utl;get_arg",x, x$

Returns the command line argument specified by 'x' in x$.

call "[WDX]*windx.utl;get_lpg", x$

Returns the LPG system value for the WindX session.

call "[WDX]*windx.utl;get_lwd", x$

Returns the local current disk directory for the WindX session.

call "[WDX]*windx.utl;get_windx", x$

Returns the absolute pathname of the WindX program.

Continued…


19

WindX Utility Program (Continued)

call "[WDX]*windx.utl;get_newport", x

Returns the port number of an unused TCP/IP port on the WindX station.

call "[WDX]*windx.utl;get_tcb", x

Returns the value of the TCB function specified by x in x; i.e., x = TCB (x).

call "[WDX]*windx.utl;get_val",x$,y$

Evaluates and returns the value of the string expression x$ in y$;i.e., y$ = EVS(x$).

call "[WDX]*windx.utl;get_num",x$,y

Evaluates and returns the value of the numeric expression x$ in y;i.e., y = EVN(x$).

call "[WDX]*windx.utl;spawn", x$,i$,f$

Spawns a new session of ProvideX on the host and an associated WindX session on the client PC. By default, if the main session terminates, then the spawned session terminates. The parameters are:

x$ specifies the command line parameters to be used on the host

i$ specifies the pathname of INI file to be used on the client PC

f$ specifies the value of FID(0) for the session

call "[WDX]*windx.utl;spawn_nohup", x$,i$,f$

Same as ";spawn" but detaches the session from the main user task so that if the main task terminates, then the spawned task continues executing.


20

Direct TCP/IP Connection

Avoids Telnet protocol.Minimizes transmission overhead.

Initiated by one of the following:"*windx.utl;spawn" utilityClient/Server facility (*nthost/*ntslave).Web page based invocation for WindX.

Only method supported by JavX.

In addition to Serial and Telnet, there is a third method for connecting WindX to the host – direct TCP/IP.

This option uses the same physical means of communicating between host and client as Telnet (TCP/IP), but does not use the Telnet protocol to send data. Instead, the data is sent as raw data packets which results in reduced packet size and less protocol overhead.

Direct TCP/IP is the communication method used by the *windx.utl program when spawning another session. Also, it allows ProvideX to offer a thin-client based client/server technology by using JavX or WindX and the host server program *nthost .

*nthost is a ProvideX program that allows JavX or WindX clients to connect to a host system (Windows or UNIX) directly via TCP/IP.


21

Client/Server

How Client/Server WorksHost/Server side - *nthost

Initiates sessions.Responsible for monitoring incoming requests and spawning host sessions to service clients.

Client side - *ntslaveRequests sessions.Connects to server and then runs JavX or WindX.

The WindX Client/Server environment consists of two distinct elements: the host/server process and the client/workstation process.

On the host computer, the program *nthost is run to monitor incoming requests from client PCs and to initiate new processes to service these requests.

On the client computer system the program *ntslave begins the initial connection to the host by requesting a new session to be started. If the sessions can be started, then *nthost sends back the TCP/IP port number of the new process. *ntslave uses this port # to connect to this process and passes control to JavX or WindX to handle all of the terminal and GUI interactions.

In order for the initial connection between *nthost and *ntslave to be established, *ntslave must know the port number that *nthost is monitoring. By default, this is port number 10000 but it can be changed in the command line used to start both programs. As *nthost initiates new processes, it assigns new port numbers in increments starting with the port number one higher than the *nthost port assignment. By default, up to a maximum of 1000 sequential port numbers can be assigned.


22

NT Server SetupCommand line to run server *nthost:pvxwin32.exe *nthost [-arg port# maxport# -k]

Optional arguments indicate:Port number to monitor (used by clients).Maximum port number to assign to sessions. (Defaults are 10000 and 10999).Use of TCP/IP KEEPALIVE's on host side of connection.

Shortcuts can be placed in Startup menu.Launches when someone signs on.

Run *nthost as an NT service using srvany.exe.Part of the NT resource kit from Microsoft.

To run *nthost on a Windows PC, set up a shortcut with the following command line:

c:\pvx\pvxwin32.exe *nthost

(assuming c:\pvx is where PVX is installed)

There are three optional arguments that can be supplied: the port number that *nthost is to monitor (and the clients to connect to), the maximum port number to use for connections, and the ability to request using the TCP/IP KEEPALIVE functionality. These can be specified in the command line as program arguments.

Example:

c:\pvx\pvxwin32.exe *nthost -arg 10000 11999 -k

These arguments direct *nthost to monitor socket 10000 and assign spawned sessions to port numbers 10001 through 11999. If no arguments are specified, then *nthost monitors port 10000 and assigns port numbers 10001 through 10999. Each session employs the TCP/IP KEEPALIVE functionality to periodically send commands to a connection to ensure that it is still active.

To run *nthost, simply launch this shortcut or place it in the PC's windows 'Startup' folder to have it run each time the machine is restarted.

If you want to run *nthost as an NT service, then you can use the program srvany.exe that comes with the NT Resource kit from Microsoft. Once srvany.exe is installed, use instsrv.exe to define your service to NT. (See the Microsoft NT Resource kit for additional details on this process).


23

UNIX Server SetupCommand line to run server *nthost:pvx1:234:respawn:/pvx/pvx \*nthost -arg port# uid umask

Command line placed in system 'inittab'.Arguments:

Port number to monitor.UserID and Umask for spawned sessions.

Should be installed by a qualified UNIX professional.

Setting up *nthost on UNIX is a little more complicated and involves changing the system process 'inittab'.

This should only be done by someone who is knowledgeable in UNIX.

To run *nthost as a UNIX service, add a line similar to the following to the system 'inittab' file (usually in the directory /etc/):

pvx1:234:respawn:/pvx/pvx \*nthost -arg port uid umask

Where:

pvx1:234:respawn 'inittab' parameters that cause UNIX to spawn *nthost at all normal execution levels and keep it running.

/pvx/pvx \*nthost Location of the ProvideX executable and *nthost program name.

port# Port number that *NTHOST is going to monitor.

uid UNIX user ID used by the spawned process.

umask umask setting for all spawned tasks used when creating files.

Continued…


24

UNIX Server Setup (Continued)

There are three optional parameters that may be specified at the end of the command line. They are the maximum port number to assign to the spawned sessions, -V which indicates that debugging information is to be sent to the system console, and –K which activates the TCP/IP KEEPALIVE functionality.

The \ in front of *nthost keeps UNIX from thinking that the * in *nthost needs to be resolved as a wildcard character.

More Information Regarding User ID

When the *nthost launches new sessions, it does so via an 'su' command. This ensures that applications do not run as root (which maintains system security). Since the host program will be spawned from the 'inittab', it will be running with full 'root' privileges. This means that the host is capable of running any application, and can utilize 'su' to launch an application under another user ID.

Special care must be taken when using 'su'. The user ID chosen must be valid and the password must not have expired. If applications refuse to launch, then it is likely that the password for the user ID has expired, or there is an administrative lock on the account. The user account should not launch anything automatically via its profile since the new session picks up the characteristics of the user id being used.

When running under an OS such as IBM AIX, characteristics such as umask in the user's account setup may need to be modified as they will override the command line arguments.

Another potential problem is the number of processes a single user may run. Since all applications are spawned as this user, the kernel may need to be re-tuned to increase the number of processes per user.


25

WindX Client SetupCommand line to run client *ntslave:pvxwin32.exe *ntslave -arg server prog port

Arguments:Name/IP address of the server.Name of the program to run – if empty, it launches to console mode.Port number on the host for *nthost.

Client is not system specific.Windows and UNIX are supported interchangeably.

Assuming c:\pvx is where PVX is installed, the *ntslave client command line would appear as follows:

c:\pvx\pvxwin32.exe *ntslave -arg server prog port#

Where:

server is either the IP address of the host system where *nthost is running or the host name of the server.

prog is the name of program to run. If no program name is specified, then a session will be started that just runs ProvideX and leaves it at console mode for development purposes.

port is the TCP/IP Socket Number that the *nthost is monitoring.

The *ntslave program will connect to any server running *nthost, whether it is Windows or UNIX. This makes it possible to have many shortcuts connecting to different servers, all running at the same time.


26

WindX ClientWeb Browser Initiated

Browser Initiated WindX ConnectionProvideX program *url launches the client-side connection.*url is based on *ntslave.

Can share the TCP/IP link with the browser.Requires setup in the Registry.

To allow WindX to be initiated directly from a browser, you need to add a few simple entries into the Client PC's Registry. These Registry entries result in the automatic launching of a *ntslave style connection in response to an URL of:

windx:\\server\port#\prog args

Where:

server IP address/name of the server running the host program. (*nthost)

port# Port address being monitored by the above.

prog args Name of the program to run and any associated arguments replacing all spaces with ~.

Example:

windx://myhost/10000/*winstar~-arg~order~c:/pvx/pizza/pizza.en

Continued…


27

WindX Client – Web Browser Initiated (Continued)

The following Registry entries are required:

HKEY_CLASSES_ROOT\windx

<default> = "URL:windx"

EditFlags = hex: 02,00,00,00,00

URL Protocol = ""

HKEY_CLASSES_ROOT\windx\shell

<default> = ""

HKEY_CLASSES_ROOT\windx\shell\open

<default> = <none>

HKEY_CLASSES_ROOT\windx\shell\open\command

<default> = "c:\\pvx\\pvxwin32.exe -MN *url -arg %1"

The pathname here needs to be adjusted to point to the pvxwin32.exeon the client machine. Normally, this is done by an installation procedure.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\URL\Prefixes

windx. = "windx://"

There really is a dot ( '.' ) following 'windx' in the above registry entry.


28

WindX Application Considerations

It is important to know where functions execute:

File references may be resolved locally.

Drive letters refer to Host drive unless prefixed by "[WDX]".

Most character-based or graphical applications can run without modification on a server when running under WindX in either Telnet or Client/Server mode. However, there are a few things to consider.

File Requirements on the Local PC

• Many commands are tokenized and sent to the local PC for processing. Some of these, such as the 'PICTURE'( ) mnemonic and MULTI_MEDIAcommands, may include file name references. Since these commands will be executed locally, all files referenced by them must exist (or be accessible by) the local WindX PC.

• DLL's and VBXs must be loaded on the client PC.

• Open requests to ODBC, DDE, *WINPRT*, or *WINDEV* files should be routed to the WindX PC by prefixing the pathname with "[WDX]".

• Fonts used in 'FONT'( ) commands must exist on the client PC.

• If using the Windows print drivers for Graphical printing, then a UNIX spooler queue could be used, if it is set up as a Shared Printer and connected to a window print server via software, such as VisionFS or SAMBA.


29

Advantages of Using WindX

Flexible Application Design.Ability to employ both Host and Client systems.

High Speed Communications.Less data transmitted.

Improved Data Integrity.Only terminal I/O is transmitted.

Remote Processing

The Remote Processing capability of WindX enables you to take full advantage of the potentials of both the Host and Client operating systems.

Faster Screen I/O

Simple screen transmissions and updates are often faster with WindX, since it can process all ProvideX mnemonics locally and eliminate screen redisplays. The reduced transmission requirements provides for faster communications, whether across 28.8 modems, LAN/WAN connections, the Internet, or VPN's (Virtual Private Networks).

Data Reliability

By eliminating the movement of data to the PC during processing, the risk of corruption can be lowered significantly. You get the data security and system integrity of UNIX with the look and feel of Windows.


30

The JavX Applet

Embedding an Applet in a Web PageHTML required to embed JavX and connect to the ProvideX host.

Code provided in the presentation notes.

Host is not system specific.Windows and UNIX supported interchangeably.

JavX is written in Java 2 and will run on a web browser in the form of an applet. Applets are embedded in a web page with the HTML <OBJECT> tag (MS Internet Explorer), and the <EMBED> tag (Netscape Communicator).

Attaching a JavX Applet To A Web Page

<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"width="200" height="50" align="baseline"codebase="http://java.sun.com/products/plugin/1.3/jinstall-13-win32.cab#Version=1,3,0,0"><PARAM NAME="code" VALUE="NetworkClientApplet.class"><PARAM NAME="type" VALUE="application/x-java-applet;version=1.3">

<COMMENT><EMBED type="application/x-java-applet;version=1.3" width="200"

height="50" align="baseline" code="NetworkClientApplet.class" pluginspage="http://java.sun.com/products/plugin/1.3/plugin-install.html">

<NOEMBED></COMMENT>

No JDK 1.3 support for JavX</NOEMBED></EMBED>

</OBJECT>

Continued…


31

The JavX Applet (Continued)

This loads JavX into Internet Explorer or Netscape Navigator. If the browser does not have the appropriate JVM version (JavX requires 1.2.x or 1.3.x), it will download and install the plug-in, then continue loading JavX. (This is a one time only download).

The source for the plug-in is located under codebase for IE and pluginspage for Navigator. The previous example has links to Sun's plug-in page:

http://java.sun.com/products/plugin/1.3/jinstall-13- win32.cab#Version=1,3,0,0

The plug-in, however, can be anywhere on the Network.

Examples:(Internet Explorer)codebase=http://www.some-domian.com/jre1_2_2-001-win.exe

(Netscape Navigator)pluginspage=http://www.some-domian.com/jre1_2_2-001-win.exe

It is important that the client machine have the appropriate plug-in. Plug-ins for Windows and Solaris can be found at http://java.sun.com/products/plug-in/.The Linux plug-in can be found at http://www.blackdown.com. The web page Nav.html located in the JavX directory contains Javascript that will detect the operating system and browser and then write the appropriate HTML to the browser. A browser, without the Java plug-in, will be directed to the appropriate source for that platform.

"args" Parameter

JavX requires the following variables to be passed from the command line in one string, or on an HTML page in a parameter called "args":

server= Either the IP address of the host system where *nthost isrunning or the host name of the server.

port= TCP/IP Socket Number that the *nthost is monitoring.

The following variables are optional:

program= Name of program to run. If no program name is specified, then a session will be started that just runs ProvideX and leaves it at console mode for development purposes.

onapplet= Boolean value indicating whether JavX should put windows in the browser or on top of the browser.( if true, " ? 'window' " puts a window on the browser).

LookAndFeel= Parameter that sets the look and feel.

set_mf= Multi_line factor (default value is 50).

fontsize= Font size for the text plane (default value is 12).

basewinwidth= Base window's width (default value is 80).

basewinheight= Base window's height (default value is 25).

Continued…


32

The JavX Applet (Continued)

With an applet, these arguments are passed using <PARAM NAME= VALUE=> in IE, and variable="some string" in Netscape. The required HTML for passing the server, program, and port number to JavX is provided below:

For Internet Explorer:

<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="200" height="50" align="baseline"codebase="http://java.sun.com/products/plugin/1.3/jinstall-13-win32.cab#Version=1,3,0,0">

<PARAM NAME="code" VALUE="NetworkClientApplet.class"><PARAM NAME="type" VALUE="application/x-java-applet;version=1.3"><PARAM NAME="args" VALUE=" server=www.somedomain.com;

program=myprog.pvx;port=10000; ">

For Netscape Navigator:

<COMMENT><EMBED type="application/x-java-applet;version=1.3" width="200"

height="50" align="baseline" code="NetworkClientApplet.class"args=" server=www.somedomain.com; program=myprog.pvx; port=10000;"pluginspage="http://java.sun.com/products/plugin/1.3/plugin-install.html">

<NOEMBED></COMMENT>

No JDK 1.3 support for JavX</NOEMBED></EMBED>

</OBJECT>

Client.html located in the JavX directory contains the complete HTML and Javascriptthat JavX requires. Additional information regarding applets and HTML can be found on Sun's site at http://www.java.sun.com/products/plugin/1.3/docs/tags.html. The program argument is optional as JavX will open in terminal mode without this variable.


33

JavX cannot access local files.

All programs must execute entirely on server.

Paths to images must be relative to Applet's web page source or URLs.

JavX Applications Considerations

Most character-based or Windows-based applications can run without modification on a server when running under JavX Client/Server mode. However, there are a few things to consider.

Restrictions

The "[WDX]" directive does not work in JavX. Images, with the exception of ProvideX's system BMPs such as !stop, must come from the server. Programs must run completely on the server with nothing being done locally. These restrictions are unavoidable due to the following:

• JavX is not a ProvideX program and can be deployed on machines where there is no local copy of ProvideX.

• JavX runs on Windows, Solaris, Linux, and Mac's. This makes it very difficult to predict what resources will be available locally (such as Notepad.exe).

• Unsigned applets are restricted to a secure area within the browser and can not access local files.

• At present JavX does not support all PVX controls; e.g., Grid and charting controls.


34

Advantages of Using JavX

Runs on World Wide WebPlatform IndependentLook and Feel FlexibilityNo Need for Local Copy of ProvideXHigh Speed Communications

Less data transmitted

Improved Data IntegrityOnly terminal I/O is transmitted

Ability to Run on World Wide Web Page

Any web page can contain the JavX applet, and JavX can control the web browser's contents.

Platform Independence

JavX runs on any PC with a Java2 Virtual Machine (Linux, Windows, Solaris, or Mac OS X).

Flexible Look and Feel

Java's Metal is the default "look and feel" for JavX . Using the 'FONT'mnemonic, the look and feel of a GUI application can be changed very easily. If JavX is running on a Windows machine, then

print 'font'("com.sun.java.swing.plaf.motif.MotifLookAndFeel")

changes the look and feel so that all future GUI objects would use the Motif look and feel.

The "~" would specify the default systemlook and feel; e.g.,

print 'font'("~")

instructs JavX to use Windows look and feel on a Windows PC, Motif on a Linux machine, and Mac on a Mac.

Continued…


35

Advantages of Using JavX (Continued)

Local Copy of ProvideX Not Required

The WindX connection logic has been changed to check if the user limit has been exceeded on the server. If the limit has been exceeded, then JavX or WindX displays a message box on the local workstation which was attempting to connect. JavX is distributed freely, so that you may ship as many copies to end users as you wish. However, they must connect to a ProvideX server where the number of simultaneous connections is limited to your server's ProvideX user limit.

Launch other Java Classes

JavX can load and launch other Java classes; i.e., call "[wdx][java] someclass" will dynamically load and run a Java class called someclass.class provided that class file is located within the client machine's class path.

Faster Screen I/O

Simple screen transmissions and updates are often faster, since JavX can process all ProvideX mnemonics locally to eliminate screen redisplays. The reduced transmission requirements provides for faster communications, whether across 28.8 modems, LAN/WAN connections, the Internet, or VPN's (Virtual Private Networks).

Data Reliability

By eliminating the movement of data to the PC during processing, the risk of corruption can be lowered significantly. You get the data security and system integrity of Unix with the look and feel of Windows.


36

End of PresentationThank You

Notes:

using thin-client technologies - · pdf filethin-client technologies direxions, august 2002 4...

Documents