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