Application Resources
HOME | DOWNLOAD | SITEMAP | CONTACT US
home
Company Profile
serviceweoffer
our clients
our partners
contact us
Knowledge base

 

company profile
SGI - Web-server and more.
2 SGI (Stratus Gateway Interface) is designed to provide TCP/IP connectivity to Stratus VOS platform.
It can be used as a web-server conforming to the HTTP/1.0 specifications or as a gateway to a wide range of VOS applications, such as online e-commerce, order processing, database access or any other client/server applications.
If used as a web-server it supports all well-known web browsers and can work with them to transfer text/html or gif/jpeg graphic files. SGI also supports gateway script (CGI).
Apart from using web-browsers as clients for SGI, any other application can be used to access VOS platform. The protocol used to communicate with SGI is a simplified HTTP/1.0 protocol. See specs below.
2Here is a summary list of the features that are supported by SGI version 1.0:
1
SGI is a multitasking server, which means all requests are processed in multitasking mode. Number of tasks is customizable.
1 SGI responds to GET/POST methods (regardless if the requester is a browser or any other custom application)
1 CGI+ support.
 
1
standard CGI support (executing and passing user input to any VOSexecutables specified in POST request)
1
application queue support (passing user input to the server-queue of a VOS application and returning either application reply or results file created by the application)
1 SGI correctly returns a simple/full response depending on request and response type.
1

Response can be a message returned by a VOS application, results file produced by a VOS application,html, text, gif or jpeg file in publicly accessible directory, or output of the CGI script executed by SGI.

1
SGI server can handle multiple types of requests at the same time. For example, it can work as a web-server and at the same time process requests from a client application to exchange data with web-server and at the same time process requests from a client application to exchange data with VOS application on Stratus. SGI dynamically suits its reply format to the type of the requester (browser/non-browser).
1 All connect/access information can be logged.
2Below are the basic protocol specs for SGI depending on the requester type.
1. Requester is a Web-Browser.
1 Request format.
 
1 Requests are created by the web-browser. SGI accepts GET and POST methods.
1 Reply format
 
1
If GET /file/path request has been received - SGI returns the file requested and closes the connection. The file path is relative to the public root directory defined in the sgi_parms.table
1
If POST /file/path/script request has been received - SGI executes the script specified and returns the output of the script to the browser.
1
If POST /queue/application_name request has been received - SGI passes the HTML form input to the server queue of the application_name defined in the sgi_parms.table and either returns the application replay message or the results file created by the application.
2. Requester is NOT a Web-Browser.
1 Request format.
  1GET request
  GET /file/path/name<new_line><new_line>
   
  1POST request
  POST /file/path/script<new_line>
[Content-Length: <length><new_line>]
<new_line>
[<input buffer passed to SGI>]
 

OR

POST /queue/application_name<new_line>
[Content-Length: <length><new_line>]
<new_line>
[<input buffer passed to SGI>]

Input bsuffer is optional. If provided, length of the buffer should be provided as a Content-
Length parameter as well.
1 Reply format
 
   
1
If GET /file/path request has been received - SGI returns the file requested in thefile reply format described below. The file path is relative to the public root directory defined in the sgi_parms.table
1
If POST /file/path/script request has been received - SGI executes the script specified and returns the output of the script in the file reply format below.
1
.If POST /queue/application_name request has been received - SGI passes the input buffer to the server the queue of the application_name defined in the sgi_parms.table and either returns the application reply message in message reply format or the results file created by the application in the file reply format.
 
1 File reply format
 
  /dbqg_command=start
<line 1>
<line 2>
<line 3> ... <EOF>
/dbqg_command=end
 
1 Message reply format
   
  Content-Length: <length><new_line>
<new_line>
<reply message buffer>>
   
1 Error message reply
   
  /dbqg_command=error_msg: <error message><new_line>
....................................................................................................................................................
.
 
Examples:
1. A custom application sends a request to run a macro my_macro.cm on Stratus and get the output of the macro. The request message should look like this:
  POST /my_macro.cm<new_line><new_line>
  If you want, for example, to pass a parameter "-my_parm" to the macro, the
message would be:
  POST /my_macro.cm<new_line>
Content-Length: 8<new_line>
<new_line>
-my_parm
 

The reply will look like:

  dbqg_command=start
Output of the macro here.
.
.
/dbqg_command=end
   
2. A custom application sends a message "1234567890abcd" to a VOS application my_app and is expecting a reply message.
 
 
/ =identifier SGI
=app_name my_app
=queue  %module#m1_d02>my_app>server_queue
=timeout  4000
  Request message layout:
  POST /queue/my_app<new_line>
Content-Length: 14<new_line>
<new_line>
1234567890abcd
  Reply layout example:
  Content-Length: 10<new_line>
<new_line>
1234567890
  In order for SGI to process this requests there should be a corresponding record in the sgi_parms.table configuration file
 
/ =identifier SGI
=app_name my_app
=queue  %module#m1_d02>my_app>server_queue
=timeout  4000
  Since in this example <b>retr_file</b> is not set - SGI returns the application reply message. If retr_file is set to 1 - SGI will expect the application to create a results file and will return it in file reply format.
   
  Examples:
   
 
/ =identifier SGI
=app_name my_other_app
=retr_file 1
=results_dir %module#m1_d02>my_other_app>tmp
=results_prefix tmp_out
=delete_res 0
=queue %module#m1_d02>my_other_app>server_queue
=timeout 4000
  In this case SGI will expect the application to create a results file named "tmp_out_X"
   
  Where X is a unique number set by SGI. The file should be created in the "results_dir" directory. The name of the file will be passed to the application in the first 35 characters of the input buffer.
Copyright (c) 2007 Application Resources, Inc.