怎样从策略上保证SOA满足业务需求

申请免费试用、咨询电话：400-8352-114

在过去超过三年的时间里我们一直在谈论如何找到一个确实可行的SOA治理方法，但是令人惊讶的是，即便到现在为止无论何种级别的IT行业，也仅仅只有很少一部分得到了相对于自身企业而言的微小成果。我们正在实践中的SOA治理却与我们期望的价值有着巨大的差距，为什么?

或许我们可以这样理解，大部分的厂商实际上并没有充分认识到SOA服务注册在整个SOA策略性发展中的价值，他们只看到了SOA所能带来的另外一些价值并疯狂的利用着。他们更关心如何将其已有技术和新的技术资源有效整合起来。之所以会忽视治理是因为他们发现，尽管可以把所有的服务描述和地址都放在一个统一的地方，但是对于已经知道并了解这些相关服务从而计划使用这些服务的开发人员来说，这样做并不会带来任何可能增加的ROI。

我们可以看到，很多的人都对SOA治理的理念非常感兴趣，也在很大程度上遵从这一系列的规范，但是对于现实的业务实践而言，并不是所有的这些理念规范都会在应用中带来实际的效果。出现这种情况的原因是在于，未经验证的SOA治理在真正遇到业务需求的时候并不能够有任何策略上的保证去满足这些需求。从本质上说，这类SOA治理仅仅只是类似于制定了一个限速的上限，但却并没有具体的措施去确保遵守这条限速的规则。

仔细想想业务与执行之间的隔阂吧，什么是业务想要去做的，而技术方面又都是如何去实现的。你如果从实际执行角度去想的越远，那验证也将愈加困难。

正如我们都能想像到的，当你所提取的抽象层越多，把这些层放在一起的时候其相似点就会越少，让其共同工作也会越困难，同时其他层对你现在所作的测试影响也会越大。

如果要在更深层次去考虑SOA治理问题你会发现这必定会是一个长远的过程。你可能对于你想做的一些治理有一个很好的想法，但是在某种意义上并不是所有的团队都会这样去做。在当前的经济环境下这也会变得更加困难，尤其是你也得考虑到你的合作伙伴，你的收购或是外包的工程，正是如此，你所依赖的开发团队也是你很难对其日常工作进行控制的团队。

当你把所有的服务都放在一个UDDI服务注册的时候，用一个已验证过的策略去连接这个服务注册，在当前环境下而言将会有着非常明显的好处。但是，要让它真正发挥效用，还需要继续发展才行。如下则是一些可供参考的不同的持续性验证条例：

1. 在建立初期进行持续性检查。当你在对一个新的服务进行检查的时候，就已经是相当于一个在其成为可用资源之前自动的验证过程。

2. 制定时间表，并按时进行持续性检查：我们通常称其为“安全带”方法，这种方法可以确保当你在不知道服务已经发生改变或是项目执行遇到问题的时候，应用还能按最初描述的方式进行工作。

3. 利用UDDI让你的BPM，整合工具以及相关的测试充分发挥效应，找到合适的服务为工作流提供验证。在使用了UDDI v3规范之后，你的接口能够很好的被识别，同时也能够更好的和其他工具进行整合。

4. 重视报告并充分提取其价值：弄清楚哪项服务是常用的，并能够逐渐成为SOA架构体系中的关键构件。企业总是在寻求最精简的方式去实现大的功能，这一点可以明确的帮助SOA团队准确的学习到应该如何完成重点测试，架构体系规划以及未来可能遇到的整合。

所有上述针对如何验证SOA治理的例子对于其进一步完善有着非常大的影响。通过完成对每一项服务的验证能够让我们在一个可变的时期内尽可能的跟上发展的进度，但是，我们仍需对这些服务进行结构、行为和运行期间的安全性检查，并做出合适的报告，以确保最大限度的提高效率。因为之前的一些验证往往只是依照WS-*协议规范检查其结构是否正确。

举一些关于Web服务的例子。如果你打开一个服务注册中心并对其中的服务按照WS-I协议或者是其他的类似WS-Security协议进行遵从性筛选的时候，你会发现只有不足1%的服务可以完全的达到兼容。这其中的原因在于无论是何种工具或流程，在生成服务的时候往往都会做一些自定义的调整以构建起更能够与自身平台实现强有力兼容的WSDL和SOAP消息。更不用说在这之下还有其自身的数据库和已有的应用系统需要考虑去兼容。

在这块竞争不断的领域内，每天我们都能看到许许多多并不符合标准的决定。所以我们必须得在头脑中有一个根本的想法，那就是“遵从性”测试是实现SOA治理可验证的唯一方向。我们需要对现有的异构SOA世界做一个充分的测试和验证，从这些SOA服务注册中心中获取令人信服的价值出来，这样才能让CXO们真正清醒过来并引起重视。

举例来说，我当前正在主营电信业务的公司，该公司使用的是具有优秀特征的Systinet公司产品。他们将服务都集中放在那里，但是当他们需要什么的时候却并不依赖这个服务注册中心，因为这些服务在变化的时期内，甚至是运行中是并不能完全的符合验证的。

这其中最明显的例子就是一个在遵从性检查中返回为“真实”的服务在确切的工作中时却并没有按预料中的那样去执行。单独依靠Web服务响应(该响应返回为“真实”且没有SOAP失败，我们且假定它是合格的。)可能会导致最终的真实结果只是假性的。我们可以执行一些更深入的验证工作从而确定这些“真实”响应确实来自能达到演练效果的真实系统或处理交易层所做出的报告。同样的方法也适用于CentraSite ，BEA公司的ALER或者是用以管理这些服务的其他服务注册中心或服务存储中心。

可验证性同样适用于非SOA的基础架构?

在服务注册中心之外，大部分的企业实际上并没有遵从WS-I协议即将很多工具连接到了一起，并且能够得到非常有效的应用。这不是一个新的概念——自CORBA出现以后这就已经存在了。而这仍然是当前大部分的整合情况。那现在我们则需要对此类服务整合进行自动化的验证，在完成之后将其中可服务组件化的技术以系统记录的形式融合进SOA治理平台中。

总而言之，如果你已经有了一个SOA的服务注册中心，但是你对其感到失望发现并没有从中获得任何有意义的结果，千万不要放弃——这其中是可以提取出非常大的ROI。开始下一步的行动，不仅仅只是一些遵从性测试，而是实际验证这些服务是否满足于你的SOA策略。（IT专家网）