架构和设计模式是SOA成功关键.docx
《架构和设计模式是SOA成功关键.docx》由会员分享，可在线阅读，更多相关《架构和设计模式是SOA成功关键.docx（15页珍藏版）》请在冰豆网上搜索。
架构和设计模式是SOA成功关键
架构和设计模式是SOA成功关键
导读：
笔者访问了当今Web服务领域最忌影响力的人物之一AnneThomasManes，主要介绍了其最近的报告《SOA现状》的结果以及为什么SOA依然盛行。
【TechTarget中国原创】AnneThomasManes是当今Web服务领域最忌影响力的人物之一。
她是BurtonGroup的调研员，同时也是SOA和Web服务话题的演讲家、作家以及博主。
Manes最近合著了《SOA现状》简明报告。
此次访问围绕着报告的结果和建议以及为什么SOA依然盛行。
TTSOA：
在您的报告中谈到一些组织并没有实现其SOA倡议承诺，其中一个关键原因是他们并不关注架构。
你嫩能够解释一下吗？
AnneThomasManes：
架构确实非常难。
人们习惯了通常做事的方式，尤其是应用系统内的设计模式。
因为很多组织不采纳新的设计模式来创建松耦合服务，所以他们在削减成本和增加敏捷性上并没有得到显著效果。
为了实现这些，我们必须回顾一下最初是什么阻碍了它，95%的例子中，其应用架构是障碍，而且应用管理和维护起来价格昂贵。
我们必须修正架构。
TTSOA：
现在也有很多SOA的先行者，他们成功了吗？
Manes：
我还是要说只有极少数组织的SOA已经成功了。
大部分组织已经使用SOA技术创建了成功的应用。
SOA技术的使用在这个层面上可以说是普遍的。
而且并不是那些陈旧的集成中间件，而是已经升级的ESB。
它们并没有使用专有的协议，而是web服务堆栈。
在迁移到下一个水平的协同中间件上还是有一定的好处的，但是一个应用的成功实施并不会成就SOA。
就像你完成了一个系统的设计，你需要确定是否追随了面向服务、封装和松耦合的核心原则。
但是如何来确保减少了依赖性呢？
这也正是设计模式的作用所在了。
最大的挑战是现有的经验丰富的面向对象开发人员，他们理解面向对象设计模式，而且没有认识到他们习惯使用的设计模式在松耦合的世界里并不适用。
另一个关键的方面是服务建模。
我们如何确定什么能够成为一种服务，这项服务该投入多少钱？
在某种程度上，我们可以使用一些模式，但是服务建模是一门艺术，很多人对此并没有足够的经验。
我们要完成哪些流程来确我们所创建的是正确的服务呢？
所以更为根本的是培训。
大家知道原则或者模式是什么吗？
知道如何建模吗？
在《揭秘SOA已死言论作者真正的目的》中，我们将为您介绍，当初提出SOA已死言论的Manes最初的目的究竟是什么？
《揭秘SOA已死言论作者真正的目的》
【TechTarget中国原创】在《架构和设计模式是SOA成功关键》中，我们主要介绍了其最近的报告《SOA现状》的结果以及为什么SOA依然盛行。
下面我们将深度解读当初提出SOA已死言论的Manes最初的目的究竟是什么？
TTSOA：
那么文化问题如何处理呢？
Manes：
我们过去一直探讨的工程学方面的核心设计是什么？
为了设计一个良好的面向服务系统，组织中必须拥有这些核心工程性能。
但是问题是这是否促进了绝大多数组织呢，他们用以来支持共享服务的创建。
基金模型的创建是个大问题。
它们并不是用来支持共享服务的概念的。
TTSOA：
这会是SOA的未来吗？
Manes：
我不知道怎么来解决这个问题。
问题是很多组织并不希望在架构上进行投资，但是如果我们希望创建敏捷性并减少成本，就必须修复这个应用组合。
应用组合管理以及一种严格的应用系统关闭是个不错的办法，但是我们必须用其他的来替代这些。
如果我们有十个管理客户信息的应用能够支持十个用力的话。
我致力于SOA就是希望能够增加敏捷性并减少资源。
我们必须处理问题源，也就是冗余和很难管理和维护的单片紧耦合系统。
减少成本、让应用易于管理和维护、减少冗余并让信息易于访问都可以通过SOA来完成。
我想没有别的方法了。
如果我们希望支持云、mashup和移动，最好还是进行面性服务的工作。
TTSOA：
那我想知道，您的2009年的报告《SOA已死，服务长存》引发了很多争论，您的目的是什么？
Manes：
我所说的并不是真的死亡；它被称为服务了。
（译者注：
在其博文中，Manes写到“SOA已死，面向服务架构的需要却更强了。
”）关键的一点在于我们不能买卖SOA了，因为我们没能交付SOA的诺言。
2009年事预算紧缩的一年，企业对于在SOA上花费五百万到一千万美元并不感兴趣。
我所要表达的是SOA不能商业化，你不能说我需要更多的资金，尤其是你不能证明其价值的时候。
停止对于SOA的探讨并开始时间。
我们需要开始在从事的每一个项目中应用SOA原则，接受这种教训而不是技术。
很多人从不会把标题读完，而且他们这也是他们放弃SOA的一种理由，但这并不是我的初衷。
厂商一定恨死我了，但是我想他们已经接纳了这个概念，因为SOA不仅是一项技术，而是设计和架构。
很多人说我的博客可能是对SOA最好的事情了，这是一种对于业界的苏醒召唤。
三年前客户提出的最普遍的问题是我应该购买什么样的ESB？
我说你为什么要这样问？
他们说这是厂商告诉我们的或者说分析师这样说的。
ESB是集成你的系统的技术的一部分，但它并不会带给你SOA。
重构时应该做什么？
从应用组合的愿景出发。
SOA有助于改善IT和业务需求的一致性。
然而，SOA要取得成功，企业应该有长远的考虑。
架构不仅仅是一个项目。
它是一个要运行许多年的项目。
一般来说，SOA项目的生命周期比ERP（企业资源规划）系统长。
ERP系统的生命周期是12至13年。
Spies还建议SOA架构师为企业定义价值，让企业理解SOA对盈亏底线的贡献。
Spies说，这全是关于集成的。
作为项目经理，你需要理解业务需求。
担任项目经理的不应该是刚刚离开大学校门的人。
这个职位需要一个能够为业务部门和IT部门都接受的人。
同时，如果设计合理，SOA将成为BPM（业务流程管理）战略的基础。
Spies解释说，这距离云计算只差一小步。
Spies说，从现在开始，云计算变成了选择和替换现有的系统的另一个采购选择。
通过采用云计算，企业也许能够降低成本，提高灵活性。
此外，虽然集成是云计算的关键挑战之一，Spies仍坚持认为，如果你正确地实施了SOA，你将拥有基础流程架构和信息架构的路线图，知道如何把它们组织在一起。
集成BPM和SOA：
模型的重要性
【TechTarget中国原创】RichardWatson是Gartner的一位首席研究分析师。
最近，他写了很多关于BMP实施的建议。
他有17年的IT从业经验，其中包括在Burton集团做了两年分析师。
以下是SearchSOA.com网站编辑JackVaughan对他的采访。
SearchSOA.com：
最近我们做了一个调查，其中一个很有趣的结果是：
在参与者所面临的挑战中，最大的一个挑战是BPM和SOA的集成。
这跟你的观点相符合吗？
RichardWatson：
是的，我发现，大多数人做得不太好。
SearchSOA.com：
因此，这确实是一个大家都面临的挑战？
RichardWatson：
对的，对那些面临实施失败的人们来说，这确实是一个常见的威胁。
我们同来自23个不同组织的35位业内人士进行了沟通，这些人士的挑选并不是由于他们成功实施过BPM，而是由于他们和我们有业务联系并且基于这种信任关系他们愿意和我们分享他们的经验。
很多时候我们从失败人士身上所学到的教训要大大超过从成功人士身上学到的经验。
在我们的调查中，我们既有失败人士，也有成功人士，但是对那些“我们在做第二次和第三次尝试”的人来说，他们失败的一个非常常见的原因是，他们的数据建模和数据管理没有做对。
另外一点是，在行业调查中，可能是最容易惹起争议的一个发现是：
我敢说，在追求从建模到执行的无缝结合模式方面，业界正在走向一个错误的方向。
很多厂商和用户所给我的大量反馈也证实了这一点。
SearchSOA.com：
模型驱动架构似乎在理论上看起来很好，但在实践中还不尽如人意。
现在，情况有所改观吗？
RichardWatson：
自从我从事IT行业以来，我们一直在某种程度上谋求模型驱动的架构。
如今，尽管BPM的一些工具已经成熟到可以付诸使用的程度，但是我们调查过的一些人说“是的，我们可以这么做，但是，保持模型和执行环境同步的开销很大，实在是难以负担”。
这看起来正是工业界正在努力的方向，但依我看来，这是一个错误的方向。
SearchSOA.com：
过程模型对软件架构师有什么影响？
RichardWatson：
我认为软件架构师的角色跟以前是一样的。
如果要使用过程模型来作为沟通需求的载体，那么架构师要确保他们所提交的系统，以及开发组所提交的系统，要忠实于这个模型。
很多相关的问题是关于如何使用这个模型，以及是否及时更新模型，模型在多大程度上真实地反映了代码。
我想说的是，模型和执行模式之间的脱节，有时候是由于产品创建了一个执行的“框架”。
有时候，这个框架阻碍了开发团队使用那些众所周知且经过验证的模式来开发应用。
如果他们用他们绝佳的代码，他们的用户界面程序，以及跟授权验证这些基础服务的集成来构建起了这个“执行框架”，他们就不能够自由的使用他们想要用的模式了。
他们不得不使用这个框架，而这意味这需要花费更多的精力来维护和交付。
你会发现这是一个惹人争论的观点。
我需要强调的是，我并不是说模型是垃圾，也不是说应该丢掉模型。
模型是BPM最具价值的部分，但我对如何使用模型有不同的看法。
模型驱动SOA
（一）
如果没有架构，SOA将只是一盘未必能够解决企业问题的大杂烩。
虽然SOA正受到越来越广泛的关注，但是创建并管理一个真正的面向服务架构并不是一项简单的任务。
本文将探讨如何通过模型驱动SOA创建并管理企业架构，解决企业对SOA实施精细管理和协作需求中的问题，让SOA更直观，让业务更规范。
精细地管理SOA
不管是业务方面还是IT方面，需要处理的变化和更新是永无休止，并且难以预测的。
有远见的IT团队认识到，敏捷环境能实现业务与IT之间的有效协作与交流，并能根据企业战略和策略的变化迅速做出调整。
IT必须通过商业模型与技术预见他们能否实现让众多利益相关者满意的低成本、高效率的解决方案，并对IT方案实现业务战略目标的价值进行评估。
但是，由于业务与IT在操作模式上的不同，一直以来他们都无法以互相理解的方式顺利沟通需求。
为了填补这一方面的空白，涌现出许多相关技术与最佳实践。
新兴的实现技术，比如SOA把业务与IT结合到一个可以有效协作的环境中，从而达到提高敏捷性的目的。
SOA使得并且鼓励IT与业务团队在描述与分析他们的业务战略时能够一起工作。
这种沟通与协作上的改善使IT团队能够部署支持公司目标和方针的信息系统及IT方案。
可以说，SOA是让企业走上成功之路的最佳途径。
可惜的是，它也可能会让企业陷入绝境。
虽然SOA有巨大的潜力，但是它也给开发与部署相关应用带来更高层次的复杂性与周密性。
要发挥SOA的真正效用，就必须对SOA进行彻底地精细管理，能够让它既它充分发挥作用，又不至失去控制。
为了更好地管理SOA，并且给企业创建一个走向成功的环境，我们有必要讨论建模应用对SOA管理的改善。
架构是指导原则
如果没有架构，SOA将只是一盘未必能够解决企业问题的大杂烩。
优秀的SOA架构可以确定高层次的业务要求，保证各个主要方案能够真正满足业务需求。
要填补业务需求与实际设计之间难以逾越的鸿沟，任何SOA方案在描述与开发的各个阶段都需要一个清晰的定义。
此外，正确地实施SOA方案还面临一个更大的挑战，那就是SOA的核心组成部分——服务。
不管是规范的Web服务还是服务总线中的软件模块，SOA服务与网络上的其它服务都是以松耦合的方式构成组合应用（compositeapplication，亦称mashup）。
组合应用取代了旧的软件应用程序——那些用来解决个别问题或某一系列问题的整体式程序。
组合应用包含了“即插即用”的服务组件，使其不管在构建时还是后来必须对应用程序进行修改以适应新的业务状态时，都比那些整体式程序更具弹性、易于修改。
许多人认为这就是SOA的全部优点了，实际上并不是如此。
SOA至少还有一个更高层次的应用——它可以让公司在相似甚至稍有不同的业务领域中重用或重新部署这些组合应用。
比如，一个财务应用程序可能包含应付账款、应收账款、信用卡交易处理和银行业务等松耦合的服务。
第一个应用程序可能部署在公司美国的业务中。
但是后来，公司业务扩展到英国，可能在英国的财务处理需求和美国非常相似，只是由于区域不同或货币不同而在银行业务方面有特殊的要求。
在SOA之前，这意味着英国的IT团队要重写美国的财务软件，甚至完全从零开始。
而借助SOA，他们就可以继续使用与美国软件中相同的服务，只需要把银行业务服务替换掉即可。
最坏的情况，英国的团队也只需要写一个独立的服务。
相对企业来说，这种层次的重用性与敏捷性既降低了开发成本又提高了业务响应性，从而使公司获得巨大的优势。
由于IT必须了解并管理由SOA而产生的庞大的蜘蛛网一样的服务与应用，因此，这也意味着复杂性的增加。
IT还必须决定是否需要一个新服务，或者在更新一个现有服务、开发一个新服务、通过网络购买一个第三方服务中哪种方式更利于成本节省和提高效率。
在SOA中采用规范的建模方法，即模型驱动SOA，可以非常有效地解决这些问题。
模型驱动SOA将高层次的业务方针直接与具体的服务功能联系，方便创建与维护符合业务与设计目标的交互服务，同时还能成为一种高效的业务沟通语言。
构建SOA蓝图
对于模型驱动SOA来说，最重要的内容就是企业架构。
聪明的企业为了解他们当前的业务操作情况、将来他们想用什么方式进行业务操作，以及各种技术对这些操作的支持情况想尽一切办法。
而通过对企业架构进行建模便可以对此有一个大概的视图，同时获得制定SOA部署计划所需的基础信息。
企业架构同时作为蓝图与路线图，将IT、数据和业务过程与业务目标与战略联系到一起。
它能直观地表示这些实践之间的关系，因此企业可以使用实例来分析IT对业务操作的支持程度。
为了获得更高的效率，蓝图上必须明确标出在哪里采取行动。
这些行动包括IT服务，甚至包括所部署的软件，其中大部分是面向SOA进行的开发与部署。
企业架构模型是实现SOA的关键，它涉及多供应商、多平台环境下的松耦合应用。
它提供了服务“互操作性”的企业视图，也是取得成功的关键因素之一。
企业架构为企业提供了所需的信息与分析以更好地利用SOA。
这些用来选择合理服务所必需的分析是SOA能带来的最大价值之一。
而构建这些服务，使其成为包含技术性服务（预构建的软件模块）的、可部署应用的任务，只要交给IT团队即可，这一点将在下面讨论。
通过蓝图，企业可以把SOA做为一种构建架构的新方式，而不仅仅是用来传输数据的新技术。
企业架构是一个实现SOA价值的平台，因为它使企业能够以新方式获取完成新任务所需的信息，从而避免只拘泥于旧有方式来使用新技术。
反过来，这也发挥了SOA时效性及敏捷性的优势。
对协作的需求
一旦确定了经营方案，企业就必须培养一个能使业务与IT有效协作和沟通的环境。
IT部门必须通过商业模型与技术预见能否提供让众多利益相关者满意的低成本、高效率的解决方案。
业务部门必须确定其计划目标可行并且实现方式成本低廉。
同时，还需要评估所用方案对达成业务战略目标所起到的作用。
模型驱动SOA为业务与IT提供了一个通用的工作流程，使其相互间能以一种双方都能理解的方式进行交流。
基于全面的设计模型作出的开发方案为企业提供了敏捷性，从而成功地将业务与IT结合到一个协作性良好的环境中。
企业级的建模使IT与业务团队描述、分析业务战略时能够专注于其专业领域，并直接看到他们对宏观设计所造成的影响。
这样既改善了沟通与协作方式，又使得IT团队能以最有效、最实际的方式部署支持公司目标和方针的方案。
真正的SOA治理
真正的SOA治理应该是和设计时的策略管理一起开始的。
为在日常实践中成功发挥SOA的优势，企业必须保证每个项目都与业务需求和最佳实践一致。
当构建大型复杂的应用网络时，企业应该尽量把初期的高层次业务需求文档整理成为详细的技术说明文档，同时保持需求与说明文档之间的可跟踪性以验证一致性。
保持可跟踪性也有利于在业务需求发生变化或即将发生变化时进行影响分析。
对需求的追踪过程既可以提高敏捷性，又能为IT提供何时可以进行更新的参考。
需求定义与需求管理方案有助于策划人员集中精力进行需求采集、整理与跟踪。
这些方案在提高信息可视度和改善协作能力的同时，还能对需求进行优先分级，把结果直观地显示出来，以确定需要实现的需求。
业务分析人员可以在整个开发生命周期对需求进行跟踪，保证这些需求与客户要求的一致性，并保证其符合相关的产业或政府法规政策。
让SOA更直观
模型驱动SOA采用了产业标准方法和语言对组合应用进行直观的描述和管理，从而构成能在整个应用与相关技术性服务的开发周期中引入规范化并逐渐发展自动化的SOA方案。
建模使业务架构设计人员、方案设计人员和开发人员能在更高的层次上工作，并通过图形分析和自动检测在整个开发周期中引入质量保证技术。
这种更高层次的抽象可以抛弃细节问题，让用户根据所需的用例和功能发表自己独特的观点、集中精力考虑应用所需提供的方案而无需担心如何构建应用。
用户可以通过模拟分析并测试既定设计方案的正确性和效率，从而验证方案与用户需求的一致性。
这种SOA开发中的建模方法能使用户在开发的各个阶段（从架构到最终部署）不断检验错误和测试一致性，因此既能保证质量又能保证更低的成本。
通过暴露组件及其接口，并对现有软件进行架构上的逆向开发以重用或重新部署服务、创建SOA接口升级遗留服务、改善现有组件之间的编排机制，它使分布式的网络型应用能够发挥最大的效率。
还有一种优势，可能也是最重要的，就是这种基于模型的方法使开发人员能够在进行真正的升级之前模拟并测试对当前应用所做的改变，为用户节省昂贵的检修时间，并避免用户遇到因使用未经过检测的应用升级而带来的风险。
使方案规范化
企业架构与SOA应用开发环境结合得越紧密越好。
在最理想的情况下，企业在这两者之间应该实现无缝连接，甚至还能支持相关的技术，比如要求管理和变更管理。
而目标则应该是实现空前的企业范围的协作，使内部团队能够明白并整理业务战略并开发能够实现商业目标的IT方案。
换句话说，这就是从概念到部署、连续的、具有端对端可跟踪性和可靠性的工作流程，保证各个利益相关人随时都能正确地读取数据或使用相关技术。
由于商业案例驱动着需求，而需求驱动着应用开发，因此需求管理实际上贯穿着整个过程。
（下文是关于需求管理在整个项目周期中作用的论述）
业界有关研究表明，拙劣的需求实践是导致项目失败的最大原因。
相反，优秀的需求实践又是项目成功的主要原因。
需求过程并不是项目生命周期中的一个一次性的预先执行的步骤。
需求贯穿着所有具有共同目标的开发规则、质量保证；并且，需求还能提供开发团队与客户之间的合约。
由于应用开发越来越复杂，要清晰地描述应用的要求也变得越来越困难，而要理解这些描述更是难上加难。
许多架构师采用了全面的过程与方法论使需求管理与应用建模能够互相提供必需的信息。
这种协作过程使架构师们既能描述问题与解决方案，同时还能跟上在这个过程中所做的决策。
要保证优秀的需求管理和项目成功，一个办法是采用正式的需求管理方案。
这样可以提高业务方针、客户需求、技术细节和政策的可视性。
由于强有力的采集、关联、分析、根据需求管理变更和追踪能力，这些方案保证了与需求的一致性，并保证符合相关政策与标准。
最重要的是，它们能够自动将这些基于同一目标的开发规范和质量保证结合到一起。
比如，建模与支持企业架构、业务过程分析、SOA应用开发和需求管理的产品的无缝集成就可以实现这种工作流程。
集成的方案以一种可以被所有利益相关人理解的方式，为每个利益相关人提供了交流与检查新的或更新的商业战略、实现理念与变更的渠道。
影响分析可以在整个企业中进行，让所有利益相关人都可以在制定最终决策并实施之前评估可能发生的变化。
从高层的业务应用与服务编排，到技术服务用途的复合应用的设计与编排，几乎在所有的层次都可以描述、分析、测试并开发SOA的概念、设计与部署。
在各个层次对设计进行模拟与测试很重要，而通过设计模型则可以把实际的Web服务当做模拟的一部分来调用并执行。
在设计可部署的组合应用的时候，开发团队就可以在SOA建模环境中测试应用的完整性，利用测试模型获得所缺少的服务的细节与设计的基本信息，并决定应应该从第三方购买这些缺少的服务或是根据设计模型提供的信息进行开发。
采用模型驱动SOA
面向服务架构（SOA）作为一种实现基于组合应用开发的企业方法论获得越来越多的赞同。
为了发挥最大效率，这种SOA方案既需要一个明确的定义，也需要与业务和设计保持同步。
一个规范的基于模型的SOA方案，一经验证可以填补业务与IT之间的空隙，就可以使企业合理地部署并管理SOA环境。
然后，SOA就能成为高效的业务语言，有效地管理并规划所部署的应用的复杂性。
建模可以直观地表示出高层次的业务方针与各种服务的具体功能之间的关系，方便各种各样的用来实现业务目标与设计目标的应用的构建与维护。
这项技术的前景怎样呢？
跟以往一样，预测某项具体的技术将来会有什么样的发展是一件很困难的事。
然而，我们可以预计，随着企业逐渐体会到SOA的强大、接受SOA带来的敏捷性与灵活性，并且能够承担随后带来的责任，越多越多优秀的过程与最佳实践也必然会随之涌现。
模型驱动的SOA由于能直观地表示企业在业务与技术方面的情况，从而能够保证企业操作跟得上商业环境的变化。
SOA模型驱动呈现
【TechTarget中国原创】业务流程管理（businessprocessmanagement，BPM）与面向服务架构（service-orientedarchitecture，SOA）的结合将有效驱动一种新的应用开发建模。
来自IDC应用开发研究部副主席SteveHendrick这样说道。
针对于本周TelelogicAB公司所新近发布的SOA模型驱动工具，SteveHendrick也对此做了相应的评论，他说道，“我不确定你们需要按照这条可测的路线去落实SOA，当然你也可以不需要建模工具的支持去实现它。
”
从企业角度出发来看，他们需要一个更多条理性和连贯性的方式去构建他们的应用系统，达到以Web服务的方式重用，根据迫切业务需求进行建模，以及确凿的业务流程从而更进一步的实现SOA所带来的好处。
Hendrick如是说。
但是，同时他也承认，包括他在内的大部分分析师都仅仅认为这会是一个趋势，而没有想过会这么快就出现了。
“我们的大多数都低估了业务流程建模的成长速度，它会是一个组织内部的热门讨论主题。
”他继续补充道。
“从过去的历史看来，我们只是熟悉了UML流程建模。
但是在SOA面前，这远远只是低层次的，甚至几乎起不了什么具体的效果。
”
回到最初，开发人员往往是最大限度的忍受着来自需求征集方面的工作，这就如同去收集隔板上的灰尘，然活将这些需求整理起来并开始着手代码开发工作。
然后在SOA和BPM得到采用之后，以及在伴随的相关技术的支持下，诸如业务流程建模标注（businessprocessmodelingnotation，BPMN）和业务流程执行语言（businessprocessexecutionlanguage，BPEL），整个应用系统开发过程的困难将得到最大程度的降低。
Hendrick说道，“在过去的一两年时间里
升级会员 