0

シナリオ: CRM システムとアプリがあります。CRM システムで新しい注文が作成されると、myApp は何らかの処理 (注文用のプロジェクト ルームの作成) を行い、何か (プロジェクト ルームの URL) を CRM システムに書き戻す必要があります。

したがって、ポイントツーポイント統合を使用してこれを簡単に実装できます。myApp はサービスをホストし、処理が終了すると CRM のサービスを呼び出します。

質問: サービス バス (追加のコード、追加の保守) を追加するという余分な作業を行う必要がありますか、それとも適切なケースではありませんか? 現在、同社にはサービス バスがなく、統合戦略もまったくありません。

上記の質問に「はい」の場合 (私はそれを期待しています)、たとえば nServiceBus または rhino-service-bus ((どちらも試したことがない) など) をスコープ? 他の esb に関する推奨事項、または私が読むことができるケース スタディはありますか?

助けてくれてありがとう

よろしく

ラルシ

4

3 に答える 3

0

SOA の主要な側面を区別する必要があります

1 つはサービスです。これは主に設計上の問題です。一言で言えば、サービスはコモディティであるべきであり、あなたが計画している特定のクライアントのためにカスタムメイドされるべきではない..

2 番目の側面はインフラストラクチャです。これには、ESB が含まれる場合があります。

単一のサービスまたは少数のサービスがある場合は、単純な Web サービス (ESB やその他のインフラストラクチャなし) を使用して、SOA のすべての利点を得ることができます。プロジェクトが大きくなった場合、ESB を追加することは、今追加するよりもそれほど難しくありません。

一方、変更が難しい既存のクライアントがある場合、クライアントを追加するときにサービスのインターフェイスを再設計するのは難しいプロセスです。

于 2011-04-21T08:37:08.740 に答える
0

SOA アーキテクチャへの移行を検討している場合、通信に関する決定を下す前に最初に考慮すべきことは、サービスの境界です。アプリが特定のビジネス機能の実装を所有している場合、つまりそれがビジネス ロジックを指定し、その機能の信頼できるデータ ソースである場合、それは独自のサービスである必要があります。ただし、アプリが CRM システムにヘルパー機能を提供するだけの場合、SOA の観点から言えば、アプリと CRM は両方とも同じサービスの一部になります。

この短い投稿を読むことから始めます: http://fafach.wordpress.com/2011/04/20/soa-what-is-a-service/

次に、この優れた SOA 入門ビデオをチェックしてください: http://www.nservicebus.com/ArchitecturalPrinciples.aspx

于 2011-04-20T14:56:01.797 に答える
0

問題は、それが他のシステムが気にする可能性のあるビジネス イベントであるかどうかです。新規顧客の場合、おそらくマーケティング システムが電子メールを送信し、注文システムが注文の処理を開始します。

それが起こっていることがわかる場合は、nservicebus を使用してプッシュ pub/sub モデル (http://www.eaipatterns.com/ObserverJmsExample.html) を使用します。あなたがしなければならないのは、関心のある各アプリケーションの新しい顧客メッセージをリッスンするハンドラーを作成し、そのメソッドで自分のことをすることだけです。

また....あなたがやっていることはSOAへの移行ですが、SOAになるにはさらにいくつかのことが必要です。SOA はアーキテクチャ哲学です。私たちが話しているパブ/サブは、MoM を使用することです。

于 2011-04-15T23:04:40.193 に答える