SOA实现与交付指南

SOA 实现与交付指南 SOA 技术专题之“SOA 实现与交付指南” Page 2 of 26 SOA 实现与交付指南 随着 SOA渐成 IT潮流， 越来越多的 SOA项目启动了。有些项目彻底失败了，有些项 目则勉强成功了。为什么有些项目成功了，有些去失败了，最大的问题出在哪里？如何吸 取这些失败项目的教训，并形成自己规划 SOA 路线图所需的远见与策略。同样的，我们又 要如何判断 SOA项目是否已经成功实现？这些将是未来 SOA项目成功实现的关键。下面让 我们来看看个中因由。 SOA 最大的问题 过去一年，即使在经济衰退的情况下，也有很多人对面向服务架构（SOA）感兴趣。 对照 Forrester的商业数据服务企业和中小企业软件（SMB）的调查结果，2008 年第四季 度到 2009年第四季度，北美和欧洲的企业（10000+ 员工）的 SOA普及程度（那些目前使 用 SOA 的，再加上准备使用 SOA）增长了 10%，中小企业增长了 33%。从时间上讲，这是一 个行业良好增长的趋势，但是有些人说 SOA 已经死了。  SOA 最大的问题是什么？  SOA 九大迷思 为什么 SOA 没有实现 敏捷性只能来自于业务和 IT的创新意愿，并通过废除死板的业务流程，脱掉实现 BPM、CRM和 ECM这身紧身衣，放权给用户才能达到。以实现 SOA的名义把流程编码成固定 的程序，将会损害我们的业务。既然，我们了解这些，那为什么 SOA 还是没有实现呢？我 们究竟错在哪里？ SOA 技术专题之“SOA 实现与交付指南” Page 3 of 26  为什么 SOA 没有实现：我们错在哪里？  为什么 SOA 没有实现：IT与流程有何关系？  为什么 SOA 没有实现：情感和敏捷性  为什么 SOA 没有实现：我们需要治理吗？  为什么 SOA 没有实现：SOA 前路何方？ SOA 何时真正交付 随着近年来有关”SOA 失败”的讨论，有一个令人迷惑的问题就是组织机构如何知道 他们的 SOA 项目是否真的“失败”了呢？SOA 也许有可能带来各种各样的价值，但是组织 机构远没有意识到这些价值怎么产生？那么，谁知道呢——也许那些“失败“真的带来了 不同。  十二步规划 了解 SOA何时真正交付  大师论战：SOA 何时真正实现？ SOA 技术专题之“SOA 实现与交付指南” Page 4 of 26 SOA 最大的问题是什么？ 过去一年，即使在经济衰退的情况下，也有很多人对面向服务架构（SOA）感兴趣。 对照 Forrester的商业数据服务企业和中小企业软件（SMB）的调查结果，2008 年第四季 度到 2009年第四季度，北美和欧洲的企业（10000+ 员工）的 SOA普及程度（那些目前使 用 SOA 的，再加上准备使用 SOA）增长了 10%，中小企业增长了 33%。从时间上讲，这是一 个行业良好增长的趋势，但是有些人说 SOA 已经死了。 TT SOA 编辑推荐：2010 年 SOA 现状调查报告 除了 SOA日益普及以外，SOA用户对 SOA 的发展和满意程度反应强烈。在 TechTarget/Forrester Research上对 2010 年 SOA 现状的调查来看，61%的人表示，他们 目前使用 SOA，有 10%或者更多的人，使用 SOA在他们的交付 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 的项目上——有 12%的 人，把 SOA 使用在了他们 50%以上的项目上。但是那些认为 SOA已死的人真的很让人愤 怒： 66%人表示他们的 SOA 提议取得成功，23%的人表示他们已经取得相当大的成功。事 实上，因为 SOA成功来之不易，存在一些利益的争斗，就需要组织的完善和纪律约束，— —但是业内 SOA的领导者已经展示了 SOA成功的方法。 但是有一些非常有趣并另人惊讶的数据：当被问到他们使用 SOA 最大的问题时，调查 对象表示，目前为止，SOA 项目面临的最大挑战已经超越了 SOA 本身。27%的人认为，最大 的担心是“如何通过多个项目（如 BPM、事件、BI、规则等）整合的方式设计 SOA？”。 只有 13%的回卷者选择了第二大担忧，即“[为 SOA]评估及选择合适的工具”。换言之， 工业界已经认识到，这是一个多元技术的世界，单一技术战略可能会错失目标。SOA固然 重要，但是业务技术解决方案需要的不仅仅是 SOA，还需要 SOA 与其他方法以及设计域结 合起来才能满足需求。 SOA 技术专题之“SOA 实现与交付指南” Page 5 of 26 换句话说，业界的人们认识到，个别的、竖井技术策略不能达到目标——这是一个多 技术的世界。SOA 固然重要，但是业务技术（BT）解决方案不仅仅是需要更多的 SOA，他 们需要 SOA 方法与其他技术和设计领域相结合的方法。通过包装主要的业务交易作为一个 外加服务，SOA为业务转换提供了一个强大的基础。29%的调查对象说，他们使用 SOA 来支 持业务转型战略 — 但是流程、事件、规则、嵌入式分析，也体现了更多的业务设计的重 要方面和建立灵活的方式来处理当前的业务变化。 SOA的基本性质强调这样一个事实，71%的调查对象表示，SOA 作为一个技术是［他们 的］组织的技术方面的努力取得的最关键成功。然而他们评价的 BPM、业务规则、传统的 现代化进程、Ajax 和丰富的网络应用、云计算、事件处理和 web导向架构，作为“最关键 的”技术，但是回答调查问题的人从 37%降到 21%（多选）。 多年来， Forrester 一直追求更大的 SOA蓝图。在 2005，我们发布数字业务架构愿 景——技术平台构重新构造成四个主要的多技术整合的领域已业务元数据为核心，定义流 程、策略、事件、信息流以及许多你的其他业务的方面。建立一个数字业务架构， Forrester公司现在定义我们的业务能力架构的愿景，提供了新的方法来规划和发展一个 多技术战略，建立并围绕业务的成果不断提高。对于 BT前进道路的成功，你必须学会进 行你的业务的设计和技术体现的整合。 (作者：Randy Heffner 译者：刘志超 来源：TechTarget 中国 ) 原文链接：http://www.searchsoa.com.cn/showcontent_36732.htm SOA 技术专题之“SOA 实现与交付指南” Page 6 of 26 SOA 九大迷思 编者按：本文由原刊于 ebizQ SOA in Action 网站的前版增补而成。 去年秋天，我们着手来理清面向服务和 SOA的真正含义，其结果便是 SOA 宣言。我们 希望籍此可以更好的澄清 SOA的含义。 然而，关于 SOA，至今仍存在许多迷思。很多人，甚至是 IT人员都说他们并不完全了 解 SOA 可以做什么，以及如何去构建 SOA。SOA 已经被软件厂商和分析师们夸大到令人难 以置信的程度，但是，却鲜见有介绍 SOA基本含义的资料。 以下是关于 SOA仍存的一些迷思： 第一，SOA和云计算的区别是什么？许多厂商，正如 Dave Linthicum所说，正在给 他们的产品贴上“云”的标签 ——只是简单的把他们的 SOA 产品更名为云产品。那么， 这其中有什么区别呢？不论 SOA还是云计算，都是要将服务 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 化，从而可以实现复用。 正如 Dave所讲，云的形成需要同样的企业架构和治理 — 包括技术，人员和流程的治 理。眼下很多公司正在落实这样的治理来管理 SOA，而这些年来 SOA 治理的经验教训也能 够帮助到云的部署。 第二，为什么大家对云计算迷的发狂，但却对 SOA 兴味索然——虽然他们在本质上都 是相同的东西？如果你了解地透彻的话，云其实是提供或获取跨企业的服务复用。同样 地，Enterprise 2.0 正在应用服务来实现更大范围的协作，以及混搭（mash up）终端用 户的信息。这些都是面向服务的架构，并且依赖基于 SOA的原则来运行。或许这有点类似 于人们对喷气推进技术还是小岛上的周末度假胜地更感兴趣 ¬—— 后者需要利用喷气 推进技术才能到达那里。 SOA 技术专题之“SOA 实现与交付指南” Page 7 of 26 第三，在尚未有人真正应用 SOA 之时，如何断定 SOA 将会失败？不少学者和分析家宣 称 SOA 将是一个失败的想法，但 SOA 是一个不断演进的过程，至今还没有人真正完成 SOA 的部署工作。最近大家都一窝蜂地宣布 SOA半路夭折了，但是，我看到的和我亲自做的调 查显示，大多数公司仍然在规划或考虑他们的第一个面向服务的项目。事实上，这些日子 我不断听到的有关 SOA面临的重大挑战是：SOA太成功了，在那些正努力部署 SOA 的企业 中，太多的服务正在被不容分辩地添加进来或创建---或者被要求创建。这也就是为什么 有这么多厂商都大肆宣传 SOA治理。 第四，如果 SOA真的失败得一塌糊涂，那么，这些“恐怖”的故事在哪里呢？不少学 者和分析家宣称 SOA将是一个失败的想法，但 SOA是一个不断演进的过程，至今还没有人 真正完成 SOA的部署工作。最近大家都一窝蜂地宣布 SOA半路夭折了，但是，我看到的和 我亲自做的调查显示，大多数公司仍然在规划或考虑他们的第一个面向服务的项目。事实 上，这些日子我不断听到的有关 SOA 面临的重大挑战是：SOA 太成功了，在那些正努力部 署 SOA 的企业中，太多的服务正在被不容分辩地添加进来或创建或者被要求创建。这也就 是为什么有这么多厂商都大肆宣传 SOA 治理。 第五，人们如何知道一个 SOA 项目何时才算成功或不成功呢？有关 SOA一个自相矛盾 的观点是——那些最倾向于采用 SOA 的企业恰恰是对 SOA需求最低的企业。如果企业的管 理层有远见有预见，能够支持 SOA，那么他们极有可能也在同时推进其他项目，比如商业 智能和分析、数据仓库等等。他们正在取得的成功有多少可以直接归因于 SOA 呢？成功的 定义是什么？成本节省？通过 Web服务完成了某个端到端的过程？ 这是 SOA首先要面临的一个艰难的挑战——成功是一个长期努力后才能取得的结果，其标 志是多个业务单位之间共享服务，从而使得企业的服务开发时间明显缩减，或者，由于企 业底层的基础设施的灵活性进一步提高，这使得企业只需重新配置即可快速地响应市场对 产品或服务的新需求。 SOA 技术专题之“SOA 实现与交付指南” Page 8 of 26 但是，在市场上唯一能真正衡量长期成功的标准是企业收入或股票价值的不断增加， 除了 SOA，还有很多其它因素会对此造成影响。真正的问题在于弄清楚如何衡量 SOA对于 企业成功的贡献。 SOA本身的“成功”同这是毫无关联的。 第六，到底有多少全功能的真正的 SOA 被部署了？一些分析机构表示，目前有很多公 司(75%或者更多)正在实施 SOA项目。还有一些分析机构则表示，目前部署 SOA 的企业只 有 4%。他们衡量的标准是什么? 根据服务的数量？还是这些服务的粒度?根据能够访问具 有服务功能的松散耦合组件的应用或进程的数量?什么时候“只是一堆 Web服务”会成为 SOA？满足什么条件的 Web 服务，有可能经过更好的“照顾”---治理、注册、管理等等， 而会变得更加 SOA 化？ 第七，如果 SOA“与技术无关”，为什么是技术人员在推动它？无时无刻，在每个会 议，每个分析家的注解，在每篇文章中我们都会见到这句话。SOA，绝对、肯定、确实、 “与技术无关”，然而，它是技术厂商在宣传推销，最终是 IT部门在操作运转。从来没 有听说过销售部门在实施 SOA。 第八，软件供应商是如何给用户灌输 SOA 观念？SOA 将会使得软件供应商自己的产品 更容易被用户所抛弃。 这对软件供应商是福还是祸呢？SOA 的真正好处在于，这些服务几 乎可以根据需求随意调换。这也正是软件厂商面临的难题之一，尤其是对于那些大力倡导 SOA的厂商（如果用户实现了 SOA，这些软件厂商的产品就有可能随时被替换掉）。 第九，谁为 SOA买单呢？归根到底，还是钱的问题。哪个部门会花费大量金钱和人力 去搭建这样一个会被其它任何人使用的系统呢？其它部门不需要花费任何资源就能利用该 系统提供的服务。 具有 SOA功能的应用在开始阶段可能会比传统的点对点接口需要更多 的成本，而投资回报率在规模经济效益中将会体现出来。同先期实施的成本较低的点到点 的应用相比，长远来看，SOA产生的规模经济效益可以带来更好的投资回报率。然而，如 果企业认为他们正在推进 SOA，但最后却没有投资回报率或者很低，因为他们部署的不是 真正的 SOA——仍然是点对点的接口：这种情况就是一个很大的风险。谁会去冒这样的风 险?或者谁被要求去承担这样的风险呢？ SOA 技术专题之“SOA 实现与交付指南” Page 9 of 26 这是 SOA首先要面临的一个艰难的挑战——成功是一个长期努力后才能取得的结果， 其标志是多个业务单位之间共享服务，从而使得企业的服务开发时间明显缩减，或者，由 于企业底层的基础设施的灵活性进一步提高，这使得企业只需重新配置即可快速地响应市 场对产品或服务的新需求。 但是，在市场上唯一能真正衡量长期成功的标准是企业收入或股票价值的不断增加， 除了 SOA，还有很多其它因素会对此造成影响。真正的问题在于弄清楚如何衡量 SOA对于 企业成功的贡献。SOA本身的“成功”同这是毫无关联的。 (作者：Joe McKendrick 译者：李松 来源：TechTarget 中国) 原文链接：http://www.searchsoa.com.cn/showcontent_35853.htm SOA 技术专题之“SOA 实现与交付指南” Page 10 of 26 为什么 SOA 没有实现：我们错在哪里？ 如果你的 IT预期要令业务更敏捷，你就得转到 SOA 来，是吧？我不同意，为什么 呢？因为大家又一次把因果混为一谈了。不管有没有 SOA，一个敏捷的组织都应该能够充 分地利用 IT。SOA 并不会让业务或者人更为敏捷。 敏捷性只能来自于业务和 IT的创新意愿，并通过废除死板的业务流程，脱掉实现 BPM、CRM和 ECM这身紧身衣，放权给用户才能达到。把流程编码为僵硬的 JAVA，对 SOA 来说无异于业务杀手。 为什么 SOA被吹嘘到令人难以置信的程度？ SOA的风潮热得过头了，随后由于大家都随大流卖起产品和服务而陷于泥潭之中。 《网络计算杂志》。因此曾把 SOA称为最受鄙视的流行语也就不出奇了。IBM（Tivoli 和 WebSphere）、Oracle （Fusion）等玩起了“卖不出就改名”的游戏。是要做出某些改 变，但应不仅限于产品名。 我们是不是甚至连错在哪儿都不知道？ 我严重怀疑这一点。很有影响的量子物理学家 David Bohm在 1980年写道：“分解在 我们的社会是如此之广泛，以至于干扰到了我们的认识，阻止我们去解决最简单的问 题。”。似曾相识吧？我们把一切都塞进小盒子里，为每一个业务问题都购买了最佳组合 的软件解决方案，现在，我们诧异地发现，它们不能工作到一起。 在过程的层次上，我们致力于将过程剖解为小的片段，因为这种方式下它们似乎更易 于管理。1993 年， Thomas Davenport 所述的过程碎片是这样的： SOA 技术专题之“SOA 实现与交付指南” Page 11 of 26 实现就能连接。但更恰当的描述是福特（Foote）和育德尔（Yoder）1999 年做出的， 他们是这样写的： 我认为 David Bohm是对的，分解对于我们在能力范围内进行思考、组织和 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 是必 要的。然而，我们周遭的世界并非由过程的片段造就的，因此当前的 SOA方案将无法解决 碎片化，相反，会在更高层次上导致一场软件工程的噩梦。在进行 IT系统的碎片清理之 前，需要对业务流程和流程变更管理好好审视一番。 业务流程的 1911风格 有些人说 SOA 就是流程管理的延伸。然而，BPM 支持者陷入了 1911 年的泰勒主义，而 SOA把局面搞得更糟，因为仍存在碎片化的变更管理。 Frederick Taylor相信分解和专门化，推荐僵化的结构化企业。因此，每一个 IT 应 用都代表着那样的一个业务流程片段，因为根据达文波特，倘不若此的话，我们就不会需 要它。但业务流程又是什么呢？ Rummler和 Brache（1990）提议说“业务流程是一系列 设计用于为客户生产产品或服务的步骤”。这压根儿就是不对的。 是的，为了给用户以及流程本身更多空间，的确有部分僵化的决策流程和特定的方 案。奇怪的是，好像几乎没人意识到我们需要的是创建一个拥有动态关联过程和企业通讯 的敏捷企业。很显然，通信过程的内容状态是受控的，而非无缝的行动。商务沟通并不仅 仅是一份文档或者电子邮件，它可以是任何东西：一份选定的菜单、一个网页、文档上的 标签、一条 记录 混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载 、一张图片或甚至语音记录或者视频。无论在业务流程分析上要花多少时 间和金钱，一旦正式的时候，商务沟通这一点仍是需要的。基于这个原因，协作工具及电 子邮件现在得到了广泛使用。任何分析都需要沟通。 在《企业再造》一书中， Hammer 和 Champy提出一个很重要的建议：“单个的任务或 过程都不重要，重要的只有结果”。BPM系统、BPR 项目无力适应面向目标的动态性。 SOA 技术专题之“SOA 实现与交付指南” Page 12 of 26 Damelio 在《流程映射基础》（Basics of Process Mapping）一书中写道：“示意图 和流程图令工作可视化„„它们展现了某段时间的快照„„”。这就是设想中的业务流 程，如博姆所言。我们需要分块来进行理解，但生活的运作方式并非如此。 (作者：Max J. Pucher 译者：杨华军 来源：TechTarget 中国) 原文链接：http://www.searchsoa.com.cn/showcontent_34489.htm SOA 技术专题之“SOA 实现与交付指南” Page 13 of 26 为什么 SOA 没有实现：IT 与流程有何关系？ 在《IT重要吗？》一书中， Nicolas G.Carr写道：“„„在二十世纪九十年代里， 许多战略投资都浪费掉了„„企业高管对 IT的怀疑不断增长„„”并宣称 IT 现在是一种 商品，不再能制造竞争性优势。我倾向于赞同他，但问题不在 IT，而在于商业用户对 IT 的需求是什么！ 用户希望以其自身难以言语表达的方式组织其工作，而管理则想严格地控制用户流 程。要做到两全其美，IT 对此肯定毫无头绪，因为底层的技术（大部分是因为 Windows、 Java及 XML）已经变得几乎不可管理。SOA 对于已经复杂得难以置信地的局面而言，无异 于火上浇油。 商业用户也是人，他们会指着某样东西然后说：“这个我喜欢，那个我不喜欢”。一 旦用户看到一个漂亮的 GUI 界面，他们会认为里面也一定是一样的。用户购买的是 GUI， 而非架构、灵活性或长期可管理性。 可是他们却要求要 99.99%的可用性（对于底层为基于大型机的银行交易系统来说是可 以的）；但是在员工的精神和身体的平均可用性至多是 50%的情况下，对可用性的期望与 当前的技术复杂性联系在一起，令上市周期十分漫长。用户把 IT 当做不近人情的东西， 他们的所想正是其所得。而正因为如此，业务正在为 IT外包和治理的控制而做斗争。这 主意糟透了！ 遵守低效的治理规则通常比需要哪些成分更重要。在其 ZD-Net的博客上， Joe McKendrick建议“将 SOA 转向 HOA（面向人的架构）， 没有治理就没有 SOA，但也许我们 SOA 技术专题之“SOA 实现与交付指南” Page 14 of 26 不需要太多的治理。”我想补充一下：如果 SOA要求对我们的业务进行甚至更为僵化的控 制和管理的话，也许我们根本就不需要它？ 业务流程决策 面对现实吧：在泰勒式（Tayloristic）二维的过程图里，AGILE-SOA-jBPEL-XML 型的 企业无法具备远见！最新的流行语“IT 工业化”描述了我们的计划——为迟钝的商业用户 创建亨利•福特式的 IT流程流水线。 事情变得更糟了。2005 年，达文波特和哈里斯在一篇 MIT-Sloan 管理学院的文章中 MIT进一步宣称：“与需要人们识别问题或开始进行分析不同，公司通常将决策能力嵌入 到日常的工作流当中去。那些系统随后感知在线数据，运用编纂成典的知识或逻辑，然后 在最少量的人类干预的情况下做出决策。” 在“超级运算器：为什么说通过数字思考是变得聪明的新途径”一书中， Ian Ayres 也主张海量数据集使以前不可能的预测成为可能，统计方法也比专家直觉所做出的决策更 为精确。 我的观点是，不管自动化与否商业智能都是一堆令人费解的混乱数据，对商业决策而 言无足轻重。想象一下，我们不仅是要盯住的流程（的执行者），还是代码化决策知识 （的来源）？那样的话，公司通通都要完蛋，因为“统计数据事实”只是一种假象，来自 于过去的最佳均值并不能应用于当前的决策。跟相关的经理、员工以及客户进行面对面的 交谈会给你一个感性的直观感受，以便做出正确的决定，那是统计所无法做到的。 (作者：Max J. Pucher 译者：杨华军 来源：TechTarget 中国) 原文链接：http://www.searchsoa.com.cn/showcontent_34506.htm SOA 技术专题之“SOA 实现与交付指南” Page 15 of 26 为什么 SOA 没有实现：情感和敏捷性 你也许要问：情感？ 有人要我把“情感”换成“本能（instinct）”，因为情感看起来是那么的负面。我 不同意！ 直觉更多是用在根本不需要思考的条件反射式的领域。也许用感受要好一些， 但感受同样需要我们人类本性深处的感情。直觉（intuition）还能接受，因为直觉是一 项情感官能。不幸的是，情感作为理智的对立面是现如今的一种设定。也许并非如此。在 英国和美国的河流上为什么会检测到抗抑郁药物百忧解（Prozac）的存在呢？因为人们不 断被迫要求成为理性而非感性的人。深入剖析一下自己，你会感觉到这是违背人类本性 的，而这正是我们致病（译者：抑郁症）的原因。 人类的决策更像是大脑的一种偏向于感性的模式匹配能力。理性只能用于决策后评估 的验证或调整。是不是说不强的企业家和经理大部分都是些很感性化、甚至不理性的人？ 绝对是！先驱者如布罗卡（Broca，1878）、培帕兹（Papez，1937）及麦克林 （MacLean ，1952）等都主张情感与大脑中枢的一组称为边缘系统的结构相关，包括了下 丘脑、扣带皮层以及海马等。安东尼奥•达马西奥（Antonio Damasio） ，现为南加州大 学的神经系统学教授，长期从事处理记忆、语言、感情及决策的神经系统的研究。在 1994 年出版的《笛卡尔的错误：感性、理性及人类大脑》一书中，他记录了自己的发现：“感 情中枢功能紊乱的人在决策时会面临严重困难。”。因此人类决策——无论是否基于直觉 ——都是偏向于感性的，那么请问流程分析顾问先生，你又打算如何对那个东西进行编码 呢？ 为了通过计算的帮助来改善决策，我们需要技术发明来对人类凭直觉做出的决策进行 建模，这远远超出逻辑规则的范畴。While 兰•艾尔斯在提到神经网络和模式匹配的时候， 他没能真正理解这一点，那就是此二者均不需要统计数据，而只需要与真实数据关联的决 SOA 技术专题之“SOA 实现与交付指南” Page 16 of 26 策点。有多少人做出了什么决定并不重要，重要的是每一个个体都使用了什么样的数据模 式来做出决定。因此，我们并不需要使用未经验证的数学假设对毫无意义且并不精确的数 据进行反复的处理，而是要把现在的计算能力运用到交互式地从人类身上学习决策上。 那“敏捷性”又是什么？ 我是认真的：敏捷性是人类的特性，而非系统的功能。是什么导致当前的组织丧失敏 捷呢？ 是 Java/XML 这团“大泥球”？泰勒式的 BPM？ Windows DLL 地狱？要我说，是因 为人们身上缺乏敏捷性，目光短浅，抗拒真正的创新。一个敏捷的 IT部门，需要有一位 真正敏捷的 CIO来运作，要能取得一个敏捷的董事会的支持，其创建出的应用平台，应能 将强大的威力交到熟练地业务用户手上，用户本身还得有敏捷的意愿。 在其 SOA白皮书上， IBM、 BEA（译者：现为 Oracle所收购）、TIBCO 及 Oracle 之 流为创建 SOA赋予了无穷维度的技术复杂性，而这个星球根本就没有那么多的 IT 人力资 源，甚至连处理那样的 SOA 项目的 2%都做不到（来源：Max Pucher，2007，《35 年 IT猜 想》）。请记住，一旦洞已经深到你无法爬出去，把洞挖得更深并不会对你的状况有所改 善。 KISS——简单一点，笨蛋！（Keep it simple, stupid!） 简化是必要的，鄙人不才，2000 至 2001 年间，正是在下首先提议通过 Papyrus WebRepository将出入库资料（Inbound and Outbound documents）合并进闭环的 CRM 流 程中—每一位大名鼎鼎的分析师听完之后都是一脸茫然！而今天，你可以在每一个 ECM 供 应商的白皮书上找到入库/出库（Inbound/Outbound）的字样。我要一并谢谢你们，因为 抄袭就是最由衷的奉承。现在，我已经提议要对 ECM、BPM和 CRM进行合并了„„所以你 们最好停止挖坑了！ (作者：Max J. Pucher 译者：杨华军 来源：TechTarget 中国) 原文链接：http://www.searchsoa.com.cn/showcontent_34548.htm SOA 技术专题之“SOA 实现与交付指南” Page 17 of 26 为什么 SOA 没有实现：我们需要治理吗？ 我们需要治理吗？ 我的确同意，我们需要一些监督来令用户满意。你喜欢的话可以把它称为治理，但那 仅是用户和 IT之间的管理。如果你的 IT已经是一幅支离破碎的景象，拥有了太多的外包 和外部顾问，也许你的确需要进行治理来度过难关。 SOA 还是变更管理？ IT 的核心问题是变更管理。变更管理与元数据有关：有关数据的结构化数据，“描 述、解释、定位信息源或令其更易于获取、使用或管理”。 我被告知：你说得对，但这些我们都是通过 XML 完成的。听着，供 SOAP 使用的 WSDL 元数据，以及供 WSDL使用的 UDDI元数据还是不够的，因为这两者都没有跟用户界面和流 程关联起来。你还需要 DTD、XSL、XSLT、XPATH、BPML 以及 BPEL和大量 Java 代码区验证 数据是否合法，并把它用到硬编码的决策模块中去。 在《SOA 傻瓜教程》中，偏向 BEA的作者因此建议提供为 Java程序一个容器 （repository），同时提供一个注册表项（registry）用于动态地跟 SOA服务关联。鉴于 BEA产品领域拥有 Tuxedo 这个老产品，以及可编程 Java 产品 Weblogic和收购的 Aqualogic工作流，其两个管理产品的理由是可以理解的。 然而，服务接口中元数据的变更并不会自动传播到所有的用户界面、java 模块、流程 定义、XML transform以及所有的数据库上去。用户自己没有手段快速简便地进行变更。 由于不存在通用的版本管理和部署管理，我们还是在原地踏步——深陷于一个“大泥球” 里，只不过更加复杂了。 SOA 技术专题之“SOA 实现与交付指南” Page 18 of 26 标准——你在哪里？ 有些人相信标准是救世主。Open Group、Oasis、 OMG等等，各不相同的组织制定许 多 SOA 的定义。在关键问题上，大部分定义仍存缺失，比如全球交易、安全及事件处理。 因此，仍然没有实现 SOA的标准方式。 若干供应商提供了 SOA 变更管理工具，如 HP-Mercury、IBM Tivoli等。这些巨大的 投资是用于处理 SOA基础设施和网络的， 不能用于处理用户所需的前端的业务服务。 如你所见，沧海横流，这个世界是一整个杂乱无章。我见到的投标 申请书 入党申请书下载入党申请书 下载入党申请书范文下载下载入党申请书民事再审申请书免费下载 （RFP） 里，在要求 SOA兼容的同时还要具备“全功能 API”。有投标申请书中要求 XML 和 Java 标 准这样的空中楼阁。（不过）在投标申请书里你只需简单地回答“满足”即可。许多 IT 人士似乎认为 SOA 是解决 Java、XML无标准现状的灵丹妙药，而它至多仅是将部分问题掩 盖了起来。 (作者：Max J. Pucher 译者：杨华军 来源：TechTarget 中国) 原文链接：http://www.searchsoa.com.cn/showcontent_34566.htm SOA 技术专题之“SOA 实现与交付指南” Page 19 of 26 为什么 SOA 没有实现：SOA 前路何方？ 我认为要不了几年，SOA可能就会被我们所遗忘。这个庞然的新流行语已经为“事件 驱动结构”所替代。 我为什么不吃惊？我在 1996年设计 WebRepository 的时候它就是围绕着状态/事件驱 动的应用模型了。BPM/SOA 厂商宣称，你“只需”利用 Java代码（比如 Oracle JDeveloper）将事件连接到 BPEL流程的二维工作流图去即可。 从我的角度来看，把“敏捷性”用在需要 Java 程序员创建一个简单的事件驱动流程 的 SOA 身上是一种虚假陈述。 顾问和分析师： 为什么我似乎总是针对顾问、分析师和外包发难？实际上我没有。但跟人无完人，并 非顾问的所有的建议都是金玉良言。 面向服务架构（SOA）1996年由 Gartner 在一篇 SSA研究报告中首次提出。Gartner 研究那些公司的偏爱，那可以堆满整个陈列柜（失败的预测），我并不认为那是他们所 好。 SOA并非什么糟糕主意，也不是电子设计自动化，但由它所组成的行业反对我今天的 演讲。我请你们不要让现在这个主意影响到你们对此的判断能力。我要邀请你，不要害 怕，站起来宣告——你并非科技的草根，作为一项人权，你必须如此宣告。只要本着提供 用户流程优先这个出发点，我对用户及业务单位的力促就不会造成妨碍。实际上，我恳请 用户和 IT要更灵活些。 神圣愿景： SOA 技术专题之“SOA 实现与交付指南” Page 20 of 26 那么，如 Gartner副总 Barbara Gomolski 前面所述，是什么阻止了大部分组织的前 瞻性战略改变及创新呢？政府和商业各打五十大板？可为什么优秀的专家那么害怕尝试新 鲜事物呢？ 我找出了一种解释：在 1996年出版的《神圣愿景》一书中，Thomas Sowell 写到了一 种政治愿景，这种愿景亦完全可以完全运用到商业和 IT等其他领域：“当然，愿景的分 歧，是基于假设的不一致的„„然而，作为一种普遍的愿景，意味着其假设是得到被称为 ‘有思想高度者’的认可的，那些假设经得起挑战，永远都不会被要求提供实验性证 据„„对于信仰者而言，普遍愿景是天恩所赐，比任何其他东西都重要。” 索维尔这本书的副题十分贴切：“自得是社会政策的基础”。在洋洋自得的艺术方 面，只有政治人物和股票分析师超越了 IT。 反对普遍愿景者竭尽所能抗争，宣称“应当揭露背后的动机”。跟气候变化讨论很相 像„„ 参考与创新： 大型组织的 IT人士比其他人更加回避创新。我总是被要求提供安装参考（没人想成 为被参考者），这对于创新型软件来说是不可能。嘿，这可是新东西；没人干过！此外， 实际上任何两个不同的客户都不会用我们的软件或使用相同的设施去干同样的事情。参考 指南自始至终都应当是有关于参与者的完整性，而非技术的完整性。 很显然，你也可以选择安全路线，回避创新，根据高德纳的魔力象限（Gartner Magic Quadrant）做出选择。然而高德纳只是一家市场分析公司，因此其信息是来源于过 去的。在那里你找不到创新。 SOA并非创新，而是面向对象消息的演进，它转错了方向，因为供应商要卖自己有的 东西——他们仅仅是更改了一下产品名称。在过去 20 里，我在本文中的观点已经被转换 成 ISIS Papyrus的产品，因此，其中部分业已、并再次具备相当的创新性。 SOA 技术专题之“SOA 实现与交付指南” Page 21 of 26 我认为，自己进行大规模的开发或者购买刚性的“标准”软件（以及固化的流程）都会比 尝试一下新东西隐含更高的风险。IT是最具竞争力的工具——如果它是由敏捷的人实现和 使用的话。 你不能跟在别人屁股后面亦步亦趋。如果缺乏创新，无论跟时髦用语有多兼容，你的 IT都不能站在风头浪尖。拿 IT跟其他不进行创新者的做比较只会把大家都贬低到同样的 低水平。不过„„，在你的评测里，你可以展现出自己位列最优秀者之中！ 创新——尝试新事物——总要承担一点风险的。勇敢点！ (作者：Max J. Pucher 译者：杨华军 来源：TechTarget 中国) 原文链接：http://www.searchsoa.com.cn/showcontent_34609.htm SOA 技术专题之“SOA 实现与交付指南” Page 22 of 26 十二步规划 了解 SOA 何时真正交付 随着近年来有关”SOA 失败”的讨论，有一个令人迷惑的问题就是组织机构如何知道 他们的 SOA 项目是否真的“失败”了呢？SOA 也许有可能带来各种各样的价值，但是组织 机构远没有意识到这些价值怎么产生？那么，谁知道呢——也许那些“失败“真的带来了 不同。 自从 SOA出现以来，它就对那些受困于孤立遗留系统的组织许诺，使其得到解脱并缓 慢转变到新的系统。支持者声称这种方法论能够带来更快的应用开发和部署，更紧密适应 了日新月异的业务的需要。然而人人都认为这仍然有很多工作需要去做——特别是在治理 和估算投资回报率领域方面——我们能够说到现在为止，SOA 就已经达到了它所允诺的期 望吗？ 我们怎样才知道一个面向服务架构实现是否成功呢？这当然是度量因子，而且重要的 是不断的测量和监测。但是什么才是正确的度量规格，我们怎样把它们应用到业务中呢？ 为了充分了解——甚至是意识到 SOA带来的好处或利益。 这些利益就应该被评估和 跟踪。通常来说，这是知易行难的事情， 跟踪 SOA 方法的测量因子和投资回报率（ROI） 是个非常令人困惑的挑战。建立了 IDC SOA 实践的 IT 行业和业务战略顾问 Sandy Rogers 认为对于 SOA的好处的看法和期望就像不同业务本身。这都取决于你在跟谁讨论，他们对 价值的理解，还有他们从 SOA获得的，以及有什么样的折衷解决方案。 那是因为“SOA 是一种体系架构，一种方法论和一系列用来解决特定业务问题集合的 技术，”桑迪说，“SOA 已经以不同的方式应用到不同的事情上。每个组织机构的不同在 于他们应对和处理不同的事情。 你应该从全局的眼光来看问题，而不是孤立的、片面地 来看待。” SOA 技术专题之“SOA 实现与交付指南” Page 23 of 26 或许 SOA最初可以把节省成本做为它最明显的利益，并确保这些好处延伸到企业。企 业也应当以更全面、整体的观点去考量 SOA 的效益，而不是基于一个一个单独的项目来观 察。Sandy 说：“这不是所有节省成本的全部”。 我们往往没有耐心，没有经过充分的评估和计算。例如，Gartner的调查发现，40%使 用基于 SOA 方法的公司没有计算它们在 SOA 方面的付出达到投资回报率的时间。大约 50% 的没有接受 SOA的组织说他们没有采用 SOA 是因为他们不能清晰描述和展示它的业务价 值。Gartner 分析师 Massimo Pezzini 这样说到：“有些 SOA 项目被认为失败，是由于事 实上根本没有公认的标准来评估成功。所以有些时候 SOA带来好处，但是人们不断地争论 SOA带来更好的东西有多少，这些改善提高是否真的与 SOA有关联。” 下面这些组成了衡量 SOA 的 12个关键因素： 这些关键基准中的哪些将会描述 SOA 正在给业务带来利益？ 几个月前，IT Business Edge编辑 Loraine Lawson 概括了 SOA 的关键测量因素，这 些都是从顶尖的 SOA 思想家们那里得出来的，他们包括 Dan Foody、Dave Linthicum、 Mark Little、Leo Shuster 和 Jerry Smith。 1.每个服务的投资回报率（ROI）：“每个服务的 ROI可以做为整个 ROI 的早期的指 示标记” 2.每个服务的收入：并不是所有的服务都将产生收入，当然，这也是应该被加以考虑 的范围。 3.服务增长率/重复使用或新服务产生与使用的数量占所有服务总数的百分比：“这 个度量可以帮助你尽可能地确保重用服务而不是开发冗余重复的服务。同样它也在你计算 每个服务的 ROI方面上非常有效。” 4.业务敏捷性或服务开发的平均时间（周期）：“它能够衡量一个服务从开发阶段到 部署阶段需要多少时间。”