AutoWeb と Telenet

Telnet とは

Telnet とは UNIX システムへのネットワーク仮想端末となる TCP/IP通信によるアプリケーションです。 TCP/IP 通信の PORT番号 23 に対して接続して対話式の画面を提供してサーバーと通信を行います。 Telnet は UNIX に始まり System i もこの Telnetサーバーが用意されています。

私達が良く知っている 5250エミュレータでは「TCP/IP接続のTelnet5250」という通信構成がありますので、5250エミュレータも Telnet であると思われがちですが 5250エミュレータは Telnet ではありません。

それでは実際の Telnet を見てみましょう。 System i が 一次言語が英語環境であれば Windowsに付属している Telnet によってSystem i に接続することができます。

Telnet での System i への接続方法

Windows で

[スタート] - [プログラム] - [アクセサリ] -
 - [コマンド・プロンプト]

によって DOS-コマンド・プロンプトを起動します。
最初に Telnet と打鍵して Enter キーを押してください。

画面が次のように変わります。
Telnet が起動されて Telnet のコマンドを使用できるようになりますので、下記のように System i のIPアドレスを指定して 

open 192.168.1.3

のように指示します。

接続が完了すると次のようにお馴染みのサイン・オン画面が
表示されます。

ユーザーとパスワードを打鍵して(実行キーではなく) Enterキーを
押すと次のように初期メニューが表示されます。

このように Windows に付属している Telnetクライアントを使ってあたかも 5250エミュレータであるかのように接続することができます。

ところで、このような Telnetクライアントはどのようにしてできているのでしょうか ? Telnetプロトコルは RFC854 という規格で決められていますので、このような Telnetクライアントをユーザーが Java や C言語で作成することはそれほど困難なことではありません。 市販書籍にも Telnetクライアントのソースや作り方は紹介されていますし、Telnetクライアントのフリーソフトも数多く出回っています。 RPGプログラムを使っても System i の中に別のSystem i の Telnetクライアントを開発することもできます。

Telnetクライアントを使った WebFacing

Telnetクライアントを作ることは容易ですので、それでは Telnetクライアントを使った WebFacing を考えてみましょう。

このTelnet による WebFacing は一見、成功に見えます。
Telnet による WebFacing には次のような利点があります。

  • Telnetクライアントの製作が簡単である。
  • Telnetクライアントであるので対System i だけでなく、Telnetサーバーを持つ、
    どのようなサーバーに対しても Web化が可能である。
  • このWeb化ツールは他のプラットフォームにも使えるので市場が広い。
  • Web化ツールの製作者は System i の知識をそれほど必要とはしない。

しかし、Telnet の問題点は次にあります。

Telnet による WebFacingツールは、この画面を表示しているのではありません。
この画面イメージとほぼ同じ情報を入手して処理しているに過ぎないのです。
例えば受注数という入力項目は、人間であれば「おそらく数字のみの入力である」と 想像がつきますが Telnet では単なる入力項目としか見なされません。
右寄せが必要であるのか、どのように編集するのかは、また漢字のみの入力であるかも 全く不明なのです。

つまり 5250エミュレータがインターフェース側として行っていた妥当性検査の情報は Telnet では取得することはできません。 そのため生成されたHTMLは、そのまま
ユーザーには解放することはできないので何らかの妥当性検査を追加する仕組みが
必要となってきます。 多くの WebFacingツールは、このようにユーザーの手動による機能追加を必要とします。

前述した Telnetクライアントによる WebFacing の利点をもう一度読み直してみてください。
Telnetクライアントの利点と思われていたものは、すべてユーザーにとってのメリットではなく、
作り手、すなわち WebFacingツールの提供側にとってのメリットでしかありません。

Telnet の処理構造と 5250エミュレータの処理構造は下図のような構図をしていると考えられます。

Telnet が一旦、5250ストリームを TELNETプロトコルに変換しているのに対して5250エミュレータは 5250ストリームを直接、
処理しています。 この5250ストリームには画面のフィールド情報の属性が詳細に定義されています。
従って5250エミュレータは 5250ストリームの仕様に従って妥当性検査だけでなく複雑な仕様にも対応することができるように
なっています。 5250ストリームは単に画面イメージを、そのままクライアントに送っているのではなく最適化されるように
事細かに圧縮されて効率よく画面を構成する仕組みを備えています。

例えば画面のある行に 「AAA ..... A」 と80文字の文字｢A｣の表示が必要であるとします。
5250ストリームには、最初に文字 A を表示して、次にその表示を 79回繰り返せ、というようなストリームとして構成されます。
また 5250ストリームは単なる文字列だけでなく画像や HTMLストリーム、あるいはビデオ・イメージすらも仕様として
兼ね備えています。もちろん各フィールドの属性は事細かに指示されています。
5250ストリームは合理化され構造化された仕様を備えているのです。
私達が毎日使用している 5250エミュレータは、実は内部ではかなりの高度な処理を経て表示されているのです。

Telnetプロトコル と 5250ストリームとを比較すると

ということになります。

AutoWeb による解決

それでは AutoWeb は、どのようにして WebFacing されているのでしようか ?
AutoWeb は Telnetクライアントではなく 5250エミュレータとしてのクライアントとしてWebFacing を行います。

AutoWeb は上記のように System i 内部で 5250ストリームを直接、読み取って処理する5250エミュレータと同じような
処理構造をとっています。 5250エミュレータのように端末表示するのではなく 5250ストリームを読み取ると同時にHTML に
変換してブラウザへ送出しています。 いわば HTMLエミュレータとでもいうべき処理を行っています。

最初に AutoWebによるこの処理構造の欠点を挙げてみましよう。
それはすべて Telnet による WebFacing の利点の裏返しとなります。

  • AutoWebの製作／開発が高度な技術を要する。
  • System i だけにしか製品化できない。
  • 市場が System i だけに限られる。
  • 開発者は System i の高度な知識が必要とされる。

しかし、これらの欠点(?)は System i ユーザーにとって欠点となりうるでしょうか ?
これらは AutoWebを提供する側にとっても不都合なことではありますがSystem i のユーザーにとっての欠点とはなりません。
AutoWeb が 5250ストリームを直接、読み取ることによって 5250画面のすべての情報をAutoWebは入手することができます。
その結果として

  • 動作させるだけでWeb化することができる。
  • 移行や開発を必要としない。
  • 5250ストリームによる HTMLや画像の埋め込みにも対応できる。
  • HTML画面のカスタマイズが容易となる。

これらはSystem iユーザーにとっての大きな利点をもたらします。

動作させるだけで必要な妥当性検査が既に埋め込まれてすぐにでも運用できる、といった理想的な Web化は
Telnetクライアントでは実現することはできません。
移行作業が必要であというWebFacing製品は Telnetクライアントを利用しているとほぼ、考えることができます。
ソリューション・プロダクトを提供する側が楽で容易な分、ユーザーが移行や開発に苦労しなければならないのはおかしな話です。

AutoWeb は高度なテクノロジーを必要としましたが、System iユーザーの多くの開発コストと労苦を削減できるのであれば
ソリューション・メーカーとして当然のことであると思います。
私達は System i のユーザーへの貢献を第一と考えます。

[ TOP ]