服务建模是为解决常见SOA问题而生

    读者应该也有所了解，最常用的应用程序分析技术是字节码技术。其工作原理是使用分析工具将字节码插入到各个类中。对于CPU性能分析，这些字节码通常是methodEntry()和methodExit()调用。对于内存分析，则是把字节码插入到每个(新)构造函数的后面。这些字节码插入操作是通过后编译器或自定义类加载器完成的。

    这种技术的主要缺陷是，一旦对类作了修改便无法再发生改变。这种灵活性的缺乏经常会导致在将来产生某种问题。如果你选择对整个应用进行分析，那么这种技术的开支常常会导致非常严重的性能问题。但如果使用封包或基于类的过滤器来对此做出一些限制，又有可能无法对应用的重要部分进行分析。而且，如果技术上的改变需要重新启动应用程序，还会极大地延长分析过程所花费的时间。

    我们曾经遇到的情况是，当前使用的应用管理系统只能使用字节码技术。所以我们开始研究如何选择一种更好的方式来对面向服务的应用的健康状态进行监控：剔除已知我们不需要的并定义我们所需要的环境。字节码技术其本身是一种优秀的技术，但是如果不能根据应用服务的环境进行部署那就会像是在无灯光的地方穿衣服一样。你可以穿上衣服，但是你无法看清你现在的模样。

    寻找可视性问题的解决方案有许多条件限制。我们知道我们需要什么。除了一般条件，我们还需要一个直观的管理控制台、深层处理的映射与建模、所有组件的持续性的性能参数、高级诊断与分辨能力、以及历史与趋势报告。我们是一家IBM工作室，所以我们所选择的方案必须能够运行在WebSphere及相关的中间件上。最后，这个方案还必须符合外包供应商的要求，并能够在无需开发人员或额外的专家资源参与的情况下进行快速部署。

    根据这些独特的需求，我们考虑了几种方案，并最终决定应用服务建模是能够解决我们的问题的非常好的方案。应用服务建模提供了所需的环境可视性。它能够动态地将应用提供的服务联系到支持这些服务的低层代码，从而提供了对其进行有效的管理所必须的环境可视性。最近的一份福里斯特报告指出，"基于模型的方法对于较复杂的组合应用(比如SOA应用与门户)来说是一种'必须'的方法。"

    应用服务建模可以提供更优秀的服务

    基于模型的面向服务的应用监控是用来提高环境可视性的。应用服务建模把可视性带入了面向服务的应用，可以让我们知道哪一个业务服务是由SOA设备中的哪一个应用组件支持的。一旦IT有了所需的环境可视度，我们就能够管理一个甚至更多的组件来优化服务交付。

    应用层次的建模为我们提供了各应用服务下的设备的可视性拓扑图，因此各服务所必须的依赖性也显露无遗。其原理是解析Java文件、配置文件和数据库中的元数据以检测入口点。这个过程结束之后，服务便被建模，参数确定，然后两者都在模型上表示出来。

    这个工具所生成的任何模型都会随低层组件的相关变动进行自动更新，因此不需要手工干预或为这些更新工作而费心。自动化能够让你的业务关键服务运行在更好的状态上。此外，IT组织还需要一个可靠的工具来做影响分析。比如，如果确定了一个即将进行的变化，那么IT操作必须能够对所有应用过程、应用组件、系统等可能受到变化的影响的各个方面进行验证。如果没有添补这个IT可视性空白的手段的话可能就无法取得如此显著的优势了。

    应用服务建模提供了一定程度的可视性和辅助解决未知问题的能力。比如系统在五分钟后显示了我们花了八个星期尚未得出结论的问题的根源。那是个什么问题？

    我们网站上的一个搜索功能，它可以让客户寻找并购买产品。但是这个功能出了故障--相当大的故障。我们的工作人员花了六个星期尝试确定问题的根源所在。这个任务非常复杂，因为我们的数据中心集成了太多的第三方软件。我们启动了一个新的客户端商务站点，可是直到交易量提升到一定程序后才再次发现这个问题，并且影响了我们整个网络结构。起初我们认为这是数据库的连接缓存的问题，是因为特定的应用引起的。

    使用了应用服务建模之后，我们在24小时之内便跟踪到问题不仅出现在我们开发的系统中，第三方结构和应用中也有问题。这样我们的问题便解决了。这是一件非常有意义的事，因为我们花费了许多时间和供应商争论到底谁应该负责处理这个问题。服务建模可以让我们进行调整和测试、过度调整和测试，并同时监控能发挥其非常好的性能的位置。要正确地实施SOA就需要一种准确的问题源诊断手段，在虚拟化和共享资源的环境下更是如此。

    由于应用服务建模这种方式确实非常卓越，我们已经在我们国内外所有的业务关键的商务站点上采用了这种技术。目前已经实现的优势包括更短的修复周期、更高性能的应用服务、以及在面向服务的应用上的投资的更高回报。我们发现了可以提高主站商务应用代码质量的新方法，从而为我们带来更高的稳定性和运行性能。我们有一位SOA开发人员甚至相信如果能更早地使用应用服务建模，我们就能节省好几年的部署时间了(我没有开玩笑)。但是最重要的可能还是它可以帮助我们完成最主要的任务--通过更高的价值和更优的服务赢得业务伙伴的尊重和忠诚度。

    总结

    应用服务建模可以填补当前动态组合应用中的IT可视性空白。如果没有这种环境意义的可视性，就不可能有效地诊断使用不断变化中的多层中间件的企业应用中的应用服务问题。不管一个应用有多成熟或功能有多丰富，如果无法管理，那么它对企业的价值就是非常有限的。并且，一个IT运营团队必须了解应用逻辑才能有效地进行影响分析并预防可能产生的应用问题。通过在应用服务层对复杂的组合应用进行管理，IT组织可以最大程度地发挥应用的性能、减少分析问题的平均时间、并使生产效率最大化。为了使IT与业务取得一致并让企业从对组合应用的投资中取得预期的投资回报率，进而完成这"最后一英里"的任务，使用一种更成熟的方式是非常有必要的。