SOA灵活性 Vs.SOA质量：孰轻孰重？

在为美国国防部编写的一部ZapThink设计教材中，我们探讨了面向服务架构的质量，我曾指出随着SOA技术实施日益成熟，质量管理在整个服务生命周期就显得尤为重要了。SOA的灵活性要求质量保证减少对部署前的测试活动的关注。一些学生指出国防部要求必须经过九个月的验证测试才能部署新的软件。当然这两个观点并不一致。现在的问题是哪一方应该首先妥协：是国防部还是实施SOA技术的其它机构，是为了保证质量而放弃SOA的灵活性，还是为了灵活性而放弃质量。

尽其所能SOA质量

答案是两者都不能放弃，这些机构不能为了保证质量放弃灵活性，他们需要重新考虑的是在SOA这个大环境下质量的意义如何。正如 ZapThink 之前所讨论的，我们在解释灵活性以及SOA灵活性模型的元要求时，灵活性要求将如何保证质量复杂化了，因为功能测试和性能测试不足以确保SOA实施能够满足业务灵活性要求。事实上，业务并不是简单地要求技术小组利用A功能或者B功能、C功能去创建某种事物，而是要求他们建造的事物能够灵活地满足日后的要求——尽管这些要求还没有被发现。

为了支持灵活性要求，传统的部署验证测试就显得不切实际了，因为验证测试影响了业务所需的灵活性。相反，质量则是一个进行中的过程，需要人们持续的关注和警戒。但是只要业务理解实施SOA这样灵活架构的内在含义，质量本身就不会受到影响了。

与此相似的是，电信界出现的SOA质量要求转移到了移动电话网。在早期简单电话服务年代，运输公司必须提交同名承运人的服务质量，递交众所周知的五个九 (99.999%)可行性。但是，到目前为止新手机网络无法完全递交承运人的可行性级别，我们还是会经历掉线，死区这样的事件。那么这是否意味着移动电话的质量不如单老式电话服务呢？回答是否定的，只要你在新环境中定义了质量即电信界所说的“尽其所能”。毕竟网络的组件——移动塔和手机等等——完全都经过测试。整个网络交付电话公司所需的质量。只要基础设施尽其所能完成并维护用户的电话，我们就知足了。

SOA质量也是一样，如果我们在质量等式中排除了灵活性要求，我们对这个结果是不会感到满意的。但是如果我们在寻求质量的过程中考虑了灵活性这个因素，结果会令双方更为满意。但是我们还会在质量和灵活性之间进行权衡，这种权衡取决于两个以上的变量。实际上，我们还需要了解更多的内容。

要把握如何权衡灵活性/质量，我们先要回顾一下软件开发的历史（比如说，十多年前），并完全去除脆弱的软件开发结构。任何SD项目都有三个主要变量：成本，时间和规模。其中的两个变量很容易锁定，而第三个变量则随着这两个变量的变化而变化。例如，如果你决定了成本和项目时间，你也许会交付项目的要求，也许不会之类等等。

要用这三个变量限定其它相关的变量，就需要一定得质量。换句话说，如果软件开发商想锁定所有的成本，时间以及规模，剩下的就是布置后的质量问题了，我要说的是，SD三角结构实际上是方形的，质量就是其第四个顶点。

SOA项目四者之间的关系就不尽相同了：他们在等式中有添加了灵活性，这样就变成了五边形，正如下图所示，下边较低的三个点构成了传统的SD三角结构：

现在我们假定的情况是这个SOA质量五边形向人们展示了五种方式的对称，你可以通过其中的一个变量来锁定其它四个变量，但是如果仔细观察的话，你会发现情况并非如此简单，实际上在这个五边形之上还嵌入了一个三角形结构，这个三角形向我们展示了SOA质量的一些基本原则。这个三角形将灵活性，质量以及时间三个要素联系在一起，这就是我们所说的尽其所能SOA三角，因为其它展示了我们在上文中提到的美国国防部当前所面临的问题：SOA实施越灵活，就需要更多的时间保证质量。如果保证质量如此耗费时间，实施的灵活性也会受到威胁。

将SD三角形和尽其所能SOA三角形一起放入SOA质量五边形当中，不能使我们得出这个结论，即通过改变第五个顶点而决定其它四个顶点。因为时间限定了我们能够实现的最大灵活性。结果是，我们无法确定的两个顶点是那两个不在尽其所能三角上的顶点，即规模和成本。换句话说，如果我们在依据尽其所能三角的基础上可以确定所需的灵活性，质量，和SOA项目所需的时间，我们就可以通过调整规模确定成本或者，通过成本确定项目规模。

结论很明显：要想在业务所需的灵活性和质量之间保持平衡，就要在SOA措施中采用迭代方法，每一种迭代都是由规模和成本所决定的。因此，SOA项目和传统的SD项目的不同之处在于，包含时间的迭代（即时间顶点已被确定）是不切实际的，因为时间的封装并没有被当作灵活性对产生质量影响的一个要素，相反，尽其所能SOA结构的一大特点就是时间顶点取决于灵活性/质量之间的平衡。

ZapThink采取的措施

也许这里所学到的最重要的课程和以上得出的结论不同：“宇宙大爆炸 ”如果SOA项目以非迭代的形式实施抛弃了全局性，企业范围内的SOA方法，就可能牺牲灵活性/质量之间的平衡。因为相应测试所需的时间就会对灵活性有所消减。只有当灵活性不是要求以后，这个大爆炸项目才会在理论上具有可行性——但是是不是所有的SOA措施都有一定的灵活性要求呢？否则，你怎么会最先考虑SOA呢？

你也许要说一个表面上一个没有灵活性要求的SOA项目实际上是一个集成项目，因为这里不需要松耦合服务。不幸的是，我们总能看到这样的项目：一些机构认为它们可能因为一个原因或者其它原因实施SOA，而不是考虑首先购买 ESB或者其它集成中间件或者交付成为大型大爆炸集成项目。这种混乱就会导致业务风险承担者因为缺少灵活性而绞尽脑汁，并担心自己可能没有从中获取到期望的业务价值。因此在SOA中采取迭代措施可能是避免这种不良后果的最佳办法。

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。