《架构和设计模式是SOA成功关键》由会员分享，可在线阅读，更多相关《架构和设计模式是SOA成功关键（13页珍藏版）》请在金锄头文库上搜索。
1、架构和设计模式是SOA成功关键导读：笔者访问了当今Web服务领域最忌影响力的人物之一Anne Thomas Manes，主要介绍了其最近的报告SOA现状的结果以及为什么SOA依然盛行。 【TechTarget中国原创】Anne Thomas Manes是当今Web服务领域最忌影响力的人物之一。她是Burton Group的调研员，同时也是SOA和Web服务话题的演讲家、作家以及博主。Manes最近合著了SOA现状简明报告。此次访问围绕着报告的结果和建议以及为什么SOA依然盛行。TT SOA：在您的报告中谈到一些组织并没有实现其SOA倡议承诺，其中一个关键原因是他们并不关注架构。你嫩能够解释一下
2、吗？Anne Thomas Manes：架构确实非常难。人们习惯了通常做事的方式，尤其是应用系统内的设计模式。因为很多组织不采纳新的设计模式来创建松耦合服务，所以他们在削减成本和增加敏捷性上并没有得到显著效果。为了实现这些，我们必须回顾一下最初是什么阻碍了它，95%的例子中，其应用架构是障碍，而且应用管理和维护起来价格昂贵。我们必须修正架构。TT SOA：现在也有很多SOA的先行者，他们成功了吗？Manes：我还是要说只有极少数组织的SOA已经成功了。大部分组织已经使用SOA技术创建了成功的应用。SOA技术的使用在这个层面上可以说是普遍的。而且并不是那些陈旧的集成中间件，而是已经升级的ESB。
3、它们并没有使用专有的协议，而是web服务堆栈。在迁移到下一个水平的协同中间件上还是有一定的好处的，但是一个应用的成功实施并不会成就SOA。就像你完成了一个系统的设计，你需要确定是否追随了面向服务、封装和松耦合的核心原则。但是如何来确保减少了依赖性呢？这也正是设计模式的作用所在了。最大的挑战是现有的经验丰富的面向对象开发人员，他们理解面向对象设计模式，而且没有认识到他们习惯使用的设计模式在松耦合的世界里并不适用。另一个关键的方面是服务建模。我们如何确定什么能够成为一种服务，这项服务该投入多少钱？在某种程度上，我们可以使用一些模式，但是服务建模是一门艺术，很多人对此并没有足够的经验。我们要完成哪些
4、流程来确我们所创建的是正确的服务呢？所以更为根本的是培训。大家知道原则或者模式是什么吗？知道如何建模吗？在揭秘SOA已死言论作者真正的目的中，我们将为您介绍，当初提出SOA已死言论的Manes最初的目的究竟是什么？揭秘SOA已死言论作者真正的目的【TechTarget中国原创】在架构和设计模式是SOA成功关键中，我们主要介绍了其最近的报告SOA现状的结果以及为什么SOA依然盛行。下面我们将深度解读当初提出SOA已死言论的Manes最初的目的究竟是什么？TT SOA：那么文化问题如何处理呢？Manes：我们过去一直探讨的工程学方面的核心设计是什么？为了设计一个良好的面向服务系统，组织中必须拥有这
5、些核心工程性能。但是问题是这是否促进了绝大多数组织呢，他们用以来支持共享服务的创建。基金模型的创建是个大问题。它们并不是用来支持共享服务的概念的。TT SOA：这会是SOA的未来吗？Manes：我不知道怎么来解决这个问题。问题是很多组织并不希望在架构上进行投资，但是如果我们希望创建敏捷性并减少成本，就必须修复这个应用组合。应用组合管理以及一种严格的应用系统关闭是个不错的办法，但是我们必须用其他的来替代这些。如果我们有十个管理客户信息的应用能够支持十个用力的话。我致力于SOA就是希望能够增加敏捷性并减少资源。我们必须处理问题源，也就是冗余和很难管理和维护的单片紧耦合系统。减少成本、让应用易于管理
6、和维护、减少冗余并让信息易于访问都可以通过SOA来完成。我想没有别的方法了。如果我们希望支持云、mashup和移动，最好还是进行面性服务的工作。TT SOA：那我想知道，您的2009年的报告SOA已死，服务长存引发了很多争论，您的目的是什么？Manes：我所说的并不是真的死亡；它被称为服务了。（译者注：在其博文中，Manes写到“SOA已死，面向服务架构的需要却更强了。”）关键的一点在于我们不能买卖SOA了，因为我们没能交付SOA的诺言。2009年事预算紧缩的一年，企业对于在SOA上花费五百万到一千万美元并不感兴趣。我所要表达的是SOA 不能商业化，你不能说我需要更多的资金，尤其是你不能证明其
7、价值的时候。停止对于SOA的探讨并开始时间。我们需要开始在从事的每一个项目中应用SOA原则，接受这种教训而不是技术。很多人从不会把标题读完，而且他们这也是他们放弃SOA的一种理由，但这并不是我的初衷。厂商一定恨死我了，但是我想他们已经接纳了这个概念，因为SOA不仅是一项技术，而是设计和架构。很多人说我的博客可能是对SOA最好的事情了，这是一种对于业界的苏醒召唤。三年前客户提出的最普遍的问题是我应该购买什么样的ESB？我说你为什么要这样问？他们说这是厂商告诉我们的或者说分析师这样说的。ESB是集成你的系统的技术的一部分，但它并不会带给你SOA。重构时应该做什么？从应用组合的愿景出发。SOA有助于
8、改善IT和业务需求的一致性。然而，SOA要取得成功，企业应该有长远的考虑。架构不仅仅是一个项目。它是一个要运行许多年的项目。一般来说，SOA项目的生命周期比ERP(企业资源规划)系统长。ERP系统的生命周期是12至13年。Spies还建议SOA架构师为企业定义价值，让企业理解SOA对盈亏底线的贡献。Spies说，这全是关于集成的。作为项目经理，你需要理解业务需求。担任项目经理的不应该是刚刚离开大学校门的人。这个职位需要一个能够为业务部门和IT部门都接受的人。同时，如果设计合理，SOA将成为BPM(业务流程管理)战略的基础。Spies解释说，这距离云计算只差一小步。Spies说，从现在开始，云计
9、算变成了选择和替换现有的系统的另一个采购选择。通过采用云计算，企业也许能够降低成本，提高灵活性。此外，虽然集成是云计算的关键挑战之一，Spies仍坚持认为，如果你正确地实施了SOA，你将拥有基础流程架构和信息架构的路线图，知道如何把它们组织在一起。集成BPM和SOA：模型的重要性【TechTarget中国原创】Richard Watson是Gartner的一位首席研究分析师。最近，他写了很多关于BMP实施的建议。他有17年的IT从业经验，其中包括在Burton集团做了两年分析师。以下是SearchSOA.com网站编辑Jack Vaughan对他的采访。SearchSOA.com：最近我们做了
10、一个调查，其中一个很有趣的结果是：在参与者所面临的挑战中，最大的一个挑战是BPM和SOA的集成。这跟你的观点相符合吗？ Richard Watson：是的，我发现，大多数人做得不太好。SearchSOA.com：因此，这确实是一个大家都面临的挑战？ Richard Watson：对的，对那些面临实施失败的人们来说，这确实是一个常见的威胁。我们同来自23个不同组织的35位业内人士进行了沟通，这些人士的挑选并不是由于他们成功实施过BPM，而是由于他们和我们有业务联系并且基于这种信任关系他们愿意和我们分享他们的经验。很多时候我们从失败人士身上所学到的教训要大大超过从成功人士身上学到的经验。在我们的调
11、查中，我们既有失败人士，也有成功人士，但是对那些“我们在做第二次和第三次尝试”的人来说，他们失败的一个非常常见的原因是，他们的数据建模和数据管理没有做对。另外一点是，在行业调查中，可能是最容易惹起争议的一个发现是：我敢说，在追求从建模到执行的无缝结合模式方面，业界正在走向一个错误的方向。很多厂商和用户所给我的大量反馈也证实了这一点。SearchSOA.com：模型驱动架构似乎在理论上看起来很好，但在实践中还不尽如人意。现在，情况有所改观吗？Richard Watson：自从我从事IT行业以来，我们一直在某种程度上谋求模型驱动的架构。如今，尽管BPM的一些工具已经成熟到可以付诸使用的程度，但是我
12、们调查过的一些人说“是的，我们可以这么做，但是，保持模型和执行环境同步的开销很大，实在是难以负担”。这看起来正是工业界正在努力的方向，但依我看来，这是一个错误的方向。SearchSOA.com：过程模型对软件架构师有什么影响？ Richard Watson：我认为软件架构师的角色跟以前是一样的。如果要使用过程模型来作为沟通需求的载体，那么架构师要确保他们所提交的系统，以及开发组所提交的系统，要忠实于这个模型。很多相关的问题是关于如何使用这个模型，以及是否及时更新模型，模型在多大程度上真实地反映了代码。我想说的是，模型和执行模式之间的脱节，有时候是由于产品创建了一个执行的“框架”。有时候，这个框
13、架阻碍了开发团队使用那些众所周知且经过验证的模式来开发应用。如果他们用他们绝佳的代码，他们的用户界面程序，以及跟授权验证这些基础服务的集成来构建起了这个“执行框架”，他们就不能够自由的使用他们想要用的模式了。他们不得不使用这个框架，而这意味这需要花费更多的精力来维护和交付。你会发现这是一个惹人争论的观点。我需要强调的是，我并不是说模型是垃圾，也不是说应该丢掉模型。模型是BPM最具价值的部分，但我对如何使用模型有不同的看法。模型驱动SOA（一）如果没有架构，SOA将只是一盘未必能够解决企业问题的大杂烩。虽然SOA正受到越来越广泛的关注，但是创建并管理一个真正的面向服务架构并不是一项简单的任务。本
14、文将探讨如何通过模型驱动SOA创建并管理企业架构，解决企业对SOA实施精细管理和协作需求中的问题，让SOA更直观，让业务更规范。精细地管理SOA不管是业务方面还是IT方面，需要处理的变化和更新是永无休止，并且难以预测的。有远见的IT团队认识到，敏捷环境能实现业务与IT之间的有效协作与交流，并能根据企业战略和策略的变化迅速做出调整。IT必须通过商业模型与技术预见他们能否实现让众多利益相关者满意的低成本、高效率的解决方案，并对IT方案实现业务战略目标的价值进行评估。但是，由于业务与IT在操作模式上的不同，一直以来他们都无法以互相理解的方式顺利沟通需求。为了填补这一方面的空白，涌现出许多相关技术与最
15、佳实践。新兴的实现技术，比如SOA把业务与IT结合到一个可以有效协作的环境中，从而达到提高敏捷性的目的。SOA使得并且鼓励IT与业务团队在描述与分析他们的业务战略时能够一起工作。这种沟通与协作上的改善使IT团队能够部署支持公司目标和方针的信息系统及IT方案。可以说，SOA是让企业走上成功之路的最佳途径。可惜的是，它也可能会让企业陷入绝境。虽然SOA有巨大的潜力，但是它也给开发与部署相关应用带来更高层次的复杂性与周密性。要发挥SOA的真正效用，就必须对SOA进行彻底地精细管理，能够让它既它充分发挥作用，又不至失去控制。为了更好地管理SOA，并且给企业创建一个走向成功的环境，我们有必要讨论建模应用对SOA管理的改善。架构是指导原则如果没有架构，SOA将只是一盘未必能够解决企业问题的大杂烩。优秀的SOA架构可以确定高层次的业务要求，保证各个主要方案能够真正满足业务需求。要填补业务需求与实际设计之间难以逾越的鸿沟，任何SOA方案在描述与开发的各个阶段都需要一个清晰的定义。此外，正确地实施SOA方案还面临一个更大的挑战，那就是SOA的核心组成部分服务。不管是规范的Web服务还是服务总线中的软件模块，SOA服务与网络上的其它服务都是以松耦合的方式构成组合应用（composite application，亦称mashup）。组合应用取代了旧
