EnterpriseServer-Alaska

「㈱」や「Ⅰ,Ⅱ, ...」などのような漢字は「機種依存の漢字」として
PCによって異なる2 種類の ASCIIコードを持っています。
一般には EBCDIC に変更可能であるのは、片方だけなのですが Alaska は、どちらの漢字の
入力もサポートしています。JIS83で変更された漢字群もサポートしています。

■ 高速 EBCDIC/ASCII 変換を搭載

HTMLテンプレートは ASCIIコードのままで IFS に保管されていますので、クライアントへ変換する必要はありません。
唯一、データだけを EBCDIC/ASCII 変換する必要がありますが、この変換速度にもこだわりました。
独自の EBCDIC/ASCII 変換は i5/OS(OS/400) API の 2倍以上の変換速度で実行されます。

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

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

しかも、

「戻るボタン」問題: 「戻るボタン」を押しても画面遷移は一致します。
「×ボタン」問題: 「×ボタン」を押しても CGI は正しく終了します。

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

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コマンドによって
ユーザー名を表示することができます。

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

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

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.

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

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

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

スレッドの自動拡大: 多数クライアントからのアクセス集中時にスレッドを自動拡大
障害時の再起動: 障害時における再起動も通信を連続させ、応答を中断させません。
ディバッグ・インスタンス: 本番環境とは別にプログラマー専用のディバッグ・インスタンスの稼動
最大オープン・ファイル数: 大規模運用時における使用可能なSOCKET数の拡大
アクセス・ログ
エラー・ログ
CLIENTキャッシュ: CGIの出力であってもブラウザにキャッシュさせることができます。
SERVERキャッシュ: System i (iSeries400)側でもCGIの出力をキャッシュさせることができます。
ディバッグ情報: 受信内容, 環境変数, 値の取得, 値のセット

| HOME |