产品之间的接口集成

Question

在我的公司，我们开发内部产品，通常必须集成此产品（典型情况）。我们的解决方案始终使用SOA Web服务来完成此类任务。

这是一种迫使不同产品开发相同UI界面的解决方案，我们的团队之间有时也不清楚这种界面或流程的责任。

我想提出一个替代解决方案，我认为有时每个产品都会发布SOA Web服务，但另外发布网页，其他产品可以调用重用。

为了在工作中提出它，我想要文档my-self因为我认为这种集成已经发明了，并且有一个名称，例子，工具，最佳实践......

任何方向？

Answer 1

对我而言，跨应用程序共享整个UI似乎是错误的。这将违反separation of concerns原则，并且会couple相互之间的申请。此外，您最终会失去自主权，因为外部应用程序将控制您的UI外观。您将遇到与应用程序之间的相互依赖性相关的各种问题。这是第一个浮现在脑海中的想法：

1. 我认为这些信息不公开。如果是这样，您需要在应用程序之间进行单点登录。为了实现某种程度的安全性（至少是身份验证），您需要在单一登录解决方案中集成所有应用程序，或者发明某种在应用程序之间传递令牌的约定。
2. 如果需要，甚至可以很难实现原始授权，因为不同系统中的角色自然会有所不同，尤其是跨业务领域。
3. 如果您必须按某些属性过滤任何数据，则必须在请求中将其传输到显示之前保存GUI的中央应用程序。然后，整个数据处理和可视化准备将由该中央UI系统负责。这将导致使用中央UI的每个调用者的疯狂数量的调用者特定规则。
4. 应用程序所需的任何复杂UI仍然必须在本地实现，因此您只能部分解决问题。

如果我真的必须实现中央UI，那么我将在你的情况下做什么，虽然我建议强烈反对并且宁愿坚持使用某种中间件（ESB甚至更多）原始EAI软件，限制点对点集成）。如果值得花时间和精力，你可以自己决定：

我只提供一个非常有限的UI版本，它基于已经存在并自动生成的服务层100％。这意味着 - 如果您更改服务，UI将容纳新数据并自动显示。如果应用程序需要复杂的可视化，它仍然必须使用服务层来检索数据并在本地实现自定义UI。在一般情况下，如果UI和可视化分别由每个应用程序控制，那将会更好。这更灵活，面向未来。

希望这有帮助！