OSGi鼓励的高度模块化对于我正在开发的一组SOA服务是可取的 .
每个服务将包括后端服务（包括一些持久性），服务接口（例如SOAP / REST）和前端UI .
原生碳产品似乎很合适，我的服务将作为定制的OSGi Carbon组件创建 .
与使用WSO2堆栈（DSS，ESB，AS等）实现SOA服务相比，定制OSGi Carbon组件的专业和概念是什么？
收到的答复摘要
由于这个问题已经结束，这是对收到的答复的总结 .
创建基于 WSO2 Custom Carbon Components (OSGi) 的SOA服务的原因：
-
您正在扩展WSO2
-
您已经拥有了要重用的OSGi组件
-
您想重用Carbon UI框架
使用 WSO2 Product based SOA服务的原因
-
使用Carbon管理UI轻松监控和管理服务生命周期
-
更容易开发SOA功能（ESB和DS功能不需要Java代码
我想可以使用多种方法，例如，后端服务创建为基于WSO2产品的服务，前端创建为WSO2定制碳组件？
2 回答
如果您在Carbon管理控制台本身提供服务的UI，这可能意味着您正在扩展/增强产品功能，那么您必须沿着编写OSGi包的路径前进 . 示例：您正在添加新的限制算法，该算法允许用户通过管理控制台配置新的限制策略，该控制台接受许多不同的参数 .
如果您正在开发将在用户级应用程序中使用的功能，那么您不应该沿着OSGi路径前进 . 除非您正在增强/修改平台，否则您不必了解OSGi . 对于最终用户，在配置ESB时，除非无法使用现有介体配置方案，否则不必编写自定义代码 . 因此，当您必须开发新服务时，ESB和DSS遵循配置驱动方法（针对最终用户） .
我相信您已将服务实现为OSGi捆绑包 . 因此，服务控制可以在OSGI级别完成 . 如果你看看我们的碳管理服务，那些是OSgi服务，你可以在OSgi级别控制它们 .
这里wso2 stack提供了为现有服务实现接口（例如：esb代理），或者将现有数据层暴露给世界之外（例如：DS）或者您可以实现自己的服务，这些服务是常见的模式，例如spring /*.aar并将它们部署在（例如：AS）中
根据我的理解，OSGI服务和您尝试使用wso2堆栈创建的服务，两者都应该没有任何重大问题 .
但是当进行监控时，我认为OSGi服务不会那么简单，因为你必须使用OSGi命令 .