随着开发人员迅速地开始采用基于组件的体系结构，应用服务器在生产中的角色就从只宿主一些简单的、基于servlet的应用程序发展为利用EJB（Enterprise JavaBean）和JMS（Java messaging services）来构建健壮的电子商务应用程序。

新的在线商业应用的繁荣激发了在绩效管理解决方案这个曾经是完全独立的行业的技术革新。在过去的12到18个月里，开发和IT操作，这两个曾经完全不相关的领域，不得不利用新的监控和管理产品来协同工作，这一新产品可以把绩效问题向下追查到一个独立的Java方法上。这些面向产品的管理生产正是汲取了诸如管理API、工具和Java分析等技术的优势，并且与诸如服务器端代理这些比较传统的管理体系相结合。尽管这些工具提供足够的粒度，但对于越来越复杂的N层基础结构的管理依然是以一种各异的、烟囱式的方式来应用，许多部门在不同层上都有操作责任。一旦绩效问题发生，这种机制只会导致各个部门之间相互指责和推卸责任。

除应用服务器管理以外

       在不到两年的时间里，一个相对来说比较新的市场微生态环境（J2EE应用服务器的性能管理）由于受到许多供应商的关注而日渐成熟。每种解决方案都有不同之处，但是本质上都识别相同的数据，那就是各种应用服务器及其组件的数百种统计数据。对于管理软件供应商来说，现在抓住这个机会，开始下一步并提供实际应用程序拓扑的视图和管理。这一远见将会扩展到应用服务之外，将完整业务流程基础结构的管理定位在事务依赖性的监控和可用于执行事务的路径上。
       新的管理解决方案引领着从传统系统管理向AMR研究院所说的商业服务管理的前进趋势。“许多不同技术组合在一起来提供一个商业服务，包括web服务器、应用服务器和数据库服务器。在它所支持的商业过程环境中监控和管理所有的这些技术正是商业服务管理的基石”。

       尽管以前的工具所提供的只是针对不同层的海量数据，经常导致大量信息的产生，也就是所谓的“数据充斥”，IT还致力于在这个复杂体系结构中获得每一事务通过每条潜在路径的全景。与此同时，商业所有者们正在寻找IT伙伴来管理交易生态系统的细节，从而有助于评估他们在线项目的成功与失败。
       进一步来说，随着越来越多的公司为了最大化他们的应用服务器基础结构的作用，不断启动新的在线项目，但IT业缺乏对许多交易执行所依赖的独立或分布式应用程序的深入了解。追踪实时交易关联性的需要依然存在，这就需要弄明白每个组件所需执行的任务以及是怎样执行的。

市场调查公司Hurwitz Group强调了这个正在不断增长的管理需求。“Hurwitz Group相信应用管理者将不得不借助一些网络管理的概念（比如拓扑图和路由追踪）来解决这个问题。我们正在寻找一种解决方案，这种方案能够产生一种软件拓扑：一张可以组成交易的群集化生产环境中不同软件组件的图。这个解决方案也应该能够追踪某笔交易在这个软件拓扑图里所通过的特定路径。只有这样管理者才能将单独的交易与所使用的具体组件相匹配，这样，不确定性消失了，我们也就可以诊断问题了”。

映射应用逻辑

如今，人们采用了很多新的技术来监控实时J2EE应用逻辑。Web应用管理解决方案中的下一步就是映射单独的商业过程，或者说是“交易路径映射”。将基于组件的性能数据与系统、数据库、应用程序和商业相关标准联系起来，使IT操作对一个电子商务系统的真实绩效进行度量，并且将其用商业相关信息表达出来。应用逻辑的这个前景最终将带来管理功能与组织的商业和在线收入目标更好关联起来。

虽然负载均衡、防火墙以及群集化对于web应用程序的可伸缩性和性能来说是很关键的因素，但这些措施也使情况变得更加复杂，对IT造成新的阻碍。Transaction Path Mapping识别执行应用程序所需要的组件，并且创造一个交易可能采取的潜在路径的拓扑图。在这之前每个元素或者层是以其本身的“烟囱式”视图来被监控的，而这个跨功能的应用使它们互相合作，这样就使得IT能够一直深究引起交易失败的问题的根本原因。

通过将各个不同的被监控数据点联系起来，可以展示出整个交易路径的总体健康情况。这样就使得交易可以沿着一条更为健康的路径进行，从而保持了或是增长了交易成功率。另外，交易图有助于将在基础结构中交易失败的地点隔离开来。更重要的是，这一监控级别使得IT操作可以与开发和在线商业管理者更好地沟通，了解他们需求的细节。

新概念，不同的方法

与许多组件监控解决方案类似，供应商正在开发交易映射的各种方法。其中一个比较流行的方法是先进行人工映射，从而勾画出一个应用程序图表的大致情况。一般来说，这种方法利用了开发者应用程序体系结构的优势，需要IT人员来选择每个交易的关联性。这种方法只是整个基础结构的表示。它不能监控实时应用程序逻辑，并且当增加或减少组件时，必须不断地对关联图进行维护。另一种方式需要通过C或者C++开发来将映射实际硬编码模型，其缺点是牺牲了灵活性，并且需要使用一些通常是IT之外的资源。虽然这种方法可以对最初人们所倾向的体系结构进行准确的描绘，但接下来需要对不断变化的基于组件的应用程序的映射进行更新，这个代价可能是很昂贵的。

另一个可以识别交易路径的方法是使用交易标签。这种方法包括标志一个交易的监控解决方案，并且对这笔交易在整个基础结构中所有层所通过的实际路径进行跟踪。这种方法非常适合于再生产环境，提供了很详细的组件信息，直到单个SQL语句和方法调用为止，但是需要大量的JVM和字节编码工具。再加上应用到每笔交易所增加的标志，这种方式可能在生产环境下对性能产生巨大的反作用。

对于交易映射最有效的方式很可能是组合每个系统的监控代理，以及监控整个Web栈（Web服务器、应用服务器和数据库）的能力和某种形式的工具（由IT控制）或用于组件级别统计信息的API通信。通过利用带有实时数据的“自底向上”的方法，IT不仅能对每条交易路径都建立实时视图，而且可以是动态变化的视图，这样就能确保整个基础结构的准确表示。无需任何开发时间或者资源，对拓扑图的任何变化都可以跟踪。

从表示层的交易入口点开始，这个入口点通常是一个servlet或者ASP支持的Web页面，IT能够自动发现每个servlet、EJB或是 COM＋对象。EJB交易方式、JDBC连接或是其他组成商业逻辑的资源池。然后该信息可用于动态映射每一路径的实时流，并以一种门户风格的视图来可视化地表示出来。

这种方法提供了最大化的可视性和相关数据的细节，同时避免了生产系统中的昂贵开销。它也满足了支持快速变化Web体系结构灵活性的需要，即可能经常性地增加、删除或者修改产品端的应用程序和组件。更重要的是，这种方法允许映射解决方案为基于预定的阈值自动调用不同的操作。对于解决较差性能或者甚至是服务质量操作，赋予具有特定交易特征的资源优先权（比如，一个优先的顾客或是大的交易值），这些将会是很好的措施。

在解决Web应用程序性能问题上，IT操作和开发不得不相互合作，能够解决两者共同需要的产品更容易受到欢迎。因为这些解决方案能以一种IT所熟悉的方式来展示出更详细的性能信息，在较为简单的问题上牵涉到的开发需要就大大减少。这一结果对于操作和开发来说都能很大地提高生产率。

随着电子商务应用程序成为提供在线商业服务的基础，度量、监控和主动管理服务的各个方面的能力显得越发重要。实际上，可靠交易管理技术的引入很可能推动新的在线计划的应用。这种Web应用程序性能管理的新方法对未来的管理技术革新铺垫了舞台，进展仍在不断推进。

参考资料

Gaughan, Dennis (March 11, 2002). "Business Services Management: Managing an ECM Infrastructure."
Hurwitz TrendWatch, March 15, 2002. Web Application's Uncertainty Principle.