产品之间的接口集成

Question

在我的公司，我们开发内部产品，通常这些产品必须是集成的(典型场景)。我们的解决方案是始终使用SOA web服务来完成这类任务。

这是一种强制不同产品开发相同的UI界面的解决方案，而这个界面或流程的职责有时在我们的团队之间并不明确。

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

对于在工作中提出它，我想自己记录下来，因为我认为这种集成已经被发明出来了，并且有一个名称、示例、工具、最佳实践……

有什么见识吗？

Answer 1

对我来说，在应用程序之间共享整个UI似乎是一个错误。这将违反separation of concerns原则，并将couple应用程序彼此。此外，你最终会失去自主性，因为外部应用程序将控制你的UI外观。你会遇到各种各样的问题，与应用程序之间的相互依赖关系有关。首先想到的是：

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

在您的情况下，如果我真的必须实现中央UI，我会这样做，尽管我强烈反对它，并且更倾向于坚持使用SOA和某种中间件(ESB，甚至是限制点对点集成的更原始的EAI软件)。你可以自己决定是否值得花时间和精力：

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

希望这能有所帮助！