CGI の標準出力をリダイレクトさせることに成功したおかげで
Alaska は理想的なサーバー・モデルへと仕上がった。
pipe による標準出力のリダイレクトをこれほどページを割いて解説してきたのは
次の大きな利点を生んだからである。
-
IBM Apache HTTPサーバーから Alaska への乗り換えが可能
- 既に開発済みのCGIで運用しているユーザーは何の修正も行わずに Alaska へ乗り換えることができる。
Alaska では最高のパフォーマンスを得ることができる。
今稼動中の Web適用業務のレスポンスを向上させたいのであれば Alaska に変更するだけで済むのだ。
-
標準出力による多言語のサポートが可能
- 当社では既に 標準出力による C 言語、RPG および Java による CGI の動作に成功している。
WAS ( WebShere Application Server )が無くても Alaska の上で何と Java が稼動する。
Java の出力もリダイレクトされることは驚きであった。
JSP&Servlet や PHP, Perl も動作できるかも知れない。
【次の課題】
-
JSP & Servlet コンテナの実現
- JSP&Servlet は アプリケーション・コンテナである、Tomcat や WAS の上でしか動作できない
ものと思われているが実は環境設定さえしてやれば Shell 環境 だけで十分、
動作するのではないかと予想している。
しかも Shell 環境も現在では、すべて別のバッチ・ジョブに投入されて初めて動作する
ようになっているが、これも標準出力のリダイレクトを同一プロセスの中で実現できなかったことが
原因であるのではないかと予想している。
もし同一プロセスでの Shell 環境の動作に成功したら Java や JSP&Servlet の
パフォーマンスは抜群のものに改善されるだろう。
現在の Shell の起動方法では初期起動があまりにも遅いからである。
-
QSHELL 環境のエミュレート
- QSHELL コマンドを実行するための、いわゆる PASE 環境は、現在(OS Ver7.1 現在)
のところ QSHELL/QZSHSH というプログラムがバッチ投入されて動作していることは
QSH などの PASE環境を使った人ならば、ご存知であろう。
しかし対話式で操作しているのは裏ではバッチ・ジョブが起動されているのはいかにもスマートではない。
しかもこのために Java を始めとするパフォーマンスの低下を招いている。
これでは System i で Java を Webアプリケーションの開発言語として使用するには実用的ではない。
QSHELL 環境を同一プロセスのスタックとして動作させる必要があると考えられる。