SOA 中的 Web 服务文档（模式、位置）发现

Question

我需要就允许存储和查找 Web 服务 (WCF) 文档（wsdl、模式、位置等）的方法提出建议。能够监控服务将是一个明确的好处。

这需要在迁移到 SOA 的更广泛背景下进行考虑，尽可能使用 Microsoft 技术构建，客户端应该可以从其他框架访问这些技术。目的是开发一个系统，在该系统中，如果服务移动或新版本上线，客户端无需更改 - 应该可以编写客户端“知道”一个地址/位置，该地址/位置能够适当地引导他们.

服务文档的中心位置也很重要；我们的业务分析师应该能够从一个中心位置找到他们需要的关于我们提供的服务的所有信息。我们还希望（可能）向合作伙伴公开该服务信息存储库。我知道我们可以生成 wsdls 并手动管理它们（在某处创建一个文件夹并在发送之前将它们压缩起来），但这似乎非常耗费人力并且容易出错（就我而言）。

在我看来，目前有两种广泛的方法；

1. 使用 WS-Discoverability 和 a dynamic routing service 编写可以响应客户端请求的定制内容。
2. 获取现成的解决方案。

我不得不说，现成的解决方案是最有可能被接受的方法，但我至少必须考虑替代方案。对于我已经确定的现成解决方案

1. BizTalk
2. WSO2 ESB 和 WSO2 Governance Registry

尽可能提供功能。

我需要知道什么
我对广泛方法的理解是否正确？
还有其他我应该考虑评估的方法吗？

具体来说，我还需要了解我考虑的任何方法的优缺点，并了解如何实施。

Answer 1

首先，我绝对不会使用 Biztalk 或任何基于 WS-Whatever SOAP 的协议。

简单一点，你最终会成为一个快乐的人。

对于中间件，我会选择Mass Transit

或者，如果您愿意，可以使用 NServiceBus，我不太喜欢它，但它提供了另一个级别的企业支持。如果您选择使用事件 SOA，您将获得异步操作作为奖励。

定义了中间件层之后，就该定义 API 层了。我不会将我的服务暴露给外界，如果中间件是基于事件的，其中的服务只能响应放置在总线中的事件，所以我会使用带有 REST 接口的 ASP.NET Web API 来获取向外部请求，并根据请求类型创建相关消息（命令）并将其放置在总线上。

高水平，但我希望它有所帮助。