1

以前は、Web アプリケーションで CRUD 操作 (またはその他のタスク) が (UI から) 行われたときに、WCF を使用して次のような単純なパターンを使用していました。

GetUserByIDResponse response = new UserServiceClientProxy().GetByID(new GetUserByIDRequest() { UserID = UserID });

if (response.success) {
    //response.data - Do something!
} else {
    //Show error response.message
}

ただし、私の調査によると、Azure プラットフォームから実行することを意図してデプロイし、クラウド サービスモデルを使用する場合、最善のアプローチは、このサービス バスの概念を次のようなコードで使用することです。

QueueClient requestClient = CreateQueueClient("RequestQueueName"); 
QueueClient responseClient = CreateQueueClient("ResponseQueueName");

MessageSession receiver = responseClient.AcceptMessageSession(ReplyToSessionId); 
//blah blah

通信するとき、すべてのサービス タイプ操作がサービス バスを介して処理されるようになったという私の仮定は正しいですか? それとも、アプリケーションの特定の側面でこの手法を使用することだけを検討しますか?

「サービス バスは、Azure プラットフォーム用に設計された SOA (サービス指向アーキテクチャ) の一般的な代替品ですか?」

うまくいけば、それは理にかなっています。

4

2 に答える 2

3

「サービス バスは、Azure プラットフォーム用に設計された SOA (サービス指向アーキテクチャ) の一般的な代替品ですか?」

絶対にありません！

Web アプリケーションで WCF を使用して現在行っていることは、クラウド サービスでもまったく同じことができます。心配する必要はありません。

Azure Service Bus Queues と Azure Storage Queues は、(私の見解では) アプリケーション ブロック/モジュールを分離するためのメカニズムです。モジュール A (または Web アプリケーション) があり、モジュール B によって完了するために、長時間実行され、CPU を集中的に使用するタスクを送信する必要があるとします。ただし、モジュール B は、夜間のみオン (使用可能) になるように設計されています。モジュール A は安全にタスク メッセージをキューに送信し、それを忘れることができます。モジュール B は後で「起動」し、タスク メッセージがないかキューをチェックします。タスクを 1 つずつ処理し (または並行して、今はそれほど重要ではありません)、結果を別のキューまたは他の形式の通知に報告できます。

Azure Service Bus Queues をさらに深く掘り下げると、彼らはPublish-Subscribeパターンを理解し、実装します。つまり、パブリッシャー (メッセージをキューに送信する) は 1 つですが、サブスクライバー (キューから読み取る) は複数ある可能性があります。さらに、各サブスクライバーにフィルターを適用できます。

さらに一歩進んで、ASB は Enterprise Service Bus やクラウドの BizTalk に似ています ( BizTalkに似ていると言っているわけではありません)。

要約すれば：

現在のセットアップで使用しているように、Windows Azure クラウド サービスで WCF を使用します。Azure Service Bus は WCF の "代替" ではありません。それには別の目的があります。

アップデート

私は言うでしょうuse queues when you want to *decouple* system components。デカップリングとは、モジュール A (呼び出し側)がモジュール B (エグゼキューター) の可用性に依存しないことを意味します。

WCF サービスの場合、モジュール A (呼び出し元) とモジュール B (WCF) の間は非常に緊密に結合されています。WCF サービスが利用できない場合、呼び出し元はすぐに失敗します。

あなたの特定のケースでは、UI 呼び出しを処理する WCF サービスがある場合、WCF サービスに大きく依存することは許容されます。特に、UI 自体として Web アプリケーションで WCF サービスをホストする場合。

しかし、シナリオでは、リモート エグゼキューター (モジュール B) にタスクを送信する必要があるデスクトップ アプリケーション (モジュール A) があり、このタスクは確実に送信する必要があり、エグゼキューターの可用性に関係なく、いくつかのキューを使用します。

于 2013-04-17T21:24:48.607 に答える
0

いいえ; どちらも SOA ではないため、WCF も ASB も SOA の代わりにはなりません。

SOA はサービスを意味します。ASB はメッセージ ブローカーであり、実際のサービス バスの最小限の部分です。WCF は RPC フレームワークです。

サービスとは、相互にリンクするために使用するソフトウェアに関係なく、独立して実行されるプログラムです。多くの場合、それらはキューと一緒にリンクされており、他のサービスをルーティングまたはルックアップするための ID、機能も必要です。多くの場合、他のサービスをリソースとして消費します。

WCFに関しては、SOAをそのように行っている場合、基本的にアーキテクチャを台無しにしています。ASB を使用する場合は、MassTransit-AzureServiceBus をお勧めします。MassTransit-AzureServiceBus は、サービス バスではない Azure Service Bus が必要とする多くの厄介なルーティング ロジック、再試行ロジック、インプロセス キューイング、非同期呼び出し、およびメッセージ処理ロジックを処理します。実装しません。

于 2013-04-17T20:39:32.607 に答える