如果你愿意的话，可以叫我巨魔，但我是认真的：新的 SOA 趋势与我 15 年前构建的客户端服务架构究竟有何不同？我一直听到 SOA，但我不明白它与我们一直以来所做的有什么不同。
早在 10 年前，我的公司就有多个客户（使用多种语言）使用相同的服务。它不是 XML（它是一种称为 Microsoft DCOM 的二进制协议），也不能通过 WSDL 自动发现，但这没关系，因为阅读文档同样容易。我们的系统甚至是“开放的”，因为我们记录了足够的信息以允许第三方与我们的服务进行对话。我们不是先驱——十年前我认识的所有其他公司都在做同样的事情。
我认为当时和现在的唯一区别是，现在互联网上提供单一服务，而 10 年前，每个客户都会托管自己的服务实例。但这不是架构问题——服务的实际存在位置对于任何使用该服务的人都是透明的。
那么，SOA 到底与我们多年来所做的事情有何不同呢？ SOA 是否只是一个营销术语，代表了一种实际上在很久以前就变得普遍的最佳实践？或者我是否错过了一些与我们一直以来所做的不同的 SOA 微妙之处？
忘记 XML。忘记 WSDL。 SOA 不是一种可以购买的技术，尽管它经常以这种方式进行营销。
SOA 的真正意义在于 IT组织。 SOA 的要点是避免出现大量具有隔离数据池的“应用程序”，这些应用程序要么根本不相互通信（因此经常重复数据），要么仅通过适配器层以低效、有缺陷的方式进行通信或EAI系统。
对于大公司来说，这是一个严重的问题 - 他们实际上有数百个独立的应用程序，但集成程度不高。到处都有重复和不一致的数据，结果是客户会生气，而且损失了真正的钱，因为计费部门不断发送取消订单的发票，而客户服务代表甚至找不到该订单，因为它在订单跟踪中被取消了。系统，但不是计费系统。
SOA 应该通过从头开始设计每个应用程序以标准化、跨平台的方式发布其服务来解决这个问题，以便其他应用程序可以访问数据而不必复制它。
从商业角度来看，这是非常可取的。流行语炒作和首字母缩略词汤只是 IT 公司利用这种需求的尝试。不幸的是，这导致许多人（包括 CEO）相信 SOA 是一种可以购买的产品，它会神奇地提高您的 IT 效率，而没有意识到只有当您也重组整个 IT（并且相当多）时，这种情况才会发生。也可能是您的业务部门）与 SOA 兼容。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
