キューイングプログラミング

WEBみたいなイベントドリブンのアプリケーション開発は、そろそろ
FlashとかのUIな人たちにシステムエンジニアがやっつけられるので

もっとビジネスよりな、キューイングされた情報を元にバッチ処理
行うって言う、古来よりな物に考えてみた。


基本的に、メール送信処理とか、日時バッチとか
キューイング処理ってのは、そこそこマトモなアプリケーションの
バックエンドでは、何十本も走っている処理で

ビジネスよりな機能が多い。


ただ、キレイな実装と管理手法って無い様な気がする。
これをキレイに纏め上げれたら、システムが、スッキリする。
また、システムトラブルによる損失の可能性が減り
ビジネスのシステムを起因としたリスクを減らせる


とりあえず、適当に実装ネタ

CREATE SEQUENCE process_queuing_seq; 
CREATE TABLE process_queuing_tbl
(
    id int primary key not null default nextval('process_queuing_seq'),
    action int not null,
    data text not null,
    processed_at timestamp not null,
    created_at timestamp not null default current_timestamp
);
  • アクションの管理
    • id ベースでアクションをコンテナで管理し、処理を委譲する
  • キューイングされたデータの管理
  • イベントの管理
    • 処理開始時間で管理


アクションの実装は、在るインタフェースを実装したクラス


多分、WEBでも、バッチ処理でも大別すれば、イベントがトリガとなって
ナニカを行うって事だから

アクション(process)のインタフェースを実装した処理って形で
全てに対応可能な形で抽象化可能だと思う


ただし、バッチ処理とWEBの処理だと、行った処理の後の処理が
HTMLを返すのか、ログを出力するのか等で違う


アクションではインタフェース化がムリ。


アクションの中身は、Linux的なプロセスになる
パイプで繋げるってイメージは、実装しにくい

DTO(DataTransferObject)による実装


プロセスをつないで、欲しい結果を作り出す
各レイヤが、DTOにより祖結合化


DOA的な実装形態


データ重要!



でも、結局上記の様な事って、正直今更感爆発な
まともなシステム開発では、すでに行われてきている事何だろうけれどもネ


ただ、最近のWEBベンチャーって技術力無いからねぇ…
正直、まともな技術者が居ない。


システム業界全般が、まともになるには
まともなシステムで業界が回る事だけれども


バグバグな、変なシステム、ドキュメント無しで
回っている業務が多いのも事実だ。