工作区分区服务
工作区分区服务是允许创建多个定制工作区的工作区服务的扩展。工作区分区服务是一种用户可选服务。当前使用工作区服务和 UserWorkArea 分区的任何用户可以通过同样的方式继续使用它。UserWorkArea 分区由工作区分区服务自动创建(如果未禁用)。用户通过工作区分区服务可以选择创建自己的工作区分区,并且用户对于此分区的配置和访问可具有更多的控制权。
工作区分区服务基本上是一个用于创建 UserWorkArea 接口实例的工厂。应用程序通过使用 UserWorkArea 接口及其实现来与工作区进行交互。此接口定义了用于创建、操作和完成工作区的所有方法。工作区分区服务允许用户创建他们自己命名的 UserWorkArea 接口实例。每个命名的实例均称为用户定义的工作区分区或简称为分区。UserWorkArea 接口(分区)的每个实例与其他由用户定义的分区是分隔开的。此外,可以使用各种选项来配置分区以向个人用户的用例提供特有的服务质量。 在工作区分区服务面板中所作的任何配置选项均不会影响工作区服务。
与众所周知的 UserWorkArea 分区不同,只有创建者才知道工作区分区服务创建的工作区并能访问它。但是,工作区分区服务并未严格规定分区只能由分区创建者访问和/或操作。创建者可以随意发布他们的工作区分区,通过在 Java 命名中绑定他们的分区引用或通过其他方法使分区成为公用分区。但是,如果一个用户不希望他人知道某个分区,工作区分区服务将尝试尽可能隐藏此分区。工作区分区服务不允许任何人确定或查询已创建的所有分区的名称;但是,它不限制分区创建者之外的用户访问分区。分区的上下文(如 UserWorkArea 分区或用户定义分区)作用于单个线程并且不能由多个线程访问。
返回给用户的工作区分区引用将实现 javax.naming.Referenceable 和 com.ibm.websphere.UserWorkArea,因此,用户可以将他们的分区绑定到一个名称中以使他们的分区成为公用分区。使用 Java™ 命名来绑定和访问分区的另一种方法是使用工作区分区管理器接口。任何人都可以访问工作区分区管理器接口;因此,如果用户要使他们的分区成为公用分区,他们只需要发布其分区名。其他用户随后可以使用发布的名称调用工作区分区管理器接口中的 getWorkAreaPartition 方法。
WorkAreaPartitionManager.createWorkAreaPartition 方法只能用于 Java Platform, Enterprise Edition (Java EE) 客户机。要在服务器端创建工作区分区,那么必须使用管理控制台。在服务器端,必须在服务器启动过程中创建工作区分区,因为每个分区必须在服务器启动之前,向适当的 Web 和 Enterprise JavaBeans (EJB) 协调程序注册。定制工作区分区由工作区分区服务创建并由 UserWorkArea 接口定义。
工作区分区服务还允许用户使用 UserWorkArea 分区中不可用的其他属性(如双向传播工作区分区上下文和延迟属性序列化)来配置分区。这些属性在创建分区时可以用作配置属性。有关创建分区时可用的配置属性的完整列表,请参阅“工作区分区管理器接口”一文中的“可配置的工作区分区属性”一节。属性定义如下:
双向传播工作区上下文
如果从与工作区关联的线程发出远程调用,那么工作区的副本将自动传播到目标对象,目标对象可以根据需要使用或忽略此工作区中的信息。如果调用应用程序有关联的嵌套工作区,那么嵌套工作区的副本及其所有祖代都将传播到目标应用程序。目标应用程序可以通过创建其他嵌套工作区来本地修改信息(这是属性方式允许的);此信息将传播到目标应用程序调用的任何远程对象。
是否将上下文更改从远程应用程序传播回到调用应用程序取决于工作区分区的配置。如果用户通过在创建分区时选择“双向”属性将分区创建为双向,那么远程应用程序进行的更改将反作用于调用应用程序,这意味着下游进程对工作区上下文作出的更改将反作用于上游。UserWorkArea 分区未配置(并且始终不可以配置)为双向,因此,上下文更改仅流入下游进程,而不会反作用于上游。
示例:工作区上下文的双向传播
是否将上下文更改从远程应用程序传播回到调用应用程序取决于工作区分区的配置。如果用户创建了一个双向分区,远程应用程序所作的更改将传播回到调用应用程序。下游进程对工作区上下文所作的更改将传播回到上游。图 配置为双向传播时,工作区上下文的分发 说明了远程调用服务器期间的这种关系。在这个示例中,客户机和服务器必须已创建一个同名分区。

当客户机对服务器发出远程调用时,服务器接收到客户机进程设置的上下文。随后,服务器对这个上下文进行更改或向其中添加内容。在这个示例中,服务器覆盖key1中的值,移除key2中的属性并在key5和key6中添加了两个新属性。当服务器应用程序返回到客户机时,工作区上下文将传播回到客户机并进行取消编组。随后,将使用新的上下文更新当前工作区。请注意,如果分区未配置为双向,而服务器尝试更改或移除“工作区 1”中的上下文,那么它会接收到 com.ibm.websphere.workarea.NotOriginator 异常,因为客户机才是这个工作区的发起方。服务器可以检索“工作区 1”中的上下文。这是上下文双向传播与非双向传播之间的主要区别。
示例:嵌套工作区上下文的双向传播
如果远程应用程序需要向只有自己或任何其他远程对象使用的工作区中添加上下文,那么它必须启动另一个工作区。通过启动一个新工作区,所添加的上下文将作用于该应用程序并且不会流回调用应用程序。嵌套工作区的主要优势在于它允许应用程序将工作区上下文作用于给定应用程序。将示例再进一步,如果服务器在覆盖key1中的值、移除key2中的属性或在key5和key6中添加新属性之前已启动一个工作区;则那些更改不会传播回到客户机。图 配置为双向传播时,嵌套工作区上下文的分发 说明了这种情况。 从中您还可以发现客户机不会接收服务器启动的嵌套工作区的上下文。

工作区上下文的延迟属性序列化
缺省情况下,每次设置操作时设置到工作区的属性由工作区服务自动序列化。对同一属性的每个后续获取操作中,将反序列化该属性,然后返回给请求者。这让工作区服务完全控制了属性,从而使可变对象的任何更改不会反映在工作区的属性副本中,除非用户特地将属性重新设置到工作区中。但是,这可能导致过多的序列化和反序列化。
过多的序列化和反序列化在重负载下会导致性能明显下降。延迟属性序列化配置属性是一种高速缓存功能,它减少了序列化和反序列化操作。在客户机或服务器进程中启用延迟属性序列化时,在创建工作区的过程中通过选择延迟属性序列化字段,设置到工作区服务中的属性在设置操作过程中不会自动序列化。而是将属性引用存储在工作区中。如果属性是可变的,对此对象的更改将反映在工作区对该属性的引用中。对该属性执行获取操作时,将返回该对象的引用,但不执行任何反序列化。
仅当与属性关联的线程执行了远程 IIOP 调用后,属性才会序列化。此时,将对属性进行序列化并对序列化形式的属性进行高速缓存。如果未将属性重新设置到工作区中,那么对原始属性的更改仍将反映在工作区中包含的属性中,因为工作区仍然保持着高速缓存的原始对象引用。但是,如果未告知工作区已通过将属性重新设置到工作区更改了属性,那么后续远程请求将继续使用高速缓存的属性序列化版本,并且不传播对可变属性的直接更改。这是启用与不启用延迟属性序列化配置属性之间的重要差异,用户必须密切注意此差异以及启用延迟属性序列化时可变对象的处理方式。发生以下任何情况时,工作区服务将释放高速缓存的属性引用和属性序列化版本:
- 重新设置或移除属性。
- 工作区由应用程序显式完成。
- 服务器组件在启动工作区的过程中结束了请求执行。
- 启动工作区的客户机进程终止。
跨进程边界传播分区上下文
当客户机对服务器进行远程调用时,工作区上下文自动从客户机传播到服务器。例如,如果客户机对服务器 server1 进行远程调用时配置了三个不同的工作区分区,那么与客户机线程中的每个分区关联的上下文将传播到 server1。如果已在 server1 中创建了三个相同分区,那么上下文将取消编组到相应的分区中。但是,如果在 server1 上未创建或只创建了三个分区中的一部分时,那么仅对与同时驻留在客户机和服务器中的分区关联的上下文进行取消编组。与未驻留在 server1 中的分区关联的上下文仍驻留在 server1 中,但是无法访问它。对一台不同的服务器进行另一次远程调用时,与未驻留在 server1 中的分区关联的上下文必须仍驻留在 server1 中。具体而言,如果 server1 对与客户机具有相同分区的另一台服务器 server2 进行调用,那么 server2 将接收那些不驻留在 server1 中分区的上下文。驻留在 server1 中但未驻留在客户机中的任何分区现在将其上下文传播到 server2。
有关工作区的更多信息,请参阅应用程序编程接口 (API) 中的 com.ibm.websphere.workare 包。在信息中心目录中,生成的 API 文档的路径是:
。