以前のブログで、産能大記号について、一つ一つみていくということで、「新しい帳票を用意する」に相当するものを、考えた。
そこでは、以下の２種類の考え方があって、
１つはＤＢに書き出せば本当はＯＫというもの
もう１つは、紙（帳票）に書き出すこと重要
というのがあると書き、このシリーズの前回では、帳票の場合を説明した。
帳票の場合は、
・帳票のサービスププログラムを用意し、データはＸＭＬで
→帳票のフォーマットはＸＭＬのタグから分かるようにする
・帳票サービスでは、データ処理はさせないで、そのサービスを呼び出すほうが、
データ加工を行い、ＸＭＬで転送する
ということを書いた。
今日は、前者の、「１つはＤＢに書き出せば本当はＯＫというもの」、つまりＤＢ書き出しについて
ＤＢ書き出しの場合、コミット、ロールバックのトランザクション処理をどこに置くか？という問題になる。仮に、トランザクション操作をクライアント側から発行できるようにするとなると、サーバーに対し、２フェーズコミットで実現するということになる。
しかし、このやり方、セキュアにして、確認をとってからコミットするというのは、通信が多くなると、時間がかかってくる（ネットワーク負荷がおおきい）。
とすると、このやり方より、１トランザクション分のデータをサーバーに送る形にして、サーバーのほうで、複数のテーブルに対してＤＢアクセスをしてもらったほうがいいということになる。
とすると、サーバー側には、２段階のモジュールができることになる。
・１つは、１トランザクション分を管理するサービスプログラム
→これを呼び出す
→このプログラムから、複数の「テーブルに対応するサービスプログラム」
を呼び出す。
・もう一つは、１テーブルに対応するサービスプログラム
ＥＪＢの世界では、前者がセッションＢＥＡＮ，後者がエンティティＢｅａｎとなり、
富士通ＩｎｔｅｒＳｔａｇｅの世界では、前者がＣＢＳ、後者がＣＢＭとなる。
ただし、「１トランザクション分を管理するサービスプログラム」処理は、固定的に決まっているものではない。
前のテーブルの結果を利用して、あとのテーブルの値を更新するなどということもある。
このため、クライアント側で１トランザクションの値を設定するときに、全ての値を設定できるわけでなく、「１トランザクション分を管理するサービスプログラム」の内部で、加減乗除その他をしてもらうことになる。
しかし、ここが、ユーザーにも分かって、確認が取れないと、おかしなプログラムが出来てしまったりする。ということで、恣意的に、このプログラムを書いてもらうというのでは困る。ある程度の規制が必要だ。
となると、仕様を、入力するツールがあって、そこから自動生成することになる。
その一方、「１テーブルに対応するサービスプログラム」というのは、Ｈｉｂｅｒｎａｔｅなどが存在するように、ある程度きまっている。そこで、この「１テーブルに対応するサービスプログラム」というのは、自動生成が可能である。
まとめると、
帳票の場合は、クライアント側でデータの値を設定するのに対し
ＤＢ更新の場合は、サーバー側で１トランザクション分の値設定の処理をさせる。
そのために、とくに、ここで恣意性をふくまないために、
仕様入力ツール、自動生成ツールが必要となる。
では、具体的に「仕様入力ツール、自動生成ツール」とは何か？という話については、長くなるし、まだ作っていないので、また今度ということにしよう。
アクセス
トータル
ランキング
