0

サービス構成は、SOA の基本的な部分です。サービス インベントリによって提供されるすべての機能は、必要に応じて、そのインベントリ内の他のサービスを利用して、小さなコンポーネント パーツから実行するタスクを構築することが期待されます。ただし、これはすべてアーキテクチャ レベルのものです。実装レベルでは、この構成はどのように行われるのでしょうか?

この状況を考えてみましょう。/process-request「実際の」リソースを生成するために大きなファイルを非同期的に処理することに関連する追加のリソースを管理するリソースを投稿することを含む「タスク サービス」があります。最終的な「実際の」リソースを PartsInventory と呼びましょう。そのため、PartsInventory の URL と名前を/process-requestサービスに提供すると、PartsInventory の「プレースホルダー」が作成され、URL にある大量の csv ファイルを実際の PartsInventory に変換する非同期 ETL が開始されます。この非同期ジョブが失敗すると、プレースホルダーが削除され、/process-requestサービスへのクエリに失敗が反映されます。成功すれば、/process-request

さて、コードの観点からする/process-requestと、 と PartsInventoryの間の相互作用の実装はどのように 見えるでしょうか? 公開されたサービスにリクエストを POST しています/parts-inventory か、それとも ORM オブジェクトを呼び出してプレースホルダーを作成していますか? 前者の場合、私は公開された契約を順守しており、自分のサービスの消費者として振舞っています。これはコンポーザビリティの原則に適合しているように見えますが、同じコードベース内からこのようにやり取りするのは非常に厄介です。一方、後者は、/process-requestハンドラーが PartsInventory プレースホルダーを独自に作成する方法を知っていることを前提としているため、それ自体がぎこちなく感じられます。3 番目のオプションは、PartsInventory オブジェクトに特殊な静的ファクトリ メソッドを作成することPartsInventory.create_placeholder()です。 /process-requestコードは少なくとも、PartsInventory オブジェクトのコンストラクターの依存関係を認識していません。ただし、これでも作成は 2 つの場所に分けられます。

これに遭遇しましたか？この質問に対する標準的な「正しい答え」はありますか?

4

1 に答える 1

0

サービスエンドポイント（この場合、さまざまなサービスによって公開されるURL）とサービスを区別する必要があります。サービスは基本的に、（メッセージで構成される）コントラクトを配信する1つ以上のエンドポイントを公開する明確に定義された境界を持つコンポーネントです。

サービス内で行われた呼び出しは、サービスインターフェイスを通過する必要はありません。サービス境界を越える呼び出しは、サービスインターフェイスを通過する必要があります。

あなたの場合の質問は、同じサービスのプロセス要求とPartsInventoryの異なる側面であるかどうかです。あなたのサービスの詳細から、それらがそうであるかどうかはわかりませんが、それらが異なるサービスとして本当に意味がある場合は、サービスインターフェースを経由する必要があります。

于 2012-11-09T17:39:32.903 に答える