Diretrizes: Descrevendo a Arquitetura de Tempo de Execução para Aplicativos J2EE
Tópicos
Introdução
A arquitetura de tempo de execução de um aplicativo é descrita na Visualização do Processo,
uma visualização de arquitetura que descreve os elementos coincidentes de um sistema. Essas
diretrizes fornecem orientação específica sobre como modelar a Visualização do Processo de um
Aplicativo J2EE.
Consulte também Conceitos: Visualização do Processo.
Modelando a Visualização do Processo
Os componentes J2EE (consulte Conceitos:
Visão Geral do J2EE: Componentes J2EE) são implementados em ambientes chamados Contêineres.
Consulte Conceitos: Visão Geral
do J2EE: Contêineres J2EE para obter uma descrição de cada um dos tipos de contêineres
definidos pelo J2EE.
Cada contêiner é um elemento coincidente e, assim, deve aparecer na Visualização
do Processo da arquitetura. Outros elementos coincidentes importantes que normalmente
aparecem na visualização do processo de alto nível são sistemas externos.
A seguir, um diagrama típico da visualização do processo de alto nível para um
Aplicativo J2EE.

Em um exemplo real, veríamos um MOM (Message Oriented Middleware) do fornecedor específico
representado, assim como sistemas legados e clientes aplicativos específicos.
Entretanto, o Contêiner de Web e o Contêiner EJB são contêineres padrão que devem
aparecer em todas as visualizações de processos do J2EE.
Observe que esse diagrama não mostra a distribuição física desses sistemas
sobre os nós específicos de hardware. Isso é mostrado no Modelo de Implementação (consulte Diretrizes:
Descrevendo a Distribuição para Aplicativos J2EE).
Neste exemplo, vemos os mecanismos de comunicação entre processos selecionados
utilizados entre os contêineres. O J2EE fornece mecanismos de comunicação entre processos
específicos. São eles:
- Java RMI (Remote Method Invocation) para comunicação síncrona entre
as classes Java
- RMI-IIOP para interoperação com clientes CORBA (normalmente, aplicativos legados)
- HTTP/HTTPS para comunicação com clientes com base na Web (embora outros protocolos da
Web também possam ser suportados, como ao interagir com serviços da Web XML)
- JMS (Java Message Service) para sistema de mensagens e interações com o MOM
Ao definir a visualização do processo, uma decisão importante é quando utilizar o JMS versus
RMI ou RMI-IIOP. Neste exemplo, o Cliente Aplicativo, o Contêiner EJB e
Outro Sistema Legado utilizam o sistema de mensagens para a comunicação. Entretanto, não está claro
quais elementos comunicam-se entre si. Para solucionar a ambigüidade, considere a eliminação
do Sistema MOM do diagrama e a apresentação do JMS como a associação entre os
elementos que se comunicam pelo sistema de mensagens.
Outra ambigüidade é se os EJBs comunicam-se entre si mesmos por meio do sistema de mensagens.
Isso pode ser esclarecido mostrando uma associação do JMS do contêiner EJB para
si mesmo. O diagrama final fica então:

A visualização do processo, entretanto, representa mais que apenas contêineres e sistemas de alto nível.
Ela trata também da coincidência nesses contêineres e sistemas.
A visualização do processo deve identificar e modelar os tipos de classes ativas a seguir.
- encadeamentos Java
- destinos das mensagens
- beans orientados a mensagens (porque são chamados assincronicamente por meio das mensagens).
Consulte Diretrizes: Identificando Enterprise JavaBeans
para obter os estereótipos específicos utilizados para modelar os beans orientados a mensagens.
- processos adicionais que fazem parte do design geral do sistema. Um processo
de cronômetro separado é um exemplo desse processo.
Ao utilizar o JMS, você pode optar por relacionar diretamente os produtores e consumidores de mensagens
ou modelar o relacionamento mais precisamente pela modelagem dos tópicos e filas.
São utilizados diagramas de interação para mostrar as comunicações síncrona e assíncrona
entre os elementos de design. Também é possível utilizá-los para analisar comportamento coincidente
para problemas de desempenho e de lógica. Especificamente, o arquiteto de software pode
procurar sistemas de mensagens freqüentes ou altos volumes de transferência de dados na rede.
Isso pode fazer com que o arquiteto reprojete as interfaces ou redesigne os elementos de design
entre os encadeamentos de controle, entre os servidores ou entre os clientes e servidores.
Observe que em um contêiner EJB, os encadeamentos e os processos são gerenciados pelo
contêiner EJB - os EJBs não podem criar ou gerenciar encadeamentos. Logicamente, todo EJB deveria
ser considerado uma classe ativa, entretanto, já que as chamadas para beans de sessão e beans de
entidade são chamadas de bloqueio síncronas, geralmente elas não são modeladas como classes
ativas. A visualização do processo de um contêiner EJB está limitado geralmente a um
mecanismo de coincidência disponível - JMS com beans orientados a mensagens
do JMS.
Embora os beans de sessão e os beans de entidade não são geralmente modelados como classes
ativas, há problemas de coincidência - tal como um EJB que lê o banco de dados
enquanto outro grava. Esses problemas são manipulados por meio das transações. A abordagem
da utilização de transações deve ser documentada nas diretrizes específicas do projeto.
Alocando Elementos de Design para Classes Ativas
A Atividade: Descrever a Arquitetura de Tempo de Execução
fala sobre a necessidade de alocar elementos de design para processos e encadeamentos.
Em um Aplicativo J2EE, todos os componentes da Web são alocados para o Contêiner de Web
e todos os EJBs para o contêiner EJB. Como esse é um relacionamento simples, não
há necessidade de modelar essa alocação.
Se, entretanto, seu design incluir processos coincidentes adicionais (como
dois clientes aplicativos diferentes), talvez seja útil especificar quais elementos
de design executar em cada aplicativo.
Para encadeamentos Java, beans orientados a mensagens e tópicos e filas JMS, o problema
está mais relacionado a como será feita a intercomunicação entre eles, para evitar conflito,
dados inconsistentes, etc. Isso é melhor explorado examinando-se realizações de
caso de uso que incluam esses elementos.
Outras Alternativas de Modelagem
Em razão da afinidade entre a Visualização do Processo e a Visualização da Implementação, os diagramas
de alto nível para essas visualizações são sempre combinados.
Além disso, como cada contêiner J2EE não é apenas um processo, mas também um ambiente de
execução, ele pode ser modelado como um "nó lógico", em vez de uma
classe ativa.
|