- - PR -
バッチをオブジェクト指向で設計
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2004-02-27 17:07
ええと、Java Solutionでよいのですよね？＾＾；
枯れた仕組みを利用するなら、JMS準拠のMessageQueueで行うべきでしょうか？ 先の話になりますが、ワーカーであるサーバにジョブキューを監視させるのではなくて、 ジョブキューを所有するサーバが一定数のワーカースレッドを所有して、各スレッドが ワーカーのサーバに配信するような仕組みでよいなら、JDK1.5で簡単に作れるように なると思います。 コアAPIにjava.util.concurrent.ThreadPoolExecutorという、WorkerThreadパター ンを丸ごと実装したクラスが追加になっていますので。 | ||||
|
投稿日時: 2004-02-27 18:27
はにまるさん、こんばんは。 その例はバリバリオブジェクト指向で作れそうですよ。 用意するのは ■抽象クラス ・コントローラークラス（ジョブログ記述部、再実行の処理を実装しておく） ・入力クラス（受信部の処理を実装） ・出力クラス（送信部の処理を実装） ・処理クラス ・バックアップクラス ・エラー処理クラス（エラー通知の処理を実装） ■具象クラス □コントローラークラス ・外部インターフェース入力コントローラークラス（ファイル存在による自動稼動処理を実装） ・外部インタフェース出力コントローラークラス ・更新処理コントローラークラス □入力、処理、バックアップ、エラー処理クラス 必要なものを作成 実装は 外部インターフェース入力コントローラークラスは 入力、処理、バックアップの各クラスを生成し、その順に実行 外部インタフェース出力コントローラークラスは 処理、出力、バックアップの各クラスを生成し、その順に実行 更新処理コントローラークラスは 処理クラスを生成し実行 各コントローラークラスは実行中にエラーがあればエラー処理クラスを生成し実行。 あまり私も経験がないのでこれで良いかわかりませんが こんな感じになるのでは。 Template Methodパターンですね。 外部からの実行は具象コントローラークラスのmain()からになります。 修正があった場合は具象入力、処理、バックアップ、エラー処理クラスの どれかを直すだけでＯＫ。 この処理はフレームワークが既に存在すると考えて作りました。 上に書いた抽象クラスの上位クラスは型とインターフェースが規定されている。 上に書いた抽象クラスは具象クラスの共通部分を括りだした 共通クラス（手続き型で言えばいわゆる共通サブルーチンにあたる）です。 ですから汎用フレームワークは具体的な業務処理によらない抽象度での 共通化（どの業務処理でも必要な機能を括り出すべき）が必要です。 どの業務処理でも必要な機能って何？ というところが悩みどころ 
[ メッセージ編集済み 編集者: キラ 編集日時 2004-02-27 18:30 ] [ メッセージ編集済み 編集者: キラ 編集日時 2004-02-27 18:33 ] [ メッセージ編集済み 編集者: キラ 編集日時 2004-02-27 18:46 ] [ メッセージ編集済み 編集者: キラ 編集日時 2004-02-29 07:26 ] | ||||
|
投稿日時: 2004-02-29 03:58
わたしも生半可な知識ですが、フレームワークという言葉ではなくて、 いわゆる「汎用ミドル製品」という言葉で。 こういうことをするにはこの社のこのミドルを使うという定番があったような。 | ||||
|
投稿日時: 2004-02-29 08:11
バッチ処理のパフォーマンスにも絡んでくると思うのですが
バッチ処理につきもののソート処理の実装ってどうなんでしょ？ ファイルをソートしたい場合 (1)中間データベース利用 (2)市販の外部ソートユーティリティ使用 (3)Collections.sort()+Comparator (4)自分で１から書く！！ (5)その部分はscript言語(Perlなど)に任せる それぞれメリットデメリットはあると思いますが 個人的には件数が少なければ3で多ければ1かなと。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。