Tópicos

IntroduçãoPara o início da página

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 ProcessoPara o início da página

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.

Diagrama descrito no texto de acompanhamento.

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:

Diagrama descrito no texto de acompanhamento.

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 AtivasPara o início da página

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 ModelagemPara o início da página

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.



Rational Unified Process   2003.06.15