如果你愿意，可以称我为巨魔，但我是认真的：新 SOA 趋势与我 15 年前构建的客户端服务架构有何不同？我一直在听 SOA，但我看不出它与我们一直所做的有什么不同。
早在 10 年前，我的公司有多个客户（使用多种语言）使用同一个服务。它不是 XML（它是一种称为 Microsoft DCOM 的二进制协议），也没有通过 WSDL 进行自动发现，但这没关系，因为阅读文档同样容易。我们的系统甚至是“开放的”，因为我们记录了它足以让第 3 方与我们的服务对话。我们不是先驱——我 10 年前认识的所有其他公司都在做同样的事情。
我当时和现在看到的唯一区别是现在互联网上只有一个服务可用，而 10 年前，每个客户都将托管自己的服务实例。但这不是架构问题——服务的物理存在对使用该服务的任何人都是透明的。
那么与我们多年来一直在做的事情不同的 SOA 到底是什么？SOA 是否只是一个营销术语，代表了很久以前实际上变得普遍的最佳实践？或者我是否遗漏了一些与我们一直在做的不同的 SOA？
忘记 XML。忘记 WSDL。SOA 不是您可以购买的技术，尽管它经常以这种方式进行营销。
SOA 的真正意义在于 IT组织。SOA 的重点是避免拥有大量具有隔离数据池的“应用程序”，或者根本不相互通信（因此经常重复数据），或者仅以低效、错误的方式通过适配器层或 EAI 系统。
对于大公司来说，这是一个严重的问题——他们实际上有数百个单独的应用程序没有充分集成。到处都有重复和不一致的数据，结果是客户很生气，因为计费部门不断发送取消订单的发票，而客户服务代表甚至找不到订单，因为它在订单跟踪中被取消了系统，但不是计费系统。
SOA 应该通过从头开始设计每个应用程序来解决这个问题，以便以标准化的跨平台方式发布其服务，以便其他应用程序可以访问数据而不必复制它。
从商业角度来看，这是非常可取的。流行语炒作和首字母缩略词汤只是 IT 公司试图利用这种可取性获利。不幸的是，这已经（错误地）让很多人（包括 CEO）相信 SOA 是一种您可以购买的产品，它会神奇地提高您的 IT 效率，而没有意识到只有在您也重组整个 IT 时才会发生这种情况（并且相当也可能是您的业务部门）与 SOA 兼容。
让我用集成地狱著名的鞭打男孩：电信公司。
早在 90 年代，手机公司就在我家附近，几乎与 90 年代中期放松通信管制所带来的长途经销商一样多。好吧，随着时间的推移，Bell Atlantic 成为了 Verizon 的强者，并吞并了一个又一个公司（以及至少一个 Baby Bell）。这些公司中的每一家都拥有彼此完全不兼容的技术，在塔、交换设备、计费系统中。
所以公司说，好吧，我们有这些模型来说明我们如何开展业务，让我们以 WSDL/SOAP/XSD 的形式对我们所有的技术进行友好、一致的处理——我们今天拥有的每一种语言和系统都可以连接到这个！缓慢但肯定地，该公司正在使其所有系统能够报告功能，为负载和计费目的进行询问，并以尚未考虑的方式向未来有远见的人展示。
任何人都可以构建 SOA 客户端。任何拥有 wget 和文本编辑器的人。任何人都可以解析结果（XML）。
这与过去的客户端/服务器架构有着根本的不同。前几天我只是在和某人谈论如何将基于 Cobol 和 Smalltalk 的系统连接到 SOA 架构。这是一个很容易解决的问题。告诉我你可以对你的 DCOM 系统说同样的话。
SOA只不过是一种设计方式，其中模块通过“服务”相互通信。就是这样，现在下一个问题是：究竟什么是“服务”，它与常规的“方法”有什么区别？？
服务是执行单个原子业务操作的操作。这种原子性使其可以从许多模块中高度重用。那么复杂的业务操作只是按特定顺序调用许多这些服务的编排。
SOA与具体的技术无关，只是一种具体的设计方式。
斯图加特大学的Frank Leymann教授在谈到 SOA时，将SOA作为其面向服务计算 (SOC) 研究工作的关键概念。人们看到他被问及 SOA 的定义，随后的谈话可能是一本好书。
请注意，我们的路线图是关于“面向服务的计算 (SoC)”，即面向服务背后的计算范式。面向服务的架构 (SOA) 是这种计算范式的架构实现。您可以将其与“客户端/服务器计算”作为范例和“浏览器/Web 服务器”或“DB-客户端/存储过程”作为该范例的两个（各种其他）架构实现进行比较。
...
SOA 并不是全新的。SOA 的一些个别方面在实践中使用了很长时间。例如，看看“松散耦合”：几十年来，企业一直在使用可靠的消息传递技术来集成应用程序，即松散耦合它们。不要误解我的意思，SOA 中有一些新的概念，例如由 SOA 中的概念组合产生的概念，即它们产生于涌现。
Web Service 规范使相应的技术跨平台可用。即，相应的规范并没有从根本上发明新概念，而是定义了这些概念和相应的实现如何在异构环境中工作。由此产生的互操作性是开创性的，使 SOA 成为现实。
总之，SOA 是成熟事物和新兴事物的混合体。
还有一份SoC 论文参考，日期为 2006 年 4 月。
谷歌搜索识别出Frank Leymann教授和他的 作品。
Neal Ford 对 SOA 有很多强烈的看法。你可能会觉得他的观点很有趣。
我认为 SOA 既是一个营销术语，也是现有解决方案的集成，其理念是我们出售服务，而不是出售整个软件或机器。
这里的大多数答案似乎都在传达SOA (Service Oriented architecture)关于以标准化方式构建应用程序，以便其他应用程序可以以独立于平台的方式与其交互。
我不确定从那以后意义是否发生了变化，但我有机会与一家提供 SOA 套件的公司合作，以下是我对它的看法。
当然，当你设计一个应用程序时，你不能保证它是跨平台兼容的。举个例子stock Trading systems。他们Fix protocol用来传输消息。您是否希望它现在以 XML 格式返回数据，以便它可以所谓的 SOA 兼容？当然不！SOA 是一种架构方法，可以帮助您decouple your application/services并让它们相互交互。SOA 的主干ESB (Enterprise Service Bus)用于将数据从一个服务传输到另一个服务。SOA 架构应该负责格式转换。例如 -
FIX(Service 1) -> (XML ---ESB---> XML) -> JSON (Service 2)
这些转换模块通常被称为adaptersSOA 套件并且通常是 SOA 套件的一部分。有关更多信息，请参阅另一个答案 -
当然 SOA 是一个为了营销目的而大肆宣传的词。从技术上讲，它就像反序列化和序列化数据一样简单，以便服务可以解耦和平台独立，但其背后的想法是具体的。
另请参阅Wiki 页面。
对我来说，当企业希望将一系列涉及公共域的不同应用程序集成到一组可互操作的服务中，这些服务针对单个数据源进行操作时，就会出现面向服务的架构。
对于一家新成立的公司来说，它有一个软件/软件套件的想法，我看不出一家公司如何从一开始就使用面向服务的架构。首先，每个解决方案（很可能会演变成一项服务，从而可以互操作）应该寻求孤立地解决其问题空间。
当解决方案完成并投入使用时，每个解决方案的企业功能或套件可能会成为可互操作的服务。为此，开发团队可能会采用模块化/面向组件的方法来构建解决方案（最终服务），以便更容易地将解决方案作为服务包含在面向服务的架构中。
在现有的软件孤岛将成为面向服务架构中的互操作服务的情况下，该方法允许软件项（可以分发并且可以用不同语言编写）通过公开的 API 和/或通用协议进行通信（例如一种 Web 服务）和通用数据格式（例如 XML）。
SOA 是一种方法或想法。它不是一个框架或工具。当 WDSL 和 EJB 被取消名称时，这通常会被遗忘……因为 SOA 的想法根本不是新的。
面向服务的架构 (SOA)是一种架构模式，其中软件被设计为构建块。即模块化开发，它可以灵活地以我们想要的任何方式进行组装。如果您想开始新项目而不是从头开始，我们可以重用服务，如果您想要新服务，我们可以轻松地与现有服务集成以创建新项目。所以我们可以节省大量的时间和金钱。面向服务架构的基本原则是独立于供应商、产品和技术的。
类比：使用乐高积木构建的玩具。
事实上，SOA 也利用了客户端-服务器架构。此外，SOA 是一种设计软件的方法。假设您的应用程序可以分解为简单且独立的任务，例如搜索书籍、添加新书、根据用户偏好推荐书籍等。如果您为每个任务考虑一个服务（一个 API），实际上，您正在使用 SOA。这种架构的优势在于，无论您是构建 Web 应用程序还是移动应用程序，您只需要开发的上述服务 (API)。
面向服务的体系结构 (SOA) 是一种设计方法，其中多个服务协作以提供一些最终功能集。这里的服务通常意味着完全独立的操作系统进程。这些服务之间的通信是通过网络调用而不是进程边界内的方法调用来实现的。SOA 作为一种应对大型单体应用程序挑战的方法而出现。这是一种旨在促进软件可重用性的方法；例如，两个或多个最终用户应用程序可以都使用相同的服务。它旨在使维护或重写软件变得更容易，因为理论上我们可以在不知情的情况下用另一种服务替换一种服务，只要服务的语义没有太大变化。
实际上，SOA 是定义良好的服务的集合。基本上 SOA 使用松散耦合的服务来轻松获得期望的结果。服务的实施细节对客户/消费者是隐藏的，因此实施中的任何更改都不会影响服务，直到它们之间的合同发生更改。服务提供者是根据预先确定的输入和输出执行某些业务逻辑并通过 SOA 实现公开此功能的组件。这使得基于 SOA 的系统能够更快速、更经济地响应业务。组件和 SOA 之间的主要区别在于，SOA 提供了一个开放标准消息，它不特定于任何编程语言或平台。因此，您可以实现跨平台和技术的高度松散耦合和互操作性。面向服务的架构 (SOA)