Serviço de Partição de Área de Trabalho

O serviço de partição da área de trabalho é uma extensão do serviço da área de trabalho que permite a criação de diversas áreas de trabalho customizadas. O serviço de partição da área de trabalho é opcional para os usuários. Qualquer usuário que utilize o serviço de área de trabalho atualmente e a partição UserWorkArea pode continuar a utilizá-los da mesma maneira. A partição UserWorkArea é criada automaticamente (se não tiver sido desativada) pelo serviço de partição de área de trabalho. Quando os usuários têm permissão para criar sua própria partição de área de trabalho por meio do serviço de partição de área de trabalho, eles podem ter maior controle sobre a configuração e acesso de suas partições.

O serviço de partição da área de trabalho é essencialmente uma "fábrica" para criação de instâncias da interface UserWorkArea. Os aplicativos interagem com as áreas de trabalho utilizando a interface UserWorkArea e sua implementação. Essa interface define todos os métodos utilizados para criar, manipular e concluir áreas de trabalho. O serviço de partição da área de trabalho permite aos usuários criarem sua própria instância nomeada da interface UserWorkArea. Cada instância nomeada é chamada de uma partição da área de trabalho definida pelo usuário ou partição para atalho. Cada instância da interface UserWorkArea (partição) é separada de outras partições definidas pelo usuário. Além disso, é possível configurar uma partição com diversas opções para fornecer qualidades de servidos exclusivas para um caso de uso de um usuário individual. Qualquer opção de configuração feita no painel do serviço de partição da área de trabalho não afeta o serviço da área de trabalho.

Ao contrário da partição UserWorkArea, que é conhecida publicamente, as áreas criadas pelo serviço de partição da área são acessíveis e conhecidas somente pelo criador. No entanto, o serviço de partição de área de trabalho não impõe de maneira estrita que uma partição seja acessada e/ou operada exclusivamente pelo criador da partição. Não existem limitações caso o criador deseje publicar sua partição da área de trabalho e tornar disponível publicamente, ligando sua referência de partição em nomenclatura Java ou por outros meios. No entanto, o serviço de partição de área de trabalho tentará ocultar uma partição tanto quanto possível, se o usuário não desejar que outros usuários conheçam uma determinada partição. O serviço de partição de área de trabalho não permite que uma pessoa determine ou consulte os nomes de todas as partições que foram criadas; No entanto, ele não restringe que as partições sejam acessadas por outros usuários além do criador daquela partição. O contexto de uma partição, como a partição UserWorkArea ou uma partição definida pelo usuário, está com escopo definido para um encadeamento único e não está acessível por diversos encadeamentos.

A referência da partição da área de trabalho retornada a um usuário implementa javax.naming.Referenceable e com.ibm.websphere.UserWorkArea, portanto um usuário pode ligar suas partições a um nome para torná-las disponíveis publicamente. Uma alternativa para utilizar a nomenclatura Java™ para ligar e acessar a partição é utilizar a interface do gerenciador da partição da área de trabalho. Qualquer usuário pode acessar a interface do gerenciador de partição de área de trabalho. Portanto, se um usuário desejar disponibilizar sua partição publicamente, basta que ele publique o nome da partição. Outros usuários podem então chamar o método getWorkAreaPartition na interface do gerenciador de partição da área de trabalho com o nome publicado.

O método WorkAreaPartitionManager.createWorkAreaPartition pode ser usado apenas a partir de um Java Platform, Enterprise Edition (Java EE) client. Para criar uma partição de área de trabalho no lado do servidor, é necessário utilizar o console administrativo. No lado do servidor, uma partição da área de trabalho deve ser criada durante a inicialização do servidor, pois cada partição precisa ser registrada com os colaboradores adequados da Web e de EJB (Enterprise JavaBeans) antes do servidor ter sido iniciado. Partições de área de trabalho customizadas são criadas pelo serviço de partição de área de trabalho e definidas pela interface UserWorkArea.

O serviço de partição de área de trabalho também permite que um usuário configure partições com propriedades adicionais que não estão disponíveis na partição UserWorkArea, como propagação bidirecional de contexto de partição de área de trabalho e serialização de atributo adiada. Essas propriedades estão disponíveis como propriedades de configuração ao criar uma partição. Para obter uma lista completa das propriedades de configuração que estão disponíveis ao criar uma partição, consulte a seção "Propriedades de Partições das Áreas de Trabalho Configuráveis" no artigo da interface no gerenciador de partição da Área de Trabalho. As propriedades são definidas da seguinte maneira:

Propagação Bidirecional do Contexto da Área de Trabalho

Se uma chamada remota for emitida a partir de um encadeamento associado a uma área de trabalho, uma cópia da área de trabalho será automaticamente propagada para o objeto de destino, que pode utilizar ou ignorar as informações na área de trabalho, conforme necessário. Se o aplicativo responsável pela chamada possuir uma área de trabalho aninhada associada, uma cópia dessa área de trabalho e de todos os seus ascendentes será propagada para o aplicativo de destino. O aplicativo de destino pode modificar localmente as informações, conforme permitido pelos modos de propriedade, criando áreas de trabalho aninhadas adicionais; essas informações serão propagadas para quaisquer objetos remotos que ele chamar.

Se as alterações de contexto serão propagadas de volta para o aplicativo responsável pela chamada a partir de um aplicativo remoto, dependerá da configuração do partição da área de trabalho. Se um usuário criar uma partição bidirecional selecionando a propriedade Bidirecional durante a criação da partição, as mudanças feitas por um aplicativo remoto serão propagadas de volta ao aplicativo responsável pela chamada, o que significa que as mudanças feita para o contexto da área de trabalho por um processo de recebimento de dados serão propagadas de volta por envio de dados. A partição UserWorkArea não está configurada (e nunca poderá ser configurada) para ser bidirecional, portanto mudanças no contexto fluirão somente para processos de recebimento de dados e não serão propagadas de volta para envio de dados.

Exemplo: Propagação Bidirecional de Contexto de Área de Trabalho

Se as alterações de contexto serão propagadas de volta para o aplicativo responsável pela chamada a partir de um aplicativo remoto, dependerá da configuração do partição da área de trabalho. Se um usuário criar uma partição bidirecional, as alterações feitas por um aplicativo remoto serão propagadas de volta para o aplicativo responsável pela chamada. As mudanças feitas no contexto da área de trabalho por um processo de recebimento de dados serão propagadas de volta para envio de dados. A figura Distribuição do Contexto da Área de Trabalho Quando Configurado para Propagação Bidirecional ilustra este relacionamento durante uma chamada remota para o servidor. Para essa ilustração, e o cliente e o servidor devem ter criado uma partição com o mesmo nome.

Figura 1. Distribuição do Contexto da Área de Trabalho Quando Configurado para Propagação Bidirecional. Esta figura ilustra a distribuição do contexto da área de trabalho quando o serviço é configurado para propagação bidirecional. Exemplo de propagação bidirecional de contexto de área de trabalho

Quando o cliente faz uma chamada remota para o servidor, o servidor recebe o contexto configurado pelo processo do cliente. Em seguida, o servidor faz alterações no contexto ou faz adições. Nessa ilustração, o servidor sobrescreve o valor da key1, remove a propriedade da key2 e adiciona duas novas propriedades à key5 e key6. Quando o aplicativo do servidor retorna ao cliente, o contexto da área de trabalho é propagado de volta para o cliente e desempacotado. Em seguida, a área de trabalho atual é atualizada com o novo contexto. Note que se a partição não está configurado como bidirecional e o servidor tenta alterar ou remover o contexto na Área de Trabalho 1, ele recebe uma exceção com.ibm.websphere.workarea.NotOriginator, porque o cliente foi o originador da área de trabalho. O servidor pode recuperar o contexto na Área de Trabalho 1. Esta é a principal distinção entre a propagação bidirecional de contexto e a propagação não bidirecional.

Exemplo: Propagação Bidirecional de Contexto de Área de Trabalho Aninhada

Se um aplicativo remoto precisar incluir contexto em uma área de trabalho que seja utilizada apenas por si mesma ou por qualquer outros objetos remotos, o aplicativo remoto deve iniciar outra área de trabalho. Ao iniciar uma área de trabalho nova, o contexto adicional estará com escopo definido para esse aplicativo e não fluirá de volta ao aplicativo do responsável pela chamada. A vantagem principal de áreas de trabalho aninhadas é que as áreas de trabalho aninhadas permitem que um aplicativo limite o contexto da área de trabalho a um determinado aplicativo. Considerando a ilustração um pouco mais além, se o servidor tiver iniciado uma área de trabalho antes de sobrescrever o valor na key1, removendo a propriedade na key2, ou adicionando novas propriedades na key5 e key6, essas alterações não serão propagadas de volta para o cliente. Isso é mostrado na figura Distribuição do Contexto da Área de Trabalho Aninhada Quando Configurado para Propagação Bidirecional. É possível também verificar a partir dessa figura se o cliente não recebe o contexto da área de trabalho aninhada iniciada pelo servidor.

Figura 2. Distribuição do Contexto da Área de Trabalho Aninhada Quando Configurado para Propagação Bidirecional. Esta figura ilustra a distribuição do contexto da área de trabalho aninhada quando o serviço é configurado para propagação bidirecional. Exemplo de Propagação Bidirecional de Contexto de Área de Trabalho Aninhada

Serialização de Atributo Adiada do Contexto da Área de Trabalho

Por padrão, em cada operação definida, o conjunto de atributos em uma área de trabalho é automaticamente serializado pelo serviço de área de trabalho. Em cada operação get subsequente nesse mesmo atributo, ele é desserializado e retornado para o solicitante. Isso dá ao serviço de área de trabalho um controle completo do atributo, de forma que qualquer alteração a um objeto mutável não será refletida na cópia da área de trabalho do atributo a não ser que um usuário reconfigure o atributo especificamente na área de trabalho. Contudo, isso pode resultar em serialização e desserialização em excesso.

Serialização e desserialização excessivas podem resultar em degradação considerável de desempenho em situações de carga pesada. A propriedade de configuração adiada de serialização de atributo é um recurso de cache que reduz as operações de serialização e de desserialização. Quando a serialização de atributo adiada é ativada em um processo de cliente ou de servidor, selecionando o campo Serialização de Atributo Adiada durante a criação da área de trabalho, os atributos configurados no serviço de área de trabalho não serão automaticamente serializados durante a operação de configuração. Em vez disso, uma referência ao atributo será armazenada na área de trabalho. Se o atributo for mutável, as alterações do objeto são refletidas na referência da área de trabalho para o atributo. Quando uma operação get for executada naquele atributo, a referência àquele objeto será retornada e nenhuma desserialização será executada.

Os atributos não são serializados até que o encadeamento ao qual o atributo está associado faça uma chamada IIOP remota. Nesse ponto, o atributo é serializado e a forma serializada do atributo é armazenada em cache. Se o atributo não for redefinido na área de trabalho, as alterações no atributo original ainda serão refletidas dentro do atributo contido na área de trabalho porque a área de trabalho ainda mantém uma referência ao objeto original no cache. No entanto, se a área de trabalho não tiver informado que o atributo foi alterado redefinindo-o na área de trabalho, solicitações remotas subsequentes continuarão a utilizar a versão serializada do cache do atributo e as alterações diretas no atributo mutável não serão propagadas. Essa é uma distinção importante entre permitir ou não permitir a propriedade de configuração de serialização adiada do atributo e um usuário deve prestar muita atenção a essa diferença e em como objetos mutáveis são manipulados quando a serialização adiada de atributo é permitida. O serviço de área de trabalho libera referências em cache e versões serializadas em cache de atributos quando qualquer uma das seguintes situações ocorrerem:

  • Um atributo é redefinido ou removido.
  • A área de trabalho é explicitamente preenchida pelo aplicativo.
  • O componente do servidor para a execução do pedido durante o qual a área de trabalho foi iniciada.
  • O processo do cliente que iniciou a área de trabalho é finalizado.

Propagação de contexto de partição em limites do processo

O contexto da área de trabalho é propagado automaticamente de cliente para servidor quando um cliente faz uma chamada remota para um servidor. Por exemplo, se um cliente estiver configurado com três diferentes partições da área de trabalho ao fazer uma chamada remota para um servidor, server1, o contexto associado a cada partição no encadeamento do cliente será propagado para o server1. Se as mesmas três partições foram criados no server1, o contexto será desempacotado para a partição apropriada. No entanto, se nenhuma ou somente algumas das três partições tiverem sido criadas no server1, apenas o contexto associado a uma partição que seja residente no cliente e no servidor será desempacotado. O contexto associado a uma partição não residente no server1 ainda será residente no server1 mas não será acessível. O contexto associado a partições que não são residentes no server1 devem permanecer residentes no server1, caso outra chamada remota seja feita para outro servidor. Indo um pouco mais longe, se o server1 fizer uma chamada para um outro servidor, server2, que possui as mesmas partições que o cliente, o server2 receberá o contexto para as partições que não eram residentes no server1. Todas as partições que residem no server1 que não residem no cliente, agora terão seu contexto propagado para o server2.

Para obter mais informações sobre área de trabalho, consulte o pacote com.ibm.websphere.workarea na Interface de Programação de Aplicativos (API). A documentação da API gerada está disponível no índice do centro de informações, no caminho Referência > APIs - Interfaces de Programação de Aplicativo.


Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwa_partition
Nome do arquivo: cwa_partition.html