如果SOA已经死了，什么在取代它？

Question

如果这个问题很密集，请原谅我。

背景：我们有几个内部应用程序集成在数据库中。我们正在研究如何突破这一点，似乎转向一种架构，其中每个应用程序通过服务公开其功能，而不是调用其他应用程序的数据库，这是最有意义的。这对我来说似乎是一种面向服务的架构。 当我浏览有关开始使用面向服务的体系结构的信息时，我看到很多关于本文的讨论：SOA Is Dead; Long Live Services。我也从Martin Fowler＆amp; amp;吉姆韦伯：Does My Bus Look Big In This?。

问题：

• SOA已经死了，或只是围绕它的嗡嗡声？
• 开始使用面向服务的体系结构的最佳方法是什么，以便尽可能保持简洁和简单？

Answer 1

SOA是一个聪明的想法，但围绕它的巨大炒作让人们写“SOA现在已经死了”。这不是真的，正如句子“结构编程已经死了，现在每个人都做OOP！”并非总是如此：有时结构代码是唯一的选择，但决定应该在评估上，而不是在宣传。 在谈论SOA时也是如此：有时你需要SOA，有时你需要服务。

Answer 2

我对SOA一无所知，但我经常看到这些技术经历了一个循环：

1. 技术问世。
2. 技术非常好，每个人都会向所有人推荐它。
3. 人们试图将这项技术用于所有事情。
4. 当人们意识到不能做所有事情时，他们会生气并发布它已经死在他们的博客上。

我的猜测是SOA只是这些技术中的另一种。

Answer 3

SOA尚未死亡。像每个好主意一样，它成为我们景观的一部分。电子商务一词在早期是一个很大的想法，现在我们甚至不再使用这个词了。我甚至不再使用术语面向对象了，几乎可以假设它。

目前的炒作是云计算。把一切都放在云端。

SOA的最佳实践是在您需要的地方编写好的服务。过度使用SOA会增加延迟。如果需要高效执行代码，请在数据库中使用存储过程。如果它能够胜任，你就无法击败一个好的本地服务。

Answer 4

我会说它并没有死，但它现在已经落入了建筑师的工具集中，因为它现在已经被理解为可以提供帮助的地方，而且可能没有。

使用SOA与您的数据库交谈是没有意义的，因为您希望这种集成是紧密且高效的。但是在正确的位置使用它可以让您在组织的不同部分之间拥有良好的干净界面，并且可能允许您升级每个系统而不管其他系统。

但在现实生活中，如果你的工资单系统出现故障，每个人都会非常不满意，只是因为你的应用程序可能会在没有其中一个组件的情况下跛行并不意味着它不会影响你的系统。

不可能创建仅具有接口知识但不知道底层系统知识的系统（我将用以下内容告知该语句：“运行良好且性能良好”）。以网络浏览器作为一个有趣的例子，每个好的网站都以“他们使用什么浏览器并修复我的网站并利用xyz功能”开头。

Answer 5

SOA是一个典型的例子，当一个有用的模式（甚至不是一个特别新的模式）作为架构的基础出售时会发生什么。与“整合企业的核心设计”一样。

中间件公司特别容易受到这些概念的影响，因为他们自己面临着将产品和服务捆绑在一起的挑战，他们需要具有潜在重大预算的大创意。

从表面上看，单一架构是否可以涵盖企业中所有软件的所有集成需求，这似乎并不可疑？

Answer 6

大多数SOA都试图通过被称为事件驱动的Arcitecture（EDA）的较少使用的SOA子集来更好地处理一个过程。

问题在于SOA被推广为从Web服务构建的东西，这可能是首先实现SOA的底层技术的艰难选择。 SOAP不必须，但通常 用作紧耦合的RPC机制。即使在内部系统中，这也不能很好地扩展，更不用说任何交叉系统或更糟糕的企业。

你可以在SOAP之上构建一个EDA，但通常你最终会得到一些ad-hoc技术。 Asynchronous operations and Web services进入了一些可能的黑客攻击。

即使您已经舔过了RPC Web服务的紧密耦合特性，但是在合作伙伴之间存在紧密绑定和WSDL版本控制的问题。

您仍然可以使用XML有效负载和模式，但SOAP本身会退化为完全在WSDL之外定义的有效负载“blob”的相当愚蠢的传输包装。

StackOverflow是一个主要是隔离的Web应用程序。最接近SOAish的可能是它使用的OpenId机制。它是简单的客户端 - 服务器，而不是SOA。你的想法太小了。

Answer 7

是的，SOA已经死了，但它已经复活成短暂的东西 - http://www.soa-manifesto.org/。现在每个人仍然可以说他们正在做SOA而不管他们做什么，只要他们能宣称遵守6条诫命（或原则）：

• 商业价值优于技术战略
• 针对项目特定利益的战略目标
• 自定义集成的内在互操作性
• 特定用途实施的共享服务
• 优化的灵活性
• 追求初始完美的进化精炼

这对我来说更像是说，任何花费更多时间和金钱制作“未来”IT解决方案的公司都可以宣称要做SOA。这真是件好事。

Answer 8

而不是SOA，为什么不选择通过接口公开功能的模块化设计呢？

它是一样的，只是不那么令人讨厌。

Answer 9

SOA的“最佳”示例是来自SAP的BusinessByDesign冒险。花了很多时间和资源，甚至开始销售它，然后才能正常工作，然后尝试修复/关闭它。

我建议你不要让这些文章吓跑你或以任何其他方式影响你。考虑一下您的特殊情况：它是否会带来您的服务带来的好处？如果是的话，那就去吧。如果没有，那么行动的过程是显而易见的。

我相信SOA背后的思想基本上有一个utopic的想法 - 创建各种众多服务的世界，这些服务可以相互发现并互操作，以自动为您提供高级服务。但这是人工智能/科幻小说的方向。您只能在非常特定的场景中实现某些事情，您可以使用算法方法进行编程。不仅如此......好吧，不是在本世纪......

Answer 10

如果您要使用内部企业级应用程序，可以使用SOA实现它们。 如果您正在创建一个面向Web的应用程序（通过它，我的意思是一个适用于新的开放堆栈oAuth，OpenID等的应用程序。），然后用WOA替换SOA。 Stackoverflow.com就是这样一个野兽的一个例子。

Answer 11

只要企业存在，他们就会有整合需求，系统总是要谈。 SOA似乎是解决此类分布式问题的明智方法。但不幸的是，它忽略了性能问题。为了提出一个可能的解决方案，我发表了一篇关于“流体服务”的文章，通过使用面向流的通信作为面向消息的通信的替代方案来利用客户端和服务器之间的并行性。

这篇关于SOA Maganizine的文章描述了这个概念：http://www.soamag.com/I41/0710-2.php 这是一篇更实用的文章，其中还包括CodeProject上的示例WCF代码：“针对高度响应，可扩展和可重用SOA服务的流体服务实验” （对不起，不能把链接）

Answer 12

SOA适用于本质上“分布式”的架构。如果您正在谈论的是基于接口的编程方法，那么您将走向“基于组件”的技术，如COM +，CORBA。或类似.NET Remoting的东西。但是，如果您在分布式环境中讨论基于合同的开发，这种开发随着时间的推移而发展，并且是由多个独立的小组开发的，那么您就是SOA范例。必须分发这些服务。但我并不是说SOA概念不能用于本地处理。我说，这就是它真正针对的地方。但同样，SOA并不关心性能这样的事情，这是不幸的。因为那是它失败的地方。