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

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

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

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

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

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