如何真正实现SOA架构？

Question

我的项目是将传统的胖客户端桌面应用程序转换为Web。结果数据库没有改变。因此，我们被迫调用外部Web服务来访问我们自己的数据库中的数据。再加上我们的应用程序的某些部分可以通过DAO直接访问数据库这一事实（这种做法更快更容易）。我们应该称之为Web服务的功能是下游依赖系统所必需的功能。

这真的是SOA应该如何工作吗？不可否认，这是我第一次涉足SOA领域，但我不得不认为这是完全错误的做法。

Answer 1

我同意这是错误的做法。通过Web服务调用您自己的数据库应该会在设计评审中引发危险信号，并且可以使用简单的DAO（KISS principle）。

现在，如果真正需要在整个公司内共享的数据（帐户，账单等），那么就应该考虑使用SOAP或REST等更重要的解决方案。但是你的团队仍然可以直接访问它，这会更快。

我的团队在我们想要以批处理模式调用的Web服务时也发生了同样的事情。我们不是调用自己的SOAP端点，而是将其设置为调用POJO（普通的旧Java对象）接口。通过SOA设备没有XML转换或额外的网络跳跃。

当您的团队拥有整个应用程序时，在MVC层之间放置XML接口是过分的。它可能不是传统的SOA ......但IMO是传统的常识。 ;）

Answer 2

我见过有人试图将SOA压得太低，这可能就是这种情况。我当然不会将DAO和SOA等同于同一级别。

我同意@ewernli
What is SOA "in plain english"?

  

恕我直言，SOA仅在企业级别才有意义，对单个应用程序毫无意义。

如果我正确地阅读了您的问题，您的Web服务就是将C / R / U / D数据导入数据库。如果是这样，直接向数据库提供C / R / U / D服务，其表可能太低而无法成为SOA服务。

我会寻找更高级别的服务，并尝试确定他们是否对企业感兴趣。如果是这样，那些都是您的服务。我也会问自己，我以前的桌面应用程序是否提供服务（即，您是否应该将自己的新应用程序本身设为SOA服务，而不是试图将SOA架构强制推向低级别的桌面应用程序。

Answer 3

  

因此，我们被迫   调用外部Web服务进行访问   我们自己的数据库中的数据。

男人，那应该受伤了。就SOA中的服务而言， 服务是业务任务的可重复逻辑表现 - 这意味着如果您不是“支持服务”业务流程，则不会实施SOA。如果你要使用一些Web服务来从数据库中选择数据，那么你所得到的就是一堆web服务，这会降低你的应用程序速度，这可能会因传统的数据访问模式（如DAO）而更快。

当您将SOA与Web服务等同时，如果没有适当的体系结构，则存在使用Web服务替换现有API的风险。这将导致识别许多非业务一致的服务。

此外，面向服务是一种将业务集成为一组链接服务的方式 - 所以问问自己，组织是否利用这些原子服务来获得更多好处？

谷歌搜索SOA反模式，你会发现有什么不同的方式来结束一堆网络服务而不是SOA。

Answer 4

良好的SOA设计完全是关于行为和数据的分离。 我重复行为和数据需要分开，否则你会有很多或者问题，无论是CORBA / SOAP / REST / XMLRPC，还是普通的JVM方法调用。

很多人会谈论服务端点，消息处理和合同，这使得SOA成为计算中较为复杂的领域之一，而这一点并不复杂。

如果你正在做Java，那真的很容易。为您的域对象创建POJO，没有奇怪的状态行为，也没有奇怪的协作者，然后使用该行为创建Service类。更常见的是，你不能只使用你的DAO作为服务（我的意思是你应该在DAO上有一层薄薄的，但如果你不需要一个......）。

OOP爱好者不同意这种数据和行为的分离，但这种设计模式非常好，并且实际上是像Erlang这样的大多数函数式编程语言。

如果您正在制作视频游戏或基于状态的东西，那么这种设计理念是一个坏主意。 BTW SOA与企业这个术语一样空洞。

Answer 5

SOA ...... SOA ......是我存在的祸根，正是出于这个原因。什么或不是什么构成SOA？我在日常工作中支持SOA产品，有些人得到它，有些则没有。 SOA .. SOA是关于用XML包装离散业务服务。 ZIP + 4验证服务。支付网关。 B2B消息传递。

SOA CAN 用于将桌面应用与后端数据库分离。有时它没有意义，有时它确实有意义。几乎 NEVER 有意义的是低延迟高查询计数逻辑。如果您必须在法国使用直接连接到加利福尼亚州数据库的应用程序，您将明白我的意思。 SOA几乎迫使您巧妙地了解如何建模和返回数据（查看 SDO - 服务数据对象）。然而，细节中的魔鬼。将数据编组到XML或从XML编组数据可能成本很高。

Answer 6

你认为哪一部分是错的？您必须访问Web服务的部分，或者您直接访问数据库的部分？

SOA更多的是API设计指南，而不是开发方法。实现起来并不容易，但可重用性的回报往往是值得的。

请参阅Service-Oriented Architecture expands the vision of Web services或任何有关SOA的技术手册。简单地使用Web调用包装函数调用并不会使其成为面向服务的体系结构。 SOA的想法是制作可重用的服务，然后通过合成或编排底层的低级服务来创建更高级别的服务（如网站）。在非常低的层次上，您应该关注无状态，松耦合和粒度等问题。像Microsoft的WCF这样的现代框架支持SOAP，REST和更快的二进制文件等并行协议。

如果您的应用程序旨在通过Internet运行，则应注意网络延迟问题。在部署在LAN上的传统客户端 - 服务器应用程序中，由于延迟低于10毫秒，因此每次需要数据时都可以访问数据库，而不会中断用户体验。但是，在Internet上，如果您跨越代理或海洋，则持续200毫秒的延迟并不罕见。如果您点击数据库100次，那将暂停最多20秒。在SOA中，您可以尝试将整个文档打包到一个文档中，然后来回交换文档，类似于您居住在美国时使用Form 1040提交税的方式。

您可能会说延迟问题无关紧要，因为Web服务仅由您的Web应用程序层使用。但是你可以使用AJAX重新加载数据从浏览器点击Web服务，这样可以缩短用户的响应时间。