具有负载平衡扩展的 OSGi 扩展器模式

发布于 2024-10-18 13:57:33 字数 482 浏览 9 评论 0原文

我想实现以下场景:

扩展器使用他的扩展,而扩展则按其类型分组。例如:扩展器 = 供应商,扩展 = HotDogSeller1、HotDogSeller2、PopcornSeller。我的观点是,客户(顾客)想要购买热狗或爆米花,但他会选择负载较少的热狗卖家(队列较小)。

我是 OSGi 新手,所以我想问一下实现此功能的最佳实践是什么?我想我可以将 Apache Felix 与 iPojo 一起使用(它是 扩展程序模式) 。这有两个问题:

  • 相同的捆绑包必须安装两次(热狗实现,每个都有自己的队列长度)
  • 以某种方式将相同类型的捆绑包(热狗,爆米花)​​分组。这可以通过使用某些键(例如“数字”来区分 HotDogSeller1 和 HotDogSeller2)为捆绑包创建属性来完成
  • I would like to implement following scenario:

    Extender uses his extensions while extensions are grouped by theirs' type. For example: Extender = Vendor and Extensions = HotDogSeller1, HotDogSeller2, PopcornSeller. My point is that client (customer) want to buy either HotDogs or Popcorns however he will choose less loaded HotDogSeller (smaller queue).

    I am new to OSGi so I would like ask what are best practices to implement this? I suppose I could use Apache Felix with iPojo (and it's extender pattern). There are 2 problems with this:

  • Same bundle has to be installed twice (the hotdog implementation, each has it's own queue length)
  • Somehow group the bundles that are of the same type (hotdogs, popcorns). This could be done by creating property for bundle with some key like 'number' to distinct HotDogSeller1 and HotDogSeller2)
  • 如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

    扫码二维码加入Web技术交流群

    发布评论

    需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

    评论(1

    孤芳又自赏 2024-10-25 13:57:33

    我认为您试图滥用扩展器模式。关键特征之一是扩展器模式本质上是静态的:安装捆绑包时一切都会发生。看来这不是你的情况:同一实现有多个队列让我认为这些队列后面有服务。服务的数量可以动态变化,因此扩展器不能很​​好地满足您的需求。

    我认为如果你使用白板模式会更好。 (忽略它是针对侦听器机制的事实)。这个想法是每个捆绑包都提供可以处理您的请求的服务。您可以使用 ServiceTacker 跟踪所有可用服务。当您需要处理请求时,您可以迭代所有可用的服务并询问它们是否免费(您可以选择在内部处理此问题,并且不与服务实现协商此问题)。当发现免费服务时,您转发该请求。

    您可以通过使用属性“type”和相应的值注册服务来对服务进行分组,这样您就可以使用具有“type”“HotDog”的服务和具有“type”“Popcorn”的服务。

    如果您这样做,您可以使用 OSGi 声明式服务,因此您不需要编写代码来进行服务注册或任何其他服务管理。

    I think that you are trying to misuse the extender pattern. One of the key characteristics is that the extender pattern is static in its nature: everything happens when the bundle is installed. It seems that this is not your case: having multiple queues for the same implementation leads me to think that there are services behind those queues. The number of services can change dynamically, so extender will not serve you well for this.

    I think it would be better if you use Whiteboard pattern. (Ignore that fact that it is targeted at listeners mechanism). The idea is that each bundle provides service, which can handle your requests. You track all available services using a ServiceTacker. When you need a request to be processed, you iterate over all available services and ask them whether they are free (you can choose to handle this internally and don't negotiate this with the service implementations). When a free service is found you forward the request.

    You can group the services by registering them with a property 'type' and the corresponding value, so you can use services, which have 'type' 'HotDog' and services with 'type' 'Popcorn'.

    If you go this way, you can use OSGi Declarative Services, so you don't need write the code, which does the service registration or any other service management.

    ~没有更多了~
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文