Date: Tue, 6 Feb 1996 10:58:26 EST
>Reply-To: CHAD GILLES <[log in to unmask]>
>Sender: HP-3000 Systems Discussion <[log in to unmask]>
>From: CHAD GILLES <[log in to unmask]>
>Subject: V/plus application on the web...Is it possible?
>
>This question may sound like it is coming from a web rookie because...well...
I
>am.
>
>My manager has asked me to find out if it is possible for one of our
>applications, running on a HP3000 and utilizing V/plus, can be accessed from
the
>web and without any changes to our application...Wouldn't this be very
>difficult to achieve if it is even possible, not to mention very slow.
>
>Anyway, that was my 'rookie' question. TIA for any answers
Read & enjoy. First cut paper I've been working on over a year (not yet
complete,) please anyone provide feedback.
Eric.
------
WORLD WIDE WEB AS A STATEFUL GRAPHICAL USER INTERFACE
This paper describes a possible method to migrate traditional session
programming techniques (such as a VPLUS application) and integrate those
techniques into Web "stateless" Hypertext Transfer Protocol, resulting in a
Web client acting as a Graphical User Interface "terminal". VPLUS is an
excellent analogy for World Wide Web transactions because both systems block
transactions (i.e., send a form and receive back a delimited data field
stream.) World Wide Web client interfaces have met almost irreconcilable
differences when traditional session based client/server methods are applied
to Internet style stateless client/server communication.
Traditional "login" sessions (such as Telnet) are used to establish a
connection between user and machine of long duration (hours, days, weeks)
allowing a user to perform many types of transactions. Sessions "remember"
sequences of events, such as an application program that remembers database
file positions and last accessed memory values. More important to this
discussion, sessions usually do "one time" large overhead allocations at
startup time, such as opening files and initialize memory. Sessions are
typically put to sleep by the Operating System between user transactions so
that they are managed efficiently in terms of CPU usage but not in terms of
memory usage. Sessions typically hold large amounts of memory resources for
long periods of time.
In contrast, the World Wide Web uses hypertext Transfer Protocol which is a
stateless model. This means the user connects to a server, makes a request,
and the server responds and closes the connection in a manner of seconds.
Stateless is a term used to describe an immediate transaction of short
duration - no history about previous transactions are stored on the server.
Since each process dies after a stateless transaction, both memory and CPU
resources are free for the next user transaction.
IRRECONCILABLE DIFFERENCES OF SESSIONS AND HTTP?
The most obvious difference between hypertext Transfer Protocol and a session
is that HTTP connections (and typically the process) terminate after each user
transaction. Extending session design perspectives into HTTP, this means any
large "one time" session overhead operations are incurred for each stateless
Web transaction. Why?
Think of HTTP transactions as the case of the user who logs on to a system,
types a SHOWJOB command and logs out. If the user wants to do a LISTF, he
logs on the system, types LISTF and logs out. If all your users behaved this
way, it would not be long before all your CPU cycles are used in LOGON, LOADER
and INITIALIZATION routines and very little CPU allocated to the task at hand.
To make this scenario worst, most logon and loader operations are single
threaded.
When programming for HTTP transactions, it is possible to achieve a high
degree of volume and efficiency when transactions have low initialization
costs, such as doing static file transfers. As "startup" costs become larger,
such as generating HTML documents that access a DBMS, these methods will offer
varying degrees of volume and efficiency. It is the later case that prevents
widespread adaptation of World Wide clients as a direct replacement for
terminal based systems.
ALIVE AND DETACHED COMMUNICATION PROCESSES
The MPE programming environment can be used to reconcile differences between
Web HTTP and a session by:
1) Keeping the host child process alive between transactions.
Keeping a process alive under MPE is easy. A listener (parent) process
generally can manage of list of child processes and check them periodically.
Keeping the child processes alive prevents excessive startup costs when
accessing a DBMS and memory initialization.
2) Provide HTTP conformance by opening and closing the communication socket
between client and host.
hypertext Transfer Protocol demands socket closure after each transaction.
This requirement can be managed effectively when 1) a unique user identifier
string is generated 2) User identifier is stored both on the client and host
3) Client sends the User identifier with each transaction.
NETSCAPE "COOKIES" AND MOSAIC "HIDDEN FIELDS"
With the introduction of the NETSCAPE Web client "cookie", or a persistent
client state mechanism, it is possible to create a unique session identifier
and store this identifier both the client and server. The client returns this
User identifier "cookie" with each Web client transaction, so that a server on
the host can reattach the Web client back to its rightful stateful host
process (like a traditional session.)
Mosaic clients implemented an earlier method called "hidden fields' to store
data on forms without the user aware of its presence. Mosaic forms are the
only method that can store extraneous server information, while NETSCAPE
cookies store server information about any HTML page.
A word of warning: This Spec assumes that the application has a strong
correlation to a session - that is say, a small population of controlled
users. The keyword here is "controlled". Do not attempt this method when
thousands of uncontrolled transactions might occur. I will explain later.
MPE INTER PROCESS COMMUNICATION FEATURES
Let us review common MPE IPC ideas - suspend, activate and message files. A
typical use of suspend and activate is to start a "master" process that
creates a slave process. Communication is done by a pair of message files -
one for input and one for output. For example, if a "master" process wishes
to execute an MPE command via the slave process, the master process writes the
command string to the slave process input file and collects results by reading
the slave process output file. This method makes the master process resilient
from any errors (in case the command aborts the calling slave process, the
"master" process remains alive and in control.)
The slave command process is simple - read a command from the input process
message file, execute the command, loop and read another command. If there
are no more commands, the slave process will suspend attempting to read an
empty message file. The "master" process can send a new command to its slave
process via message file and collect the results anytime afterward.
A simple master/slave command diagram:
1) "master" (create/activate/send message) ---> slave . . .
2) . . . slave (reads message file / executes command)
3) . . . slave (suspends waiting for next message)
MPE NETIPC METHOD
The idea of a suspend/activate mechanism using message files is extended to
sockets programming. The NetIPC IPCGIVE/IPCGET combo behave like message file
suspend / activate except that a newly acquired "socket" from a connecting
client is passed to the child process instead of an MPE command, as in our
example above.
A simple socket handoff master/slave diagram:
---------------------------------------------
1) "listener" (IPCGIVE socket) --> child . . .
2) . . . child (IPCGET socket - process request)
3) Close socket
Normally, stateless hypertext protocol would follow step 3) "close socket and
terminate process". What happens if the process does not terminate when the
socket is closed?
HyperText protocol demands socket closure. So, if the slave process is not
terminated along with the act of closing the socket, the resulting process
becomes a "process that lost communication with its client" or a "detached"
process. When a process has lost its ability to communicate - no messages or
alarms can flow between host and client after the socket is closed.
If this was a UNIX system, the child process could truly be an orphan. Under
MPE, process trees are hierarchical and dependant. This means when any MPE
process is killed, all descendants of that process are killed preventing a
child process to exist without a parent process. The MPE listener program
remains in control of all child processes.
THE INTRUSIVE NETIPC LISTENER
Normally, the only function a listener program should perform is to receive
incoming socket connections and "hand-off" the connection to a slave process.
Typical listener programs never interrogate the data stream of the incoming
socket.
This Listener program reads the incoming socket data stream and parses the
"session ID" returned by the NETSCAPE Web client. NETSCAPE stores "session
ID" information as directed by the server in the form of a "cookie" content
type. Another method to store session ID could be a hidden HTML form field
type. A listener program could be constructed to handle both cases and
different types of Web clients.
Once the session ID is extracted from the HTTP content type stream, the
Listener program can "IPCGIVE" away the connecting socket by placing the name
of the session ID into the NetIPC socket registry (a parameter of IPCGIVE).
The receiving child process is blocked on an IPCGET call - which immediately
resumes execution when a matching session ID is placed into the socket
register. The new Web client socket connection is thus "reattached" to the
original stateful "detached communication process" on the host, which does the
next client request or application step, similar to a terminal transaction.
In normal operation, data read from a socket is destroyed. If this is allowed
to happen when the Listener program reads the incoming socket data stream to
determine session ID, this action breaks the client/server model. The child
process would no longer have input to read from the client because it was
destroyed by the listener.
NetIPC has a solution to the intrusive listener problem. There is a socket
option called "preview", which allows the listener program to perform a
non-destructive read of the input data stream. Thus, the Listener program can
effectively manage incoming connections by previewing the socket data stream
without breaking the client/server model.
PROCESS PROPAGATION
The NetIPC Web listener mechanism could propagate many "detached communication
processes" around the system (there is no definition of "logout" in HTTP), so
a timeout would be needed to kill them off, say after 15 minutes or so of
inactivity. Timer info could be sent back on each Web form (within a message
window area) warning the user of the time before the "session" times out host.
Users can prevent timeouts by initiating a transaction within the allotted
time.
The new NETSCAPE client content type "cookie" support a timer, so the Web
client could actually prevent needless timeout connections to the host that
busy the listener. A more elegant solution would be to include a "logout"
button on the Web form to formally kill off a "session". Otherwise, a
timeout must terminate all "detached communication process" processes.
NETIPC LISTENER SCHEMATIC
|<---> run progA;xl=
Web client <--> Web "terminal" listener|<---> run progB;xl=
w/aifchangelogon, |<---> run progA;xl=
IPCGIVE |<---> run ....
The Web client stores the "session ID" as a NETSCAPE "cookie", which is sent
with every request. Earlier attempts used HTML "hidden fields", which can
serve the same purpose.
The Web terminal Listener would need to create and track active processes and
"IPCGIVE" each connection away, using an IPC table name (socket registry)
entry that is unique to the process (IP+PIN+PROGNAME+TIME?) combination. If a
request comes in for a timed out session, the Web terminal listener would need
to send a message back to the user instructing them to "restart" the session
again from the "homepage", which would do the "run prog" command again.
The "run prog;xl=" is the child process and would block around a pair of
IPCLOSE/IPCGET calls. This would be placed within the "vreadfields" intrinsic
call. I'm assuming that many blocked IPCGET's will only obtain the socket
designed for it, its unique name. All others should remain blocked.
NETIPC REATTACHMENT: WHO AM I?
When the Web client initiates a subsequent transaction, it will use a
completely different socket descriptor and TCP/IP connection. The problem of
client "reattachment" to an "detached communication process" on the host is
solved by the use of the NetIPC "socket registry" and by the use of a unique
"session ID" stored both on the client and server.
This socket "reattachment" scheme behaves very similar to a traditional
terminal transaction, where the analogy is defined as:
1) READ TERMINAL -> attach client to server - obtain request,
2) WRITE TERMINAL -> respond with HTML document,
3) INTERRUPT -> close connection.
The NetIPC loop:
IPCGET... <Listener accepts socket - IPCGIVE back to child process>
IPCSEND... <Child does request - sends HTML to Web client>
IPCCLOSE.. <close socket connection - HTTP demands it>
IPCGET... <"detached process" - waits for client request (again)>
POSIX METHODS
POSIX uses fork() to create child processes and sockets are integrated
directly into $STDLIST and $STDIN of the calling programs. POSIX interfaces
will rely on message files to achieve suspension and activation. Also, the
function of the "NetIPC listener" must be emulated as a lower layer of the
HTTPD daemon listener.
THE POSIX INTERFACE
The trick of constructing POSIX interfaces on MPE is that you must realize
that POSIX process trees are handled in an MPE manner (i.e., no orphan process
allowed.) Therefore, the user must initiate a kludge two step "login" process
that 1) creates a listener process from the root HTTPD daemon and 2) a slave
process from the root HTTPD daemon. In this way, the NetIPC master/slave
combination can exist under POSIX but the master and slave will exist at the
same level on the process tree (i.e., one level down from the root.)
The other trick of using POSIX is that the master process will disappear while
the child process will suspend on a pair of message files. This is because
communication between master and slave under POSIX can only be possible
through a message file layer. POSIX has no concept of "passing" a socket to
another process. The master process must generate a "link2" HTML page and
store User identifiers on the client to be picked up by the slave process (the
process that will remain alive.)
The last trick of using POSIX is that the "link2" slave process must close
$STDIN and $STDLIST. This will break the socket connection between client and
server but the slave process will remain alive by opening and suspending on
the input and output message files built by the initial master "login"
program. All subsequent connections will create a master process that acts as
a gateway between the POSIX fork() socket connection and the alive process
dangling from the root HTTPD daemon. The purpose of this gateway is to
function as a communication pipe between the new forked process (initiated by
the client connection) and the old and alive slave process (doing the DBMS
calls and staying alive.)
POSIX SCHEMATIC
Client link1 <---> creates master "login" process - generates HTML link2
Client link2 <---> creates slave process that suspends on message file.
Client linkn... <--> creates a master process that behaves as a gateway
between the new HTTPD forked() process and the old (kept alive) process.
Socket communication on the client side - message file communication on the
DBMS side.
VPLUS AND WWW OVERVIEW
People using this spec could actually use terminal skill programming to write
a Web application or retrofit previous terminal VPLS code (or other
applications) into a Web application (TRANSACT code would work). That is the
driving force behind this idea: "re-use of traditional application skill sets"
found in any HP 3000 shop. Icing on the cake is revealed when the model
discards proprietary client models up front - no large purchases of client
software is needed. Web clients are Internet free software and can run just
about anywhere there is a LAN or WAN! Connection to the Internet is not
required.
VPLUS AND THE WEB
HTML field types could be mapped to VPLUS forms via the assigned internal
VPLUS field names and located on the HOST. For instance, a VPLUS field name
of "STATES" could be mapped to an HTML file containing a pre-formatted HTML
pick-list of states on the host and integrated into the HTML output Web form
on the fly - using a simple fopen - fread - fclose sequence.
All "construction" of the "extra" Web GUI parts of the Web form could be
stored in external files, driven by conventions between VPLUS field names and
HFS file names as the links. This makes GUI's easy to configure by
manipulation of files - rather than writing perl scripts or 'c' code. In
this approach, graphical buttons for an application Web page might be stored
in a directory named "buttons", for example and sub-directory forks from that
point could be used to further customize the form.
In contrast, NewFace expects tables stored on the CLIENT to perform this
function. This WebFace approach uses all HOST based files to construct the
final product. For example, an active "pick-list" script could be written to
read existing tables in KSAM files to export on the Web form while under
construction on the host.
HTML OUTPUT - PAINT A WEB PAGE
What is the "terminal" output to look like? Well, I speculate that every
field type on a VPLS screen could be mapped to HTML, then throw in a IMAGE MAP
for buttons, (like Mike Belshe did on the jazz phone database CGI). Going out
to HTML, you need to grab the data "vgetbuffer" and read the fieldtypes
"Vgetfieldinfo" and slap HTML field form types around the data, creating HTML.
On return from the Web client, a substitute "vreadfields" routine would
actually be the CGI script string parser that will tuck things into a buffer
for any "VGETxxx" calls. This can be done by parsing the HTML item name/item
value pair values returned from the Web client "post" action. A mapping of
HTML fields to VPLS field types could be done and a call to "VPUTFIELD" as
appropriate to update the VPLS form buffer. So, the VPLUS intrinsics that
need a rewrite are:
Vopenterm <dummy, fake out>
Vcloseterm <dummy, fake out>
Vreadfields <IPCGET - parse HTML tagged fields>
Vshowform <create HTML tagged fields and IPCSEND>
----------------------------------------------------------------
Eric J. Schubert Senior Data Base Analyst
Office of Information Technologies Univ of Notre Dame, IN USA
(219) 631-7306 http://www.nd.edu/~eschuber
|
