文章的第一部分讨论了SOA系统的分散性，以及在有众多小组参与的情况下，在这一过程中确保质量所遇到的困难。因此我们为连接工作流提供了许多策略，并且支持重用其它小组工作成果。当问题出现时，及时找出负责解决问题的那部分系统。在本文的第二部分我们将从组织层面转移到技术层面。分散式SOA系统中有那些技术难题？我们需要采用何种原则，实施什么样的测试才能解决这些问题？

　　使用SOA系统对许多不同的组件都有依赖性。而大多数小组都无法及时控制这些组件。这样就会直接引发两个技术问题。首先，一个小组创建的系统质量取决于其它小组建造的组件质量，不管这些组件建在同一个组织里，还是由不同的业务伙伴人建成。如果一个组件出了问题，使用这个组件的系统也会跟着出问题。其次，要对一个依赖外部组件的系统进行测试十分困难，因为进行测试的小组无法直接控制这些组件。一旦这个组件不能用了，或者出现了故障，这个系统测试就会受到干扰。而且在组件合法但确明显错误的条件下测试系统就难上加难了。测试分散式系统的更一个难题就是对整个业务流程情况进行测试。正如文章第一部分所提到的，在一个流程中，用户可能会和网络接口发生交互作用，一个用户销售人员可能会批准一个用户要求。这样就会触发一个Web服务。多层系统界面要求这种互操作性，以确保整个流程得以执行。

　　确保所有系统组件的安全

　　要想描述每一个组件的质量原则，必须要确保整个系统的质量。这些原则需要管理组件的编写方式。所有建立在网络和SOA基础上的系统必须要考虑其安全性。同时还要囊括密码编写原则以确保我们能够解决在OWASP Top Ten所提到的问题。此外，Web服务也要考虑W3C，OASIS，和WS-中的互操作标准。对于SOA服务来说，许多WS-*标准都很重要—这些标准取决于应用的要求。参见SOA标准的实例。Web服务必须满足SLAs。

　　上述所有的原则都会影响到密码和组件的编写。我们需要考虑的另一个原则就是要强制执行自动化功能测试实例。每个组件里都有这种实例。这些功能测试可能是单位测试也可能是为信息所设定的功能验证测试。不管是成功案例或者是失败的案例，其功能都必须遵照SLAs.网络接口可能要求其它类型的原则。网络应用的WCAG 2.0可以得到批准，但是必须保证那些有视觉障碍的用户也能使用这些Web服务，否则标志和内容原则将会影响到人们对Web服务的感官。

　　这些原则每一个都可以被自动实施，其发行也应该是自动的。这就可以确保原则得以实施，并且提供原则的可视性。机构中的每一个小组都要遵循这些原则。当和业务伙伴进行洽谈时也要确保他们必须遵循系统的这些原则。所有的小组必须在自己的测试活动中公布结果。当所有的组件都经过这个程序之后，可以把结果汇聚在一起，最终决定系统的健康状况。由此可见，系统的命运和所有组件的命运息息相关。