Understanding Web processing: Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (minor formatting)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
Here's how web processing works: At your local machine you run an application called a
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
“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).
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)
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.
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
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,
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
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
of a document specifies “text/HTML”, the browser knows to interpret the HTML tags as
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.
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,
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
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
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
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.
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
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.
http server translates that URL into a document and sends it. A special format of
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.
document called a form allows two-way interaction between a browser and server.
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.  
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.
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.
Line 45: Line 21:
==The Janus Web Server solution==
==The Janus Web Server solution==


Allowing Web access to applications faces the following limitation, however: web
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.
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
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 <var class="product">Model&nbsp;204</var>
Server is a full-featured Hypertext Transfer Protocol server running inside a <var class="product">Model 204</var>
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.
region under either the MVS or VM operating system. The Janus Web Server uses
Instead of Perl or C coding, forms can be written and replied to using <var class="product">Model&nbsp;204</var>'s native language, SOUL (formerly called User Language).
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 <var class="product">Model 204</var>'s
native language, User Language.


The Janus Web Server has all the features of other web servers but is tightly integrated
The Janus Web Server has all the features of other web servers but is tightly integrated with the high-performance <var class="product">Model&nbsp;204</var> database and makes full use of the security and
with the high-performance <var class="product">Model 204</var> 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.
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 <var class="product">Model 204</var>, the Janus Web Server is
For sites that already have applications written in <var class="product">Model&nbsp;204</var>, the Janus Web Server is the most direct and easily implemented Web solution.
the most direct and easily implemented Web solution.


==Serving web pages from within Model 204==
==Serving web pages from within Model 204==


<var class="product">Janus Web Server</var> can be configured to present web pages to clients in essentially two
<var class="product">Janus Web Server</var> can be configured to present web pages to clients in essentially two ways:
ways:


<ul>
<ul>
<li>As a “static” page of text containing text and HTML commands.
<li>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
In Janus Web Server, this type of web page is simply stored as a procedure in a <var class="product">Model&nbsp;204</var> file. It can be created and edited using the <var class="product">Model&nbsp;204</var> editor, it can be
<var class="product">Model 204</var> file. It can be created and edited using the <var class="product">Model 204</var> editor, it can be
[[Uploading files to a Janus Web Server|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]].
[[Uploading files to a Janus Web Server|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|“Loading with the SIRPIPE and SIRPUT utilities”]].
Serving static pages is simple and can serve many purposes for presenting
Serving static pages is simple and can serve many purposes for presenting
information that does not change often.</li>
information that does not change often. </li>


<li>As a page that is “dynamically” built within <var class="product">User Language</var>, a more powerful yet still
<li>As a page that is "dynamically" built within <var class="product">SOUL</var>, a more powerful yet still quite simple approach.
quite simple approach.
One way to do this is to route the output of <var class="product">SOUL</var> <var>Print</var> statements to the client's browser. By “printing” HTML commands among the other data being "printed," a <var class="product">SOUL</var> procedure can be quickly converted into an attractive web page.  
One way to do this is to route the output of <var class="product">User Language</var> <var>Print</var> statements to the
client's browser. By “printing” HTML commands among the other data being
“printed,a <var class="product">User Language</var> procedure can be quickly converted into an attractive web page.  


Easier and more economical than a series of <var>Print</var> statements, you
Easier and more economical than a series of <var>Print</var> statements, you
can also enclose blocks of HTML data within an <var>Html</var> (or <var>Text</var>) statement (see [[Text_and_Html_statements|"Text and Html statements"]]) and an
can also enclose blocks of HTML data within an <var>Html</var> (or <var>Text</var>) statement (see [[Text and Html statements]]) and an
<var>End Html</var> (or <var>End Text</var>) statement. <var>Html</var> (or <var>Text</var>) statement blocks may
<var>End Html</var> (or <var>End Text</var>) statement. <var>Html</var> (or <var>Text</var>) statement blocks may contain any <var class="product">Model&nbsp;204</var> expression, including %variables and $functions.
contain any <var class="product">Model 204</var> expression, including %variables and $functions.


Even more powerful capabilities can be created by using the <var class="product">Janus Web Server</var>
Even more powerful capabilities can be created by using the <var class="product">Janus Web Server</var> functions described in [[Janus Web Server $functions]]. These enable the processing of the following, among other things:
functions described in [[Janus Web Server $functions|“Janus Web Server $functions”]]. These
enable the processing of the following, among other things:


<table>
<table class="thJustBold">
<tr>
<tr>
<th>HTML forms</th>
<th>HTML forms</th>
Line 118: Line 68:
</table>
</table>


When a client enters a URL requesting a particular web resource from <var class="product">Janus Web Server</var>, 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 <var class="product">User Language</var> 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|“Defining Web rules”]].
When a client enters a URL requesting a particular web resource from <var class="product">Janus Web Server</var>, 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 <var class="product">SOUL</var> 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 <code>/documents/report17.html</code> 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 <var>[[UPCASE (JANUS DEFINE parameter)|UPCASE]]</var> parameter, the default, was specified on the <var>JANUS DEFINE</var> command for the port).
For instance, a request for <code>/documents/report17.html</code> 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 <var>[[UPCASE (JANUS DEFINE parameter)|UPCASE]]</var> parameter, the default, was specified on the <var>JANUS DEFINE</var> command for the port).


Alternatively, a rule can be defined so that a URL causes the execution of a <var class="product">Model 204</var> subsystem or procedure. An example of this type of application is presented in [[Janus Web Server application example#Sample application: command processor|"Sample application: command processor"]].
Alternatively, a rule can be defined so that a URL causes the execution of a <var class="product">Model&nbsp;204</var> subsystem or procedure. An example of this type of application is presented in [[Janus Web Server application example#Sample application: command processor|Sample application: command processor]]. </li>
</ul>
</ul>



Latest revision as of 17:15, 7 August 2018

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