3

たとえば、在庫管理システム (IMS) と注文管理システム (OMS) の 2 つの別個のシステムを備えた単純な e コマース システムがあるとします。IMS が在庫に関する情報 (getItem、getItemQuantities など) を提供し、OMS が注文サービス (startOrder、addItemToOrder、finalizeOrder など) を提供するとします。

これら 2 つのシステムは、異なるバックエンドを使用する Web サービスとして実装されます。OMS では、次のような単純化されたモデルを想定します。

public class Order {
    private int orderId;
    private List LineItem;
    ...
}

public class LineItem {
    private int orderId;
    private int itemId;
    private int quantity;
    private int subTotal;
    ....
}

IMS では、次のようなモデルを想定します。

public class Category {
    private int catId;
    private List Item;
    ...
}

public class Item {
    private int itemId;
    .... (other attributes)
}

上記を実装するための単純な db テーブル構造を簡単に理解できます。

1 つの使用例として、注文にアイテムを追加するクライアントを考えてみましょう。この要求では、OMS がいくつかのサービス/データベース呼び出しを行う必要があります。

  1. orderId の検証 (オプション、この責任をデータベースに渡すことができます)。
  2. 渡された itemId が存在することを検証するための IMS の呼び出し (diff DB のために必要)
  3. IMS を呼び出して、渡された数量に対して在庫を検証します (diff DB のために必要)
  4. テーブルへの新しいレコードの挿入 (必須)

これはパフォーマンスの観点から理にかなっていますか? もっと良い方法を考えられますか？

[編集]:フォローアップとして、ユーザーが OMS に注文の詳細を要求した場合、orderId と、それぞれ itemId、quantity、および subTotal を含む orderLineItems のリストのみを返すことができます。クライアントは、アイテムの名前と説明も実際に必要としています。(IMS を介して) クライアントに名前/説明を取得する責任はありますか、それとも OMS がこれを担当しますか?

4

6 に答える 6

1

SOA のことはしばらく忘れてください。

2 つの独立したシステムと、それらの両方に一貫した更新を必要とする少なくとも 1 つの共通操作があります。

在庫を確認するだけでなく、在庫を減らすことも考慮する必要があります。おそらく、注文明細行の追加が機能する場合にのみ正しいでしょう。

その一貫性をどのように確保しますか？私たちはあらゆる種類のアプローチ (2PC トランザクション、レコードの予約、補償トランザクション、またはバッチ照合による楽観的な作業) を考案できますが、私の見解では、SOA であろうとなかろうと、Web サービスであろうとなかろうと、まだこれらの問題を解決する必要があります。

明らかに、効率のために、必要な機能を提供するために必要なシステムの部分間の通信の数を減らしたいと考えています。したがって、「チェック アンド ドゥ」のパターンが提案されています。ただし、そのようなパターンは、少なくとも生の形では、障害パスに対処できない傾向があります。

いくつかの短絡を考え出すのが最善かもしれません。たとえば、注文ラインが追加されたときに実際に在庫を確認することはありません。（おそらくUIはすでに在庫を表示していたので、比較的最近のチェックはすでに行われています）代わりに、最終的に注文が行われたときに在庫を確認し、ユーザーに「できませんでした」または「待つ必要があるかもしれません」と伝えます1 ～ 2 週間ほどお待ちください。続行しますか。」

狡猾な方法で、多くの操作で、1 つのサービス呼び出しに対して 1 つのバックエンド システムのみを更新することができます。

于 2009-10-16T16:27:02.850 に答える
0

これは、1 回のサービス呼び出しで実行でき、ストアド プロシージャに対して 1 回のデータベース呼び出しを行うことができます。

于 2009-09-11T00:47:32.597 に答える
0

これは SOA に関する質問であるため、なぜアプリケーションと Web サービスの間にこのような強い依存関係を作成しているのかに興味があります。

ESB を使用しない理由はありません。注文情報を使用して ESB を呼び出すだけで、エラーや注文番号など、必要なものが返されるオープンソースのものがいくつかあります。

ESB のルールに従って処理されるため、他のすべてを抽象化します。

私が実験している ESB の 1 つ: https://open-esb.dev.java.net/

利点は、アプリケーションのコードを変更することなく、Web サービスやデータベースを交換したり、新しいルールを追加したりできることです。

これは、アプリケーションが分散されている場合に非常に役立ちます。

理想的には、ある程度のサービス品質要件を設定して、VIP からの注文が通常の人よりも早く処理され、新しいユーザーが最初の 2 回はさらに早く処理されて、システムの速度を確認できるようにすることができます。

ESB を追加するとパフォーマンスが低下しますが、ESB Web サービスの wsdl 以外の変更から隔離されるため、結合が緩くなるなどの利点があります。

于 2009-09-22T00:10:29.217 に答える
0

パフォーマンスの観点から、私はこれをしたでしょう

orderIdの検証サービスです。

渡された itemId の存在を検証し、渡された数量に対して在庫を検証する ValidatePlaceInDetails と呼ばれるサービス

テーブルに新しいレコードを挿入するサービス。

2 と 3 を統合することで、サービス コールを削減しました。

于 2009-09-13T02:56:59.877 に答える
0

あなたが説明したシステムには、それらが分離されているという事実を除けば、問題はありません。

しかし、これを別の方法で行うことはできず、パフォーマンスが心配な場合は、何らかのキャッシュを実装して、データベース ルックアップの数を減らし、注文の内容全体をキャッシュに保存することもできます。キャッシングの問題は、注文の送信時に、注文されたアイテムが実際に在庫にあるかどうかを確認するか、代わりに利用できないアイテムを単にドロップする、少し高価なデータベース操作を実行する必要がある場合です。

考えられるキャッシング ソリューションについては、memcachedをご覧ください。

于 2009-09-16T19:06:05.390 に答える
0

商品Xが実際に在庫があるかどうかを確認するリクエストをIMSに1回だけ行います。有効なアイテムでない場合、IMS は無効なアイテムを要求したことを示す結果コードを返す必要があります。このようにして、IMS への往復を節約できます。リクエストした数のアイテムが在庫にない場合は、それを示す別の結果コードが返されると思います。

于 2009-10-01T07:03:53.480 に答える