ステータスのチェック †
要するに †
- 長い取引では進行状況をチェックしたくなる。こんなのがつかえる。
- Publish-Subscribe Channelで盗聴
- Wire Tapを追加して盗聴
- Message Storeにクエリ
- Process Managerで管理
- SOAあるで
細かいこと †
- メッセージチャネルでシステムをつなぐとはいえ、注文を完了させるにはやや時間がかかる。
- たとえば、商品が在庫切れで在庫管理システムが商品到着まで在庫チェックメッセージを返さないかもしれない。
- コンポーネントのペースでやり取りできる、非同期システムの利点の1つ
- 在庫管理システムがメッセージをとどめている間、決済システムは顧客の信用状況を審査できる
- 両方が終われば、AggregatorがValidated Orderメッセージを送信して出荷と請求をはじめる
- ビジネスプロセスが長時間に渡る場合には、顧客も管理者も特定の注文がどのような状態にあるのか知りたくなることが多い。たとえばある商品が在庫切れとなっている場合、顧客は在庫にある商品ですますかもしれない。
- また、顧客が商品を受け取っていない場合、商品が配送中であるとか、倉庫で遅れているなど伝えられると良いだろう。
- 今の設計で、ある注文の状態を追跡するのは簡単ではない。関連するメッセージ群がさまざまなシステムを通過していく。各ステップで注文ステータスを確認するには、この注文に関連した最新のメッセージを知る必要がある。
- Publish-Subscribe Channelの利点の一つは、メッセージの流れを乱すことなく購読者を追加できること。この特性を使えば、新規や検証済みの注文を盗みぎきしてMessage Storeに格納できる。これに照会をかければいい。
- Point-Point Channelを使う状況では、こうはいかないが、Wire Tapを追加することで同じことができる。
- Message Storeへの格納には、大きな利点がもう一つある。もとの設計では、処理をつづけるには外から来たデータをすべて運んでいかなくてはいけない。例えば、Validate Customer Standingメッセージは、必要なのが顧客IDだけだったとしてもすべての種類の顧客データを運ばなくてはいけない。これは、結果メッセージが元の注文メッセージからのデータをすべて引き継がなくてはいけないから。Message Storeを使えば、これは不要になる。
- こうした機能はClaim Checkという。あとで使うためにデータをチェックインするからCheck。しかし、このアプローチはメッセージングに比べると信頼性に欠ける。
- こうしてMessage Storeを使うと、プロセス内のメッセージ進行状況がわかるようになる。このデータを使えば、次に必要なステップを動的に決めることができる。独立したAggregatorコンポーネントを使わなくても、Message Storeでできるようになる。Message StoreはProcess Managerに近くなる。
- Process Managerはシステムを流れるメッセージフローを管理する中心的なコンポーネント。
- メッセージ間のデータを格納する（プロセスインスタンス）
- 進行状況を追跡し、次のステップを決める（プロセステンプレート）
- このアーキテクチャーでは、個々の独立したシステムが、他のコンポーネントからサービスとしてアクセス可能な共有されたビジネス機能へと変化する。最良が促進され、メンテナンスが単純化される。
- 新しいアーキテクチャでは、すべてのサービスが共通のサービスバスに接続され、他のコンポーネントから呼び出せるようになる。中央サービスリポジトリからサービスを検索する機構を追加すれば、SOAにできる。SOAに参加するには、個々のサービスは追加機能が必要になる。インターフェイス契約が必要。request-replyサービスは、Return Addressをサポートしなくてはいけない。Return Addressを使えば、呼び出し元が、返信メッセージのチャネルを指定できるようになる。これは、サービスを異なる状況で再利用するために重要。
- Process Managerはプロセスインスタンスの格納に永続ストアを使う。Webから照会できるよう、メッセージをProcess Managerか注文データベースに送る。が、ステータスのチェックは同期プロセス（顧客はすぐに応答がほしい）。Webインターフェースはカスタムアプリケーションなので、注文ステータスを確認するためには、注文データベースを照会することにする。このShared Databaseの形態は、単純で効果的なやり方。常に最新の状況を顧客に見せることができる。WebがDBに密結合するという欠点はある。
- システムをサービスとして公開する際に難しいのは、既存システムの多くがReturn Addressを念頭に置いて設計されていない点。Smart Proxyでラップすればいい。Smart Proxyが要求と応答をインターセプトしてうまいことできる。Smart Proxyはリクエストのデータをとっておいて、レスポンスの処理に使える。外部サービスのQoSの追跡にも有用。
アドレスを変更する †
要するに †
- SOA化したシステムで請求先・出荷先等多数の住所を扱う方法はだいたい2つ、今回は既存APの制約から2つ目が良い
- すべての新規注文メッセージに住所を含める
- 住所データを個々のシステムに保持し、変更は複製する
細かいこと †
- WGRUS多数のアドレスを扱う必要がある。請求書は顧客の請求先住所に送る必要があるし、商品は出荷先住所に送らなくてはいけない。余分な手運用をなくすために、顧客がWebインターフェースを通じてこうした住所をすべて管理できるようにしたい。
- 請求・出荷システム向けに正しい請求先・出荷先住所を得るためには、基本的なやり方が２つある。
- すべての新規注文メッセージに住所を含める
- 住所データを個々のシステムに保持し、変更は複製する
- 1つ目のやり方なら、既存の統合チャネルを使える。欠点としては、運ぶべきデータが増えること。このやり方で実装する場合、請求や出荷システムはパッケージシステムで、統合を念頭において設計されていないことを考慮する必要がある。メッセージ内の住所は使われず、自身で格納した住所を使うことが多い。請求システム（出荷システムでも）で2つ機能を動かす必要がある。
- 1つは、住所の更新。住所更新後に請求メッセージを送る必要がある。Process Managerコンポーネントがある。（2つめ？）Channel Adapterがメッセージを各アプリケーション用のフォーマットに変更しなくてはならないことも注意。Process Manager向けの変換も必要だが、Process Manager内部で変換するとProcess Managerが各アプリケーションの複雑なフォーマットに影響されるため、外部のMessage Translatorを作りたい。
- 2つ目のやり方は、住所変更を広めるためにデータを複製すること。Webインタフェースから住所が変更されたら、Publish-Subscribe Channelで関連する前システムに伝搬させる。各システムは住所を更新し、注文メッセージが届いた際にはこの住所を使う。メッセージトラフィックを減らせる。システム間の結合度もさげられる。
- 複数の住所があるので、正しい種類の住所各システムに格納されるようにしなくてはいけない。変更されたのが請求先住所なら、出荷システムには送らないようにしなくてはいけない。Message Filtersが使える。
- Address Changeメッセージを各アプリケーション用フォーマットに変換するには、Message Translatorsを使う。Webインタフェース向けには必要ない。Canonical Data ModelをWebインタフェースAPと同じフォーマットにしているから。住所変更に他の手段を取りたい場合に柔軟性が制限されるかもしれないが、今のところは問題ない。住所変更にはDatabase用Channel Adapterを使う。
- どちらを使うか、どうやって決めるか？今の状況なら、メッセージトラフィックを気にする必要はあまりない。1日に数百取引程度。着目すべきはアプリケーションの内部構造。住所を直接DBには追加できず、ビジネスレイヤーから追加することになる。この場合、アプリケーションでは検証とDB更新が必要になる。システムは、アドレス変更のたびにe-mailを送信する。新規注文のたびにこうなるのはまずい。こうした状況を考えると、2つ目のやり方が良さそう。
- 一般的に、Change AddressやPlace Orderのようなきれいに定義され、自身に閉じているようなビジネスアクションが好まれる。ビジネスプロセス上のオーケストレーションで柔軟性が高いから。粒度と関連するトレードオフの問題につながる。細粒度のインターフェースでは、多数のリモート呼び出しやメッセージ送信によってシステムが遅くなる。密結合にもつながる。（個々のアドレスフィールドがインタフェースになっている場合を想像）
粗粒度インタフェースではこうならないが、柔軟性が失われる。（請求と住所変更が同じ場合を想像）
場合によりけり。
