建立在面向服务架构(SOA)上的Web应用程序将极大的提高IT效率和业务灵敏度。SOA 建立起了数据和协议方面的统一标准，以使得现有的内部和第三方应用程序模块或服务能够有效的重复利用，并可以进一步重新组合进业务应用程序。但不幸的是，在SOA迅速促进业务应用程序实施的同时，这些应用于生产的程序也大大增加了其性能管理的复杂性――这在很大程度上降低SOA应用所能实现的优势。如果没有有效的方法来监控应用程序的性能、迅速找出症结所在并加以解决，那么SOA应用就很有可能成为死亡之路(dead on arrival ，DOA)。

　　在实施SOA有几个方面的原因导致IT很难管理应用程序的性能：

　　造成低效的共同要素：一个SOA应用程序所提供的服务，其水平受到网络中该SOA应用程序所需性能的服务水平限制。为了达到最大限度的灵活性，服务甚至可以由第三方供应商提供，并有可能在不同的计算平台上运行。这使得IT从实际操作上不可能界定出服务构件的性能特点，更不可能完全控制那些影响程序交付和执行的众多机动部分。服务的重新利用还意味着通用服务中所存在的性能缺陷也在程序应用中被复制过来，产生了无法预计的故障。这样以来，就很难从数量上确定服务水平是否超过终端客户的期望或至少达到服务水平协议(SLA)中规定的性能目标。

　　联动实验效果：对于一个通过Web发布的SOA应用程序来说，要确认其服务的发起和交付时存在哪些问题同样是非常困难的。问题根源可能存在于交付机制中任何一个“机动部分”，比如客户的个人电脑、网络、数据中心、服务组件和/或第三方服务提供商的服务或基础架构。在这样一个复杂的环境中，没有一张“嫌疑列表”足够巨细无遗列出所有的可能性。

　　繁杂的网络环境：在处理这些通过Web发布的应用程序或基础架构时缺少一种可预见性或事先确定的步骤去实现操作，也进一步使得诊断SOA应用性能问题的任务变得更加复杂。在客户端或服务器端的计算环境中，一个目录查询是经由定义的网络分段，并由安装在固定服务器上的ERP应用程序加以支持; 而在SOA环境中的目录查询可能经由网络动态的进行，并且由多个虚拟或实际服务器所在基础架构的多层逻辑中加以支持。第三方Web服务需求也能传输给提供商的基础架构从而从提供商自身开始说明详细目录。这种复杂的组合需要涉及非确定性的操作路径，这使得改造或诊断整体应用性能的问题变得十分困难。

　　为了应对如上的这些挑战，使得SOA应用不至走上死亡之路(DOA)，IT需要两种能力为其所用。首先，IT必须能够像真正的用户那样监控应用程序的性能，因为这是唯一能感受到所有服务组件的环节要素所在。除此以外，如果发现服务水平受到影响，他们必须能够迅速的追踪不利操作，查明引起性能下降的问题根源所在。如果能系统的利用这些能力，IT就能够：

　　· 通过发现性能瓶颈与缩短问题解决时间来提高服务水平。

　　· 排除不必要的评估会议和毫无成果的改造尝试，降低操作管理的成本和失误几率。

　　那么现存的终端用户在实现其应用程序满足IT需求的同时应该如何监控其技术交付从而避免应用程序走上死亡之路(DOA)呢?让我们看看对于监控技术在应用于SOA性能管理的调查情况：

　　· 嗅探器或是其他的包捕获程序即可很容易的评估出在传输规则下包响应的来回时间，但是对于那些传输路径并未通过在网络中安装了这些程序的关键点的交易则无法判断出准确的响应时间。拿Mashups应用做一个例子：关键的数据项目由第三方应用程序提供，旁路的嗅探器会安装在网络服务器前端。在数据中心，基于SOA应用的基础上嗅探器依旧会遗漏掉Web服务而是更多的监测到来自服务器端或是第三方的服务。

　　· 服务器监测工具只能针对其所监测的局限范围做出事务处理时间响应的报告。举例而言，流行的J2EE应用程序服务器端监测工作只能对安装了这个应用程序服务器的范围内做出事务处理响应时间的判断。直接由Web或是第三方服务所提供的事务处理服务没有涉及到应用程序层面则无法被J2EE监测工具直接管理。

　　· 传统的网站性能监测服务可以准确的监测到SOA应用程序是否可行。但是它并不能就性能做出一个有经验可参考的报告提供给真正的使用者，或是给出一份针对问题的精细记录信息从而完成纠正性的完善。

　　· 纯粹的SOA管理产品可以帮助IT部门从相互依赖的各种服务中建立起有效模型，从而提供有限的事务处理方式的信息，但是这样的产品往往会忽视整体基础架构的良性发展。最关键的是它无法对最终的性能表现做出预判并给予最终用户以经验指导。

　　在提供“真实”可行的信息以管理SOA的性能方面，这些遗产工具不仅在所收集的性能数据类型上不够完善，在收集数据的来源方面也存在缺陷。至关重要的是要界定应用程序性能在被终端用户感应到的反应时间，而不是服务器、网络J2EE、数据库或其他局限范围内的度量。毫无疑问的是，终端用户体验是唯一重要的事情。此外，在mashup应用程序中，网页是由多个服务器或第三方数据中心来支持的，当应用程序通过内容传输工具执行的时候，程序在内容都已经到达浏览器的时候也许都还没有组合起来。结果，唯一衡量SOA应用性能好坏的有效方法就是直接从真实用户的浏览器来测量。

为真实用户确保实时监测和事务处理追踪能力可以避免SOA一步一步走向死亡之路，IT部门需要在其SOA性能管理工具中拥有如下的三个整合基础功能：

　　有效监测：“没有度量标准就没有管理”。SOA管理的第一步是要找到一个界定SOA应用程序是否满足服务水平要求的定量的方法。换句话说，“正确的应用反应(数据、页面、行动等等)是否在合适的时间内传输给了正确的用户?”有许多质量保证技术来确保正确的应用程序反应的交付。而且，多数组织都具有必要的安全措施来确保信心传送到正确的人手上。但是，确保信息在正确的时间内通过复杂的基于网络的SOA基础架构传达给终端用户却又是另外一回事了。具有能力对真实用户体验应用性能进行非干扰性的监测是绝对必要的，原因有二：一是因为这是唯一办法来准确监测SOA应用程序服务水平保障和报表真实用户感受到的问题; 二是因为它创造了进行流程改进和提高应用程序反应时间的关键推动力。这种监测手段始于终端用户浏览器，也就是所有的应用程序真正组合到一起的地方。只有在浏览器上，IT才可能考虑“最后一里”的情况并识别是否有会影响到客户满意度的事情发生。由遗产工具搜集而来的数据主要侧重于监测特定的技术局限范围――如网络路由器、Apache网络服务器、WebSphere应用服务器或者是NET框架――都不能用于推断识别SOA复杂应用程序的真实最终用户在浏览器中的体验。

　　隔离分析：一旦了解了最终用户在应用程序性能方面的体验，它就应该与SOA相关反应交付中涉及到的所有的基础架构和应用组件性能资料联系起来。因为复合应用程序是由像“黑匣子”一样的服务构成的，它们的性能是不能够被这些组合程序的工具所控制和调节，对于这些运行在真实或虚拟基础架构组件之上的应用是不可能完全的被IT运作所掌控，他们可能有来自不同数据中心的事务交易或是由第三方服务方所提供服务端，最重要的一点这些不管是整体基础架构也好，第三方数据中心也好，还是不同的应用组件也好需要紧密的相互关联起来并对其性能做出准确的报告。性能的相关性可以通过对日志文件的细致分析或是通过各阶段IP匹配与请求发起的时间等做出判断，但是即便在所有的日志文件都可得的情况下这种方法依然会是非常困难并且会有难以避免的错误出现，而且一旦出现事务交易涉及到了外部的数据中心那日志文件将很难记录下来从而在分析时造成错误。另一种简单的机制则是标记出每一个事务交易是由哪一个终端用户所发起，并在整个基础架构中采用非干扰性的动态追踪，在每一阶段记录下适当的性能数据。这种端到端的性能观测需要基于用户的使用经验所能提供的对于整体状况的鸟瞰视角，从而对细微的事件、错误或性能瓶颈所对最终用户在响应时间上的影响做出判断。

　　优化：全面的浏览器到数据库的事务交易性能视角可以确保提供可靠的信息从而使得特别的或是反复试验所得的方法将不再需要用来对性能问题做出鉴别和响应。如果缺少可靠的信息那么IT部门的事件响应团队可能需要花费更多的时间去辩论，努力找出问题所出现的原因，在很大程度上他们会更多试图重建这次问题而不是马上着手于解决这个问题从而恢复整体的业务功能。通过长期对这些相互关联的事务交易性能的信息进行分析，IT部门可以准确的判断出性能影响中最关键的主要冲突所在并能在下一次问题对用户满意度或业务生产力造成影响之前将其解决。此外，这些信息也能更好对基础架构、服务以及应用程序性能的改善带来着实有效的帮助。

　　将以上三种功能集成到一个单一的SOA性能管理工具里可以为IT部门提供一个前期响应系统用以监测并在最终用户端性能问题引发大范围冲击造成巨大损失之前迅速做出响应。业务冲击或性能瓶颈的相关信息应第一时间及时反馈到运作人员用以完成对基础设施或流程的改进，同时为开发人员优化程序应用。

　　毋庸置疑，SOA的出现可以大大提升业务灵活性，降低应用程序开发成本。但是，如果没有一个真正的面向用户的方式用以管理SOA部署实施以及一个系统化的生产管理，那SOA应用的前途真的有可能踏上不归的死亡之路。 
(来自www.csdn.net)