我们正在开发一个Web应用程序(我们称之为图像库),我们已经确定了以下需求:
问题:我们应该在标准的OSGi框架上构建它还是我们更好地使用其中一个新兴的应用程序框架(Virgo,Aries或即将推出的OSGi标准)？
更多背景和一些初步想法:
我们正在构建一个网络应用程序,我们预计很快就会有数百个客户(公司),每个用户数量达到数百名(员工),否则为什么会这么麻烦;).我们希望使其模块化,因此OSGi.在未来,客户自己可能会开发和插入组件到他们的应用程序,因此我们需要客户隔离.我们也可能希望不同的客户获得不同的功能集.
当不同的客户端共享相同的捆绑包时,为应用程序的不同客户端提供不同的服务实现的"正确"方法是什么？
我们可以使用app-server方法(我们已经查看过Virgo)并将每个客户的每个包加载到他们自己的"app"中.然而,它不喜欢拥抱OSGi.我们没有托管多个应用程序,99%的服务将共享相同的impl.为所有客户.我们还希望将应用程序作为一个进行管理(配置,监视等).
每个服务都可以为每个客户注册(正确配置)一次,以及一些"客户令牌"属性.它有点乱,需要使用扩展模式或ManagedServiceFactory来处理？在为客户A注册服务之前,还需要获取每个依赖项的A版本.
每个请求都将知道"当前"客户,并且可以绑定到该线程.每次搜索服务时都必须提供客户令牌,这有点乱.这使得很难使用蓝图等组件框架.为了解决这个问题,我们可以使用服务挂钩来代理每个注册的服务类型,并让代理根据当前客户(线程)调度到正确的实例.
通过实现上面的解决方法(hack？)来开始我们整个OSGi体验真的感觉就像是我们走错了路.那我们该怎么办？回到处女座？尝试类似于上面概述的内容？有什么完全不同的东西？!
PS.感谢您一直在这里阅读!;)