SOA在企业发展中的影响

　　面向服务架构与我们传统意义中封闭式的应用有很多的不同。SOA架构下的应用是多层次的，其生命周期也是具有多阶段性，并且有着高度的可重用性，随着企业的不断发展，来自其自身内部或者是外部的变化

　　也会给其带来多方面的影响。它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

　　提供一个安全可靠并完全适用的SOA并非易事，由于所提到的这些复杂因素，需要通过不同的方式确保SOA质量问题。在一个复杂的系统环境下，质量测试必须深入到各个环节，才能转化为高质量的交付应用。

　　架构与接口的连贯性

　　具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。

　　对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需(On demand)业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。

　　举例来说，架构与接口必须遵循一定的政策和标准来在组织内部保持一致性。为了达到这样的连贯性，企业必须在设计和开发阶段就开始推动标准化和特定政策的实行。一旦可定义的政策开始实行，SOA资产中的连贯性和基本信任就算达成了。

　　为一项服务资产推行信任的过程必须在该资产建立初期就开始实行。早期和持续的对于该资产质量的可视性能促进信任的建立和随后的重新利用。为了在促进早期信任，企业必须定义和实施在服务生命周期中支配其不同方面的政策。比如，支配着服务开发的政策：诸如计划合法性(W3C)，语意的标准一致性，WS-I一致性和采用WS-*标准的定义。此类政策对于达成连贯性和保证再利用和互用性是至关重要的。

　　政策也可以囊括最佳实践――普遍被接受的最佳实践以及与企业目标的底层服务相关的最佳实践。这些一般领政策包括：安全、可维护性、可靠性和性能，以及根据特定要求制定的所有其他政策。

　　一旦政策被定义，那么对其的应用、验证、测试和测量将是至关重要的。我们必须使同步数据链路控制(SDLC)基础架构和流程自动化，以使得这些政策和标准能够通过开发、测试和质量团队一致的在SOA产物中应用。

　　持续回归测试：

　　为了正确有力的实施服务资产政策、合约、情景描述，企业必须通过一系列自动的、持续的回归测试来验证。

　　作为每一个特定服务资产的生命周期的一部分，持续回归测试(在任何发布周期内)对于提供持续和可预测的质量都是必要的，这个测试必须是由业务需求所决定的，并包括功能需求、技术需求和性能预期。如果这些早期测试是由需求驱动的，那么质量部门将通过重新利用测试资产取得显著的优势。

　　为了保障安全、可靠、一致的服务资产，通过资产注册表来进行集成是必要的。持续回归测试应该每夜自动建立并运行，而适当的测试数据可以通过中央资产注册表获得。那么测试将在不打断现存开发过程的情况下持续运行。

　　这种自动测试保障了需求的自动验证和开发阶段与质量保证期间的测试资产重新利用。自动回归测试同时也能为应用软件政策实施提供文件证明，从而对更可预测的成果提供了保障。

　　SOA环境的复杂性

　　在一个SOA环境中开发并保证功能是非常复杂的。系统的分布式性质和数据几乎使建立阶段性测试环境成为不可能。

　　SOA的设计部分通常都需要使用未完成的

　　或不可获得的服务，通过仿效服务来提供压缩服务是比较理想化的方式。一个开发员或质量工程师应该仿效服务并在早期就演练业务情景以在早期阶段就确认问题所在，并判断服务的正确性、更好的预测性能。

　　流程敏捷性与速度

　　先进的平台可以保证一个提供速度与敏捷性的SOA基础设施以满足更加复杂的业务需求变化。但不幸的是，质量检测流程仍旧还停留在传统的连续程度。有效协作与积木式构建方式的质量解决方法会是针对SOA所带来的一系列复杂问题最为合适的方法。如果一个企业需要快速递增的可交付产品从而达到需要的敏捷性，那么仅仅通过这样传统的质量检测流程是绝对做不到的。

　　面对SOA环境下的新交付状况，在企业中必须完全改变这样的质量监测手法才能更好的受益于敏捷性变化所带来的好处。这样的话一个可重复，并以变化为基础的质量流程将会最大程度的体现SOA真正的敏捷性优势。在之前的测试过程中所使用到的测试方法在业务服务的演变过程将会得到有效的重用，从而提高敏捷性和速度反应。

　　此外，设置连续性的回归测试套件将会给刚刚所提到的敏捷性增加带来显著的效果。

　　以变化为基础的测试可以让团队更好的共同合作，改变版本控制，了解影响范围等，这样的测试以节约时间为重，并提供更快更准确的完善解决方案。

　　整合

　　如何让业务合作伙伴更有效的整合到一起仍旧是一个停留在“整合”层面的难题。无论是对于任何两个以上的业务流程而言都必须得做出取舍和让步。这意味着即便是基于标准的生产和消费服务都会有难以避免的麻烦所在。为了消除在整合过程中所出现的问题，业务合作伙伴需要获得一份关于服务的“健康报告”，一个类似于包含备份与数据测试的报告从而可以对服务的交互起到监测调控作用。这可以有效的防止错误在整个周期的最开始时期就被体现出来，而这也可以在服务资产回归测试中暴露并得到解决。

　　发展和发展前期的准备

　　在业务流程方面，架构师将必须做出选择，从而确保某项特定的服务资产会是所有资产中最优先的。当然，对于这项服务的选择决非毫无缘由。架构师在做出决定之前必须能够验证他们所选择的服务资产所能表现出来的性能。这使得开发人员以及质量测试人员可以通过其连续不断的回归测试手段所能实现的更新结果去对自己的业务情况和业务流程有一个清楚准确的认识。

　　结论

　　大家看到有大企业，两三年前还在讨论建立现代企业制度，还要从老三会变成新三会，差一百多天的时间。同时这些企业要构建最先进，与世界最同步的，甚至超过SOA的标准，这个对我们来说的确很严重，但是的确又是一个机会。但是在未来全球化当中没有一个企业是封闭的。考虑到整个SOA环境的复杂性，对于企业内部而言鲜明的角色和责任将会带来一个非常显著的影响。传统的应用测试方法将不能再确保任何有关于SOA的应用质量。在当前的SOA时代里，逻辑问题在信息层与跨系统之间表现的更为抽象，正是出于这样的原因才使得测试变得更加复杂，而质量保证方面不由得有所下降。虽然发展同质量评估之间的问题会一如既往的维持下去，各个环节的职能尤其是质量检测流程还是需要尽可能早的开始提升，从而在整个周期的最开始便能确保安全，可靠已经完全兼容的面向服务架构。