CCSID = 5026, 5035 および 1399 をサポートしています。 半角カナも英小文字の入力／表示も問題なく行えます。

半角カナや英小文字の入力は問題ありません。 また�鰍竍T、�U･･･などのいわゆる機種依存の漢字も正しい EBCDIC 漢字コードに変換されます。

外字も PC にダウンロードして頂ければ入力と表示が可能です。

可能です。 PORTを IBM HTTPサーバーの 80番とは別に 3009番を使用することができます。

Alaska であれば漢字はカナの文字化けが起こることはありません。 EnterpriseServer のユーザー様では照会業務だけではなく、ほとんどのユーザーが日常的な入力業務に利用している例がほとんどです。

多数クライアントからのアクセスによって子スレッド数が不足すると Alaska は新しい子スレッドを自分で生成しますので問題ありません。 ただしアクセスするクライアント数が減少したからといって増えた子スレッドが消滅するわけではありません。

できます。

ご指摘のとおり開発中の CGI が暴走したりして本番環境への悪影響が発生することも想定されます。 このような事態に備えて、本番用のインスタンスとしての HTTPサーバーの起動とは別に開発用のインスタンスの HTTPサーバーを起動させることができます。 開発用の HTTPインスタンス (PGMR) であれば本番に影響を与えることはありません。

再起動の必要はありません。

従来の既存の HTTPサーバーはご指摘のように全体を再起動させる必要がありました。 これは親 HTTPサーバーと子スレッドが論理的に関連づけられて構成されているからです。 しかし Alaska であれば親 HTTPサーバーである Alaska が子スレッド達に一斉にメッセージを配布するだけというシンプルな構造となっていますのでトラブルを起こしている子スレッドだけをWRKACTJOB 上で強制終了させるだけで何の問題もなく継続して処理は続行されます。

これは Alaska が IBM が推薦する次世代の C/Sモデルを踏襲しているからです。 したがって障害に非常に強い C/S モデルであり、大規模な多数クライアントからのアクセス集中や上記のような障害時に効果を非常に発揮します。 この点において Apache よりは Alaska は次世代モデルとして進んでいます。

可能です。

ブラウザ(IE) で設定済みの言語を System i 側の CGI で判断することができます。 それによって HTML テンプレートを言語別に用意しておけば対応する言語で表示することができます。

可能です。

携帯電話からのアクセスであることと携帯電話会社(3Wave)を CGI で簡単に判別することができます。

大丈夫です。

従来のHTTPサーバーはクライアントに対する送受信をすべてHTTPサーバーだけが行っていました。 これではご指摘のとおり、多数アクセスが集中すると HTTPサーバーばかりに負担がかかってしまい、全体のパフォーマンスが著しく低下してしまいます。

Alaskaはロード・バランサーとしてクライアントからの要求信号を受け取るだけに過ぎません。 つまりクライアントからの要求文の受信もクライアントへの結果の HTML の送信も数多く待機している子スレッドに分散されて処理されます。 最もアクセスが集中するはずの Alaska は信号を検知するだけで、ただちに子スレッド達に分散してしまいますので、多数クライアントからのアクセスが集中したときにこそ真価を発揮します。

ご参考までに子スレッド数が不足していると検知されると子スレッドは自動的に生成されて増加します。 ( しかし、アクセス数が少なくなったからと言って増加したスレッド数が減少することはありません。)

大丈夫です。

Alaska は子スレッド達に処理を指示した後でもクライアント数に不足がないかどうかを常に監視してします。 試しに子スレッドをすべて強制終了させてから要求を行っても正しく応答が帰ります。 しかも子スレッド達は最初に指定して投入した個数の分だけ新しく復活します。 このように実際運用面での耐用性が考慮されています。 実行中の障害によって子スレッドが一時的に減少していも全体としての整合性が損なわれることはありません。

ブラウザは通信を開始してから何も操作の行われない時間(アイドル時間)が 1分以上発生すると
サーバーとの通信を切断してしまいます。
このため次の操作が行われて再接続されたときには以前とは異なる別の子プロセス上で
実行されます。
このため QTEMP や *LDA, ライブラリー・リストも使用することができません。
しかし Alaska では適用業務を通信の保持(Keep-Alive)として設定して5250 エミュレーターのように
通信を永続的に持続させることができます。
通信の保持(Keep-Alive)を指定すれば QTEMP や *LDA, ライブラリー・リストも使用することが
できます。
またライブラリー・リストは様々な方法での設定が用意されています。

以前に言われていたような DMZ は不要です。 一般には System i にインターネット用の LANカードと構内用のLANカードの2枚を装着してこれらのあいだの通信を遮断さえしてやれば十分です。

開発会社としての弊社では実証用としてAlaskaをHTTPサーバーとして長い間、インターネットに公開を続けています。 これはユーザーさまに代わり、実際運用面での実証を行うためであり、アタックを受けても問題なく正常動作が維持されていることを確認しております。 もちろんAlaskaも不明なアタックに対する対応も施されているのは言うまでもありません。

ご参考までに攻撃を受けやすい HTTP サーバーは不明な要求に対しても応答してしまうからに過ぎません。 HTTP サーバー自体は単なる TCP/IPサーバーのひとつに過ぎませんので PORT = 80 を経由して何か得体の知れないモノが物理的に入ってくるわけではありません。 単なる通信プログラムに過ぎないのです。 攻撃のほとんどは簡単なスクリプトを送りつけたり、CFG などのダウンロードを要求するものです。 Alaska はこのような不明な要求には応答しませんので、外部からの攻撃を受けて被害を被ることはありません。

SSL は Ver4.0 での2007年3月20日出荷分よりサポートされています。 SSL通信を可能にするためには次の IBM ソフトウェアが導入されていることがご必要となります。

製品としては SSL通信をサポートするように改訂されていますが、製品だけでただちに SSL が利用可能というわけではありません。 SSL を利用するには System i 上で SSL の環境設定がご必要になります。

SSL の環境の設定は IBM HTTPサーバー *ADMIN を起動してブラウザからディジタル証明書マネージャーを起動し、証明書を作成して Alaska をアプリケーション登録し、さらにアプリケーションに証明書を割り当てる必要があります。

ところが多くの場合、IBM HTTPサーバー *ADMIN が起動しなかったりディジタル証明書マネージャーの操作がわかりにくいものであるため、高度な技術経験がないと登録できないのが実情です。 このため(株)オフィスクアトロでは、お客様に代わって SSL環境のセットアップと1年間の保守サービスを含めた 「SSL環境セットアップ・サービス」(￥480,000) をご用意しております。

実は、HTTP サーバーのような待機ジョブは日付が変わっても内部での UDATE は起動したときのままです。 しかし Alaska からの CGI の起動の直前にはシステム日付(QDATE) が取得されてジョブの日付(UDATE) を更新するような仕組みとなっていますので、ご心配はありません。

できます。

実は通信相手の IPアドレスは HTTPプロトコルではなく、TCP/IPストリーム中に含まれています。 したがって一般の HTTPサーバーでは 通信相手の IPアドレスを取得することはできません。

しかし Alaska では CGI に対して IPアドレスを提供するプロシージャー(REMOTE_ADDRESS) が用意されています。 それだけでなく下記のように「遠隔装置名の登録」を事前に行っておけば、装置名をジョブ名として把握することが可能です。 このジョブ名は TONAKAI/2.0 で移行した RPG 内で SDS で今までどおりに取得することができますし、 EnterpriseServer での RTVJOBA コマンドで CLP でも取得することができます。

可能です。

Alaska では Proxyサーバー機能が追加されました。 これは公開サーバーとして最前面に立つ Alaska が社内サーバーへの要求を社内サーバーへリダイレクトするための機能です。

具体的には HTTP構成に社内サーバーへの転送記述を登録しておけば、転送記述に基づいて社外クライアントからの HTTP要求を社内サーバーへリダイレクトします。 社内サーバーからの応答は Alaska が代理応答として社外クライアントへ返送します。 社外からは Proxy応答であったのかは全くわかりません。

もちろん社内サーバーはローカル配置だけで十分であり、グローバル IP を持っている必要はありません。 唯一の条件は社内サーバーも Webサーバーであることです。 社内サーバーは System i であれば、Alaska が導入されて起動待機している必要がありますが、社内サーバーは Windows サーバーであれば、IIS が、また Linux であれば Apache や Tomcat などのWebサーバーでもかまいません。

このようにして 複数のWebサーバーを統合化して運用することが可能となりました。

はい表示できます。
別のサーバーに保管している画像ファイルを表示するには、HTTPサーバーである
Alaskaのディレクティブ設定[ Redirect ]を使用すれば、簡単に別サーバー(System i、PCサーバー)
に保管している画像ファイルを取得し表示することができます。
ただし他のサーバー(System i サーバー、PCサーバー等)にもHTTPサーバーが必要になります。

Alaska は HTTPサーバー として Apache の約 5〜6 倍異常の高速パフォーマンスを
発揮することが実証されています。
Apache の場合、すべてのブラウザとの通信を親プログラムである、
Apache サーバーが、すべて行なっています。
つまり、すべてのクライアントとの入出力をひとつの JOBが行なっているため
その JOB がボトル・ネックとなり負荷集中のためアクセスが集中すると
パフォーマンスが低下する原因となってしまっています。

これに対して Alaska の場合は、Alaska は着信だけを検知しますが
実際の入出力は複数用意されている各子プロセス(JOB)に分散されて処理されます。
従って負荷の分散が行なわれるため全体としてロード・バランスされて
最適なパフォーマンスを得ることができるようになります。

HTML は UNICODE (UTF-8) として Wizard で生成することができます。
EBDCDIC/ASCII 変換は CCSID 5026, 5035 および 1399 をサポートしています。

できます。

CCSID が 5026, 5035 または 1399 の、どの環境下であっても
半角カナと英小文字を同時に使用することができます。(入出力)

できます。

中国語の簡体字と繁体字の両方および韓国語の入出力をサポートしています。
例えば中国語の簡体字のみをサポートしているブラウザからの入力はブラウザが
サポートしている、と宣言している国際言語(Accept-Language)によって
簡体字が入力されたものと判断します。
これによってブラウザから入力された簡体字もEBCDIC の簡体字に翻訳されます。

また出力のときはブラウザがサポートしている言語の種類を判断して
そのブラウザに見合った適切な言語のHTMLテンプレートを出力することができます。
このようにひとつの CGI で、同時に複数の国際言語への対応が可能となります。

対応済みです。

特に、「スマート・コネクション機能」と呼ばれる新しい HTTPプロトコルの処理方法によって
プロセス共有問題も解決されています。

弊社ではこのようなクロス・ブラウザ対応を既に精力的に進めて開発中です。
FireFox, Opera, Chrome などの IE 以外のブラウザ上での動作を保証することを
クラス・ブラウザ対応と呼びますが、その対応としては大きく分類すると

�@ HTML , CSS による正しい表示
�A JavaScript の正しい動作
�B 操作上での正しい動作

がありますが、�@および�Aに関しましては開発に使用する HTMLテンプレートの問題であり
これは随時、お客様にご指導していく予定です。
�Bに関しましては、いわゆるプロセス共有問題を中心として製品の対応を進めています。

他社製品の多くが IE のみの対応としているのはソフトウェア・メーカーの技術的な問題に
起因していることがほとんどの原因です。
しかし最近では IE8 以降は他のブラウザと同じようにプロセス共有問題が問題視されるように
なっています。
プロセス共有問題とは複数個のセッション(画面)を起動しても、内部的にはプログラム(プロセス)は
少ない数しか起動されず、複数個のセッションを数少ないプロセスで共有されてしまう現象のことです。
これは最近のブラウザの仕様であり、IE と言えども、この仕様になりつつあります。
このプロセス共有は、PCのメモリ使用を少なく抑える効果はありますが、ある画面の結果が
別の画面に表示されてしまう、という、いわゆる入れ違い現象を発生させてしまいます。
この障害は特に WebFacing やセッション管理では深刻な事態を引き起こします。
そのため他社製品では 仕様を IE のみに限定してきましたが、IE8 からもセッション共有が
行なわれているため、手者製品ではこの問題は到底、解決することはできません。
近い将来に、やがては他社Web化製品では使えなくなってしまう日が近づいていると言えます。

この問題を重要視してきた弊社では、Alaska/7.0で、このプロセス共有問題をいち早く解決しました。
Alaska/7.0 の「スマート・コネクション機能」と呼ばれる新しい HTTPプロトコルの処理方法によって
高速パフォーマンスを維持しつつ、プロセス共有問題を解決しています。