GlassFish v2: 明智选择

对于许多公司及其内部开发人员来说，开源软件的吸引力正在与日俱增。这是因为社区可以免费获得和升级开源软件的源码。这意味着这种软件比专用软件拥 有更快的更新速度，并且其升级通常也与公司及其开发人员的需求相吻合。还有它的低成本（开源软件通常是免费的）并没有任何负面影响。所有这些都将转换为巨 额的利润和不断增加的占用率。

然而，公司并不信任使用开源软件来管理它们的业务关键型应用程序或处理高负荷、高事务的环境。这是因为开源软件往往不提供支持，并且有时提供的性 能、可靠性和易操作性都不如专用软件。特别是当遇到类似应用服务器的关键企业组件时，IT 决策者倾向于将开源软件委托给利基 (niche) 应用程序或低风险应用程序。

<!---->

公司再也不必在开源应用服务器和健壮的、可靠的、企业级就绪应用服务器二者之间作出选择。他们可以使用 GlassFish v2 来同时兼顾二者。

<!---->

但是自 GlassFish v2 发行之后，公司现在已经有了开源的应用服务器，并具有处理业务关键应用程序所需的特征以及生产环境的严格性。公司再也不必在开源应用服务器和健壮的、可靠的、企业级就绪应用服务器二者之间作出选择。他们可以使用 GlassFish v2 来同时兼顾二者。

本文着重介绍使 GlassFish v2 成为处理关键业务应用程序的明智选择以及成为生产环境的需求的功能。

目录

目录

 

-	什么是 GlassFish？
-	GlassFish v2 及其商业发行版
-	高可用性和可伸缩性
-	企业级性能
-	集中管理和监控
-	使用配置文件实现简单一步配置
-	与 .NET 的互操作性
-	JBI 就绪
-	高级消息处理
-	具有吸引力的支持报价
-	结束语
-	更多信息
-	关于作者

 

什么是 GlassFish？

2005 年 6 月，Sun 启动了 GlassFish 项目 —— 开发一个与 Java Platform, Enterprise Edition 5 (Java EE 5) 兼容的应用服务器，并向 Java 社区公开。此后，一个名为 GlassFish 社区 的活跃的开发人员社区参与了此项目。他们努力的最初结果是 GlassFish v1（第一个开源的、与 Java EE 5 兼容的应用服务器），以及 Java EE 5. 的参考实现。另外，GlassFish 社区还发布了 Toplink Essentials，即 Java Persistence API 的参考实现。此社区还培养了许多不同的子项目，比如 Metro、jMaki、Open Message Queue (Open MQ)、Hudson 和 Grizzly。

GlassFish v2 包括 GlassFish v1 的所有功能，并添加了其他功能，使得应用服务器能够接受重型生产环境的挑战。

GlassFish v1 的重点是开发人员。目的是提供一个开源并与 Java EE 5 完全兼容的应用服务器，开发人员可以使用此服务器部署并测试其 Java EE 5 应用程序。远景是简单部署，也就是对单个 GlassFish 实例的应用程序部署。在 Common Development and Distribution License (CDDL) 下可用的 GlassFish v1 已经非常流行，每年的下载量都超过 3 百万。它已被全世界采纳并在多个发行版中可用，其中包括支持 Sun 的商业发行版 Sun Java System Application Server Platform Edition 9.0。它还在多个平台上可用，其中包括 Solaris、Windows 和 Linux 操作系统。

2007 年 9 月，GlassFish 社区发布 GlassFish v2，其中包括 GlassFish v1 的所有功能，并添加了其他功能，使得应用服务器能够接受重型生产环境的挑战。本文概述了这些功能。

GlassFish v2 及其商业发行版

正如前文所述，GlassFish v1 有一个支持 Sun 的商业发行版。GlassFish v2 也是如此。GlassFish v2 的支持 Sun 的商业发行版是 Sun Java System Application Server 9.1. GlassFish v2 和 Sun Java System Application Server 9.1 有相同的代码基础。另外，可以从 Sun 购买 Sun Java System Application Server 9.1 的支持服务。有关支持服务的更多信息，请参阅 具有吸引力的支持报价 一节。 可 以免费部署并重新分布 GlassFish v2 和 Sun Java System Application Server 9.1。然而，和 GlassFish v2 不同的是，您不可以修改 Sun Java System Application Server 9.1 —— 它的代码只能以二进制格式获取。GlassFish v2 资源代码可以使用 Classpath 异常 在 CDDL 或 GNU General Public License (GPL) v2 下修改。 多数情况下，本文使用 GlassFish v2 术语来涵盖开源应用服务器、GlassFish v2 及其商业发行版 Sun Java System Application Server 9.1。少数情况下，讨论的内容涉及两个发行版的不同之处时，本文将特指 GlassFish v2 或 Sun Java System Application Server 9.1。

高可用性和可伸缩性

如果应用服务器将要处理关键业务应用程序，则必须确保那些应用程序是高可用性的。为了满足生产环境需求，应用服务器必须扩展以满足增加的工作量。 GlassFish v2 通过集群和 High-Availability Database (HADB) 技术来确保高可用性和可扩展性。

集群

集群 是一组 GlassFish v2 应用服务器实例，您可以将其作为单个逻辑实体进行管理和监控。要创建一个集群，必须首先启用 GlassFish v2 域进行集群。GlassFish v2 域，或更精确地说是 管理域， 是一个逻辑边界，其中所有的 GlassFish v2 实体都由管理员控制。在运行时，一个域相当于一个 GlassFish v2 应用服务器实例或一个集群。安装 GlassFish v2 时，可以很容易地为域启用集群。例如，安装了 GlassFish v2 之后，可以使用下列命令来创建一个域并为其启用集群：

lib/ant/bin/ant -f setup-cluster.xml

 

还可以从 GlassFish v2 Admin Console 中为现有域启用集群，这将在下文介绍。

通过启用域进行集群，则为域指定一个集群配置文件。有关配置文件的详细信息，请参阅 使用配置文件实现简单一步配置 一节。然后，可以灵活地从域中创建或移除集群，并从指定集群中添加或移除 GlassFish v2 实例。通过将实例添加到集群中或在域内添加集群，可以进行扩展以满足增加的应用服务器容量和速度的需求。有关管理和监控集群的更多信息，请参阅 集中管理和监控。

如果集群中的一个应用服务器实例失败了，与此实例交互的会话将会被重新发送给集群中的另一个实例，以便其可以处理此会话。

也许集群最重要的方面是 内存复制。在内存复制中，GlassFish v2 实例中有关已部署应用程序的用户会话状态的信息被复制到集群中的一个对等实例中。集群中的每个 GlassFish v2 实例都将会话状态信息发送到集群中的下一个实例中，即它的 复制伙伴。集群中实例的顺序基于实例的名称。当已部署应用程序的会话状态信息在任何实例中更新时，它将被复制到整个集群中。

在内存复制中扮演重要角色的是 负载均衡器，它可用作 GlassFish v2 的插件。负载均衡器服负责在多个 GlassFish v2 实例之间分配工作量。当一个实例失败时，它还参与重新发送会话。如果集群中的 GlassFish v2 实例失败了，负载均衡器会将与此实例交互的会话重新发送给集群中的另一个实例。

<!----> 图 1. 处理集群中的故障转移   <!---->

如 图 1 所示，如果 Instance 1 失败了，负载均衡器将与 Instance 1 交互的会话发送给另一个实例，即图中的 Instance 2。如果接收会话的实例是失败的 GlassFish v2 实例的复制伙伴，那么将在此处理会话。但是如果接收会话的实例不是复制伙伴，那么复制伙伴会将复制的会话数据传输给接收会话的实例。 换句话说，如果负载均衡器将会话发送给 Instance 3（不是复制伙伴），则复制伙伴 Instance 2 会将状态数据发送给 Instance 3 以处理会话。 通过内存复制，GlassFish v2 使得已部署的应用程序具有高可用性。用户应该很少注意到与这些应用程序交互中的中断（如果存在的话）。

可以通过将集群实例及其复制伙伴放置在不同的计算机上来进一步提高可用性。这样的话，即使其中一台计算机失败了，会话数据也不会丢失。

高可用性数据库（High-Availability Database，HADB）技术

需要非常高级的可用性的企业可以利用 High-Availability Database (HADB) 技术，一种在 Sun Java System Application Server 以前的版本和版本 9.1 中可用的功能。HADB 提供了 99.999％（“五个九”）的可用性，并为维护会话状态信息提供了一个永久数据库。HADB 不是开源，但在生产中是免费使用的。

然而要注意的是，通过 GlassFish v2 集群功能提供的健壮的内存复制应该满足大部分安装的高可用性需求。另外，内存复制比 HADB 需要的安装设置和管理控制要少，而且它还是开源。除此之外，内存复制利用了大量性能优化来超过 HADB。然而，如果您具有当前使用 HADB 的操作，或需要五个九的可用性，那么您可以选择使用 HADB 的 Sun Java System Application Server 9.1。

有关集群及 HADB 的详细信息，请参阅 GlassFish Version 2 中的集群。

企业级性能

不论扩展多少，您都希望应用服务器表现良好。希望它能够以出色的吞吐量和响应时间来处理其处理负载。GlassFish v2 满足这些目标。事实上，在 GlassFish v1 的商业版本中，Sun Java System Application Server 9.0 是第一个发布了 SPECjAppServer2004 基准结果 的开源应用服务器。SPECjAppServer2004¹ 是端对端的应用程序，它使用了由兼容应用服务器实现的所有主要的 Java EE 技术，其方式反映了企业环境中典型的应用程序复杂性和大规模事务处理。

GlassFish v2 是最快的开源应用服务器，其性能胜过市场领先的专用应用服务器。

GlassFish v2 是最快的开源应用服务器，其性能胜过市场领先的专用应用服务器。2007 年 7 月，GlassFish v2 以 20％ 击败竞争者时发布了 单个 Sun Fire T2000 服务器在 SPECjAppServer 上的历史最高分 ²。

最近，为 GlassFish v2 发布了可扩展的结果，即 在此基准上发布的第三高分^.3。此结果在曾经发布的最好结果的 20％ 范围之内，尽管它比产生竞争结果的基准使用了较少的硬件、空间和电源。

请注意，应用服务器的性能取决于所运行的应用程序集合。您的结果可能与 SPECjAppServer2004 基准中的结果不同。

在 GlassFish v2 中已经获得显著性能提升的一个领域是 web 服务技术。GlassFish v2 中的 web 服务技术集合称为 Metro。Metro 包括核心 web 服务技术，比如 Java API for XML-Based Web Services (JAX-WS) 2.1 和支持 Java EE 与 Windows .NET 环境之间的 web 服务交互性 的技术。与伙伴技术 Java Architecture for XML Binding (JAXB) 合作的 JAX-WS 2.1，已经在严格的 web 服务基准 下进行了测试，在每秒处理的请求数方面显示出杰出的性能结果。

有关 GlassFish v2 性能的详细信息，请查阅 SJSAS 9.1 (Glassfish V2) Posts New SPECjAppServer 2004 Result 和 A Scalable SPECjAppServer 2004 Submission。

集中管理和监控

Admin Console 为您提供了对企业中 GlassFish 实例和集群进行控制的中心点。

您可以在单一的 GlassFish v2 Admin Console（官方称为 Sun Java System Application Server Admin Console）中或从 GlassFish v2 命令行界面 (CLI) 中管理并监控 GlassFish v2 实例或集群。这样做不仅为您提供对企业中 GlassFish 实例进行控制的中心点，还允许您独立地管理并监控每一个集群。

易用的 Admin Console

Admin Console 的重要方面之一是它的易用性。登录 Admin Console 时您会注意到这一点。显示的第一个页面是集合了常用操作任务的 Common Tasks 页面。图 2 显示了启用了集群的域的 Common Tasks 页面。

图 2. 启用了集群的域的 Common Tasks 页面
单击查看大图。

 

注意，显示的按钮是用来执行一些任务的，比如创建新的集群、部署企业应用程序以及监控数据。导航树对这些按钮作出补充，为您提供备选路径以执行管理 任务。要启动一个操作任务，只要在此页面单击适当的按钮或在单击树中的一个节点即可。例如，要在启用了集群的域中创建集群，可以通过单击此页面中的 Create New Cluster 按钮或单击导航树中的 Clusters 节点开始。

还要注意，管理任务的支持文档在 Common Tasks 页面中直接可用。这些文档是 Sun Microsystems Documentation 页面 中可用的参考文档的扩展库的一部分。

Common Tasks 页面以及 Admin Console 的许多其他元素是动态的。这些元素是在 Project Woodstock 中开发的下一代用户界面组件集的一部分，它利用 Ajax 功能提供了对输入的快速响应和显示之间的平滑过渡。

综合监控

Admin Console 还使得监控大范围的应用服务器相关数据更容易。在 Common Tasks 页面上单击 View Monitoring Data 按钮就会显示一个选项卡页面，其中每个选项卡会提供有关应用服务器或其操作环境的不同方面的数据。例如，Call Flow 选项卡显示调用流数据 如 图 3 所示。

图 3. 监控调用流
单击查看大图。

 

通过监控给定事务的调用流，可以跟踪穿越不同应用服务器容器的事务，如 图 4 所示。

图 4. 事务的调用流详细信息
单击查看大图。

 

GlassFish v2 启用了 Java Management Extensions (JMX) 技术。这意味着，如果您已经使用 JMX 来监控和管理企业中的资源，那么您也可以很容易地将此方法运用于管理和监控 GlassFish v2 资源。您还可以将 GlassFish v2 合并到通过 Sun Management Center 和 Halcyon 的 PrimeAlert for Sun Application Server 实现的端对端的管理和监控方法中。

智能命令行界面 (CLI)

还可以通过 CLI 来执行与 GlassFish v2 相关的一套完整的管理任务。一般来说，可以通过 Admin Console 或通过 CLI 来执行几乎任何一个与 GlassFish v2 相关的管理任务。例如，可以使用 CLI 来启动和停止 GlassFish v2 域，创建集群，打开或关闭调用流数据的收集。CLI 还有一个“最佳匹配”功能，如果您在输入命令时出现错误，那么它会建议备选输入。例如，如果在 asadmin 命令中错误键入关键字 domain，如下所示：

asadmin start-domian

 

CLI 建议备选输入：

Closest matching command(s):
    asadmin start-domain

 

管理大规模部署

GlassFish v2 提供的 Admin Console 和 CLI 是部署和配置单个实例或集群的极好工具。对于大规模企业部署，可以使用 Sun N1 Service Provisioning System (N1SPS)。Sun Java System Application Server 的 N1SPS 插件使得在整个企业中安装、配置和管理 Sun Java System Application Server 9.1 安装更为容易。还可以使用此插件来配置和管理现有的 GlassFish v2 安装，但是不可用于安装。有关 N1SPS 的详细信息，请参阅 Provisioning Sun Java System Application Server With N1SPS。

有关 Admin Console in GlassFish v2 的详细信息，请参阅 GlassFish Project - Admin Console (GUI) 主页。有关 GlassFish v2 中监控功能的信息，请参阅 GlassFish Version 2 Monitoring Capabilities。

使用配置文件实现简单一步配置

优化是应用服务器的一个重要需求，但是使用每一个服务器可能需要不同种类的优化。例如，要构建和测试应用程序的开发人员可能对优化应用服务器响应应 用程序请求的速度特别感兴趣，但是对安全性则不太感兴趣。比较而言，在生产环境中安全性是非常重要的，因此它成为人们部署应用程序的主要集点。

创建应用服务器域时，可以仅通过指定适当的配置文件来配置和优化 GlassFish v2 以用于特定类型的用途。

可以通过设置配置参数来手动调优应用服务器以满足特定需求，但是这可能需要花费大量的时间和精力。或者可以使用为特定类型的用途预配置的应用服务器 的特定版本。事实上，Sun Java System Application Server 的前一个发布有不同的可用版本。例如，Platform Edition 是为开发人员设计的，而 Enterprise Edition 是为大型企业设计的。然而，为不同用途而安装并管理应用服务器的多个版本可能很难操作。

更好的解决方案是提供单个应用服务器版本，但也为特定的使用模式提供预置配置。事实上，这是 GlassFish v2 的发布方式。它可用于一个大小适宜的发行版捆，并且它支持不同的使用配置文件。每一个配置文件都为特定的使用类型预置配置参数。GlassFish v2 支持三个配置文件：开发人员、集群和企业。

开发人员配置文件优化在开发环境中使用的 GlassFish v2。这意味着配置参数支持快速启动等目标，但不支持登录或会话复制等目标。集群配置文件设置启用集群创建和会话复制的配置参数。企业配置文件优化生产环 境的 GlassFish v2。它支持登录以及其他与安全相关的功能。

表 1 概述三个配置文件的一些特征。

表 1：GlassFish v2 配置文件的特征和设置

特征

描述

开发人员配置文件中的值

集群配置文件中的值

企业配置文件中的值

<!---->

安全存储	用 于安全工件（比如密钥和证书）的存储类型。有两个主要的存储类型：JKS (Java Key Store)，由 Sun 提供的专有类型的密钥库实现，NSS (Network Security Services)，设计用于支持启用安全性的客户机和服务器应用程序的跨平台开发的一组库。存储类型在格式和可以对其进行配置的工具方面是不同的。 NSS 通常是企业解决方案的首选安全存储类型。	JKS	JKS	NSS
快速启动	支持应用服务器快速启动的选项。快速启动通过基于 Java-NIO 的实现来完成，此实现是按需服务框架的一部分。	真（启用）	假（禁用）	假（禁用）
JVM	Java Virtual Machine 配置参数。	Hotspot VM 配置参数	Hotspot VM 配置参数	由 JDK 确定
会话复制机制	标识会话复制机制的选项。	无	内存复制	HADB

 

当创建域时指定配置文件。例如，下列命令创建域并指定此域的企业配置文件。

asadmin create-domain --user admin --adminport 4848 --profile enterprise dev-domain

 

您只需要为特定类型的用途（此处是生产环境）配置和优化 GlassFish v2 应用服务器实例。

有关配置文件的详细信息，请查阅 One Pager: Usage Profile Support for Application Server。

与 .NET 的互操作性

互操作性是企业中的一个重要需求。这是因为企业的应用程序资源通常分布在一定范围的操作环境中。例如，应用程序的客户机部分可能位于一个环境中（比 如 Java EE），而它需要的 web 服务可能位于另一个环境中（比如 Microsoft 的 .NET 框架）。GlassFish v2 支持基于 web 服务的应用程序在 Java EE 和 .NET 环境之间互操作。

Metro 和 Web Services 的互操作性

通过支持安全可靠的消息传送和事务，GlassFish v2 支持基于 web 服务的应用程序在 Java EE 和 .NET 环境之间互操作。

如前文所述，GlassFish v2 包括 Metro， 它提供一组健壮的 web 服务技术。然而，Metro 有不止一堆运行于 Java EE 中的 web 服务技术。Metro 还支持 web 服务与 Windows Communication Foundation (WCF) 互操作，其中 WCF 是 Microsoft 的 .NET 框架中的 web 服务堆。Metro 和 WCF 实现了一套 web 服务规范，通常称为 WS* 规范 —— 均以“WS”开头 —— 它支持安全、可靠和面向事务的 web 服务交互。Metro 中 WS* 规范的实现被称为 Web Services Interoperability Technology (WSIT)。如 图 5 所示，WSIT 支持 GlassFish v2 中的 web 服务客户机与 .NET 3.0 中的 web 服务端点交互，还支持 .NET 3.0 中的 web 服务客户机与 GlassFish v2 中的 web 服务端点交互。还支持 GlassFish v2 客户机与 GlassFish v2 端点通信。

图 5. Metro 与 .NET 的互操作性

 

因为 Metro 和 WCF 支持安全、可靠和面向事务的 web 服务交互，web 服务客户机可以请求它与 web 服务的交互是安全的，交互被安全接收，或这些交互就像可以提交或回滚的事务一样被处理，还可以是这些要求的任意组合。

用于配置 Web 服务互操作性的简单界面

GlassFish v2 中 web 服务端点的交互性特征在名为 WSIT 配置文件的 XML 文件中指定。web 服务开发人员可以在文件中编码所需的 XML。然而，XML 可能十分繁琐，且 WSIT 配置文件的内容十分冗长。开发互操作的 web 服务的更简单的方法是使用 NetBeans IDE 版本 5.5.1 或 6.0。要为 WSIT 启用 NetBeans IDE 5.5.1，请安装 WSIT 插件模块。此插件模块已在 NetBeans IDE 6.0. 中打包。一旦启用，IDE 会呈现一个简单的复选框界面，可用于配置具有 WSIT 特征的 web 服务，比如安全消息、可靠消息和事务支持。图 6 是在 NetBeans IDE 6.0. 中显示的此界面。

图 6. 为互操作的 web 服务指定可靠的消息传递
单击查看大图。

 

注意，在图 6 中选中了 Reliable Message Delivery 和 Deliver Messages In Exact Order 复选框。选中这些复选框之后，就允许 web 服务进行可靠的消息传递，并确保由客户机发送的消息以发送时的正确顺序被传递到 web 服务端点。

然后可以使用 NetBeans IDE 在 GlassFish v2 上部署 web 服务。在这个过程中，IDE 为配置选择生成适当的工件，包括配置文件以及所有适当的 XML 代码。

考虑在 Java EE 平台和 .NET 框架之间实现 web 服务互操作性的时间、困难和成本。要做到这一点，通常需要大量的自定义代码以及一些昂贵的消息传送基础设施。使用 Metro，可以无代价地获得此支持 —— 它已被构建到 GlassFish v2 中。

有关 Metro 对 web 服务与 .NET 互操作性的支持的详细信息，请参阅 Project Tango: An Overview (PDF) 和 Metro Project。

JBI 就绪

GlassFish v2 有对 Open ESB 的内置支持，即 Java Business Integration (JBI) 的实现。由 JSR 208 指定的 JBI 是一个 Java 标准，用于按照面向服务的体系结构 (SOA) 构造业务系统。在 SOA 方法中，应用程序可以在不同的服务中组装，其中每个服务执行一个或多个与业务相关的进程。在构建这些合成应用程序时，SOA 为企业提供了许多敏捷性，因为在一个应用程序中使用的服务和数据可以被其他应用程序共享和重用。类似这种用集成服务和数据来生成新的应用程序的方法通常被 称为集成应用程序系统。过去，实现集成应用程序系统需要使用许多自定义代码或需要在专用系统上投资。JBI 标准化了构造集成应用程序系统的方法，并消除了专门编码或专用解决方案的需要。

JBI 为插件组件定义环境，在此环境中，每一个插件组件都提供一定的技术来运行特定的服务类型、更改服务的运行顺序或执行其他与业务进程相关的任务，比如转换数 据格式。例如，一个 JBI 组件可能是一个 EJB 服务引擎，用于运行部署为 Java EE 企业存档 (EAR) 文件的服务。另一个组件可能是一个运行 SQL 查询的 SQL 服务引擎。第三个组件可能是一种业务进程执行语言 (Business Process Execution Language, BPEL) 服务引擎，此服务引擎运行更改业务进程顺序的 BPEL 语句。一些插件组件是与其他环境通信以提供或使用服务的绑定组件。例如，一个绑定组件可以使用 SOAP over HTTP 来运行一个远程服务以执行信用检查。另一个绑定组件可以使用 SMTP 来发送有关信用检查的电子邮件通知。

这种思想旨在于为组成基于 JBI 系统的组件提供许多灵活性，并在可以合并到合成应用程序中的服务类型上为企业提供范围广泛的选择。作为 JBI 的实现，Open ESB 允许将服务集成到松散耦合的合成应用程序中。

GlassFish v2 为 Open ESB 提供运行时环境。GlassFish v2 提供了运行特定类型服务的大量服务引擎，以及与其他环境通信以提供或使用服务的绑定组件。

Open ESB 运行时环境

GlassFish v2 为 Open ESB 提供运行时环境。GlassFish v2 提供大量服务引擎和绑定组件。因为 Open ESB 是基于 JBI 的，所以可以将与 JBI 兼容的服务引擎和绑定组件添加到 GlassFish v2 所提供的项目中。

如 图 7 所示，在 GlassFish v2 应用服务器中部署的 web 服务通过 JAX-WS 和名为 Sun Java EE Engine 的组件与 JBI 运行时环境进行通信。其他 JBI 组件也是如此，Sun Java EE Engine 使用名为 Normalized Message Router (NMR) 的轻量级消息框架来同其他服务引擎和绑定组件通信。注意，在图 7 中 SE 代表服务引擎，BC 代表绑定组件。

图 7. GlassFish v2 中的 JBI 运行时环境

 

管理 Open ESB 组件

可以使用 Admin Console 或 CLI 来管理 Sun Java EE Engine 以及 GlassFish v2 中的其他 Open ESB 组件。例如，通过在 Common Tasks 页面中单击 Deploy Java Business Integration (JBI) Service Assembly 按钮，就可以使用 Admin Console 来部署一个 JBI 服务程序集，其中包含部分或全部合成应用程序。可以在 Admin Console 或 CLI 中启动、停止、关闭或卸载 Sun Java EE Engine。例如，可以通过在 CLI 中输入下列命令来启动 Sun Java EE Engine：

asadmin start-domian

 

用于构建合成应用程序的工具

在开发端，NetBeans IDE 6.0 提供了大量工具来构建在 Open ESB 环境中运行的合成应用程序。这些工具包括 BPEL 设计工具、图形化 Web Services Description Language (WSDL) 编辑器、Composite Application Service Assembly (CASA) 编辑器以及用于管理模式和 XSLT 转换的工具。

使用 NetBeans IDE 6.0 来构建合成应用程序。然后在 GlassFish v2 中部署、运行并管理这些应用程序。

有关 GlassFish v2 中 Open ESB 支持的详细信息，请参阅 Sun Java EE Engine: Bridging Java EE Web Services and JBI Components 和 Open ESB Project。

高级消息处理

在连接业务软件以建立高效的企业时，有效的消息服务器至关重要。GlassFish v2 提供了 Open Message Queue (Open MQ)，它是面向消息的系统集成的一个完整的 Java Message Service (JMS) 实现。JMS 是一个消息标准，它允许基于 Java EE 的应用程序组件创建、发送、接收和读取消息。实现 JMS 时，Open MQ 提供一个功能完全的消息服务器，Open MQ 是 Sun Java System Message Queue 产品的开源版本。Open MQ 可以独立运行 —— 它有自己的一套管理工具，也可以完全集成到 GlassFish v2 中。

GlassFish v2 提供了 Open MQ，它是面向消息的系统集成的一个完整的 Java Message Service (JMS) 实现。

与 GlassFish v2 一起使用时，消息代理，即为客户机提供基于 JMS 的消息传递服务的 Open MQ 组件，可以与 GlassFish v2 位于相同进程中。也就是说，它们运行在同一个 Java Virtual Machine 中。Open MQ 同应用程序服务器的这种关系被称为 EMBEDDED 模式。消息代理还可以在 LOCAL 模式与 GlassFish v2 共享相同的生命周期，或以 REMOTE 模式单独运行。

高效可靠的消息传递

使用 Open MQ，因为确保了可靠的消息传递，所以可以将旧应用程序和新应用程序连接起来。这样消息传递就有了保证，而且消息会以发送时的正确顺序被传递。

Open MQ 支持异步消息，这意味着应用程序可以发送消息并继续处理消息，而无需等待消息被接收。消息可以以发布-订阅方式发送。使用这种方法，消息的发送者被称为发布者，将消息发送到被称为主题 的中间目标上，如 图 8 所示。订阅主题的多个应用程序（被称为订阅者）通过将消息从主题中移除来消费消息。注意，发布者完全独立于订阅者。消息还可以点对点发送，也就是说，发送到特定的接收者。在这种情况下，消息被发送到队列 中，接收者通过将消息从队列中移除来消费消息。

图 8. Open MQ 中的发布-订阅机制

 

除它的处理能力之外，Open MQ 还易于安装和管理。可以基于 openInstaller 使用基于 GUI 的安装程序安装 Open MQ。或者也可以进行基于文件的安装，即解压归档发行版，然后运行设置脚本来配置 Open MQ 以供使用。Open MQ 提供其自己的 Admin Console 和 CLI 来执行与 Open MQ 相关的操作，比如启动消息代理。此外，Open MQ 通过 Java Authentication and Authorization Service (JAAS) 支持基于 Java Management Extensions (JMX) 的监控、集群和身份验证。

高性能和可用性

Open MQ 已作为独立的应用程序进行测试或集成到 GlassFish 中进行测试，性能结果非常好。另外，在数据和消息代理方面，Open MQ 都支持高可用性。将 Open MQ 与高可用性的 JDBC 提供商一起使用时，就会实现高可用性能力。OpenMQ 已使用 Sun Java System Application Server 9.1、Oracle Real Application Clusters (RAC) 和 mySQL 的 HADB 功能进行了测试。

有关 Open MQ 的详细信息，请参阅 Open Message Queue 项目。

具有吸引力的支持报价

一组灵活的订阅选项可用于 Sun Java System Application Server 9.1。可以获得全额赔偿的支持服务、随需而变的软件更新和升级、Sun Developer Expert 帮助以及更多。订阅价格低至四个套接字每年 $4500。有关详细信息，请参阅 Java System Application Server Subscriptions。

结束语

高可用性、可扩展性、企业级性能、集中管理、简单一步配置以及有效可靠的消息传递等特征使得 GlassFish v2 成为企业品质的应用服务器，它的稳健性可用于处理生产环境的需求，它的可靠性可用于处理业务关键的应用程序。添加对 web 服务互操作性和与兼容 JBI 的运行时的支持，应用服务器就可以为企业提供许多灵活性来满足其应用程序进程需求。不管是开源的 GlassFish v2，还是 GlassFish v2 的 Sun 支持的商业发行版 Sun Java System Application Server 9.1，GlassFish v2 都为业务开放。

¹ SPEC 和基准名称 SPECjAppServer 2004 是 Standard Performance Evaluation Corporation 的注册商标。Sun Java System Application Server 9.0 达到了 521.42 JOPS@Standard（1 Sun Fire T2000 [8 cores, 1 chip] 应用服务器和 1 Sun Fire T2000 [6 cores, 1 chip] 数据库服务器）。有关最新的 SPECjAppServer 2004 基准结果，请访问 SPEC 网站。
²比较基于截至 2007 年 7 月 10 日使用单个 Sun Fire T2000 作为应用服务器的所有 SPECjAppServer 2004 分数。参考分数有：Sun Java Application Server 9.1 达到 883.66 JOPS@Standard（1 Sun Fire T2000 [1 chip, 8 cores] 应用服务器和 1 Sun Fire T2000 [1 chip, 6 cores] 数据库）；BEA Weblogic 9.1 达到 801.70 JOPS@Standard（1 Sun Fire T2000 [1 chip, 8 cores] 应用服务器和 1 Sun Fire T2000 [1 chip, 6 cores] 数据库）；Sun Java Application Server 9.0 达到 521.42 JOPS@Standard（1 Sun Fire T2000 [1 chip, 8 cores] 应用服务器和 1 Sun Fire T2000 [1 chip, 6 cores] 数据库）；IBM WebSphere achieved 616.22 JOPS@Standard（1 Sun Fire T2000 [8 cores, 1 chip] 应用服务器和 1 Sun Fire X4200 [2 chips, 4 cores] 数据库服务器）；BEA Weblogic 9.0 达到 615.64 JOPS@Standard（1 Sun Fire T2000 [1 chip 8 cores] 应用服务器和 1 Sun Fire V490 [4 chips, 8 cores] 数据库）。
³比较基于截至 11/23/07 发布的所有 SPECjAppServer 2004 分数。参考分数有：Sun Java Application Server 9.1 达到 8439.36 JOPS@Standard（6 Sun SPARC Enterprise T2150 应用服务器 [6 chips, 48 cores] 和 1 Sun Fire E6900 数据库 [24 chips, 48 cores]）；Oracle Application Server 10.1 达到 10519.43 JOPS@Standard（Twelve HP BL860c 应用服务器 [24 chips, 48 cores] 和两个 HP Superdome 数据库服务器 [40 chips, 80 cores]）；Oracle Application Server 10.1 达到 9459.19 JOPS@Standard（11 HP BL860c 应用服务器 [22 chips, 44 cores] 和两个 HP Superdome 数据库服务器 [40 chips, 80 cores]）。

 

本文转自:http://blog.csdn.net/elevenXL/archive/2008/05/26/2480984.aspx