OSGi鼓励的高度模块化对于我正在研究的一组SOA服务来说是可取的。
每个服务将由一个后端服务(包括一些持久性)、一个服务接口(例如SOAP/REST)和一个前端UI组成。
本地的碳产品似乎是一个很好的适合,我的服务将创建为定制的OSGi碳组件。
自定义OSGi碳组件与使用WSO2堆栈(DSS、ESB、AS等)实现WSO2服务相比有什么好处?
收到的答复摘要
由于这个问题已经结束,这是所收到的答复的摘要。
创建基于WSO2的自定义碳组件(OSGi)服务的原因:
使用基于WSO2产品的 SOA服务的原因
我想可以使用多种方法,例如作为基于WSO2产品的服务创建的后端服务和作为WSO2自定义碳组件创建的前端?
发布于 2013-06-10 14:13:41
如果您正在碳管理控制台本身中为您的服务提供UI,这可能意味着您正在扩展/增强产品功能,那么是的,您必须沿着编写OSGi包的道路前进。示例:您正在添加一个新的节流算法,该算法允许用户通过接受许多不同参数的管理控制台配置新的节流策略。
如果您正在开发将在用户级应用程序中使用的功能,那么您不应该沿着OSGi路径前进。除非您正在增强/修改平台,否则您不必对OSGi有任何了解。对于最终用户,在配置ESB时,您不必编写自定义代码,除非您的场景无法使用现有的中介程序进行配置。因此,当您必须开发新服务时,ESB和DSS遵循配置驱动的方法(针对最终用户)。
发布于 2013-06-10 14:12:43
自定义OSGi碳组件
我相信您已经将您的服务实现为OSGi包。因此,服务控制可以在OSGI级别完成。如果您查看我们的碳管理服务,这些都是OSgi服务,您可以在OSgi级别上控制它们。
使用WSO2堆栈(DSS、ESB、AS等)实现SOA服务
在这里,wso2堆栈提供实现现有服务的接口(例如: esb代理),或者向外部公开现有的数据层(例如: DS),或者您可以实现自己的服务,这些服务是通用的模式,如spring/*..aar,并在其中部署它们(例如: AS)。
据我理解,OSGI服务和您试图使用wso2堆栈创建的服务都应该能够正常工作,不会出现任何重大问题。
但是当谈到监视时,我认为OSGi服务不会那么容易,因为您必须使用OSGi命令。
https://stackoverflow.com/questions/17023754
复制相似问题