SOA实现和交付指南.pdf

SOA实现与交付指南 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实现与交付指南”Page2of26 为什么SOA没有实现：我们错在哪里？为什么SOA没有实现：IT与流程有何关系？为什么SOA没有实现：情感和敏捷性为什么SOA没有实现：我们需要治理吗？为什么SOA没有实现：SOA前路何方？SOA何时真正交付随着近年来有关”SOA失败”的讨论，有一个令人迷惑的问题就是组织机构如何知道他们的SOA项目是否真的“失败”了呢？SOA也许有可能带来各种各样的价值，但是组织机构远没有意识到这些价值怎么产生？那么，谁知道呢——也许那些“失败“真的带来了不同。十二步规划了解SOA何时真正交付大师论战：SOA何时真正实现？SOA技术专题之“SOA实现与交付指南”Page3of26 SOA最大的问题是什么？过去一年，即使在经济衰退的情况下，也有很多人对面向服务架构（SOA）感兴趣。对照Forrester的商业数据服务企业和中小企业软件（SMB）的调查结果，2008年第四季度到2009年第四季度，北美和欧洲的企业（10000+员工）的SOA普及程度（那些目前使用SOA的，再加上准备使用SOA）增长了10%，中小企业增长了33%。从时间上讲，这是一个行业良好增长的趋势，但是有些人说SOA已经死了。TTSOA编辑推荐：2010年SOA现状调查报告除了SOA日益普及以外，SOA用户对SOA的发展和满意程度反应强烈。在TechTarget/ForresterResearch上对2010年SOA现状的调查来看，61%的人表示，他们目前使用SOA，有10%或者更多的人，使用SOA在他们的交付方案的项目上——有12%的人，把SOA使用在了他们50%以上的项目上。但是那些认为SOA已死的人真的很让人愤怒：66%人表示他们的SOA提议取得成功，23%的人表示他们已经取得相当大的成功。事实上，因为SOA成功来之不易，存在一些利益的争斗，就需要组织的完善和纪律约束，——但是业内SOA的领导者已经展示了SOA成功的方法。但是有一些非常有趣并另人惊讶的数据：当被问到他们使用SOA最大的问题时，调查对象表示，目前为止，SOA项目面临的最大挑战已经超越了SOA本身。27%的人认为，最大的担心是“如何通过多个项目（如BPM、事件、BI、规则等）整合的方式设计SOA？”。只有13%的回卷者选择了第二大担忧，即“[为SOA]评估及选择合适的工具”。换言之，工业界已经认识到，这是一个多元技术的世界，单一技术战略可能会错失目标。SOA固然重要，但是业务技术解决方案需要的不仅仅是SOA，还需要SOA与其他方法以及设计域结合起来才能满足需求。SOA技术专题之“SOA实现与交付指南”Page4of26 换句话说，业界的人们认识到，个别的、竖井技术策略不能达到目标——这是一个多技术的世界。SOA固然重要，但是业务技术（BT）解决方案不仅仅是需要更多的SOA，他们需要SOA方法与其他技术和设计领域相结合的方法。通过包装主要的业务交易作为一个外加服务，SOA为业务转换提供了一个强大的基础。29%的调查对象说，他们使用SOA来支持业务转型战略—但是流程、事件、规则、嵌入式分析，也体现了更多的业务设计的重要方面和建立灵活的方式来处理当前的业务变化。SOA的基本性质强调这样一个事实，71%的调查对象表示，SOA作为一个技术是［他们的］组织的技术方面的努力取得的最关键成功。然而他们评价的BPM、业务规则、传统的现代化进程、Ajax和丰富的网络应用、云计算、事件处理和web导向架构，作为“最关键的”技术，但是回答调查问题的人从37%降到21%（多选）。多年来，Forrester一直追求更大的SOA蓝图。在2005，我们发布数字业务架构愿景——技术平台构重新构造成四个主要的多技术整合的领域已业务元数据为核心，定义流程、策略、事件、信息流以及许多你的其他业务的方面。建立一个数字业务架构，Forrester公司现在定义我们的业务能力架构的愿景，提供了新的方法来规划和发展一个多技术战略，建立并围绕业务的成果不断提高。对于BT前进道路的成功，你必须学会进行你的业务的设计和技术体现的整合。(作者：RandyHeffner译者：刘志超来源：TechTarget中国)原文链接：http://www.searchsoa.com.cn/showcontent_36732.htmSOA技术专题之“SOA实现与交付指南”Page5of26 SOA九大迷思编者按：本文由原刊于ebizQSOAinAction网站的前版增补而成。去年秋天，我们着手来理清面向服务和SOA的真正含义，其结果便是SOA宣言。我们希望籍此可以更好的澄清SOA的含义。然而，关于SOA，至今仍存在许多迷思。很多人，甚至是IT人员都说他们并不完全了解SOA可以做什么，以及如何去构建SOA。SOA已经被软件厂商和分析师们夸大到令人难以置信的程度，但是，却鲜见有介绍SOA基本含义的资料。以下是关于SOA仍存的一些迷思：第一，SOA和云计算的区别是什么？许多厂商，正如DaveLinthicum所说，正在给他们的产品贴上“云”的标签——只是简单的把他们的SOA产品更名为云产品。那么，这其中有什么区别呢？不论SOA还是云计算，都是要将服务标准化，从而可以实现复用。正如Dave所讲，云的形成需要同样的企业架构和治理—包括技术，人员和流程的治理。眼下很多公司正在落实这样的治理来管理SOA，而这些年来SOA治理的经验教训也能够帮助到云的部署。第二，为什么大家对云计算迷的发狂，但却对SOA兴味索然——虽然他们在本质上都是相同的东西？如果你了解地透彻的话，云其实是提供或获取跨企业的服务复用。同样地，Enterprise2.0正在应用服务来实现更大范围的协作，以及混搭（mashup）终端用户的信息。这些都是面向服务的架构，并且依赖基于SOA的原则来运行。或许这有点类似于人们对喷气推进技术还是小岛上的周末度假胜地更感兴趣¬——后者需要利用喷气推进技术才能到达那里。SOA技术专题之“SOA实现与交付指南”Page6of26 第三，在尚未有人真正应用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实现与交付指南”Page7of26 但是，在市场上唯一能真正衡量长期成功的标准是企业收入或股票价值的不断增加，除了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实现与交付指南”Page8of26 这是SOA首先要面临的一个艰难的挑战——成功是一个长期努力后才能取得的结果，其标志是多个业务单位之间共享服务，从而使得企业的服务开发时间明显缩减，或者，由于企业底层的基础设施的灵活性进一步提高，这使得企业只需重新配置即可快速地响应市场对产品或服务的新需求。但是，在市场上唯一能真正衡量长期成功的标准是企业收入或股票价值的不断增加，除了SOA，还有很多其它因素会对此造成影响。真正的问题在于弄清楚如何衡量SOA对于企业成功的贡献。SOA本身的“成功”同这是毫无关联的。(作者：JoeMcKendrick译者：李松来源：TechTarget中国)原文链接：http://www.searchsoa.com.cn/showcontent_35853.htmSOA技术专题之“SOA实现与交付指南”Page9of26 为什么SOA没有实现：我们错在哪里？如果你的IT预期要令业务更敏捷，你就得转到SOA来，是吧？我不同意，为什么呢？因为大家又一次把因果混为一谈了。不管有没有SOA，一个敏捷的组织都应该能够充分地利用IT。SOA并不会让业务或者人更为敏捷。敏捷性只能来自于业务和IT的创新意愿，并通过废除死板的业务流程，脱掉实现BPM、CRM和ECM这身紧身衣，放权给用户才能达到。把流程编码为僵硬的JAVA，对SOA来说无异于业务杀手。为什么SOA被吹嘘到令人难以置信的程度？SOA的风潮热得过头了，随后由于大家都随大流卖起产品和服务而陷于泥潭之中。《网络计算杂志》。因此曾把SOA称为最受鄙视的流行语也就不出奇了。IBM（Tivoli和WebSphere）、Oracle（Fusion）等玩起了“卖不出就改名”的游戏。是要做出某些改变，但应不仅限于产品名。我们是不是甚至连错在哪儿都不知道？我严重怀疑这一点。很有影响的量子物理学家DavidBohm在1980年写道：“分解在我们的社会是如此之广泛，以至于干扰到了我们的认识，阻止我们去解决最简单的问题。”。似曾相识吧？我们把一切都塞进小盒子里，为每一个业务问题都购买了最佳组合的软件解决方案，现在，我们诧异地发现，它们不能工作到一起。在过程的层次上，我们致力于将过程剖解为小的片段，因为这种方式下它们似乎更易于管理。1993年，ThomasDavenport所述的过程碎片是这样的：SOA技术专题之“SOA实现与交付指南”Page10of26 实现就能连接。但更恰当的描述是福特（Foote）和育德尔（Yoder）1999年做出的，他们是这样写的：我认为DavidBohm是对的，分解对于我们在能力范围内进行思考、组织和计划是必要的。然而，我们周遭的世界并非由过程的片段造就的，因此当前的SOA方案将无法解决碎片化，相反，会在更高层次上导致一场软件工程的噩梦。在进行IT系统的碎片清理之前，需要对业务流程和流程变更管理好好审视一番。业务流程的1911风格有些人说SOA就是流程管理的延伸。然而，BPM支持者陷入了1911年的泰勒主义，而SOA把局面搞得更糟，因为仍存在碎片化的变更管理。FrederickTaylor相信分解和专门化，推荐僵化的结构化企业。因此，每一个IT应用都代表着那样的一个业务流程片段，因为根据达文波特，倘不若此的话，我们就不会需要它。但业务流程又是什么呢？Rummler和Brache（1990）提议说“业务流程是一系列设计用于为客户生产产品或服务的步骤”。这压根儿就是不对的。是的，为了给用户以及流程本身更多空间，的确有部分僵化的决策流程和特定的方案。奇怪的是，好像几乎没人意识到我们需要的是创建一个拥有动态关联过程和企业通讯的敏捷企业。很显然，通信过程的内容状态是受控的，而非无缝的行动。商务沟通并不仅仅是一份文档或者电子邮件，它可以是任何东西：一份选定的菜单、一个网页、文档上的标签、一条记录、一张图片或甚至语音记录或者视频。无论在业务流程分析上要花多少时间和金钱，一旦正式的时候，商务沟通这一点仍是需要的。基于这个原因，协作工具及电子邮件现在得到了广泛使用。任何分析都需要沟通。在《企业再造》一书中，Hammer和Champy提出一个很重要的建议：“单个的任务或过程都不重要，重要的只有结果”。BPM系统、BPR项目无力适应面向目标的动态性。SOA技术专题之“SOA实现与交付指南”Page11of26 Damelio在《流程映射基础》（BasicsofProcessMapping）一书中写道：“示意图和流程图令工作可视化„„它们展现了某段时间的快照„„”。这就是设想中的业务流程，如博姆所言。我们需要分块来进行理解，但生活的运作方式并非如此。(作者：MaxJ.Pucher译者：杨华军来源：TechTarget中国)原文链接：http://www.searchsoa.com.cn/showcontent_34489.htmSOA技术专题之“SOA实现与交付指南”Page12of26 为什么SOA没有实现：IT与流程有何关系？在《IT重要吗？》一书中，NicolasG.Carr写道：“„„在二十世纪九十年代里，许多战略投资都浪费掉了„„企业高管对IT的怀疑不断增长„„”并宣称IT现在是一种商品，不再能制造竞争性优势。我倾向于赞同他，但问题不在IT，而在于商业用户对IT的需求是什么！用户希望以其自身难以言语表达的方式组织其工作，而管理则想严格地控制用户流程。要做到两全其美，IT对此肯定毫无头绪，因为底层的技术（大部分是因为Windows、Java及XML）已经变得几乎不可管理。SOA对于已经复杂得难以置信地的局面而言，无异于火上浇油。商业用户也是人，他们会指着某样东西然后说：“这个我喜欢，那个我不喜欢”。一旦用户看到一个漂亮的GUI界面，他们会认为里面也一定是一样的。用户购买的是GUI，而非架构、灵活性或长期可管理性。可是他们却要求要99.99%的可用性（对于底层为基于大型机的银行交易系统来说是可以的）；但是在员工的精神和身体的平均可用性至多是50%的情况下，对可用性的期望与当前的技术复杂性联系在一起，令上市周期十分漫长。用户把IT当做不近人情的东西，他们的所想正是其所得。而正因为如此，业务正在为IT外包和治理的控制而做斗争。这主意糟透了！遵守低效的治理规则通常比需要哪些成分更重要。在其ZD-Net的博客上，JoeMcKendrick建议“将SOA转向HOA（面向人的架构），没有治理就没有SOA，但也许我们SOA技术专题之“SOA实现与交付指南”Page13of26 不需要太多的治理。”我想补充一下：如果SOA要求对我们的业务进行甚至更为僵化的控制和管理的话，也许我们根本就不需要它？业务流程决策面对现实吧：在泰勒式（Tayloristic）二维的过程图里，AGILE-SOA-jBPEL-XML型的企业无法具备远见！最新的流行语“IT工业化”描述了我们的计划——为迟钝的商业用户创建亨利•福特式的IT流程流水线。事情变得更糟了。2005年，达文波特和哈里斯在一篇MIT-Sloan管理学院的文章中MIT进一步宣称：“与需要人们识别问题或开始进行分析不同，公司通常将决策能力嵌入到日常的工作流当中去。那些系统随后感知在线数据，运用编纂成典的知识或逻辑，然后在最少量的人类干预的情况下做出决策。”在“超级运算器：为什么说通过数字思考是变得聪明的新途径”一书中，IanAyres也主张海量数据集使以前不可能的预测成为可能，统计方法也比专家直觉所做出的决策更为精确。我的观点是，不管自动化与否商业智能都是一堆令人费解的混乱数据，对商业决策而言无足轻重。想象一下，我们不仅是要盯住的流程（的执行者），还是代码化决策知识（的来源）？那样的话，公司通通都要完蛋，因为“统计数据事实”只是一种假象，来自于过去的最佳均值并不能应用于当前的决策。跟相关的经理、员工以及客户进行面对面的交谈会给你一个感性的直观感受，以便做出正确的决定，那是统计所无法做到的。(作者：MaxJ.Pucher译者：杨华军来源：TechTarget中国)原文链接：http://www.searchsoa.com.cn/showcontent_34506.htmSOA技术专题之“SOA实现与交付指南”Page14of26 为什么SOA没有实现：情感和敏捷性你也许要问：情感？有人要我把“情感”换成“本能（instinct）”，因为情感看起来是那么的负面。我不同意！直觉更多是用在根本不需要思考的条件反射式的领域。也许用感受要好一些，但感受同样需要我们人类本性深处的感情。直觉（intuition）还能接受，因为直觉是一项情感官能。不幸的是，情感作为理智的对立面是现如今的一种设定。也许并非如此。在英国和美国的河流上为什么会检测到抗抑郁药物百忧解（Prozac）的存在呢？因为人们不断被迫要求成为理性而非感性的人。深入剖析一下自己，你会感觉到这是违背人类本性的，而这正是我们致病（译者：抑郁症）的原因。人类的决策更像是大脑的一种偏向于感性的模式匹配能力。理性只能用于决策后评估的验证或调整。是不是说不强的企业家和经理大部分都是些很感性化、甚至不理性的人？绝对是！先驱者如布罗卡（Broca，1878）、培帕兹（Papez，1937）及麦克林（MacLean，1952）等都主张情感与大脑中枢的一组称为边缘系统的结构相关，包括了下丘脑、扣带皮层以及海马等。安东尼奥•达马西奥（AntonioDamasio），现为南加州大学的神经系统学教授，长期从事处理记忆、语言、感情及决策的神经系统的研究。在1994年出版的《笛卡尔的错误：感性、理性及人类大脑》一书中，他记录了自己的发现：“感情中枢功能紊乱的人在决策时会面临严重困难。”。因此人类决策——无论是否基于直觉——都是偏向于感性的，那么请问流程分析顾问先生，你又打算如何对那个东西进行编码呢？为了通过计算的帮助来改善决策，我们需要技术发明来对人类凭直觉做出的决策进行建模，这远远超出逻辑规则的范畴。While兰•艾尔斯在提到神经网络和模式匹配的时候，他没能真正理解这一点，那就是此二者均不需要统计数据，而只需要与真实数据关联的决SOA技术专题之“SOA实现与交付指南”Page15of26 策点。有多少人做出了什么决定并不重要，重要的是每一个个体都使用了什么样的数据模式来做出决定。因此，我们并不需要使用未经验证的数学假设对毫无意义且并不精确的数据进行反复的处理，而是要把现在的计算能力运用到交互式地从人类身上学习决策上。那“敏捷性”又是什么？我是认真的：敏捷性是人类的特性，而非系统的功能。是什么导致当前的组织丧失敏捷呢？是Java/XML这团“大泥球”？泰勒式的BPM？WindowsDLL地狱？要我说，是因为人们身上缺乏敏捷性，目光短浅，抗拒真正的创新。一个敏捷的IT部门，需要有一位真正敏捷的CIO来运作，要能取得一个敏捷的董事会的支持，其创建出的应用平台，应能将强大的威力交到熟练地业务用户手上，用户本身还得有敏捷的意愿。在其SOA白皮书上，IBM、BEA（译者：现为Oracle所收购）、TIBCO及Oracle之流为创建SOA赋予了无穷维度的技术复杂性，而这个星球根本就没有那么多的IT人力资源，甚至连处理那样的SOA项目的2%都做不到（来源：MaxPucher，2007，《35年IT猜想》）。请记住，一旦洞已经深到你无法爬出去，把洞挖得更深并不会对你的状况有所改善。KISS——简单一点，笨蛋！（Keepitsimple,stupid!）简化是必要的，鄙人不才，2000至2001年间，正是在下首先提议通过PapyrusWebRepository将出入库资料（InboundandOutbounddocuments）合并进闭环的CRM流程中—每一位大名鼎鼎的分析师听完之后都是一脸茫然！而今天，你可以在每一个ECM供应商的白皮书上找到入库/出库（Inbound/Outbound）的字样。我要一并谢谢你们，因为抄袭就是最由衷的奉承。现在，我已经提议要对ECM、BPM和CRM进行合并了„„所以你们最好停止挖坑了！(作者：MaxJ.Pucher译者：杨华军来源：TechTarget中国)原文链接：http://www.searchsoa.com.cn/showcontent_34548.htmSOA技术专题之“SOA实现与交付指南”Page16of26 为什么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模块、流程定义、XMLtransform以及所有的数据库上去。用户自己没有手段快速简便地进行变更。由于不存在通用的版本管理和部署管理，我们还是在原地踏步——深陷于一个“大泥球”里，只不过更加复杂了。SOA技术专题之“SOA实现与交付指南”Page17of26 标准——你在哪里？有些人相信标准是救世主。OpenGroup、Oasis、OMG等等，各不相同的组织制定许多SOA的定义。在关键问题上，大部分定义仍存缺失，比如全球交易、安全及事件处理。因此，仍然没有实现SOA的标准方式。若干供应商提供了SOA变更管理工具，如HP-Mercury、IBMTivoli等。这些巨大的投资是用于处理SOA基础设施和网络的，不能用于处理用户所需的前端的业务服务。如你所见，沧海横流，这个世界是一整个杂乱无章。我见到的投标申请书（RFP）里，在要求SOA兼容的同时还要具备“全功能API”。有投标申请书中要求XML和Java标准这样的空中楼阁。（不过）在投标申请书里你只需简单地回答“满足”即可。许多IT人士似乎认为SOA是解决Java、XML无标准现状的灵丹妙药，而它至多仅是将部分问题掩盖了起来。(作者：MaxJ.Pucher译者：杨华军来源：TechTarget中国)原文链接：http://www.searchsoa.com.cn/showcontent_34566.htmSOA技术专题之“SOA实现与交付指南”Page18of26 为什么SOA没有实现：SOA前路何方？我认为要不了几年，SOA可能就会被我们所遗忘。这个庞然的新流行语已经为“事件驱动结构”所替代。我为什么不吃惊？我在1996年设计WebRepository的时候它就是围绕着状态/事件驱动的应用模型了。BPM/SOA厂商宣称，你“只需”利用Java代码（比如OracleJDeveloper）将事件连接到BPEL流程的二维工作流图去即可。从我的角度来看，把“敏捷性”用在需要Java程序员创建一个简单的事件驱动流程的SOA身上是一种虚假陈述。顾问和分析师：为什么我似乎总是针对顾问、分析师和外包发难？实际上我没有。但跟人无完人，并非顾问的所有的建议都是金玉良言。面向服务架构（SOA）1996年由Gartner在一篇SSA研究报告中首次提出。Gartner研究那些公司的偏爱，那可以堆满整个陈列柜（失败的预测），我并不认为那是他们所好。SOA并非什么糟糕主意，也不是电子设计自动化，但由它所组成的行业反对我今天的演讲。我请你们不要让现在这个主意影响到你们对此的判断能力。我要邀请你，不要害怕，站起来宣告——你并非科技的草根，作为一项人权，你必须如此宣告。只要本着提供用户流程优先这个出发点，我对用户及业务单位的力促就不会造成妨碍。实际上，我恳请用户和IT要更灵活些。神圣愿景：SOA技术专题之“SOA实现与交付指南”Page19of26 那么，如Gartner副总BarbaraGomolski前面所述，是什么阻止了大部分组织的前瞻性战略改变及创新呢？政府和商业各打五十大板？可为什么优秀的专家那么害怕尝试新鲜事物呢？我找出了一种解释：在1996年出版的《神圣愿景》一书中，ThomasSowell写到了一种政治愿景，这种愿景亦完全可以完全运用到商业和IT等其他领域：“当然，愿景的分歧，是基于假设的不一致的„„然而，作为一种普遍的愿景，意味着其假设是得到被称为‘有思想高度者’的认可的，那些假设经得起挑战，永远都不会被要求提供实验性证据„„对于信仰者而言，普遍愿景是天恩所赐，比任何其他东西都重要。”索维尔这本书的副题十分贴切：“自得是社会政策的基础”。在洋洋自得的艺术方面，只有政治人物和股票分析师超越了IT。反对普遍愿景者竭尽所能抗争，宣称“应当揭露背后的动机”。跟气候变化讨论很相像„„参考与创新：大型组织的IT人士比其他人更加回避创新。我总是被要求提供安装参考（没人想成为被参考者），这对于创新型软件来说是不可能。嘿，这可是新东西；没人干过！此外，实际上任何两个不同的客户都不会用我们的软件或使用相同的设施去干同样的事情。参考指南自始至终都应当是有关于参与者的完整性，而非技术的完整性。很显然，你也可以选择安全路线，回避创新，根据高德纳的魔力象限（GartnerMagicQuadrant）做出选择。然而高德纳只是一家市场分析公司，因此其信息是来源于过去的。在那里你找不到创新。SOA并非创新，而是面向对象消息的演进，它转错了方向，因为供应商要卖自己有的东西——他们仅仅是更改了一下产品名称。在过去20里，我在本文中的观点已经被转换成ISISPapyrus的产品，因此，其中部分业已、并再次具备相当的创新性。SOA技术专题之“SOA实现与交付指南”Page20of26 我认为，自己进行大规模的开发或者购买刚性的“标准”软件（以及固化的流程）都会比尝试一下新东西隐含更高的风险。IT是最具竞争力的工具——如果它是由敏捷的人实现和使用的话。你不能跟在别人屁股后面亦步亦趋。如果缺乏创新，无论跟时髦用语有多兼容，你的IT都不能站在风头浪尖。拿IT跟其他不进行创新者的做比较只会把大家都贬低到同样的低水平。不过„„，在你的评测里，你可以展现出自己位列最优秀者之中！创新——尝试新事物——总要承担一点风险的。勇敢点！(作者：MaxJ.Pucher译者：杨华军来源：TechTarget中国)原文链接：http://www.searchsoa.com.cn/showcontent_34609.htmSOA技术专题之“SOA实现与交付指南”Page21of26 十二步规划了解SOA何时真正交付随着近年来有关”SOA失败”的讨论，有一个令人迷惑的问题就是组织机构如何知道他们的SOA项目是否真的“失败”了呢？SOA也许有可能带来各种各样的价值，但是组织机构远没有意识到这些价值怎么产生？那么，谁知道呢——也许那些“失败“真的带来了不同。自从SOA出现以来，它就对那些受困于孤立遗留系统的组织许诺，使其得到解脱并缓慢转变到新的系统。支持者声称这种方法论能够带来更快的应用开发和部署，更紧密适应了日新月异的业务的需要。然而人人都认为这仍然有很多工作需要去做——特别是在治理和估算投资回报率领域方面——我们能够说到现在为止，SOA就已经达到了它所允诺的期望吗？我们怎样才知道一个面向服务架构实现是否成功呢？这当然是度量因子，而且重要的是不断的测量和监测。但是什么才是正确的度量规格，我们怎样把它们应用到业务中呢？为了充分了解——甚至是意识到SOA带来的好处或利益。这些利益就应该被评估和跟踪。通常来说，这是知易行难的事情，跟踪SOA方法的测量因子和投资回报率（ROI）是个非常令人困惑的挑战。建立了IDCSOA实践的IT行业和业务战略顾问SandyRogers认为对于SOA的好处的看法和期望就像不同业务本身。这都取决于你在跟谁讨论，他们对价值的理解，还有他们从SOA获得的，以及有什么样的折衷解决方案。那是因为“SOA是一种体系架构，一种方法论和一系列用来解决特定业务问题集合的技术，”桑迪说，“SOA已经以不同的方式应用到不同的事情上。每个组织机构的不同在于他们应对和处理不同的事情。你应该从全局的眼光来看问题，而不是孤立的、片面地来看待。”SOA技术专题之“SOA实现与交付指南”Page22of26 或许SOA最初可以把节省成本做为它最明显的利益，并确保这些好处延伸到企业。企业也应当以更全面、整体的观点去考量SOA的效益，而不是基于一个一个单独的项目来观察。Sandy说：“这不是所有节省成本的全部”。我们往往没有耐心，没有经过充分的评估和计算。例如，Gartner的调查发现，40%使用基于SOA方法的公司没有计算它们在SOA方面的付出达到投资回报率的时间。大约50%的没有接受SOA的组织说他们没有采用SOA是因为他们不能清晰描述和展示它的业务价值。Gartner分析师MassimoPezzini这样说到：“有些SOA项目被认为失败，是由于事实上根本没有公认的标准来评估成功。所以有些时候SOA带来好处，但是人们不断地争论SOA带来更好的东西有多少，这些改善提高是否真的与SOA有关联。”下面这些组成了衡量SOA的12个关键因素：这些关键基准中的哪些将会描述SOA正在给业务带来利益？几个月前，ITBusinessEdge编辑LoraineLawson概括了SOA的关键测量因素，这些都是从顶尖的SOA思想家们那里得出来的，他们包括DanFoody、DaveLinthicum、MarkLittle、LeoShuster和JerrySmith。1.每个服务的投资回报率（ROI）：“每个服务的ROI可以做为整个ROI的早期的指示标记”2.每个服务的收入：并不是所有的服务都将产生收入，当然，这也是应该被加以考虑的范围。3.服务增长率/重复使用或新服务产生与使用的数量占所有服务总数的百分比：“这个度量可以帮助你尽可能地确保重用服务而不是开发冗余重复的服务。同样它也在你计算每个服务的ROI方面上非常有效。”4.业务敏捷性或服务开发的平均时间（周期）：“它能够衡量一个服务从开发阶段到部署阶段需要多少时间。”SOA技术专题之“SOA实现与交付指南”Page23of26 5.服务变更周期：更换服务所需要的时间是衡量敏捷性的另一个因素。6.服务的可用性：也称为可靠性，用平均无故障时间（MTTF）和平均修复时间来衡量（MTTR）。7.服务活力指数：这用来跟踪过去12个月从新服务获得收入数量占所有服务收入的比例。8.与服务重用相关的效率：“这个效率可以衡量重用服务后项目更快交付带来的时间和费用的节省”9.集成时间成本：虽然每个正在进行或者将要进行的项目的集成成本仅能够估算，但有一个标准可重用的因数可用于服务的构建成本。通常，这些情况下服务构建成本占到80%。10.相关的机会成本：由SOA带来的机会和服务再利用都需要跨组织之间的沟通。这就需要在治理方法及其相关技术领域进行投资。11.成本节省/避免：“服务成本避免=服务构建成本–项目服务集成成本。”12.项目和维护成本的减少：“为了计算出整个项目的成本节省的数量，可以简单地使用叠加所有服务的成本节省数量来实现。”为了在任何一个时间点预测整体潜在的成本节省数量，可以通过几倍于每个服务的构建成本然后再把他们加起来得到。(作者：JoeMcKendrick译者：吴军建来源：TechTarget中国)原文链接：http://www.searchsoa.com.cn/showcontent_37260.htmSOA技术专题之“SOA实现与交付指南”Page24of26 大师论战：SOA何时真正实现？不久前，我有幸跟SOA领域的大师，企业服务总线概念的创始人DavidChappell探讨SOA成功的意义。他表示：“许多SOA的采纳者的原始驱动力都和怎样帮助IT部门更好地适应满足业务需求的需要相关，但通常它也是由降低IT成本来带动的，这种成本降低是通过消除冗余硬件、应用软件和共享跨越独立部门和业务组织边界的应用资产和资源来实现的。”虽然许多公司都看到SOA在IT方面提供的好处，但现在重点已经扩大到包括业务及其相关领域方面。Chappell认为：“我们看到业务变得能够更快采纳和适应支持新的业务创新的软件——例如吸引新的客户或保持现有客户，如果你用IT来支持新的市场计划，那么这个业务本身就可以变得更加敏捷。”从已往的经验更能帮助我们思考——看看那些当今疯狂的市场上成功的企业，看看他们面向服务水平上是否有共同点。这正是IBM商业价值研究所在今年早些时候做的事情，是的，研究人员已经得到结论，揭开一个表现优越公司的面罩看，你将有机会发现面向服务架构的商业运作方法。IBM研究所发现，表现优越的公司9倍于其他公司更可能使用一个面向服务的体系架构，而且3倍于其他公司更可能使用其他协同技术战略，如分析技术战略。从MichaelHolmes、TamiCannizzaro和KristenLauria收集的对275多名高级管理人员的调查得知，处于领导地位的组织使用更聪明的工作方法，远比他们低效率的同行者更广泛，如运用分析、业务活动监测、面向服务体系架构和协同化空间技术。研究人员把“优胜者”同剩下的公司区分开，这些公司明显优于其同行（整个样本的16%）。那么这些“优胜者”做了些什么不同于相对不敏捷竞争对手的事情呢？研究人员说这特殊的16%——优胜者——比一个中游公司更可能去收集分散的数据来进行决策。SOA技术专题之“SOA实现与交付指南”Page25of26 将近30%的报告集成了各种不同来源的数据来达到重要范围，这种范围3.5倍多于他们的低效的同行者。他们在使用实时信息来做决策上，使用程度是其它组织的2.6倍。虽然技术是这些更智能工作方法的主要推动者，但研究者也指出，仍然有许多工作需要做，从而实现这些能力。例如，他们注意到，虽然在某些领域已经实现了70%的分析和数据可视化技术，但是他们仍然没有充分利用过程自动化和面向服务架构，这些创新能够帮助他们获得更大的敏捷性。仅有55%和36%已经接受采纳了这些方法。这项研究的作者发现，优胜者更可能比他们拙劣的同行拥抱这些技术和方法。“当我们审查了最有活力、最协作和最连通组织的技术概况后——那些组织在每个方面都最广泛地实现更智能工作的方法，我们看到了一个不同的画面，研究人员说到。“那些组织在广泛使用面向服务架构方面是其同行的九倍，在广泛接受协作空间方面也将近4倍于他们的同行。事实上，在每个使工作更聪明的技术领域上，那些表现杰出的公司或组织对它们的接受率都更高于它们的对手”。SOA能够非常形象地勾画出一条水平线，但是公司应该清楚SOA在哪里和怎样带来利益。(作者：JoeMcKendrick译者：吴军建来源：TechTarget中国)原文链接：http://www.searchsoa.com.cn/showcontent_37262.htmSOA技术专题之“SOA实现与交付指南”Page26of26