2

我们有一个基于 SOA 的项目，该项目从一开始就被构建为一个 Web 服务层到一个完善的应用程序。

客户A-->                       
ClientB --> ESB --> 原子服务 --> 已建立的应用程序（DB/NAS 等）
客户C-->

我们有几个场景，其中 ESB 提供的服务由多个按交互顺序调用的原子调用组成，因此从逻辑上讲，它们会执行以下操作：

def compose_service(xmlrequest):
    output_of_decision_service = 决策服务（xmlrequest）
    如果（output_of_decision_service.matches（“foo”））：
        xmlresult = foo_service(xmlrequest)
    if (output_of_decision_service.matches("bar")):
        xmlresult = bar_service(xmlrequest)
    返回xml结果

事实上，这个逻辑是使用 XSLT 转换实现的，并且 XPath 查询构建到我们购买的 ESB 实现中。这对我来说似乎有问题，原因如下：

  • 开发人员无法在本地测试组合服务（从业务角度来看的简单功能），因为 ESB 实现过于“繁重”而无法在本地部署。整体测试是一项集成活动。
  • 用于形成这些和类似控制块的 XSLT 语法不像通用编程语言中的代码那样可读或可访问。（if ... then，else finally 等） XSLT 已经变得很长而且令人生畏。
  • 在某些复杂的场景中，更细粒度的控制将是有益的，即通过调用补偿原子服务来回滚较早的操作来补偿失败的调用。

我想在这个项目上工作了一年之后，我觉得将应用程序功能分解为原子服务的想法是一个很好的想法。然而，我经常觉得我更喜欢用 Java 等普通的老式编程语言来实现组合 Web 服务。

我想这看起来像这样：

ClientA --> ComposingServiceA -->                   
ClientB --> ComposingServiceB --> 原子服务 --> App
ClientC --> ComposingServiceC -->

但是，在这里阅读我发现了一个未引用的声明，如下所示：

当然，在代码中模拟 ESB 行为是更糟糕的选择

遗憾的是，这只是对事实（意见）的盲目陈述，没有任何支持理由。然而它让我慌了。为什么上面说的是真的？我准备起草一封电子邮件给我们的建筑师，表达上述所有担忧，但这条评论让我想知道我是否应该这样做？

为什么在代码中模拟 ESB 行为肯定是最糟糕的选择？

4

1 回答 1

1

不知道该声明的完整上下文很难发表评论，但是如果他们的意思是尝试从头开始实现您自己的 ESB，那么是的，我将不得不同意。ESB 非常复杂，您不想尝试自己动手。

就架构而言，您希望分解为“组合”服务是正确的。这称为服务分层，通常会产生三层。您的原子服务对应于实体层服务或实用程序后期服务，它们与业务流程无关并且通常可重用。您的组合服务通常对应于任务层服务，这些服务组合其他服务，与特定的业务流程相关，通常不可重用。

于 2012-02-27T22:53:12.590 回答