0

OSGi 鼓励的高度模块化对于我正在处理的一组 SOA 服务来说是可取的。

每个服务都包含一个后端服务（包括一些持久性）、一个服务接口（例如 SOAP/REST）和一个前端 UI。

原生碳产品似乎很合适，我的服务将被创建为自定义 OSGi Carbon 组件。

自定义 OSGi Carbon 组件与使用 WSO2 堆栈（DSS、ESB、AS 等）实现 SOA 服务的优缺点是什么？

收到的答复摘要

由于这个问题已经结束，这是收到的答复的摘要。

创建基于WSO2 自定义碳组件 (OSGi)的 SOA 服务的原因：

  • 您正在扩展 WSO2
  • 您已经拥有想要重用的 OSGi 组件
  • 您想重用 Carbon UI 框架

使用基于 WSO2 产品的SOA 服务的原因

  • 使用 Carbon admin UI 轻松监控和管理服务生命周期
  • 更容易开发 SOA 功能（ESB 和 DS 功能不需要 Java 代码

我想可以使用多种方法的组合，例如创建为基于 WSO2 产品的服务的后端服务和创建为 WSO2 自定义碳组件的前端？

4

2 回答 2

1

自定义 OSGi Carbon 组件

我相信您已经将服务实现为 OSGi 包。因此，服务控制可以在 OSGI 级别完成。如果您查看我们的 carbon 管理服务，那些是 OSgi 服务，您可以在 OSgi 级别控制它们。

使用 WSO2 堆栈（DSS、ESB、AS 等）实现 SOA 服务

这里 wso2 堆栈提供了为现有服务（例如：esb 代理）实现接口，或者将现有数据层暴露给外部（例如：DS）或者您可以实现自己的服务，这些服务是常见的模式，例如 spring /*.aar 并将它们部署在（例如：AS）

据我了解，OSGI 服务和您尝试使用 wso2 stack 创建的服务都应该没有任何重大问题。

但是在监控方面，我认为 OSGi 服务不会那么容易，因为你必须使用 OSGi 命令。

于 2013-06-10T14:12:43.253 回答
1

如果您在 Carbon 管理控制台本身中为您的服务提供 UI，这可能意味着您正在扩展/增强产品功能，那么是的，您必须走上编写 OSGi 捆绑包的道路。示例：您正在添加一个新的限制算法，它允许用户通过接受许多不同参数的管理控制台配置新的限制策略。

如果您正在开发将在用户级应用程序中使用的功能，那么您不应该沿着 OSGi 路径走下去。除非您正在增强/修改平台，否则您不必了解任何有关 OSGi 的信息。对于最终用户，在配置 ESB 时，您不必编写自定义代码，除非您的场景无法使用现有的中介进行配置。因此，当您必须开发新服务时，ESB 和 DSS 遵循配置驱动的方法（针对最终用户）。

于 2013-06-10T14:13:41.700 回答