Understanding Web processing

Here's how web processing works: At your local machine you run an application called a "browser." To begin a request for some information, you provide the browser with a pointer in the form of a Universal Resource Locator (URL) identifying which information you want to begin accessing over the Internet (or intranet, which is a secured implementation of internet technologies where access is limited to users in a particular organization. For simplicity, we'll simply refer to the Internet in this document).

The Internet locates the resource, and a HyperText Transfer Protocol Server (http) replies to the request. The information arrives at your machine with a content type which your browser associates with a presentation method or with a helper application which handles presentation services for that type. Your browser will have various pre-defined content types which it knows how to present and some for which it will have associated helper applications.

Some documents arrive with embedded suggestions to your browser for how the document should be presented. These suggestions are in the form of markup language, the most common of which is Hypertext Markup Language, or HTML. If the content type of a document specifies "text/HTML," the browser knows to interpret the HTML tags as formatting suggestions. If a document arrives with content type "text/plain," it knows to ignore HTML tags and other embedded flags, and to present the document to the user exactly as it appears, character by character. Each browser has a different way of interpreting tags, most of which can be changed by individual users, making it very difficult for the exact format of a page to be specified by the author.

While limitations on author-specified formatting are a limitation of web-based authoring, the web offers many more benefits, primarily in embedded hot-spots, or jump points, which allow a browser user to point and click on graphics or pieces of text to invoke another URL, invoking another server conversation, perhaps moving to another document which could exist anywhere on the Web: it's this aspect which makes the web what it is, a collection of connected resources linked together by inter-document references.

Most of the web operates in a single direction: a browser requests information, and an http server translates that URL into a document and sends it. A special format of document called a form allows two-way interaction between a browser and server. Forms have a variety of graphical and text-based ways to let users enter information into a page and to send that custom information to the server as form parameters. Because of forms, Web browsers are sometimes referred to as a "universal client" in client-server architecture. Using a browser as the front-end, a client-server system can be built in which each user uses the browser they prefer (most of which are free), and application development is concentrated on the server system. No client software distribution is required, and access to the server can be tightly controlled.

While the client must conform to the limitations of the current HTML standard, the standard is quite flexible, and it provides all of the features needed to write sophisticated applications. The HTML standards for current, past, and proposed future implementations can be viewed online through the web at the location that maintains them, http://www.w3.org.

The Janus Web Server solution

Allowing Web access to applications faces the following limitation, however: web servers commonly reside on Unix platforms and communicate with data via an interface known as the Common Gateway Interface (CGI). CGI is not really a specification but a set of suggestions for how communication between a server and data source should occur. Typically, URLs that initiate calls to CGI interface programs require PERL or C programming. Also, communication from the Web Server to the data source which contains open-coded passwords, and the transfer of other private information, should — but cannot easily — be secured. Due to the kludgy and scantily specified CGI, and because of the security problems, most serious database sites have been prevented from making data available on the web.

Sirius Software wrote the Janus Web Server to solve these problems. The Janus Web Server is a full-featured Hypertext Transfer Protocol server running inside a Model 204 region under either the MVS or VM operating system. The Janus Web Server uses command-level Janus subcommands to define rules on how the server will operate, and an application-level API to process forms and handle complex database server issues. Instead of Perl or C coding, forms can be written and replied to using Model 204's native language, SOUL (formerly called User Language).

The Janus Web Server has all the features of other web servers but is tightly integrated with the high-performance Model 204 database and makes full use of the security and speed of the Janus TCP/IP Base. While the Janus Web Server can be used to serve up any content types, from plain text to complex graphics, it's the application level API that makes it the right choice for Web-based database applications that require speed, security and integration.

For sites that already have applications written in Model 204, the Janus Web Server is the most direct and easily implemented Web solution.

Serving web pages from within Model 204

Janus Web Server can be configured to present web pages to clients in essentially two ways:

• As a "static" page of text containing text and HTML commands. In Janus Web Server, this type of web page is simply stored as a procedure in a Model 204 file. It can be created and edited using the Model 204 editor, it can be uploaded to the web server, or it can be loaded from the mainframe to the web server (as described in Loading with the SIRPIPE and SIRPUT utilities. Serving static pages is simple and can serve many purposes for presenting information that does not change often.
• As a page that is "dynamically" built within SOUL, a more powerful yet still quite simple approach. One way to do this is to route the output of SOUL Print statements to the client's browser. By “printing” HTML commands among the other data being "printed," a SOUL procedure can be quickly converted into an attractive web page. Easier and more economical than a series of Print statements, you can also enclose blocks of HTML data within an Html (or Text) statement (see Text and Html statements) and an End Html (or End Text) statement. Html (or Text) statement blocks may contain any Model 204 expression, including %variables and $functions. Even more powerful capabilities can be created by using the Janus Web Server functions described in Janus Web Server $functions. These enable the processing of the following, among other things:

  HTML forms	These provide a mechanism for creating powerful graphical interfaces for data entry and data presentation, which can significantly extend the options available over standard 3270 interfaces.
  URL parameters	Also known as “isindex data,” this provides an alternative mechanism from form fields to encapsulate data entered on a form or data generated by a web application but to be passed around to different URLs.
  headers	These identify various characteristics about the client such as their browser, their IP address, etc., which can be used to control the type of information presented to the user.
  cookies	These enable persistent storing of information on the client's workstation for later retrieval, and they can be used to help create customized displays or remember information entered in a previous session.

  When a client enters a URL requesting a particular web resource from Janus Web Server, the way the server is configured will determine whether the request should cause the display of a static web page or the execution of a SOUL procedure. One or more “web rules” can be defined in the web server to control how to interpret specific URLs or URL patterns. These rules are described in Defining Web rules.

  For instance, a request for /documents/report17.html might very well prompt the server to respond by sending to the client the contents of a procedure named "/documents/report17.html" (or "/DOCUMENTS/REPORT17.HTML" if the UPCASE parameter, the default, was specified on the JANUS DEFINE command for the port).

  Alternatively, a rule can be defined so that a URL causes the execution of a Model 204 subsystem or procedure. An example of this type of application is presented in Sample application: command processor.

References and links

• List of Janus Web Server $functions
• Janus Web Server
• Janus commands
• Getting started with Janus Web Server