我正在构建一个应用程序，该应用程序公开一个 Rest API，并在后端通信和协调多个 SOAP 服务以构建对 REST API 的响应。我一直在阅读有关规范数据模型以及它们如何帮助我松散耦合这些后端 SOAP 服务的文章。
我应该在我的 Rest API 和后端服务之间使用规范数据模型吗？
目前，后端 SOAP 响应使用 JAXB 解组为 Java 对象。然后，我使用脚本将 jaxb 对象映射到表示我想要以 JSON 形式返回的结构的映射，并通过我的 Rest API 将映射简单地转换为 Json。
所以 SOAP -> jaxb Java 对象 -> Java Map（代表 JSON） -> Json
我应该在此处为规范模型添加另一个步骤吗？
所以 SOAP -> jaxb Java Object -> CANONICAL MODEL 不代表 SOAP 或 JSON 结构 -> Java Map（代表 JSON） -> Json
这是否适合 CDM？还是添加这个额外的级别是多余的？
我认为您是在谈论在您和服务之间建立一个门面，而不是 CDM。您可以将 jaxb 生成的对象映射到内部对象，在这些对象上执行应用程序逻辑，然后将它们映射到表示您的 JSON 接口的对象。jaxb-internal 映射将使您的应用程序与您正在使用的接口分离。internal-to-json 映射将使您向消费者公开的接口与您的内部对象分离。
这是否值得取决于您的环境的复杂性，成本和改变的可能性是多少。例如，与共享和公开成熟且版本化的规范模型的服务紧密耦合可能是可以接受的。如果您使用一组 ad-hoc 或第三方接口，这是一个非常不同的风险概况。
据我所知，规范数据模型是指代表所有可能的消息格式和/或协议的通用数据模型。例如，在 MuleMuelMessage中是一个规范的数据模型，因为我们发送的每条消息，Mule 都会创建MuleMessage代表您的消息的模型，而与我们使用的协议无关。所以一般来说创建这样一个规范的数据模型有点困难
谈到您的情况，我不知道您的 SOAP 对象有多复杂。如果它们太复杂，即具有多层次，那将是一项艰巨的工作。我的建议是，您为什么不能编写自己的自定义转换器（看看您是否可以使用内置转换器），而不是拥有规范的数据模型，它将您的 SOAP 消息解析并转换为相应的 JSON 响应。您可以有一个通用的转换器接口，但有多个实现会执行解析和转换，这取决于您的 SOAP 消息。
希望这有帮助。