这是您第一次登陆到 developerWorks，已经自动为您创建了您的概要文件。 选择您概要文件中可以公开的信息的信息（如姓名、国家/地区，以及公司），这些信息同时也会与您所发布的内容相关联。 您可以随时更新您的 IBM 账号。

所有提交的信息确保安全。

当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。

所有提交的信息确保安全。

My developerWorks:

我的通知：

退出

选择语言：

SOA 的优点、缺点与糟糕之处

SOA 的优点与缺点

Jens Andexer, IT 架构师, WSO2 Inc

Jens Andexer 是 IBM SOA Advance Technologies 小组的执行 IT 架构师，并且是撒哈拉以南非洲的架构主管。他在世界各地从事软件开发工已经作超过 25 年，专门从事金融系统、公营部门、银行与保险行业。他的职业生涯开始于一名 PL/I 维护程序员，之后 Jens 在许多大型复杂的软件开发项目中负责领导架构师。在其职业生涯中期获得计算机科学（软件工程）硕士学位之后，于 1998 年加入了 IBM 公司，现在他为欧洲和非洲的 SOA 客户带来了 host 技术、软件开发以及软件维护方面的丰富经验。

Willem Bekker, 架构计划负责人, WSO2 Inc

Willem Bekker 目前是标准银行的架构计划负责人。Willem 拥有学士学位以及超过 15 年的IT 行业经验。其中有 12 年 ERP Technical 领域的经验。Willem 已经树立了作为 “Turn Around” 代理的声誉，通过运用他的能力来优化对信息技术的投资，从而提高业务效率。

简介： 面向服务的体系架构（SOA）是当前的一个热门话题，并且公平地说，这种架构类型拥有一些非常好的特点。但是在拥有良好特点的同时也伴随有缺点甚至少许糟糕的问题。

发布日期： 2010 年 4 月 26 日
级别： 中级
其他语言版本： 英文
访问情况： 6317 次浏览
评论：

简介

IT 战略能够反映出 IT 部门如何来支持企业战略的交付。从根本上来说，这意味着组织需要让他们的 IT 部门高效地进行日常运营并且支持快速、成本低廉地进行新产品和服务的运营。面向服务的体系架构（SOA）在这方面有优势，但并不是十全十美。

下表突出了对 SOA 良好、不良与糟糕的业务影响描述的示例。

表 1. 优点、缺点、糟糕之处

SOA 的良好业务影响	SOA 的不良业务影响	SOA 糟糕的业务影响
敏捷性 - SOA 支持更加快速地开发业务流程以及更加轻松地对业务流程进行改变。它可以使组织更迅速地适应他们业务环境的改变。这就转化成为实际的市场优势，因为它能够使产品和服务比竞争对手更快速地推向市场。	组织结构的改变 - 在每个 SOA 的中心都有一个卓越中心（COE）。COE 就是一个控制 SOA 技术开发以及向组织的其他人员提供专业知识的新实体。SOA COE 是对任何组织来说都是新增加的，并且由此推出，当它实力雄厚并且在这里所做的决定会影响组织的其他人员时，它的引入可能会导致冲突。	转变并不容易 - 转化和组织成为以服务为中心并不容易。过渡到 SOA 的特点是演变而不是革命。以孤岛的传统形式创建的组织需要改变它们的结构，以充分利用成为以服务为中心的优势。这种转变是复杂的、昂贵的，而且从来不缺少这种变革的反对者。
一致性 - 业务与 IT 之间更加紧密的合作关系抛开了阻碍 IT 实现业务需求的传统障碍。业务领域中的服务足迹是一项业务功能，并且用业务术语对其进行了描述。它实现的细节是隐藏的。	组织权力结构的改变将服务的所有权和控制权放到业务领域中，会改变组织中的权力结构。这样做通常会遭遇来自那些有维持现状特权的人的阻力。	文化改变 - SOA 不仅仅代表着技术的改变。伴随着这种改革产生了一个组织的文化变革，因为它成为了价值的驱动。组织必须明白敏捷意味着什么以及如何充分开发其自身的敏捷性。糟糕的事实是，这是最难学习的课程之一。
业务流程的改进 - 一般而言，任何 SOA 与业务流程的再次思考都是相关的。这种业务流程重构对优化组织运营业务的方式而言是一次机会。良好的重构工作能够使业务的运营效率得到显著提高。	业务面临的新挑战 - 业务必须给予 IT 更多的指导。业务线必须对服务及增强行使所有权并对其负责，从而启动开发与变化周期，因为它们将推动这一进程。这不是一种典型的由业务线进行补充的作用，这将会导致不合适的改变。
灵活性 - 在 SOA 中坚持良好的软件工程实践能够提高 IT 对业务需求的响应。缩短了产品和服务的上市时间，降低了开发与改变流程的成本。	IT 在变得更简单之前会越来越复杂 - 利用一套如业务流程执行引擎和 ESB 的技术来实现 SOA。把这种技术添加到 IT 规划中并不会让它更加简单，即使当它的优势远远超过了它的成本。然而，IT 规划更复杂并不意味着它就不能以更简单的形式出现。这种服务的推出让 IT 的复杂性成为秘密。这些服务的消费者不需要知道服务内部是如何运行的。结果，任何发生在后端的的合理化操作，都可以隐藏在服务界面之后。	技术本身不会体现价值 - 专注于基础架构和技术的 SOA 是很可能失败的。SOA 举措是建立在比以往更快速更低成本地提供业务价值的承诺之上的。一种过于重视技术的 SOA 是不可能实现该承诺的，因为它们不会显示出业务人员希望看到的价值。灵活性只有在加速运营性业务需求，或者通过支持业务的合理性来降低操作系统成本时才会被认为是业务价值。以技术为中心的举措一般不会这样做。
数据统一 - 服务接口可提供统一数据特征的机会，以使服务接口使用遵照统一的数据模型的数据。统一在这里的意思是通用：结构 - 元素之间的结构关系是相同的，因此例如地址一贯地包含门牌号、街道、城市、地区和邮政编码。语义 - 语义是指含义以及数据的使用。数据必须有统一的含义，并且必须以不会产生歧义的方式使用。例如客户的概念可能会在网站上遇到，与帐户所有者形成对比。格式 - 数据的表现方式很重要。DDMMYYYY 格式的日期不能与 MMDDYYYY 格式混淆。类型 - 类型是由数据的表现形式以及一套可以执行的行为决定的。时间 - 时间指的是属性更新的时候。在某些情况下属性会在前端系统进行实时更新。然而一些属性只在定期的批处理时进行更新。生命周期 - 在什么情况下将数据添加到数据库中，什么时候进行更新，以及什么时候、以什么方式最终从数据库中删除数据。	没有数据视图 - 服务的标准接口需要统一的数据视图。这种统一视图通常不存在，并且设法开发统一视图时往往会发现组织中的视图非常不同。	可能无法实现统一 - 使数据的所有特点一致几乎不太可能实现。除了上述问题之外，与 “脏数据” 相关的问题也总是存在。处理一致性是设计服务接口面临的巨大挑战之一。尴尬的事实是建立统一的服务接口是一件非常困难的事情。
运行监控 - 用于支持 SOA 的技术和原理使对业务流程的监控更加轻松。这种监控类型支持来自日常运行的反馈。该反馈可用来衡量组织对其战略目标的实现情况如何。传统的业务流程（BP）与表现逻辑都写入了包含业务逻辑的相同程序。所能希望的最好结果就是至少将不同逻辑类型组合在一起，但是即使这一点也往往难以实现，其结果是很难监控逻辑范畴。例如业务流程只能作为应用程序的一部分来监控，因为它不能被分离出来。 SOA 通常伴随着业务流程执行引擎。这种技术的引入可促进业务流程逻辑被分配到一个点上。在一个点上拥有 BP 使 BP 监控成为可能，而无需在应用逻辑中使用 BP 逻辑。这不是 SOA 的专有技术，但是用于支持 SOA 与来自 SOA 良好软件工程实践规则的技术能够使该技术在 SOA 中更加轻松地得以实现。	监控复杂性 - 开发一个针对组织目标提供反馈的业务流程监控模型是一项需要专业技能的重要工作。
利用操作平台 - SOA 使用操作平台为服务提供业务功能。这意味着对现有系统的投资可通过将其重新包装到服务中来使用。	技术不匹配 - 在某些情况下并不能轻松地对操作平台进行重新打包，原因是业务功能结构与需求不匹配。例如，如果一个添加新客户的事务在姓名和地址添加到客户数据库之后有一个提交点，并且在安全数据被添加之后有第二个提交点，那么这两种操作将紧密链接。	可能需要做出改变 - 在某些情况下可能需要改变操作平台。当需要在 ERP 中作出改变时，供应商非常不情愿做出改变。如果组织决定在内部作出变革，服务资金必须考虑维护成本。

回页首

结束语

欲使 SOA 获得成功，业务与 IT 必须与他们的目标和目的保持一致。 IT 推动的 SOA 失败的原因是它们被理解为技术的变化，并不对业务产生直接利益。SOA 案例必须加强组织现有的目标和战略，并且将超越以 IT 为中心的方法。这代表了一种文化变革，变革后由业务期望值推动 IT 优先级，再加上业务与 IT 之间的合作文化，就为成功奠定了坚实的基础。

参考资料

学习