WebLogic Real Time_在线百科全书查询
WebLogic Real Time
BEA WebLogic Real Time (WLRT)服务器提供了一种基于Java的基础架构来满足实时处理需求。这在Java领域中是比较少见的：按照实时需求处理请求，而不是只要求J2EE服务器可运行且可靠即可。使新特性成为可能的关键组件是JRockit Java Virtual Machine (JVM)。
简介
WebLogic Real Time server (WLRT)为事件驱动的应用提供了一个低延迟的轻量级基础架构。它旨在用于竞争性较高的环境中，在这种环境中，性能非常关键，每一毫秒都很重要。例如，特定的行业（比如电信或保险业）要求事务在给定的时间帧中以极低的延迟执行。然而，如果尝试用标准的Java来实现，则很可能会因为由垃圾收集过程所产生的无法预测的暂停时间而失败。这就是WLRT的用武之地了。它结合了JRockit JVM，后者引入了一种确定性垃圾收集机制，提供了一个用于执行这些关键型应用的J2EE运行时。确定性垃圾收集确保程序执行期间的暂停时间非常短，而且挂起的请求会在定义的时间帧中得到处理——从而允许购建高性能和确定性的应用程序。
产品组合
要了解该新产品，我们需要详细看一下整个产品组合。WLRT是一个依赖于JRockit JVM中的新特性的WebLogic Server，它使用集成的BEA Spring Framework支持轻量级编程：
BEA WebLogic Server 9.1是实时应用程序的J2EE服务提供程序。
BEA JRockit 5.0 R26为确定性垃圾收集提供了基础。
BEA Spring Framework 1.2.6是轻量级的编程模型。
BEA WebLogic Server 9.1 SP4
WebLogic Server 9.1是BEA有着良好口碑的著名企业Java应用服务器的最新版本。除了完全实现了J2EE 1.4规范外，它还提供了一组标准的API，用于创建可以访问各种服务（比如数据库、消息传递服务以及其它与外部企业系统的连接）的分布式Java应用程序。借助于WebLogic Server，企业可以在一个健壮、安全、高度可用且可伸缩的环境中部署任务关键型的应用程序。所有这些都可以使用一组集群化、管理和监控特性在给定的基础架构中实现。作为WLRT的一部分，WebLogic Server是事件驱动的低延迟应用程序的服务提供程序。
JRockit
垃圾收集对Java性能有着很大的影响。在full垃圾收集期间，Java进程会完全停止。当垃圾收集完成后，进程才会继续。从堆中清理废弃对象以及为新对象释放空间的过程需要进行高度优化，以便确保有效的内存管理。
JRockit可以使用一种动态的“确定性”垃圾收集优先级(-Xgcprio:deterministic)。该策略被优化以确保暂停时间非常短，并限制定义良好的时间帧（也称为“滑动窗口”（sliding window））中的这些暂停的总次数。这对特定的应用程序来说很有用，尤其是对事务延迟有严格要求的应用程序。然而，即使较短的确定性暂停时间也不一定能保证较高的应用程序吞吐量。确定性垃圾收集的目标是降低在执行垃圾收集时运行的应用程序的延迟。与常规垃圾收集相比，确定性垃圾收集产生的暂停时间会短得多。通过在JRockit 5.0 R26中引入确定性垃圾收集优先级，可以保证以下的事务延迟：
在99%的情况下，在任何50ms的滑动窗口中，每周由垃圾收集引起的总暂停时间不超过30m。
在任何130ms的滑动窗口中，由垃圾收集引起的总暂停时间不超过100ms。
对于具有1 GB堆以及在收集时平均30%或更少的活动数据的应用程序，这些目标很容易实现。WLRT文档声明，这已经在以下硬件上得到了验证：
2 x Intel Xeon 3.6 GHz，2 MB level 2缓存，4 GB RAM
4 x Intel Xeon 2.0 GHz，0.5 MB level 2缓存，8 GB RAM
在具有不同堆大小且/或者有更多活动数据的更慢的硬件上运行可能会破坏这一确定性行为。在这种情况下，可能需要使用-XpauseTarget选项增加暂停时间目标。确定性垃圾收集只作为WLRT的一部分可用。如果没有相应的许可文件而试图启用该功能，则会在服务器控制台上出现警告。
WebLogic Spring Framework
WLRT的最后一部分是用于BEA WebLogic Real Time的Spring Framework 1.2.6。作为一个轻量级的应用程序开发框架，它的开发工作比起传统的J2EE开发有了极大的简化。实践证明，它非常灵活、易用，并且能够运行在具有高度的延迟敏感性的环境中。通过将Plain Old Java Object (POJO)用作EJB的替代方案，Spring Framework仍然能够访问WebLogic Server的所有可靠性特性。此外，它实施了模块化和可重用的编码实践。它还包括基于JavaBean的配置、一个AOP框架、声明式事务管理、JDBC支持和一个web MVC框架。它在WebLogic Server上得到了认证（从9.0版本开始）。可以从WebLogic Real Time产品下载页面下载受BEA支持的Spring版本。关于该框架及其与WebLogic Server集成的更多信息，请参见Spring与WebLogic Server的集成（中文版，Dev2Dev，2006年3月）。
将各组件组合起来
在了解了组成WLRT的所有单个组件之后，接下来就是要把它们放在一起考虑了。图1展示了所有组件协同工作的方式。其中，必要的构件块是具有新增的确定性垃圾收集功能的JRockit JVM。比起其它JVM，它保证了极短的垃圾收集时间。只有在高性能容器的基础上构建应用程序，才可以获得这样的结果。对于WLRT 1.0来说，这是指WebLogic Server 9。但是在完成时，高性能且可靠的应用程序的关键是您自己的代码。WLRT尊重这一点，它只将Spring Framework作为一个架构组件进行集成，但并不强制用户使用它。只不过它是一个构建模块化的、可重用的、高性能的应用程序的良好起点。如果使用它来开发应用程序，就很容易遵循常见的用于优化资源访问和灵敏性环境中的其他关键因素的著名模式。
实时用例
了解了WLRT的所有组件之后，我们需要看一下相关的用例。WebLogic Real Time可以使用响应灵敏的应用程序为高性能环境提供解决方案。即使WLRT并没有附带相关的示例应用，我们也很容易想到一些。
向套利交易商提出挑战的衍生工具交易
一家大型零售银行的投资工具提供了欧洲证券的衍生工具交易。它是一个柜买中心(over-the-counter，OTC)请求报价和执行系统（但是不提供结算和清算服务）。经纪人提交一个报价请求，并包括了证券代码和数量。系统接受报价并应用特定的业务规则。根据证券代码和市场形势，请求被转发到特定的第三方做市商（market maker），然后做市商会计算并提供该衍生工具的出价和叫价。响应会通过OTC交易台返回给经纪人。然后经纪人可以通过一个后续请求执行该衍生工具的交易，该请求会通过OTC交易台转发给相应的做市商。
该场景的复杂性在于，银行的OTC交易基础架构处理报价请求的短暂等待延迟可能会被套利交易商所利用。在瞬息万变的证券市场上，在这个延迟发生期间，该衍生工具的价格就可能发生了变化。这为套利交易商提供了一个利用交易所的低效率的空子，并将投资银行暴露于其无法承受的风险中。因此投资银行需要一个性能驱动的软件基础架构来交付具有极低延迟的OTC交易。具体来说，为了抵制套利交易商，交易所基础架构的延迟必须比套利交易商的基础架构的延迟短。这样，套利交易商的数据就在交易所的数据之前失效，因此就不可用了。
