外部系统集成最佳实践

Question

关于与外部系统集成的最佳实践是什么的快速问题。

我们有一个与公司打交道的系统，这些公司由我们自己的对象表示。我们还通过SOAP使用外部系统，该系统返回一个Organization对象。它们非常相似，但并不相同(我们的是他们的子集)。

我的问题是，我们应该通过外观包装SOAP服务，以便只向应用程序返回公司对象，还是应该返回另一种类型的对象(例如OrgCompany)，或者甚至只在代码中使用组织对象。

SOAP服务和组织对象是由我们无法控制的外部公司(银行)定义的。

任何建议和理由都是非常感谢的。

Answer 1

在这里，您要决定如何管理应用程序中的外部代码依赖项。一些因素会影响你的决策: 1) API多久会改变一次，这些改变的预期性质是什么? 2)除了依赖之外，你的应用程序的效用是什么？如果您删除了SOAP服务依赖，您的应用程序还会发挥作用吗？

一种防御性方法是围绕SOAP服务构建外观或适配器，以便您的代码仅依赖于对象模型。这为您提供了大量的控制，并且您的代码/逻辑和服务之间的耦合相对松散。您为此控制付出的代价是，当SOAP协定更改时，您通常还必须更改您的代码层。

另一种方法是直接使用从WSDL获得的对象。当在客户端代码之间的应用程序中引入某种程度的间接性没有意义时，这是有益的，例如，您的应用程序只是不同系统的馈送器，而应用程序的全部目的是将Organization对象填充到JMS管道或类似的东西中。如果SOAP API契约从不更改，并且您不希望应用程序的输出发生太大变化，那么引入额外的间接层只会长期阻碍代码库的可读性。

根据我的经验，大多数j2ee开发人员倾向于采用前一种方法，这既是因为他们的应用程序的性质，也是因为他们希望将应用程序逻辑与数据源的细节分开。

希望这能有所帮助。

Answer 2

我的两点意见是，在应用程序中引入外部对象总是一个问题。特别是在维护期间。一个小的服务更改可能会导致应用程序中的大代码更改。

在外部服务和应用程序之间有一个层抽象总是很好的。我建议创建一个服务层，它将执行外部服务对象到应用程序域对象的转换，并在应用程序中使用它们。清晰的分离/解耦对维护有很大帮助。

下图描述了上述内容。

​

​

Answer 3

我想不出任何情况下，使用其他公司控制的对象是很好的。您应该做的第一件事是将这些对象桥接到您自己的对象中。此外，通过拥有自己的对象，您可以将它们的功能扩展到您所连接的第三方所提供的功能之外(例如，如果将来您需要与多个公司对象提供程序对话)

看看Adapter pattern。