Java 外部系统集成最佳实践

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

我们有一个系统，处理我们用自己的对象代表的公司。我们还通过返回组织对象的SOAP使用外部系统。它们非常相似但不相同（我们的是它们的子集）

我的问题是，我们应该通过一个Facade包装SOAP服务，以便只向应用程序返回公司对象，还是应该返回另一种类型的对象（例如OrgCompany），甚至只是在代码中使用Organization对象

SOAP服务和组织对象由外部公司（银行）定义，我们对其没有控制权

---

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

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

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

下图描述了上述内容

我通常总是将外部定义的域对象转换为内部表示

我还针对外部域对象创建了一套全面的测试，如果外部供应商发布了新版本，这些测试将快速突出任何问题。

该体系结构在这里可能很有用

它的主要用途是在的企业应用程序集成中 异质和复杂的景观

（来自）

---

如果您正在寻找开源解决方案，我会选择开源。我想不出在什么情况下使用另一家公司控制的对象是好的。你应该做的第一件事是将这些对象连接到你自己的对象中。此外，通过拥有自己的对象，您可以将其功能扩展到您连接到的第三方提供的功能之外（例如，如果将来您需要与多个公司对象提供商交谈）

---

请看。

您在这里的决定是如何管理应用程序中的外部代码依赖关系。一些应该影响您决策的因素： 1） API多久会更改一次，更改的预期性质是什么？ 2） 您的应用程序在其部门之外的用途是什么？如果您删除了SOAP服务依赖项，您的应用程序是否仍有用途

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

另一种方法是直接使用从WSDL获取的对象。当在应用程序中引入客户端代码之间的间接级别没有意义时，这是有益的，即应用程序只是一个不同系统的馈线，应用程序的整个要点是将组织对象填充到JMS管道或类似的东西中。如果SOAPAPI契约从未改变，并且您不希望应用程序的输出有太大的变化，那么引入额外的间接层只会长期阻碍代码库的可读性

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

---

希望这有帮助。

我支持Sridhars建议，我只想补充一点，为了将外部服务对象转换到您的应用程序域，您可以使用Dozer：

---

我会检查这些：谢谢大家的意见。我真的很感激。我选择保罗的答案作为最可取的答案，只是因为它是最全面的。但我认为每个人在这个问题上都是一致的。再次感谢。亚当