• Managed Server的状态监控。
• Managed Server在进程或状态故障时自动重启。
• 对Managed Server进行远程和集中控制，包括启动和停止服务器。

　　Node Manager安全地提供这些功能，将双向的SSL身份验证、一个被允许控制Managed Server的可信主机列表、其他安全功能结合在一起。

　　Node Manager可以注册为Windows服务或UNIX守护程序，因此当机器启动或重启时，它能够自动启动计算机上的Managed Server。

　　本文讨论了如何为WebLogic Portal配置WebLogic Node Manager Service，并提供了一个示例配置顺序。

　　有关Node Manager的完整信息，请参阅http://e-docs.bea.com/wls/docs81/adminguide/nodemgt.html。
Node Manager概览：

　　在高层次上，Node Manager使用被管理的服务器信息进行配置，并且使这些服务器保持在所希望的状态。

　　Node Manager只管理已经启动的托管服务器——Node Manager不影响手动启动的托管服务器。

　　每一台Managed Server运行的主机上能够运行一个Node Manager进程。Node Manager与该主机上的每个Managed Server保持一个socket连接，并使用该连接监视Managed Server的状态。如果Managed Server进程意料外故障或WebLogic确定该进程活着但处在失败或挂起状态，那么Node Manager能够自动重启Managed Server。

　　除了自动重启功能，Node Manager还具有远程控制功能，因此管理员能够通过WebLogic Administration Console或WebLogic Admin工具启动或停止单个或所有Managed Server。在每个Managed Server主机上，Node Manager在配置的端口上监听服务器远程控制命令。

　　Node Manager使用几个安全方法来限制对Node Manager Service、以及从Node Manager Service到Managed Server的远程管理访问。

• 所有从Node Manager Service到Managed Server的通信都是通过安全的双向SSL。每一方必须向另一方证明其身份。
• 所有从管理客户端（WebLogic Administration Console或weblogic Admin工具）到Node Manager Service的通信也都是通过安全的双向SSL。每一方必须向其他一方证明其身份。
• Node Manager Service配置支持指定一个允许管理客户端连接的受信任主机列表。来自其他（非受信任）主机的连接是不被允许的。该功能能够用于拒绝来自除Administration Server主机之外的访问。
• 也有其他一些安全选项是可用的，例如在一个具有多个网卡的系统上指定Node Manager Service应该监听的网络地址。

　　Node Manager Service创建命令行，启动Managed Server进程，不需要调用启动脚本。因此，在启动一台Managed Server时指定标准startManagedServer脚本向操作系统发出的相同类型的信息是很重要的。

　　结合使用Node Manager和WebLogic Portal：
　　除了标准的Node Manager配置步骤，在配置Node Manager与WebLogic Portal协同工作时需要应用一个额外的步骤。

　　特别地，Administration Server域目录包含一个名为“wrspKeystore.jks”的文件。每个Managed Server需要访问服务器根目录上的一个目录中的该文件。

　　默认情况下，Node Manager将在WL_HOME/common/nodemanager的一个子目录下运行服务器，例如，WL_HOME/common/nodemanager/ms1/…。

　　因此，如果Node Manager启动了目录WL_HOME/common/nodemanager/ms1/中一个名为ms1的Managed Server ，那么应该把wsrpKeystore.jks复制到每个Managed Server上的一个目录中，例如，WL_HOME/common/nodemanager/wsrpKeystore.jks。

　　Node Manager配置概述
　　存在许多可能的配置变体，这些变体在http://e-docs.bea.com/wls/docs81/adminguide/confignodemgr.html中有详细描述。

　　一些主要的配置变体包括：

• Node Manager作为一个系统服务/守护程序还是手动启动的进程运行。
• 安全配置的类型和程度。
• Node Manager是否应该自动杀死崩溃或运行在故障状态的Managed Server进程。

　　如果将Node Manager配置为服务器/守护程序，那么在系统启动时将会自动启动它。以这种方式配置，Node Manager能够在机器重启时自动重启Managed Server。

　　Node Manager配置过程：
　　在配置Node Manager中涉及的主要步骤包括：

• 指定安全配置和受信任主机。
• 在每台Managed Server主机上，必须配置Node Manager进程，可选择注册为服务/守护程序。在该步骤中指定安全设置。
• 在WebLogic Administration Console中，需要指定每台Managed Server运行在哪台主机上，以及Administration Server如何联系每台主机上的Node Manager服务。
• 在WebLogic Administration Console中，Node Manager正在管理的每台Managed Server也必须进行配置，这样Node Manager就能够建立起要发送给操作系统的命令。我们将首先通过startManagedWeglogic脚本启动服务器、注意生成的命令行，并使用该信息正确配置每台Managed Server。

　　为WebLogic Portal配置Node Manager示例
　　该示例配置用于具有一台Administration Server和两台Managed Server的域。每台服务器将运行在其自己的主机上。

Administration Server:
- platform: Windows 2000
- hostname: adminbox.foo.com
- IP address: 192.168.1.51

Managed Server 1 (ms1):
- platform: Windows 2000
- hostname: host1.foo.com
- IP address: 192.168.1.52

Managed Server 2 (ms2):
- platform: Windows 2000
- hostname: host2.foo.com
- IP address: 192.168.1.53

　　选择安全配置和信任机制
　　该示例产生环境配置使用完整安全模式。

　　我们将使用WebLogic演示SSL身份keystore (DemoIdentity.jks)和演示SSL发证机构（CA）信任keystore (DemoTrust.jks)，它们包含在WebLogic安装中，安装在WL_HOME/server/lib/*.jks。

　　身份keystore保存证明一方身份的SSL证书；信任keystore保存受信任发证机构的SSL证书，发证机构能够用于证实身份。运行时，服务器提供SSL证书，客户端根据列在其信任keystore中的CA进行检查。

　　SSL证书也包含一个主机身份，该身份嵌入在证书的“Subject”（主题）字段中。SSL客户端使用该主机身份和证书/信任发证机构匹配项确定远程服务器的证书是否可用。客户端验证两台服务器的身份证书都能够被客户端的信任发证机构所接受，客户端用于联系服务器的主机地址与列在证书中的主机身份匹配。

　　每台安装WebLogic的主机具有自己惟一的特定于主机的演示SSL证书，该证书与那台特定的主机的身份一起嵌入。该证书被嵌入到DemoIdentity.jks keystore中。主机身份能够通过Java keytool实用程序显示。我们后面将看一个例子。所有的演示SSL证书由同一个DemoTrust.jks信任发证机构签署，该机构对于所有主机都是一样的。

　　和双向SSL一起使用这些演示keystore，客户端将在DemoIdentity.jks中向一个服务器提供SSL证书，服务器将检查列在其DemoTrust.jks keystore中的CA SSL证书是否接受该证书。

　　这些演示keystores不提供安全的环境。每个WebLogic安装包括相同的演示 CA信任keystore文件（在WL_HOME/server/lib/DemoTrust.jks中）和生成DemoTrust.jks keystore中CA签署的特定于主机的演示身份证书的工具。因此，任何WebLogic安装都能产生被其他使用该DemoTrust.jks CA keystore的WebLogic安装所接受。

　　因此，对于一个真实的生产环境，您应该希望禁用演示CA信任keystore (DemoTrust.jks)，并使用一个有名的发证机构签署的SSL证书，或者至少是您自己定制的发证机构。有关更多信息，请参见http://e-docs.bea.com/wls/docs81/secmanage/ssl.html。

　　因为SSL证书包含主机身份信息，所以当使用SSL证书时，特别是演示证书时，应当注意客户端用于联系服务器的主机名称必须和服务器证书中的主机身份匹配。

　　这暗示多数情况下主机名称是在一个域中配置的。它也暗示了DNS命名。

　　一个通用规则是：不要使用IP地址，而是使用主机名称。主机名称需要以正确格式指定。在指定一个主机名称时，当指定服务器地址时会为SSL证书主机名称格式使用接收服务器端的规则。例如，一个客户端使用的地址“fooHost”需要与服务器SSL证书主机身份字段匹配（如“fooHost”）。如果客户端正在使用“fooHost.foo.com”，服务器SSL证书的主机身份字段是“fooHost”，那么SSL连接将会失败。

　　例如，当一台Administration Server联系一个Managed Server时，为了使SSL配置工作，Administration Server用于联系Managed Server的主机地址必须与Managed Server主机的SSL证书主机身份匹配。

　　使用“keytool” Java实用程序，您能够检查嵌入在演示SSL证书中的主机名称身份，该证书嵌入在DemoIdentity.jks中。这里显示了如何做到这一点：

转到WL_HOME/server/bin。
setWLSEnv.cmd/.sh
cd ..\lib
(WL_HOME/server/lib)
keytool -list -v -alias demoidentity -keystore DemoIdentity.jks
当提示输入keystore密码时，输入：
DemoIdentityKeyStorePassPhrase

　　在输出（Owner字段）中、CN属性是嵌入到主机名称身份中的。

　　例如，在名为“host1.foo.com”的Windows主机中，您将看到像下面的输出：

D:\wl81sp3\weblogic81\server\lib>keytool -v -alias demoidentity
-list -keystore DemoIdentity.jks
Enter keystore password: DemoIdentityKeyStorePassPhrase
Alias name: demoidentity
Creation date: Jun 24, 2004
Entry type: keyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=host1, OU=FOR TESTING ONLY, O=MyOrganization,
L=MyTown, ST=MyState, C=US
Issuer: CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization,
L=MyTown, ST=MyState, C=US
Serial number: -3cb71787b0af00ee4160180a08e071b0
Valid from: Wed Jun 23 16:32:25 MDT 2004 until: Mon Jun 24 16:32:25 MDT 2019
Certificate fingerprints:
　　MD5: 34:B4:D4:86:28:06:9B:C2:29:A1:09:4B:A1:9C:77:55
　　SHA1: F8:A0:AE:6C:A7:9B:CC:FD:0D:AE:17:8D:D9:C8:2F:E9:36:41:86:5B

　　在这种情况下，SSL证书具有主机身份“host1”，因此无论什么时候客户端需要联系host1.foo.com，它需要指定“host1”。

　　对于Windows主机，嵌入在主机上DemoIdentity.jks中的演示SSL证书通常只是主机名称——例如，如果完整的主机名称是“host1.foo.com”，那么将把SSL证书链接到主机“host1”。在这种情况下，您将希望任何联系该Windows主机的客户端在连接时都使用DNS地址“host1”。

　　对于UNIX主机，嵌入在主机上DemoIdentity.jks中的演示SSL证书通常是完全限定的DNS名称——例如，如果完整的主机名称是“host5.foo.com”，那么将会把SSL证书链接到主机“host5.foo.com”。在这种情况下，您将希望任何联系该UNIX主机的客户端在连接时使用主机名称“host5.foo.com”，而不是“host5”或IP地址。

　　当一台Managed Server联系Administration Server时，完全相同的规则也适用。

　　就主机信任来说，我们将允许只有Administration Server主机能够联系Node Manager Service进程。这将允许我们从该Administration Serer主机使用WebLogic Administration Console或weblogic.Admin工具来控制Managed Servers，但拒绝来自任何其他主机的访问。

　　在每台Managed Server主机上配置Node Manager进程：
　　在每台运行着至少一个Managed Server的主机上执行这些步骤一次。在我们的示例配置域中，这些步骤将在主机host1.foo.com和host2.foo.com上执行。

　　1. 首先，让我们手动启动Node Manager，它将创建一些用于编辑的配置文件。默认情况下，Node Manager将在第一次启动时在目录WL_HOME/common/nodemanager下编写一些配置文件。
打开一个命令/终端窗口，cd WL_HOME/server/bin
运行 “startNodeManager(.cmd/.sh)”来交互地启动Node Manager。
Node Manager将在WL_HOME/common/nodemanager中创建一些文件。
在WebLogic Administration Console窗口中，等待直到看到一些下面形式的文本：

　　<Jul 26, 2004 6:00:18 PM MDT> <Info> <NodeManager@*.*:5555> <NodeManager started, log messages being written into file ...,

　　然后输入ctrl-C关闭Node Manager。

　　2. 在WL_HOME/common/nodemanager/nodemanager.hosts中编辑受信任主机文件，以便指定被允许访问和控制将要运行在该主机上的Node Manager Service的远程主机集。每台受信任主机应该在单独一行输入。

　　您能够以主机名称或IP地址输入受信任主机。如果输入了主机名称，那么需要在nodemanager.properties文件中启用逆向DNS查找，我们将在下一步配置该文件。
如果您希望Node Manager Service接受来自任何主机的远程命令，就在hosts文件中输入*。

　　在该示例中，我们希望限制只有Administration Server主机能够访问，因此我们输入Administration Server IP地址：192.168.1.51。

　　限制对受信任主机文件WL_HOME/common/nodemanager/nodemanager.hosts的访问。Node Manager Service在运行期间读取该文件，如果在该文件中添加了主机，它将动态启动接收来自那些主机的远程管理命令。因此，限制对该文件的访问很重要。

　　3. 编辑Node Manager 属性文件WL_HOME/common/nodemanager/nodemanager.properties，来指定SSL安全配置和其他选项。

　　这是指定SSL安全身份和信任keystore与访问信息（如别名和passphrase）的地方。

　　在运行时，Node Manager进程将为主机上的一台或多台Managed Server、可能也有Administration Server或weblogic.Admin工具提供一个SSL证书。所有这几方都将需要在信任keystore中拥有一个发证机构，该keystore接收提供的Node Manager SSL证书。另外，所有这几方都将在运行时向Node Manager进程提供它们自己的SSL证书。因此，Node Manager进程将需要在信任keystore中具有一个发证机构，该keystore接受这几方提供的SSL证书。

　　为了本示例的目的，我们将配置Node Manager进程使用DemoIdentity.jks keystore和DemoTrust.jks CA keystore。因为Administration Server、Managed Server和Node Manager进程都使用DemoTrust.jks keystore中相同的发证机构，该机构已经签署了所有主机上的所有SSL证书，所以这几方都互相信任对方。

　　编辑nodemanager.properties，并指定
KeyStores=DemoIdentityAndDemoTrust
该文件可以指定的其他选项包括Node Manager进程应该监听的端口和网络接口。我们使用默认值。

　　保存nodemanager.properties文件。

　　4. 将Node Manager注册为Windows Service / UNIX守护程序。（可选）

　　如果正在使用UNIX，那么按照http://e-docs.bea.com/wls/docs81/adminguide/confignodemgr.html中的步骤进行配置。

　　对于Windows...
- 转到WL_HOME/server/bin
- 检查“BEA WebLogic ... NodeManager”是否被列为Windows Service （在控制面板/管理工具/服务)。
- 如果它被列为服务，并且正在运行，那么使用鼠标右键单击该服务，选择停止，然后运行：
.\uninstallNodeMgrSvc.cmd
, 按F5刷新服务，确认它已经不再服务列表中。
- 运行
.\installNodeMgrSvc.cmd

- 确认“BEA WebLogic ... NodeManager”服务是否被列为Windows Service

　　5. 在主机上安装Managed Servers需要的文件。

　　WebLogic Portal在每个Managed Server根目录中都需要“wsrpKeystore.jks”文件。默认情况下，Node Manager将在WL_HOME/common/nodemanager的子目录中运行服务器，例如，WL_HOME/common/nodemanager/ms1/…。

　　将wsrpKeystore.jks文件从Administration Server主机Administration Server域目录中复制到该主机上的WL_HOME/common/nodemanager/wsrpKeystore.jks。

　　假定您正在生产模式运行，为了使该主机上的Managed Servers能够自动启动，您在WL_HOME/common/nodemanager目录中也将需要一个boot.properties文件。

　　在WL_HOME/common/nodemanager中创建一个“boot.properties”文件。添加以下形式的内容：
　　username=weblogic (或者任何其他系统用户名)
　　password=weblogic (或者任何其他系统密码)

　　保存该文件。

　　对于每台运行Managed Server的主机重复这些步骤。

　　通过WebLogic Administration Console指定整体Managed Server和Node Manager配置:
　　1. 启动Administration Server。这时候不要启动任何Managed Server。

　　2. 连接WebLogic Administration Console。

　　3. 在WebLogic Administration Console中，我们需要指定主机列表（Managed Server应当运行在其中每个主机上）和Administration Server如何联系每台主机上的Node Manager进程。

　　Node Manager需要该信息，因此它知道启动哪个Managed Server以及在哪里启动。该信息能够在Configuration Wizard中的域安装时指定。如果它还没有被配置，或者我们希望修改它，那么这可以通过WebLogic Administration Console进行配置。

　　3a. 在左窗格中，单击“<域>/计算机”。

　　3b. 如果没有列出计算机，那么为每台正在运行Managed Server的主机创建一个计算机项。单击“Configure a new Machine/Unix Machine...”链接指定该信息。为计算机指定一个唯一名称，并单击Create。对于UNIX计算机，您还能够指定Node Manager服务以特定的userID/groupID运行。

　　3c. 单击Node Manager选项卡，然后指定DNS地址，Administration Server将使用该地址访问那台主机上的Node Manager进程。对于该示例，保持默认的Listen Port设置为5555。

　　如前面所提到的，为了使演示SSL配置能够工作，指定用于联系Managed Server的DNS主机地址必须与Managed Server主机的演示SSL证书匹配。

　　对于Windows主机，Managed Server的演示SSL证书通常只是主机名称——例如，如果完整的主机名称是“host1.foo.com”，那么SSL证书将被链接到主机“host1”。在这种情况下，您将希望Administration Serer在连接时使用主机名“host1”s，而不是“host1.foo.com”或IP地址。

　　对于UNIX主机，Managed Server的演示SSL证书通常是完全限定DNS名称——例如，如果完整的主机名是“host5.foo.com”，那么SSL证书将被链接到主机“host5.foo.com”。在这种情况下，您将希望Administration Server在连接时使用主机名“host5.foo.com”，而不是“host5”或IP地址。

　　3d. 单击服务器选项卡，然后指定哪台（些）Managed Server将运行在该机器上，单击Apply。

　　3e. 对所有运行Managed Server的主机重复步骤3。
　　指定Node Manager应当如何通过WebLogic Administration Console启动和控制每台Managed Server：
在WebLogic Administration Console中，我们需要配置关于每台Managed Server的信息，使Node Manager能够启动它。按照以下步骤配置每个Managed Server节点：

　　1. 在左窗格中，单机<域>/<Managed Server>节点。

　　2. 选中Configuration --> Remote Start选项卡。为了填写该页面，我们需要一些关于Managed Server如何启动的信息。获取这些信息的一个简单方法是通过一个startManagedServer脚本在合适的装箱中手动启动Managed Server。下一步将帮助识别这些信息。

　　3. 为了构建一个startManagedServer脚本，我们暂时在每台运行Managed Server的主机上创建一个“伪造”域文件系统的目录。以后，在我们获得信息后，将会删除这个“伪造”域目录，因为它在运行时是不需要的。

　　在每台运行Managed Server的主机上：（例如，host1.foo.com，host2.foo.com）

　　启动Configuration Wizard创建一个新的WebLogic Configuration，使用Basic WebLogic Portal Domain模板，使用Express配置，输入与真实域相同的用户名和密码，配置与真实域相同的启动模式，命名并创建域。

　　对于该主机上的每个Managed Server：

　　4. 通过startManagedWebLogic脚本启动Managed Server。

　　如前面所提到，为了使演示SSL配置能够工作，在启动Managed Server时指定的Administration Server主机地址必须与Administration Server主机的演示SSL证书匹配。

　　对于Windows主机，Administration Server主机的演示SSL证书通常只是主机名称——例如，如果完整的主机名是“adminbox.foo.com”，那么SSL证书将被链接到主机“adminbox”。在这种情况下，您将希望Managed Server在连接时使用主机名“foobar”，而不是“adminbox.foo.com”或IP地址。

　　对于UNIX主机，Administration Server主机的演示SSL证书通常是完全限定的DNS名称——例如，如果完整主机名是“adminbox.foo.com”，那么SSL证书将被链接到主机“adminbox.foo.com”。在这种情况下，您将希望Managed Server在连接时使用主机名“adminbox.foo.com”，而不是“adminbox”或IP地址。

　　在命令/终端窗口中，转到刚刚创建的“伪造”域目录。

　　通过startManagedWebLogic脚本启动Managed Server。

　　例如，如果Managed Server名为“ms2”，Administration Server在一个具有SSL证书名“adminbox”和端口8001的Windows主机上：
startManagedWebLogic.cmd ms2 t3://adminbox:8001

　　如果您正在生产模式（应该的模式）下运行域，那么您将需要输入系统用户名和密码。

　　一旦Managed Server成功启动，查看WebLogic Administration Console窗口中关于如何启动Managed Server的信息。我们将使用这些信息为Managed Server实例配置Node Manager。如果您是在windows下启动，那么文件和目录名可能会被截短。如果希望，可以扩展路径，但这不是必需的。

　　复制CLASSPATH=... 等行和运行java来启动服务器进程的行。这些行以“weblogic.Server”结束，删除所有新行。

　　例如，CLASSPATH= 等行可能看上去像这样：

　　服务器启动的行可能看上去像这样：

　　5. 关闭Managed Server。

　　6. 回到WebLogic Administration Console，为Managed Server指定Java主目录。Java主目录列在服务器启动行的开始处。删除“bin/java”部分。例如，在上面的服务器启动行中产生Java主目录D:\WL81SP~2\JROCKI~1。输入该值作为Java主目录。

　　7. 现在在主机上指定BEA主目录，也就是WebLogic Platfrom安装的位置。该目录也在CLASSPATH行中被列出了几次，它以weblogic目录开头。在上面的服务器启动行中，您可以看到字符串'D:\WL81SP~2\WEBLOG~1'重复了许多次。删除WebLogic目录，生成'D:\WL81SP~2'。输入该值作为BEA home。

　　8. 保留（Managed Server）根目录字段为空。默认情况下，将在WL_HOME\common\nodemanager的一个子目录下启动Managed Server。

　　9. 现在为Managed Server指定Class Path。使用与服务器启动期间相同的CLASSPATH，但删除前缀“CLASSPATH=”。

　　10. 现在指定（Managed Server）参数。它们由许多服务器启动行组成，去掉了java前缀，删除了-Djava.security.policy= 参数，还删除了weblogic.Server后缀。

　　例如，我们从这样的一行开始：

　　然后删除前缀、参数、后缀，以这样的参数设置结束：

　　11. 指定Security Policy文件。使用与我们在前面步骤中删除的相同的安全策略参数，确定这是绝对路径。不包括-Djava.security.policy=前缀。这将给我们下面的策略文件：
'D:\WL81SP~2\WEBLOG~1\server\lib\weblogic.policy'

　　12. 输入系统用户名和密码，单击Apply

　　13. 为域中每台Managed Server重复这个步骤顺序。

　　在为所有Managed Server完成这些步骤后，关闭Administration Server。

　　使用Node Manager测试
　　1. 首先，让我们确保Node Manager进程正运行在每台Managed Server主机上。

　　在Windows下，能够通过控制面板/管理工具/服务启动Node Manager Windows Service。在UNIX下，以合适的方式启动守护程序。

　　确认Node Manager进程保持运行状态至少30秒。如果错误配置Node Manager进程，它有时会立即关闭。

　　2. 如果需要，启动Administration Server。

　　3. 登录进WebLogic Administration Console，并执行希望的操作。

　　例如，为了启动所有的Managed Server，选择<域>/<Clusters>，右键单击您的群集，选中“Start/Stop this Cluster...”。然后单击“Start all Managed Servers...”，单击Yes。WebLogic Administration Console将与每台Managed Server主机上的Node Manager服务通信，并通知它们启动Managed Server。

　　如果一切都工作了，WebLogic Administration Console屏幕将稳定，这时，所有的Managed Server处于RUNNING状态、TASK COMPLETED状态。

　　如果错误发生，状态将变为FAILED。您可以在FAILED文本上单击来查看错误消息。您能够通过单击“Remote Start Output”选项卡发现额外的信息。

　　4. 如果所有东西工作得都很好，您可以删除在每个装箱上创建的“伪造”域目录，因为它不再需要。

　　调试Node Manager配置
　　调试Node Manager涉及到检查不同组件记录的各种日志文件。

　　下列组件记录了日志文件：
　　- WebLogic Administration Console客户端（调试从管理客户端到Node Manager进程的通信）。

　　默认情况下调试日志是关闭的，但可以为与一台主机上的特定Node Manager进程通信而启用。

　　为了启动它，登录进WebLogic Administration Console，选择希望在与其通信时启用调试的Machines/<主机>，选中“Debug Enabled”框，单击Apply。

　　日志文件被写入到Administration Server的域目录的NodeManagerClientLogs子目录中。

　　- Node Manager进程（调试启动、监控和控制Managed Server）。

　　该输出可以从WebLogic Administration Console中查看，这可以通过单击<Domain>/Servers/<ServerName>，然后选择Control选项卡，然后选择Remote Start Output子选项卡，单击“View Node Manager output”链接来实现。

　　默认情况下，该日志记录是开启的，它被存储在Node Manager运行的主机上，默认情况下存储在WL_HOME/common/nodemanager/NodeManagerLogs/NodeManagerInternal中。

　　- Managed Server进程（调试服务器启动错误）

　　该日志记录默认时是开启的，以多个文件存储在运行Node Manager的主机上。

　　默认情况下把服务器日志写入到WL_HOME/common/nodemanager/<servername>/<servername>.log。

　　该输出能够从WebLogic Administration Console中通过单击<Domain>/Servers/<ServerName>，然后选择窗口底部“View server log”链接来查看。

　　默认情况下把任何服务器向标准输出写的输出发送到WL_HOME/common/nodemanager/<domainname>_<servername>/<servername>_output.log。

　　该输出能够从WebLogic Administration Console中查看，这可以通过单击<Domain>/Servers/<ServerName>，选择Control选项卡，选择Remote Start Output子选项卡，单击“View Server output”链接来实现。

　　默认情况下把任何由服务器写到标准错误的输出发送到
WL_HOME/common/nodemanager/<domainname>_<servername>/<servername>_error.log。

　　该输出可以从WebLogic Administration Console中查看，这可以通过单击<Domain>/Servers/<ServerName>，选择Control选项卡，选择Remote Start Output子选项卡，然后单击“View Server error output”链接来实现。

　　原文出处：http://dev2dev.bea.com/products/wlportal81/articles/wlp_roth.jsp

• Managed Server的状态监控。
• Managed Server在进程或状态故障时自动重启。
• 对Managed Server进行远程和集中控制，包括启动和停止服务器。

　　Node Manager安全地提供这些功能，将双向的SSL身份验证、一个被允许控制Managed Server的可信主机列表、其他安全功能结合在一起。

　　Node Manager可以注册为Windows服务或UNIX守护程序，因此当机器启动或重启时，它能够自动启动计算机上的Managed Server。

　　本文讨论了如何为WebLogic Portal配置WebLogic Node Manager Service，并提供了一个示例配置顺序。

　　有关Node Manager的完整信息，请参阅http://e-docs.bea.com/wls/docs81/adminguide/nodemgt.html。
Node Manager概览：

　　在高层次上，Node Manager使用被管理的服务器信息进行配置，并且使这些服务器保持在所希望的状态。

　　Node Manager只管理已经启动的托管服务器——Node Manager不影响手动启动的托管服务器。

　　每一台Managed Server运行的主机上能够运行一个Node Manager进程。Node Manager与该主机上的每个Managed Server保持一个socket连接，并使用该连接监视Managed Server的状态。如果Managed Server进程意料外故障或WebLogic确定该进程活着但处在失败或挂起状态，那么Node Manager能够自动重启Managed Server。

　　除了自动重启功能，Node Manager还具有远程控制功能，因此管理员能够通过WebLogic Administration Console或WebLogic Admin工具启动或停止单个或所有Managed Server。在每个Managed Server主机上，Node Manager在配置的端口上监听服务器远程控制命令。

　　Node Manager使用几个安全方法来限制对Node Manager Service、以及从Node Manager Service到Managed Server的远程管理访问。

• 所有从Node Manager Service到Managed Server的通信都是通过安全的双向SSL。每一方必须向另一方证明其身份。
• 所有从管理客户端（WebLogic Administration Console或weblogic Admin工具）到Node Manager Service的通信也都是通过安全的双向SSL。每一方必须向其他一方证明其身份。
• Node Manager Service配置支持指定一个允许管理客户端连接的受信任主机列表。来自其他（非受信任）主机的连接是不被允许的。该功能能够用于拒绝来自除Administration Server主机之外的访问。
• 也有其他一些安全选项是可用的，例如在一个具有多个网卡的系统上指定Node Manager Service应该监听的网络地址。

　　Node Manager Service创建命令行，启动Managed Server进程，不需要调用启动脚本。因此，在启动一台Managed Server时指定标准startManagedServer脚本向操作系统发出的相同类型的信息是很重要的。

　　结合使用Node Manager和WebLogic Portal：
　　除了标准的Node Manager配置步骤，在配置Node Manager与WebLogic Portal协同工作时需要应用一个额外的步骤。

　　特别地，Administration Server域目录包含一个名为“wrspKeystore.jks”的文件。每个Managed Server需要访问服务器根目录上的一个目录中的该文件。

　　默认情况下，Node Manager将在WL_HOME/common/nodemanager的一个子目录下运行服务器，例如，WL_HOME/common/nodemanager/ms1/…。

　　因此，如果Node Manager启动了目录WL_HOME/common/nodemanager/ms1/中一个名为ms1的Managed Server ，那么应该把wsrpKeystore.jks复制到每个Managed Server上的一个目录中，例如，WL_HOME/common/nodemanager/wsrpKeystore.jks。

　　Node Manager配置概述
　　存在许多可能的配置变体，这些变体在http://e-docs.bea.com/wls/docs81/adminguide/confignodemgr.html中有详细描述。

　　一些主要的配置变体包括：

• Node Manager作为一个系统服务/守护程序还是手动启动的进程运行。
• 安全配置的类型和程度。
• Node Manager是否应该自动杀死崩溃或运行在故障状态的Managed Server进程。

　　如果将Node Manager配置为服务器/守护程序，那么在系统启动时将会自动启动它。以这种方式配置，Node Manager能够在机器重启时自动重启Managed Server。

　　Node Manager配置过程：
　　在配置Node Manager中涉及的主要步骤包括：

• 指定安全配置和受信任主机。
• 在每台Managed Server主机上，必须配置Node Manager进程，可选择注册为服务/守护程序。在该步骤中指定安全设置。
• 在WebLogic Administration Console中，需要指定每台Managed Server运行在哪台主机上，以及Administration Server如何联系每台主机上的Node Manager服务。
• 在WebLogic Administration Console中，Node Manager正在管理的每台Managed Server也必须进行配置，这样Node Manager就能够建立起要发送给操作系统的命令。我们将首先通过startManagedWeglogic脚本启动服务器、注意生成的命令行，并使用该信息正确配置每台Managed Server。

　　为WebLogic Portal配置Node Manager示例
　　该示例配置用于具有一台Administration Server和两台Managed Server的域。每台服务器将运行在其自己的主机上。

Administration Server:
- platform: Windows 2000
- hostname: adminbox.foo.com
- IP address: 192.168.1.51

Managed Server 1 (ms1):
- platform: Windows 2000
- hostname: host1.foo.com
- IP address: 192.168.1.52

Managed Server 2 (ms2):
- platform: Windows 2000
- hostname: host2.foo.com
- IP address: 192.168.1.53

　　选择安全配置和信任机制
　　该示例产生环境配置使用完整安全模式。

　　我们将使用WebLogic演示SSL身份keystore (DemoIdentity.jks)和演示SSL发证机构（CA）信任keystore (DemoTrust.jks)，它们包含在WebLogic安装中，安装在WL_HOME/server/lib/*.jks。

　　身份keystore保存证明一方身份的SSL证书；信任keystore保存受信任发证机构的SSL证书，发证机构能够用于证实身份。运行时，服务器提供SSL证书，客户端根据列在其信任keystore中的CA进行检查。

　　SSL证书也包含一个主机身份，该身份嵌入在证书的“Subject”（主题）字段中。SSL客户端使用该主机身份和证书/信任发证机构匹配项确定远程服务器的证书是否可用。客户端验证两台服务器的身份证书都能够被客户端的信任发证机构所接受，客户端用于联系服务器的主机地址与列在证书中的主机身份匹配。

　　每台安装WebLogic的主机具有自己惟一的特定于主机的演示SSL证书，该证书与那台特定的主机的身份一起嵌入。该证书被嵌入到DemoIdentity.jks keystore中。主机身份能够通过Java keytool实用程序显示。我们后面将看一个例子。所有的演示SSL证书由同一个DemoTrust.jks信任发证机构签署，该机构对于所有主机都是一样的。

　　和双向SSL一起使用这些演示keystore，客户端将在DemoIdentity.jks中向一个服务器提供SSL证书，服务器将检查列在其DemoTrust.jks keystore中的CA SSL证书是否接受该证书。

　　这些演示keystores不提供安全的环境。每个WebLogic安装包括相同的演示 CA信任keystore文件（在WL_HOME/server/lib/DemoTrust.jks中）和生成DemoTrust.jks keystore中CA签署的特定于主机的演示身份证书的工具。因此，任何WebLogic安装都能产生被其他使用该DemoTrust.jks CA keystore的WebLogic安装所接受。

　　因此，对于一个真实的生产环境，您应该希望禁用演示CA信任keystore (DemoTrust.jks)，并使用一个有名的发证机构签署的SSL证书，或者至少是您自己定制的发证机构。有关更多信息，请参见http://e-docs.bea.com/wls/docs81/secmanage/ssl.html。

　　因为SSL证书包含主机身份信息，所以当使用SSL证书时，特别是演示证书时，应当注意客户端用于联系服务器的主机名称必须和服务器证书中的主机身份匹配。

　　这暗示多数情况下主机名称是在一个域中配置的。它也暗示了DNS命名。

　　一个通用规则是：不要使用IP地址，而是使用主机名称。主机名称需要以正确格式指定。在指定一个主机名称时，当指定服务器地址时会为SSL证书主机名称格式使用接收服务器端的规则。例如，一个客户端使用的地址“fooHost”需要与服务器SSL证书主机身份字段匹配（如“fooHost”）。如果客户端正在使用“fooHost.foo.com”，服务器SSL证书的主机身份字段是“fooHost”，那么SSL连接将会失败。

　　例如，当一台Administration Server联系一个Managed Server时，为了使SSL配置工作，Administration Server用于联系Managed Server的主机地址必须与Managed Server主机的SSL证书主机身份匹配。

　　使用“keytool” Java实用程序，您能够检查嵌入在演示SSL证书中的主机名称身份，该证书嵌入在DemoIdentity.jks中。这里显示了如何做到这一点：

转到WL_HOME/server/bin。
setWLSEnv.cmd/.sh
cd ..\lib
(WL_HOME/server/lib)
keytool -list -v -alias demoidentity -keystore DemoIdentity.jks
当提示输入keystore密码时，输入：
DemoIdentityKeyStorePassPhrase

　　在输出（Owner字段）中、CN属性是嵌入到主机名称身份中的。

　　例如，在名为“host1.foo.com”的Windows主机中，您将看到像下面的输出：

D:\wl81sp3\weblogic81\server\lib>keytool -v -alias demoidentity
-list -keystore DemoIdentity.jks
Enter keystore password: DemoIdentityKeyStorePassPhrase
Alias name: demoidentity
Creation date: Jun 24, 2004
Entry type: keyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=host1, OU=FOR TESTING ONLY, O=MyOrganization,
L=MyTown, ST=MyState, C=US
Issuer: CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization,
L=MyTown, ST=MyState, C=US
Serial number: -3cb71787b0af00ee4160180a08e071b0
Valid from: Wed Jun 23 16:32:25 MDT 2004 until: Mon Jun 24 16:32:25 MDT 2019
Certificate fingerprints:
　　MD5: 34:B4:D4:86:28:06:9B:C2:29:A1:09:4B:A1:9C:77:55
　　SHA1: F8:A0:AE:6C:A7:9B:CC:FD:0D:AE:17:8D:D9:C8:2F:E9:36:41:86:5B

　　在这种情况下，SSL证书具有主机身份“host1”，因此无论什么时候客户端需要联系host1.foo.com，它需要指定“host1”。

　　对于Windows主机，嵌入在主机上DemoIdentity.jks中的演示SSL证书通常只是主机名称——例如，如果完整的主机名称是“host1.foo.com”，那么将把SSL证书链接到主机“host1”。在这种情况下，您将希望任何联系该Windows主机的客户端在连接时都使用DNS地址“host1”。

　　对于UNIX主机，嵌入在主机上DemoIdentity.jks中的演示SSL证书通常是完全限定的DNS名称——例如，如果完整的主机名称是“host5.foo.com”，那么将会把SSL证书链接到主机“host5.foo.com”。在这种情况下，您将希望任何联系该UNIX主机的客户端在连接时使用主机名称“host5.foo.com”，而不是“host5”或IP地址。

　　当一台Managed Server联系Administration Server时，完全相同的规则也适用。

　　就主机信任来说，我们将允许只有Administration Server主机能够联系Node Manager Service进程。这将允许我们从该Administration Serer主机使用WebLogic Administration Console或weblogic.Admin工具来控制Managed Servers，但拒绝来自任何其他主机的访问。

　　在每台Managed Server主机上配置Node Manager进程：
　　在每台运行着至少一个Managed Server的主机上执行这些步骤一次。在我们的示例配置域中，这些步骤将在主机host1.foo.com和host2.foo.com上执行。

　　1. 首先，让我们手动启动Node Manager，它将创建一些用于编辑的配置文件。默认情况下，Node Manager将在第一次启动时在目录WL_HOME/common/nodemanager下编写一些配置文件。
打开一个命令/终端窗口，cd WL_HOME/server/bin
运行 “startNodeManager(.cmd/.sh)”来交互地启动Node Manager。
Node Manager将在WL_HOME/common/nodemanager中创建一些文件。
在WebLogic Administration Console窗口中，等待直到看到一些下面形式的文本：

　　<Jul 26, 2004 6:00:18 PM MDT> <Info> <NodeManager@*.*:5555> <NodeManager started, log messages being written into file ...,

　　然后输入ctrl-C关闭Node Manager。

　　2. 在WL_HOME/common/nodemanager/nodemanager.hosts中编辑受信任主机文件，以便指定被允许访问和控制将要运行在该主机上的Node Manager Service的远程主机集。每台受信任主机应该在单独一行输入。

　　您能够以主机名称或IP地址输入受信任主机。如果输入了主机名称，那么需要在nodemanager.properties文件中启用逆向DNS查找，我们将在下一步配置该文件。
如果您希望Node Manager Service接受来自任何主机的远程命令，就在hosts文件中输入*。

　　在该示例中，我们希望限制只有Administration Server主机能够访问，因此我们输入Administration Server IP地址：192.168.1.51。

　　限制对受信任主机文件WL_HOME/common/nodemanager/nodemanager.hosts的访问。Node Manager Service在运行期间读取该文件，如果在该文件中添加了主机，它将动态启动接收来自那些主机的远程管理命令。因此，限制对该文件的访问很重要。

　　3. 编辑Node Manager 属性文件WL_HOME/common/nodemanager/nodemanager.properties，来指定SSL安全配置和其他选项。

　　这是指定SSL安全身份和信任keystore与访问信息（如别名和passphrase）的地方。

　　在运行时，Node Manager进程将为主机上的一台或多台Managed Server、可能也有Administration Server或weblogic.Admin工具提供一个SSL证书。所有这几方都将需要在信任keystore中拥有一个发证机构，该keystore接收提供的Node Manager SSL证书。另外，所有这几方都将在运行时向Node Manager进程提供它们自己的SSL证书。因此，Node Manager进程将需要在信任keystore中具有一个发证机构，该keystore接受这几方提供的SSL证书。

　　为了本示例的目的，我们将配置Node Manager进程使用DemoIdentity.jks keystore和DemoTrust.jks CA keystore。因为Administration Server、Managed Server和Node Manager进程都使用DemoTrust.jks keystore中相同的发证机构，该机构已经签署了所有主机上的所有SSL证书，所以这几方都互相信任对方。

　　编辑nodemanager.properties，并指定
KeyStores=DemoIdentityAndDemoTrust
该文件可以指定的其他选项包括Node Manager进程应该监听的端口和网络接口。我们使用默认值。

　　保存nodemanager.properties文件。

　　4. 将Node Manager注册为Windows Service / UNIX守护程序。（可选）

　　如果正在使用UNIX，那么按照http://e-docs.bea.com/wls/docs81/adminguide/confignodemgr.html中的步骤进行配置。

　　对于Windows...
- 转到WL_HOME/server/bin
- 检查“BEA WebLogic ... NodeManager”是否被列为Windows Service （在控制面板/管理工具/服务)。
- 如果它被列为服务，并且正在运行，那么使用鼠标右键单击该服务，选择停止，然后运行：
.\uninstallNodeMgrSvc.cmd
, 按F5刷新服务，确认它已经不再服务列表中。
- 运行
.\installNodeMgrSvc.cmd

- 确认“BEA WebLogic ... NodeManager”服务是否被列为Windows Service

　　5. 在主机上安装Managed Servers需要的文件。

　　WebLogic Portal在每个Managed Server根目录中都需要“wsrpKeystore.jks”文件。默认情况下，Node Manager将在WL_HOME/common/nodemanager的子目录中运行服务器，例如，WL_HOME/common/nodemanager/ms1/…。

　　将wsrpKeystore.jks文件从Administration Server主机Administration Server域目录中复制到该主机上的WL_HOME/common/nodemanager/wsrpKeystore.jks。

　　假定您正在生产模式运行，为了使该主机上的Managed Servers能够自动启动，您在WL_HOME/common/nodemanager目录中也将需要一个boot.properties文件。

　　在WL_HOME/common/nodemanager中创建一个“boot.properties”文件。添加以下形式的内容：
　　username=weblogic (或者任何其他系统用户名)
　　password=weblogic (或者任何其他系统密码)

　　保存该文件。

　　对于每台运行Managed Server的主机重复这些步骤。

　　通过WebLogic Administration Console指定整体Managed Server和Node Manager配置:
　　1. 启动Administration Server。这时候不要启动任何Managed Server。

　　2. 连接WebLogic Administration Console。

　　3. 在WebLogic Administration Console中，我们需要指定主机列表（Managed Server应当运行在其中每个主机上）和Administration Server如何联系每台主机上的Node Manager进程。

　　Node Manager需要该信息，因此它知道启动哪个Managed Server以及在哪里启动。该信息能够在Configuration Wizard中的域安装时指定。如果它还没有被配置，或者我们希望修改它，那么这可以通过WebLogic Administration Console进行配置。

　　3a. 在左窗格中，单击“<域>/计算机”。

　　3b. 如果没有列出计算机，那么为每台正在运行Managed Server的主机创建一个计算机项。单击“Configure a new Machine/Unix Machine...”链接指定该信息。为计算机指定一个唯一名称，并单击Create。对于UNIX计算机，您还能够指定Node Manager服务以特定的userID/groupID运行。

　　3c. 单击Node Manager选项卡，然后指定DNS地址，Administration Server将使用该地址访问那台主机上的Node Manager进程。对于该示例，保持默认的Listen Port设置为5555。

　　如前面所提到的，为了使演示SSL配置能够工作，指定用于联系Managed Server的DNS主机地址必须与Managed Server主机的演示SSL证书匹配。

　　对于Windows主机，Managed Server的演示SSL证书通常只是主机名称——例如，如果完整的主机名称是“host1.foo.com”，那么SSL证书将被链接到主机“host1”。在这种情况下，您将希望Administration Serer在连接时使用主机名“host1”s，而不是“host1.foo.com”或IP地址。

　　对于UNIX主机，Managed Server的演示SSL证书通常是完全限定DNS名称——例如，如果完整的主机名是“host5.foo.com”，那么SSL证书将被链接到主机“host5.foo.com”。在这种情况下，您将希望Administration Server在连接时使用主机名“host5.foo.com”，而不是“host5”或IP地址。

　　3d. 单击服务器选项卡，然后指定哪台（些）Managed Server将运行在该机器上，单击Apply。

　　3e. 对所有运行Managed Server的主机重复步骤3。
　　指定Node Manager应当如何通过WebLogic Administration Console启动和控制每台Managed Server：
在WebLogic Administration Console中，我们需要配置关于每台Managed Server的信息，使Node Manager能够启动它。按照以下步骤配置每个Managed Server节点：

　　1. 在左窗格中，单机<域>/<Managed Server>节点。

　　2. 选中Configuration --> Remote Start选项卡。为了填写该页面，我们需要一些关于Managed Server如何启动的信息。获取这些信息的一个简单方法是通过一个startManagedServer脚本在合适的装箱中手动启动Managed Server。下一步将帮助识别这些信息。

　　3. 为了构建一个startManagedServer脚本，我们暂时在每台运行Managed Server的主机上创建一个“伪造”域文件系统的目录。以后，在我们获得信息后，将会删除这个“伪造”域目录，因为它在运行时是不需要的。

　　在每台运行Managed Server的主机上：（例如，host1.foo.com，host2.foo.com）

　　启动Configuration Wizard创建一个新的WebLogic Configuration，使用Basic WebLogic Portal Domain模板，使用Express配置，输入与真实域相同的用户名和密码，配置与真实域相同的启动模式，命名并创建域。

　　对于该主机上的每个Managed Server：

　　4. 通过startManagedWebLogic脚本启动Managed Server。

　　如前面所提到，为了使演示SSL配置能够工作，在启动Managed Server时指定的Administration Server主机地址必须与Administration Server主机的演示SSL证书匹配。

　　对于Windows主机，Administration Server主机的演示SSL证书通常只是主机名称——例如，如果完整的主机名是“adminbox.foo.com”，那么SSL证书将被链接到主机“adminbox”。在这种情况下，您将希望Managed Server在连接时使用主机名“foobar”，而不是“adminbox.foo.com”或IP地址。

　　对于UNIX主机，Administration Server主机的演示SSL证书通常是完全限定的DNS名称——例如，如果完整主机名是“adminbox.foo.com”，那么SSL证书将被链接到主机“adminbox.foo.com”。在这种情况下，您将希望Managed Server在连接时使用主机名“adminbox.foo.com”，而不是“adminbox”或IP地址。

　　在命令/终端窗口中，转到刚刚创建的“伪造”域目录。

　　通过startManagedWebLogic脚本启动Managed Server。

　　例如，如果Managed Server名为“ms2”，Administration Server在一个具有SSL证书名“adminbox”和端口8001的Windows主机上：
startManagedWebLogic.cmd ms2 t3://adminbox:8001

　　如果您正在生产模式（应该的模式）下运行域，那么您将需要输入系统用户名和密码。

　　一旦Managed Server成功启动，查看WebLogic Administration Console窗口中关于如何启动Managed Server的信息。我们将使用这些信息为Managed Server实例配置Node Manager。如果您是在windows下启动，那么文件和目录名可能会被截短。如果希望，可以扩展路径，但这不是必需的。

　　复制CLASSPATH=... 等行和运行java来启动服务器进程的行。这些行以“weblogic.Server”结束，删除所有新行。

　　例如，CLASSPATH= 等行可能看上去像这样：

　　服务器启动的行可能看上去像这样：

　　5. 关闭Managed Server。

　　6. 回到WebLogic Administration Console，为Managed Server指定Java主目录。Java主目录列在服务器启动行的开始处。删除“bin/java”部分。例如，在上面的服务器启动行中产生Java主目录D:\WL81SP~2\JROCKI~1。输入该值作为Java主目录。

　　7. 现在在主机上指定BEA主目录，也就是WebLogic Platfrom安装的位置。该目录也在CLASSPATH行中被列出了几次，它以weblogic目录开头。在上面的服务器启动行中，您可以看到字符串'D:\WL81SP~2\WEBLOG~1'重复了许多次。删除WebLogic目录，生成'D:\WL81SP~2'。输入该值作为BEA home。

　　8. 保留（Managed Server）根目录字段为空。默认情况下，将在WL_HOME\common\nodemanager的一个子目录下启动Managed Server。

　　9. 现在为Managed Server指定Class Path。使用与服务器启动期间相同的CLASSPATH，但删除前缀“CLASSPATH=”。

　　10. 现在指定（Managed Server）参数。它们由许多服务器启动行组成，去掉了java前缀，删除了-Djava.security.policy= 参数，还删除了weblogic.Server后缀。

　　例如，我们从这样的一行开始：

　　然后删除前缀、参数、后缀，以这样的参数设置结束：

　　11. 指定Security Policy文件。使用与我们在前面步骤中删除的相同的安全策略参数，确定这是绝对路径。不包括-Djava.security.policy=前缀。这将给我们下面的策略文件：
'D:\WL81SP~2\WEBLOG~1\server\lib\weblogic.policy'

　　12. 输入系统用户名和密码，单击Apply

　　13. 为域中每台Managed Server重复这个步骤顺序。

　　在为所有Managed Server完成这些步骤后，关闭Administration Server。

　　使用Node Manager测试
　　1. 首先，让我们确保Node Manager进程正运行在每台Managed Server主机上。

　　在Windows下，能够通过控制面板/管理工具/服务启动Node Manager Windows Service。在UNIX下，以合适的方式启动守护程序。

　　确认Node Manager进程保持运行状态至少30秒。如果错误配置Node Manager进程，它有时会立即关闭。

　　2. 如果需要，启动Administration Server。

　　3. 登录进WebLogic Administration Console，并执行希望的操作。

　　例如，为了启动所有的Managed Server，选择<域>/<Clusters>，右键单击您的群集，选中“Start/Stop this Cluster...”。然后单击“Start all Managed Servers...”，单击Yes。WebLogic Administration Console将与每台Managed Server主机上的Node Manager服务通信，并通知它们启动Managed Server。

　　如果一切都工作了，WebLogic Administration Console屏幕将稳定，这时，所有的Managed Server处于RUNNING状态、TASK COMPLETED状态。

　　如果错误发生，状态将变为FAILED。您可以在FAILED文本上单击来查看错误消息。您能够通过单击“Remote Start Output”选项卡发现额外的信息。

　　4. 如果所有东西工作得都很好，您可以删除在每个装箱上创建的“伪造”域目录，因为它不再需要。

　　调试Node Manager配置
　　调试Node Manager涉及到检查不同组件记录的各种日志文件。

　　下列组件记录了日志文件：
　　- WebLogic Administration Console客户端（调试从管理客户端到Node Manager进程的通信）。

　　默认情况下调试日志是关闭的，但可以为与一台主机上的特定Node Manager进程通信而启用。

　　为了启动它，登录进WebLogic Administration Console，选择希望在与其通信时启用调试的Machines/<主机>，选中“Debug Enabled”框，单击Apply。

　　日志文件被写入到Administration Server的域目录的NodeManagerClientLogs子目录中。

　　- Node Manager进程（调试启动、监控和控制Managed Server）。

　　该输出可以从WebLogic Administration Console中查看，这可以通过单击<Domain>/Servers/<ServerName>，然后选择Control选项卡，然后选择Remote Start Output子选项卡，单击“View Node Manager output”链接来实现。

　　默认情况下，该日志记录是开启的，它被存储在Node Manager运行的主机上，默认情况下存储在WL_HOME/common/nodemanager/NodeManagerLogs/NodeManagerInternal中。

　　- Managed Server进程（调试服务器启动错误）

　　该日志记录默认时是开启的，以多个文件存储在运行Node Manager的主机上。

　　默认情况下把服务器日志写入到WL_HOME/common/nodemanager/<servername>/<servername>.log。

　　该输出能够从WebLogic Administration Console中通过单击<Domain>/Servers/<ServerName>，然后选择窗口底部“View server log”链接来查看。

　　默认情况下把任何服务器向标准输出写的输出发送到WL_HOME/common/nodemanager/<domainname>_<servername>/<servername>_output.log。

　　该输出能够从WebLogic Administration Console中查看，这可以通过单击<Domain>/Servers/<ServerName>，选择Control选项卡，选择Remote Start Output子选项卡，单击“View Server output”链接来实现。

　　默认情况下把任何由服务器写到标准错误的输出发送到
WL_HOME/common/nodemanager/<domainname>_<servername>/<servername>_error.log。

　　该输出可以从WebLogic Administration Console中查看，这可以通过单击<Domain>/Servers/<ServerName>，选择Control选项卡，选择Remote Start Output子选项卡，然后单击“View Server error output”链接来实现。

　　原文出处：http://dev2dev.bea.com/products/wlportal81/articles/wlp_roth.jsp

摘要
　　BEA WebLogic Server™通过它的无与伦比的集群技术为电子商务提供所需的可伸缩性和24×7的可用性。集群指的是：在业务关键型系统内，为了分配负载和消除单点故障而将服务器分组的若干方法。集群实现冗余，通过Web技术和对象集群自动将故障切换到备份服务器或者对象实例、保持有状态对象的状态，以及更新JDNI树和复制感知的占位程序。如果硬件或者软件出现故障，客户机访问被透明地转移到工作的服务器或者对象的复制品。集群对它的客户机而言，就像是单一的“超级”服务器，通过惟一的URL访问。在集群内部，服务器通过IP多播通信，通过DNS负载均衡、硬件负载均衡器或者代理服务器支持简单的Web访问模型。BEA WebLogic集群技术是该行业内最先进的，它为客户提供最高级别的可伸缩性和业务关键型Web应用程序的可靠性。

概述
　　Internet已经提高了可靠性标准。用户愈加期盼“dial tone”式的服务质量，24×7的可用性和即时性。人们无法接受直接影响业务关键型客户或者业务合作伙伴的故障。基础架构必须保证高可靠性，以便向企业提供不间断的服务。
　　在当今动态的业务环境中，企业必须能够动态地提高能力以满足需求。支持这种应用程序的基础结构必须具备高度可伸缩性，在不必改变硬件或者软件的情况下，就能够无限制的增长。
　　现在，企业使用Java应用服务器，特别是占据领先地位的BEA WebLogic Server，来为客户的自服务、供应链和分配信道管理、交易、转帐、物资供应和许多其他服务开发和部署高度可伸缩和极其可靠的任务关键型应用程序。在BEA WebLogic Server上的部署覆盖了所有行业，包括电讯（AT&T、Qwest和Verizon）、卫生保健（Aetna、Blue Cross/Blue Shield和Oxford Health Plan）、运输（United Airline、Delta Air Line和DHL Worldwide Express）和金融服务（Charles Schwab、American Express和Fidelity Investment）。

　　这些成功的客户使BEA成为基础架构软件的领头羊，它拥有2100多个合作伙伴ISV、ASP和系统集成商，以及11000多家客户。BEA WebLogic是行业内最先进的Java应用服务器，一直赢得最高的市场份额，以及对J2EE和Web service技术的大力支持。
　　BEA WebLogic Server成功的关键之一是它已经证明，通过卓越的集群能力，它能够提供可伸缩性和高可用性。

集群BEA WebLogic Server TOP
　　BEA WebLogic Server集群由许多部署在网络上的BEA WebLogic Server组成。集群服务器一起工作，提供比单台服务器功能更强大、可靠性更高的应用程序平台。集群对于其客户机来讲是单台服务器，但事实上，它是起着一台“超级”服务器作用的一组服务器。

与单一服务器相比，BEA WebLogic集群有两个主要优点：

• 可伸缩性——集群的能力不受某一单台服务器或者单台机器的限制。为了提高处理能力，可以动态地将新的服务器添加到集群中。如果需要更多的硬件，可以在新机器上添加新的服务器。如果单一的服务器不能充分利用现有的机器，可以在该机器上添加其他的服务器。
• 高可用性——集群利用多台服务器的冗余使客户机与硬件或者软件故障隔离开。集群中的多台服务器可以提供相同的服务。如果某台服务器发生故障，另一台服务器可以接管。从发生故障的服务器自动切换到正在运行的服务器的能力，可以保证对客户机而言具有应用程序的无缝可用性，而无需客户机知道出现了问题。

集群的其他特性：

　　BEA WebLogic Server集群可以进一步聚合在某个域内——域指的是能够由控制台作为单一的逻辑安装所管理的一组BEA WebLogic Server实例和/或者集群。如上所述，BEA WebLogic Server集群以对应用程序开发人员透明的方式向J2EE应用程序提供可伸缩性和高可用性。但是，为了使应用程序程序员和管理员最大限度地提高其应用程序的可伸缩性和可用性，让他们了解集群内固有的问题很重要。
　　BEA WebLogic Server有几种形式的复杂的集群，分别是Web集群、对象集群、JMS（Java消息服务）集群和JDBC连接池（元池）集群。
　　除了基本的集群功能之外，集群内的BEA WebLogic Server实例可以与全局共享和复制的（全部集群）JNDI树（Java命名和目录接口）的组合相互配合，并在内存中进行Servlet和EJB会话状态的复制。

访问BEA WebLogic Server集群 TOP
　　BEA WebLogic Server集群在客户机看来是单一的服务器，可以使用简单的URL来寻址。 实际上，该URL必须映射到集群内的多台服务器，以保证连接请求可以在该集群内负载均衡，并且可以透明地进行故障切换。BEA WebLogic Server支持几种实现这种简单访问模型的技术：

• DNS负载均衡
• 代理服务器（BEA WebLogic代理，或者使用BEA WebLogic插件的第三方Web服务器)
• 硬件负载均衡器

DNS负载均衡 TOP
　　访问BEA WebLogic Server集群最简单的方法是使用映射到所有集群服务器的IP地址的单一DNS（域名系统）名称。当一个DNS名称映射到多个地址时，DNS服务器将循环使用该列表，连续查找这个DNS名称。这提供了一种简单的负载均衡和故障切换方式。每次客户机解析URL，它都将得到循环的下一个地址。这样可以保证客户机连接均匀地在集群中得到均衡。如果某一客户机请求失败，客户机可以通过再一次查找该名称来故障切换该请求，并用新地址重新尝试。对某些应用程序而言，这是一种简单但足以解决问题的方法。但是，它不具备其他解决方案可提供的性能和可管理水平。

代理服务器 TOP
　　访问集群的另一种方法是使用代理回该集群的其他Web服务器。代理服务器可以是含有BEA WebLogic Server的Web服务器，或者是具有BEA WebLogic 插件的Apache、Netscape或者Microsoft Web Server。
　　代理服务器被设置为将某些类型的请求重定向到支持它的服务器上。例如，可以配置代理服务器处理静态HTML页面请求，而将针对Servlet和Java Server Page的请求重定向到支持代理的BEA WebLogic集群。
　　代理服务器的作用类似于硬件负载均衡器，因为代理服务器执行负载均衡、在支持它的集群中的多台服务器之间分配请求。当会话建立时，它继续代理该会话的所有请求到单一的服务器。如果该服务器发生故障，它将任务切换到副服务器。

使用 BEA WebLogic Server作为 Web Server TOP
　　BEA在BEA WebLogic Server中加进了具有完全功能的HTTP服务器。因此，BEA WebLogic Server能够作为完全集群解决方案中的主Web服务器。作为Web站点，除继续提供静态HTML文件之外，还提供个性化的、动态的内容，人们可能期望看到更多的Web服务器被Web应用服务器所替代。

　　用作Web服务器时，高性能的BEA WebLogic Server支持最新的J2EE 1.3标准，进而为客户提供了以下好处：

• 与大多数负载均衡硬件，以及最为广泛使用的Web服务器（使用了所提供的插件）集成
• 与大多数Java虚拟机兼容
• 可伸缩性和高可用性的集群
• 跨集群的Servlet状态复制
• Servlet自动故障切换
• 支持Cookies
• Servlet转发和链接
• JSP结果缓冲
• JSP标签库
• 动态部署
• 基于Web的管理和监控

使用 BEA WebLogic Server作为负载均衡代理 TOP
　　BEA WebLogic Server可以作为负载均衡代理与BEA WebLogic 集群接合。就这一点而论，它可以提供负载分配、故障切换和其他的负载均衡器特性，以及处理Web请求的某些部分（例如，快速静态页面服务）。作为代理，然后它可能将大多数请求重定向到支持它的集群。
　　图1显示了使用BEA WebLogic代理作为负载均衡器的第一种可能的BEA WebLogic集群配置。这种配置充分利用BEA WebLogic作为Web服务器。

图1：BEA WebLogic代理作为BEA WebLogic Web Serve前面的负载均衡器

与第三方Web服务器集成 TOP
　　可以将BEA WebLogic Server与第三方Web服务器集成。Web服务器代理向使用BEA WebLogic Server 所供插件的BEA WebLogic Server代理请求。插件是为iPlanet (Netscape) Enterprise Server、Microsoft IIS和在指定平台上的Apache准备的。它设计用于第三方服务器处理静态页面的环境中。在这种情况下，动态内容（动态页面最好由HTTP Servlet或JSP生成）委托给BEA WebLogic Server ，它可能运行在不同的进程中或者在不同的主机上。对于最终用户——浏览器来说，将HTTP请求委派给BEA WebLogic Server 看起来仍然是来自相同的源。
　　在这种情况下，代理插件也可以访问由BEA WebLogic Server所托管的业务组件（如图2所示）。

图2：BEA WebLogic代理插件连接BEA WebLogic Server

　　该配置使用户可将其投资利用到第三方Web服务器中，从而提供到基于WebLogic Server的环境的平稳过渡，同时支持与第三方服务器密切整合，并且支持BEA WebLogic本身的负载均衡和故障切换能力。

硬件负载均衡器 TOP
　　硬件负载均衡器克服了DNS方法的缺点，它工作在IP级而不是在命名级。同时，硬件负载均衡器比代理服务器所实现的软件均衡器的性能更好。硬件负载均衡器相当于集群的代理。客户机连接到负载均衡器上，并且将该连接路由到支持它的集群服务器中的某一服务器。负载均衡硬件可以跟踪每台服务器的“可用状态”，避免向“反常的”访问器发送请求。在其负载均衡判定中，负载均衡硬件也可以结合负载信息。使用负载均衡硬件更容易看见的一些优点是：

• 更宽的负载均衡算法选择范围——您可以选择各种各样的负载均衡算法。例如，您可以根据负载、连接或者简单的“循环”逻辑来选择算法。
• 跳过失效的服务器——负载均衡器将跳过集群中失效的服务器，从而提高响应时间。
• 加速安全套接字层（Secure Socket Layer，SSL）——负载均衡器通常将SSL处理从应用程序服务器转移到专用SSL加速器上，因而可以加速SSL。通过减少处理安全事务所需的时间，这可以极大地提高性能。
• 较少的网络跳数（hop）——在BEA WebLogic Server集群前面直接使用一个硬件负载均衡器导致从负载均衡器到BEA WebLogic Server 只有一个网络跳。这样比将负载均衡器放在第三方代理Web服务器场之前性能要好，因为那样需要标准的两跳——一跳是从负载均衡器到Web服务器，另一跳是从Web服务器到BEA WebLogic Server。

　　然而，硬件负载均衡器一般比用BEA WebLogic Server充当代理更昂贵，并且没有BEA WebLogic Server特有的智能，该智能可提供更好的故障切换性能、降低网络混乱程度。特别是，硬件负载均衡器不能利用HTTP cookies，这些cookies载有BEA WebLogic集群特有的有关集群对象的主实例和副实例位置的信息。
　　 BEA WebLogic Server支持大多数现在市场上流行的负载均衡硬件产品。注意一点很重要，联合使用这些负载均衡产品和BEA WebLogic Server不需要额外的编码。
　　要支持通过负载均衡硬件的直接客户机访问，BEA WebLogic Server的复制系统（replication system）使客户机能够使用副（secondary）会话状态，而不用管客户机故障切换到哪台服务器。BEA WebLogic Server继续使用客户机方的cookies或者URL重写功能，以记录主服务器和副服务器的位置。然而，在部署负载均衡硬件时，这一信息只能用作客户机会话状态位置的历史。通过负载均衡硬件访问集群时，客户机不使用cookie信息主动查找故障后的服务器位置。简而言之，负载均衡硬件使用它的配置策略将请求定向到集群中某一可用BEA WebLogic Server。

图3：硬件负载均衡器连接BEA WebLogic Server

　　一旦服务器选定哪台客户机将进行故障切换，该服务器就使用该客户机cookie中的信息（或者如果使用URL重写功能，就使用HTTP请求中的信息）获得会话状态复制品（稍后会更详细地讨论）。故障切换过程对客户机仍保持完全透明。

WAN集群 TOP
　　BEA WebLogic集群也可以配置在广域网（WAN）上。在这种情况下，尽管配置成单一的集群，但BEA WebLogic Server实例在物理上可能位于不同的数据中心、属于不同的局域网（LAN），并且可能相距很远。这些配置通常用于灾难恢复，或者提供从地理上分布的客户机到全球分布的应用程序（不同的数据中心托管相同的应用程序）的快速本地访问。

WAN集群方案：
1.在构成WAN集群的两个或者多个LAN之间有可靠的、高吞吐能力的连接。该连接可以是专用线路，或者其他受控的“宽管（fat pipe）”型连接。从BEA WebLogic集群的角度来看，这种情况与简单的LAN情况没什么差别。集群可以为持久性状态使用内存中（in-memory）复制，并且两个LAN之间的所有路由器必须允许多播和点到点连接的TCP/IP。

图4：具有可靠的、高吞吐量连接的WAN集群

　　要使WAN集群高度可用，应该跨WAN生成复制组，以便主和副服务器不在同一数据中心（如图4所示）。

2.没有高吞吐量、可靠的连接可以利用，并且每个LAN只能通过常规的Internet连接访问集群的其他部分，并且没有受控的集线器和路由器。
　　值得推荐的是，在这种情况下，只能使用基于磁盘的持久性（基于JDBC－或者文件）。利用这种配置，子集群不能相互通信。然而，他们使用持久的状态存储设备通过Internet进行复制。使用市场上销售的文件和数据库复制产品（用于文件的Veritas，用于数据库的Oracle等）可以实现这一功能。但是，磁盘存储器复制可能不是实时的，即：它可能根据配置的时间间隔进行复制。测试表明：基于JDBC的持久性比基于文件的持久性要快得多。

图5：没有可靠连接的 WAN集群

　　在此方案中（如上面的图5所示），如果第1个数据中心发生故障，请求将被重路由到另外一个数据中心，对象的状态将从持久性存储器中重载，但自最后一次成功复制之后，可能有些信息没有被复制，因而可能丢失。
　　为了使BEA WebLogic WAN集群能够实现，必须使用像Alteon、F5、和Resonate这样的第三方全局负载均衡器（Global Load Balancer）（也称为Global Content Manager）。
为了实现最高的可用性，WAN 集群可能需要大量的网络和系统资源。

Web 集群 TOP
　　BEA WebLogic Server通过保持访问集群Servlet和Java Server Page（JSP）的客户机的HTTP会话状态，为Web应用程序提供集群支持。这种持久性可以通过配置BEA WebLogic控制台获得，可以从下面三个互斥选项中选择：

• In-memory复制
• 文件系统持久性
• 通过JDBC的数据库持久性

　　每个选项分别表现了持久性和性能之间的一种折衷。文件或数据库的持久性提供可能的最可靠持久性。然而，这些选项就性能而言代价更大。In-memory复制通过Servlet和JSP HTTP会话状态自动故障切换为客户提供高可用性优点。该选项最适合那些为了获取最优性能而愿意接受持久性折衷方案的客户。
　　In-memory复制通过创建主会话来提供客户机会话状态的持久性。而主会话保存在客户机最初连接到的BEA WebLogic Server实例上，并且在集群内的另一个BEA WebLogic Server实例上有该会话状态的副复制品。复制品总是保持最新，以便托管主会话状态的服务器发生故障时可以使用它。从一个实例复制会话状态到另一个实例的过程正是In-memory复制的机制。
　　如果可能，BEA WebLogic Server在不同的机器上（有别于托管主会话状态的机器）创建会话状态的复制品。BEA WebLogic Server使您能够利用Administration Console中的复制组（replication group）进一步控制存放副状态的地方。复制组只是用于存储会话状态复制品的集群实例优先级列表。
　　图6描述了客户机利用BEA WebLogic代理或者硬件负载均衡器访问服务器集群。该示例使用BEA WebLogic Server集群处理静态和动态的Web内容，以及托管应用程序的业务逻辑。所有HTTP请求通过负载均衡器转发给集群。

图6：负载均衡（硬件或者代理）将请求发送给集群内的某一可用服务器

　　当客户机请求Servlet时，硬件负载均衡器代理到集群的请求。负载均衡器利用它的配置策略，将客户机请求发送到Server A之后，Server A充当客户机Servlet会话状态的主托管机。
　　在上面的图6中，Server A使用特殊的算法托管会话状态的复制品。选择Server B托管该复制品。通知客户机在本地cookie中记录Server A和Server B的位置。如果客户机不使用cookies，主服务器和副服务器的记录可以记录在通过URL重写功能返回客户机的URL中。
　　当客户机向集群提出另外的请求时，负载均衡器使用客户机方cookie中的标识符来确保这些请求继续发送到Server A（而不是被负载均衡到集群内的其他服务器）。这就确保在会话生存期内，客户机总是保持与托管主会话对象的服务器相关联。
　　文件系统和数据库持久性工作方式类似，只是状态数据保存在磁盘上。在这种情况下，BEA WebLogic Server实例之间没有集群感知的占位程序或者状态复制。在故障切换处理期间，保存的状态由下一个从负载均衡器中得到请求的可用服务器实例从磁盘上读取。

用代理Web服务器的故障切换 TOP
　　在客户机会话期间，万一Server A出现故障，客户机到Server A的下一个连接请求也会失败。
　　发生这种情况时，代理可以确定（从cookie或者URL）JSP或者Servlet对象要访问的副服务器（在该例中是Server B）。请求被代理直接重路由到副服务器（B）。之后，Server B指定自己作为主服务器，并在集群内的任何其他可用服务器上创建另一个副服务器（C）（如图7所示）。

图7：具有代理负载均衡的主服务器出现故障，则将请求重定向到集群中的副服务器

用负载均衡硬件的故障切换 TOP
　　负载均衡硬件为了响应连接失败，会使用其配置策略把请求发送给集群中某一可用的BEA WebLogic Server。在上述示例中，假设在Server A出现故障后，负载均衡器会将客户机的请求定向到Server C。
　　当客户机连接到Server C时，服务器使用客户机cookie中的信息(或者如果使用了URL重写功能，则使用HTTP请求中的信息)获取Server B上的会话状态复制品。故障切换的过程足够快，因而系统故障对客户机是完全透明的。
　　Server C变成客户机主会话状态的新托管主机，Server B继续托管会话状态的复制品。在客户机cookie中，或者通过URL重写功能，会再一次更新有关主、副托管主机的新信息。

图8：具有负载均衡硬件的主服务器出现故障，它将请求重定向到集群中的某一可用服务器

　　在两个服务器集群中，客户机将透明地故障切换到托管副会话状态的服务器。另一台服务器一加入到该集群中，或者原来的主服务器重新启动或重新连接到网络中，就会继续客户机会话状态的复制。

对象集群 TOP
　　BEA WebLogic Server支持的第二种形式的集群是对象集群。如果某一对象被集群，该对象的实例——称为复制品——将被部署在集群内的所有服务器上。
　　在BEA WebLogic Server中，支持集群对象的关键技术是复制品感知的占位程序。连接到BEA WebLogic Server集群、并且查找集群对象的客户机获得一个该对象的占位程序，在调用者看来，它是一般的占位程序。但是，该占位程序不是表示单一的对象，而是表示一个复制品集合。
　　通过使用复制品感知的占位程序和全局共享和复制的JNDI树，客户机可以选择调用对象的哪一个实例。
　　默认情况下，在部署对象、然后连入JNDI树的时候，会自动生成该对象的复制品感知的占位程序。如果该对象不需要复制，可以关闭这一特性。复制品感知的占位程序含有查找某一对象所需的逻辑，而这一对象在部署该对象的任意BEA WebLogic Server实例上。
　　BEA WebLogic Server实例有能力更新该占位程序的本地副本，因而该占位程序含有托管对象复制品的所有可用服务器实例的完整列表。该占位程序还包含在其主服务器之中分配负载时的负载均衡逻辑。每次调用时，占位程序利用其负载均衡算法选择调用哪一个复制品。这种在集群中负载均衡对调用者是透明的。如果在调用过程中出现故障，占位程序截获异常并重新尝试调用另一个复制品。这种故障切换对调用者也是透明的。
　　万一出现故障，占位程序从其列表中删除失效的服务器实例。如果在其列表中没有服务器了，则它再次使用DNS查找某个正在运行的服务器，获得当前正在运行的实例列表。此外，占位程序定期地刷新集群内可用的服务器实例列表。这使得占位程序能够利用添加到集群中的新服务器。
　　BEA WebLogic Server中的对象集群根据维护实体bean和会话bean状态的重要性，有差别地处理实体bean和会话bean。下面描述对各种EJB（Enterprise JavaBean）的不同处理方法。

无状态会话EJB TOP
　　因为无状态bean不保存代表客户机的状态，所以占位程序自由地将所有调用路由到托管该bean的任何服务器。因为bean是集群的，所以在故障事件中，占位程序可以自动进行故障切换。

有状态会话EJB TOP
　　BEA WebLogic Server复制有状态会话bean EJB的状态，方法与它复制HTTP会话状态的方法类似。当客户机创建EJBObject占位程序时，最初由负载均衡器选择的实例会自动选择托管已复制EJB状态的副服务器。
　　客户机接收一个复制品感知的占位程序，它列出集群内托管EJB状态的主、副服务器的位置。主服务器托管与客户机交互的实际EJB实例。副服务器只托管复制的EJB状态，这只消耗很小的内存空间。除非发生故障切换，否则副服务器不创建实际的EJB实例。这样保证在副服务器上消耗的资源最少，保存复制的EJB状态不需要配置额外的EJB资源。
　　当客户机修改EJB的状态时，状态变化被复制到副服务器实例上。对于使用事务的EJB，事务提交后，复制立即发生。对于不使用事务的EJB，调用每个方法后复制发生。在这两种情况下，只有EJB状态的实际变化被复制到副服务器上，从而保证与复制过程相关的开销最小。
　　如果主服务器出现故障，客户机的EJB占位程序会将以后的请求重定向到副BEA WebLogic Server实例。此时，副服务器利用复制的状态数据创建一个新的EJB实例，并在副服务器上继续处理。
　　故障切换后，BEA WebLogic Server选择一个新的副服务器来复制EJB会话状态（如果在集群中有其他可用服务器的话）。在下一个方法调用中，将会自动更新客户机的复制品感知占位程序中的新的主、副服务器实例位置。

实体bean TOP
　　当EJBHome找到或者创建一个实体bean之后，它返回订住该服务器的占位程序。该服务器出现故障之前，有关该占位程序的所有请求都发往相同服务器。在这种情况下，BEA WebLogic Server故障切换至另一台服务器。注意：在这种情况下没有复制，BEA WebLogic Server依靠数据库来存储变化情况。由于EJB部署在集群内，所以只需要另一台可用的服务器从数据库中重载其状态。此时，占位程序将会用托管重新创建的EJB的服务器位置进行更新。
　　实体bean的负载均衡只在主（home）级进行。然而，为了故障切换，复制品感知占位程序将在另一台服务器上重试请求。应该注意的是：只有请求在当前事务外时，才是这种情况。
　　由于在集群内可能存在该实体bean的多个实例，所以每个实例都必须在每个事务之前从数据库中读取，并且每次提交时写入。
　　如果是只读的实体bean，bean的数据由访问该bean的服务器实例在本地缓存。在数据很少修改的情况下，这样做节省数据库访问。当这些数据是由只读的EJB修改时，通过向服务器的其他实例多播无效消息，可明确地使集群内相关的只读bean失效。这种失效方法可用于指定的主键、某一键集或者所有指定类型的bean。

全部集群的JNDI树 TOP
　　某一单独BEA WebLogic Server的客户机使用JNDI兼容的命名服务访问对象和服务。JNDI命名服务包含一系列由服务器提供的公共服务，以“树形”结构进行组织。BEA WebLogic Server通过将名称绑定到表示新服务的JNDI树来提供新的服务。客户机通过连接到服务器并查找服务的绑定名称来获得服务。
　　集群内的服务器实例利用全部集群的JNDI树。全部集群的JNDI树与单一服务器的JNDI树类似，在这种情况下该树包含一系列可用的服务。但是，全部集群的JNDI树除了保存本地服务的名称之外，它还保存复制品感知的占位程序，而该占位程序指向集群内所有服务器上可用的集群对象。集群内的各BEA WebLogic Server实例创建和维护全部集群JNDI树的一个本地副本。

JMS 集群 TOP
　　BEA WebLogic Server通过在整个集群内分布JMS目的地和连接工厂来支持多个JMS服务器的集群。
　　JMS目的地是接收消息的实体。客户机使用JMS连接工厂建立与目的地的连接。
　　利用集群，BEA WebLogic Server的高级JMS可伸缩性可通过如下方法实现：
　　通过连接工厂在多个JMS服务器中分配应用程序的负载。这样提供多个服务器间的连接负载平衡，减少单台JMS服务器上的负载，并通过将连接路由到指定服务器而使会话集中。
　　通过虚拟目的地标识跨多个JMS服务器分配目的地。这可减少指定服务器上各物理目的地的负载，并且极大地提高消息传递的可靠性和性能。
　　可选的多播支持可以减少JMS服务器必需传送的消息数目。JMS服务器只将消息的单个副本转发给每个与多播IP地址相关的主机组，而与订阅的应用程序数目无关。
　　JMS连接工厂可以自动部署在集群内的多台服务器上。使用分布式JMS连接工厂，客户机可以从BEA WebLogic Server的任意实例中取得一个JMS连接。每台BEA WebLogic Server处理一组JMS目的地请求。
　　当JMS客户机请求来自BEA WebLogic Server集群的JMS连接时，它可能根据所用的负载均衡算法从集群的任意服务器上获得。该服务器可能不是处理客户机所需的到指定目的地JMS请求的服务器。但使用JNDI，部署在每个BEA WebLogic Server实例上的连接工厂可以访问集群内任意服务器的目的地组。这样每台客户机可以在集群范围内透明地访问集群内的任何目的地。
　　使用虚拟目的地，允许您配置多个物理目的地作为单一分布式目的地集合的成员，这样万一某台服务器出现故障，BEA WebLogic JMS的高可用性实现可提供某种程度的服务连续性。特别是，管理员可以配置集群内某一给定目的地的多个实例作为虚拟目的地的成员。如果集群内的一个实例出现故障，则同一目的地的其他实例能够为JMS过程和消息使用者提供服务。在这种情况下，可以将遗留在故障服务器上的可迁移目的地服务消息迁移到正在运行的实例上。
　　虚拟目的地和遍及整个集群的分布式连接工厂，使管理员能够通过配置不同的负载均衡算法和为集群各节点设置相对权重来人工均衡JMS服务的负载。

JDBC元池集群 TOP
　　万一正在服务的集群成员发生故障，在不更改连接参数的情况下，集群JDBC（元池）允许外部的JDBC客户机自动重新连接和重启它们的JDBC连接。集群JDBC需要DataSource对象和BEA WebLogic RMI驱动程序以连接到DBMS。利用Administration Console 可以为每个BEA WebLogic Server定义DataSource对象。JDBC元池为部署在BEA WebLogic Server集群内多台服务器上的JDBC连接池提供集群。当客户机向元池请求连接时，集群选择将提供连接的服务器，进行负载均衡和保护，以防止服务器失效。一旦客户机拥有一个连接，由JDBC驱动程序保存的状态使它必需将客户机与主BEA WebLogic Server绑定在一起。

BEA WebLogic Server实例如何在网络上通信 TOP
　　每个BEA WebLogic Server实例运行在惟一IP地址的网络上。整个集群的监听端口必须相同。BEA WebLogic Server允许多宿主（multi-homing），这意味着可以分配多个IP地址给同一台物理机器。因此多宿主主机有多个网络接口，每个网络接口可以运行一个BEA WebLogic Server实例。集群内BEA WebLogic Server实例彼此利用IP多播通信，用以向集群内的所有服务器复制某类信息。IP多播是一种简单的广播技术，它使多个应用程序能够向某一给定IP多播地址和端口号“订阅”，并监听消息。
　　集群中的每台服务器都配置常用的多播地址。当服务器向集群的多播地址发送消息时，所有的服务器都接收消息。这比让服务器发送点到点消息的效率要高得多，但它的确要求集群中的所有服务器必须在支持多播的网络上。多播不能通过Internet上进行，因而集群不能经过Internet。
　　BEA WebLogic Server把IP多播用于集群中各个服务器实例的所有一对多通信。例如：

• 集群范围内的JNDI更新——所有集群成员使用多播通知本地部署或者删除服务的可用性。服务器监视这些通知，以便它们能更新其本地JNDI树以反映当前的部署情况。
• 集群“心跳（heartbeats）”——BEA WebLogic Server使用多播来广播规律的“心跳”消息，通告集群内单个服务器实例的可用性。集群内的所有服务器将监听心跳消息作为确定服务器失效时间的方法。“心跳”的使用是BEA WebLogic确定给定服务器实例是否可用的两种机制之一。BEA WebLogic还监视IP套节字错误作为确定服务器失效时更直接的方法。例如，如果服务器实例A具有到实例B的开放套节字，而该套节字突然关闭了，则Server A假定Server B脱线了。

配置和管理BEA WebLogic 集群 TOP
　　作为一个单位来管理的内部相关BEA WebLogic Server资源集称为域（domain）。一个域包括一台或者多台BEA WebLogic Server，也可能包括BEA WebLogic Server集群。域，以及集群可以跨多个物理机器生成。
　　通过Administration Console，可以使用BEA的图形用户接口（GUI）管理和监视域、集群或者单独的BEA WebLogic Server的配置。
　　BEA WebLogic集群的重要特性之一是能够把单一的视图应用于集群内配置的所有单独服务器上。在该意义上来说，集群被作为某一域内的实体进行管理。在域中配置集群时，集群的所有服务器必须也是该域的一部分。一个域可以包含多个集群。
　　正在运行管理服务的BEA WebLogic Server称为管理服务器（administration server）。管理服务提供配置和监控整个域的控制中心点。为了在该域进行任意管理操作，必须运行管理服务器。
　　在拥有多台BEA WebLogic Server的域中，只有一台服务器是管理服务器，其他服务器称为受管服务器（Managed Server）。每个BEA WebLogic受管服务器在启动时从管理服务器获得其配置。
　　在生产系统的典型配置中，关于您的业务逻辑的应用程序和组件可以部署在受管服务器上，而管理服务器的作用是配置和监视受管服务器。如果管理服务器出现故障，部署在受管服务器上的应用程序不会受影响，继续处理客户机的请求。在这样的情况下，管理服务器一旦重新启动，就可以重新获得活动域的管理控制。

图9：一般的BEA WebLogic Server域架构，它含有单独的服务器、集群、多台物理机器和单台管理服务器

配置集群 TOP
　　利用BEA WebLogic Server的Domain Configuration Wizard，可以简单快速地配置集群。通过直观的图形接口，管理员可以通过检查一系列的窗口并输入特定的参数来创建集群域。这些参数配置拥有管理服务器、受管服务器、物理机器，以及特定应用程序的JDBC数据源参数、JMS工厂和目的地、安全实体、JVM以及其他基本子系统和组件（图10）的集群拓扑。验证并记录用户提供的信息，并由这些信息生成完整的集群配置。

图10：用Domain Configuration Wizard配置BEA WebLogic Cluster

　　Domain Configuration Wizard也可以创建域模板，这样可以复制复杂的环境，简化将集群应用程序转入生产的冗长过程。
　　BEA WebLogic Server域和集群的持久性配置保存在一个XML配置文件中。管理服务器动态管理该配置，并且用户可以通过Administration Console使用它（图11）。

图11：通过BEA WebLogic Server Administration Console管理集群域

　　在Administration Console中可以完成的集群配置任务包括：

• 利用Administration Console的Cluster节点配置服务器集群。利用该节点可以修改的属性包括Cluster Name、Cluster ListenPort和集群中的服务器名称。
• 利用Administration Console的Cluster节点复制服务器集群。集群被复制，保持属性值和原集群中各个服务器，以及在Server节点的Configuration部分设置的新集群名称。
• 利用Administration Console的Cluster节点监视集群中的服务器。
• 利用Administration Console的Cluster节点为集群指派服务器。
• 利用Administration Console的Cluster节点删除集群。

使用节点管理器（Node Manager）自动管理 TOP
　　BEA WebLogic Server生产环境中的受管服务器通常被分布在多台机器和多个地理位置。自动管理允许集群自管理和自动地对各种突发条件和情况做出反应。利用节点管理器实用程序大大方便了这一强大的特性。
　　节点管理器是一个Java实用程序，在BEA WebLogic Server（图12）中作为独立的进程运行，允许您执行受管服务器的常规操作任务，而不管它与其管理服务器的相对位置如何。虽然节点管理器的使用是可以选择的，但如果您的BEA WebLogic Server环境以高可用性要求托管应用程序，则它可提供极有价值的优点。

图12：多机集群域中的节点管理器

　　与只刷新用户请求信息显示的Administration Console不同，节点管理器连续地监视受管服务器。通过基于JMX的开放管理接口，客户可以基于节点管理器构建强大的事件通知和统计监视框架。同时，可以配置节点管理器自动对集群事件做出反应，并根据预先配置的条件采取某些行动。例如，节点管理器可以在突然失效后自动重启某台受管服务器，或者如果由某台服务器所报告的某一统计参数低于配置的阈值时，则给管理员发送消息。

　　有关配置和管理BEA WebLogic服务器、集群和域的更多信息，请参阅BEA WebLogic在线文档，其网址是：http://e-docs.bea.com/wls/docs81/adminguide/。

结束语 TOP
　　本白皮书概述了BEA WebLogic Server中的集群特点，说明了BEA WebLogic架构如何使用集群技术提供企业客户所需的高可用性和可伸缩性。
　　有关BEA WebLogic集群技术的更多细节，请参阅BEA WebLogic Server文档，其网址是：http://e-docs.bea.com/wls/docs81。
　　BEA WebLogic集群的目的之一是消除集群内的单点故障。这一点是通过架构实现冗余来达到的。在硬件或者电源故障事件中，客户机能够利用这种冗余自动故障切换到某一正在运行的系统资源上。正是这种避免停机的能力为BEA客户提供了24×7可管理的保证。
　　另一个目标是推动高度可伸缩的企业电子商务基础结构，这在当今的动态业务环境中可使增长能力无限。
　　BEA相信BEA WebLogic集群技术是业内最先进的，并且向客户提供最高级别的可伸缩性和任务关键型应用程序最需要的可靠性。
　　BEA WebLogic集群，加上其他的性能和可伸缩性特性，例如JDBC连接池和多池、高级缓存、只读/可改写的只读实体bean以及线程池，使WebLogic Server成为市场上最可靠、最具伸缩性和性能最强的Java应用服务器。这也是一些大客户，如FedEx、Charles Schwab、Amazon.com和很多其他客户在WebLogic Server上构建其任务关键型应用程序的原因。
　　BEA WebLogic Server是BEA E-Business Platform?的基础。BEA E-Business Platform专门设计成能够跨多个应用程序和系统共享数据和服务，它是构建在各种开放标准之上的基础结构产品集成套件，这些开发的标准支持大量事务、业务流程管理、应用程序集成、企业内和企业之间的业务协作以及创建和维护动态电子市场（e-market）的能力。
　　要了解关于BEA WebLogic Enterprise Platform?的更多信息，请访问 BEA Web站点，其网址是： www.bea.com/。

BEA 简介 TOP
　　BEA是世界上领先的应用程序基础架构软件公司，在世界各地的客户超过13000家，包括Fortune全球500强企业中的大多数。BEA WebLogic Enterprise Platform提供工业强度（industrial strength）的、易于使用的软件基础，使企业更灵活、生产率更高和连接更强，从而显著地增加了IT生产率并加快了投资回报。BEA的平台是超过1700家系统集成商、独立软件开发商，以及与BEA合作以确保成功部署客户解决方案的应用程序服务提供商们的事实标准。

BEA Systems, Inc.
2315 North First Street
San Jose, CA 95131 U.S.A.
电话: +1.408.570.8000
传真: +1.408.570.8901
网址：http://www.bea.com

原文出处：
http://dev2dev.bea.com/products/wlserver81/whitepapers/WLS_81_Clustering.jsp

Enterprise JavaBean (EJB) 是一些應用程式元件，它們實現了 EJB 體系結構規範，並且是 Java 2 Enterprise Edition (J2EE) 平臺的一部分。EJB 是開發和部署分散式的、可伸縮的、交易型的、安全的、可移植的、基於元件的商業應用的理想選擇。

Enterprise JavaBean (EJB)是一些應用程式元件，它們實現了EJB體系結構規範，並且是Java 2 Enterprise Edition (J2EE) 平臺的一部分。EJB是開發和部署分散式的、可伸縮的、交易型的、安全的、可移植的、基於元件的商業應用的理想選擇。

基於EJB的商業應用需要一個EJB容器，用於運行時的執行。所有遵從J2EE規範的應用伺服器，包括WebLogic 8.1在內，都提供了EJB容器。

EJB體系結構背後的主要動機是關係的分離：它將與應用程式基礎設施相關的部分（例如交易處理和安全性）與核心應用程式部分（例如業務邏輯）分離開來。簡言之，EJB體系結構通過指定EJB容器與EJB開發者之間職責的區別，從而達到這種關係上的分離。例如，透明地實現交易處理是EJB容器的職責，而實現業務邏輯則應由EJB開發者負責。雖然EJB容器執行任務時可能需要某些線索（hint），但是，比起實際地實現這些與基礎設施相關的活動來，提供這類線索（通過基於XML的部署描述符）的代價是非常少的。總之，這種關係分離的規則使得商業應用的開發比其他方式要高效得多。

EJB體系結構規範有4種版本：1.0、1.1、2.0和2.1。事實上，EJB version 1.0已經過時了，而最新版本，即2.1，由於剛剛才出現，所以還沒有廣泛提供。BEA WebLogic Server 8.1同時支援1.1和2.0這兩種版本。我們強烈建議在WebLogic Server 8.1中進行開發時使用EJB version 2.0。

實體bean是一種EJB。除了EJB背後的一般動機外，使用實體bean的特定動機是為持久儲存中的業務域（business-domain）實體提供一種駐留在記憶體中的、可共用的、物件導向的視圖。通常，業務域物件就是關聯資料庫中一個表裏面的一行。在本文中，我們討論了關於在WebLogic Server 8.1環境下Entity EJB的設計、開發和部署的特定問題。至於關於EJB技術的綜合教程，我們推薦http://java.sun.com/j2ee上的J2EE教程。

概述

實體bean是設計用來管理關聯資料庫中的資料的。在BEA WebLogic Server 8.1環境下，Entity EJB的開發包括EJB的設計、生成、打包和部署。

從設計的角度來看，實體bean可以由兩條正交軸線來分類：持久性和讀取。順著持久性這條軸線，有兩種類型的實體bean：Bean管理的持久性（Bean-managed persistence，BMP）和容器管理的持久性（Container-managed persistence，CMP）。如果是CMP，則EJB容器將管理實體bean的持久性。而對於BMP，則由實體bean的開發者通過指定的Java原始碼來管理實體bean的持久性。CMP和BMP之間的選擇是互斥的。順著讀取這條軸線，又有兩種類型的bean：遠端的和本地的。遠端實體bean提供了定位的透明性，並且可以從不同的Java虛擬機上讀取。相反，本地實體bean只能在同一應用伺服器內讀取。本地和遠端之間的選擇不是互斥的，因此可以設計具有雙重介面的bean。

在EJB體系結構規範中，每個實體EJB元件都是由一組指定的Java類和一組指定的XML部署描述符組成。EJB的打包過程包括將所有指定的EJB Java類檔和XML部署描述符檔打包到一個Java Archive (JAR)檔中。如果實體EJB還要依賴於一些Java助手類檔，那麼也可以將這樣的類檔包括到EJB JAR檔中，或者將它們單獨打包到一個不同的JAR檔中。

EJB的部署可分為兩種方式，要麼是在BEA WebLogic Server 8.1內直接部署EJB JAR檔以及所依賴的任何JAR檔，要麼是首先將EJB jar檔和所有依賴的JAR檔打包到一個企業應用歸檔（enterprise application archive，EAR）檔內，然後再在WebLogic Server 8.1內部署這個EAR檔。

設計EJB

在設計一個實體時，需要考慮的幾個重要選擇是：

1. 是設計一個CMP實體bean還是一個BMP實體bean。
2. 是設計一個本地實體bean，還是設計一個遠端實體bean，抑或是設計一個雙重介面的實體bean。
3. 是設計一個粗粒度（coarse-grained）的實體bean，還是一個細粒度（fine-grained）的實體bean。
4. 是使用資料傳輸物件，還是使用get和set方法來讀取實體EJB中的資料。
   

下面將討論在開發實體EJB時要面臨的這些設計選擇。

• CMP與BMP
  記住，雖然可能存在一些很合理的例外，但是一般情況下我們強烈推薦使用CMP這種設計。至於為什麼要選擇CMP，而不是BMP，這裏有三大主要原因。

1. 與BMP相比，CMP提供了跨多種不同資料庫的可攜性，因為CMP實體bean不包含任何特定於資料庫的持久性原始碼。CMP易於設計、實現和維護。
2. 通常，CMP擁有好於BMP的性能，因為EJB容器將自動生成特定於資料庫的原始碼，並且這些原始碼將為目標資料庫而最佳化。
3. CMP通過使用本地介面，使得在相關EJB的網路中程式性地（programmatically）進行瀏覽變得非常容易。

• 本地介面、遠端介面和雙重介面

因為CMP通過本地介面管理著實體EJB之間的關係，所以我們強烈建議總是提供一個本地介面。我們認為遠端介面需要的時候很少，但是如果仔細評估一下就會證明遠端介面也是需要的。所以，我們還是設計一個雙重介面吧。

本地介面通過本地客戶機提供了對EJB的最佳化的讀取；遠端方法呼叫（remote method invocation，RMI）的語義不要求通過本地客戶機、使用本地介面來讀取EJB。

遠端客戶機與EJB容器位於不同的虛擬機上，它需要RMI和遠端介面來讀取EJB。從理論上講，單單設計一個本地實體存在著一個明顯的缺點，那就是只有在相同應用伺服器內的客戶機才能讀取該實體bean。然而，這只是一個理論上的缺點，因為實際上很少需要從應用伺服器之外讀取實體EJB。

• 粗粒度與細粒度
  
  這是一個非常有爭議的專題，所以還應根據您個人的經驗小心地評價關於此專題的一些不同觀點。我們的選擇是，實體EJB最常用於表示應用程式業務域中各個實體，所以應該讓實體EJB儘量地細粒度，不過也應將設計限定為僅提供一個本地介面。關於這個問題的爭論始於EJB體系結構規範1.x版本，當時只能通過一個遠端介面來讀取實體EJB。建立在EJB 1.x版本基礎上的任何反對使用細粒度實體EJB的觀點，雖然當時也有合理之處，但是在EJB體系結構規範2.0 中卻已不合時宜了，並且最終遭到反對。請謹記：有些專家可能不同意我們的觀點，所以我們鼓勵您通過實驗進行考證，並在此專題上形成自己的觀點。
  
• 資料傳輸物件與Get和Set方法
  這又是一個有爭議的專題。我們的觀點如下所述：
  • 在實體EJB的本地介面中暴露CMP持久欄位的所有get讀取器（accessor）方法。
  • 為不屬於實體EJB主鍵的一部分的每個CMP持久欄位建立包裝器（wrapper）set方法，並且在實體EJB的本地介面中暴露這些包裝器方法。使用這些包裝器方法背後的動機是，CMP要求所有持久欄位都具有抽象方法setXXX，如果需要在這些setXXX方法內進行任何驗證，那麼就可以先在包裝器方法內完成驗證，然後再呼叫相應的setXXX方法。如果不需
    這樣的驗證，那麼省掉包裝器方法而直接包括setXXX方法也無不可。
  • 在某些少見的環境下，可能要求實體EJB有一個遠端介面，這時可以為每個實體EJB定義一個資料傳輸物件，將該資料傳輸物件作為實體EJB的遠端介面中的一個參數，暴露其get和set方法。

生成和打包EJB

在EJB體系結構規範中，每個實體EJB元件都由一組指定的Java類和一組指定的XML部署描述符組成：

1. 一個必需的實現實體bean核心功能的bean類。
2. 一個遠端介面、本地介面或雙重介面，該介面為實體bean提供了適當的客戶機視圖。
3. 一個遠端主介面（home interface）、本地主介面或者雙重主介面，該介面為實體bean的生命週期管理提供了適當的介面。
4. 如果是具有組合主鍵的實體bean，那麼還有一個必需的主鍵類。
5. 一個ejb-jar XML部署描述符檔，EJB體系結構規範version 2.0對此作了規定。
6. 一個特定於供應商的 weblogic-ejb-jar XML部署描述符檔，BEA WebLogic Server 8.1 對此有規定。
7. 如果是CMP實體bean，那麼還應有一個特定於供應商的weblogic-cmp-rdbms-jar XML 部署描述符檔，BEA WebLogic Server 8.1對此有規定。

這裏使用的例子實體EJB是一個CMP實體EJB，它有一個遠端介面，它的名稱是AccountEJB。在隨WebLogic Server 8.1一起安裝的示例檔中，即 /weblogic81/samples/server/examples/src/examples/ejb20/basic/containerManaged目錄下，可以找到這個實體EJB。

實體bean EJB類和介面可以用EJBGen工具來生成。

• EJBGen
  EJBGen是一種EJB 2.0原始碼生成器，它能夠從一個EJB bean類生成本地介面/遠端介面、本地主介面/遠端主介面、主鍵類和部署描述符。在EJB bean類中使用EJBGen標記來指定不同的EJB設計設定（例如，本地/遠端和CMP/BMP）。在WebLogic Server 8.1 SP01 中，EJBGen 類被包括在/weblogic81/server/lib/weblogic.jar中。在WebLogic Server 8.1 SP02 & SP03中，EJBGen類被包括在/weblogic81/server/lib/ejbgen.jar文件中。將ejbgen.jar添加到Classpath中，以便使用EJBGen工具。

  EJBGen通過以下命令來呼叫：

  javadoc -docletpath ejbgen.jar -doclet weblogic.tools.ejbgen.EJBGen
  <EjbBeanClass>.java

  該命令有一些選項：

  • d [directory]: 建立EJB類/介面和部署描述符時所在的目錄。
  • descriptorDir [directory]: 建立部署描述符時所在的目錄。
  • wls7: 有了–wls7這個選項，就會生成WebLogic Serve 7.1部署描述符。
    

    如果要將更早版本的BEA WebLogic Server部署描述符轉換成WebLogic Server 8.1部署描述符，那麼可以使用DDConverter。

• DDConverter
  DDConverter是一個命令行工具，用於將更早版本的XML部署描述符（ejb-jar.xml、weblogic-ejb-jar.xml和weblogic-cmp-rdbms-jar.xml）轉換成當前版本的WebLogic Server。 DDConverter可以用以下命令來呼叫：

java weblogic.ejb20.utils.DDConverter [options] –d destDir file1 [file2...]

在這個命令中，file是指包含EJB 1.1部署描述符的一個EJB 1.0部署描述符檔或JAR檔。DDConverter的一部分選項有：

• d destDir:部署描述符輸出到的目錄。
• EJBVer output EJB version: 指定輸出EJB版本。缺省版本是2.0。
  在部署EJB之前，必須將其打包到一個JAR檔或EAR檔中。

• EJB JAR文件
  
  EJB JAR檔的結構由EJB類和介面以及包含部署描述符的 META-INF目錄組成。建立一個目錄source/ejb20/basic/containerManaged和一個目錄source/ejb20/basic/containerManaged/META-INF。將Account.java、AccountBean.java、AccountHome.java 和ProcessingErrorException.java從/weblogic81/samples/server/examples/src/examples/ejb20/basic/containerManaged目錄複製到source/ejb20/basic/containerManaged目錄。將ejb-jar.xml、weblogic-ejb-jar.xml和weblogic-cmp-rdbms-jar.xml從/weblogic81/samples/server/examples/src/examples/ejb20/basic/containerManaged目錄複製到source/ejb20/basic/containerManaged/META-INT目錄。

通過Apache Ant使用編譯好的EJB Java類檔和部署描述符建立一個JAR檔，Apache Ant 是一種基於Java的聯編（build）工具。Apache Ant工具需要一個聯編檔。建立一個帶有目標的build.xml檔（參見清單1），以便編譯EJB原始檔案並利用編譯好的類檔生成一個JAR 檔。

將build.xml檔複製到/source目錄。運行build.xml中的ejb-jar目標。EJB JAR檔生成在source/dist目錄中。EJB JAR可以使用BEA WebLogic appc編譯器來編譯。用appc編譯器來編譯並不是必需的，但這是BEA WebLogic推薦的。

• appc
  appc編譯器利用EJB JAR檔生成容器類，並驗證部署描述符。在部署EJB JAR檔之前用 appc編譯EJB JAR類的好處是，這樣可以識別出在部署EJB JAR時可能發生的錯誤。要運行 appc編譯器，應保證weblogic.jar被包括在Classpath中。appc可以通過以下命令來呼叫：

java weblogic.appc [options] <jar file or directory>

appc有一些選項：

• output<file>:指定輸出目錄。
• keepgenerated: 保留生成的.java文件。
• compiler<java>: 將Java編譯器設置成可用。
  

• 部署EJB
  
  要部署一個實體EJBJAR檔，必須有一個帶有Java命名和目錄介面（Java Naming and Directory Interface，JNDI）名稱的資料源。在我以前的文章（WLDJ, Vol. 3, issue 1）中我已解釋了如何建立連結池（Connection Pool）。用JNDI名 "examples-dataSource-demoPool" 建立一個Tx Datasource。這個JNDI 名應該與weblogic-cmp-rdbms-jar.xml部署描述符檔的 <data-source-name>元素中指定的名稱相一致。

為了部署實體EJB JAR檔，在管理控制臺（administration console）中選擇Deployments>EJB Modules節點。單擊Deploy a new EJB Module鏈結（見圖1）。

這時會顯示出Deploy an EJB Module表單（見圖2）。在Deploy an EJB Module 表單中選擇 upload your files(s) 鏈結。接著將會顯示一個Upload and Install an Application or Module 表單。選擇一個要上載的EJB JAR檔，並單擊Upload按鈕。

這時會顯示出Deploy an EJB Module表單。選擇myserver鏈結。接著可以看到myserver目錄中的子目錄列表。單擊upload directory鏈結。在upload目錄中選擇要部署的EJB JAR，並單擊Target Module按鈕（見圖3）。這時會顯示一個Select Targets for this EJB module表單（見圖4）。

在Select targets for this EJB module表單中選擇一個或多個目標伺服器，並單擊Continue按鈕。在接著顯示出的表單中，在Name欄位中指定用於要部署的EJB模組的名稱（見圖5）。

單擊Deploy按鈕以部署EJB JAR檔。這樣一來，EJB JAR將被部署到伺服器上，並且有一個EJB節點被添加到EJB Modules節點中（見圖6）。

EJB應用程式還可以部署到BEA WebLogic Server上，方法是將EJB JAR檔複製到該應用程式要部署到的那個域上的applications目錄中。

BEA WebLogic為在 WebLogic伺服器上部署EJB提供了一些建議。

1. 應該將EJB作為企業歸檔應用程式（EAR應用程式）中的一個EJB JAR來部署，以利於應用程式的移植和修改。
2. 引用了其他EJB的EJB應該部署在相同的應用程式中；weblogic-ejb-jar.xml中的enable-call-by-reference元素應該設置成True，以獲得更好的性能。
3. 部署在WebLogic伺服器叢集上的EJB應該其次地（homogeneously）部署到叢集內每一台受管的伺服器上。如果一個EJB只需部署到叢集內的一台伺服器上，那麼在部署之前應使用appc編譯器先對 EJB進行編譯。
   

結束語

EJB應用程式的開發包括建立EJB類、編譯EJB類和利用編譯好的EJB類建立一個JAR檔，以及將EJBJAR部署到BEA WebLogic Server。通過遵循關於設計、生成和部署EJB JAR到BEA WebLogic Server上的一些建議，EJB應用程式的性能得到了提高。

參考資料

l Programming WebLogic Enterprise JavaBeans: http://edocs.bea.com/wls/docs8.1/ejb/index.html

關於作者

Deepak Vohra 是一名 Web 開發人員，同時也是一名 NuBean 顧問。
Ajay Vohra 是Compuware 公司的一名高級軟體工程師。

Listing 1: build.xml file
<project name="example-entity-ejb" default="all" basedir=".">
<property name="source" value="."/>
<property name="ejb" value="ejb20/basic/containrManaged"/>
<property name="build" value="{source}/build"/>
<property name="j2sdkee" value="c:/j2sdkee1.3.1"/>
<property name="dist" value="{source}/dist"/>

<target name="init">
<!-- Create the time stamp -->
<tstamp/>
<mkdir dir="{build}"/>
<mkdir dir="{build}/META-INF"/>
<mkdir dir="{dist}"/>
</target>
<target name="ejb">
<javac srcdir="{source}" classpath="{j2sdkee}/lib/j2ee.jar"
destdir="{build}" includes="{ejb}/*.java"/>
<copy todir="{build}/META-INF">
<fileset dir="META-INF" includes="*.xml" />
</copy>
</target>
<target name="ejb-jar" depends="ejb">
<jar jarfile="{dist}/entityejb.jar" includes="META-INF/*.xml,
{ejb}/*.class" basedir="{build}"/>
</target>
</project>

　　尽管服务器集群是推动可伸缩性的基本技术，但是当所有的处理都同步完成时，它可能变得很低效。吞吐量可能会增加，但是响应性却会变得不可救药。

　　在本文中，我讨论了异步处理，并举例说明了，巧妙的任务管理会如何提高您应用程序的性能、可用性、可伸缩性和可管理性。我们将以一种高度可配置的方式，创建一个一般的任务分配框架，该框架可以发送任何任务给您的集群中的一台或每台服务器。通过使用多态和 Java 消息服务（ Java Message Service ， JMS ），我们的框架将实现著名的 Command 模式。

解耦合在实际中的意义

　　当服务器收到客户端请求时，它通常需要在返回响应之前执行几个单独的任务。解耦合（ decoupling ）意味着不会一次执行所有的任务，而是把一些任务放入队列并异步地进行处理。因为排队通常是一项低开销的操作，同步的请求会更快地结束。

解耦合的优点

　　按照顺序和并行地处理任务，通常会比随机地处理它们要更加高效（客户端偶然发出请求的时候）。正面的影响比随即表现出来的要大。理论上，解耦合可以提高以下各个方面的性能：

• 健壮性 ： 提高，因为请求将依赖的可能失效的过程更少。
• 响应性 ： 请求的部分后处理减少了接收请求和返回响应之间的时间。
• 可伸缩性 ： 所有解耦合后的过程在复杂性方面可能会增加，但不会有降低响应度的危险。
• 可用性 ： 可以在服务器永远不知道故障原因的情况下处理故障。

　　在子系统不可用的情况下，配置自动重试要更加容易。

　　自然，理论与实践之间的差别在每个应用程序上的体现各不相同。然而，显然，几乎每种实现都至少具有前述的某些优点。

解耦合的缺陷

　　和大部分好东西一样，解耦合也存在缺点。其中最严重的缺点之一就是，如果您不能确保您拥有足够强大的硬件来清空繁忙的处理队列，那么您可能会发现，它的可用性实际上降低了。如果进入的异步请求比您的系统能够处理的要多，队列就会非常迅速地增长。您必须注意设计过程，而对队列实行自动监控无疑是可取的做法。另一个明显的问题是，在请求驱动的环境中，大多数过程都不是很适合于解耦合。事实上，大多数处理都可能被要求返回响应。有时，它会需要一些开箱即用的思想，甚至可能是您为您的客户端所提供的服务方式的变化。

哪些过程可以解耦合

　　从纯技术的角度来讲，几乎所有的过程都可以解耦合。例如，您可以把一个所购买物品及客户详细信息的清单放入队列，从而可以解耦合一个订单事务——异步处理将负责余下的工作。不足之处在于您不能在响应中包含任何处理细节。因此，谨慎地预先验证数据是很重要的，这样可以确保不会出现问题。

　　一种越来越流行的实现是，马上把请求放入队列，然后持续轮询服务器，以便了解何时可以获得响应。尽管这种方法在本质上实际是同步的，而且不会增加请求的处理时间，但是它在心理上具有优势，因为可以在轮询期间显示进度条。

　　除了解耦合完整的业务逻辑（这是一个巨大的难题）之外，更少的集中处理，比如日志记录和发送电子邮件，是可以考虑的良好选择。当性能变得及其重要时，没有理由让客户端等待这种任务的完成。特别的电子邮件是用于解耦合的一个良好选择。让我们做进一步的了解。

实例研究:异步的电子邮件

　　以传统的方式发送电子邮件（作为同步请求的一部分）会引起一些问题。首先，连接到电子邮件服务器需要一次网络往返，速度可能会很慢，尤其是在服务器非常繁忙的时候。过载的电子邮件服务器甚至可以使依赖于电子邮件的服务暂时不可用。

XA 事务支持
　　另一个显而易见的问题是，电子邮件服务器通常在本质上是非事务性的。当事务被回滚时，这可以导致出现不一致的通知——把一条消息放入队列之后不能取消它。幸运的是， JMS 支持事务，而且可以通过把消息的发送延迟到提交底层事务的时候来解决这个问题。

　　考虑访问数据库和事务感知的 JMS 时，您将需要使用 XA 和两阶段提交（ 2PC ）事务。可以使用非 XA 资源来模拟 XA ，但是您可能会得到不一致的数据。启用 XA 只是一个配置问题，而且通常不需要修改代码。参见 WebLogic 文档以获得相关的详细信息。

通过 JMS 发送电子邮件
　　为了使用 JMS 来发送电子邮件，我们需要配置 JMS 组件（比如， JMS 服务器， JMS 队列和连接工厂）。我们还需要编写一个消息驱动 Bean （ Message Driven Bean ， MDB ）来执行信件的实际发送。当我们想要在我们的代码中发送电子邮件时，需要创建一条包含信件的属性和内容的 JMS 消息。之后，我们把它发送给处理队列。

　　这样做的工作量很大！幸运的是， BEA WebLogic JMS 为我们提供了创建一个可以解耦合几乎任何过程的框架所需的全部内容。

用于异步执行的框架

　　是动手看看一些代码的时候了。我们将创建一个框架，这个框架支持在集群中的一台或所有服务器上，异步地执行代码的任何部分。实现起来的确需要花费些力气，但是一旦框架完成，异步执行就是再容易不过的事情了。

　　这个思路是编写一些类，这些类包含一个带有可运行代码的公共方法和另一个用于初始化参数的方法——可能是构造器。封装在 JMS 对象消息中之后，这些预先编写好的类的实例（命令消息）就被发送给在您的服务器上配置的 JMS 队列。至此，消费者把它们取出，然后异步地执行它们（参见图 1 ）。

　　让我们逐个看看这个框架的所有部分：

• JMS 队列 ： 应该在每台服务器上配置一个用于接收命令消息的 JMS 队列。还应该为重复保存故障消息配置错误队列。
• JMS 连接工厂 ： 为了支持事务性行为的运行时选择，应该配置两个连接工厂：一个支持 XA ，而另一个不支持 XA 。
• 命令对象接口 (CommandMessage) ： 这是一个所有命令对象都需要实现的简单 Java 接口。它扩展了 java.io.Serializable 接口，该接口对于在 JMS 对象消息中嵌入我们的命令来说是必需的。现在，因为我们想要在不知道命令的确切类型的情况下运行它们，我们还要实现 java.lang.Runnable 接口，稍后把它们简单地转换为 Runnable 对象，并执行它们的运行方法。我们在不知道我们运行的确切内容的情况下运行了代码。这是最理想的多态。
• 命令执行程序 (CommandExecutionManager) ： 我们将使用一个 MDB 来处理命令。实例池化防止了 JMS 初始化重复出现，这使得 MDB 成为功能非常强大的消息监听器，非常适合于这项任务。编写 Bean 类不需要很大的工作量，我们只需要在 onMessage 方法中编写数行代码（参见清单 1 ）。

　　这样就把收到的消息传递给一个 ObjectMessage ，获得嵌入的命令对象，然后执行它的运行方法。通过在 config.xml 文件中，把队列的重新发送限制设置为一个大于 0 的值，您可以配置一个重试计数器。从您的命令对象抛出一个运行时异常，便可触发重新发送的动作。此外，通过配置重新发送延迟，您还可以控制重试的频率。

用于发送消息的一个帮助器类 (TaskDistributor)

　　从技术上说，这个部分并不是完全必要的，每次都可以手动进行 JMS 排队。然而，这是一个冗长乏味的过程，而且实际上是帮助器使这个框架变得如此实用。帮助器是一个常规的 Java 类，带有用于对命令消息进行排队的静态方法。您可以针对处理不同的场景编写单独的方法，但是为了简明起见，我选择了编写一个可以处理大多数情况的方法：

static void execute(CommandMessage cm, long delay, b oo lean runEverywhere, b oo lean persisted, b oo lean
enableXA, int priority)

　　这个静态方法带有几个用于精确执行控制的参数。让我们逐个讨论这些参数：

• CommandMessage cm ： 一个命令消息实例。
• long delay ： 代表发送属性的时间，借助 weblogic.jms.extensions.WLMessageProducer 类进行设置。这样，就可以在夜间或者其他方便的时间执行命令。接受一个 Date 对象也是可以的。
• b oo lean runEverywhere ： 决定是否发送要执行的消息给集群中的一台随机选中的访问器或者所有的服务器。
• b oo lean persisted ： 将通过使用队列发送程序的 setDeliveryMode 方法选择发送模式。应该始终保持业务关键型的消息，从而在访问器崩溃的时候，这些消息不会丢失。然而，持久性始终是以性能损失为代价的，这也应该纳入考虑的范围内。
• b oo lean enableXA ： 将选择方法是否使用支持 XA 的 JMS 连接工厂。此参数设置为 true 时，排队将参与底层事务（如果存在的话），在提交事务之前不会对消息进行排队。
• int priority ： 决定消息的 JMS 优先级。在发送之前，将使用给定的值调用 javax.jms.Message 类的 setJMSPriority 方法。有效的范围是 0-9 。对于大多数应用程序来说，给命令消息指派不同的优先级似乎有些过头，但是出于完整性方面的考虑，我还是在这里包括了这个选择。

　　应该针对您的特定执行的需要，来量身打造 TaskDistributor 帮助器类的实现。在本文中，要包含一个例子似乎太长了，但是您可以从 WLDJ Web 站点 www.sys-con.com/wldj/sourcec.cfm 下载一个。还可以添加几个额外的参数来控制更高精度的执行，但是另一方面，您可能已经满足于较少的几个选项。

使用异步执行

　　框架完成之后，我们就可以开始实现我们的命令消息了。让我们看一个简单的例子。首先，我们需要创建一个代表我们的命令消息的类（参见清单 2 ）。为了调用执行，我们使用了 TaskDistributor 类（参见清单 3 ）。

　　当调用例子中的执行方法时，一个包含 DistributedLogger 类实例的 ObjectMessage （ JMS 优先级被设置为 4 ）将在 1 秒延迟之后，被发送给集群中所有的服务器。随后，记录程序将在所有的服务器上打印一个字符串给 stdout 。借助已经完成的框架，异步执行变得非常易于实现，完全没有障碍。节点到节点的通信变得前所未有的容易。

容器托管的任务分配

　　我们可以通过使用池化线程和虚拟内存队列，来创建一个类似的服务，以处理异步请求。然而，我们强烈建议让应用服务器来管理所有的线程。

　　此外，因为 JMS 为我们提供了一个非常简洁和灵活的解决方案，没有理由不让我们的服务器来处理错综复杂的过程。事实上，我们可以调用这个方法容器托管的任务分配（ Container-Managed Task Distribution ）。

性能问题

　　BEA WebLogic 可以处理很大的消息量，而且性能通常不是问题。尽管如此，当生产非常大量的命令用于处理时，还是推荐使用非持久性的消息和流水线操作。另外，消息流控制可以缓解：服务利用率的暂时高峰所导致的消息处理消耗过多资源。

并行处理

　　使用 MDB 的一个巨大优点是，它们可以自动地并行处理消息。您可以通过显示池化消费者 Bean 的数量来调整消耗处理资源的数量。

　　WebLogic 提供大量有价值的 JMS 扩展和配置选项——它们中有许多可以用在任务分配的各种实现中。选择和优化用于分页、重新发送、持久性和调节（流控制）的 JMS 参数时，应该格外注意。

　　JMS 是一个非常完善的服务，对其功能进行仔细研究是值得的。想要了解有关提高性能的更多信息，请参见 WebLogic JMS 性能指南。

结束语

　　我们已经讨论了解耦合和异步的消息收发。作为一条经验法则，我们可以说，处理异步请求的服务器，比专门处理同步请求的服务器的执行效率要高。尽管解耦合并不总是件容易的事情，或者甚至不总是个可行的方法，但在考虑周全地实现时，它仍然是一种功能非常强大的机制。我们获得的不仅仅是几个与性能相关的优点，而且能够设计更加灵活的应用程序。

　　BEA WebLogic JMS 远远不止是个用于数据传输的服务。除了可配置性非常强之外，它还提供许多有用的功能，比如自动重新发送，消息的持久化，可调度性， XA 支持，调节，瞬时分页和循环故障消息的重定向。通过利用这种强大的通用性，我们可以创建一个功能强大而且可以扩展的框架，来处理需要进行异步处理的所有情形。

关于作者

　　John-Axel Strahlman 是 Sanda Interactive Ltd ( www.stcinteractive.com ) 的创立者和 CEO 。 Sanda Interactive Ltd 是一家软件咨询公司，总部位于芬兰的 Espoo 。他是一位分布式系统专家，为他的客户的项目提供咨询已经超过 5 年。（ 更多信息 ）

清单 1 ：命令处理器 MDB

public void onMessage(Message msg) {

  ObjectMessage om = 
  	(ObjectMessage) msg;

  Runnable command = 
  	(Runnable) om.getObject();

  command.run();
}

清单 2 ：命令类示例

public class DistributedLogger
  implements CommandMessage {

  private String text = null;

  public void setText(String text) {
    this.text = text;
  }

  public void run() {
    System.out.println(text);
  }
}

清单 3 ：框架使用示例

DistributedLogger logger =
  new DistributedLogger();

String text = 
  "Hello asynchronous execution!"

logger.setText(text);
TaskDistributor.execute(
  logger, //Command instance
  1000,   //delay
  true,   //runEverywhere
  false,  //persisted
  false,  //enableXA
  4);     //delay.

http://sys-con.com/story/?storyid=48222&de=1

1.           Weblogic Portal的 Rules Management Framework提供了运行时功能，用于提供基于具体规则的个性化内容。

2.           Rules Manager EJB 是用于访问底层 BEA Rules Engine的一个可伸缩的、无状态的 J2EE 入口点。它提供了执行用户定义的业务规则所必需的运行时服务。

3.           两个Portal控件：RulesManagerControl和RulesExecutorControl，提供了访问Rules Manager EJB的方便手段。

Portal自带了一些规则，例如内容选择器和活动（campaigns）。用户可以手工建立自定义规则。在把规则部署到Portal之前，可以使用 Portal的Expression包，或者Xml Spy 来验证这些规则的有效性。

业务规则可以动态地加载和修改，这样，通过Workshop IDE，提供了一种测试已部署应用程序中规则的有效方式。

规则引擎的工作原理

规则引擎（Rules Engine）的运作机制是在内存中向对象应用一套规则。首先内存使用来自调用对象的输入，例如用户档案请求会话。这样，在任何规则实际激活之前，在内存中就已经有了一份用户档案的内容。

规则只能在一个上下文环境中执行，上下文环境把规则集和内存关联起来。该环境提供了到Rules Engine的接口，Rules Engine控制着应用程序的规则部分与内存之间的关系。

内存由生产规则（production rules）负责操作，生产规则包含在规则集里。，依照规则的左半边（left-hand sides，LHS）针对内存中的对象进行计算。如果内存中的对象与LHS中描述的模式匹配，就会触发规则的右半边（right-hand side，RHS）指定的操作。 此外某些操作可能会在内存中加入新的对象。例如，规则 Classifier 对用户年龄进行测试，如果 USER.age > 45，就在内存中加入一个新的Classification 对象。

生产系统的运行，要执行以下操作：

1.           匹配: 估计规则的LHS，判断哪个规则与当前内存中的内容匹配。

2.           冲突解决：选择一个LHS匹配的规则。如果没有规则匹配，就停止解释。

3.           操作: 执行选中规则RHS中指定的动作。

4.           返回第1步。

规则会一直在内存中执行，直到冲突解决集变为0时才停止（也就是没有规则能激活了）。

在Rules Engine停止之后，规则管理器组件会返回一个对象列表，列表中包含内存中仍然存在的对象。一个可能的场景就是，还剩下一个类型为“Classification”或“ContentQuery”的对象。

Rules Manager接着对剩下的对象进行迭代，用可选的对象过滤器过滤它们。过滤器可以有选择地忽略某些对象或者对某些对象进行变换。

使用门户规则服务

要使用门户规则服务（Portal Rules Service），有几个步骤。首先，必须预先建立规则，然后把规则部署到一个正在运行的Weblogic服务器实例中。接着，规则被计算，而计算结果在返回用户之前，有可能先被过滤。最后，用户在应用程序代码里利用经过规则处理的结果。

建立规则集

规则集是符合特定模式的XML文件（详见XmlSpy的链接)。规则“语言”实际就是Portal表达软件包的使用，可以扩充以满足规则引擎的额外要求。

规则集的扩展名为.rls，由以下几部分构成：

·             标签 <cr:rule-set> 包含了对文档（规则集）中所使用的模式的所有引用

·             一个或多个规则，由标签 <cr:rule> 定义

·             在每个规则里，用标签 <cr:condition>定义一个或多个测试条件，用标签 <cr:actions>定义一个或多个动作

测试条件是输入对象可以满足的测试；操作(action)一般是当规则条件被满足，规则被触发时，被实例化进内存中的对象。

实际上，建立规则集的最简单方法就是从一个现有的规则集开始，并修改现有的规则集。本文的例子里有几个规则集。可以使用XML Spy这样的工具手动建立规则集。规则和表达模式在p13n_ejb.jar文件里可以找到，位置是在 lib/schema目录下。

部署规则集

每个应用程序都与自己的数据实例相关联，这些数据的存储于应用程序的 META-INF/data 文件夹中。这个文件夹下面以及该文夹件的子文件夹里的任何数据，都能通过数据同步机制进行部署。作为最佳实践，我喜欢在保存规则集的文件夹下面建立一个子文件夹“rulesets”。

规则服务使用门户数据同步机制（Portal Data Sync）来把规则集部署到运行服务器。也就是说，用户只需把规则集保存在数据同步文件夹里，规则集就会自动被部署。如果文件夹里已经存在相同的规则集，那么数据同步机制会自动检查规则集的变化，规则服务数据库会自动刷新规则集的实例。规则集文件必须以.rls为扩展名，这样规则管理器才会认识它。

例如，如果我的应用程序是 drtApp，我把我的规则集放在drtApp/META-INF/data/rulesets文件夹里。现在，当服务器首次启动，规则服务第一次调用时，这个文件夹里的所有规则集都会被数据同步机制加载，供规则引擎使用。

那么，如果想在规则控件或EJB API里调用规则集的URI，那么所使用的文件名应当相对于 META-INF/data文件夹。例如，如果我把规则集 simple.rls 放在 drtApp/META-INF/data/rulesets文件夹里，就应当用 “/rulesets/simple.rls”这样的URI来引用它。

只要修改数据同步规则集文件夹的内容，数据同步机制就会重新载入规则集（规则集发生修改）或者从规则服务器删除规则集（规则集被删除）。

这意味着我们可以在服务器运行的时候调整规则，或者对解析错误进行调试。修改规则集之后，无需重新启动服务器。

规则服务组件

Portal 控件是易于使用的用于表示和执行业务逻辑的组件。这些组件都是图形控件，可以在WebLogic Workshop里使用。RulesExecutorControl就是这样一个控件，它可以执行已经命名的规则和规则集，在规则集计算之后还可以对计算结果进行过滤。

在使用这个控件之前，需要配置控件的几个属性：

·             包含规则的规则集的 URI。如前所述，URI要相对于应用程序的META-INF/data 文件夹。

·             用于计算的规则的名称。如果没有指定规则，那么规则集中的全部规则都会被计算。

·             可选的过滤器参数，详见下文。

在dev2dev上还有另一篇有关规则的文章，说明了如何使用这个控件动态引导页面流。 这个RulesExecutorControl控件实际上封装了RulesManager EJB，p13n_ejb.jar 文件中的任何Portal应用程序都可以使用这个EJB，并可用于直接调用规则服务(不过，最好是用控件进行调用)。有关RulesManager EJB API的调用说明，详见Portal的在线文档javadocs。

对规则进行计算

对规则集进行计算，可以考虑通过以下步骤：

·             Portal的规则引擎初始化，建立“内存”。

·             规则控件指明要使用哪个规则集，并且还可以进一步指定要对哪个规则进行计算 (默认是全部规则都计算)，以及是否过滤计算结果。所有这些参数都可以通过Rules控件进行配置，并传递给规则引擎，用于对规则进行计算。

·             开发人员建立对象，并把对象加入“内存”。示例对象可能是用户的档案、Request对象等。 这些参数会作为变量传递给规则控件的evaluate() 方法

·             通过RulesExecutorControl调用规则引擎。

·             规则引擎根据输入的规则集和输入的对象创建Rete Network。

·             规则引擎反复触发，根据输入对象的状态和规则条件执行规则。

·             当规则引擎遇到没有规则可以触发的时候，计算结果和所有的原始输入对象一起存在于内存里。

·             由于输入对象也是结果的一部分，因此可以根据一个类对结果进行过滤。例如，可以指定只返回类 com.bea.p13n.usermgmt.profile.ProfileWrapper的结果。下面一节的例子显示了如何建立和使用过滤器。

过滤规则

假如现在已经有了一个规则，就像前面例子里的简单规则一样。应用程序的目标是输入用户的档案，检查用户的某些属性，根据这些属性来触发一些规则，如果规则的计算结果为真，则初始化一个新的Integer对象。然后在页面流（page flow））里，可以使用Integer值进行决策。

在规则引擎已经触发完所有规则并完成所有预定工作结束之后，会返回一个 Iterator对象，它描述了仍然保留在内存里的所有对象。可能没有必要关注内存里有哪些对象，例如用户档案、Request对象等，真正想从结果中得到的，可能只是Integer对象。所以我们需要对结果进行过滤。

对象过滤器是一个参数，可以在计算规则时传递给规则。如果使用规则控件，参数在控件的属性里指定。如果直接使用控制管理器 EJB ，参数在 evaluate() 方法的参数中指定。

可以用任何Java类或类集来构造 ObjectFilter，在本例里，我们直接使用RulesManager EJB，像下面这样建立过滤器：

有关 com.bea.p13n.rules.manager.RuleResultClassFilter 的详细介绍，请参考javadoc。

如果正在使用RulesExecutorControl，那么是在该控件的属性里指定要过滤的类，如下所示：

使用计算结果

现在，假设你已经建立了上面的简单规则，用RulesExecutorControl计算了规则，而且还过滤了计算结果。下面是在一个代码片段里它实际的使用情况：

结束语

Portal规则服务为Portal应用程序提供了访问实时商业智能的方法。可以通过RulesManager EJB直接调用规则服务，也可以使用RulesExecutorControl调用。在Portal中，通过EJB调用规则服务已经可用了，但是对RulesExecutorControl控件的使用需要等到Portal SP3发布，其才会得到完全的支持。不过，虽然在SP3之前不支持规则控件，但是你可以从dev2dev上直接得到它。 

BEA WebLogic Portal运行在WebLogic Server之上，并且拥有一系列的特性和服务，从而使你能够建立一个交互式的、自适应的门户网站。它的一个突出优点是提供了一些能够基于用户档案文件来配置网站的工具。例如，仅当用户档案文件符合特定要求时，你才能够获得授权，从而进入特定的门户页面，甚至是portlets，或者，能够修改门户页面提供的内容或基于用户档案文件的portlet。例如，一个用户可能需要成为某个部门的成员或是在公司中占据特定的职位才能够进入不同的内容条目或是portlet。这可以利用在BEA EBCC（E-Business Control Center）中那些以交互方式定义的的规则来实现。使用这个工具，可以很容易地把工作内容或是市场活动瞄准到特定的用户，并且不需要高深的编程知识。另一方面，作为软件开发人员，你可以享受到如下的好处：利用方便的Java API和Taglib就能够访问并且修改用户档案文件。

不幸的是，数据很少被仅仅存储在企业的一个地方，而且也很少被保存为BEA WebLogic Portal所需要的格式。

实际上，用户档案数据可能被分散地存储在很多不同的系统当中。通常，数据的一部分被存储在像SAP这样的ERP系统中、像Siebel这样的CRM系统中、LDAP目录服务中、像Oracle或 Sybase这样的关系数据库中，以及各种各样其他的地方。幸运的是，BEA Portal没有仅在它的本地数据库模式中提供用户描述的存储。它定义了名为统一用户档案文件（Unified User Profile ，UUP）的机制，使你可以创建所有的与该门户应用(portal application)紧密结合用户档案文件的应用模块。接着，你就能创建内容选取规则(content selection rule)，或是用户权限，从而利用那些已经存在并且安全地存储于企业遗留或是核心系统中的数据。

创建统一用户档案
本文将会告诉你如何建立并使用一个依赖于外部数据的UUP。我们假设现在有一个大型跨国公司的员工门户。简单地说，我们只考虑一个门户页面，它包括了一个展示公司新闻的portlet和一个展示公司国际分支机构销售数据的portlet。后者仅仅对于销售部门的员工是可见的。新闻portlet根据员工所在的部门、员工的国籍、以及员工在公司内职位的不同来显示公司新闻。有些新闻将会仅仅和软件开发人员相关，因此仅仅对于他们可见，另外一些可能仅仅对于管理人员是可见的。当然，任何信息都可以按照员工首选的语言来显示。

公司已经在不同的数据库中存储了关于员工的大多数数据。值得庆幸的是，该公司实施了面向服务的软件体系结构，所以所有的相关员工数据都能够以像清单1中定义的SOAP Web service的方式被访问。（清单1-3附后）

为了使用来自门户的Web服务中的数据，必须首先使用EBCC定义用户档案文件和相关规则。用户档案文件在"site infrastructure"选项卡中建立。按照通常的经验，你应该为每一个要访问的数据源创建至少一个用户档案文件。为了满足要求，你会想要定义两个用户档案文件。第一个是corporateProfile，如图1所示。这个配置文件稍后将会被映射成从Web服务中获得的数据。如果你检查了Web服务的WSDL，将会注意到它没有定义员工的首选语言。因此，你需要创建另外一个名为preferencesData的配置文件，它将被保存在默认的门户数据库模式中。

接下来，你需要建立一些规则(rules)，稍候它们将被应用到用户档案文件上。首先，定义为用户选取特定新闻内容的规则。你需要在EBCC的presentation选项卡中定义一个新的内容选择器。现在，可以定义内容选取规则了。

在定义这些规则时，EBCC会连接到你的门户应用，从而获取可用的内容类型及其元数据。当然，可否获取元数据取决于那些被载入到你门户模式中的内容。出于演示的目的，BEA提供了一个叫做bulk loader的工具。可以使用该工具从具有特殊注解的HTML文件中索引和装载内容。一旦检索出了元数据，你就能够借助可利用的菜单创建一个内容搜索。

图2所示的是组成内容搜索的规则。它只选取了那些符合国家、部门、职务、和用户喜好语言条件的内容条目。把规则用"ShowNews"这个名字进行保存，以便以后在新闻portlet中访问它。使用相似的方法，可以创建一个权限片断，其中包含了所有在销售部门工作的用户，我们把它叫做MemberOfSales。在保持同步的同时，这些规则已经可以在门户应用中使用了。

开发UUP
现在开始真正的软件开发工作。针对那些可以获得预期结果的规则，你需要提供能够在Web 服务和门户应用之间连接用户档案文件数据的组件。访问用户档案文件的一般结构如图3所示。在BEA WebLogic Portal中，所有对用户档案文件的访问都是通过一个名为UserManager的无状态会话bean实现的。

根据用户档案文件的类型，它授权了对适当ProfileManager EJB的访问。接着，ProfileManager EJB根据被请求的用户档案文件，授权对一个com.bea.p13n.property.EntityPropertyManager类型的无状态会话bean 的访问。这就是实际的用户档案文件访问过程（参见图3）。框架中展示了两个钩子（hook），你可以在这里插入你自己的配置文件访问。只在很少的情况下，你需要为特定的配置文件类型编写一个自定义的ProfileManager。如果你需要提供一个和默认实现功能完全不同的实现，这可以作为你的一个选择。大多数情况下，你希望提供一个自定义的EntityPropertyManager，并且为一个定义在EBCC中的，特定的用户档案文件而注册它。本文余下的部分将会专注于后面这种情况。









EBCC中定义的用户档案文件
你需要定义一个其远程接口为EntityPropertyManage类型的EJB，并且把它部署在BEA WebLogic Portal所在的EAR中，同时，把它注册到门户的用户管理工具中去。清单3展示了组成CorporateProfileManager这个EJB的所有的类。在我们的例子中，用户数据是只读的，不能被门户的配置文件管理工具所修改。在企业环境中这并不少见，这样的数据可能只有授权用户才能够编辑。

在这样的环境中，必须以非空的形式实现的EntityPropertyManager的方法是：

public Object getProperty(PropertyLocator propertyLocator,
String pSet, String pName) throws EntityNotFoundException;

public EntityPropertyCache getProperties(PropertyLocator propertyLocator)
throws EntityNotFoundException;

对于其他方法，你应该抛出一个如上面代码中所示的UnsupportedOperation异常。值的注意的是，把用户档案文件的检索结果缓冲一定的时间是一种很好的做法。同样，getProperty()方法通常把任务委托给getProperties() 方法。该方法一次性地为一个特定用户检索出用户档案数据，并且缓冲它们以便后面使用。为用户档案文件提供数据的Web服务由BEA WebLogic Workshop来创建。CorporateProfileManager使用由BEA WebLogic Workshop创建的stubs来访问隐藏了所有实现细节的服务。

EJB被打包在自己的jar文件中，并且被部署在门户所在的企业应用中。最后，你需要通知ProfileManager EJB：它应该委托新部署的CorporateProfileManager EJB，为所有向用户档案文件"corporateProfile"发出的请求提供服务，这可以通过在ProfileManager的配置描述文件中把用户档案文件映射到EJB来实现。ProfileManager位于usermgt.jar中。

你可以使用WebLogic控制台来编辑配置描述文件，或者采用从jar中提取文件，修改它们，然后重新打包成jar的方法。如同下面展示的那样，你需要添加一个新的封闭条目来映射CorporateProfileManager的配置文件。条目的名称必须符合PropertyMapping/<profileName>的格式，其中<profileName>是指EBCC中定义的用户档案文件的名字。你还需要针对刚刚建立的CorporateProfileManager ejb创建一个ejb-ref（ejb描述文件）（参见清单4）。

最后，你需要编辑weblogic-ejb-jar.xml文件，把在web.xml中建立的ejb-ref-name映射为如下所示的已部署的EJB的实际JNDI名字。

<weblogic-enterprise-bean>
<ejb-name>UserProfileManager</ejb-name>
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>ejb/CorporateProfileManager</ejb-ref-name>
<jndiname>
.BEA_personalization.CorporateProfileManager
</jndi-name>
</ejb-reference-description>
</reference-descriptor>
</weblogic-enterprise-bean>

当应用了这些修改之后，你需要做的仅仅是重新部署企业应用。现在你的用户档案文件已经可以使用了。

运行状态的UUP
现在，我们来看看新的用户档案文件如何运行。假设有两个员工：Sima是在德国法兰克福工作的开发部经理；Teresa是在英国伦敦工作的销售部职员。

Sima的首选语言是德语，Teresa的首选语言却是英语。

为了测试配置文件是否按照你所要求的那样被访问，你可以使用WebLogic Portal的management WebApp。选择user management->users，然后选择一个用户。为这个用户选择corporateProfile作为察看属性。如果一切工作正常，你应该看到从Web服务中检索出来的实际的数值。（参考图4）现在，使用EBCC portlet创建向导创建并且部署你自己的portlets。利用在EBCC中定义好的内容选择器来选择要显示给用户的合适的新闻内容。清单3显示了一个简单的新闻portlet。实际执行内容选择器的代码如下所示：

<pz:contentSelector rule="ShowNews"
contentHome="<%=ContentHelper.DEF_DOCUMENT_MANAGER_HOME %>"
id="news"/>

需要注意的是我们所使用的实际规则既访问了preferencesData，也访问了corporateProfile，从而获取数据。实际上，我们可以把不同来源的数据混合到一起，从中选择内容或是建立用户访问权限。在portalTools Web application中，你需要使portlet可用并且可见。同样，你需要在销售portlet上应用管理权限片断。（参见图5）

图6a和6b分别展示了用户Teresa和Sima的门户显示。





正如期望的那样，既然Teresa工作在销售部门，她就看到销售数据的portlet。她的所有新闻条目都是按照她配置文件设定的那样，用英文显示。Sima看不到销售数据，因为她不是销售部门的一员，而且她不具备察看销售portlet的权限。她的新闻条目都是德语的，她还可以看到许多不同的新闻条目，因为她在开发部门工作。

小结
到目前为止，你已经掌握并且理解了在BEA WebLogic Portal中建立UUP的基本机制。通过部署和注册适当的EntityPropertyManager EJB你可以集成任何数目的遗留数据源，基于此，你能够创建用户档案文件。而且你还能--在你所能做的其他事情中--在你的门户应用中提供个性化的内容和细粒度的访问控制。

当然，在实际的项目中还必须对实际的EJB设计进行其他重要的考虑。例如，你的后端数据源不像你所要求的那样可用并且可靠。在这种情况下，你可能会创建一个本地持久缓冲。这个缓冲可能存在的时间非常短而且可能仅仅作为备用数据，以防真正提供数据的系统掉线。

你还可以使用BEA 缓冲库（BEA caching library）为缓冲EntityPropertyManager中的数据提供更好的控制。
考虑到未来的开发，你还应该关注一下BEA提供的另外一个工具。WebLogic Liquid Data是专门为集成来自不同数据源的数据而设计的。插入到WebLogic Portal之后，WebLogic Liquid Data将会使实施用户档案文件的过程更加容易和迅速。

清单 1: web服务 WSDL

<?xml version="1.0" encoding="utf-8"?>
<!-- -info:link source="UserInfoService.jws" autogen="true" -->

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:conv="http://www.openuri.org/2002/04/soap/conversation/"
xmlns:cw="http://www.openuri.org/2002/04/wsdl/conversation/"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:jms="http://www.openuri.org/2002/04/wsdl/jms/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:s0="http://www.openuri.org/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xm="http://www.bea.com/2002/04/xmlmap/"
targetNamespace="http://www.openuri.org/" >
<types>
<s:schema attributeFormDefault="qualified" elementFormDefault="qualified"
targetNamespace="http://www.openuri.org/">
<s:element name="getUserInfo">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="userId" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="getUserInfoResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="getUserInfoResult" type="s0:UserInfo" />
</s:sequence>
</s:complexType>
</s:element>
<s:complexType name="UserInfo">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="address" type="s0:Address" />
<s:element minOccurs="0" maxOccurs="1" name="person" type="s0:Person" />
<s:element minOccurs="0" maxOccurs="1" name="orgaInfo" type="s0:OrgaInfo" />
</s:sequence>
</s:complexType>
<s:complexType name="Address">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="street" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="city" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="postcode" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="country" type="s:string" />
</s:sequence>
</s:complexType>
<s:complexType name="Person">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="firstNames" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="lastNames" type="s:string" />
</s:sequence>
</s:complexType>
<s:complexType name="OrgaInfo">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="department" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="function" type="s:string" />
</s:sequence>
</s:complexType>
<s:element nillable="true" name="UserInfo" type="s0:UserInfo" />
</s:schema>
</types>
<message name="getUserInfoSoapIn">
<part name="parameters" element="s0:getUserInfo" />
</message>
<message name="getUserInfoSoapOut">
<part name="parameters" element="s0:getUserInfoResponse" />
</message>
<portType name="UserInfoServiceSoap">
<operation name="getUserInfo">
<input message="s0:getUserInfoSoapIn" />
<output message="s0:getUserInfoSoapOut" />
</operation>
</portType>
<binding name="UserInfoServiceSoap" type="s0:UserInfoServiceSoap">
<soap:binding transport=
"http://schemas.xmlsoap.org/soap/http" style="document"/>
<operation name="getUserInfo">
<soap:operation soapAction=
"http://www.openuri.org/getUserInfo" style="document"/>
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
<service name="UserInfoService">
<port name="UserInfoServiceSoap" binding="s0:UserInfoServiceSoap">
<soap:address location=
"http://C800-001:7501/userInfoService/UserInfoService.jws"/>
</port>
</service>
</definitions>

清单 2: CorporateProfileManager

/**
* The remote interface of the ejb that will access the corporateProfile
*/
package com.iternum.uup;

public interface CorporateProfileManager extends com.bea.p13n.property.EntityPropertyManager {

}

/**
* Create the implementation of the CorporateProfileManager. This class
* does not support dynamic properties nor any write operations and will
* throw UnsupportedOperationException accordingly
* iternum GmbH (bankkar)
*/
package com.iternum.uup;

import com.bea.p13n.property.*;
import com.bea.p13n.property.internal.PropertyMapKeyImpl;
import com.bea.p13n.property.internal.EntityPropertyCacheImpl;

import weblogic.jws.proxies.*;
import java.rmi.RemoteException;
import java.io.IOException;
import java.util.HashMap;

import org.openuri.www.UserInfo;

import javax.ejb.EJBException;
import javax.ejb.SessionContext;
import javax.ejb.CreateException;

public class CorporateProfileManagerImpl implements javax.ejb.SessionBean {

private HashMap caches = new HashMap();
private SessionContext context;

public CorporateProfileManagerImpl() {
}

/**
*
* propertyLocator
* pSet
* pName
*
* EntityNotFoundException
*/
public Object getProperty(PropertyLocator propertyLocator, String pSet, String pName)
throws EntityNotFoundException {
EntityPropertyCache cache = getProperties(propertyLocator);
return cache.get(new PropertyMapKeyImpl(pSet,pName));
}

/**
* TODO: Use application wide caching
* Returns all properties that are available for a given property locator.
* Caches the properties locally.
* propertyLocator
*
* EntityNotFoundException
*/
public EntityPropertyCache getProperties(PropertyLocator propertyLocator)
throws EntityNotFoundException {
EntityPropertyCache cache = (EntityPropertyCache)caches.get(propertyLocator.getPkString());
if (cache != null) {
return cache;
}
cache = new EntityPropertyCacheImpl();

PropertyMapKey nextKey = null;

String pSet = "corporateProfile";
try {
String userName = propertyLocator.getPkString();
UserInfoService service = new UserInfoService_Impl();
UserInfo info = service.getUserInfoServiceSoap().getUserInfo(userName);
cache.put(new PropertyMapKeyImpl(pSet,"firstnames"),info.getPerson().getFirstNames());
cache.put(new PropertyMapKeyImpl(pSet,"lastname"),info.getPerson().getLastNames());
cache.put(new PropertyMapKeyImpl(pSet,"street"),info.getAddress().getStreet());
cache.put(new PropertyMapKeyImpl(pSet,"postcode"),info.getAddress().getPostcode());
cache.put(new PropertyMapKeyImpl(pSet,"city"),info.getAddress().getCity());
cache.put(new PropertyMapKeyImpl(pSet,"country"),info.getAddress().getCountry());
cache.put(new PropertyMapKeyImpl(pSet,"division"),info.getOrgaInfo().getDepartment());
cache.put(new PropertyMapKeyImpl(pSet,"function"),info.getOrgaInfo().getFunction());
caches.put(propertyLocator.getPkString(),cache);
} catch (IOException e) {
e.printStackTrace();
//To change body of catch statement use Options | File Templates.
}
return cache;
}

public void removeProperties(PropertyLocator propertyLocator)
throws EntityNotFoundException {
throw new UnsupportedOperationException("Read only profile");
}
public Object removeProperty(PropertyLocator propertyLocator, String s, String s1)
throws EntityNotFoundException {
throw new UnsupportedOperationException("Read only profile");
}

public void setProperty(PropertyLocator propertyLocator, String s, String s1, Object o)
throws PropertyValidationException, EntityNotFoundException {
throw new UnsupportedOperationException("Read only profile");
}

public void removeEntity(PropertyLocator propertyLocator)
throws EntityNotFoundException {
throw new UnsupportedOperationException("Read only profile");
}

public long createUniqueId(String s, String s1)
throws ConfigurableEntityCreateException {
throw new UnsupportedOperationException("Read only profile");
}

/**
* Not supported
* EntityNotFoundException
*/
public String[] getDynamicProperties(PropertyLocator propertyLocator, String s)
throws EntityNotFoundException {
throw new UnsupportedOperationException();
}

/**
* Not supported
* EntityNotFoundException
*/
public long getUniqueId(String s, String s1) throws EntityNotFoundException {
throw new UnsupportedOperationException();
}

/**
* Not supported
* EntityNotFoundException
*/
public PropertyLocator getPropertyLocator(long l) throws EntityNotFoundException {
throw new UnsupportedOperationException();
}

/**
* Not supported
* EntityNotFoundException
*/
public String getHomeName(long l) throws EntityNotFoundException {
throw new UnsupportedOperationException();
}

/**
* Not supported
*/
public String[] getEntityNames(String s) throws RemoteException {
throw new UnsupportedOperationException();
}

public void setSessionContext(SessionContext sessionContext) throws EJBException {
context = sessionContext;
}

public void ejbRemove() throws EJBException {
}

public void ejbActivate() throws EJBException {
}

public void ejbPassivate() throws EJBException {
}

public void ejbCreate() throws CreateException {
}
}

/**
* Home interface for the coporate profile manager.
We just need a default create method here
* iternum GmbH (bankkar)
* : CorporateProfileManagerHome.java,v 1.1 2003/01/15 16:54:17 bankkar Exp 505BR>*/
package com.iternum.uup;

import javax.ejb.CreateException;
import java.rmi.RemoteException;

public interface CorporateProfileManagerHome extends javax.ejb.EJBHome {

public CorporateProfileManager create() throws CreateException, RemoteException;

}

清单 3: news portlet代码段

<%@ page import="com.bea.p13n.content.ContentHelper"%>
<%@ taglib uri="es.tld" prefix="es" %>
<%@ taglib uri="pz.tld" prefix="pz" %>
<%@ taglib uri="um.tld" prefix="um" %>
<%@ taglib uri="cm.tld" prefix="cm" %>

<h3>iternum latest news</h3>

<pz:contentSelector rule="ShowNews"
contentHome="<%=ContentHelper.DEF_DOCUMENT_MANAGER_HOME %>"
id="news"/>
<es:forEachInArray array="<%=news%>" id="newsItem"
type="com.bea.p13n.content.Content">
<p><cm:printDoc id="newsItem"/></p>
</es:forEachInArray>

清单 4: ejb-ref that references the Corporate Profile Manager EJB<session>

<ejb-name>UserProfileManager</ejb-name>
...
<env-entry>
<env-entry-name>PropertyMapping/corporateProfile</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>CorporateProfileManager</env-entry-value>
</env-entry>
...
<ejb-ref>
<description>ejb/CorporateProfileManager</description>
<ejb-ref-name>ejb/CorporateProfileManager</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.iternum.uup.CorporateProfileManagerHome</home>
<remote>com.iternum.uup.CorporateProfileManager</remote>
<ejb-link>CorporateProfileManager</ejb-link>
</ejb-ref>
...
</session>

Kunal Mittal
门户/J2EE 架构设计师和咨询顾问
2005 年 5 月 09 日

Beehive 是一个新的 Apache 项目，用于简化 Java 2 Platform, Enterprise Edition（J2EE）以及 Web 服务编程。本文将介绍如何使用 Beehive，并概要介绍 Pollinate，这是一个用于创建 Beehive 应用程序的 Eclipse 插件。

BEA Systems Inc. 和 Apache 在 2004 年 5 月 25 日宣布了 Beehive 项目的诞生。这个项目着重用于简化 Java 2 Platform, Enterprise Edition（J2EE）和 Web 服务编程，它使用了注释（annotation）的概念，这种技术很快就会成为 Java 技术的一部分。面向服务的架构（SOA）开发也是这个项目的一个重点。

Beehive 是按照 Apache License V2.0 许可协议进行发布的，BEA 对此项目进行了广泛的支持。现在，大约有一半的 Beehive 代码提交者都是 BEA 公司的雇员，这清楚地表明社区中还有其他一些人正在对这个项目贡献着力量。

Apache Beehive 项目创建是为了支持以下功能：

• Java Page Flow （JPF）技术，也称为（NetUI）
• 控件
• 基于 Java Specification Request（JSR）181 的 Web 服务

最终，这些技术将一起汇集到 Model-ViewController（MVC）编程模型中，如图 1 所示。JPF 技术形成控件器层。NetUI 标记库则会参与视图层。模型层是使用 Java 控件构建的。

图 1. MVC 模型和 Apache Beehive 技术

Pollinate 插件 NetUI、控件和 Web 服务技术一起用于简化 J2EE 和 SOA 的开发。另外还有一个名为 Pollinate 的 Eclipse 插件项目也在进展之中。这个项目可以允许开发人员使用 Eclipse 来构建 Apache Beehive 应用程序。我相信其他 IDE，例如 IntelliJ 和 JBuilder 很快也会开始支持 Apache Beehive。

下面让我们更详细地来了解一下 Apache Beehive 中使用的各种技术。

NetUI 还是 JPF
如果您曾经使用过 BEA WebLogic Workshop V8.1，就可能使用过 JPF 技术，它是直接在 Struts 之上构建的。正如您可能了解的一样，Struts 是目前市场中采用最为广泛的一种 MVC 框架。因此，如果 JPF 是在 Struts 之上构建的，那么为什么不使用 Struts 呢？

JPF 充分发挥了 Structs 的关键功能，但却省略了 Struts 所需要的很多繁琐工作（指对部署配置文件的管理，例如 struts-config.xml 文件）。在 BEA 的 Page Flows 最初版本中，引入了一种由 BEA WebLogic Workshop 自动生成和维护的声明性编程语言。与之相反，Apache Beehive 版本的 Page Flows 使用 JSR 175 来定义自己的元数据。JSR 175 是一种元数据规范，它可以让您降低 J2EE 的编码量。

JPF 技术中也提供了一组标签库，名为 NetUI。在典型的 MVC 设计模式中，JPF 用来构成控制器层。NetUI 标签库可以在表示层中提供帮助。实际上，您可以让一个 Web 应用程序同时使用 Struts 和 JPF。

清单 1 给出了一个简单的 JPF 控制器，它会打印 HelloWorld。

import org.apache.beehive.netui.pageflow.PageFlowController;
import org.apache.beehive.netui.pageflow.annotations.Jpf;
import org.apache.beehive.netui.pageflow.Forward;

@Jpf.Controller (
    simpleActions= {
       @Jpf.SimpleAction (name="cancel", path="begin.do")
   }
)

public class HelloWorldController extends PageFlowController {


   @Jpf.Action (
       forwards= {
           @Jpf.Forward (name="success", path="helloworld.jsp")
       }
   )
 
   public Forward begin() {
      return new Forward("success");
   }
}

注意，这里使用了注释。我首先使用 @Jpf.Controller 注释来定义这个类是一个 JPF 控制器。@Jpf.SimpleAction 注释定义了这个控制器中的操作。这些注释与 Struts 中操作（action）的概念类似。@Jpf.Action 注释定义了操作本身。@Jpf.Forward 注释定义了在流程的下一个阶段会发生什么。这个注释与 Struts 配置文件中信息的概念类似。

前向注释（forward annotation）中引用的 HelloWorld JSP 文件在本文中并没有介绍。对于这个例子来说，它可以是任何 JSP 文件，只要包含一行向屏幕上打印 HelloWorld 信息的代码即可。

NetUI 技术还包括 3 个标签库，它们的基本功能是简化 JSP 文件的开发，并在视图层和控制器层之间提供自动的数据绑定。这些标签都可以支持 JavaScript，因此您可以像标准的 HTML 标签（例如 input 和 select）一样使用它们。这些标签库包括：

NetUI

这个标签库包括与 struts-html 标签类似的一些标签。

NetUI-data

NetUI-data 标签库用来将表单和控制器中的数据绑定到 JSP 文件中。它可以让您快速显示数据列表，例如搜索结果。

NetUI-template

您可以在 JSP 文件中使用 NetUI-template 标签库来创建子节（或模板）。

有关 NetUI 标签库的更多信息，请参阅 参考资料。

控件
控件是一种非常有趣的技术。控件对基于 SOA 的开发提供了一层很好的抽象和封装。控件是一些封装在 EJB 或消息驱动 bean 中的业务逻辑组件。它们为所有的资源集（数据库、外部系统，等等）提供了一组通用的接口。您可以将控件拖放到 Java 应用程序或 Web 服务中，从而为应用程序或 Web 服务提供这种功能。这可以帮助加速开发过程。

与 Apache Beehive 的其他部分类似，控件也大量使用了 JSR 175 注释。控件通过提供一种允许访问各种类型的资源的统一客户机模型，从而降低了作为一个 J2EE 资源的客户机的复杂性和学习曲线。

清单 2 给出了一个 HelloWorld Java 控件。

import org.apache.beehive.controls.api.bean.*;
@ControlInterface
public interface HelloWorld {
    String sayHelloWorld ();
}

在这个例子中，我定义了一个简单的 ControlInterface。如果您去除 @ControlInterface 注释，这就是一个简单的 Java 接口类。清单 3 显示了 HelloWorld 控件接口的控件实现。

import org.apache.beehive.controls.api.bean.*;

@ControlImplementation
public class HelloImpl implements HelloWorld {
    public String sayHelloWorld ()  {
        return "hello!";
    }
}

这个清单中的代码非常简单，不是吗？现在，让我们使用这个例子构建一个 Web 服务。

使用 JSR 181 的 Web 服务
JSR 181 是基于 JSR 171 注释标准的 Web 服务所使用的一种元数据标准。Apache Beehive 使用 JSR 181 来定义一组注释，您可以使用它们将任何 Java 类暴露为 Web 服务。Beehive Web 服务开发背后的思想是开发者编写一个简单的 Java 类，然后将其功能暴露为一个 Web 服务。

清单 4 给出了一个简单的 HelloWorld Web 服务。

import javax.jws.WebService;
import javax.jws.WebMethod;

@WebService(
    targetNamespace="targetNamespace = 
           http://www.openuri.org/my/web/service/wsdl"
)

public class HelloWorld {
    @WebMethod
    public String sayHelloWorld() {        
        return "Hello world!";
    }
}

在这个清单中，如果您删除黑体表示的元素，那么它就是一个简单的 Java 类。使用 @WebService 和 @WebMethod 注释，我们已经将这个简单的 Java 类暴露为一个 Web 服务了。

现在，使用 Apache Beehive 技术，您就可以更好地理解如何开始在您的项目中使用 Apache Beehive 了。

使用 Eclipse 来构建 Beehive 应用程序
Eclipse Pollinate 项目是目前惟一支持 Apache Beehive 开发的 IDE 环境。这种限制随着将来 Apache Beehive 的不断发展而会不断变化。基本上来说，Pollinate 是 Eclipse 的一个可以支持 Beehive 框架的插件。Eclipse IDE 和 Pollinate 与一个 Apache Tomcat 之类的服务器的组合可以构造一个完美的环境，从而简单而快速地开发 Beehive 应用程序。

开始使用 Pollinate
如果您的机器上没有安装 Eclipse，那么请首先下载并安装它。要在 Eclipse 中安装 Pollinate，请启动 Eclipse IDE，然后：

1. 选择 Help > Software Updates > Find and Install。
2. 在 Install/Update 窗口中，选择 Search for new features to install。
3. 在下一个窗口中，单击 New Remote Site。
4. 在 New Update Site 窗口中，输入 Pollinate 和 URL http://download.eclipse.org/technology/pollinate/update-site。
5. 展开树形结构中的 Pollinate，然后选中 Integration Builds 复选框。
6. 在下一个窗口中，选择 Eclipse Pollinate Tools 复选框，并完成安装过程。

成功安装 Pollinate 插件之后，您可以创建一个新的 Beehive 项目。要创建一个这种项目，请在 Eclipse 中选择 File > New > Other，启动 New Wizard，然后选择 Pollinate > Web Application。

当然，您还需要下载并安装 Apache Beehive。

结束语
Apache Beehive 项目似乎正在蓬勃发展。BEA Systems 公司做了一个非常聪明的决定，将这部分核心技术在开源社区中公开发布，这样可以促进这些技术的成熟并扩大采用范围。最初，这些技术只在 BEA WebLogic 平台上获得了支持。然而，在开源社区公开发布之后，现在您就应该可以在 IBM® WebSphere® Application Server 以及其他应用服务器上利用这些技术了。您还可以使用基于 Eclipse 的 IBM Rational® 工具（例如 IBM Rational Software Architect 和 IBM Rational Software Modeler）来设计并开发 Beehive 应用程序。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• Getting started with the Eclipse Platform（developerWorks，2002 年 9 月）介绍了 Eclipse 的历史和概述信息，包括如何安装 Eclipse 及插件的详细步骤。
  
  
• 下载并学习有关 Apache Beehive 的更多知识。
  
  
• 要学习更多有关 NetUI 和 JPF 的知识，请参阅 Page Flow Overview。
  
  
• 要阅读更多有关控件的内容，请参阅 Controls Overview。
  
  
• 您可以在 Java Community Process 上阅读 JSR 181 Web 服务元数据规范，以及 JSR 175 规范。
  
  
• Apache Wiki 是一个很好的交换有关 Beehive 信息的地方。
  
  
• 有关 Beehive 的更多信息，请访问 BEA Systems 公司的 Dev2Dev。
  
  
• 获取更多有关 Eclipse Pollinate 项目 的信息。
  
  
• 参阅我即将出版的图书：Pro Apache Beehive: With Eclipse Pollinate and SOA。
  
  
• Eclipse In Action: A Guide for Java Developers（Independent Publishers Group，2003 年）是使用 Eclipse 的 Java 开发者的一本必读物。
  
  
• 获取最新版本的 NetBeans，这是用来开发 Java 程序的一个开源的 IDE。
  
  
• 在 developerWorks Java 技术专区 中寻找更多为 Java 开发者准备的资源。
  
  
• 获取试用版的 DB2®、Lotus®、Rational、Tivoli® 和 WebSphere 产品，并在 IBM 中间件上开始构建和部署应用程序。选择免费的 Linux 或 Windows 版本的 Software Evaluation Kit (SEK)。
  
  
• 通过参与 developerWorks blogs 加入 developerWorks 社区。
  

关于作者 Kunal Mittal 是一位咨询顾问，他的特长是 Java、J2EE 和 Web 服务技术。他与别人合著了多本有关这些主题的书籍。他目前正在开发 Sony Pictures Entertainment 的门户项目，同时还在撰写一本有关 Apache Beehive 的书籍，该书将于 2005 年秋季出版。有关他的更多信息，请访问他的 Web 站点。

1．  在页面流流视图中，为什么看不到由外部页面（即不属于当前页面流目录的页面）引发的动作？

2．  在WebLogic Express上，可以部署使用Java页面流（JPF）和NetUI标签库的web应用吗？

3．  页面流何时被销毁？

4．  如何访问被嵌套页面流的父（嵌套）页面流？

5．  一个JSP页面与定义消息源的JPF文件不在同一个文件夹下，该JSP如何使用此JPF中<netui:error>元素中的消息源？

6．  Workshop 8.1支持Strut的DynaValidatorForm吗？

7．  如何为使用排序服务的网格设置初始排序？

8．  如何指定<netui:imageButton>元素中的“action”参数？

9．  在JSP中使用控件时，如何为其指定属性？

10．             为什么存在允许我们使用pageContext.getAttribute和pageContext.setAttribute的<netui:GetData>标签，却不存在类似的<netui:SetData>标签？

11．             如何将动态数据传递给<netui:methodParameter>标签？

12．             如何使第三方或特定于应用的标签库出现在IDE 选项板（Pallette）窗口中？

13．             当在netui-data:repeater中嵌套netui-data:repeater时，如何能够访问最内部repeater中的外部项的属性？

14．             有没有办法将NetUI标签中的XScript表达式绑定到jsp页面中的局部变量？

15．             JSLT与XScript之间有什么关系？

16．             NetUI的pageContext数据绑定作用域与javax.servlet.http.PageContext属性映射之间有什么关系？

17．             如何对NetUI标签库中的各种标签加以分类，以使其更好理解？

18．             页面流支持Struts Tiles吗？

19．             在页面流数据绑定作用域内，我能够使用的各种可用属性有哪些？

20．             如何从当前页面流的JSP中调用不同页面流中的动作？

问：在页面流流视图（PageFlow View）中，为什么看不到由外部页面（即不属于当前页面流目录的页面）引发的动作？

答：为了使页面流流视图（PageFlow View）看起来更加一目了然，Workshop在流视图中显示了对外部页面（不属于当前页面流目录的页面）的引用，但是没有显示任何由这些外部页面引发的动作。要查看由外部页面引发的动作，您需要在与相应页面所在的目录中打开页面流的流视图。

问：在WebLogic Express上，可以部署使用Java页面流（JPF）和NetUI标签库的web应用吗？

答：答案是肯定的，使用JPF和NetUI标签库的web应用可以被用在WebLogic Express（WLX）上。然而，您不能在WLX上使用控件，因为它们使用了EJB和/或JMS。在Service Pack 2上，页面流和NetUI标签库将能够以一种独立于平台的方式为servlet容器（而不仅仅是WebLogic服务器）上的运行时部署所用。

问：页面流何时被销毁？

答：页面流被销毁的时候是：

a.       流移动到不同的、不可嵌套的页面流时

b.       被嵌套的页面流返回到嵌套它的页面流时

c.       当会话超时并被销毁时。当前Http会话的生存期是页面流能够具有的最长生存期。

注意，这里有一点很重要，即任何被嵌套的页面流都隐藏在嵌套页面流的“栈”中，并且对于当前被嵌套的页面流来说，无需返回到嵌套它的页面流，即可转到外部页面流（从而销毁了嵌套页面流的整个栈）。

问：如何访问被嵌套页面流的父（嵌套）页面流？

答：您可以使用下列方法从被嵌套的页面流中访问嵌套页面流。

如果函数

返回null，这就意味着被嵌套的页面流是被直接调用的，而不是通过父页面流调用的。

问：一个JSP页面与定义消息源的JPF文件不在同一个文件夹下，该JSP如何使用此JPF中<netui:error>元素中的消息源？

答：如果您正在JSP中引用的消息源被定义为“test”文件夹（位于web项目的根目录下）中页面流的默认消息源，那么通过在“bundle”名称之前添加其后带有文件夹名称的“org.apache.struts.action.MESSAGE”前缀，您可以像下面这样使用<netui:error>元素：

或者

如果您已经在页面流中使用“err”键定义了消息源，如下所示：

您需要将“org.apache.struts.action.MESSAGE”字符串替换为键值，如下所示：

问：Workshop 8.1支持Struts的DynaValidatorForm吗？

答：Workshop 的8.1版本不支持Struts的DynaValidatorForm。

问：如何为使用排序服务的网格设置初始排序？

答：在版本8.1中，SortFilterService不支持设置过滤器的初始排序。您始终可以在JPF中手动创建一个排序，或者在RowSet控件上的SQL中使用静态的WHERE或ORDER BY子句。关于这些方法惟一的限制是，当为页面添加书签时，排序与过滤器不会反映在所使用的URL中。

问：如何指定<netui:imageButton>元素中的“action”参数？

答：<netui:imageButton>元素不支持“action”参数。它总是前移到与表单相关的默认动作。您可以使用<netui:imageAnchor>元素作为代替，如下所示：

问：在JSP中使用控件时，如何为其指定属性？

答：不幸的是，当前版本不支持这种行为。但存在其他两种选择：

1．  执行页面流中控件的方法，并将结果存放于request及动作表单中传递给相应的页面。

2．  使用callControl标签的控制属性中的表达式，直接绑定到一个控件，该控件在页面流中被公开为如下形式：

接下来，您可以使用页面流中控件实例上的注解。

问：为什么存在允许我们使用pageContext.getAttribute和pageContext.setAttribute的<netui:GetData>标签，却不存在类似的<netui:SetData>标签？

答：getData标签的作用是，允许JSP作者针对由于数据绑定而产生的对象书写scriptlet。我们不提供setData标签，因为我们要使程序设计模型和工具继续支持它，使其专注于在页面流中添加业务/状态维护逻辑。任何对(session|request).setAttribute的调用多半应该在一个动作(action)内完成。这可以避免页面出现副作用，并使它们更加容易维护。

问：如何将动态数据传递给<netui:methodParameter>标签？

答：我们可以使动态数据可以为<netui:methodParameter>标签所用，具体方法是从pageContext变量来设置并访问它，如下所示：

问：如何使第三方或特定于应用的标签库出现在IDE 选项板（Pallette）窗口中？

答：要在IDE中为Pallette窗口添加一个标签库，您需要：

1．  将标签库JAR添加到相关项目的WEB-INF/lib目录中。

2．  在web.xml中添加一项使其指向标签库的TLD文件，并赋予相应的URI，这使得JSP文件通过该URI引用TLD。

接着，您可以打开一个JSP，查看Insert菜单或标签选项板，以确保标签库中的标签能够显示出来。

问：当在netui-data:repeater中嵌套netui-data:repeater时，如何能够访问最内部repeater中的外部项的属性？

答：您可以访问最内部repeater中外部repeater的属性，具体方法是使用一个形如“{container.container.*}”的表达式，其中第一个容器引用当前的repeater，而第二个容器则引用其父repeater，等等。还有另外一种办法，通过使用netui-data:getData标签，您可以在页面上下文中的外部repeater中设置一个变量，并在形如{pageContext.*}的被嵌套的repeater中访问该变量。

问：有没有办法将NetUI标签中的XScript表达式绑定到jsp页面中的局部变量？

答：<netui-data:getData>标签可以用于计算XScript表达式的值，并将其放置到JSP的pageContext中。接下来就可以在scriptlet中访问pageContext中的变量。例如，

问：JSLT与XScript之间有什么关系？

答：在当前的版本中，JSTL的表达式语言（EL）与XScript之间没有任何关系。您可以在需要的时候使用JSTL标签，而脚本语言不会彼此干扰。

问：NetUI的pageContext数据绑定作用域与javax.servlet.http.PageContext属性映射之间有什么关系？

答：NetUI的pageContext数据绑定作用域只不过是javax.servlet.http.PageContext属性映射顶部的一层而已。这个上下文的定义是，它访问页面作用域内的名称/值对的映射。例如，下面这种形式是合法的：

接下来的这两种形式是完全等同的：

和

问：如何对NetUI标签库中的各种标签加以分类，以使其更好理解？

答：对NetUI标签库值的标签进行分类的基本方法是，这些标签是只读的，还是可读写的（即是否与服务器进行数据的交互）。

基于这标准，标签可以被划分为三类：

a．  只读 Read-Only

只读标签有<netui:content>和<netui:label>等等。它们从标签中的“value”属性中读取数据，但不会将数据发回给服务器。

b．  读写单值 Read-Write Single Value

这一类的标签有<netui:textbox>、<netui:textarea>、<netui:checkbox>等等。这些标签需要了解两件事情：

l         在JSP呈现时，在何处获取数据片断。

l         在请求提交时，将数据片断放置到何处。

“数据片断”即为“dataSource”属性的值。请注意，这与javax.sql.Datasource对象没有任何关系。

c．  读写多值 Read-Write multiple value

这一类标签包括<netui:checkBoxGroup>、<netui:select>等等，它们不过是上面一类标签的多值版本罢了。它们同样需要了解从何处获取各种选项，以便从服务器读取并显示给用户。它们可以从“optionsDataSource”属性中获得。“dataSource”属性被用于引用将被写回到服务器上的数据。

问：页面流支持Struts Tiles吗？

答：在当前的版本中，页面流不支持下面这种做法，即通过在页面流中使用Struts-merge功能以求在页面流中使用Struts Tiles。这是因为Tiles要求使用它自己的RequestProcessor，而这会干扰页面流RequestProcessor。然而，我们的确支持Tiles模块与页面流在同一个Web项目中共存与交互。

问：在页面流数据绑定作用域内，我能够使用的各种可用属性有哪些？

答：在页面流数据绑定作用域内，可用的属性包括任何公共字段，以及任何开发人员在特定页面流中定义的公共JavaBean属性。例如，下面的页面流定义了可以与标签属性中的“{pageFlow.name}”绑定的“name”属性。

问：如何从当前页面流的JSP中调用不同页面流中的动作？

答：要从当前页面流的JSP中调用不同页面流中的动作，您可以使用<netui:anchor>标签中的“href”属性。（注意，您不能使用“action”属性，因为它只能用于调用当前页面流中的动作）。您可以构造遵循模式的URI。

例如：.,

表达式语言
表达式语言使得Workshop开发人员能够使用一种简单的语法在JSP页面中引用业务对象的数据。通常，一个表达式引用业务对象上的一个或一系列属性，从而可以唯一标识JSP标签所绑定的数据。在以上例子中，表达式{request.customer.name}引用Customer JavaBean中的name 属性，保存在request中的该JavaBean被称作"customer"。
在JSP标签属性中，表达式分别以'{' 和'}'作为开始和结束标记。标签探测一个属性是否是表达式、或者其中是否包含表达式，从而对属性进行求值。
一个表达式含有两个独立的部分--数据绑定上下文：在其中进行表达式求值；属性：它是表达式求值返回的结果。在表达式{request.customer.name}中， request是绑定上下文，它引用JSP页面request的属性映射。表达式剩下的部分用来引用唯一的对象属性。"customer"标识符用来在request的属性映射中查找相关对象，name标识符用来获取Customer 对象上的JavaBean 属性name。从功能上讲，该表达式等同于以下语句：

同样是引用相同的数据，表达式语法更为简单。
除了request 上下文，还可以在其它数据绑定上下文中求值表达式，这些上下文用来访问Web应用和页面流环境的不同部分。绑定上下文还可以引用其它资源，比如通过url 或 bundle 上下文，它可以分别引用URL参数或资源包中的国际化字符串。完整的上下文及其引用对象/资源的列表如下：

现在进一步讨论上表中提到的一些上下文。
同样是使用表达式，仍然存在多种不同方法来引用同一对象的同一属性。例如，在我们的例子中，以下几个表达式都是等价的：

而且，表达式既可以访问字段，也可以访问属性，这些属性返回任意基本类型或Java Object类型，也可以返回它们的数组、列表和映射类型。一般说来，属性命名遵循JavaBean属性的setter和getter方法命名规范。关于暴露、命名、引用数据绑定对象属性的特殊规则将在下面进行讨论。
注意：对象的值既可以是只读的也可以是可读/写的；对象对应的值的暴露方式决定了它对于表达式仅是只读的，还是当Web浏览器向服务器提交数据时该值是可更新的。

访问属性
为了识别类暴露的可绑定数据属性，表达式语言采用了JavaBean命名规范。符合以下条件的方法可以暴露一个只读属性：

可以使用表达式来引用数据绑定上下文中符合以上条件的任意方法。JavaBean属性的名称被包含在表达式中。例如，类中定义了一个属性：

在表达式中它被引用为：

前提是一个Customer 对象被指定为“customer”并可以从request中得到。

在本例中，方法 getName 对应名为name的JavaBean属性；这是通过去掉“get”并将第一个字符变成小写之后得到的。一个例外是如果“get”之后的头两个字符都是大写的，JavaBean属性的名称将在表达式中保持不变。例如，属性：

在表达式中被引用为：

迄今为止，以上的name 和URL 属性都是只读的，因为我们没有为它们定义setter方法，该方法可以用来更新对象的属性值。一个JavaBean的setter方法需要符合以下条件：

前面两个属性的JavaBean setter如下：

访问字段

可以通过表达式访问公共字段。上面Customer类中定义的“eMail”字段就是一个例子。公共字段总是可读/写的。Customer的email地址在Web页中可以显示为：

使用常用的[index] 语法可以引用数组或列表中的条目。如果一个属性被暴露为：

那么可以通过以下表达式访问数组的第四个条目：

假定LocationInfo对象可以在request中通过关键字“locationInfo”进行访问，

如果一个属性被暴露为：

那么以下表达式将会访问列表中的第四个条目：

此类表达式求值还是略有不同。如果该表达式在一个长度仅为2的String[]上被求值，因为数组的长度小于表达式的引用长度，所以将会发生错误。如果属性是列表类型，表达式将被简单地求值为null。

使用NetUI Repeater标签集可以方便地绘制数组和列表。稍候一篇dev2dev文章将会涉及该标签集以及“container”绑定上下文。

访问映射中的元素

表达式还可以采用与访问属性相同的语法来引用映射中特定键值对应的条目。例如，如果LocationInfo 类暴露了一个含有州名缩写和州名的Map，并将其定义为带有JavaBean getter方法的可绑定数据属性：

那么，以下两个表达式都可以使用键值“CO”在映射中进行查找：

访问基本类型

采用以上任何机制暴露的数据类型可以是Java对象或基本类型。如果某个属性或字段的类型是基本类型，比如int 或 boolean ，表达式的求值结果将是基本类型的Java对象包装器。在本例中，将分别是Integer 和 Boolean。

表达式和NetUI JSP标签

在NetUI JSP标签上使用表达式、属性可以引用业务对象属性，并将数据显示在Web页面上。同一属性的显示方式取决于标签的选择。比如，绑定到NetUI label的字符串属性是只读的，而绑定到NetUI form内NetUI text box的字符串属性却是可读/写的。

目前存在三个NetUI标签库——HTML、复杂数据绑定、模板，本文不涉及后面两个。HTML标签集尽可能遵循HTML4.01规范并将自己的标签和HTML中定义的元素相互结合。例如，textBox、 checkBox、 和radioButton 标签分别显示HTML输入标签类型“text”、 “checkbox”、 和“radio”。可以在Workshop标签面板中找到这些标签。

也可以在Workshop 8.1的Insert菜单中找到这些标签。

NetUI HTML 标签进一步可以分为两类——只能显示数据的标签（或称为只读的）、能够在服务器和Web浏览器之间“往返”的标签（或称为可读/写的）。可以使用诸如netui:form 内的textBox这类标签在服务器和客户端之间传递数据。关于此类标签如何绑定数据，彼此之间也存在不同。

只读NetUI标签

只读标签使用表达式绑定属性“value”来指定在页面中绘制的数据。此类标签只是简单地通过表达式从业务对象中读取数值并在Web页面上绘制，可能还会对输出结果进行格式处理。我们已经知道netui:label 标签可以在页面上绘制表达式的值，其实它也可以绘制普通文本：

因为label标签不是到服务器的可往返标签，所以它的value属性可以是文本和表达式的组合。例如，想要显示用反斜杠分开的客户姓名和年龄，可以这样使用label：

每个表达式都将被求值，文本“/”将会混合到表达式结果中。

可读/写NetUI标签

第二组标签使用“dataSource”属性，它们比较特殊因为被“dataSource”属性引用的数据可以在Web浏览器和服务器之间往返。尽管dataSource属性可以绑定表达式，但该属性的value必须是一个纯粹的表达式。与label标签的value属性不同，dataSource属性不能混合文本和表达式，因为dataSource属性的value被用在两个地方：

采取这种方式，诸如textBox这样的标签就可以在服务器和Web浏览器之间来回传输数据。
如果在dataSource 属性中混合使用文本，属性就不是一个纯粹的表达式并将报错。因为dataSource 属性通常被用于同数据库交换数据，所以这里使用的表达式必须引用那些可以更新的数据绑定上下文，它们是actionForm、pageFlow、和 globalApp。 除此以外，所有其它绑定上下文在数据被POST到服务器时都是只读的。

一个简单例子
让我们对前面的Customer例子稍作修改并利用NetUI编写一个“Hello World”，从而形成一个实用的例子。本例中含有一个页面流simpleForm 和一个JSP。JSP定义了一个绑定到页面流中某个action的NetUI表单。当表单从浏览器中POST的时候，动作表单将被创建，提交的数据将被添加到动作表单中。接着，输入页面被刷新，刚刚在只读label中显示的信息将会显示到可编辑的文本框中。这里所说的页面流是指本文示例应用中的simpleForm。

首先我们来看看动作表单，它们负责封装那些在页面中被显示并更新的数据。该类定义了通过NetUI HTML在JSP表单标签内可编辑的属性；它暴露了唯一一个属性——message。

接着我们来看看JSP页面。这里的netui:form 标签用于引用在表单POST时将会执行的页面流动作。如果您对页面流不熟悉，请参阅参考材料部分的页面流参考手册。一般来说，从可读/写NetUI标签POST到服务器的更新必须在NetUI form 标签中进行。

JSP中有两个附加NetUI标签；其中netui:textBox 利用表达式{actionForm.message}在当前动作表单中显示message的值。最初该值以及textBox都是空的。还有一个button标签用来把表单提交到服务器。运行例子的时候，请在文本框中输入“Hello World”并按下“Submit”。

看！当表单提交到服务器时，页面流生命周期创建了接收POST数据（即本例中的message）的动作表单。因为textBox的dataSource 属性对应的表达式被映射为HTML输入标签——{actionForm.message}，所以message的值被路由到该属性上。

一旦表单填充完毕，postback 动作就会执行并在页面中重新绘制相同的表单。运行结果是：表达式{actionForm.message} 现在同时指向label和textBox 中显示的“Hello World”。在文本框中输入文本并重新提交表单可以修改该值。

技巧和经验

如何访问页面流的成员属性？

页面流可以像其它类一样暴露JavaBean属性；利用表达式和pageFlow 绑定上下文可以绑定这些属性。例如，如果一个页面流用以下方法暴露属性productName：

就可以通过以下表达式在JSP中进行数据绑定：

你还可以绑定到页面流暴露的公共字段。

应该在页面流上暴露映射吗？
在任何可以接受POST数据的数据绑定上下文中暴露Map类型都是危险的。问题在于映射可以变得很大，这就在服务上开了一个安全漏洞：因为网页可以直接POST数据到Map，这将会导致map无限变大、消耗掉可观的服务器资源。
通过类似request这样的只读数据绑定上下文来暴露Map类型要安全很多。上面的例子中，LocationInfo对象通过abbrevMap 属性实现了这点。

如果在表单上暴露一个int 类型的属性，从页面POST出去的是什么类型？

当JSP页面POST数据到服务器时，所有的数据都以字符串形式到达。应用POST数据到页面流属性或动作表单的过程中，NetUI会设法把已经POST到底层属性或字段的字符串数据转换为原有的类型。
例如，如果动作表单暴露一个类型为int、名称为 age 的属性，并且该字段可以从NetUI表单更新，类型转换工作即是把String 类型的“42”的转换成int 类型的42。如果转换失败，失败信息将会显示在运行WebLogic的命令提示窗口中。

如何显示一个数据列表或数组？

利用NetUI复杂数据绑定标签可以绘制诸如列表、数组、映射、和行集这类的数据集。这些将在接下来的dev2dev文章中讨论。

表达式求值失败会怎样？
当JSP准备绘制时，如果一个表达式求值失败了，JSP页面上将会显示一个失败信息。假定有属性绑定的例子：

如果request的属性映射中不包含名为“customer”的对象，那么绑定将会失败，因为name属性无法访问null对象。请尝试将例子改为：

这样就可以知道表达式求值是如何失败的了。

Workshop 8.1 IDE如何帮我进行数据绑定？

Workshop可以用多种方式帮助JSP作者进行数据绑定，其中最重要的一种是通过数据面板。使用数据面板可以在JSP页面中创建能够显示或更新数据的NetUI标签。

例如，在Workshop中打开JSP页面howdoi/index.jsp；在页面上，数据面板显示如下：

试着添加其它属性到页面流中并拖动它们到JSP页面中，从而生成可以显示数据的NetUI标签。

如果页面上有动作表单，它上面的属性也可以被拖动到JSP上。

结论
本文覆盖的范围很广。现在重新回顾一下，表达式语言使得NetUI JSP能够引用业务对象暴露的数据、页面流、以及数据绑定上下文暴露的其它对象和资源。表达式可以引用这些对象的属性和字段，并且NetUI HTML标签既可以用于显示数据，也可以用于从Web浏览器更新数据。

本文附带的应用程序包含多个示例，其中包括基本数据绑定规则的例子、Hello World例子、和一个创建、显示、和编辑Customer对象的复杂例子。

在以后的文章中我们还会介绍更多的内容，希望本文使您对WebLogic Workshop 8.1的从UI到数据的绑定有了初步了解。

问题

　　为什么创建 URL 是 WebLogic Portal 的核心任务 ？ 为什么 portlet 不能像在 HTML/JSP 页面中创建 URL 那样在以下示例代码中创建 URL ？

　　Click <a href="next.jsp">here</a> to continue.

　　当用户点击与此类似的链接时 ， 下面的某种情况将发生 ：

• 用户将看到未经门户页面聚合的 next.jsp 内容。

• 用户将看到错误页面，带有可怕的异常堆栈跟踪。

• 如果门户调用 portlet 使用的是 WSRP ，但是用户不具有与 WSRP Producer 直接交互的权限，则该用户的浏览器上将显示一个 DNS 或安全性错误。

　　要避免这些情况的发生 ， portlet 必须要求 WebLogic Portal 创建 URL 。为什么 portlet 将此任务委派给 WebLogic Portal ？ 原因如下 ： 

提示 ：在创建 portlet 时 ， 不要假定关于 URL 结构的任何事情。实际结构不仅可以由部署在 portlet 的 Web 应用程序中的模板确定，而且也可以由客户确定，比如 WSRP 。

• 门户是访问 portlet 的网关 —— 当用户与 portlet 交互（即提交表单或点击链接）时，门户接收用户请求，查找负责处理该请求的 portlet ，然后调用 portlet 。门户还可提供附加服务，如个性化、权利等。因此， portlet 创建的链接必须指向门户，而不是指向 portlet 的 JSP 、 servlet 或页面流。

• Portlet 从门户中去耦 ——Portlet 是可重用单元，可以将其聚合到多个门户和桌面。因此， Portlet 不能对门户页面的 URL 假定太多。聚合 portlet 的门户可以位于： (a) 本地，在同一 Web 应用程序中， (b) 在同一服务器上的不同 Web 应用程序中，或者 (c) 物理远程位置。在 (b) 和 (c) 两种情况下，门户可以使用 WSRP 在页面中聚合 portlet 。实际上，可以同时将同一 portlet 聚合到这三种类型的门户页面中。

• Portlet 不知道部署 —— 更重要的是， portlet 对于如何部署它们无法假定太多。部署细节包括代理服务器、域名称、端口，等等。 Portlet 对这些无法做出任何假定 。

　　当您将 URL 的创建委托给 WebLogic Portal 时 ， 它将对 portlet 屏蔽门户页面 URL 、域名称、代理服务器等。门户管理员和部署人员可以控制细节，无需破坏 portlet 中的任何 URL 。

　　如果您非常想知道上述链接的创建方式（假定您要在简单 JSP portlet 中创建这一链接），下面就是一个例子：

　　Click <a href="<render:jspContentUrl contentUri="next.jsp"/>">here</a> to continue .

　　现在 ， 我们来检查 WebLogic Portal 的 URL 的基础结构

URL模板

　　WebLogic Portal 使用称为 “ URL 模板 ” 的简短 URL 片断创建 URL 。它们不是有效的 URL ， 需要进一步处理才能使用。要查看 URL 模板，需要创建门户项目并检查其 WEB-INF 目录。在此目录中，您将发现一个 url-templates-config.xml 文件。该文件中包含大量的默认 URL 模板。每个 URL 模板的外观如下所示：

<url-template name="default">
     {url:scheme}://{url:domain}:{url:port}/{url:path}?{url:queryString}{url:currentPage}
</url-template> to continue.

提示 ： 您可以使用已知值替换任何可选标志。例如 ， 如果您认为永远不会通过 HTTP 访问门户页面 ， 则可以在所有 URL 模板中使用 “ http ” 替换“url:scheme” 。

　　您将发现该文件不只是列出一个模板 ， 而是列出多个模板。在讨论为何需要多个模板之前，我们先看一看 URL 模板的结构。

剖析URL模板

　　URL 模板是带有一个或多个标志的 URL 。这些标志由 WebLogic Portal 预定义，在使用远程 portlet 的情况下，是 WSRP 1.0 规范规定的。所有标志均由大括号包围 ( { , } ) 。使用 URL 模板创建 URL 时， WebLogic Portal 使用相应的值替代这些标志，这些值或者由 URL API 或者由 JSP 标记指定，或者从部署门户的方式自动派生。

　　每个 URL 模板中可以具有一个或多个下面的标志 ：

• url:scheme: 这是一个可选的标志，用于指定访问该 URL 所需的 HTTP 方案。该值可以是“ http ”或“ https ”。如果在使用此 URL 模板时没有为该标志指定值， WebLogic Portal 将使用可用于生成该模板在其中发挥使用的页面的任一方案。例如，如果使用“ https ”访问包含具有模板的 URL 的页面，则它会将这一标志替换为“ https ”。

• url:domain : 这是一个可选标志 ， 用于指定访问该门户时使用的域的名称。在大多数情况下，它就是在 WebLogic Portal 之前部署的代理服务器的域名称。如果在使用 URL 模板时没有为该标志指定值， WebLogic Portal 将使用传入的 HttpServletRequest 的 getServerName() 的值。

• url:port : 这是一个可选标志 ， 用于指定访问门户时使用的端口号。在大多数情况下，它将是代理服务器的端口号。如果未指定值，则 WebLogic Portal 将使用传入的 HttpServletRequest 的 getServerPort() 的值。

• url:securePort : 这是一个可选标志 ， 用于指定访问门户时使用的 SSL 端口号。在大多数情况下，它将是代理服务器的 SSL 端口号。如果未指定值，则 WebLogic Portal 将从服务器 / 代理配置获取值。

• url:prefix: 这是一个可选标志，如果您在代理服务器设置中使用路径前缀，则需指定该标志 。

• url:path : 所有 URL 模板都必须包括此标志。 WebLogic Portal 根据页面是门户的一部分还是桌面的一部分 ， 使用相应的值替换它。

• url:contextualPath : 此标志是可选的 ， 应用于指向与 Web 应用程序上下文根相关的路径的 URL 。一个示例是到与 Web 应用程序上下文根相关的图像或文件的链接。

• url:queryString : 所有 URL 模板都必须包括此标志。 WebLogic Portal 使用很多保留查询参数 ， 使用该标志替换那些查询参数。实际替换的参数取决于如何和在何处使用这一模板。要查找有关这些保留查询参数的更多信息，请参考 WebLogic Portal 框架中的 白皮书 。

• url:currentPage : 这是一个可选项 ， 用于在生成的 URL 中嵌入当前的页面标签。

提示 ： 记住使用用于设置代理服务器的路径前缀替换url:prefix标志。

　　创建门户项目时创建的 url-templates-config.xml 文件中包含的模板列表 ， 可以满足大多数常见开发需求。

URL的类型

　　WebLogic Portal 使用三种 URL

• 操作 URL ： 这些 URL 可用于提交用户互操作 （ 如表单提交和查询链接 ）， 可以由任何 portlet 创建。

• 资源 URL ： 资源 URL 可用于生成到静态内容 （ 如图像、样式表、 JavaScript 文件、 pdf 文件等 ） 的链接。任何 portlet 都可以创建这些 URL 。

• 呈现 URL 。呈现 URL 是一种特殊类型的 URL ， 供 Java （ 符合 JSR168 的 ） portlet 和远程 （ 使用 WSRP 的 ） portlet 使用。

　　稍后我们将讨论在 JSP 中如何创建这些类型的 URL 。

　　参照前面的 url-templates-config.xml 文件 ， 您将发现该文件具有两个主要部分。第一部分定义大量模板。

　　第二部分定义 Java 和 Page Flow portlet 如何使用这些模板。

　　文件中定义的每个 url-template 具有一个名称和一个字符串值。任何两个 URL 模板的名称都不能相同。

　　字符串值是带有一个或多个标志的 URL 模板字符串。

　　此文件的第二部分为 Java 和 / 或 Page Flow portlet 定义一个或多个 url-template-ref 元素。使用这些元素可以指定要用于给定 URL 的 URL 模板。例如 ， 以下片断指定 ， 名为 jpf-action 的 URL 模板可用于创建在页面流中使用的操作 URL ， 而名为 jpf-secure-action 的 URL 模板 可用于在页面流中创建安全操作 URL ：

 <jpf-url-templates>
   <url-template-ref type="action" name="jpf-action"/>
   <url-template-ref type="secure-action" name="jpf-secure-action"/>
   ...
</jpf-url-templates>

使用URL模板

　　WebLogic Portal 提供了很多使用在前一节中定义的 URL 模板的方法。

显式使用URL模板

　　利用 URL 模板 ， 您可以使用 com.bea.portlet.GenericURL 及其子类创建 URL 。下面是一个示例 ：

 <% 
    ResourceURL url = ResourceURL.createResourceURL(request, response);
    url.setScheme("http");
    url.setDomain("my.domain.com");
    url.setPort(8001);
    url.setPathPrefix("/static");
    url.setTemplate("my-resource-template");
    url.setPath("/images/my.jpg");
%>
<img src="<%=url.toString()%>"/>  

　　此片断使用 my-resource-template 创建到图像的链接。执行时 ， 该 JSP 生成以下代码 ：

<img src="http://my.domain.com:8001/static/images/my.jpg"/>

提示 ： 确保正在使用的 URL 模板具有与 setter 方法相对应的标志。如果没有 ， WebLogic Portal 将忽略到 setter 的调用。

　　注意 ， 模板必须存在于 my-resource-template 文件中 ， 此片断才能生效。模板还必须具有一个指定的 url:prefix 标志 ， setPathPrefix() 方法将替换 该标志。

<%@ taglib uri="render.tld" prefix="render" %>
<img src="<render:resourceUrl port="8001" template="default-complete" 
      scheme="http" domain="my.domain.com" 
      pathPrefix="/static" path="/images/my.jpg"/> "/>

　　注意 ， 所有的框架主干 JSP 均使用呈现标记创建到窗口模式 / 状态按钮的链接、到页面的链接 ， 等等。

在Portlet中使用URL模板

　　使用 Page Flow 和 Struts 标记在 Page Flow 和 Struts portlet 中创建表单、链接等时 ， 这些 JSP 标记通过 URL 重写程序将 URL 创建委派给 WebLogic Portal 。这些 URL 重写程序使用 jpf-url-templates 指定的 URL 模板创建 URL 。

　　WebLogic Portal 中的 portlet 容器使用类似的方法处理 Java portlet 。创建 javax.portlet.PortletURL 时， portlet 容器使用在 url-templates-config.xml 文件中指定的 java-portlet-url-templates 。下面是一个示例：

<%
   PortletURL actionURL = renderResponse.createActionURL();
   PortletURL renderURL = renderResponse.createRenderURL();
%>

　　WebLogic Portal 将分别使用 “ 操作 ” 和 “ 资源 ” 类型的 URL 模板生成这两个 URL 的字符串值。

远程Portlet中的URL

　　当您使用WSRP消费远程portlet时，确保远程portlet返回的标记引用门户至关重要（WSRP Consumer）。使用远程portlet时，Consumer充当最终用户和WSRP Producer上部署的portlet的中间件。一般情况下，Producer可能设置安全性策略，限制最终用户对部署在Producer上的资源的访问权限。所以，未使用WebLogic Portal创建的链接在远程portlet上可能失败。

　　WSRP 1.0规范为URL创建指定了两种方法：“producer writing”和“consumer rewriting”。下面简要介绍一下这两种方法。

Producer Writing

　　此方法包括以下步骤：

• Consumer 将一组 URL 模板发送给 Producer 。这些 URL 模板在结构上类似于上面讨论的模板 ， 不同的是它们包含由 WSRP 1.0 规范指定的标记。

• Producer 使用这些 URL 模板创建 URL ， 并向 Consumer 返回标记。

• 如果需要 ， Consumer 可以进一步处理 URL 以便 URL 引用 Consumer 。

　　在这三个步骤中 ， 只有第三步依赖于 WSRP Consumer 的实现方式。如果 WebLogic Portal 就是 Consumer ， 则 Producer 的 URL 的编写包括以下步骤 ：

• WebLogic Portal 使用一组用于远程 portlet 的 URL 模板。这些模板连同其他 URL 模板一起在 url-templates-config.xml 文件中声明。门户 Web 应用程序的 WEB-INF 目录中的 wsrp-producer-registry.xml 文件指定了必须用于远程 portlet 的 URL 模板的名称。注意这些模板中出现的额外标志。例如， wsrp-default 模板具有类似 {wsrp-interactionState} 、 {wsrp-navigationalState} 和 {wsrp-mode} 的标志。 WSRP 1.0 规范描述这些标志的意义。

• Producer 使用这些模板创建 URL 。注意 ， Producer 不一定是 WebLogic Portal 。使用其他实现也可以处理这些 URL 模板 ， 因为这些标志是由 WSRP 1.0 规范定义的。

• WebLogic Portal 聚合 Producer 返回的标记而不进一步处理。

• 将 WebLogic Portal 设置为 Producer 时 ， 它将使用 URL 模板 ， 这一点与本地使用 portlet 的 情况类似。惟一的区别是 ， 它使用 Consumer 发送的模板 ， 而不使用在 Producer 本地部署的模板。

　　下面是一个示例。我们假定您使用以下 JSP 部署 Page Flow portlet ：

 <%@ taglib uri="netui-tags-html.tld" prefix="netui"%>
 <netui:anchor action="next">Next</netui:anchor>

当您在 WebLogic Portal Consumer 中消费此 portlet 时 ， 它将发送以下 SOAP 请求以获取该 portlet 的标记 ：

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <urn:getMarkup xmlns:urn="urn:oasis:names:tc:wsrp:v1:types">
      <urn:portletContext>
        <urn:portletHandle>portlet_1</urn:portletHandle>
      </urn:portletContext>
      <urn:runtimeContext>
        <urn:userAuthentication>wsrp:none</urn:userAuthentication>
        <urn:portletInstanceKey>portlet_1_2_1</urn:portletInstanceKey>
        <urn:namespacePrefix>portlet_1_2_1</urn:namespacePrefix>
        <urn:templates>
          <urn:defaultTemplate>
            http://localhost:7001/consumer/hello.portal?_nfpb=true&amp;
            _windowLabel=portlet_1_2_1&amp;_pageLabel=hello_page_2&amp;
            wsrp-urlType={wsrp-urlType}&amp;wsrp-url={wsrp-url}&amp;
            wsrp-requiresRewrite={wsrp-requiresRewrite}&amp;
            wsrp-navigationalState={wsrp-navigationalState}&amp;
            wsrp-interactionState={wsrp-interactionState}&amp;
            wsrp-mode={wsrp-mode}&amp;wsrp-windowState={wsrp-windowState}
          </urn:defaultTemplate>
          <urn:blockingActionTemplate>
            http://localhost:7001/consumer/hello.portal?_nfpb=true&amp;
            _windowLabel=portlet_1_2_1&amp;_pageLabel=hello_page_2&amp;
            wsrp-urlType=blockingAction&amp;wsrp-url={wsrp-url}&amp;
            wsrp-requiresRewrite={wsrp-requiresRewrite}&amp;
            wsrp-navigationalState={wsrp-navigationalState}&amp;
            wsrp-interactionState={wsrp-interactionState}&amp;
            wsrp-mode={wsrp-mode}&amp;wsrp-windowState={wsrp-windowState}
          </urn:blockingActionTemplate>
          <urn:renderTemplate>
            http://localhost:7001/consumer/hello.portal?_nfpb=true&amp;
            _windowLabel=portlet_1_2_1&amp;_pageLabel=hello_page_2&amp;
            wsrp-urlType=render&amp;wsrp-url={wsrp-url}&amp;
            wsrp-requiresRewrite={wsrp-requiresRewrite}&amp;
            wsrp-navigationalState={wsrp-navigationalState}&amp;
            wsrp-interactionState={wsrp-interactionState}&amp;
            wsrp-mode={wsrp-mode}&amp;wsrp-windowState={wsrp-windowState}
          </urn:renderTemplate>
          <urn:resourceTemplate>
            http://localhost:7001/consumer/resource?_windowLabel=portlet_1_2_1&amp;
            wsrp-urlType=resource&amp;wsrp-url={wsrp-url}&amp;
            wsrp-requiresRewrite={wsrp-requiresRewrite}
          </urn:resourceTemplate>
          <urn:secureDefaultTemplate>
            http://localhost:7002/consumer/hello.portal?_nfpb=true&amp;
            _windowLabel=portlet_1_2_1&amp;_pageLabel=hello_page_2&amp;
            wsrp-urlType={wsrp-urlType}&amp;wsrp-url={wsrp-url}&amp;
            wsrp-requiresRewrite={wsrp-requiresRewrite}&amp;
            wsrp-navigationalState={wsrp-navigationalState}&amp;
            wsrp-interactionState={wsrp-interactionState}&amp;
            wsrp-mode={wsrp-mode}&amp;wsrp-windowState={wsrp-windowState}
          </urn:secureDefaultTemplate>
          <urn:secureBlockingActionTemplate><![CDATA[
            https://localhost:7002/consumer/hello.portal?_nfpb=true&
            _windowLabel=portlet_1_2_1&_pageLabel=hello_page_2&
            wsrp-urlType=blockingAction&wsrp-secureURL=true&
            wsrp-url={wsrp-url}&wsrp-requiresRewrite={wsrp-requiresRewrite}&
            wsrp-navigationalState={wsrp-navigationalState}&
            wsrp-interactionState={wsrp-interactionState}&
            wsrp-mode={wsrp-mode}&wsrp-windowState={wsrp-windowState}]]>
          </urn:secureBlockingActionTemplate>
          <urn:secureRenderTemplate><![CDATA[
            https://localhost:7002/consumer/hello.portal?_nfpb=true&
            _windowLabel=portlet_1_2_1&_pageLabel=hello_page_2&
            wsrp-urlType=render&wsrp-secureURL=true&wsrp-url={wsrp-url}&
            wsrp-requiresRewrite={wsrp-requiresRewrite}&
            wsrp-navigationalState={wsrp-navigationalState}&
            wsrp-interactionState={wsrp-interactionState}&
            wsrp-mode={wsrp-mode}&wsrp-windowState={wsrp-windowState}]]>
          </urn:secureRenderTemplate>
          <urn:secureResourceTemplate>
            https://localhost:7002/consumer/resource?_windowLabel=portlet_1_2_1&amp;
            wsrp-urlType=resource&amp;wsrp-secureURL=true&amp;
            wsrp-url={wsrp-url}&amp;wsrp-requiresRewrite={wsrp-requiresRewrite}
          </urn:secureResourceTemplate>
        </urn:templates>
      <urn:runtimeContext>
      <urn:userContext xsi:nil="true" 
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
      <urn:markupParams>
        <urn:secureClientCommunication>false</urn:secureClientCommunication>
        <urn:locales>en-US</urn:locales>
        <urn:mimeTypes>text/html</urn:mimeTypes>
        <urn:mimeTypes>*/*</urn:mimeTypes>
        <urn:mode>wsrp:view</urn:mode>
        <urn:windowState>wsrp:normal</urn:windowState>
        <urn:clientData>
          <urn:userAgent>Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; 
             SV1; .NET CLR 1.1.4322; FDM)</urn:userAgent>
        </urn:clientData>
      <urn:markupCharacterSets>UTF-8</urn:markupCharacterSets>
    </urn:markupParams>
  </urn:getMarkup>
</soapenv:Body>
</soapenv:Envelope>

　　在此请求中 ， 要注意的主要细节是模板元素。将 URL 模板发送到任何 Producer 之前 ， WebLogic Portal Consumer 会将 URL 模板中的所有 Consumer 特定的标志替换掉 ， 仅留下 WSRP 1.0 特定的标志。替换 WSRP 1.0 特定的标志由 Producer 来完成。注意，出于可读性方面的考虑，上述消息中的模板的多个行被强制换行。

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <urn:getMarkupResponse xmlns:urn="urn:oasis:names:tc:wsrp:v1:types">
      <urn:markupContext>
        <urn:mimeType>text/html; charset=UTF-8</urn:mimeType>
        <urn:markupString><![CDATA[
          <a href="http://localhost:7001/consumer/hello.portal?_nfpb=true&
              _windowLabel=portlet_1_2_1&_pageLabel=hello_page_2&
              wsrp-urlType=blockingAction&wsrp-url=&wsrp-requiresRewrite=&
              wsrp-navigationalState=&
              wsrp-interactionState=_action%3D%252Fhello%252FHelloWorld%252Fbegin&
              wsrp-mode=&wsrp-windowState=">Next</a>
     ]]></urn:markupString>
        <urn:locale>en-US</urn:locale>
        <urn:requiresUrlRewriting>false</urn:requiresUrlRewriting>
      </urn:markupContext>
    </urn:getMarkupResponse>
  </soapenv:Body>
</soapenv:Envelope>

提示 ： WebLogic Portal Producer 可以将 URL 模板存储在 HTTP 会话中 ， 所以 ， WebLogic Portal Consumer 每个会话发送一次 URL 模板。

　　注意 ， Producer 使用 blockingActionTemplate 创建 netui:anchor 标记的链接。由于在这次响应中返回的 portlet 标记完全合格 ， 不需要在 Consumer 上对其进行进一步地处理。

　　如果您有意了解关于这些 SOAP 消息内容的更多信息 ， 请访问 OASIS WSRP TC 主页 ， 并下载最新版本的 WSRP 1.0 Primer 。

Consumer Rewriting

　　在此方法中 ， Consumer 不发送 URL 模板 ， 而是执行以下步骤 ：

　　Consumer 为 portlet 标记发出请求。该请求不包括 URL 模板。

　　Producer 创建链接 ， 这些链接被封装在由 WSRP 1.0 规范指定的特殊标记中。

　　Consumer 分析该标记 ， 并使用适当的 URL 替换这些标记中的链接。

　　对于上述示例 portlet ， Producer 返回如下响应 ：

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <urn:getMarkupResponse xmlns:urn="urn:oasis:names:tc:wsrp:v1:types">
      <urn:markupContext>
        <urn:mimeType>text/html; charset=UTF-8</urn:mimeType>
        <urn:markupString>Hello World 
           &lt;a href="wsrp_rewrite?wsrp-urlType=blockingAction&wsrp-secureURL=false
           &wsrp-interactionState=_action%3D%252Fhello%252FHelloWorld%252Fbegin/wsrp_rewrite">Begin
           &lt;/a></urn:markupString>
        <urn:locale>en-US</urn:locale>
        <urn:requiresUrlRewriting>true</urn:requiresUrlRewriting>
      </urn:markupContext>
    </urn:getMarkupResponse>
  </soapenv:Body>
</soapenv:Envelope>

　　注意 ， 链接的 href 值被封装在 wsrp_rewrite? 和 /wsrp_rewrite 标记之间。然后 ， WebLogic Portal Consumer 分析这些记号中的标记 ， 并使用部署在 Consumer 上的 URL 模板创建 URL 。 

提示 ： 如果将 WebLogic Portal 用作 Consumer ， 则可以尝试对 Producer 进行设置 ， 以便更好地使用 URL 模板。

Producer Writing还是Consumer Rewriting？

　　URL 创建的两种方法的主要不同点在于 URL 模板的使用。由 WebLogic Portal Consumer 发送给 Producer 的那种模板不需要对 Producer 返回的标记进行进一步地处理。因此，将 WebLogic Portal 用作 Consumer 时，此方法执行地较好。

　　WebLogic Portal Producer （ 无论简单还是复杂 ） 默认的设置是使用 Producer writing 生成 URL 。您可以通过更新 Producer 的 WEB-INF 目录下的 wsrp-producer-config.xml文件改用 Consumer rewriting 。请参考 关于 WSRP 的 WebLogic Portal 文档资料 以获取更多细节。

结束语

　　在本文中 ， 我的目的之一是想指出为什么创建 URL 对于提供一致的用户体验是关键一步。当您使用 WebLogic Portal 提供的 API 和 JSP 标记、 Page Flow 或 Struts 标记、或者 Java Portlet API 或标记时， URL 创建过程依赖于 URL 模板。 WebLogic Portal 具有消费本地部署的模板和远程 Consumer 发送的模板的能力。这些功能在设计上允许 URL 模板控制所有创建的链接，以声明的方式即可调整，无需更改代码。

　　反向工程生成的 URL 结构以手动创建链接 （ 即不使用任何 WebLogic Portal API 或标签 ）， 也是很可能实现的。这种链接在有些情况下可以使用，但是当部署配置变更或使用 WSRP 时，则很可能失败。下面是最新的准则。始终使用以下标签创建链接：

• 在框架主干 JSP 和 portlet JSP 中 ： com.bea.portlet.GenericURL 或其子类或者呈现标签库中的 URL 标签

• 在 Page Flow portlet 中 ： Page Flow HTML 标记

• 在 Struts portlet 中 ： Struts HTML 标记

• 在 Java Portlet 中 ： Java Portlet API 或 portlet 标记库中的 URL 标记

　　您完全可以不使用这些标记 ， 而按照自己的意思创建 URL 。但这样的 URL 有时可能不可用。

参考资料

关于 WSRP 的 WebLogic Portal 文档资料

WebLogic Portal GenericURL 文档资料

描述 WebLogic Portal Framework 的白皮书

OASIS WSRP TC 主页

关于作者

　　Subbu Allamaraju 是 BEA Systems 的 WebLogic Portal 开发团队的专职软件工程师。从事 WSRP 标准及其 WebLogic Portal 实现方面的工作。此外他还在 subbu.org 上扮演一个技术博客的角色。

原文出处

http://dev2dev.bea.com/products/wlportal81/articles/urls_in_portal.jsp

        <weblogic.security.providers.authentication.DefaultIdentityAsserter
            ActiveTypes="AuthenticatedUser"
            Name="Security:Name=myrealmDefaultIdentityAsserter" Realm="Security:Name=myrealm"/>
        <weblogic.security.providers.authorization.DefaultRoleMapper
            Name="Security:Name=myrealmDefaultRoleMapper" Realm="Security:Name=myrealm"/>
        <weblogic.security.providers.authorization.DefaultAuthorizer
            Name="Security:Name=myrealmDefaultAuthorizer" Realm="Security:Name=myrealm"/>
        <weblogic.security.providers.authorization.DefaultAdjudicator
            Name="Security:Name=myrealmDefaultAdjudicator" Realm="Security:Name=myrealm"/>
        <weblogic.security.providers.credentials.DefaultCredentialMapper
            Name="Security:Name=myrealmDefaultCredentialMapper" Realm="Security:Name=myrealm"/>
        <weblogic.management.security.authentication.UserLockoutManager
            Name="Security:Name=myrealmUserLockoutManager" Realm="Security:Name=myrealm"/>
        <weblogic.management.security.Realm
            Adjudicator="Security:Name=myrealmDefaultAdjudicator"
            AuthenticationProviders="Security:Name=myrealmDefaultAuthenticator|Security:Name=myrealmDefaultIdentityAsserter|Security:Name=myrealmWSRPIdentityAsserter"
            Authorizers="Security:Name=myrealmDefaultAuthorizer"
            CredentialMappers="Security:Name=myrealmDefaultCredentialMapper"
            DefaultRealm="true" DisplayName="myrealm"
            FullyDelegateAuthorization="true"
            Name="Security:Name=myrealm"
            RoleMappers="Security:Name=myrealmDefaultRoleMapper" UserLockoutManager="Security:Name=myrealmUserLockoutManager"/>
        <com.bea.wsrp.security.WSRPIdentityAsserter
            ActiveTypes="WSRPPerimeterAtnToken"
            Base64DecodingRequired="false"
            Name="Security:Name=myrealmWSRPIdentityAsserter" Realm="Security:Name=myrealm"/>
    </Security>
    <SNMPAgent Name="portal"/>
    <Log FileMinSize="20000" FileName="./wl-domain.log" Name="portal" RotationType="bySize"/>
    <JMSConnectionFactory
        JNDIName="weblogic.jws.jms.QueueConnectionFactory"
        Name="cgQueue"
        Notes="User transactions must be enabled to ensure transaction coordination for persistence and asynchronous operations"
        Targets="portalServer" UserTransactionsEnabled="true"/>
    <JMSFileStore Directory="rmfilestore" Name="FileStore"/>
    <JMSJDBCStore ConnectionPool="cgJMSPool-nonXA" Name="cgJMSStore" PrefixName="weblogic"/>
    <JMSServer Name="cgJMSServer" Store="cgJMSStore" Targets="portalServer">
        <JMSQueue JNDIName="jws.queue" Name="cgJWSQueue"
            RedeliveryLimit="2" StoreEnabled="default"/>
    </JMSServer>
    <WSReliableDeliveryPolicy DefaultRetryCount="10"
        DefaultTimeToLive="60000" Name="RMDefaultPolicy" Store="FileStore"/>
    <JDBCConnectionPool CapacityIncrement="1"
        DriverName="com.pointbase.jdbc.jdbcUniversalDriver"
        InitialCapacity="5" MaxCapacity="50" Name="cgPool"
        PasswordEncrypted="{3DES}s4loB2ZDe75pVWDp7VCO5Q=="
        Properties="user=weblogic" RefreshMinutes="0"
        ShrinkPeriodMinutes="15" ShrinkingEnabled="true"
        SupportsLocalTransaction="true" Targets="portalServer"
        TestConnectionsOnRelease="false"
        TestConnectionsOnReserve="false" URL="jdbc:pointbase:server://localhost:9093/workshop"/>
    <JDBCConnectionPool CapacityIncrement="1"
        DriverName="com.pointbase.jdbc.jdbcUniversalDriver"
        InitialCapacity="5" MaxCapacity="50" Name="cgJMSPool-nonXA"
        PasswordEncrypted="{3DES}s4loB2ZDe75pVWDp7VCO5Q=="
        Properties="user=weblogic" RefreshMinutes="0"
        ShrinkPeriodMinutes="15" ShrinkingEnabled="true"
        SupportsLocalTransaction="true" Targets="portalServer"
        TestConnectionsOnRelease="false"
        TestConnectionsOnReserve="false" URL="jdbc:pointbase:server://localhost:9093/workshop"/>
    <JDBCConnectionPool CapacityIncrement="1"
        DriverName="com.pointbase.jdbc.jdbcUniversalDriver"
        InitialCapacity="5" MaxCapacity="50" Name="portalPool"
        PasswordEncrypted="{3DES}s4loB2ZDe75pVWDp7VCO5Q=="
        Properties="user=weblogic" RefreshMinutes="0"
        ShrinkPeriodMinutes="15" ShrinkingEnabled="true"
        Targets="portalServer" TestConnectionsOnRelease="false"
        TestConnectionsOnReserve="false" URL="jdbc:pointbase:server://localhost:9093/workshop"/>
    <JDBCDataSource JNDIName="p13n.trackingDataSource"
        Name="p13n_trackingDataSource" PoolName="cgJMSPool-nonXA" Targets="portalServer"/>
    <JDBCDataSource
        JNDIName="p13n.sequencerDataSource;p13n.dataSyncDataSource;p13n.entitlementsDataSource"
        Name="p13nDataSource" PoolName="cgJMSPool-nonXA" Targets="portalServer"/>
    <JDBCTxDataSource EnableTwoPhaseCommit="true"
        JNDIName="cgDataSource;cgSampleDataSource" Name="cgDataSource"
        PoolName="cgPool" Targets="portalServer"/>
    <JDBCTxDataSource EnableTwoPhaseCommit="true"
        JNDIName="cgDataSource-nonXA;weblogic.jdbc.jts.ebusinessPool"
        Name="cgDataSource-nonXA" PoolName="cgJMSPool-nonXA" Targets="portalServer"/>
    <JDBCTxDataSource EnableTwoPhaseCommit="false"
        JNDIName="portalFrameworkPool;contentDataSource;weblogic.jdbc.jts.commercePool"
        Name="portalFrameworkPool" PoolName="portalPool" Targets="portalServer"/>
    <JTA Name="portal" TimeoutSeconds="500"/>
    <EmbeddedLDAP
        CredentialEncrypted="{3DES}HMSGZ1HaJ4VJJp5iPsboY2qt7eMGGlyJSzpb0VaY60s=" Name="portal"/>
    <SecurityConfiguration
        CredentialEncrypted="{3DES}88uPm33g3MGkMPADkzvpPzRLt1DSFb5Ua8+9I7M8VtyQ8jGORFsxHbg6J6t+Fawqv69kg2seht65KpJJiReAPGLQZh3RfJPF"
        Name="portal" RealmBootStrapVersion="1"/>
    <JMSServer Name="WSStoreForwardInternalJMSServerportalServer"
        Store="FileStore" Targets="portalServer">
        <JMSQueue CreationTime="1115867722375"
            JNDIName="jms.internal.queue.WSStoreForwardQueue"
            JNDINameReplicated="false" Name="WSInternaljms.internal.queue.WSStoreForwardQueueportalServer"/>
        <JMSQueue CreationTime="1115867722906"
            JNDIName="jms.internal.queue.WSDupsEliminationHistoryQueue"
            JNDINameReplicated="false" Name="WSInternaljms.internal.queue.WSDupsEliminationHistoryQueueportalServer"/>
    </JMSServer>
    <Application Name="portalApp"
        Path="D:\bea\weblogic81\samples\portal\portalApp"
        StagingMode="nostage" TwoPhase="true">
        <EJBComponent Name="commerce.jar" Targets="portalServer" URI="commerce.jar"/>
        <WebAppComponent Name="sampleportal" Targets="portalServer" URI="sampleportal"/>
        <WebAppComponent Name="tutorial" Targets="portalServer" URI="tutorial"/>
        <WebAppComponent Name="portalAppAdmin" Targets="portalServer" URI="adminPortal.war"/>
        <WebServiceComponent Name="portalAppTool" Targets="portalServer" URI="wps-toolSupport.war"/>
        <WebAppComponent Name="portalAppDataSync" Targets="portalServer" URI="datasync.war"/>
        <EJBComponent Name="netuix.jar" Targets="portalServer" URI="netuix.jar"/>
        <EJBComponent Name="prefs.jar" Targets="portalServer" URI="prefs.jar"/>
        <EJBComponent Name="p13n_ejb.jar" Targets="portalServer" URI="p13n_ejb.jar"/>
        <EJBComponent Name="pipeline.jar" Targets="portalServer" URI="pipeline.jar"/>
        <EJBComponent Name="wps.jar" Targets="portalServer" URI="wps.jar"/>
        <EJBComponent Name="content_repo.jar" Targets="portalServer" URI="content_repo.jar"/>
        <EJBComponent Name="content.jar" Targets="portalServer" URI="content.jar"/>
        <WebAppComponent Name="defaultWebApp" Targets="portalServer" URI="defaultWebApp"/>
        <EJBComponent Name="calendar_ejb.jar" Targets="portalServer" URI="calendar_ejb.jar"/>
        <EJBComponent Name="contact_ejb.jar" Targets="portalServer" URI="contact_ejb.jar"/>
        <EJBComponent Name="todo_ejb.jar" Targets="portalServer" URI="todo_ejb.jar"/>
        <EJBComponent Name="discussion_ejb.jar" Targets="portalServer" URI="discussion_ejb.jar"/>
        <EJBComponent Name="security_ejb.jar" Targets="portalServer" URI="security_ejb.jar"/>
        <EJBComponent Name="uniqueid_ejb.jar" Targets="portalServer" URI="uniqueid_ejb.jar"/>
    </Application>
</Domain>

An Overview of Role-Based Security

1. Application scoped (defined in the application's application.xml / weblogic-application.xml files)
2. Web application scoped (defined in a project's web.xml / weblogic.xml files)
3. EJB scoped (defined in an EJB's ejb-jar.xml / weblogic-ejb-jar.xml files)

本节讲述安全管理功能在 EJB 体系架构中的工作方式，并提供针对环境开发安全的 Enterprise Bean 的准则。

本节介绍以下主题：

• 关于安全的 Enterprise Bean

• 定义安全角色

• 声明方法权限

• 声明安全角色参考

• 指定安全标识 

• 使用编程安全

• 处理未受保护的 EJB 层资源

有关应用程序安全的一般信息，请参阅 Sun ONE 应用服务器开发者指南。

关于安全的 Enterprise Bean

EJB 开发者的主要角色是声明您的应用程序的安全要求，应用程序开发期间，需要满足这些要求。多数情况下，EJB 的业务方法不应包含任何与安全相关的逻辑。

本节介绍以下主题：

• 授权和身份验证

• 安全角色

• 部署

授权和身份验证

授权提供对受保护资源的受控访问；授权以身份识别和身份验证为基础。身份识别是通过一个系统实现实体认可的过程。授权是验证计算机系统中用户、设备或其他实体的身份的过程，通常作为允许访问系统中资源的前提条件。

Enterprise Bean 可配置为仅允许具有适当授权级别的用户进行访问。此任务是通过利用 Sun ONE 应用服务器管理界面为应用程序 EAR 和 EJB JAR 文件生成部署描述符来完成的。

安全角色

安全角色是应用程序特有的逻辑用户分组，具体按照通用特征（如客户概要或工作头衔）分类。部署一个应用程序时，可以将角色映射到安全标识，如操作环境中的原则（principal）（作为身份验证结果指定给用户的标识）或组。基于此，具有某种安全角色的用户对 Enterprise Bean 具有关联访问权限。链接为所引用的安全角色的实际名称。

一个组也可以代表一个用户类别，但其范围不同于一个角色的范围。

• 角色是 J2EE 应用程序特有的抽象概念。

• 一个组是一组当前领域中环境特定的用户。组成员身份是通过基本领域实施来确定的。

  
  

  ---

  注意	定义方法限制和角色映射时，将领域组和 J2EE 应用程序角色混淆起来是一个常见的错误。这样的混淆会导致不希望的访问结果或不可互操作的应用程序配置。有关领域的信息，请参阅 Sun ONE 应用服务器开发者指南。

  ---

  
  

部署

安全角色引用定义使用 isCallerInRole（字符串名称）从 Enterprise Bean 调用的角色的名称与已为应用程序定义的安全角色的名称之间的映射。此安全性角色引用使一个 Enterprise Bean 可以引用一个现有安全角色。

部署应用程序时，部署者将角色映射到操作环境中存在的全标识。开发 Enterprise Bean 时，您应知道您的用户的角色，但很可能不会准确地知道用户的真实身份。在 J2EE 安全体系架构中，对此设计非常细致。部署您的组件之后，系统管理员将角色映射到默认领域（通常为文件领域）的 J2EE 用户（或组）。

定义安全角色

要为 J2EE 应用程序创建一个角色，需要为 EJB JAR 文件或应用程序中包含的 WAR 文件声明该角色。security-role 元素中定义的安全角色的范围限制在 EJB JAR 文件级别，并适用于 EJB JAR 文件中的所有 Enterprise Bean。

示例

部署描述符中一个安全角色定义的以下示例指定了两个角色名称元素 employee 和 admin。

...
<assembly-descriptor>
   <security-role>
      <description>
         This role includes the employees of the enterprise who
         are allowed to access the employee self service
         application. This role is allowed to access only
         her/his information
      </desciption>
      <role-name>employee<role-name>
      </security-role>
      <security-role>
         <description>
            This role should be assigned to the personnel
            authorized to perform administrative functions
            for the employee self service application. This
            role does not have direct access to
            sensitive employee and payroll information
         </desciption>
      <role-name>admin<role-name>
      </security-role>
...
</assembly-descriptor>

声明方法权限

方法权限表示允许哪些角色调用哪些方法。应用程序汇编者使用如下所示方法权限元素在部署描述符中声明方法权限：

• 每个 method-permission 元素都有一个包含一个或多个安全角色的列表以及一个包含一个或多个方法的列表。

  列出的所有安全角色都可以调用列出的所有方法。列表中的每个安全角色通过 role-name 元素识别，而每个方法（或方法集，如下面所述）则通过方法元素识别。可以使用说明元素将一个可选说明与 method-permission 元素关联。

• 方法权限关系作为个别方法权限元素中定义的所有方法权限的集合进行定义。

• 一个安全角色或一个方法可以出现在多个 method-permission 元素中。

示例

以下部署描述符示例说明如何在部署描述符中给安全角色指定方法权限。部署时将这些方法权限转换为安全元素。

...
<method-permission>
   <role-name>employee</role-name>
      <method>
      <ejb-name>EmployeeService</ejb-name>
      <method-name>*</method-name>
   </method>
</method-permission>

<method-permission>
   <role-name>employee</role-name>
   <method>
      <ejb-name>AardvarkPayroll</ejb-name>
      <method-name>findByPrimaryKey</method-name>
   </method>
   <method>
      <ejb-name>AardvarkPayroll</ejb-name>
      <method-name>getEmployeeInfo</method-name>
   </method>
   <method>
      <ejb-name>AardvarkPayroll</ejb-name>
      <method-name>updateEmployeeInfo</method-name>
   </method
</method-permission>
...

声明安全角色引用

EJB 开发者应负责声明所有安全角色名称的，它们用于角色的部署描述符中的 security-role-ref 元素，这些角色由程序从各自 Enterprise Bean 中进行使用。

• 应用程序汇编者负责将在 security-role-ref 元素中声明的所有安全角色引用链接到 security-role 元素中定义的安全角色。

• 应用程序汇编者使用 role-link 元素将每个安全角色引用链接到一个安全角色。
  

  ---

  注意	role-link 元素值必须是 security-role 元素中定义的安全角色名称之一。

  ---

  
  

示例

以下部署描述符示例说明如何将名为 payroll 的安全角色引用链接到名为 payroll-department 的安全角色。

<enterprise-beans>
   ...    
   <entity>
      <ejb-name>AardvarkPayroll</ejb-name>
      <ejb-class>com.aardvark.payroll.PayrollBean</ejb-class>
   ...
      <security-role-ref>
      <description> This role should be assigned to the payroll
      department's employees. Members of this role have access to
      anyone's payroll record. The role has been linked to the
      payroll-department role.
      </description>
      <role-name>payroll</role-name>
      <role-link>payroll-department</role-link>
      </security-role-ref>
   ....
   </entity>
   ...
</enterprise-beans>

应把此角色指定给薪资部的员工。此角色的成员可以访问任何人的薪资记录。该角色已被链接到 payroll-department 角色。

有关安全角色的进一步信息，请参阅 Sun ONE 应用服务器开发者指南。有关 EJB 访问控制配置的详细信息，请参阅 Enterprise JavaBeans Specification 2.0。

指定安全标识

EJB 汇编者可以随意指定是否将调用者的标识用于执行 EJB 方法，或指定是否使用 run-as 身份。出于此目的，使用部署描述符中的 security-identity 元素。security-identity 元素的值为 use-caller-identity or run-as。

如果没有指定，默认情况下使用调用者标识。.

run-as 标识

run-as 标识建立 Enterprise Bean 进行调用操作时将使用的标识。 run-as 标识不会影响其调用这的标识，这些标识是针对访问 Enterprise Bean 的方法权限而测试的标识。

EJB 汇编者可以使用 run-as 元素为部署描述符中的 Enterprise Bean 定义一个 run-as 标识。run-as 标识总体上适用于 Enterprise Bean，即适用于 EJB 的主接口和组件接口的所有方法 EJB，或适用于消息驱动型 Bean 的 onMessage 方法以及可能调用的 Enterprise Bean 的所有内部方法。

由于汇编者一般不知道操作环境的安全环境，因而按一个逻辑角色名指定 run-as 标识，该逻辑角色名与部署描述符中定义的安全角色之一相对应。然后，部署者必须指定一个作为 run-as 标识的原则使用的安全原则（在操作环境中定义）。安全原则应是一个已经指定给安全角色的与 role-name 元素指定的相同的原则。

使用编程安全

一般来说，应由容器以一种对 EJB 的业务方法透明的方式执行安全管理功能。

EJB 层中的编程安全由 getCallerPrincipal 和 isCallerInRole 方法组成。您可以使用 getCallerPrincipal 方法确定 Enterprise Bean 的调用者，以及使用 isCallerInRole 方法确定调用者的角色。

EJBContext 接口的 getCallerPrincipal 方法返回识别 Enterprise Bean 的调用者的 java.security.Principal 对象。（在此情况下，原则与一个用户相同。在以下示例中，一个 Enterprise Bean 的 getUser 方法返回调用它的 J2EE 用户的名称：

   public String getUser()
   {
      return context.getCallerPrincipal().getName();
   }

   boolean result = context.isCallerInRole("Customer");

有关如何实施编程安全的详细信息，请参阅 Enterprise JavaBeans Specification 2.0 的第 21 章“安全管理”。

处理不受保护的 EJB 层资源

所有用户都具有匿名角色。默认情况下，匿名角色的值为 ANYONE，该值可在 server.xml 文件中进行配置。因此，如果某个方法权限指定所需角色为 ANYONE（或将匿名角色设置为的任何值），则任何用户都可以访问此方法。

如果存在方法权限，就始终执行此方法权限。例如，如果设置了某个方法权限，因而 updateEmployeeInfo 方法只能由 employee 角色进行访问，那么，如果没有角色 employee，就始终无法访问此方法。如果没有把 employee 角色映射到任何用户或组，就没有人能够调用 updateEmployeeInfo 方法。

笨笨 2005-05-16 14:11 发表评论

]]>

　　目前，我们已经拥有了5个可以通过WSRP访问的驻留portlet。这些portlet是：
　　BEA: WSRP
　　BEA: Racing!
　　BEA: Double Byte
　　BEA: SOA - eWorld 2004
　　BEA: Download WebLogic Portal 8.1

您需要的主要URL是:

1. WebLogic Portal 8.1 SP3测试服务器：http://wsrp.bea.com
2. 具有WSRP portlet的WSRP门户示例：http://wsrp.bea.com/portal/wsrp.portal
3. WSDL Address：http://wsrp.bea.com/portal/producer?wsdl

　　为了在WebLogic Portal项目中支持远程portlet，您可以使用Workshop或者Portal Administration工具。Workshop使您可以通过portlet向导来创建一个引用远程portlet的代理portlet。Administration Portal使您可以通过添加Producer来创建代理portlet。

从Workshop使用WSRP测试服务器
　　在这个例子中，我们在一个门户域中使用具有Portal Application的Workshop（您可以使用其他的配置 — 参见“ Working with Producers ”）。为了创建代理portlet：

1. 右键点击Portal project，选择“New”→“Portlet”。
2. 在Portlet Wizard中选择“Remote Portlet”选项。
3. 将以下测试服务器WSDL粘贴到Remote Server字段中： http://wsrp.bea.com/portal/producer?wsdl。
4. 根据Wizard提示来注册Producer。
5. 选择一个portlet和应用程序联合，例如：“BEA: eWorld 2004”。
6. 完成以后，您将得到一个.portlet 文件。.portlet应该文件存放在什么地方呢？
7. 把 portlet 添加到门户中，用拖放操作把它放置在所需的位置上（book、page等）。
8. 运行门户来察看远程portlet。

从Administration Portal使用WSRP测试服务器
　　在访问Administration Portal之前，您必须首先运行WebLogic Portal服务器。您应当运行WebLogic Portal 8.1 SP3或者更新的版本。
　　使用Administration Portal，按照以下的说明来创建代理portlet：

1. 在Portal选项卡中，展开左边的Portal Library。
2. 右键点击“Portlet Producer”文件夹，选择“Add Producers”。
3. 在Add Producer对话框中，将测试服务器WSDL粘贴到Producer字段中：http://wsrp.bea.com/portal/producer?wsdl
4. 点击“Add Producer”创建到producer的引用。
5. 键入Producer Property。
6. 点击“Register”确立与producer的关系。
7. 注册完成后，点击producer链接察看所提供的远程portlet（参见下图）。
8. 点击“Add”激活portlet库中的远程portlet。
9. 将portlet添加到桌面。
10. 如果想预览远程portlet，右键点击桌面，并选择“View Desktop”。

　　您还可以使用WebLogic Portal 8.1 SP3或更新版本将自己的portlet（Page Flow、Struts、JSR168）作为远程portlet发布。如果使用WebLogic Server 8.1 SP3或者更新版本，您可以把使用Page Flow和Struts创建的应用程序作为WSRP资源发布。要获取更多关于使用WSRP的信息，请访问以下链接：

1. 利用WebLogic Portal 8.1使用Web Services for Remote Portlets (WSRP):
   http://dev2dev.bea.com/products/wlportal81/articles/wsrp.jsp
2. WSRP Standards 站点：
   http://www.oasis-open.org/committees/wsrp/
3. BEA WebLogic Portal 8.1 相关站点：
   http://dev2dev.bea.com/products/wlportal81/index.jsp
   http://e-docs.bea.com/wlp/docs81/wsrp/index.html
   http://edocs.bea.com/wlp/docs81/index.html
4. 网络培训：WSRP和 Federated Portals
   http://dev2dev.bea.com/trainingevents/webinars/060904_wsrp.jsp

原文出处
http://dev2dev.bea.com/products/wlportal81/articles/wsrp_test_server_at.jsp

1. 修改 JSP 第一行的 ContentType 宣告，将 UTF-8 改为 GBK/GB2312，即：
   <%@ page language="java" contentType="text/html;charset=GBK"%>
2. 编辑 weblogic.xml中，关于 encoding 这项的设定，将 UTF-8 改为 GBK，即：
   <jsp-param>
   <param-name>encoding</param-name>
   <param-value>GBK</param-value>
   </jsp-param>
3. 变更 Web 应用程序字符编码
   在 Workshop IDE 中，从 Tools 选单 -> Application Properties -> Encoding 选项中，将 Web App Character Encoding 底下的 "Use default (UTF-8)" 一项，移除勾选，并在 "Encoding" 字段后键入 GBK或gb2312。
4. 将 charset-params 项目加到 weblogic.xml 中：
   <charset-params>
   <input-charset>
   <resource-path>/*</resource-path>
   <java-charset-name>GBK</java-charset-name>
   </input-charset>
   </charset-params>
5. 将以下项目从 web.xml 中移除或批注掉，或者将param-value修改为GBK
   <context-param>
   <param-name>weblogic.httpd.inputCharset./*</param-name>
   <param-value>UTF-8</param-value>
   </context-param>
6. 将 WLP8.1 portal 模板(即 .portal 文件) 的 ContentType 编码加以修改 (预设编码为 UTF-8) 如下：
   <portal:directive.page contentType="text/html;charset=GBK"/>
   
   变更方法
   (由于 .portal 档的本质为 XML，建议使用 Workshop 来编辑该档案，比较安全)
   在 Workshop IDE 中，从 Tools 选单中选择 "Application Properties"
   选择 "Portal" 的选项，然后勾选 "Open as XML Option" 选项
   接着便可以以右键点选您的 .portal 档案，并选择 "Open as XML" 指令
   按照以上的说明，编辑 .portal 文件的 XML 原始码，修改编码部分的宣告
   关闭当前文件，再打开.portal文件时，又是图形化界面
   
   执行到这一步时，已经能够保证运行.portal文件的编码是简体中文了。
   
7. 使用 WebLogic Administration Portal，以 GBK 型建立之 Portal 为基础来建立桌面时，必须更新数据库表数据。
   更新对象表：L10N_LOCALE
   更新对象列：ENCODING (标准设置是 UTF-8)

变更方法和执行步骤如下。
　　部署 Portal 应用程序。
　　启动 WebLogic Administration Portal 并登入。
　　在数据库的 L10N_LOCALE 表中，寻找LANGUAGE =’zh’ 的 记录，然后将ENCODING 列从 UTF-8 修改为 GBK。
　　使用 WebLogic Administration Portal 来建立新的桌面。以后建立的所有桌面都是 GBK 型桌面。

补充 1. 表更新时机
　　在 L10N_LOCALE 表中，必须变更下述两列的 ENCODING 列：分别是 LANGUAGE 值为 zh 且 COUNTRY 值为 CN 的行，以及 LANGUAGE 值为 zh 的行。LANGUAGE 值为 zh 且 COUNTRY 值为 CN 的行，会在部署 Portal 应用程序时自动建立，而 LANGUAGE 值为 zh 的行，则会因为 Portal 应用程序所建立的内容，而未在部署时登录。 在这种情况下，此列会在登入 WebLogic Administration Portal 时自动建立。因此，在登入 WebLogic Administration Portal 之后再变更表较为适当。

范例：更新 Oracle9i 的列
　　SQL> UPDATE L10N_LOCALE SET ENCODING='GBK' WHERE LANGUAGE='zh'; 两列已更新。
　　SQL> commit;

范例：更新 PointBase 的列
　　由于缺省时，Portal带有的数据库是Pointbase，所以，进入Domain目录，运行startPointBaseConsole.cmd或者startPointBaseConsole.sh，然后确定Concole里面URL是jdbc:pointbase:server://10.130.2.150:9093/workshop，输入用户名称和密码都是weblogic/weblogic，在Enter SQL Commands输入框中输入
　　UPDATE L10N_LOCALE SET ENCODING='GBK' WHERE LANGUAGE='zh';
　　点击Toolbar上的Execute All ，执行完毕。

　　执行完该步骤时，才能保证streaming portal运行支持简体中文。

1.2 在 Portal 应用程序中添加版面、外壳以及观感的简体中文登录信息的方法
　　如果在 Portal 管理画面中看到以下的讯息：
　　尚未设置 [zh_CN] 语言地区的标题。

　　这是因为版面、外壳以及观感等 Portal 样板的简体中文信息尚未登录所致。登录信息的默认值为 "en"，如果要显示其它语言地区，必须执行下列步骤。

　　通过Portal 管理工具的修正方式：
　　启动 portalAdmin (将浏览器的语言设定为 'en')
　　选择 PortalResources-Layout
　　为树状目录中显示的每个项目选择 '添加语言地区'。(设定想要添加的语言 (例如，'zh_CN')，然后说明标题。)
　　回复浏览器初始的语言设定，然后重新显示。
　　透过这些步骤，可以将版面、外壳以及观感的登录信息储存在数据库中 (表名称：L10N_RESOURCE)。

　　通过Workshop 的修正方式：
　　在 Workshop 中建立的 Portal Web project 的 framework\markup\ 数据夹中，有 fourcolumn.layout、text.laf 等样板档案。如果事先将这些档案中的语言地区值设定为 "zh"，则上述讯息就不会显示出来。所有样版的原始档都来自 %WL_HOME%\workshop\templates\portal-project.zip 中的 portal.war。

下载portal-project.zip

　　通过命令方式：
　　解开压缩包，拷贝com目录和changelocale.cmd到domain目录下
　　打开changelocale.cmd，查看URL，username和password，确保与当前Domain相符。
　　运行setdomainenv.cmd
　　运行changelocale.cmd
　　由于直接操作数据库，所以该命令适合Weblogic Portal8.13（不能保证其他版本数据库表结构不会发生变化），主要是为各个资源建立zh_CN相关的数据库表记录，注意的是，这样修改不会马上在管理工具中生效，需要等待一段时间。

• Weblogic Server 无法连接到 LDAP 或无法找到用户/组来执行角色映射。
• 内嵌的 LDAP 锁定问题。
• 与客户端身份验证相关的性能问题。

1. Authentication Provider 无法连接到 LDAP。
2. 用户无法验证身份。
3. 用户可以验证身份，但 Authentication Provider 无法找到此用户所属的组。
4. 用户可以验证身份，但没有所需的角色。
5. 服务器因内嵌的 LDAP 锁定问题而无法启动。
6. 对 LDAP 的客户端身份验证速度太慢。

本文假定读者熟悉如何在WebLogic Workshop中构建和运行页面流。文中将会介绍三个特性：嵌套、声明性异常处理、Global.app。

嵌套

默认情况下，在一个新页面流中执行动作会导致当前页面流失效，这使得您可以为项目的不同部分创建独立的控制器，并最小化了每次用户会话需要保存的数据量。每个页面流管理它自己的状态和逻辑。在WebLogic Workshop IDE中，将控制权交给另外一个页面流用一个代表外部页面流的暗淡的终端节点表示。


想要更深入地了解高级页面流？请下载 本文附带的作者示例应用。
页面流嵌套使开发人员可以更好地将项目分解成独立的、自包含的功能块。它的核心功能是把当前页面流暂时放在一边，并将控制权交给另外一个页面流，该页面流将来会返回到原来的页面流。

什么时候应该使用页面流嵌套呢？当执行以下任务时嵌套十分有用：

• 从用户那里搜集用于当前页面流的数据
• 允许用户改正错误，或在执行特定动作的过程中提供额外信息
• 为当前页面流中的数据提供另外一种显示视图
• 显示在当前页面流中有用的用户信息（例如，帮助窗口）

如果颜色选择的部分更为复杂（比如在继续之前需要一个确认过程），就可以采用一个嵌套页面流来替代chooseColor.jsp，它同样可以满足要求（位于/simpleNesting/simpleNestingController.jpf）：

嵌套页面流的一个重要特性是它可以替代页面的许多工作。嵌套页面流可以启动动作，甚至可以进行“post”，或者用表单进行初始化。通常，总是可以用嵌套页面流来替代页面。以下是该嵌套页面流的流程视图/chooseColor/chooseColorController.jpf:

该页面流允许用户选择一种颜色，请求确认，然后在原来的页面流上启动一个动作。该页面流出于激活状态时，原来的页面流被保存在用户会话中（位于堆栈中）。当该页面流结束时，被保存的原页面流上的“chooseRed”或“chooseBlue”动作将被激活。

创建和使用嵌套页面流是相当简单的。页面流向导提供了一个“make this a nested page flow”选项，它可以用类一级的注解@jpf:controller将新页面流定义为嵌套页面流：

想让嵌套页面流在原页面流上启动一个动作，您可以定向到一个“退出节点”（页面流面板上的红色方块“Exit”），它的动作方法形如下面所示：

定向到@jpf:forward ——它定义了一个return-action而不是path——时，嵌套页面流就会退出。

下面介绍一个稍微复杂的例子。在/demoNesting/demoNestingController.jpf中，用户进入一个嵌套页面流（/chooseAirport/chooseAirportController.jpf），该页面流是帮助用户查找机场的向导。嵌套页面流将选定的机场返回（或者说“post”）到原页面流中，原页面流继续执行。

·如果嵌套页面流激活一个“chooseAirportCancelled”动作，页面流将会返回到刚才展示给用户的前一页面。这是通过在@jpf:forward中使用return-to属性达到的：

·当启动“chooseAirportDone”动作时，嵌套页面流会返回一个表单（FormData 类）。这些将在后面讨论，但值得注意的是：页面流处理该返回表单的方式与它处理页面post过来的表单的方式一样。

嵌套页面流如下，/chooseAirport/chooseAirportController.jpf：

唯一不同的地方在于：在原页面流中启动“chooseAirportDone”动作时将会同时返回一个表单。这是通过在@jpf:forward中使用return-form 属性实现的：

除了@jpf:controller nested="true" 声明、激活退出动作和返回表单的模式之外，声明嵌套页面流与声明非嵌套页面流一样。

其它注意事项

• 定向/重定向到一个嵌套页面流或在其上启动任何动作都会引发嵌套。原页面流被保存到“嵌套堆栈”中，直到嵌套页面流在@jpf:forward中使用return-action 属性来启动一个返回动作。
• 页面流可以自嵌套
• 在嵌套页面流的动作方法中，您可以通过调用PageFlowUtils.getNestingPageFlow( getRequest() ) 来获得原页面流的一个引用；
  
• 嵌套页面流（任何其它页面流也是这样）可以在begin动作方法中接收一个FormData类型的参数。
  

为了初始化嵌套页面流，原页面流可能会像下面这样定向到嵌套页面流：

• 嵌套页面流实际定义将要返回的表单（FormData 类）。这和页面的行为不同，后者只是简单地将数据作为request参数post过去，这些参数被添加（或诱骗到）到与将要启动的动作相关联的表单bean中。更为精确的嵌套页面流return-form行为可以嵌套两个启动同一动作的页面流。处理来自两个嵌套页面的动作类似下面这样：
  

异常处理

尽管可以在动作方法中通过编程来处理异常，但为了仅通过声明就可以处理异常，页面流还提供了一种更强大的框架。在动作方法和类级别上，处理异常的方式可以是直接定向到一个页面（或一个嵌套页面流），也可以是调用一个异常处理方法，由该方法决定下一步显示的页面。

直接定向到一个URI是处理异常最简单的方法：

在上面的例子中，当一个NotLoggedInException 异常被抛出时，用户将看到/login/loginController.jsp。当其它异常被抛出时，用户看到/error.jsp （注意：页面流异常处理总是试图先匹配那些最具体的异常）。异常自动被存储在request的 JSP 标签中，该标签可以显示异常信息和/或堆栈跟踪记录。

也可以用异常处理方法来处理异常。为此，请在@jpf:catch中使用method属性：

method属性指向一个异常处理方法，message-key 属性用来解析资源包中的某条信息，该资源包是通过@jpf:message-resources 标签（该标签负责在/WEB-INF/classes/exceptions/Messages.properties中查找资源）在类级别上声明的：

异常处理方法本身被定义成下面这样：

在本例中，该方法在request中保存异常类型和自定义信息（在@jpf:catch中通过message-key 属性定义），这样errorDetails.jsp就能够将它们显示出来。

Global.app

定义在/WEB-INF/src/global/Global.app的Global.app既是那些无法处理的动作和异常的最后处理者，也是保存会话范围状态的地方。自从任何一个页面流被请求开始，该类的一个唯一实例就被保存在用户会话中，并且一直存在直到会话结束。

在一个页面流中启动一个动作，但该页面流并不能处理这个动作，这时Global.app就会处理它。对于异常也是一样：如果异常在某个页面流中无法处理，Global.app将会处理它。下面的Global.app例子处理任何无法捕捉的Exception，并管理所有不由页面流处理的“goHome”动作。

如前所述，Global.app实例在整个用户会话中保持激活状态。想要从页面流中访问它的实例，需要做下面两件事情：

• 在页面流中声明一个特殊成员变量：protected global.Global globalApp。它会被自动初始化为当前Global.app实例，并可以在页面流的动作方法和生命周期方法（比如onCreate，beforeAction，afterAction）中使用。
  
• 调用PageFlowUtils.getGlobalApp( getRequest() );

可以使用“globalApp”数据绑定上下文从JSP中访问Global.app公共成员以及getter/setter方法：

一个高级例子

下面的例子用来演示嵌套、异常处理、和Global.app。在例子中，用户可以执行一个需要登录的动作（“doit”）。如果用户登录，页面流继续执行“doit”动作。否则一个异常将被迫抛出并被Global.app捕获，然后它将定向到一个嵌套登录页面流，在用户登录之后再重新返回“doit”动作。首先，我们来看看主页面流（/demoLogin/demoLoginController.jpf）：

该页面流中唯一特殊的地方就是“doit”动作的行为：

@jpf:action 中的login-required 属性在用户没有登录的情况下将会抛出一个NotLoggedInException 。这从逻辑上相当于明确地抛出异常：

当从doit中抛出NotLoggedInException时，该异常将被Global.app捕获，它将定向到嵌套页面流/login/loginController.jpf：

/login/loginController.jpf 如下：

当嵌套页面流启动“loginOK”动作时，它不被/demoLogin/demoLoginController.jpf 处理（仍是原页面流），而是被交给Global.app，Global.app在当前页面流——/demoLogin/demoLoginController.jpf——中重新运行先前的动作。

@jpf:forward 中的return-to="action" 属性使最近执行过的动作被重新运行；在本例中即是“doit”，现在它可以成功执行了。最后，如果嵌套页面流启动“loginCancel”动作，同样将会交给Global.app处理，Global.app将返回到当前页面流的前一个显示页面（仍然在/demoLogin/demoLoginController.jpf 中）。

在本例中，如果用户取消登录，他将重新回到起始页面。

　　本文是第2部分，介绍了一些实现上的底层支持技术，讨论与Documentum安全性的集成，并研究一些示例代码。这篇文章是在第一篇文章（可从Ness的Web站点上得到）所介绍的概念基础上形成的。

　　作为Documentum和BEA的合作伙伴，Ness科技受邀在 BEA的Workshop和Documentum基于服务的业务对象之间建立集成。这一集成包括控件、示例应用程序和集成的帮助，所有这些都可以在第一次使用控件时下载并安装到Workshop中。

　　DBOC是怎样集成到Workshop中的？
　　WebLogic Workshop引入了Java控件，把它作为一种封装业务逻辑、方便地访问企业资源的方法。为Workshop集成开发环境（IDE）提供的内置平台控件，可以连接数据库、EJB、消息队列等。

　　因为BEA致力于推广控件，所以他们使应用程序开发人员可以容易地建立自己的自定义控件，代表应用程序的具体逻辑，并为开发团队提供一套一致的工具。

　　为了进一步推动Java控件的创新，Workshop的8.12版本引入了一个扩展开发工具包，支持第三方控件和用户界面组件无缝地集成入WLW环境。DBOC就是这一新的扩展性框架的第一个实现。

　　我们会稍花一点时间来讨论这是如何办到的，因为大家可能想做类似的集成工作，把自己的自定义控件集成进IDE，其中可以包含利用DBOC的控件，但是当然不仅限于此。

　　在第一次安装WebLogic Platform 8.12版本时，在BEAHOME\ext_components文件夹里会放入一个 DocumentumBusinessObjectsControlStub.zip文件。

　　这个小小的压缩包里包含有关控件的足够信息（文本、图标、下载URL），所以它可以在Workshop的增加控件菜单里显示。

　　在准备第一次使用DBOC时， Workshop 会提示它还没有安装，然后会下载完整的控件档案压缩包DocumentumBusinessObjectsControl.zip，取代原来的存根文件。

　　然后，系统就会把BEADocumentumControlProj.jar文件插入当前项目的库文件夹，这样项目就可以使用其中的功能了（请看下图）。

　　Workshop还会把示例应用程序安装到BEAHOME\weblogic81\samples\partners\Documentum文件夹。最后，再把DBOC的帮助文件安装入Workshop的帮助系统，编排文件索引，使得可以在帮助的内容列表的扩展区域里使用DBOC的帮助。

　　有关扩展开发工具包的更多详细信息，可以在Workshop的帮助系统中找到，也可以在dev2dev.bea.com站点在线得到。

　　穿戴整齐，却无处可去
　　完成这一步骤后，像大多数控件一样，会弹出了一个向导，让您开始填写信息。

　　但是， Documentum 环境要求我们要特别注意几个项目。和许多其他实用控件（报表生成器之类的）不同，DBOC控件不是自包含的实体，它实际是一个达到更大型的运行系统的桥梁。可以把它当作到数据库系统的连接。您不该试图把整个数据库系统拷贝到每个J2EE应用程序项目。相反，您应当指定共享的数据库服务器的位置，然后访问这些资源。在使用DBOC的情况下，我们需要指定Documentum基本类库(DFC)资源在开发人员机器上的位置。DFC只安装一份非常重要，这样DFC才不会重复，特别是要考虑到实际只需要Documentum业务对象注册表（DBOR）的一个实例，这样所有的业务对象都会包含在一个位置（否则会带来维护上的麻烦）。

　　关于DFC资源，需要了解两个WebLogic环境。

• 需要更新Weblogic服务器域的SetDomainEnv.cmd 文件，以便在服务器的Classpath中可以找到DFC的jar文件。
• 需要设置Workshop IDE 的应用程序属性，以便IDE识别DFC和BOF资源。这样， Workshop 可以做一些有用的工作，例如语法检测、自动完成等。

　　探索DBOC
　　DBOC使得访问Documentum基于服务的对象非常简单。没有必要声明（或者根本不需要了解或考虑）home 和remote接口，只需要在向导中回答一些问题，就万事俱备了。

　　向导的头两步是所有Java控件都需要的公共步骤：

• 第一步是给控件代表的变量命名。
• 在第二步，确定是利用现有控件的.jcx文件或者让向导为您建立一个新的.jcx文件。在上面的屏幕中，我们正在建立一个名为inbox.jcx的新控件。
  在第三步，要提供针对于DBOC的信息。
• 所有的业务对象都在DBOR中注册。控件向导读取DBOR，并在下拉列表中列出所找到的全部SBO。
  
  
  上图只显示了默认的Documentum安装所提供的SBO。而在实际情况下，列表中会显示出所有从Documentum开发人员网站下载或者自行开发的SBO。
  
• 最后，为DFCSessionManager（SessionManager）对象提供访问SBO所必需的凭证信息。我们会在本文后面详细介绍这方面内容。
  点击Create按钮后，向导就会建立一个指向新的（或现有的）控件文件的变量。在上面的示例中，向导建立了inbox.jcx文件，并把它放在当前项目中。

　　控件文件里有什么？
　　DBOC不仅仅是SBO外面的简单包装器，它还加入了一些所有SBO都需要的实用特性。您的代码与代表SBO的控件进行交互。

　　在.jcx文件中的代码非常简单：

　　需要注意的关键一点是，控件文件本身只是扩展了SBO提供的Java接口以及DBOC自身提供的实用代码。向导对DBOR进行查询，然后建立新的接口，并把您提供的其他信息作为标签属性（docbase、 安全类型、用户名、口令） 保存在.jcx文件里。当在设计视图里查看控件实例时，控件的标签属性可以在属性编辑器中使用，可以在其中做任何必要的修改。

　　当WLW IDE 以图形方式显示控件时，它会枚举控件的所有可用方法，包括来自SBO的方法和来自控件的实用工具方法。

　　凡是以getSBO… 和setSBO… 前缀开始的方法，都是DBOC自己提供的实用工具方法。可以用这些方法取得和设置控件的属性。

　　需要记住，用这些前缀开始的方法不与SBO对话，它们只是引用控件的属性。提供这些方法是为了在运行的时候可以使用控件自身的信息。有人可能会说，前缀应当是getSBOControl…和setSBOControl…，但是开发人员一般喜欢简洁，所以更短的名字保留了下来。所有剩下的方法则都是SBO自身提供的功能。

　　SessionManager对象
　　SessionManager对象在DFC 5.1中引入，SessionManager对象是Documentum Business Object服务使用的所有会话所必需的接口。它负责集中实体、会话和事务。

　　DBOC设计用于减少需要手工编写的代码数量。所以，如果还不存在SessionManager对象，DBOC能够为您建立一个，这是合情合理的。

　　SessionManager对象负责表示试图访问SBO的Documentum用户的标识。即使SBO可能是不进行Docbase事务的Java代码，也是一样。

　　DBOC的安全类型属性接受三个值，分别代表处理用户凭证的三个不同方法：

• Registered Identity
  这个值来自控件向导中选择“Use control generated Session Manager with the following identity”（使用控件生成的具有以下标识的Session Manager）。它提供了最简单的认证方法。SessionManager由控件本身（不是由客户端代码）生成。客户端只需把用户ID、口令和Docbase设置成控件的属性。SessionManager会由控件在运行时生成，根据控制中设置的凭证进行连接。
• Principal Identity
  这个值来自控件向导中选择“Use control generated SessionManager for principal identity”（使用控件生成的代表主体标识的SessionManager）。这个选项便于使用Documentum的Principal Security。与Registered Identities一样，SessionManager也是由控件本身自动生成的。
  
  　　但是，必须使用控件客户端来创建并注册超级用户的凭证，并注册IdfPrincipalSupport对象。然后客户端只需把Principle User帐户设置为控件的属性。
  
  　　所以，您要提供能让SessionManager访问SBO的超级用户帐户名称和口令，还要提供没有口令的用户帐户名称（主体帐户）。SessionManager作用的时候，就好像主用户提供了正确的凭证一样。所有应用在用户帐户上的访问控制列表也都适用。
  　　对于超级用户执行管理性任务来说，这项技术特别有用，因为这些任务需要通过在运行时模拟用户来访问用户数据。
  
• Assign SessionManager at Run-Time
  
  　　当在控制向导中选择“Assign SessionManager at Run-Time”（在运行时分配SessionManager）时设置这个值。与前二个选项不同，这个选项要求控件客户端建立SessionManager对象，并把该对象作为控件的属性传入。它给控件客户端提供了最大的灵活性（当然在客户端代码需要的设置代码也最多）。在代码的其他地方已有SessionManager对象在使用时，这个选项最有用，有可能是在应用程序开始时设置一次SessionManager，而不用在控件初始化时设置。
  
  页面流示例的示例代码演示了用于以上全部三种场景的技术，可以用作建立自己代码的指导。

　　查看一些示例代码

　　下图显示了来自Web服务示例的代码片断。这个示例是个简单的演示，用DBOC访问用户的收件箱。它在收件箱项目之间循环，累计计数器，然后把收件箱中项目的数量返回给Web服务。

　　虽然这很基础，但是确实可以作为页面流示例的基础，可以采用这个技术，并在其上进行扩展，查询每个收件箱项目，然后把数据在Web页面上表示出来。

　　在写这篇文章的时候，关于收件箱SBO，几乎还没有公开的文档，所以这个代码恰好可以给您一个起步的地方。

　　为了让代码能够识别DFC API，需要在代码顶部加入import语句（一定记得服务器的Classpath已经更新，其中包含这些jar文件）。如果要访问另外的SBO，就必须更新Classpath，以便把它们也包含进来。

　　可以看到，下图是一段混合代码，既处理控件本身，也处理DFC。

　　在示例代码中，变量inbox是扩展SBO并具有DBOC实用工具方法的控件。

　　例如，第33行显示了一条语句如何能够根据控件的属性对SBO进行设置：inbox.setDocbase(inbox.getSBODocbase());

　　这条语句告诉系统把SBO的Docbase属性设置成控件的docbase属性中所包含的值（在设计时设置的）。

　　下面，我们开始处理DFC的IInboxCollection和IInboxItem接口。

　　在第39行，代码通过getItem方法，请求控件把所有收件箱项目返回到一个集合。

　　要想查看inbox控件其他可以使用的方法，只要输入inbox和一个句点，然后让Workshop弹出方法列表（下图是部分列表）即可。

　　代码剩下的部分就非常简单了；它对集合里的每个项目执行循环，增量计数器。循环完所有项目之后，方法就返回计数值。当然，这全都封闭在Try/Catch块里，以便捕获可能发生的任何错误。运行这个Web服务示例的结果就是一个简单的服务响应，在这个例子中，有三个收件箱项目被计数。

　　一旦您知道了如何与收件箱SBO建立基本的连接，您就可以使用其他收件箱方法了。

　　例如，如果您想修改页面流示例，让它按照发件人和日期对结果排序，您可以在用getItems方法填充集合之前，添加一个对setSortBy方法的调用。下面的代码根据发件人降序排列收件箱，在每个发件人里，则按发送日期升序排列。

　　inbox.setSortBy("sent_by DESC, date_sent ASC", true );
　　IInboxCollection iInboxCollection = inbox.getItems();

　　setSortby方法接受二个参数：

• 第一个参数是一个字符串，定义OrderBy子句，可以简单到就是一个字段名，也可以复杂到包含多个字段和方向。
• 第二个参数是一个布尔值，指明是否为更新的OrderBy子句（在这个例子里，必须为true）。

　　我们还要去哪里？
　　本文对于Documentum业务对象控件做了更进一步的考察。

　　Business Object Framework是Documentum的战略组成部分，DBOC是BOF与J2EE框架集成的第一个实现。就在我们完成的时候，其他使用WebLogic Workshop框架的开发人员可以利用新的扩展开发工作包把他们自己的控件、服务和帮助提供并集成到Workshop IDE中。

　　我们已经指出了一些DBOC提供的实用工具方法和安全性选项，利用它们可以在运行时使用SBO，从而实现更大的灵活性。最后，我们还显示了代码既需要处理控件本身，也需要处理SBO提供的方法。

　　DBOC允许您方便地把Documentum SBO集成到WebLogic Workshop环境。学习了这个集成，只需下载并安装WebLogic Platform，插入DBOC，修改一些WebLogic服务器的配置，并按照示例教程的指导即可。

　　作者注：特别感谢Documentum的Kevin O'Connor，感谢他创建DBOC项目，支持Java控件工作，以及对本系列文章所做的贡献。

　　如果对本文有疑问，，请联系作者： Alan Zenreich ，电话：201-488-7222 转160.

　　欢迎继续阅读本系列的第3部分

　　原文出处：
　　http://dev2dev.bea.com/products/wlworkshop81/articles/DCMT2.jsp

　　本文介绍了如何使用JDK5.0的新特性Annotation和Spring框架来实现一种简单的JavaControl框架，主要实现了成员变量的自动带入，以及方法调用的权限检查控制，同时实现了一个JavaDatabaseControl的扩展，模仿workshop中的对应功能。

目录：

环境
背景资料
JavaControl最基本的功能--声明注入
使用动态代理来增加横切
Control方法的权限检查
一个DatabaseControl的特例
关于Demo程序
框架如何的加强
感受
代码下载
参考文档

环境 (目录)

由于使用了Annotation，所以必须准备好JDK5.0

背景知识 (目录)

1）Annotation简介
　　在Java领域，最早的Annotation就是JavaDoc了，将文档直接写在源程序里极大的方便了文档的编写，后来出现了许多有这种同步需求的工作，大家便发明了XDoclet，使用类似于JavaDoc的语法撰写描述信息，并使用工具生成描述文件。到JDK5.0出现以前这种需求已经更多了，许多工具和框架已经通过各种方式实现自己的这种标记，.NET更是率先推出了语言级的支持，所以JDK5.0终于推出了自己的Annotation。
　　以下是两个简单的Annotation定义，定义的方式类似于接口，只是在interface前面多了个"@"

public @interface SampleAnnotation{
        String someValue;
}
public @interface NormalAnnotation{
      String value1;
      int value2;
}

　　然后我们在程序里可以这样使用Annotation，我们的编程工具或者是运行中的框架程序可以读取这些内容，生成代码或者是添加动作。

@SampleAnnotation (someValue ="Actual Value used in the program”)
public void annotationUsingMethod(){
      …
}

　　Annotation主要是给工具开发商和框架开发者使用的工具，一般的编程人员可能仅仅是使用其他人开发的Annotation。Workshop在两年前已经开始尝试在开发工具里运用Annotaion，但当时没有语言级的支持，所有的Annotation都是以注释的形式出现，这样虽然灵活但是不严谨，也不适于推广，所以Annotation的出现可以大大方便开发商的工作，使得许多小开发商以及一般的架构设计人员也可以利用这种方式编程。
注：本文中Annotation可能对应的名字是“注释”或者是“说明”

2）Spring和DI（IOC）简介
　　在我看来，Spring和Annotation能完成很多相似的工作，它们之间的区别是在解决问题的位置并不相同。
　　这是一个Spring的配置文件的信息，里面定义了三个bean，其中的exampleBean的属性中引用了其他的bean




bean="yetAnotherBean"/>

1



　　我们用以下方式调用

InputStream is = new FileInputStream("beans.xml");
XmlBeanFactory factory = new XmlBeanFactory(is);
Object o = factory.get("exampleBean");

　　通过以上方式我们可以得到一个exampleBean的实例,并且里面的一些属性已经被预先注入了。
　　在Spring结合了一些动态代理的以后，我们完全可以实现Annotation所能做到的许多功能。但是我们可以看出两种方式是不一样的，使用Spring面临着同步问题，维护配置文件比较的麻烦；而使用Annotation时，我们通常不容易在不改变原代码的时候改变一些特性，而且有时候也面临着代码复用的问题。本文并不讨论这些内容，本文里Spring只是一个bean的容器，用来存放JavaControl的注册信息，不会涉及依赖注入，而使用Annotation来完成相应的功能。
　　注：在本文里使用了两个配置文件，bean.xml放置了我们测试用的Control信息，在实际环境中可能需要不断添加新的Control。另一个配置文件是config.xml，里面是我们定义的ControlWrapper，每当我们增加一种Control的时候，如DatabaseControl的时候，就需要添加一个Wrapper。你应该首先看看这两个文件，里面有demo程序的配置以及注册的Control。

JavaControl最基本的功能--声明注入(目录)
　　在JavaControl里编程的时候，我们通常并不会显式的初始化JavaControl，因为具体的实现不应该在程序里绑定，而应该完全的面向接口编程，我们只是简单的在声明Control的地方加一句简单的注释：

    /**
    * @common:control
    */
   private myJavaControl.JCSecond jCSecond;   

　　然后在我们的Control里就可以直接使用jCSecond,如下: 

    /**
    * @common:operation
    */
   public String serviceA()
   {
       System.out.println("This is serviceA");
      return "This is serviceA"+":"+jCSecond.serviceB();
   }

　　Workshop>平台会根据这些注释，自动生成代码，来完成初始化jCSecond的动作，来完成注入的工作。而我们的程序会在程序运行中读取注释信息，来完成注入工作，这与workshop不同。 
　　至于这个接口具体要使用哪个实现类,大家可以看看workshop的打包文件的META-INFjc-jar.xml,里面有所有JavaControl的说明，包括接口和实现，这说明了我们以后可以改变实现。
　　下面我们实现自己的声明注入，这里我们需要一个JavaControlFactory类，作为进入Control环境的接口。两个Annotation，用来说明Control的实现类和包装器。JavaControlFactory类来读取Control中的注释信息，完成包装等工作。

1）首先我们需要定义一个修饰成员变量的Annotation，所有被当作Control的成员变量都可以使用这个annotation来说明，完整的定义如下：

package net.rocksun.tiffany.annotation;
import java.lang.annotation.*;

@Retention(java.lang.annotation.RetentionPolicy.RUNTIME)

@Target({java.lang.annotation.ElementType.FIELD})

public @interface Control {
       public String name();
}

　　这是个简单的annotation，@Retention说明本Annotation要保留到什么时候，因为我们需要在程序运行时动态的读取，所以设置为RUNTIME。@Target说明了本annotation所针对的对象，是FIELD。

　　我们在Control里这样使用这个annotation：

    @Control(name="second")
   private SecondControl second;  

　　name是SecondControl的实现类名称，我们在这里说明，然后通过JavaControlFactory来根据名字自动的将SecondControl实例化。

2）我们还需要一个说明类的ControlType，用来注释所有的Control类：

package net.rocksun.tiffany.annotation;

import java.lang.annotation.*;

@Retention(java.lang.annotation.RetentionPolicy.RUNTIME)
@Target({java.lang.annotation.ElementType.TYPE})
public @interface ControlType {
   public String name();
}

　　它也是运行级别保留，但它针对的对象是类，只有类可以使用这个annotation注释。name表示这个类需要的包装器，也就是用来对这个类进行特殊处理的类。
　　使用方式如下

.............
@ControlType(name="DefaultControl")
public class FirstControlImpl implements FirstControl {
.............

@ControlType(name="DefaultControl")说明这个类需要使用DefaultControl类型的包装器包装一下。

3）ControlFactory实现
　　我们希望从JavaControl中取得类的方式为FirstControl first = (FirstControl)factory.getControl("first");并且first中所有的标记为Control的成员变量都可以被正确的初始化。
　　所以我们的ControlFactory首先应该遍历类first的所有成员变量，当遇到使用Control注释的成员变量,根据它的类型进行实例化。以下是遍历所有成员变量的过程：