通信とセッション管理

5250エミュレータの動作を ブラウザ上で再現するには、いくつかの問題があります。
現在の多くのブラウザは複数のセッションを起動したとしても、それらは別々の
プロセスとして動作するのではなく、同一のプロセス内の異なるタブとして
動作するように設計されているからです。

この図のようにブラウザのセッションは増えても HTTPサーバーとブラウザとのあいだの
通信プロトコルの TCP/IP Socket はただ一つしかありません。
これは複数組の電話で話し合う状況で利用している電話回線が一本しかないのと同じです。

セッションA から要求した結果はセッションB の画面に表示される、という入れ違い現象が起こります。
通信を保持しなければ、この問題は発生しませんが、通信を切断してしまうとセッション管理を
行うことができません。

というのも HTTPサーバー側ではブラウザの要求を処理する子プロセス(JOB) と複数、上図のように用意されて
待機していますがブラウザからの要求は毎度、同じ子プロセスで継続されて処理されるわけではありません。
毎回、どの AURORA_EGN上で実行されるかは不定です。
しかし、セッションを継続させて同じ AURORA_EGN上で動作が継続しなければ
QTEMP, *LDA, COMMIN & ROLLBK などのセッション管理を行うことはできません。

そこでこれまでは通信を保持する(Keep-Alive) ということで解決が図られていましたが
前述のように通信が共有されてしまうと同じ TCP/IP Socket での通信が行われてしまい、入れ違い現象を
避けることができなくなってしまっています。

このことは「セッション共有問題」と呼ばれていてあらゆる Web業務での深刻な問題となっています。

�潟Iフィスクアトロでは前述のセッション共有問題をスマート・コネクションという手法によって解決しました。
スマート・コネクションは安全で確実に動作し、求めるセッションの維持を実現する技術的解決です。

1. HTML には、その HTML を出力したジョブNo を AURORA_EGN の番号として
 AURORA_EGN=xxxxxx として埋め込んでブラウザへ出力します。

2.さらに HTML を出力と同時に TCP/IP通信は直ちにサーバーが切断します。
通信は切断されますので同じ Socket識別子による共有は発生しません。

3. HTML を出力した、この子プロセスは通常のメッセージ受信状態(一般受信=DEQW) ではなく
 元の同じ AURORA_EN=xxxxxx からだけを受信するという専用受信(SELW) に変化します。

4. HTTPサーバーAlaska は AURORA_EGN=xxxxxx として受け取った一般受信の AURORA_EGN は
 専用受信(SELW) の子プロセスに要求を転送します。

以上のように、1〜4 の処理によって

TCP/IP通信は常に切断されている

同じ元のJOB(AURORA_EGN=xxxxxx) に必ず戻って処理が継続される。

ということが実現されます。

さらにスマート・コネクションでは

5. セッションが終了とともに子プロセス(AURORA_EGN) も終了します。

これは AURORA_EGN=xxxxxx が埋め込まれていた HTML を静的にどこかに保存していて
後でログインしないで静的なHTML を再ロードして行う成りすましを防ぐためです。
セッション終了とともに子プロセスを終了してしまいますので後で HTML だけを
起動したとしても対応する子プロセスがもはや終了しているので
成り済ましによる活動化は絶対できません。

解説

セッション管理を行うと最初に問題となるのがブラウザの 閉じるボタンの処理です。
エンド・ユーザーが ボタンを押してブラウザを終了させてしまうと、サーバー側が
それを検知できないでいるとサーバー側の仮想端末ジョブがいつまでも終了しないで
更新レコードをロックし続けるという問題を生じます。

海外輸入製品ではタイマーを設けてある一定の時間のあいだにブラウザからの応答がないと
自動的にサーバー側のアプリケーションを強制終了するという手法がほとんどです。

これではソフトウェア・メーカーの技術の拙さを露呈しているだけであり問題の解決にはなっていません。

いくらエンド・ユーザーに ボタンを押さないように依頼したとしてもそれは無理な話です。

ボタンが押されたことを検知することは実は容易ではありませんでした。
実は ボタンはブラウザのフレーム外のボタンであるため JavaScript では ボタンが押されたことを
正確には検知できないのです。
サーバーとの通信が継続している場合であれば通信が切断されたことをサーバー側で検知することが
できますが ボタンは JavaScript の検知外です。

多くの Webアプリケーションではマウス・ポインターの位置を読んでクリックしたときに
「 ボタンが押されたのではないか」と予想するようにしています。
しかし、この方法は現在の類推に過ぎず、ブラウザの形態が変われば役に立たなくなってしまう可能性が
あります。
エンド・ユーザーがツール・バーなどをカスタマイズすれば、たちまちマウス・ポインターの位置は
異なる値となってしまいます。

そこで、スマート・コネクションでは出力する HTML が出力されると同時に
(OnLoad)HTTPサーバーAlaska にその旨を示す信号を送ります。
また、HTML がエンド・ユーザーによる操作によって別の HTML が要求されるときは一旦、
その HTML は表示されるなくなるわけですから消滅する旨(OnUnload) をやはり HTTPサーバーに伝えます。

画面遷移であれば OnUnload(消滅) の直後には、すぐに画面表示(OnLoad) の通知が
ブラウザからあるはずです。
OnUnload(消滅) だけの信号であれば、それは画面の消滅、すなわち ボタンが押されたものと
解釈することができます。

スマート・コネクションでは、このようにして ボタンを検知するようにしています。
この方法であれば ボタンの位置に左右されませんし、 ボタンではない終了方法にも対応できます。
しかも、最大の利点は通信が切断されている状態で ボタンが押されたことを検知できることです。
また、この方法はすべてのブラウザのすべてのリリースにおいて同様に判定することができます。

閉じるボタンの動作を検証の方法について解説します。

最初に AutoWeb でユーザー・アプリケーションを起動します。
ここではサンプル・プログラムとしてユーザー名: MN00, パスワード: MN00 で
ログインして [受注管理メニュー] - [受注の入力] を選択します。
ブラウザには次のように表示されます。

5250エミュレータで GO SERVERメニューで F5キーを押すと
HTTPサーバー : Alaska で MN00 でログインされている子プロセスがあることが
次のように確認することができます。

次に 5250エミュレータで実際に起動しているジョブを WRKACTJOB で
サブ・システム QINTER または QBASE の配下にあることを確認します。

この状態でブラウザの ボタンを押してジョブを中断して終了させます。

GO SERVERメニューでは MN00 で実行していた子プロセスは消滅しています。

さらに QINTER または QBASE の配下に存在していたジョブも消滅しています。

これで ボタンを押すと ボタンに連動して関連するジョブも自動的に消滅することを
確認することができました。
ボタンを押して直ちに元のジョブも終了させることができるのは AutoWeb だけです。

�潟Iフィスクアトロではブラウザの 戻るボタンに関しても ボタンはブラウザの履歴の
ヒストリー・バックではなく「 F12=戻る」ボタンとして処理されるよう JavaScript による
機能を組み込んでいます。
このため「 ボタン」は履歴を戻るのではなく F12キーとして動作します。
この機能はプラウザの設定やブラウザの種類やリリースに影響を受けることのないように
考慮されています。

ここではブラウザの 戻るボタンを押すことによる動作の検証方法について紹介します。

最初に AutoWeb でサンプル・アプリケーションを次のように起動します。

ユーザー名: MN00, パスワード: MN00 でログインして
[受注管理メニュー] - [受注の入力] の初期画面で、そのまま GOボタンを押すと
次のように明細画面が表示されます。

WRKACTJOB で、このプログラムPGM201 が実行されているジョブを
「 5=処理」→「 11.呼び出しスタックの表示」で呼出しスタックを調べて見ると
次のようにステートメント 210で停止していることがわかります。

また「 14.オープンされたファイルの表示」を調べてみると
DSPF : PGM201FM のレコード様式 : SFCTL01(サブ・ファイル・コントロール) が
オープンされていることがわかります。

次にこの状態でブラウザの ボタンを押してください。

( 戻るボタンが有効となるのは MS-IE では Ver9 以降です。)

ブラウザの表示は次のように初期画面の表示に戻ります。

この画面表示はブラウザのヒストリー・バック機能によって履歴を戻ったのでしょうか ?
「 11.呼び出しスタックの表示」の表示を調べてみると
次のように明細画面のスタックとは異なっています。

さらに「 14.オープンされたファイルの表示」を調べてみると
DSPF: PGM201FM のレコード様式 : DSPHEAD(初期画面レコード) が
オープンされていることがわかります。

以上でおわかりのようにブラウザの ボタンはブラウザの履歴を戻るヒストリー・バックではなく
F12キーとして働いていることがわかります。
ブラウザの ボタンをこのように動作させるためにはユーザー・アプリケーションは
F12キーで初期画面へ戻るように設計されていなくてはなりません。