为真实用户确保实时监测和事务处理追踪能力可以避免SOA一步一步走向死亡之路，IT部门需要在其SOA性能管理工具中拥有如下的三个整合基础功能：
有效监测：“没有度量标准就没有管理”。SOA管理的第一步是要找到一个界定SOA应用程序是否满足服务水平要求的定量的方法。换句话说，“正确的应用反应(数据、页面、行动等等)是否在合适的时间内传输给了正确的用户?”有许多质量保证技术来确保正确的应用程序反应的交付。而且，多数组织都具有必要的安全措施来确保信心传送到正确的人手上。但是，确保信息在正确的时间内通过复杂的基于网络的SOA基础架构传达给终端用户却又是另外一回事了。具有能力对真实用户体验应用性能进行非干扰性的监测是绝对必要的，原因有二：.一是因为这是唯一办法来准确监测SOA应用程序服务水平保障和报表真实用户感受到的问题;二是因为它创造了进行流程改进和提高应用程序反应时间的关键推动力。.这种监测手段始于终端用户浏览器，也就是所有的应用程序真正组合到一起的地方。只有在浏览器上，IT才可能考虑“最后一里”的情况并识别是否有会影响到客户满意度的事情发生。由遗产工具搜集而来的数据主要侧重于监测特定的技术局限范围――如网络路由器、Apache网络服务器、WebSphere应用服务器或者是NET框架――都不能用于推断识别SOA复杂应用程序的真实最终用户在浏览器中的体验。
隔离分析：一旦了解了最终用户在应用程序性能方面的体验，它就应该与SOA相关反应交付中涉及到的所有的基础架构和应用组件性能资料联系起来。因为复合应用程序是由像“黑匣子”一样的服务构成的，它们的性能是不能够被这些组合程序的工具所控制和调节，对于这些运行在真实或虚拟基础架构组件之上的应用是不可能完全的被IT运作所掌控，他们可能有来自不同数据中心的事务交易或是由第三方服务方所提供服务端，最重要的一点这些不管是整体基础架构也好，第三方数据中心也好，还是不同的应用组件也好需要紧密的相互关联起来并对其性能做出准确的报告。性能的相关性可以通过对日志文件的细致分析或是通过各阶段IP匹配与请求发起的时间等做出判断，但是即便在所有的日志文件都可得的情况下这种方法依然会是非常困难并且会有难以避免的错误出现，而且一旦出现事务交易涉及到了外部的数据中心那日志文件将很难记录下来从而在分析时造成错误。另一种简单的机制则是标记出每一个事务交易是由哪一个终端用户所发起，并在整个基础架构中采用非干扰性的动态追踪，在每一阶段记录下适当的性能数据。这种端到端的性能观测需要基于用户的使用经验所能提供的对于整体状况的鸟瞰视角，从而对细微的事件、错误或性能瓶颈所对最终用户在响应时间上的影响做出判断。
优化：全面的浏览器到数据库的事务交易性能视角可以确保提供可靠的信息从而使得特别的或是反复试验所得的方法将不再需要用来对性能问题做出鉴别和响应。如果缺少可靠的信息那么IT部门的事件响应团队可能需要花费更多的时间去辩论，努力找出问题所出现的原因，在很大程度上他们会更多试图重建这次问题而不是马上着手于解决这个问题从而恢复整体的业务功能。通过长期对这些相互关联的事务交易性能的信息进行分析，IT部门可以准确的判断出性能影响中最关键的主要冲突所在并能在下一次问题对用户满意度或业务生产力造成影响之前将其解决。此外，这些信息也能更好对基础架构、服务以及应用程序性能的改善带来着实有效的帮助。
将以上三种功能集成到一个单一的SOA性能管理工具里可以为IT部门提供一个前期响应系统用以监测并在最终用户端性能问题引发大范围冲击造成巨大损失之前迅速做出响应。业务冲击或性能瓶颈的相关信息应第一时间及时反馈到运作人员用以完成对基础设施或流程的改进，同时为开发人员优化程序应用。
毋庸置疑，SOA的出现可以大大提升业务灵活性，降低应用程序开发成本。但是，如果没有一个真正的面向用户的方式用以管理SOA部署实施以及一个系统化的生产管理，那SOA应用的前途真的有可能踏上不归的死亡之路。
本文整理： 爱ERP网 http://www.loveerp.com/
相关阅读：
调查结果显示 SOA在整个IT行业内广泛…
双面SOA架构炼狱“三重门” 透过黑洞…
SOA是成长型ERP的救星吗?
何时采用SOA 何时不采用SOA…
企业管理信息化是很简单的事情
SOA倍受软件巨头关注 但缺乏中小企业…
IBM SOA Sandbox…
透过SAP与ORACLE看SOA
SOA中间件展望：前景广阔 现实问题重…
SOA框架的不足
最新推荐：
| 发 表 评 论 |
新闻排行
资讯
热点
产品
签约
