产品之间的接口集成 [英] interfaces integration between products
问题描述
在我公司中，我们开发内部产品，通常必须将此产品集成（典型情况）。我们的解决方案始终是将SOA Web服务用于此类任务。
In my company we develop internal products and usually this products must be integrated (typical scenario). Our solution is always use SOA web services for this kind of task.
这是一种解决方案，可迫使不同的产品开发相同的UI界面，并且这些界面或有时我们的团队之间的流程并不明确。
This is a solution that forces different products to develop same UI interfaces, and the responsibility of this interfaces or process is sometimes not clear between our teams.
我想提出一个替代解决方案，我认为有时候每个产品都发布SOA Web服务，但另外还发布网页，
I want to propose an alternative solution, I think that sometimes each product publish SOA web services but in addition publish web-pages, that other products can call to reuse.
为了在工作中提出它，我想记录下自己，因为我想这种集成已经发明了，并且具有名称，示例，工具，最佳实践...
for propose it in the work, I want document my-self because I suppose that this kind of integration is already invented, and have a name, examples, tools, best-practices...
任何方向？
推荐答案
在我看来，跨应用程序共享整个UI似乎是一个错误。这将违反关注点分离原则，并且会将应用程序彼此耦合。而且，由于外部应用程序将控制UI的外观，您最终将失去自治权。您将遇到与应用程序之间的相互依赖性有关的各种问题。这些是第一个想到的：
To me it looks like a mistake to share entire UIs across applications. This will violate the separation of concerns principle, and will couple applications to each other. Also, you will end up losing autonomy because an external application will control how your UI looks. You will have all kinds of issues, related to the inter-dependencies between applications. These are the first that come to mind:
- 我认为信息不是公开的。如果是这样，您将需要在应用程序之间进行单点登录。为了实现某种程度的安全性（至少是身份验证），您需要将所有应用程序集成到一个单一的解决方案中，或者发明某种约定以在应用程序之间传递令牌。
- 如果需要，甚至很难执行原始授权，因为不同系统中的角色自然会有所不同，尤其是跨业务域。
- 如果必须过滤某些数据属性，则必须在显示之前将其在请求中转移到保存GUI的中央应用程序。然后，整个数据处理和可视化准备工作将由该中央UI系统负责。对于使用中央用户界面的每个调用者，这将导致大量特定于调用者的规则。
- 应用程序所需的任何复杂UI仍必须在本地实现，因此您只需解决部分发行。
- I assume the information is not public. If so, you'll need single sign-on between applications. In order to implement some level of security (at the very least authentication) you'll need to integrate all your applications within a single sign on-solution or invent some kind of convention for passing tokens between applications.
- It will be very hard to implement even primitive authorization if needed, because naturally roles in different systems vary, especially across business domains.
- If you have to filter any data by some property, it will have to be transferred in the request to the central application that holds the GUI prior to displaying. The whole processing of data and preparation for visualization will then be responsibility of this central UI system. This will lead to insane amount of caller-specific rules for each caller that uses the central UI.
- Any complex UI required by applications will still have to be implemented locally, so you only solve the issue partially.
如果我真的必须实现中央UI，这就是我要在你的情况下做的事情，尽管我强烈反对它/ em>，并且倾向于使用某种中间件（ESB或限制点对点集成的更原始的EAI软件）坚持SOA。您可以自己决定是否值得花费时间和精力：
Here is what I would do in your case if I really must implement central UI, although I advice strongly against it and would prefer sticking to SOA with some kind of middle ware (ESB or even more primitive EAI software that limits point-to-point integration). You can decide for yourself if it is worth the time and effort:
我只会提供非常有限的UI版本，基于已经存在的服务层，这是100％存在并自动生成。这意味着-如果您更改服务，则UI会容纳新数据并自动显示。如果应用程序需要复杂的可视化，它仍必须使用服务层来检索数据并在本地实现自定义UI。通常，最好由每个应用程序分别控制UI和可视化。
I would only offer a very limited version of UI that is 100% based on the service layer that already exists and is generated automatically. This means - if you change the service the UI accommodates the new data and displays it automatically. If an application needs complex visualization it must still use the Service layer to retrieve data and implement custom UI locally. In genera, it will be better if UI and visualization are controlled by each application separately. This is much more agile and future-proof.
希望这会有所帮助！
这篇关于产品之间的接口集成的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
