Note: Descriptions are shown in the official language in which they were submitted.
CA 02251442 1998-10-22
- 1 -
WEB BASED GUI SERVER AND METHOD FOR A
TELECOMMUNICATIONS NODE
Field of the Invention
s The present invention relates to a web based graphical user
interface (GUI) server and method for a telecommunications node and is
particularly concerned with applications to craft user interfaces.
Backaround to the Invention
In the telecommunications industry (switching, transport, and
1o network management), the key requirements for the craft user interface
(CUI) are
a) fast, b) reliable, c) easy to use and d) connectivity. The user
interface should be simple and easy to use. A simple interface helps to
reduce procedural errors, outages, and is easy to learn. The information
15 (the content and presentation) viewed at different nodes should be
identical. Connectivity is the ability to access any node in a network via
remote login procedures. For example, access to transport nodes from
surveillance centers or from one node to another node via remote login.
In 1970s and 1980s, the craft user interface (CUI) has been based
20 on command line languages (CLL) with the principal input/output (I/O) user
device being either an actual or a simulated VT100 terminal. Connectivity
using the command line languages (CLL), for interconnecting nodes has
been provided by the widely used Telnet protocol.
In late 1980 and in early1990s, the prevalent connectivity (CLL)
2s interfaces have slowly been replaced by graphical user interfaces (GUIs)
with the principal I/0 device being a personal computer (PC) having a
mouse, which is used as a selecting device. GUIs have been found to
perform much better with regard to ease of use. They have been found to
offer a superior UI and to be an economical solution for the
3o telecommunications industry. However, there has been a problem with
CA 02251442 1998-10-22
-2-
regard to connectivity between the nodes, since there has been no
replacement for the Telnet (VT100 based) protocol.
Fig. 1 illustrates a known GUI implementation based on a client-
server arrangement. A GUI client 10 typically resides on a PC 12 and is
s implemented with Visual C + + or Visual Basic. The GUI client 10
represents the GUI engine. A server 14 represents the execution engine.
Communication between the client 10 and the server 14 is typically based
on proprietary protocols 16. User Interface (UI) commands are interpreted
by the GUI client 10 and communicated via a proprietary protocol 16 to a
to server 14 on a telecommunications node 20. The server 14 communicates
with applications 19 via an API 21 to execute the UI commands and then
returns results to the GUI client 10. The results are then rendered on the
screen of the PC 12.
The known client-server systems have used a client having
is either a proprietary communications protocol or a Telecommunications
Language-1 (TL-1 ) protocol. For the GUI client with a proprietary protocol,
the GUI implementation improves the simplicity and usability of the UI.
However, a C + + implementation (or Visual Basic or Java
implementations) results in a large program (fat GUI) that requires time and
zo resources to design and implement. Also, since the presentation of the
GUI is platform dependent, it is difficult and expensive to achieve the
same presentation on different platforms having different operating
systems. The connectivity requirement of being able to remotely access
any node in a network could only be solved by using proprietary protocols,
2s and implementing such protocols on all nodes in a network. As can be
appreciated, design and implementation of a this type of protocol is both
expensive and time consuming. Often this alternative is not practical.
A fat GUI client with the TL-1 protocol GUI implementation is similar
to the above except that the connectivity is provided by the TL-1 standard
3o protocol. This protocol had been originally designed (in 1960) for
CA 02251442 1998-10-22
-3-
machine-to-machine communication and is based on command line
languages (CLL). Consequently, it is not well suited to communicating
with a GUI and may become a bottleneck in the near future.
In addition to the above problems, both the client and server
s software must be of the same version. Since the GUI client is developed
for a PC and is distributed on diskettes (or CDs), the version of the
diskette should match the version of the main software (i.e. the server) on
a telecommunications node. To maintain compatibility between the client
and server in the field is logistically very difficult and expensive. In
so practice this could lead to version control problems and the possibility of
mistakes or dysfunctional UI, if the versions do not match.
Another problem with this client/server approach is each
telecommunications product would require its own design and
implementation of the GUI client. Consequently, the design and
is implementation would be expensive. Also, the user must have several GUI
clients on their PC, that is one for each different product. In practice it
would be difficult from both operation and maintenance points of view.
The user would have to switch between different GUI clients, and would
have to maintain several different GUI clients. GUI version control issues
ao could easily lead to a situation becoming unmanageable. Clearly these
problems would not be acceptable for telecommunications providers.
Another problem with GUI clients that are platform dependent is
cost. Each platform, e.g. PC Windows 95, Windows NT (trademarks of
Microsoft Corporation), Unix (trademark of AT&T) would require a new
2s implementation of the GUI. The overall design would be the same, but
parts of the GUI client would have to be redesigned and implemented.
Since, in reality, telecommunications providers are using different
platforms, the telecommunications equipment vendors would have to
support all platforms.
CA 02251442 1998-10-22
-4-
An additional problem with platform dependent GUI clients are
differences in presentation. Each platform has its own way to present
graphical elements. As a result, if a craft person has a PC which has a
different platform than that used in the surveillance center (usually Unix
s engine), the presentation of the same information will be slightly
different.
Such differences could lead to errors in operation that would not be
acceptable by telecommunications providers.
A further problem is GUI clients do not support remote logins. The
ability to connect (to login) to another node, thereby performing a remote
login, is a basic requirement of the craft user interface (CUI). With the
GUI client-server paradigm, this requirement is very difficult to satisfy.
Theoretically it is possible to develop proprietary protocols (or use the old
TL-1 protocol), but in practice such solutions would be very expensive and
very difficult to maintain. This would mean that GUI clients would have to
be able to interpret commands of all products, leading to very large GUI
clients with nearly impossible version control requirements (i.e. they would
have to be in sync with many products).
Summary of Invention
2o An object of the present invention is to provide and improved web
based GUI server and method for a telecommunications node.
According to an aspect of the present invention, there is provided a
web based GUI architecture for telecommunications node that is an
economical and uniform solution and that enables a common GUI on all
z5 nodes in a network, uniform access to all nodes in a network via common
standard protocols, economical UI development for telecommunications
vendors, and an economical solution for telecommunications providers by
way of saving of craft training.
In accordance with another aspect of the present invention there is
3o provided apparatus for a web based graphical user interface (GUI) server
CA 02251442 1998-10-22
-5-
for a telecommunications node comprising a module for creating a
predetermined number of interface tasks at initialization and a session
manager for establishing a session and associating one of the
predetermined number of interface tasks with the session.
s In accordance with a further aspect of the present invention there is
provided a method of providing a web based graphical user interface (GUI)
to a telecommunications node comprising the steps of creating a
predetermined number of interface tasks at initialization, establishing a
session and associating one of the predetermined number of interface
Zo tasks with the session.
Brief Description of the Drawings
The present invention will be further understood from the following
detailed description, with reference to the drawings in which:
is Fig. 1 illustrates a known GUI implementation based on a client-
server arrangement;
Fig. 2 illustrates in a block diagram a web based GUI server for a
telecommunications node in accordance with an embodiment of the
present invention;
zo Fig. 3 illustrates in a functional block diagram a session task
structure used in the architecture of Fig. 2 in accordance with an
embodiment of the present invention; and
Fig. 4 illustrates, in a block representation, a GUI screen for the
embodiment of Fig. 3.
Detailed Description
Referring to Fig. 2, there is illustrated, in a block diagram, a web
based GUI server for a telecommunications node in accordance with an
embodiment of the present invention. The architecture includes within
3o telecommunications nodes 22 and 24, proxies 26 and 28, respectively,
CA 02251442 1998-10-22
-6-
servers 30 and 32, respectively and CGI tasks 34 and 36, respectively. A
personal computer (PC) 38 includes a client (browser) 40 and
communicates with the telecommunications node 22.
A web based GUI works on the client-server paradigm, but both the
s client and the server are based on (industry) standard programs, platform
independent, communicating via (industry) standard protocols TCP/IP and
HTTP.
In web terminology, the client is called a browser. The browser is a
platform independent GUI engine that accepts and interprets standard data
io formatting descriptions (HTML1, standard script language constructs
(JavaScript) and standard Java written small programs (applets). The
present embodiment takes advantage of the widespread availability of
browsers to provide the client portion of its web based GUI architecture.
The server is called an HTTP daemon or just an HTTP server. The
15 HTTP server is platform independent due to wide acceptance of the HTTP
protocol. The HTTP server receives requests from browsers one at a time.
The HTTP server is supported by common gateway interface (CGI) tasks
(programsl. Requests accepted by the server are passed to CGI tasks for
execution/processing. The CGI tasks then return the results to the
2o browsers. The browser provides the GUI framework, while the actual CUI
resides on the telecommunications node as a set of HTML files (with
JavaScript constructs), XML files, CGI tasks and Java applets.
The standard protocols used between the browsers and servers are
capable of communicating GUI to remote nodes and can perform a similar
25 function to GUI as the Telnet protocol provides for command line
languages (CLL). However, in order to achieve the remote login capability
needed for the craft user interface in accordance with the present
embodiment, additional elements are required. A server proxy 26, 28 and
an address service (not shown in Fig. 2) are added to provide remote login
3o capability. The proxy server 26, 28 acts as a relay enabling a browser 40
CA 02251442 1998-10-22
,- 7 _
to connect to a remote node 24 via access to a local node 22. This is
called a remote login. The browser 40 connects to a local node proxy 26,
and the proxy 26 with the help of the address service locates the remote
HTTP server 32 and relays the browser's requests to it.
s In operation, the browser 40 on a PC 38 sends a request to a locally
connected telecommunications node 22. The connection is either physical
(through RS232 port) or through a LAN (through Ethernet port). First, a
request is accepted by the proxy server 26. The request can be either
navigation (i.e., move to next menu level) or a command (e.g., list all
to alarms) or the very first request - the login request. The protocols used
between the browser 40 and the proxy 26 are HTTP over TCP/IP.
The proxy server 26 accepts the request and determines its
destination. If it is a local request, then the proxy 26 passes the requests
to the local server 30. The protocols used are the same, i.e., HTTP over
TCP/IP. If it is a request for a remote node 24, the proxy 26 determines
the remote node destination, converts the TCP/IP protocol into TP4
protocol and sends the request to the proxy 28 on the remote node 24.
The protocols are now HTTP over TP4. The physical connection can be
either LAN (Ethernet) if the nodes are connected on the same LAN
backbone or optical if the nodes are connected through SONET optical
data communications channels (DCC). Note, that for the access,
Department of Defence (DOD) protocol stack (TCP/IP) is being used and
for the internal routing through SONET DCC an ISO seven layer protocol
(TP4) is being used. Both protocols are connection-oriented protocols.
Referring to Fig. 3 there is illustrated, in a functional block diagram,
a session task structure used in the architecture of Fig. 2 in accordance
with an embodiment of the present invention. In addition to the proxy 26,
the web based GUI requires a way to define all requesitions that constitute
a session. For this purpose a session manager 42 and four CGI tasks 44,
46, 48, 50 are provided. The server 30 gets the request from browser 40
CA 02251442 1998-10-22
8 _
and determines which session is associated with the request. If the
request is not associated with any previous requests, it is a first request of
a session. The first request is a login request that causes a session to be
created. For the login request, the server 30 creates a session. There are
four CGI tasks 44, 46, 48 and 50 pre-created at the time of initialization
and waiting in the 'suspend' mode. This is done for the real-time and
memory requirements as it would be too slow if the server were creating
the CGI tasks at the time of login. The CGI task should be waiting and all
required memory should be pre-allocated once the system is initialized.
The server 30 selects the first waiting CGI task 44 and requests a special
numeric tag, a session handle from a session manager 42. This session
handle then serves as an association between all browser's requests
(transactions) and this particular CGI task 44, thereby forming a session
task. When creating a session, the session CGI task 44 checks all the
requirements for a secure connection (authentication, validity of a
password, etc). The session CGI task request queue is then initialized and
activated.,The task has a request queue with the maximum number of two
requests at a time. The depth of the request queue is important for the
robustness of the operations. Once, the session initialization is done, the
session CGI task 44 is ready for routine processing.
If the request is a command or navigation, the server 30 finds the
appropriate session CGI task 44 and passes the requests to it. The request
has been changed by a server 30 from an HTTP request into a CGI
request.
When the CGI task 44 gets the request, it first determines if the
request is a navigation or a command request. If it is navigation request,
i.e., the user wants to move to different menu on the screen. The CGI
task 44 retrieves a template for the new menu. The template is actually
an HTML file, the CGI task 44 sends the template back through the server
30 (or the proxy 28 if the request came from a remote browser) to the
CA 02251442 1998-10-22
_g_
originating browser 40. This completes the request and the user can now
issue another transaction.
If the request is a command, i.e., user wants to perform some
action such as listing all alarms, the CGI task 44 converts the CGI request
into appropriate application call, to telecom applications 54 and gets the
application reply data. The reply data are then converted into an HTML file
and send back through the server 30 (or the proxy 28 if the request came
from a remote browser) to the originating browser 40. This completes the
request and the user can now issue another transaction.
If the request is a command, i.e, user wants to perform some action
such as listing all alarms, the CGI task 44 converts the CGI request into
appropriate application call, to telecom applications 54 and gets the
application reply data. The reply data are then converted into an HTML
file and sent back through the server 30 (or the proxy 28 if the request
came from a remote browser) to the originating browser 40. This
completes the request and the user can now issue another transaction.
In order to provide a craft user interface based on a web GUI,
synchronization of current session states on a telecommunications node
and a browser must be provided. Current HTTP protocol and servers are
stateless, that is, the servers process one request at a time and they do
s not rely on previous requests. For the CUI session, however, the context
is an important aspect of operation. The browser 40 and the
telecommunications node 22 or 24 need to have a memory of what
session the current page/window is associated with and as well the state
of a particular session. The association of a session with the page is
Zo described herein below in regard to the session management. The context
sensitivity, i.e., how the state of a current session on the browser and the
Telecommunications node is synchronized is described here.
Context sensitivity is a feature of the present embodiment of the
invention. Context sensitivity means, that any time the user interacts with
CA 02251442 1998-10-22
- 10-
the telecommunications node 22, he/she can operate and get information
only on the current configuration of the node 22. For example, before the
node 22 is commissioned, only a certain subset of the CUI is available to
the user. Or, for example, if a card is removed from the node 22, the CUI
s immediately recognizes the change and does not allow any operation on
the missing card. The context sensitivity is programmed at two places.
First, the CGI task 44-50 interacts with the node's applications 54
and gets notifications about configuration changes. Second, the changes
are communicated to a JavaScript construct on the browser 40 and
Zo reflected in the variables of session page 56.
Note: When the session is created, the first HTML file contains
global variables and JavaScript routines. The variables are set to reflect
the configuration state of the telecommunications node 22 at the login
time. Any configuration (context) changes are immediately communicated
15 to the JavaScript routines via HTTP protocol and the global session
variables are changed appropriately. This way, the telecommunications
node software and the browser session page 56 are always in
synchronization.
In the telecommunications CUI, certain information rendered on the
2o screen is dynamic in nature, i.e. changing in the real time. There is a
need
to display the change immediately when the telecommunications node
changes the value of the information.
In the CUI, a typical example is a banner line, i.e., a line with
several fields that are changing in real-time. The fields are for example
as critical and/or major alarms, and number of protection switches.
Another example is protection screens. When protection information
is displayed in the output screen area, the information on the screen is
updated in real-time.
Web based GUI in accordance with the present embodiment
3o provides for both banner line and dynamic screens in the output screen
CA 02251442 1998-10-22
-.1 1 -
area. The dynamic (or real--time) updating is implemented at two places.
First, the CGI task 44-50 is notified about the change by
telecommunications node's applications 54. Then, these changes are
pushed to the browser's session page 56, processed by the JavaScript
s constructs and then modified in the appropriate screen area.
The change may be high-lighted for example by changing a color of
the changed field. The banner line is placed above the menu and output
area. There may be several banner lines, a local banner line, and a network
banner line.
Zo Because current HTTP protocol and servers are stateless, that is,
the servers process one request at a time, they do not remember previous
requests. For the CUI session, however, the context is an important
aspect of operation as described above. The browser 40 and the
telecommunications node 22 or 24 need to have a memory of what
is session the current page/window is associated with and as well the state
of a particular session.
This means that all request originated by a browser 40 should be
associated with a certain session and all replies received by a browser 40
should be displayed in the appropriate browser window 58. One browser
20 40 can run several (max. 4) sessions simultaneously, i.e., a one to one
association between the browser window and the session on the
telecommunications node.
In known web technology, with the stateless paradigm, the server
creates a CGI task to process a request and the CGI task then terminates
2s when its processing is completed. In the HTTP protocol, there is the
concept of a "cookie", to maintain an association between one request
and one reply. The cookie could be used for the session/window
association, but it is not a sufficient solution. The problems associated
with the use of a cookie are as follows: the creation and termination of
3o tasks in real-time systems consumes CPU and memory resources; the
CA 02251442 1998-10-22
paradigm allows a user to create a number of concurrent requests; each
one resulting in a creation of new CGI tasks, i.e. burst of requests can
cause a resource crisis in the real time systems; and some requests may
have longer processing time and if the user creates other requests, the
s previous requests should be aborted - i.e., there needs to be a certain
level
of serialization otherwise resources could be depleted very quickly.
In accordance with an embodiment of the present invention, four
CGI tasks 44-50 are created at the system startup and then suspended.
The four CGI tasks 44-50 will be in the suspended state. When the server
Zo 30 gets login requests, it first acquires a free (suspended) CGI task 44
(46, 48, or 50) and activates it. The CGI task is then associated with this
session. At anytime, the number of sessions is limited to four, i.e. the
number of CGI tasks that exist. This is done to manage the resources of
the system that are required for a session. A special numeric tag, the
is session handle, is used to establish an association between the window
and the session. This allows the server, to recognize that the requests
should go to the appropriate CGI task. The handle is never repeated, for a
new session, there is always a new instance of a handle.
To provide the serialization and aborting of requests, each CGI task
2o has a queue of only two requests, labeled 'new' and 'current'. The CGI
task can work on one request at a time. When the new request arrives,
the server 30 always places the new request into the queue called 'new'.
This allows the CGI task to discard excessive requests from the browser.
The CGI task takes the request from the queue named 'new', moves the
2s request into the queue named 'current', clears the 'new' queue and starts
processing the current request. When the processing is completed, the
CGI task checks the queue named 'new' before returning the results of the
current request. If the queue 'new' contains a request, the CGI task
discards the results, and starts processing this new request as described
CA 02251442 1998-10-22
-13-
above. This allows the CGl task to abort a command that has been
superceded
Session task structure and functions shown in Fig. 3 includes and a
HTTP server 30, a session manager 42, CGI tasks 44-50, a session page
s 56 and session security (not shown in Fig. 31. HTTP Server30 has been
modified from the standard HTTP server. Instead of creating new CGI
tasks, the server communicates with a session manager to find an
appropriate existing CGI task. The method of passing CGI requests has
been modified accordingly. The session manager 42 keeps track of the
to state of CGI tasks 44-50. The session manager 42 also generates the
session handles and assigns them to a session.
The CGI task represents a session on the telecommunications node.
The CGI tasks are created at the system startup and then suspended.
Each CGI task 44-50 is activated for the duration of a session, by a
is session manager 42. When the session is terminated, the CGI task is
once again suspended.
The session page 56 represents the session on the client 40 (the
browser). The session page 56 is an HTML file with JavaScript constructs
and is downloaded by the browser 40 during the login procedure. The
2o session page contains all global variables and routines for the session.
The session page processes the session handle and attaches the session
handle to each request originated by the associated session.
Session security has the following aspects: authentication,
automatic logout, and intrusion protection. Authentication is provided for
2s by requiring the user logging in to enter a USERID and a password.
Verification is done by the session manager when the session is being
created. The CGI task monitors session inactivity. If the session is not
active for a predetermined period of time, for example 30 minutes, the
CGI task suspends itself and informs the session manager. The session
3o handle is invalidated, i.e., any request coming from the browser with this
CA 02251442 1998-10-22
- 14-
session handle will be refused with a message stating that the session is
not active.
The session manager counts the number of invalid login attempts
and stores information about invalid login attempts in the log and provides
s the information in a welcome message for valid login. This is to inform
about possible intrusion attempts. After a predetermined number of
attempts, for example 3 invalid login attempts, the session manager does
not accept any further login attempt for a predetermined period of time,
for example 30 seconds. This acts as a defense against machine
1o generated login attempts.
Connectivity, that is, ability to remote login from one
telecommunications node to another telecommunications node is a basic
requirement of the craft user interface (CUI). The web based GUI of the
present embodiment consists of the following components that facilitate
is connectivity: proxy server and address service. The proxy server works as
a relay and as a protocol converter. Each node, in order to support the
web based GUI, has a proxy server. The proxy server operates on
requests. Requests conform to the HTTP protocol. The proxy determines
the destination of a request and relays the request to the proper node for
zo example from node 22 to node 24. If the request is destined to the local
node 22, then the request is passed to the HTTP server 30. The proxy
server 26 converts the protocols as described herein below.
The address service (not shown in Figs. 2 and 31 maintains the
address space, that is the addresses and names of the
2s telecommunications nodes that are using a OSI protocol address service.
Each node has a (Network) Service Access Point (NSAP). The NSAPs are
reused by the proxy server for addressing telecommunications nodes.
Connectivity between web based GUI and legacy CLL Uls (for
example VT100 based UI) are maintained by the present embodiment.
3o The connectivity, that is, the remote login to the nodes, which do not
CA 02251442 1998-10-22
-15-
support web based GUI, is .done through the Telnet protocol. Telnet
protocol works on the client/server principle. The Telnet client is
implemented as a task running with the session CGI task. The Telnet client
is invoked through the "remote login" command from the browser 40 and
s the CGI task processing the command, connects the Telnet client with the
browser; output from the Telnet client is then emulated in the browser
window. This allows the telnet session to be run from inside the web
based GUI .
The main protocol, HTTP protocol, is not converted. The lower
Zo protocol, TCP/IP and TP4 protocols are converted, depending on the
destination and origination of the request. The basic rule is: traffic on
SONET DCC channels is carried by TP4 and traffic on Ethernet
connections are carried by TCP/IP. The protocol conversion, the fact that
we are running HTTP protocol over the TP4 protocol, is a significant
15 feature of the present embodiment.
The web based GUI of the present embodiment makes use of the
browser 40, as the framework for the GUI implementation. The browser
40 gets HTML files 52 (and possible XML files) with Java Script constructs
and /or Java applets from the server 30, that is, from the
2o telecommunications node 22. This set of HTML files 52 (and XML files,
JavaScript and Java applets) reside on the telecommunications node 22.
These files define the craft UI, hence replacing the set results in a
different
craft UI, without changing anything else on the telecommunications node
22.
2s This feature of the embodiment of the present invention allows
customization of user interfaces by replacing the set of HTML files. User
interfaces can be implemented in other natural languages by replacing the
set of HTML files with new HTML files of the desired language.
Since the HTML files 52 reside on the telecommunications node 22
3o with the main software, there is no need to have a separate
CA 02251442 1998-10-22
-16-
implementation on a PC. Consequently, any browser from any platform
(Mac, PC, Unix) will get the same rendering of the GUI. Distribution of
software is not a problem, since the UI is distributed together with the
main software on the telecommunications node.
s Main building blocks for the web based GUI are buttons, forms,
tables, list, selections and hypertext links. The browser 40 interprets these
HTML/Java/JavaScript elements. Additional building blocks include maps,
style sheets, graphics and XML elements.
Using the browser 40 and its capabilities allows for a common look
to and feel of user interfaces across different telecommunications products,
from the top managing nodes to the bottom managed nodes.
Referring to Fig. 4 there is illustrated, in a block representation, a
GUI screen for the embodiment of Fig. 3. The screen includes a main
menu 60, and output area 62, a first submenu 64, a second submenu 66
is and a parameters area 68. The screen layout for the client 40 has been
designed to provide immediate user feedback. The users should see the
immediate context of their interaction with the telecommunications node
22. They should see on the session screen 58, what command has been
issued, what the current state of the command execution is, and what
20 options have been used with the current command. This design intent is
achieved by dividing the screen into several hierarchical areas: main menu
area, first submenu area, second submenu area, parameters area and
output area. Each area displays immediate identification of the command
executed in its first line.
25 The screen layout, positioning of all its elements and color coding is
the same for all commands.
The point and click user interface is optimized for response time.
For each command, the screen layout is designed to minimize the number
of clicks needed for a command. The definition of the screen layout is
3o done by means of HTML frames. When the session is created during a
CA 02251442 1998-10-22
-17-
login procedure, the first downloaded HTML file contains the frame
definition, i.e. the screen layout.
On-line help is an important feature of GUIs. The present
embodiment may include on-line help. The on-line help is based on the
s HTML (help) files containing detailed descriptions of commands. Since the
on-line help information can grow into large sized files (hundred of
kilobytes) some compression techniques are necessary. The design of the
decompression of the help files is based on the concept of the session
page. The first HTML file downloaded by the browser during the login
1o procedure contains decompression routines, i.e., all HTML help files will
be
decompressed on the client (browser) side.
The present embodiment of the invention has the advantage of
using a server (browsed that is economical. Using the browser as the GUI
engine brings advantages for the user. All browser capabilities can be
is applied to the UI, for example, the users can print a page, search pages of
output for certain strings, file the pages as a file into his/her directories,
and mail a page.
Acronyms
API Application Programming Interface
ao CGI Common Gateway Interface
CLL Command Line Language
DCC Data Communication Channel
DOD Department Of Defense
DWDM Dense
Wave Division
Multiplexing
2s GUI Graphical User Interface
HTML hypertext Markup Language
HTTP Hypertext Transmission Protocol
JavaS cript Script programming language supported
by browsers
Java Programming language
CA 02251442 1998-10-22
-18-
OSI Open System.lnterconnect protocols
SONET Synchronous Optical Networks
XML Extended Markup Language
TCPIIP Transmission Control Protocol/Internet protocol
s Telnet Application enabling remote logins
TP4 Transmission Protocol - layer 4
