使用OSGI将不同的提供者和使用者链接到一个使用者

Question

我正在尝试使用OSGI framewrok构建天气应用。我创建了一个由消费者和提供者组成的国家搜索器，以及一个由消费者和提供者组成的城市搜索器，最后是天气提供者和消费者。

1. 在国家/地区消费者中，我允许用户检查某个国家/地区是否可以检查天气。
2. [在城市消费者中，我允许用户检查城市是否可以检查城市提供者中的天气，我已将哈希图国家/地区用作键，将城市用作值。
3. 在天气束中，一旦执行了消费者操作，我希望用户能够输入城市，并且应该使用上面创建的国家束检查国家（如果有国家/地区，则下一步应该要求用户输入）一个城市，应使用城市捆绑包检查该城市，如果存在该城市，则最终天气提供者应使用该城市并提供天气详细信息。

我无法理解如何将天气捆绑包与国家和城市捆绑包链接

Answer 1

捆绑之间的通常连接方式是OSGi服务。您可以使用接口或类发布服务。然后，使用者可以绑定到接口或类。在最低级别上，可以使用OSGi API完成此操作，但不建议直接使用它。相反，我建议使用带注释的声明式服务。

See the OSGi enroute microservice example。

它显示了内部布线以及使用和提供REST服务。

Answer 2

我认为主要的见识是凝聚力。在您的描述中，您混合了application的非常不同的方面。即您将用户交互（我希望用户..）与查找特定信息的底层机械细节混合在一起。

OSGi的基本思想是将这些部分分成services。该服务提供了高度内聚的底层function。即它只做[[one一件事情，一件事情。如果您查看Event Admin服务，则会看到它确实在发布和订阅。这样的想法是，您最终会获得可以做一件事并且与任何其他服务都没有关系（或耦合）的不同服务。这种策略使它们可以在许多不同的应用程序中重用。当您降低内聚力的那一刻，您会发现它们变得很难在其他应​​用程序中重用。这听起来比实际要容易，它通常需要一些迭代才能获得真正具有凝聚力的服务。

组件是可以提供服务的OSGi物品。通常，组件会消耗其他服务。在您的示例中，您可能拥有一个包含城市的数据库。为了保持组件的凝聚力，它不应直接操作数据库，而应使用服务。您的组件应仅在城市中为

expert

，但对数据库内容一无所知。每当您编写组件时，一旦意识到自己正在编写与城市无关的代码，就将其委托给另一项服务。还请确保您的数据库服务不了解城市，而只了解数据库。城市部分是一种非常好用的简便方法，可从根本不了解城市的部分访问城市。如果您这样想，最终将获得许多无所作为的服务。您需要在某处协调这些服务。这是

application

。该应用程序负责整体功能。其目的是将所有松散的末端绑在一起。在您的情况下，它将消耗城市，天气和其他服务。它还将与用户互动。为了与用户互动，它需要能够搜索城市。因此，这样的服务接口将很有用：

 public interface Geo {
     List<String> countries();
     List<String>    cities(String country);
     Country         city(String country);
     City            city(String city);
 }

我将您的城市和乡村搜索者结合在一起，因为我发现它们非常有凝聚力。分解它们会增加复杂性。该服务使我可以在用户界面上创建国家/地区弹出窗口，并可以从选定的国家/地区选择城市。
接下来是气象服务：
 public interface Weather {
       boolean hasWeather( String country, String city);
       Report getShortReport(String country, String city);
 }

选择了一个国家和城市后，我可以要求气象服务提供报告。
我在这些界面中使用String的原因是为了防止Geo服务和Weather服务之间的耦合。这是我经常看到的主要的菜鸟错误。创建然后在各地（或更糟糕的是，CityKey）使用的城市和国家（地区）类型，有效地使系统再次成为big ball of mud，其中所有内容都通过某些仅用作String的类与其他内容绑定在一起。
因此，现在应用程序组件可以选择GUI（HTML，gogo，Swing，SWT等）。它可以有效地集中在GUI上，并且低级细节由服务提供商处理。通常，该应用程序应该是系统中任何人都无法重复使用的唯一组件。如果是这样，请将其拆分为可重用部分和特定部分。由于此组件不可重用，因此它是软件中唯一无需担心耦合的地方。
摘要。这个想法是，如果您查看OGSi应用程序的服务图，应该清楚地知道发生了什么，并且应用程序组件（通常不是服务本身）将它们联系在一起。
希望这会有所帮助。