[jboss-cvs] JBossAS SVN: r83837 - projects/docs/enterprise/4.3.3/Server_Configuration_Guide/zh-CN.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue Feb 3 22:11:14 EST 2009
Author: xhuang at jboss.com
Date: 2009-02-03 22:11:14 -0500 (Tue, 03 Feb 2009)
New Revision: 83837
Modified:
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/zh-CN/Clustering_Guide_Clustered_Singleton_Services.po
Log:
update
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/zh-CN/Clustering_Guide_Clustered_Singleton_Services.po
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/zh-CN/Clustering_Guide_Clustered_Singleton_Services.po 2009-02-04 02:39:09 UTC (rev 83836)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/zh-CN/Clustering_Guide_Clustered_Singleton_Services.po 2009-02-04 03:11:14 UTC (rev 83837)
@@ -1,24 +1,26 @@
+# translation of Clustering_Guide_Clustered_Singleton_Services.po to
# Language /tmp/mike/JBEAP420/JBAS translations for JBEAP package.
-# Copyright (C) 2007 Free Software Foundation, Inc.
+# Copyright (C) 2007, 2009 Free Software Foundation, Inc.
# Automatically generated, 2007.
#
msgid ""
msgstr ""
-"Project-Id-Version: JBEAP 420\n"
+"Project-Id-Version: Clustering_Guide_Clustered_Singleton_Services\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2009-01-20 02:37+0000\n"
-"PO-Revision-Date: 2001-02-09 01:25+0100\n"
-"Last-Translator: Automatically generated\n"
-"Language-Team: none\n"
+"PO-Revision-Date: 2009-02-04 13:10+1000\n"
+"Last-Translator: Xi HUANG\n"
+"Language-Team: <en at li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
+"X-Generator: KBabel 1.11.4\n"
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:5
-#, fuzzy, no-c-format
+#, no-c-format
msgid "Clustered Singleton Services"
-msgstr "群集的 JMS 服务"
+msgstr "群集的单点登录服务"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:6
@@ -32,13 +34,13 @@
"restarted on the new master. Thus, other than a brief interval when one "
"master has stopped and another has yet to take over, the service is always "
"being provided by one but only one node."
-msgstr ""
+msgstr "群集的单点登录服务（也称为 HA 单点登录）部署在多个节点上，但只在其中一个节点上提供其服务。运行单点登录服务的节点通常被称为主节点。当主节点发生故障或被关闭时，新的主节点将从剩下的节点里选择并重启服务。因此，除了在主节点停止而新主节点接替之间的短暂间隔，单点登录服务总是只由一个节点来提供。"
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:9
#, no-c-format
msgid "Topology after the Master Node fails"
-msgstr ""
+msgstr "主节点发生故障后的拓扑结构"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:17
@@ -52,13 +54,13 @@
"different nodes in the cluster start and stop; based on those notifications "
"each node in the cluster can independently (but consistently) determine if "
"it is now the master node and needs to begin providing a service."
-msgstr ""
+msgstr "JBoss 应用服务器（AS）为一些帮助你部署群集单点登录服务的策略提供支持。在本节，我们将探索不同的策略。所有这些策略都构建在前面介绍的 HAPartition 服务之上。它们依赖 <literal>HAPartition</literal> 来提供群集里不同节点启动和停止的通知；基于这些通知，群集里的每个节点都可以独立地（一致地）决定它是否成为主节点并开始提供服务。"
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:22
-#, fuzzy, no-c-format
+#, no-c-format
msgid "HASingletonDeployer service"
-msgstr "client-deployer-service.xml"
+msgstr "HASingletonDeployer 服务"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:23
@@ -79,6 +81,10 @@
"service when it stops being the master (typically at server shutdown) is to "
"undeploy the contents of <literal>deploy-hasingleton</literal>."
msgstr ""
+"部署 HA 单点登录服务的最简单和最常用的策略是采用普通的部署文件（WAR、EAR、JAR 等）并部署到 <literal>$JBOSS_HOME/server/all/"
+"deploy-hasingleton</literal> 目录而不是 <literal>deploy</"
+"literal> 目录下。<literal>deploy-hasingleton</literal> 目录不在 deploy 或 farm 里，所以当 AS 实例启动时它的内容不会自动部署。相反，部署这个目录下的内容是一个特殊服务的职责：<literal>jboss.ha:"
+"service=HASingletonDeployer</literal> MBean（它自身是通过 deploy/deploy-hasingleton-service.xml 文件部署的）。HASingletonDeployer 服务自己也是一个 HA 单点登录服务，它在节点成为主节点时部署 deploy-hasingleton 目录下的内容，并在该节点发生故障或关闭时卸载 <literal>deploy-hasingleton</literal> 下的内容。"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:26
@@ -89,14 +95,13 @@
"the master node cleanly shuts down, they will be cleanly undeployed as part "
"of shutdown. If the master node fails or is shut down, they will be deployed "
"on whatever node takes over as master."
-msgstr ""
+msgstr "所以，如果把你的部署放入 <literal>deploy-hasingleton</literal>，它们只会部署在群集里的主节点上。如果主节点正常地关闭了，它们将作为关闭过程的一部分干净地卸载。如果主节点发生故障或被关闭，它们将部署在接替的主节点上。"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:29
#, no-c-format
-msgid ""
-"Using deploy-hasingleton is very simple, but it does have two drawbacks:"
-msgstr ""
+msgid "Using deploy-hasingleton is very simple, but it does have two drawbacks:"
+msgstr "使用 deploy-hasingleton 非常简单，但它有两个缺点："
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:33
@@ -106,6 +111,8 @@
"hasingleton</literal>. Redeploying a service that has been deployed to "
"<literal>deploy-hasingleton</literal> requires a server restart."
msgstr ""
+"<literal>deploy-"
+"hasingleton</literal> 里的服务不能热部署。重部署 <literal>deploy-hasingleton</literal> 里已经部署的服务需要重启服务器。"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:38
@@ -116,13 +123,13 @@
"it will be providing services. Depending on how complex the deployment of "
"your service is and what sorts of startup activities it engages in, this "
"could take a while, during which time the service is not being provided."
-msgstr ""
+msgstr "如果主节点发生故障且另外一个节点接替称为新的主节点，在开始提供服务之前，你的单点登录服务需要完成整个部署过程。根据服务的部署复杂度以及启动行为，这个过程可能需要一段时间，在此期间无法提供服务。"
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:50
#, no-c-format
msgid "Mbean deployments using HASingletonController"
-msgstr ""
+msgstr "使用 HASingletonController 部署 Mbean"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:51
@@ -137,7 +144,7 @@
"on your service telling it to begin providing service. If it determines it "
"is no longer the master node, it invokes a method on your service telling it "
"to stop providing service. Let's walk through an illustration."
-msgstr ""
+msgstr "如果你的服务是一个 Mbean（也就是说，不是 J2EE 部署如 EAR 或 WAR 或 JAR），你可以用 HASingletonController 来进行部署使其称为单点登录服务。HASingletonController 的任务是和 HAPartition 服务一起监控群集并决定节点是否应该称为主节点。如果它决定一个节点称为主节点，它将调用服务上的一个方法来通知它开始提供服务。如果它决定节点不再是主节点，它也将调用服务上的一个方法来通知它停止提供服务。让我们来看一个演示。"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:54
@@ -147,7 +154,7 @@
"only thing special about it is it needs to expose in its MBean interface a "
"method that can be called when it should begin providing service, and "
"another that can be called when it should stop providing service:"
-msgstr ""
+msgstr "首先，我们想使一个 MBean 服务称为 HA 单点登录服务。唯一特殊的是它需要在其 MBean 接口上开放一个在应该开始提供服务时被调用的方法，以及一个在应该停止提供服务时被调用的方法。"
#. Tag: programlisting
#: Clustering_Guide_Clustered_Singleton_Services.xml:57
@@ -172,6 +179,24 @@
" } \n"
"} ]]>"
msgstr ""
+"<![CDATA[ \n"
+"public class HASingletonExample\n"
+"implements HASingletonExampleMBean { \n"
+" \n"
+"private boolean isMasterNode = false; \n"
+" \n"
+"public void startSingleton() { \n"
+"isMasterNode = true; \n"
+"} \n"
+". \n"
+"public boolean isMasterNode() { \n"
+"return isMasterNode; \n"
+" } \n"
+" \n"
+" public void stopSingleton() { \n"
+" isMasterNode = false; \n"
+" } \n"
+"} ]]>"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:59
@@ -179,7 +204,7 @@
msgid ""
"We used “startSingleton” and “stopSingleton” in the above example, but you "
"could name the methods anything."
-msgstr ""
+msgstr "在上面的例子里，我们使用“startSingleton”和“stopSingleton”，但你可以使用任何名字。"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:62
@@ -189,6 +214,8 @@
"it, most likely packaged in a .sar file, with the following <literal>META-"
"INF/jboss-service.xml</literal>:"
msgstr ""
+"然后，我们部署这个服务，以及控制它的 HASingletonController，通常是打包在 .sar 文件里并使用下列的 <literal>META-"
+"INF/jboss-service.xml</literal>："
#. Tag: programlisting
#: Clustering_Guide_Clustered_Singleton_Services.xml:65
@@ -223,12 +250,40 @@
" </mbean> \n"
"</server> ]]>"
msgstr ""
+"<![CDATA[\n"
+" <server> \n"
+" <!-- This MBean is an example of a clustered singleton --> \n"
+" <mbean code=\"org.jboss.ha.examples.HASingletonExample\" \n"
+" name=“jboss:service=HASingletonExample\"/> \n"
+" \n"
+" <!-- This HASingletonController manages the cluster Singleton --> \n"
+" <mbean code=\"org.jboss.ha.singleton.HASingletonController\" \n"
+" name=\"jboss:service=ExampleHASingletonController\"> \n"
+" \n"
+" <!-- Inject a ref to the HAPartition -->\n"
+" <depends optional-attribute-name=\"ClusterPartition\" proxy-"
+"type=\"attribute\">\n"
+" jboss:service=${jboss.partition.name:"
+"DefaultPartition}\n"
+" </depends> \n"
+" <!-- Inject a ref to the service being controlled -->\n"
+" <depends optional-attribute-name=\"TargetName\">\n"
+" jboss:service=HASingletonExample\n"
+" </depends>\n"
+" <!-- Methods to invoke when become master / stop being "
+"master -->\n"
+" <attribute name=\"TargetStartMethod\">startSingleton</"
+"attribute> \n"
+" <attribute name=\"TargetStopMethod\">stopSingleton</"
+"attribute> \n"
+" </mbean> \n"
+"</server> ]]>"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:67
#, no-c-format
msgid "Voila! A clustered singleton service."
-msgstr ""
+msgstr "好了，群集单点登录服务启动了。"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:69
@@ -244,6 +299,8 @@
"service could be primed and ready to go, just waiting for the controller to "
"implement startSingleton() at which point it can immediately provide service."
msgstr ""
+"这个方法一个明显的缺点是它只能用于 MBean。优点是上面的例子可以放入 <literal>deploy</literal> 或 "
+"<literal>farm</literal> 里，因此可以热部署或 farm 部署。而且，如果我们的示例服务具有复杂的、耗时的启动要求，那可以在 create() 或 start() 方法里实现。只要这个服务被部署，JBoss 将调用 create() 和 start()，而不会等到节点成为主节点。所以，服务已经准备好了，只要等控制器执行 startSingleton()，它就会马上开始提供服务。"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:72
@@ -254,6 +311,8 @@
"deployment descriptor (extracted from the <literal>deploy/deploy-hasingleton-"
"service.xml</literal> file):"
msgstr ""
+"上面讨论的 jboss.ha:service=HASingletonDeployer 本身是一个使用 HASingletonController 的例子。下面是它的部署描述符（从 <literal>deploy/deploy-hasingleton-"
+"service.xml</literal> 文件里抽取）："
#. Tag: programlisting
#: Clustering_Guide_Clustered_Singleton_Services.xml:75
@@ -279,6 +338,25 @@
" </attribute> \n"
"</mbean> ]]>"
msgstr ""
+"<![CDATA[ \n"
+"<mbean code=\"org.jboss.ha.singleton.HASingletonController\" \n"
+"name=\"jboss.ha:service=HASingletonDeployer\"> \n"
+" <depends optional-attribute-name=\"ClusterPartition\" proxy-type=\"attribute"
+"\">\n"
+" jboss:service=${jboss.partition.name:DefaultPartition}\n"
+" </depends> \n"
+" <depends optional-attributeame=\"TargetName\">\n"
+" jboss.system:service=MainDeployer\n"
+" </depends> \n"
+" <attribute name=\"TargetStartMethod\">deploy</attribute> \n"
+" <attribute name=\"TargetStartMethodArgument\">\n"
+" ${jboss.server.home.url}/deploy-hasingleton\n"
+" </attribute> \n"
+" <attribute name=\"TargetStopMethod\">undeploy</attribute> \n"
+" <attribute name=\"TargetStopMethodArgument\">\n"
+" ${jboss.server.home.url}/deploy-hasingleton\n"
+" </attribute> \n"
+"</mbean> ]]>"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:77
@@ -296,13 +374,13 @@
"singleton service's start/stop methods can take an argument, in this case "
"the location of the directory the <literal>MainDeployer</literal> should "
"deploy/undeploy."
-msgstr ""
+msgstr "这里有些有趣的东西。首先，被控制的服务是 <literal>MainDeployer</literal> 服务，这是 JBoss 里的核心部署服务。它在编写时并非是 <literal>HASingletonController</literal> 控制的服务，但它仍然可用！其次，目标的启动和停止方法是“deploy”和“undeploy”。它们并不需要特殊的名称，或者只要它们在逻辑上具有“start”和“stop”功能就可以了。这里被调用的方法的功能更象是“do”和”undo”。最后，请注意“<literal>TargetStart(Stop)MethodArgument</literal>”属性。你的单点登录服务的 start/stop 方法可以使用一个参数，在这个例子里是 <literal>MainDeployer</literal> 应该部署/卸载的目录。"
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:85
#, no-c-format
msgid "HASingleton deployments using a Barrier"
-msgstr ""
+msgstr "使用 Barrier 的 HASingleton 部署"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:86
@@ -312,7 +390,7 @@
"stopped whenever the content of deploy-hasingleton gets deployed/undeployed, "
"(i.e., whenever the current node becomes the master), need only specify a "
"dependency on the Barrier mbean:"
-msgstr ""
+msgstr "通常部署在 deploy 或 farm 下的服务在 deploy-hasingleton 的内容被部署/卸载时都会被启动/停止（例如，每当当前节点成为主节点时），它们只需要在 Barrier MBean 上指定一个依赖关系："
#. Tag: programlisting
#: Clustering_Guide_Clustered_Singleton_Services.xml:88
@@ -321,6 +399,8 @@
"<![CDATA[<depends>jboss.ha:service=HASingletonDeployer,type=Barrier</"
"depends>]]>"
msgstr ""
+"<![CDATA[<depends>jboss.ha:service=HASingletonDeployer,type=Barrier</"
+"depends>]]>"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:90
@@ -338,7 +418,7 @@
"Barrier MBean using the usual <depends> tag, and they will be started "
"and stopped in tandem with the Barrier. When the BarrierController is "
"undeployed the Barrier is destroyed too."
-msgstr ""
+msgstr "这个办法之所以可行是因为 BarrierController 和 jboss.ha:service=HASingletonDeployer MBean 一起部署并侦听 JMX 通知。BarrierController 一个相对简单的 Mbean，它可以订阅并接收系统里的任何 JMX 通知。它使用接收的通知来控制动态创建的名为 Barrier 的 Mbean 的生命周期。当 BarrierController 被部署时，这个 Barrier 被实例化、注册并带入 CREATE 状态。之后，当接收到匹配的 JMX 通知时，BarrierController 启动并停止 Barrier。因此，其他服务只需要用普通的 <depends> 标签就可以依赖于 Barrier MBean，它们将随着 Barrier 被启动和停止。当 BarrierController 被卸载时，Barrier 也会被销毁。"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:94
@@ -348,6 +428,8 @@
"can use farming to distribute the service, while content in deploy-"
"hasingleton must be copied manually on all nodes."
msgstr ""
+"这提供了 deploy-hasingleton 方法的一个替代方案，我们可以使用 farming 来分发服务，但 deploy-"
+"hasingleton 里的内容必须手工复制到在所有节点上。"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:97
@@ -359,6 +441,8 @@
"that will only deploy (instantiate/create/start) the contents of the deploy-"
"hasingleton directory on one of the nodes."
msgstr ""
+"从另一方面来说，barrier-dependent 服务将在所有节点上实例化/创建（例如调用任何的 create() 方法），但只在主节点上启动。这和 deploy-hasingleton 方法不同，它只在一个节点上部署（实例化/创建/启动）deploy-"
+"hasingleton 目录下的内容。"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:101
@@ -367,13 +451,13 @@
"So services depending on the barrier will need to make sure they do minimal "
"or no work inside their create() step, rather they should use start() to do "
"the work."
-msgstr ""
+msgstr "所以，依赖于 barrier 的服务将需要确保它们的 create() 方法里里只有最少或甚至没有任何步骤，这些步骤应该放到 start() 里完成。"
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:104
-#, fuzzy, no-c-format
+#, no-c-format
msgid "Note"
-msgstr "备注"
+msgstr "注意"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:105
@@ -386,12 +470,16 @@
"normal “undeploy” operation (like, for example, an <literal>EJBContainer</"
"literal>) will not have the desired effect."
msgstr ""
+"Barrier 控制依赖服务的启动/停止，但不控制其构析，这只发生在 <literal>BarrierController</"
+"literal> 自身被销毁/卸载时。因此，使用 <literal>Barrier</"
+"literal> 来控制需要被“销毁”的服务并作为“卸载”操作的一部分（如 <literal>EJBContainer</"
+"literal>）将不会获得想要的结果。"
#. Tag: title
#: Clustering_Guide_Clustered_Singleton_Services.xml:114
#, no-c-format
msgid "Determining the master node"
-msgstr ""
+msgstr "决定主节点"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:115
@@ -401,7 +489,7 @@
"that each node in the cluster can independently react to changes in cluster "
"membership and correctly decide whether it is now the “master node”. How is "
"this done?"
-msgstr ""
+msgstr "不同的群集单点登录管理策略都依赖于每个节点可以独立地响应群集成员资格的变动并正确地决定自己是否是“主节点”。这是怎么实现的呢？"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:118
@@ -417,6 +505,8 @@
"literal> mbean. Every member of the cluster will have the same view, with "
"the members in the same order."
msgstr ""
+"在 JBoss AS 4.2.0 之前，方法很简单且固定。对于群集里的每个成员，HAPartition Mbean 维护一个名为 CurrentView 的属性，它基本上是一个当前成员的排序列表。当节点加入和离开群集时，JGroups 确保每个活动的节点获得被更新的视图。要查看当前视图，你可以进入 JMX 控制台并查看 <literal>jboss:service=DefaultPartition</"
+"literal> Mbean 的 CurrentView 属性。群集里的每个成员都将有相同的视图，其中的成员按相同顺序排列。"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:121
@@ -427,7 +517,7 @@
"the order of nodes in the view will reflect the order in which they joined "
"the cluster (although this is not always the case, and should not be assumed "
"to be the case.)"
-msgstr ""
+msgstr "例如，假设我们有一个 4 个节点的群集，节点 A 到 D，当前的视图可表达为 {A, B, C, D}。通常来说，节点的顺序将反映它们加入节点的先后（但并非总是这样，我们不应该进行这样的假设）。"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:124
@@ -441,6 +531,8 @@
"<literal>HAPartition</literal> service knows that the view with respect to "
"the Foo service is {A, C, D} (no B)."
msgstr ""
+"假设有一个名为 Foo 的单点登录服务（如 <literal>HASingletonController</literal>）已经部署在群集里，但由于某种原因，没有部署在节点 B 上。<literal>HAPartition</"
+"literal> 服务维护一个关于服务的部署位置以及顺序的注册表。所以，在群集里的每个节点上，<literal>HAPartition</literal> 服务都知道关于 Foo 服务的视图是 {A, C, D}（没有 B）。"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:128
@@ -454,7 +546,7 @@
"independently decide if it is now the master. The Foo service on each node "
"does this by checking if they are the first member of the view – if they "
"are, they are the master; if not, they're not. Simple as that."
-msgstr ""
+msgstr "每当 Foo 服务的群集拓扑结构有改动，<literal>HAPartition</literal> 服务将调用 Foo 的一个回调方法来通知它新的拓扑结构。所以，例如，当 Foo 在节点 D 上他启动，运行在 A、C 和 D 上的 Foo 服务都通过回调方法被告知新的拓扑结构 {A, C, D}。回调方法给予每个节点足够的信息来独立地决定自己是否该成为主节点。每个节点上的 Foo 服务都通过检查自己是否是视图中的第一个成员来进行判断 - 如果是，它就是主节点；如果不是，则不是主节点。就是这么简单。"
#. Tag: para
#: Clustering_Guide_Clustered_Singleton_Services.xml:132
@@ -465,4 +557,5 @@
"A, C and D would get a callback with a new view for Foo of {C, D, A}. C "
"would remain the master – there's nothing magic about A that would cause it "
"to become the master again just because it was before."
-msgstr ""
+msgstr "如果 A 发生故障或关闭了，C 和 D 上的 Foo 将通过回调方法知道新的视图为 {C, D}。C 将成为主节点。如果 A 重启了，A、C 和 D 将通过回调方法知道新的视图为 {C, D, A}。C 仍然是主节点 - A 不会象之前一样是主节点了。"
+
More information about the jboss-cvs-commits
mailing list