1

以前在我的 Web 应用程序中，当（从 UI）进行 CRUD 操作（或任何其他任务）时，我会使用如下简单的模式，利用 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 服务总线队列和 Azure 存储队列（在我看来）是用于解耦应用程序块/模块的机制。假设您有一个模块 A（或一个 Web 应用程序），它需要发送一些长时间运行的重 CPU 密集型任务以由模块 B 完成。但是，模块 B 被设计为仅在夜间打开（可用）。模块 A 可以安全地将任务消息发送到队列并忘记它。模块 B 稍后将“唤醒”并检查队列中是否有任何任务消息。将一个一个地处理任务（或并行，现在并不重要）并且可以将结果报告给另一个队列，或其他形式的通知。

深入了解 Azure 服务总线队列，他们了解并实现了该Publish-Subscribe模式。这意味着您可能有一个发布者（将消息发送到队列），但有多个订阅者（从队列中读取）。甚至更多 - 您可以为每个订阅者应用过滤器。

更进一步，ASB 更像是企业服务总线，或者云中的 BizTalk（我不是说它是，我说它类似于BizTalk）。

总之：

在当前设置中使用 Windows Azure 云服务中的 WCF。Azure 服务总线不是 WCF 的“替代品”。它还有另一个目的。

更新

我会说use queues when you want to *decouple* system components。解耦意味着模块 A（调用者）不依赖于模块 B（执行者）的可用性。

在 WCF 服务的情况下，我们在模块 A（调用者）和模块 B（WCF）之间有非常紧密的耦合。如果 WCF 服务不可用，则调用者会立即失败。

在您的特定情况下，如果您有 WCF 服务来处理 UI 调用，那么严重依赖 WCF 服务是可以接受的。尤其是在您将 Web 应用程序中的 WCF 服务作为 UI 本身托管的情况下。

但是在这种情况下，我有一个桌面应用程序（模块 A），它必须将任务发送到某个远程执行器（模块 B），并且该任务需要可靠地发送，并且无论执行器可用性如何，我都会使用一些队列。

于 2013-04-17T21:24:48.607 回答
0

不; WCF 和 ASB 都不是 SOA 的替代品，因为 SOA 都不是。

SOA 意味着服务。ASB 是消息代理和实际服务总线的最小部分。WCF 是一个 RPC 框架。

服务是独立运行的程序，无论您使用什么软件将它们链接在一起。它们通常与队列链接在一​​起，并且它们还需要一些身份、路由或查找其他服务的能力。他们经常使用其他服务作为资源。

关于 WCF - 如果您以这种方式进行 SOA，那么您基本上是在弄乱您的体系结构。如果你想使用 ASB，我可以推荐 MassTransit-AzureServiceBus，它处理了很多恼人的路由逻辑、重试逻辑、进程内队列、异步调用和消息处理逻辑，而不是非服务总线 Azure 服务总线不执行。

于 2013-04-17T20:39:32.607 回答