Servicio de partición de área de trabajo

El servicio de partición de área de trabajo es una ampliación del servicio de área de trabajo que permite la creación de múltiples áreas de trabajo personalizadas. El servicio de partición de área de trabajo es un servicio opcional para los usuarios. Los usuarios que utilicen actualmente el servicio de área de trabajo y la partición de UserWorkArea pueden continuar utilizándola de la misma manera. El servicio de partición de área de trabajo crea la partición de UserWorkArea de forma automática (si no se ha inhabilitado). Al permitir a un usuario la opción de crear su propia partición de área de trabajo a través del servicio de partición de área de trabajo, éste puede tener más control sobre la configuración y acceder a su partición.

El servicio de partición de área de trabajo es básicamente una fábrica para crear instancias de la interfaz UserWorkArea. Las aplicaciones interactúan con áreas de trabajo utilizando la interfaz UserWorkArea y su implementación. Esta interfaz define todos los métodos para crear, manipular y terminar áreas de trabajo. El servicio de partición de área de trabajo permite que los usuarios creen sus propia instancia con nombre de la interfaz UserWorkArea. Cada instancia con nombre se denomina partición de área de trabajo definida por el usuario, o simplemente partición para abreviar. Cada instancia de la interfaz UserWorkArea (partición) está separada de otras particiones definidas por el usuario. Además, puede configurar una partición con varias opciones para proporcionar calidades de servicio que sean exclusivas de un caso de uso para un usuario individual. Cualquier opción de configuración realizada dentro del panel de servicio de partición del área de trabajo no tiene efecto alguna en el servicio del área de trabajo.

A diferencia de la partición de UserWorkArea, que se conoce públicamente, las áreas de trabajo creadas por el servicio de partición de área de trabajo sólo son conocidas y accesibles para la persona que las ha creado. Sin embargo, el servicio de partición de área de trabajo no aplica de forma estricta que el creador de la partición acceda y/u opere de forma exclusiva en ella. No existe ninguna limitación en caso de que el creador desee publicar su partición de área de trabajo y hacerla pública y disponible vinculando su referencia de partición en denominación Java o por otros medios. No obstante, el servicio de partición de área de trabajo intenta ocultar lo máximo posible una partición en el caso de que un usuario no desee que otras personas conozcan una partición concreta. El servicio de partición de área de trabajo no permite a una persona determinar o consultar los nombres de todas las particiones que se han creado; sin embargo, no restringe el acceso a las particiones por parte de usuarios que no sean el creador de esa partición. El ámbito del contexto de una partición, como la partición de como la partición de UserWorkArea o una partición o una partición definida por el usuario, se establece en una sola hebra y no pueden acceder a él varias hebras.

La partición de área de trabajo que se devuelve a un usuario implementa javax.naming.Referenceable y com.ibm.websphere.UserWorkArea, por ello, un usuario puede enlazar su partición con un nombre para hacer que dicha partición esté disponible públicamente. Una alternativa a la utilización de la denominación Java™ para vincular y acceder a la partición es utilizar la interfaz del gestor de particiones de área de trabajo. Todo el mundo puede acceder a la interfaz del gestor de particiones de área de trabajo; por lo tanto, si un usuario desea hacer pública y disponible su partición, sólo tiene que publicar su nombre de partición. Los demás usuarios pueden llamar al método getWorkAreaPartition en el gestor de particiones de área de trabajo con el nombre publicado.

El método WorkAreaPartitionManager.createWorkAreaPartition sólo se puede utilizar desde un cliente Java Platform, Enterprise Edition (Java EE). Para crear una partición de área de trabajo en el lado del servidor, se debe utilizar la consola administrativa. Se debe crear una partición de área de trabajo en el lado del servidor durante el arranque del servidor porque cada partición tiene que registrarse con la web y los colaboradores EJB (Enterprise JavaBeans) adecuados antes de que se inicie el servidor. Las particiones de área de trabajo personalizadas se crean mediante el servicio de partición de área de trabajo y se definen mediante la interfaz UserWorkArea.

El servicio de partición de área de trabajo también permite a un usuario configurar particiones con propiedades adicionales que no están disponibles en la partición de UserWorkArea, como la propagación bidireccional del contexto de partición de área de trabajo y la serialización de atributos diferida. Estas propiedades están disponibles como propiedades de configuración al crear una partición. Para obtener una lista completa de las propiedades de configuración que están disponibles al crear una partición, consulte la sección "Propiedades de partición de área de trabajo configurable" en el artículo de la interfaz del gestor de particiones de área. Las propiedades se definen de la manera siguiente:

Propagación bidireccional de contexto de área de trabajo

Si se emite una invocación remota desde una hebra asociada a un área de trabajo, se propaga automáticamente una copia del área de trabajo al objeto de destino, que puede utilizar o ignorar la información del área de trabajo según le convenga. Si la aplicación que realiza la llamada tiene un área de trabajo anidada asociada a ella, se propaga a la aplicación de destino una copia del área de trabajo anidada con todos sus antecesores. La aplicación de destino puede modificar la información localmente, según lo permiten las modalidades de propiedad, creando áreas de trabajo anidadas adicionales; esta información se propagará a cualquier objeto remoto que invoque.

El hecho de que los cambios en el contexto se propaguen a una aplicación de llamada desde una aplicación remota depende de la configuración de la partición de área de trabajo. Si un usuario crea una partición para que sea bidireccional seleccionando la propiedad Bidireccional al crear la partición, los cambios efectuados por una aplicación remota se propagarán también por la aplicación que realiza la llamada, lo que significa que los cambios efectuados en el contexto de área de trabajo por un proceso en sentido descendente se propagará en sentido ascendente. La partición de UserWorkArea no está configurada (y no se puede configurar nunca) como bidireccional, por lo tanto, los cambios en el contexto sólo fluyen en procesos en sentido descendente y no se propagan en sentido ascendente.

Ejemplo: propagación bidireccional de contexto de área de trabajo

El hecho de que los cambios en el contexto se propaguen a una aplicación de llamada desde una aplicación remota depende de la configuración de la partición de área de trabajo. Si un usuario crea una partición bidireccional, los cambios efectuados por una aplicación remota se propagan a la aplicación de llamada. Los cambios efectuados en el contexto de área de trabajo mediante un proceso en sentido descendente se propagan en sentido ascendente. La figura Distribución del contexto de área de trabajo cuando se ha configurado para realizar una propagación bidireccional ilustra esta relación durante una llamada remota al servidor. En el caso de esta ilustración, el cliente y el servidor deben haber creado una partición con el mismo nombre.

Figura 1. Distribución del contexto de área de trabajo cuando se ha configurado para realizar una propagación bidireccional. Esta figura ilustra la distribución del contexto de área de trabajo cuando el servicio está configurado para realizar una propagación bidireccional. Ejemplo de propagación bidireccional de contexto de área de trabajo

Cuando el cliente efectúa una llamada remota al servidor, el servidor recibe el contexto establecido por el proceso de cliente. El servidor realiza, a continuación, cambios en este contexto o lo añade. En esta ilustración, el servidor sobrescribe el valor en la clave1, elimina la propiedad en la clave2 y añade dos nuevas propiedades a la clave5 y la clave6. Cuando la aplicación del servidor vuelve al cliente, el contexto de área de trabajo se propaga al cliente y se desorganiza. El área de trabajo actual se actualiza, a continuación, con el nuevo contexto. Tenga en cuenta que, si la partición no está configurada como bidireccional y el servidor intenta cambiar o eliminar el contexto en el Área de trabajo 1, recibe una excepción com.ibm.websphere.workarea.NotOriginator, ya que el cliente era el originador del área de trabajo. El servidor puede recuperar el contexto en el Área de trabajo 1. Se trata de la principal diferencia entre la propagación bidireccional de contexto y la propagación no bidireccional.

Ejemplo: propagación bidireccional del contexto del área de trabajo anidada

Si una aplicación remota tiene que añadir contexto a un área de trabajo que sólo es utilizada por la propia aplicación o por otros objetos remotos, la aplicación remota debe iniciar otra área de trabajo. Al iniciar una nueva área de trabajo, el contexto adicional se circunscribe a esa aplicación y no fluye de nuevo a la aplicación de llamada. La ventaja más importante de la anidación de áreas de trabajo es que permite que una aplicación establezca el ámbito del contexto de área de trabajo en una aplicación determinada. Profundizando en la ilustración de un paso anterior, si el servidor ha iniciado un área de trabajo antes de sobrescribir el valor en la clave1, eliminando la propiedad en la clave2, o añadiendo nuevas propiedades en la clave5 y la clave6, estos cambios no se propagarían al cliente. Se muestra en la figura Distribución del contexto de área de trabajo anidado cuando se ha configurado para realizar una propagación bidireccional. También puede ver en esta figura que el cliente no recibe el contexto del área de trabajo anidada iniciada por el servidor.

Figura 2. Distribución del contexto de área de trabajo anidado cuando se ha configurado para realizar una propagación bidireccional. Esta figura ilustra la distribución del contexto de área de trabajo anidado cuando el servicio está configurado para realizar una propagación bidireccional. Ejemplo de propagación bidireccional de contexto de área de trabajo anidada

Serialización de atributos diferida de contexto de área de trabajo

Por omisión, en cada operación set, el servicio de área de trabajo serializa de forma automática el atributo establecido en un área de trabajo. En cada operación get posterior en ese mismo atributo se deserializa y vuelve al solicitante. Esto ofrece al servicio de área de trabajo un control total del atributo, de manera que los cambios en un objeto mutable no se reflejan en la copia del área de trabajo del atributo, a menos que un usuario restablezca de forma específica el atributo en el área de trabajo. Sin embargo, esto puede llevar a una serialización y deserialización excesiva.

Las serializaciones y deserializaciones excesivas pueden provocar una notable degradación del rendimiento en condiciones de cargas de gran tamaño. La propiedad de configuración de serialización diferida de atributos es una característica de almacenamiento en memoria caché que reduce las operaciones de serialización y deserialización. Cuando se habilita la serialización de atributos diferida en un cliente o en un proceso de servidor, si habilita el campo Serialización de atributos diferida durante la creación, los atributos establecidos en el servicio de área de trabajo no se serializan de forma automática durante la operación set. En su lugar, se almacena una referencia al atributo en el área de trabajo. Si el atributo es mutable, los cambios en el objeto se reflejan en la referencia a dicho atributo del área de trabajo. Cuando se realiza una operación get en ese atributo, se devuelve la referencia a ese objeto y no se lleva a cabo ninguna deserialización.

Los atributos no se serializan hasta que la hebra con la que está asociado el atributo realiza una invocación IIOP remota. En ese punto, el atributo se serializa y la forma serializada del atributo se almacena en memoria caché. Si el atributo no se restablece en el área de trabajo, los cambios en el atributo original aún se reflejan en el atributo contenido en el área de trabajo porque el área de trabajo todavía mantiene una referencia en memoria caché al objeto original. No obstante, si no se ha indicado al área de trabajo que el atributo ha cambiado restableciéndolo en el área de trabajo, las solicitudes remotas posteriores continúan utilizando la versión serializada en memoria caché del atributo y los cambios directos en el atributo mutable no se propagan. Existe una diferencia importante entre la habilitación y la no habilitación de la propiedad de configuración de la serialización diferida de atributos y los usuarios deben prestar mucha atención a esta diferencia y a cómo se manejan los objetos mutables al habilitar la serialización diferida de atributos. El servicio de área de trabajo libera referencias en memoria caché y versiones serializadas en memoria caché de atributos cuando se da una de las situaciones siguientes:

  • Se restablece o se elimina un atributo.
  • La aplicación completa de forma explícita el área de trabajo.
  • El componente de servidor finaliza la ejecución de la solicitud durante la que se ha iniciado el área de trabajo.
  • Termina el proceso de cliente que ha iniciado el área de trabajo.

Propagación de contexto de partición fuera de los límites de proceso

El contexto del área de trabajo se propaga del cliente al servidor cuando un cliente realiza una llamada remota a un servidor. Por ejemplo, si un cliente se ha configurado con tres particiones de área de trabajo distintas cuando realiza una llamada remota al servidor, el server1, el contexto asociado con cada partición en la hebra de cliente se propagará al server1. Si las mismas tres particiones se han creado en el server1, el contexto se desorganiza en la partición apropiada. No obstante, si ninguna de las tres particiones (o no todas ellas) se ha creado en el servidor1, sólo se desorganiza el contexto asociado con una partición que reside tanto en el cliente como el servidor. El contexto asociado con una partición que no reside en el servidor1 sigue residiendo en el servidor1, pero no se puede acceder a él. El contexto asociado con las particiones que no residen en el servidor1 debe seguir residiendo en el servidor1 en caso de que se realice otra llamada remota a un servidor distinto. Siguiendo un paso más allá, si el server1 efectúa una llamada a otro servidor, el server2, que tiene las mismas particiones que el cliente, el server2 recibe el contexto para las particiones que no residían en el server1. Las particiones que residen en el servidor1 y que no residían en el cliente ahora tienen su contexto propagado en el servidor2.

Para obtener más información acerca del área de trabajo, consulte el paquete com.ibm.websphere.workarea en la interfaz de programa de aplicación, API. La documentación de la API generada está disponible en la tabla de contenido del centro de información en Referencia > Interfaces de programa de aplicación - API.


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwa_partition
File name: cwa_partition.html