EIP / Process Manager

Process Manager †

サマリ †

• 最も動的で中央集権的なルーティングをしたい場合は、Process Managerに辿り着く。最も汎用性が高い。EAIからワークフローやプロセスモデリングへのエントリポイント。

詳細 †

• Routing Slipの2つの前提は、処理ステップのシーケンスが事前に決まっていることと、そのシーケンスが線形であること。
• しかし、その前提が満たされないことは多い。

複数の処理ステップを通ってメッセージをルーティングさせたい場合に、そのステップが設計時に決まらなかったり、シーケンシャルでなかったりしたときはどうするか？

• Pipes and Filtersアーキテクチャスタイルを活用してContent-Based Routerを駆使すると、ルーティングロジックがコンポーネント間に散らばってしまう。Routing Slipだと制御を中央にまとめられるが、柔軟性が犠牲になる。
• 毎回の処理後に中央コンポーネントに処理を返すことで、柔軟性とメンテナンス性を達成できる。中央コンポーネントが毎回、次に処理ステップに進むかを決定するが、そのために各処理コンポーネントが中央コンポーネントに十分な情報を提供しないといけないとすると、各処理コンポーネントが中央に依存してしまう構造になる。
• もし各処理コンポーネントを中央から分離したいなら、中央コンポーネント自身が何らかの「メモリ」を持ってシーケンスのどのステップまで来たかを分かるようにしなければいけない。

中心的な処理単位 Process Manager を置いて、シーケンスの状態を管理し、中間結果に基づき次の処理ステップを決定させよ。

• まず最初に、Process Managerはそれだけで一冊の本になるほど非常に広大なトピックなので、このパターンはあくまでワークフローやプロセスモデリングへの導入を示す概論でしかない。
• Process Managerはいわゆるハブ＆スポークパターンになる。Trigger Message -> Process Manager -> Proc A (1) -> Proc B (2) -> Proc C (3) の流れ。欠点は、Process Managerがパフォーマンスのボトルネックになりうること。
• Process Managerの汎用性は、強みでもあり弱みでもある。この章のルーティングパターンはすべてProcess Managerで解決できるが、それはやり過ぎ。真の設計上の問題から目を逸らさせてしまうし、パフォーマンス上のオーバーヘッドも大きい。

状態の管理 †

• Process Managerの主要機能の1つが、メッセージ間での状態管理。
  • プロセス実行の現在位置
  • 先行処理での中間結果（Process ManagerはClaim Checkの役割を果たす）

プロセスインスタンス †

• プロセス実行は長時間にわたることがあるので、並列実行を可能にするために、プロセスインスタンスの管理が必要になる。プロセスインスタンスは状態（現在の実行位置と関連データ）を持ち、一意なプロセスIDを持つ。
• プロセス定義（process definition）とプロセスインスタンを区別することが重要。オブジェクト指向言語のクラスとインスタンスの関係のようなもの。

相関性 †

• 複数のプロセスインスタンスが並行して実行されるので、どのメッセージがどのインスタンスに紐付くかを判定できる仕組みが必要。
• Correlation Identifierを使う。プロセスインスタンスが一意なプロセスIDを持っている場合は、そのプロセスIDをCorrelation Identifierに使える。

メッセージそのものによる状態保持 †

• 状態管理がProcess Managerの重要な機能。これまでのパターンでは、チャネルそのものが状態を表していたので状態管理が必要なかった。
• 特筆すべきは、EIPのメッセージフロー表記がUMLアクティビティ図によく似ていること。アクティビティ図は、Process Managerの振る舞いをモデリングするのによく使われる。
• 中央集権型のProcess Managerで行くか分散型のPipes and Filtersで行くか、というアーキテクチャ決定は、単純な Yes or No では決まらない。多くの場合、Process Managerは複数立てられ、それらが今度はPipes and Filtersアーキテクチャで通信しあう、という構成もありうる。
• Process Managerが明示的に状態管理をするのは、複雑な実装を要求するが、プロセスのレポーティングやデバッギングに優れているという面もある。すべての状態が中央にあるので、様々な状態のレポーティングやデバッギングが容易にできる。分散型では、すべてのチャネルを見なくてはならないので、非常に実現が大変。

プロセス定義の生成 †

• プロセス定義の表記法：
  • 多くの商用EAIツールはビジュアルなツールを提供している。UMLアクティビティ図に似た表記法で、最近まではそれを内部のプロプラなプロセス定義にして実行していた。
  • Webサービスによる標準化の流れ：MicrosoftのXLANG、IBMのWSFL -> BPEL4WS ＝ プロセスモデリングツールとProcess Managerエンジンの架け橋となる中間言語。
• プロセス定義のセマンティクス：
  • 基本要素はアクティビティ（タスク、アクション）
  • アクティビティ同士は、直列または並列（join、fork）に接続可能
  • fork = Publish-Subscribe Channel, join = Aggregator, branch = Content-Based Router
  • loopはbranchの特殊ケース

Process Managerと他のパターンとの比較 †

• Process Managerは単一障害点があるので、エンタープライズなDBを使って状態を永続化、冗長化する。
• Process Managerを並列化するのも一般的。プロセスインスタンスは互いに独立なので、並列化は容易。
• 並列化したProcess Managerが共有DBに状態を保持すれば、システムは十分堅牢になる。しかし、今度はDBがボトルネックになる。
• アーキテクトは、パフォーマンス、堅牢性、コスト、メンテナンス性のバランスをとる必要がある。

例：Loan Broker †

• 9章の融資ブローカー（Loan Broker）のサンプルでは、C#によるMSMQの実装と、TIBCOによる実装を示している。

例：Microsoft BizTalk? オーケストレーションマネージャ †

• ほとんどの商用EAIツールには、プロセス設計／実行の機能が含まれている。
• MicrosoftのBizTalk?では、Visual Studio .NETと統合されたOrchestration Designerツールを使ってプロセス定義を設計できる。
• 例では、注文メッセージを受け取って、2つの並列アクティビティ（在庫システムへのリクエストと与信管理システムへのリクエスト）を実行している。

担当者のつぶやき †

みんなの突っ込み †