TCP/IP
|
|
最近良く耳にするTCP/IPはインターネットのプロトコルです。
ただし、現実に「TCP/IP」という名称のプロトコルが存在するわけではなく、
いわば複数のプロトコル群の総称です。
TCP/IPは「Transmisson Control Protocol」、IPは「Internet Protocol」
の総称で、それぞれトランスポート層、ネットワーク層に属するプロトコルです。
また、FTP、TELNET、HTTP等は アプリケーション層に属します。
このプロトコル群で重要なのは、パケットを使用していることです。
データをぶつ切りにした各パケットには、到達すべきノードのアドレスが付加されます。
32ビットで表されるこのアドレスが いわゆるIPアドレスです。
ノードのアドレスとは、「AS/400の端末にポートごとのアドレスを割り振る」
というときのアドレスと同じです。
異なるのは AS/400と端末のデータのやり取りでは、一度接続が確立してしまえば、
再度アドレスを解決する必要はない（セッション維持される）のですが、
パケットの場合は１パケットごとにアドレスの解決が必要な点です。
現実的にTCPによって仮想回路が設定されるので、パケットを意識する必要はありません。
アプリケーションによっては １バイト単位の送受信が必要されます。
|
URL
|
日常のシーンでも耳にするURLは、インターネット上に存在する
資源を特定するための場所を意味します。
例として次のようなURLを見てみましょう。
http://www.as400.co.jp:80/~hai/index.html
最初の「http:」の部分はスキーム（scheme）と呼ばれ、
使用するアプリケーション層レベルのプロトコルを意味します。
種類は次の通り。
| http: | HTTPを使用してwwwのデータを扱う。 |
| ftp: | FTPを使用してファイルの送受信を行う。 |
| mailto: | 指定されたアドレスにメールを送る。 |
| telnet: | 指定されたアドレスのマシンにTELNET接続する。 |
| file: | ローカルマシンのディスク内のファイルを指定する。 |
|
「www.as400.co.jp」はドメイン名です。
ドメイン名はDNSによってIPアドレスに変換されます。
これはSNA上のマシンを、アドレスではなく名前で参照できるのと同じです。
ホストという言葉もありますが、ドメインとの違いは、
「ホスト」がマシン固有の名前であるのに対し、
ドメインはアドレスだという点です。（「co.jp」の意味はDNSの項を参照）
「:80」はポート番号です。
ポートとはAS/400のTWINAXをつなぐものとは異なるので注意が必要です。
（「後述の「ポート」を参照）
普通はこのポートは指定されないことが多く、
その場合、HTTPはディフォルトでポート80を使用します。
「~hal/index.html」はパスです。
最近 AS400でもIFSで使用されるようになりました。
DOS/Windows系でお馴染みのディレクトリ構造を表現するものです。
もともとはUNIXのファイルシステムをDOSが取り入れたものです。
ちなみにこの「~」（チルダ）はUNIXのユーザーと意味します。
UNIXではユーザー登録を行うと、（AS/400でユーザープロフィールを作るのと似ています）
そのユーザー名でディレクトリが作成されます。
「~hal/index.html」はそのユーザーディレクトリの中の index.htmlを示しています。
通常はこの「/index.html」でさえ省略しますが、「/」はブラウザが補完し、
「index.html」の部分はWebサーバーの設定でディフォルト指定します。
|
DNS
|
|
Domain Name Systemの略で、ドメイン名をIPアドレスの変換します。
実際にはたった１台のマシンで全世界のドメイン名を管理するわけにはいきませんから、
変換テーブルは分散管理されています。
分散管理の方法はディレクトリ構造に似ています。
一つのノードからインターネットの世界へ流れでたパケットは、
最初に発信元のノードで指定されたDNS（Primary DNS）へ飛んでいきます。
そこでアドレス変換できなければ上位のDNSへ転送されます。
「.co.jp」の場合はjp.がトップドメインのDNSをあらわし、co.がサブドメインのDNSです。
さて目的のアドレスを理解したパケットが、
一直線に目的地に到達できるかというと、そうではありません。
「どこへ行くか」はわかっても、「どうやって行くか」まではわからないからです。
そこで、パケットはとりあえず隣のルーターを訪問し、そこでアドレスを照会します。
アドレスがその管理下にあれば旅も終わりですが、
なければさらにその隣のルーターへ、といったことを繰り返します。
最大255のルーターを経由することが可能ですが、
それを超えるとパケットは破棄され、送信元に破棄が通知されます。
|
COOKIE
|
|
WWWのHTTPというプロトコルは、ユーザーの状態を保存できるよういは設計されていません。
たとえば検索エンジンで何かをサーチした結果が、複数ページに渡る場合、
ユーザーが「次の２０件の表示」と指示しても、Webサーバーが受け取るのは
最初のページを表示したときと全く同じコマンドです。
これでは不便なのでWebサーバーからブラウザに送るデータに
ユーザー識別記号を付加して送り、ブラウザ側でそれを保存し、
ブラウザからWebサーバーにデータを送り返すとき、
その識別記号を添付する仕組みを考え出したわけです。
Webサーバーでは識別記号単位でユーザーを管理する情報を
「セッション」情報として保管します。
この識別記号をWebサーバーからブラウザに送ることを「クッキーを食べさせる」と表現します。
|
XML
|
|
eXtensible Markup Languageの略。
WWWのホームページを記述するHTMLの拡張版で、異機種間のデータ交換にも使用されます。
HTMLの拡張でデータ交換というやや不思議な感じもしますが、
実際のところHTMLはタグの使用でブラウザにデータを送っているわけですから、
自然な拡張方向であると言えます。
HTMLがブラウザさえあれば機種を選ばないように、
XMLでも基本的に平易なテキストでデータ交換を行うので、異機種混在は問題になりません。
また通常のデータ交換では、受け取り側が事前にデータのフォーマット自体も
タグという形で同じに送り出します。
これによって変更に強いシステムが容易に構築できます。
|
ファイアウォール
|
|
IPアドレスは気温的にはすべてのノード、
つまり世界中に存在するあらゆるパソコンが、
それぞれに唯一無二のアドレスをもつという考えで作られています。
（この固有の番地がないと、パケットを正確に届けることすらできません）
ですから、どこかのサーバーにアクセスすれば、
逆にそのサーバーから自分のパソコンを識別され、
パケットを送りつけられることになります。
またDNSの項目でも説明したように、パケットは複数のルーターを経由するので、
ルーターの管理者がその気になれば、パケットを盗み取ることもできます。
しかも送られるデータは基本的に、誰もが解読できる平易なテキストで作成されます。
これがインターネットはセキュリティに弱いと言われる理由です。
そこで、悪意ある人間が侵入できないように頑丈な門を置き、（PROXYサーバー）
仲間内でしか通用しない符丁で会話（暗号）することが必要になります。
|
日本語文字コード
|
現在コンピュータの世界で使用されている日本語文字コードは以下のものが主流です。
１．EBCDIC
２、JIS
３．SHIFT JIS
４．EUC
５．UNICODE
２．のJISはJIS X 0208という規格で制定されています。
基本的にSHIFT JIS、EUC、UNICODEはこの規格のスーパーセットです。
つまり相互に変換が可能だということです。
この中でEBCDICの際立った特徴は漢字表記のためにSI/SOを採用していることです。
JISは区と点という概で文字を識別します。
区は１バイト目、点は２バイト目で、94x94の符号区間をもちます。
ただし実際には９区から１５区と、８５区から９４区は使用されていません。
どの文字をコード体系に含めるかという点では他のコードの基礎になっています。
SHIFT JISはマイクロソフト社が提供したコード体系です。DOSとWindowsの普及により、
PCの世界では実質的な標準になりました。
EUCは Extended Unix CODE の略です。
UNIXのための日本語であるということは、
インターネットの世界では「標準」を意味します。
よく、「メールに半角カナを使うな」と言われるのは、
このコード体系の半角カナの扱いに起因しています。
（もっともEUCという体系が半角カナを規定していないわけではなく、
単にEUCを処理するプログラムが手を抜いていることが多いだけ、とも言えます）
UNICODEは最新の規格です。Windows NTで使用され始め、
JavaやVisua Basicの内部処理で使われています。
|
Websphere
|
IBMのeビジネスの中核ともいえるWebSphereは、
主に WebSphere Application Server と WebSphere Studio という
２つの製品群で構成されています。
WebSphere Application Server は WebサーバーとAS/400の資源を結びつける役割をします。
AS/400に保管されたDBから動的にHTML/XMLページを作成するため、
サーブレットやJSPといった機能を提供します。
HTMLはいわば、いろいろな場所へジャンプする機能が付いた本のようなものです。
これが HyperText Markup Language と呼ばれる由縁です。
本であるなら、どこへ飛ぼうが書かれた内容が変化することはありません。
本来非常に静的なものなのです。
ホームページの作者が書き換えない限り、いつまでも同じ内容です。
これでは面白くないと考えだされたのがCGI（Common Gateway Interface）です。
HTMLはディスク上に存在するファイルなので、それをプログラムで読み書きすることが可能です。
そこでユーザーからの要求があった時点で、
プログラムによりHTMLファイル自体を生成しようというのがCGIの考え方です。
これに対してJSPやNet.Dataは、HTMLファイルの内部にマクロを組み込み、
それを処理させて、動的にHTMLを組み立てます。
（ちなみに「Net.Data」とはAS/400HTTPサーバーの機能です。）
この処理プロセッサ自体はCGIです。
一方の WebSphere Studio はWebアプリケーションの構築・保守を行うための、
統合開発環境を提供する PCベースのツール群です。
|
Net.Commerce
|
WebSphereがeビジネスの万能ツールだとしたら、
Net.Commerceはネット上にバーチャルショップを開設するための
専用ツールといえるでしょう。
（というより、バーチャルショップ運営の適用業務パッケージと言ったほうが
正解かもしれません。）
X-PACKなどと同様、まったくカスタマイズしなくてもバーチャルショップ運営は可能ですが、
やはりカスタマイズしたほうがニーズを正確に実現できるでしょう。
この Net.Commerce のカスタマイズは主に Net.Data を使用して行います。
|
CCSID
|
AS/400erにとっての文字コードと言えばCCSIDです。
実際eビジネス系の資料にはCCSIDがよく出てきます。
CCSIDは以下の４つの要素で構成されています。
１．Character Set
２．Code Page
３．Encoding Scheme
４．Additional Coding-related Required Infomation
１．の Character Set はどんな文字が含まれるかを規定します。
（たとえば英小文字を入れるかどうか、など）
２．の Code Page は、１．で規定された文字にどの符号を割り当てるかを規定します。
（たとえば「耳」という漢字を１６進数の0x33で表す など）
３．の Encoding Scheme はCCSID相互のコード変換方法を規定します。
４．は補完情報です。
|
オブジェクト
|
AS/400でお馴染みのオブジェクトとは違って、
オブジェクト指向プログラミングでいう「オブジェクト」とは、
データと独自の処理ルーチンを内包し、自立的にある機能を遂行できる
一種のロボットのような存在です。
オブジェクトに何らかの動作をさせるときには、
メッセージという形で命令を与えます。
その命令をどのように実行するかはオブジェクト自体が知っています。
オブジェクト指向自体は きわめて広範な概念を含んでおり、
このサイトでは全部を説明することはできません。
だからここでは、ルーチンをcallすることで何かの処理を行うのではなく、
「オブジェクトにメッセージを伝えて処理を行う」という発想が、
オブジェクト指向のコンセプトだという程度にとどめておきます。
|
インスタンス
|
インスタンスはオブジェクトの実体です。
たとえば Java言語で、「AS/400から今月の売り上げを取ってくる」
というオブジェクトを定義したとします。
ユーザーがそのJavaプログラムに、「売り上げデータを取ってこい」と指示すると、
コードに埋め込まれたオブジェクト定義からオブジェクトを生成します。
メモリ上にエリアを確保して初期化すると言ってもよいでしょう。
この生成されたオブジェクトを、そのオブジェクトのインスタンスと呼びます。
これは設計図と実際の建物の関係に似ています。
このオブジェクトの使い方をもう少具体的に見てみます。
まずメッセージを与える前にこのインスタンスに、
「どの商品の、何月の売り上げ」を持ってくればよいかを教えます。
AS/400のアドレスも必要です。
そして「さあ行ってこい」とメッセージを渡します。
子供に買い物メモと地図を渡して、お使いに行かせるようなものです。
|
マルチスレッド
|
スレッドというのは、オブジェクト指向と切り離せない仕組みです。
特にJavaを実装するなら不可欠の機能です。
前述の「売り上げデータを取ってくる」というオブジェクトで考えてみましょう。
あるルーチンがオブジェクトに行ってこいとメッセージを出します。
オブジェクトが任務をしている間に、
ルーチンは別の処理を実行したほうが効率の良い場合があるでしょう。
その場合、オブジェクトに別のスレッドを割り当てます（SUBMITJOB に似ています）。
このとき予想される問題は、一つの連続した処理を複数のジョブに割り当てて処理した場合に、
同期が正しくとれるかということです。
スレッド間の同期をとる仕組みがJavaには言語レベルで実装されています。
そのためJavaは「スレッドセーフ」であると言われています。
（ちなみにRPGやCOBOLはスレッドセーフではないので、IBMのドキュメントに、
複数のスレッドで使用しないようにと書かれています。）
|
パッケージ
|
Javaの保守性の高さや再利用性の高さは、
すなわち「オブジェクトの使いまわし」に尽きます。
この意味で生産性の高さは、洗練された共通サブルーチン
（日付チェックサブルーチン等）の使いまわしのメリットと全く同じです。
パッケージとは再利用可能なオブジェクト定義が文字どおりパッケージされたものです。
その利用の仕方は、あえて説明するなら。何かの機能を外サブにするのではなく、
/COPYメンバーにしてソースに組み込むようなものです。
|
バイトコード
|
Javaのソースコードはコンパイルされた時点で、
AS/400で言うプログラムオブジェクトにはならず
（つまりDOS/Windowsでいう.EXEファイルにはならず）
バイトコードという形式に翻訳されます。
このバイトコードがJVM（Java Virtual Machine）に渡され、実行されるわけです。
いわゆるインタープリタです。
バイトコードはどのような機種であれ、JVMが搭載されているマシンであれば、
何でも（たとえ電子レンジであろうが）実行可能です。
もちろんJVM自体は各マシンに合わせて別々に作成してあります。
実際にはAS/400ではJavaをプログラムオブジェクトにコンパイルすることも可能です。
Windowsの処理系でもJavaをEXEファイルにしてしまうコンパイラもあります。
いずれもインタープリタの処理の遅さを解決する為の手段です。
またバイトコードという呼び方は、
各インストラクション（CPUに対する実行単位）が１バイト単位で表現されることに由来します。
|
アプレット／サーブレット
|
アプレットは、サーバーからローカル端末にダウンロードされて
ブラウザの中で実行されるバイトコードです。
前述したとおりHTMLは基本的に静的なものなので、
その限界を超えようと努力した結果と言えます。
ローカル端子があまり勝手な動作を行わないように、
実行可能な機能に種々制限が課せられています。
Javaが登場した頃は、「Javaとはホームページを華やかにするアプレット」
のような捉え方をされていましたが、今ではむしろ、
より本格的なプログラム言語として認識されています。（よね？）
ちなみにサーブレットはサーバーで動くバイトコードのことです。
|
Javaスクリプト
|
|
JavaやNet.Dataは、サーバーで解釈されるHTMLに埋め込まれたマクロですが、
Javaスクリプトはクライアントのブラウザで解釈されるマクロです。
バイトコードではありません。
似たような機能でマイクロソフト社が提唱するVBスクリプトがあります。
|
JSP
|
|
Javaスクリプトとは反対に、サーバー側で解釈されるマクロのです。
HTML自体を動的に変化させることが可能になります。
|
ガーベッジコレクション
|
インスタンスにの項で、インスタンスとは「メモリ上にエリアを確保して初期化するもの」
と表現しましたが、それでは使い終わったインスタンスはどうなるのでしょうか。
実はC++といった言語では、インスタンスを作り出したプログラム自身が
そのインスタンスを削除してメモリを開放しない限りなくなりません。
マシンを再起動するまでメモリを占有し続けます。
メモリを占有し続けるのはオブジェクトに限りませんが、
とにかくメモリの解放を怠ったプログラムがあると、
後から実行されるプログラムが使用できるメモリ空間はどんどん狭くなっていきます。
これをメモリリークといいます。
多くのPCアプリケーションでメモリリークが発生しています。
（OS自体がメモリリークを起こすものさえあるそうです。）
Javaではこうした自体を避けるために、JVMがメモリを監視し、
不要となったメモリ空間を自動的に解放する機能を実装しています。
これがガーベッジコレクションです。
|
実装
|
この言葉は開発言語レベルでは、「定義と実装」といった感じで使います。
たとえばRPGで、
| |
| PARM01 |
PLIST |
|
|
|
| |
PARM |
|
ARE |
|
| |
PARM |
|
KORE |
|
| |
CALL |
"SAMPLE" |
PARM01 |
|
| |
のようなルーチンを書き、コンパイルするとプログラムができます。
その時点では"SAMPLE"というプログラムが存在している必要はありません。
これが「定義」です。そして実際に"SAMPLE"というプログラムを作成することが、
「実装」すつということです。
一方、あるプログラムやオブジェクトが何々の機能を持っている、
ということを意味する場合に「何々を実装している」という文脈で使うこともあります。
|
ディレクトリ構成
|
|
IFSで本格的にAS/400にも導入されました。
AS/400以外のマシンからAS/400へFTP接続すると、
ライブラリがあたかもディレクトリであるかのように見えます。
またAS/400のライブラリリストと同様の考えがパスのリスト
（後述の環境変数に指定する）で実現されています。
AS/400のCURLIBに相当するものは、ワーキングディレクトリと言います。
|
ポート
|
|
UNIXでのポートは、受信したパケット／コマンドを
どのサーバーにつなぐかの識別番号を意味します。
よく使われるポートは「ウェルノウンポート」として実質的に予約されています。
たとえば、HTTPの80、TELNETの23などです。
|
デーモン
|
|
AS/400では、OSが使用しているサブシステムの中で動いている
バッチジョブと同じものだと考えてください。
OSと協調してサービスを提供する機能です。
|
シェル
|
|
コマンドインタープリタです。
AS/400ではCALL QCMDで現れる画面に相当します。
ただUNIXの場合は複数のシェルの実装があり、
マクロが使用できます。
|
カーネル
|
|
UNIXの核になる部分です。
システムの構成を変えると（新しいデバイスを追加したりすると）
カーネルをリコンパイルします。
|
標準入力／出力
|
|
UNIXでは標準入力はキーボード、標準出力はディスプレイです。
しかしAS/400でRPGをCGIとして利用すると、
結果が標準出力に出力されると記述されています。
おそらく標準出力からリダイレクトされているのでしょう。
リダイレクトというのは、たとえば長さ132バイトの物理ファイルを作成して、
そのファイルでQSYSPRTにOVRDBFし、RPGのプログラムをコンパイルすると、
その物理ファイルにコンパイルリストが書き込まれる、
といったようなことを実現する機構です。
|
環境変数
|
|
SYSVALに似ています。
稼動しているすべてのジョブから参照できる変数です。
SYSVALと違うのは、独自の変数を設定できることです。
|
