System i 上、最速のレスポンス

Alaska は System i 日本語環境専用として独自に弊社が開発した HTTPサーバーです。

すべてのWeb環境のプラットフォームとなる HTTPサーバーだからこそ、

安全で高速で、軽く動作する必要があります。

System i にこそ、i5/OS の機能の高さを生かした

HTTPプロトコルの処理構造があっても良いのではないでしょうか?

Alaskaは IBM System i のCPU性能を最大限に引き出すように IBM が次世代のTCP/IPサーバー・モデルとして

推薦するアーキテクチャーをベースにして開発された HTTPサーバーです。

レガシーな Apache に比べて通常でも約2倍以上のレスポンスを誇り、大規模アクセスになればなるほど効果を

発揮します。Alaskaそのものがロード・バランサー(負荷分散)モデルであることから負荷集中がつねに最適化されて

分散され、最小限のリソースで最大限の効率を発揮することができます。

Alaska図解

日本語環境を安心サポート

RPGエンジン

ユーザーCGI 開発のために「RPGエンジン」と呼ばれるサービス・プログラムが提供されており、
RPG ソース(CGI) からは RPGエンジンの 42種類のプロシージャー を呼び出すことによって
HTML へのきめ細かな制御をやさしく行うことができます。
RPGエンジンはサービス・プログラム( *SRVPGM ) として提供されていますので製品の
リリース・アップや PTF 適用時にもユーザー・プログラムを一切、手修正したり再コンパイルする必要はありません。

仮想対話式環境

仮想対話式環境とは、DSPF での EXFMT 動作を Webでも実現する機能です。
TONAKAI によって移行された CGI は、DSPF の EXFMT と同じように
操作員からの入力を子プロセス上で待機し続けます。
コミット&ロールバック、標識・フィールド値の保存はもちろんEXFMT の動作を全く同じように再現します。

しかも、

「戻るボタン」問題

「戻るボタン戻るボタン」を押しても画面遷移は一致します。

「×ボタン」問題

「×ボタンXボタン」を押しても CGI は正しく終了します。

のように、これまで不可能と思われてきた Web上の問題も解決されています。

最新のC/Sモデルにリエンジニアリング

Alaska は Ver4.0 で IBM が次世代の C/Sモデルとして最もふさわしいとして推薦する
C/S モデルに リエンジニアリング(再作成)されて生まれ変わりました。
Alaska はブラウザからの要求信号のみを受け取り、ブラウザとの送受信はすべて子スレッドに分散され、
ロードパランスを HTTPサーバーとして実現しています。
速度もさらに 150%以上向上しただけでなく、大量の大規模システムでの効果を発揮します。

■ 理想的な C/S モデルとは ?

IBMが推薦する理想的な クライアント/サーバー・モデルとはどのようなものでしょうか?

従来型の C/Sモデルはサーバーがクライアントから要求を受け取ると、
実行用に待機しているいくつかの子スレッドに実行を指示していました。
クライアントからの要求データ・ストリームは HTTPサーバーが受け取ってから
そのデータを pipe と呼ばれるデータ待ち行列を通じて子スレッドに送っていたのです。

次に子スレッド上で CGI が実行されると、その結果としてのHTML は再び親のHTTPサーバーに
データ待ち行列を通じて戻されて、HTTPサーバーがクライアントへ結果の HTMLを送信していました。

従来のクライアントサーバー・モデル

しかし、お気付きのように、これでは HTTPサーバーにばかり送受信の負荷が集中してしまいます。
また HTTP サーバーと子スレッドのあいだには絶え間ない通信が行われます。
子スレッド達は次に利用可能な子スレッドはどれであるかを常に HTTPサーバーに報告しなければなりません。
ひとつの子スレッドが異常終了したり、フリーズしたりすると親の HTTPサーバーはフリーズしたり、
論理的矛盾を生じてすべての動作が凍結してしまったりすることが発生してしまいます。
しかし世界中に存在する多くの HTTPサーバーはこの処理形式によって行われています。

それでは IBM が推薦する次世代のC/Sモデルとは、どのようなものなのでしょうか?
次世代の C/S モデルではHTTPサーバーはクライアントからの要求信号は受け取りますが、
クライアントからの要求データを受信することはありません。
要求の信号を受け取るや否や子スレッド達にメモリを通じて一斉に同時に配布するだけです。
すべての子スレッド達は我先、一斉にこのメッセージだけを争って受け取ろうとします。

そして最初に受け取った子スレッドだけが、クランアントと単独で受信を開始します。
クライアントからの要求を受信すると、その子スレッドはまた自分自身で CGI を実行した結果のHTML を戻します。
親の HTTPサーバーはどの子スレッドが要求を受け取ったのかは全くわかりません。
ただ一斉に要求があったことのメッセージをバラまくだけでいいのです。

次世代のクライアントサーバー・モデル

このモデルでは HTTPサーバーの役割はブラウザからの信号を受信するだけです。
したがって HTTPサーバーへの負荷は大幅に緩和されており、
全体としてのロード・バランスが図られていることがおわかりでしょう。

子スレッドとの通信もごくわずかな最小限のものだけで済みますので、
全体として処理速度は大幅に向上することになります。
特に大規模システムでのアクセスの集中に効果を発揮し、
ローエンド・モデルのSystem i (iSeries400) であっても十分なパフォーマンスを得ることができます。
しかもどの子スレッドが異常終了したり操作員による強制終了があったとしても
論理的矛盾を起こすことなくそのまま平静として処理は続行されます。
つまり堅牢性とパフォーマンスを兼ね備えた理想的な C/S モデルであると言うことができます。

Ver4.0 ではAlaska はこの理想的な C/S モデルとしてリエンジニアリング(再作成)されて生まれ変わりました。
しかも Alaska のソース・コードは以前の数分の一という小さなものです。
軽快で堅牢な Webのプラットフォームを AlaskaVer4.0 が提供します。

ユーザーログイン機能

Web移行で最初に悩むのがサインオンに代わる
ログイン機能です。
Alaska Ver4.0 ではユーザー・プロフィールの
「ホームディレクトリー」 に登録しておくだけで
ブラウザ(IE) によるログイン機能を利用することができます。

しかもログインはブラウザ(IE) によってコード化されますので
不正な盗撮によるパスワードを盗まれる可能性を低減しています。

ログイン

■ どのユーザーがログインしているか ?

現在、どのユーザーが接続して使用中であるかはシステム管理者にとって気になるところです。
ユーザーログイン機能によってログインした後では CGI の起動も、
すべてログインしたユーザーでの仮想ユーザー環境として実行されます。
このためにクッキーや HTMLを工夫する必要もありません。

i5/OS(OS/400) V5R4M0 であれば WRKACTJOB によって接続中のユーザー名を表示することができますし、
それ以前の i5/OS(OS/400)リリースであっても EnterpriseServer の WRKNETJOBコマンドによって
ユーザー名を表示することができます。

ログインユーザーの確認

Keep-Alive接続を保持

世界標準の HTTP/1.1 規格ではブラウザが HTTPサーバーに対して通信の接続を保持(Keep-Alive)しようとしますが、
CGI の実行では HTTPサーバーが接続を保持することはありませんでした。
そのため CGI が実行される度に毎回々、再接続が行われていたのです。

Alaska Ver4.0 では CGI といえども一旦、接続が確立されてしまえば接続を保持します。
これは WWW が理想とする完全なクライアント/サーバー型接続を実現するものです。
接続の保持によって再接続することなく、あたかもローカルの PCOMM のように驚くほど素早い応答が可能になりました。

SSL通信でセキュアな通信を保証

SSL ( Secure Socket Layer ) によって通信の情報は暗号化されて送受信することができますので、
パスワードや 企業秘密、プライバシーに関わる情報、クレジットカード番号などを安全に送受信することができます。
System i(iSeries400) の SSL通信の高度な設定から運用までをサポートしています。

■ SSLとは?

TCP/IP 通信を利用するプロトコルとして HTTP, Ftp, Telnet などがありますが、
構内はもちろんインターネット経由でのこれらの通信は通信を傍受(キャプチャー)すれば、
簡単にその内容が悪意のある第三者によって読み取られてしまいます。
これに対して SSL はデータの盗聴やなりすましを防ぐことができます。

SSL とは Netscape Communications 社が開発したインターネット上で情報を暗号化して
送受信するプロトコル(通信手続き)のことです。
SSL は TCP/IP通信を行う HTTP, Ftp, Telnet などでデータを暗号化して
情報を安全に送受信することができる通信手段です。

SSL は公開鍵暗号やデジタル証明書、秘密鍵暗号、ハッシュ関数などによってサーバーと
クライアントのあいだの認証と通信の暗号化を行います。

■ SSLを iSeries/i5 で使うには?

iSeries/i5 で SSL を使うには以下の条件が必要となります。

前提となる IBM i OS(i5/OS、OS/400) ライセンス・プログラム (無償)
  • 5722DG1 IBM HTTP SERVER FOR I5/OS

  • 5722SS1 ディジタル証明書マネージャー

  • 5722SS1 CCA 暗号サービス・プロバイダー

対象となる IBM i OS(i5/OS、OS/400)リリース
  • IBM i OS(i5/OS、OS/400) V5R2M0 〜 V5R4M0 , Ver6.1 〜 Ver7.3

サーバー側の設定

SSLを使用可能にするためには次のような高度な設定が必要となります。

  • SSL 通信用のユーザー・プロフィールの作成

  • IBM HTTPサーバー *ADMIN の起動

  • ディジタル証明書マネージャーによる

    • - 証明書ストアの登録

    • - 証明書の作成

    • - アプリケーションの登録

    • - アプリケーションへの証明書の割り当て

SSL通信をサポートするEnterpriseServer 累積PTFの適用

EnterpriseServer の保守ユーザーであれば EnterpriseServer を導入後、
弊社サイトより最新の累積PTF をダウンロードして適用する必要があります。(無償)

■ SSL環境設定サービス(有償)

EnterpriseServer の保守ユーザーであれば(株)オフィスクアトロが提供する
「SSL環境設定サービス」(有償)によって SSL通信のための環境の設定を行うことができます。

「SSL環境設定サービス」ではサーバー側の次のSSL環境の設定をすべてユーザーの代わりに行います。
  • SSL 通信用のユーザー・プロフィールの作成

  • IBM HTTPサーバー *ADMIN の起動

  • ディジタル証明書マネージャーによる

    • - 証明書ストアの登録

    • - 証明書の作成

    • - アプリケーションの登録

    • - アプリケーションへの証明書の割り当て

導入と保守サービス

(株)オフィスクアトロによる「SSL環境設定サービス」はオンサイトの SSL環境の設定と教育、
さらに設定後の1年間の保守をサービスとして行います。

対象となる証明書

「SSL環境設定サービス」で使用する証明書は iSeries/i5 が発行する無償のイントラネット用の証明書だけです。

第三者機関による有償の証明書を使用されたい場合は最寄りの特約店やソフトウェア・ハウスにご相談ください。

特約店やソフトウェア・ハウスまたは自社による SSL環境の設定

(株)オフィスクアトロに依頼するのではなく、自社によるか、または最寄りの特約店や
ソフトウェア・ハウスなどにって SSL環境の設定を行うこともできます。

ただしその場合は SSL通信上の Q&A は製品保守サービスの対象外とさせて頂きます。

料金

iSeries/i5 1台または1 LPAR につき ¥480,000.

Proxyサーバー機能でWebサーバーを統合化

一台の公開Webサーバーだけで社内のローカル・サーバーを統合化して処理することができます。
外部に対するWebサーバーに Alaska が起動していれば、外部クライアントからのHTTP要求を
必要に応じて社内の別のサーバーへリダイレクトして、Alaska が応答を受け取って
社外クライアントへ代理応答(Proxy)として戻すことができます。

この Proxy サーバー機能によって 重要なデータ・ベースだけは公開サーバーではなく
安全な社内サーバーへ配置することができます。
また大量の画像データだけを 安価な HDD である別の PCサーバーへ配置させることができます。

■ Proxy サーバーの仕組みとは ?

Proxyサーバーの仕組みとは?

実用性/運用性のサポート

スレッドの自動拡大

多数クライアントからのアクセス集中時にスレッドを自動拡大

障害時の再起動

障害時における再起動も通信を連続させ、応答を中断させません。

ディバッグ・インスタンス

本番環境とは別にプログラマー専用のディバッグ・インスタンスの稼動

最大オープン・ファイル数

大規模運用時における使用可能なSOCKET数の拡大

アクセス・ログ
エラー・ログ
CLIENTキャッシュ

CGIの出力であってもブラウザにキャッシュさせることができます。

SERVERキャッシュ

System i (iSeries400)側でもCGIの出力をキャッシュさせることができます。

ディバッグ情報

受信内容, 環境変数, 値の取得, 値のセット