--正确的SOA开发要求对软件开发方法进行重新设计

　　面向服务架构（SOA）的概念已经成为一个非常时髦的技术术语。尽管技术确实扮演了重要角色，但是正确的SOA方法要求对软件开发方法进行重新设计（或重构）。我们习惯采用基于组件或基于项目的方法来进行应用程序开发，但是SOA要求采用自顶向下（top-down）的方法。这意味着我们应以全新的眼光来看待应用程序设计和项目管理。

　　让我们来探讨一下成功实施SOA的非常重要的10个关键要素。

　　1.企业架构团队
　　SOA是企业范围的长期战略。因此，大多数公司都通过成立中心团队（企业架构团队）来实施SOA，该中心团队掌管并向前推动SOA。在大多数情况下，该团队是一个小而严密的工作组，具有多样且互补的技术，掌管企业的总体架构。企业架构团队负责制定内部标准、蓝图、参考架构、设计模式、模板、一些共享和水平服务等。它与业务线专家紧密合作，或者拥有领域专家作为该团队的一部分。这个高瞻远瞩的中心团队对于减少各个工作组和部门重复开发工作策略以及制定其自己工作方法的风险十分重要。
企业架构团队是成功实施SOA的最关键要素。没有一个理解如何操作和掌控SOA的优秀团队，实施SOA的工作很难成功。

　　2.实施路线图
　　一旦成立了企业架构团队，接下来的主要任务是与业务和IT团队合作，然后制定实施路线图。就像任何一个好的项目，计划得越细致，成功的机会就越大。

　　一个常见策略是开始创建当前状态和未来状态的文档，这些文档使得查看整体情况和理解系统的交互变得更加容易。这一方法还能帮助确定哪些是公司“痛点”的系统。

　　下一步是确定可行的里程碑（在大多数情况中，为6个月、12个月、24个月或36个月）。

　　一些遗留下来的关键任务系统会随着时间的推移而修修补补，包括“粘缝在一起的借助于绷带”的解决方案。像这样的系统就是定时炸弹。有时候，这些就是实现SOA的很好的初始候选项目。通常，根据系统功能的紊乱情况如何、修复它的可行性如何以及投资回报率（ROI）来挑选初始候选项目。

　　该路线图应与公司的战略利益联系在一起。诸如项目进度、资金筹集、人员安排、业务驱动因素和业界竞争等因素都可能影响实施的进程。由于一些因素可能使得SOA脱离正确的轨道，应当仔细地定期追踪进程。记住，最初的一些成功对于赢得对SOA的支持和给机构带来的重构十分重要。因此，从策略的角度看，在初始阶段选择正确的候选项目十分重要。

　　SOA路线图一般具有多个阶段。在第一阶段中，公司进行前期摸索并试图了解技术挑战。在这一阶段，实施诸如验证、授权、确认和数据转换等简单的水平服务。在第二阶段中，制定更多的面向业务的服务。这些服务常常从门户中冒出来，因此很容易获得收集在后端系统中的信息。第三阶段包括聚合服务、开发工作流和集成各个不同的系统。

　　3.架构
　　只有具备健全的架构基础才可发挥SOA的主要优点（松散耦合、重用以及技术和服务的抽象）。企业架构团队是一个中心机构，掌控着整个企业的架构。从SOA的立场上看，架构和设计的以下方面十分重要。

　　平台：最根本的决定之一是使用什么技术。来自底层平台的支持很重要，因为它能帮助我们避免自己编写解决方案。用户还需要考虑团队对具体平台的满意度。一个好的平台能显著减少开发和维护的总体成本。一些公司也使用多个平台的组合。SOA的优点是，当服务成熟到一定程度之后，界面比底层技术更加重要。由于ROI的原因，技术也变得“可插拔”，即可以任意选用技术。

　　标准：对于SOA来说，Web服务是业界最常选用的技术。在这一领域，标准正在不断发展，并且多个相互竞争的标准解决的是同一个特定问题。良好地掌握这些基本原理和要素的实施方向可确保资金不会花在错误的技术上。遵从标准的平台能够保护投资，并且使得与外部合作伙伴和软件开发商的的集成变得更轻松。

　　第三方：公司总是和外部合作伙伴保持联系。尽管我们不能控制第三方的架构，但是我们应试图使他们遵循SOA，这样在长期内使得每一方都更轻松和经济高效。这一点同样适用于系统集成商和开发商。尽量减少战略合作伙伴的数量对于控制复杂性非常有帮助。

　　服务：一个机构可能有几种服务。有一些是垂直的和以业务为中心的，而其他的更加广泛。后一类别中的服务——例如安全、数据转换、翻译和事件服务——一般是较好的初始SOA候选项目。企业架构团队负责在实现“横切”服务中提供设计模式和指导准则。

　　企业架构团队（与各垂直团队相合作）还负责培养Gartner所说的“生产力层”，该“生产力层”促进服务的重用和聚合。Garner称：“没有它，在Web服务和其他服务方向中的投资将很难得到回报。”因此，其中一些服务属于该类别。

　　像Web服务这样的技术使得这些服务独立于环境。这种独立性使得服务可以跨多个水平项目而方便地使用。消息传递可以使应用程序松散地耦合联结，但是为了实现最佳的重用，甚至环境也应被抽象掉。

　　强烈建议这些服务要经过具体计划和架构审查。这将为与之合作的垂直开发团队提供一致的和相似的模式样式、名称空间以及其它。较好的策略是，在利用架构模式的同时，采用业界或领域模式。

　　管理服务：一旦开发和测试了这些服务，就需要将它们部署在生产环境中。正如Web开发世界中那样，开发应用程序是一回事，在生产环境中管理它们完全是另外一回事。服务水平目标（SLO）、服务质量（QoS）、安全、访问控制、故障转移、监视、灾难恢复、审计和通知仅仅是需要管理的长长列表中的一小部分。特定于行业的管理方法，如HIPAA和Sarbanes-Oxley（SOX）可能需要用于控制更改、审计、监视关键系统的附加基础设施。其他需要注意的事情包括：循环负载处理、版本管理、服务的生命周期管理和伸缩性等。

　　您应为服务的健康增长和发展制定规划。因此，应具备良好的变更管理策略。如果您需要遵照HIPAA和SOX等，则这可能是强制性的要求。

　　4.技能
　　优秀的技能分类对于任何软件项目的成功都是必要的，这一分类包括深入理解领域、垂直技术和过程、业界和技术标准、新兴技术和趋势、编译要求、开发平台的专门知识、模式、最佳实践、项目管理和测试。

　　为了能够提供强有力的指导和领导，企业架构团队应该是熟知这些核心技术的一个精干的小组，。而在那些垂直团队中，其成员应深刻理解业务流程并应能够协助EA团队确定和设计良好的服务。

　　5.交付模型
　　交付模型包括三个主要方面：团队组成和规模、项目持续时间和开发方法。由于项目、技术方案、对技术的满意度和专业知识的不同，每个组织的交付模型都不相同。该模型应在各个工作组和项目中保持一致，这样当开发人员跨项目进行转移时，会有相似的经验和最低限度地减少学习弯路。

　　交付模型的示例包括对于中型项目的6x12（6个开发人员12周），以及对于小型项目的4x6（4个开发人员6周）。该团队一般包括诸如项目经理、质量控制（QA）人员或业务分析人员的附加支持成员。支持团队成员理解总体SOA目标很重要。他们需要和企业架构团队紧密合作，并帮助确保工作具有策略意义。公司还已经尝试了不同的SOA常用方法，如敏捷建模（AgileModeling）和极限编程（ExtremeProgramming）。

　　6.管理
　　拥有健全的管理模型能够确保服务的结构化、成熟和健康增长。诸如组织中的驱动因素、文化、技术和信心等因素都显著地影响着这一模型。管理对于确保没有重复劳动和项目不偏离SOA都非常重要。

　　谁应对这一策略负责呢？无法得出直接答案。SOA确实是全体人员的责任。个人和垂直工作组自己均应确保他们总是符合服务方向。用户不应屈从于走捷径的诱惑，除非业务压力而必须这样做。企业架构团队可以发起制订策略，并在一定程度上对其进行监视。然而，即使在一个中型组织中，企业架构团队也不能为每个项目制定策略。

　　企业架构团队和项目管理办公室（PMO）负责项目的优先级制定和排序。所有的业务要求（共享的或企业范围内的）都应经过企业架构团队。与使用单位人员、PMO和垂直团队紧密合作，制定项目的优先级。一旦实施，企业架构团队确保应用程序是符合SOA的。随着服务发展到下一代，企业架构团队为垂直工作组提供技术指导。

　　与第三方开发商和外部合作伙伴一起承担SOA一致性的专门检查。有时候，如果SOA一致性的级别不能令人满意，则企业架构团队成员应与开发商合作，并确保其满足一致性。应制定方法来确保开发商为产品的后继版本提供持续的SOA一致性。

　　管理组织应确定谁拥有给定服务（并因此对此负责）。责权的结合能够减少模糊性，并且在出现问题时能够确认哪个团队对此负责。这对于共享的或企业范围的服务（如编写日志和安全）特别重要。在组合式服务的情况下，服务的总体质量取决于每一个组成服务。适当的责权结合有助于系统的平稳运行。

　　7.战略安排
　　新技术的刺激有时候会妨碍基本的业务因素。IT业在这方面有许多实际例子。有了SOA，这可能更容易发生。

　　因此，企业架构团队的重要任务之一是进行持续的现实性检查。企业架构团队和业务专家需要确保SOA的步伐总是跟随战略性业务目标。如果短期的商业目标与长期目标冲突，那么该团队应和高级管理层协商并找出最佳解决途径。

　　这一点说起来容易做起来难。由于总会有异常发生，必须具有一个基于其问题的紧急程度进行改正的程序，这一点很重要。否则，这些异常可能会从制订IT项目优先级的业务流程中被孤立出来。
无论技术解决方案多么优秀，不着眼于业务价值的解决方案都是毫无用处的。

　　8.沟通
　　SOA是整个企业范围的工作。在大多数公司中，企业架构团队创建其他垂直开发组能够利用的可重用服务。即使在一个中型的IT团队中，协调工作也是一项巨大的任务。其他工作组如何才能知道有什么服务可供使用？哪些组件可以忽视？正确使用服务的方法是什么？

　　提供服务的目录清单是一种可能的方法，但是在大多数实际情况中，这一点并不能确保人们理解它。应该利用过程和最佳实践来发布和消费有关可用服务的信息。一些公司为此目的而使用门户，而另一些公司则使用通知媒介，如blogs和wikis。无论您喜欢什么媒介，在正确的时间对正确的人发布正确的信息都十分重要。

　　SOA涉及重大的重新设计，而每个人都对变化持有抵触情绪。在任何一个组织中，特别是在实施的初始阶段，预计会有一些抵触。怀疑对于组织有利有弊。它是有利的，因为怀疑可平衡激进。它们有助于确保SOA支持者不会过于有野心。但是怀疑也是有弊的，因为它为说服怀疑者和推动正确的变化带来了额外的工作。

　　Web服务技术的缺陷之一是，如果没有良好的沟通渠道，架构可能变得更糟。采用XML计划。当团队独立工作时，他们总是创建定制的但未必基于标准的模式。“最后一分钟”的压力和严格的时间期限成为这一现象的催化剂。这一方法在短期内是有效的，但是这种“临时”计划很快就累积起来，并导致系统过于相互依赖和脆弱。

　　持续的沟通十分重要。公司通过定期举行全体会议找到了成功之门。也可以通过这些会议来交流项目如何带来良好的ROI，以及其他工作组如何使用现有的服务来使其流程更加高效。这将有助于更快的采纳。

　　9.高级管理层的支持
　　高级管理层的支持不仅对控制抵触力量很重要，而且对其他方面如资金筹集等也很重要。SOA包括先期的投资。除非IT具有高层的支持，否则推动它向前是很困难的。如果我们看看业界主要的SOA实施，一个共同的模式就是CEO强烈信任该范例和技术的价值体现。

　　高级管理层还应确保，SOA实施符合业务需求并提供了所承诺的ROI。管理指导对于确保长期的业务目标和IT方向之间没有偏离极为重要。

　　10.持续进行重新设计
　　SOA不是一次性的模型。它包括持续的发展和重新设计。在初始几个阶段，它主要涉及到构建新服务以及将遗留的应用程序（使用适配器）部署在SOA上。水平服务（或共享服务）通常也是初始阶段的一部分。一旦基础服务就位，服务的下一代通常包括抽象化和精化业务流程。沿着这一路径我们需要经过多次迭代。对于每一次迭代，反馈信息传回到服务并进一步精化。

　　全程实现SOA的目的在于，在不断变化的市场条件下促进灵活性和适应性。随着业务的不断发展，支持它的服务也将不断发展。

　　SOA投资
　　走上SOA之路就像是进行退休储蓄——这是一种长期的投资。用户可能会经历一些短期的痛苦，但是最终将得到回报。灵活、坚定、纪律和执着是先决条件。抛弃不良习惯而采用更好的习惯，真诚地反省和坚定不移的恒心。SOA并非万能药，但是它确实能够帮助集成业务关键型软件。SOA既是技术也是业务流程的重构。透彻地理解这两者有助于确保长期的成功。

　　致谢：感谢MikeMcCoy、VasaviNemani、MadhusudanNori和SrinivasaNemani，感谢他们的反馈意见和建议。

　　原文出处：http://www.fawcette.com/weblogicpro/2004_09/magazine/features/akadiyala/