Question

我在OSGi中构建了一个应用程序，它提供了一个REST API，用于读取不同数据源的值。然后我在我的应用程序中安装了几个模块，公开了这些数据源。例如，一个模块公开来自数据库的读数，另一个模块公开来自网站，另一个读取来自TCP / IP设备等......

例如，如果我这样做： http://--------/listAllDataSources

如果我安装了3个模块，我会得到类似的东西：

{
   dataSources : [ 0, 1, 2 ]
}

然后，如果我这样做： http://--------/read/1

我会从数据源编号1中读取数据。

{
    currentValue : "44.5"
}

所以我的架构包括：

[ External Apps]
        |
        |
      *Web*
        |
        |
[   REST API   ]
[M1][M2]....[Mn]

这被认为是SOA吗？

另外，我不会使用任何服务代理，因为你可以看到。这是否使我的应用程序不是SOA？

谢谢！

Answer 1

SOA是一个抽象概念，类似于3层架构可以应用于不同的层次。

如果您将“外部应用程序”视为系统的一部分，则这些应用程序是服务使用者，“[Rest API]带有[M1] .. [Mn]”是服务提供商。沟通超过http。这是SOA。

如果您的系统范围仅为“[Rest API] [M1] .. [Mn]”，那么您仍然有消费者 - [Rest API]（也是外部服务的提供者）和提供者[M1] .. [Mn]为。

这个模块中的每一个都是一个服务，所以我认为这个设计是一个非常简单的SOA。服务代理作业由OSGI运行时完成，通信协议可以只是Java方法调用 - 但是它可以简单地替换为ECF以在不同的JVM之间分配模块，然后通信协议取决于ECF中配置的内容。

Answer 2

我认为你在这里混合概念，PedroD。您可以详细阅读SOA所指的术语here。（我故意没有链接到维基百科的文章，这篇文章非常糟糕且具有误导性。）

您的应用程序是为了公开功能而构建的，因此可以说它可以是SOA的一部分，但它本身不是SOA。

SOA指的是支持面向服务的体系结构样式。它有助于组织以面向服务的方式集成和开发其系统。 SOA是一种比您拥有的范例更广泛的范例，它大大超出了单个应用程序的上下文 - 例如它建立了内部企业指南，治理流程，跨多个业务领域构建服务清单以及服务协调，以使组织能够非常快速地实施业务流程，从而缩短产品上市时间。

当然，SOA具有进化水平。您可能还没有适当的流程，或者您可能不使用消息传递代理，可以说您仍在努力实现完全面向服务的体系结构。但是为了实现SOA，你必须至少拥有某种中间件层，这样你就可以避免点对点集成，至少做一些简单的服务组合。

我会说你的应用程序是在考虑到集成的基础上构建的，并且考虑到了服务导向，但它本身并不是SOA。

注意：如果您希望以一种从SOA借用许多概念的样式在内部组织您的应用程序，您可能需要查看Microservice Architecture。实际上对我来说，你的架构看起来更像是微服务。

是否可以在没有服务代理的情况下构建SOA？这有什么好的例子吗？

2 个答案: