一切都通过公共汽车吗？
我们已将 BizTalk 作为服务总线引入到我们的组织中，它将新的 Web GUI 连接到众多现有的后端系统。 我们将现有系统包装为服务（WCF）并将它们连接到总线。
我们还用新的 Web GUI 替换了一些遗留系统 GUI（确保我们复制现有功能），但我很好奇我们是否应该通过 BUS 公开所有遗留服务/API、直接连接到它们或以不同的方式组合它们，通过公共汽车暴露他们。 例如，假设我们的客户管理系统有 5 个现有服务/API：搜索、添加、检索、更新、设置账单详细信息。
通过总线公开这些服务是否有意义（有人认为这会增加延迟）？ 或者总线是否应该仅公开粗粒度服务，例如搜索、添加、检索和检索。 更新而不是细粒度的更新？ GUI 应该直接连接到细粒度服务吗？
我的印象是，在理想的 SOA/ESB 中，您会将更新和设置计费详细信息组合到一个粗粒度服务中，这是正确的吗？
我想忠于 SOA/ESB 范式，请有人启发我。
We have introduced BizTalk into our organization as a Service Bus, it is linking a new Web GUI to numerous existing back end systems. We have wrapped our existing systems as Services (WCF) and connected them to the BUS.
We are also replacing some of the legacy system GUI's with our new web GUI (ensuring we replicate existing functionality) but I am curious as to whether we should expose all legacy services/api's via the BUS, connect to them directly or compose them differently and expose them via the bus. For example, lets say our Customer Management system has 5 existing services/api's, Search, Add, Retrieve, Update, Set Billing Details.
Does it make sense to expose each of these services through the BUS (some argure it adds latency)? Or should the BUS only expose the coarse grained services such as Search, Add, Retrieve & Update and not the fine grained one? Should the GUI connect to the fine grained service directly?
I am under the impression that in an ideal SOA/ESB you would compose both Update and Set billing Details into one Coarse grained service, is this correct?
I would like to stay true to the SOA/ESB paradigm, could someone enlighten me please.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
ESB 最适合构建“复合”应用程序。
首先，您必须公开来自大量离散应用程序的大量细粒度服务。
这为构建复合应用程序奠定了基础。
重点是创建任何单个应用程序中都不存在的组合服务。 这些服务仅存在于 ESB 中。 它们是由细粒度的服务构建的。
请注意，组合依赖于细粒度服务，这两者都位于 ESB 中，从而减少了定位和执行细粒度服务所涉及的开销。 然而，真正的工作是由外部应用程序完成的，这会带来一些开销。
请注意，基于 ESB 的应用程序的性能完全击败了其他交互方法，以至于您因“延迟”而苦恼，从而错过了立即、直接集成带来的巨大胜利。
The ESB is best applied to building "Composite" applications.
First, you have to expose a lot of fine-grained services from a lot of discrete applications.
This sets the stage for building composite applications.
The point is to create composite services that don't exist in any single application. These services only exist in the ESB. They are built from fine-grained services.
Note that the composites rely on fine-grained services, both of which live in the ESB, reducing the overheads involved in locating and executing the fine-grained services. However, the real work is done by external applications, which introduces some overhead.
Note that the performance ESB-based applications so totally defeats other methods of interaction that wringing your hands over "latency" misses the huge victory from immediate, direct integration.
通常情况下，有不同的方式来看待这个问题 -
如果您只是从总线角度来看它（我不完全赞成）-那么使用 BizTalk 进行非聚合/复合服务几乎没有价值（而且，正如您所提到的）您会增加延迟ETC。
当然，即使在这种情况下，人们也可以争论 BizTalk 为您提供的所有服务，例如监控、管理、可扩展性等，但在不了解完整场景的情况下很难判断这些服务的相关程度。
然而，BizTalk 也是（有些人认为主要是）集成引擎，并且经常用于将消费者从服务实现中屏蔽掉。
这是一个可能的场景（同样，不知道这是否适用于您的情况以及在多大程度上适用） - 您有一个遗留应用程序，您将其包装在服务中以启用 SOA。
18 个月后，您完成替换服务的实现，但它有一个不同的界面（因为它有更多功能） - 如果您在中间有 BizTalk，您就有一个层，您可以在其中将调用者提供的旧格式映射到服务所需的新格式，反之亦然。
这意味着您不必更改所有客户端应用程序（无论如何，立即更改）。
所以 - 我想答案是 - 这要看情况。
As is often the case there are different ways to look at this -
If you're looking at it simply from a bus perspective (something I don't fully favour) - then using BizTalk for non-aggregate/composite services has very little value (and, as you've mentioned) you're adding latency etc.
Of course, even at this case one can argue for all those service BizTalk gives you such as monitoring, administration, scalability etc, but it's hard to judge how much these are relevant without knowing the full scenario.
However, BizTalk is also (and some would argue - primarily) an integration engine and is often used to mask a consumer from a service implementation.
Here's a possible scenario (again, not knowing if, and to what extent, that applies to your case) - you have a legacy app, which you're wrapping in a service to enable SOA.
18 months from now you finish implementing the replacement service, but that has a different interface (as it has more features) - if you have BizTalk in the middle you have a layer where you could poitentially map the old format provided by the caller to the new format required by the service and vice versa on the response.
this means that you don't have to change all your client app (at once, anyway).
So - the answer is, I guess - it depends.