Como estruturar um sistema Java EE? Como é a aplicação prazo e, portanto, o conteúdo de um EAR definida?

Question

Eu estou no processo de concepção de um sistema de compilação e a estrutura de diretórios de um sistema de software de grande porte desenvolvido com Java EE 5. O sistema de construção vai ser implementado usando formiga.

Temos vários serviços diferentes, que estão agrupadas tematicamente. Cada serviço oferece tanto um serviço Web ou EJBs. Cada serviço é executado em um cluster de servidor de aplicativos dedicado. Assim, temos vários clusters e alguns desses grupos podem ser agrupados logicamente por tópicos.

Eu li definições genéricas e exemplos, mas eu ainda estou confuso sobre a terminologia Java EE:

• O que é uma aplicação Java EE? E assim, o que é o conteúdo de um arquivo EAR?
• O que é um projeto Java EE? (O termo é usado pelo Netbeans, bem como nas Convenções de Java Blueprints Projeto Diretrizes para Enterprise Applications)

Eu tenho que colocar todo EJB e WAR-pacote do módulo-arquivos em um único EAR, de modo que este único EAR contém o nosso sistema completo?

Ou eu colocar cada grupo de serviços em um EAR, apesar do fato de que estes serviços só são agrupados logicamente, mas não tecnicamente?

Ou eu montar um EAR separado para cada serviço, ou seja, na maioria das vezes contendo apenas um único arquivo JAR EJB e, por vezes, e EJB e um arquivo WAR?

Ou eu descartar o conceito de aplicações e apenas construir arquivos EJB e WAR, de modo que eu tenho exatamente um arquivo de implantação para cada cluster de servidor de aplicação?

Eu acho, minha pergunta principal é: Quais são as vantagens da embalagem de arquivos EAR

?

A meu ver, no momento, há apenas a necessidade de EAR-EJB e arquivos WAR e, adicionalmente, o conceito de subprojeto aninhada no-build-sistema de formigas e a estrutura de diretórios da nossa fonte?

Edit: Muito obrigado pelas respostas! Parece-me que um aplicativo empacotado em uma orelha é um subsistema em vez atômica. Então eu acho que vou ter um subprojeto-estrutura aninhada (lógico, visível apenas para o sistema de compilação e na estrutura de diretórios da fonte) e uma quantidade bastante grande de orelhas, cada um deles contendo principalmente apenas um ejb-jar e / ou módulo de guerra e implementação de um único serviço (que é implantado em um cluster único servidor de aplicativos).

Answer 1

Eu acho que o que você decidir colocar em cada orelha é regido por questões técnicas e organizacionais.

Eu acho que o mais importante papel técnico de uma EAR é uma raiz carregador de classe em um ambiente de tempo de execução. Isso normalmente significa que você pode implantar diferentes versões de bibliotecas e de suas próprias classes em diferentes da orelha. Isto significa que você deve manter o seu classpath raiz recipiente quase vazio (ou como fornecido pelo fornecedor do container), porque pode permitir que um recipiente phsyical de serviço múltiplas aplicações que utilizam bibliotecas possivelmente conflitantes. Esta é uma grande notícia, se você está desenvolvendo uma série de diferentes aplicações utilizando uma base de código comum. Você pode ter um número de projetos de implantação para o mesmo farm de servidores sem bagunçar um para o outro.

Você normalmente nunca implantar uma unidade menor de software do que a EAR. Cada EAR pode ser mais ou menos totalmente auto-suficiente. Eu normalmente deixar o conteúdo destes refelect o que a organização possuir pensa em como aplicações ou subsistemas. Normalmente você pode empacotar os mesmos componentes em vários ouvido de.

Answer 2

Muitas perguntas aqui.

projetos

Java EE são ou EAR ou WAR implantações que usam a tecnologia Java EE. Se você tem uma guerra com JSPs e JDBC acesso de um banco de dados relacional, que é um projeto Java EE. A intenção original era que os arquivos EAR foram "empresa", e que EJBs significava. Um arquivo EAR uma conter EJBs, guerras, JARs, o enchilada inteiro.

Thinking em termos de serviços são um pouco diferentes. Acho implantação merece cuidadosa consideração, porque os componentes que são agrupados devem ser trazidos para baixo e juntos se qualquer tipo de manutenção tem que ser feito.

Então, pense com cuidado sobre como você empacotar seus serviços. Não é uma resposta tudo ou nada cobertor, IMO. Você deve olhar para o que seus serviços estão fazendo e como eles podem ser usados ??juntos para decidir como devem ser empacotado e implantado.

Answer 3

considerações lógico e organizacionais entram em jogo. Cada EAR conteria todas as peças que estão relacionados para uma capacidade particular. Nós sempre podemos assumir que cada EAR será auto-contido e pode ser implantado em um ou mais recipientes. A abordagem típica que sempre seguido é ter cada orelha conter um ou mais frascos e guerras. Cada guerra ou frasco contém algum componente chave ou conjunto de componentes relacionados. A EAR representa uma aplicação empresa que contém os componentes e as aplicações web para a aplicação. Um exemplo é um sistema de processamento de pagamento I foi envolvido em. O EAR continha tudo o necessário para executar o sistema de processamento de pagamentos. Isto incluiu uma meia dúzia de frascos e 3 guerras. Cada frasco representado algumas funcionalidades ou agrupamento lógico de funcionalidade. Cada guerra representou um aplicativo web. Um exemplo da composição do frasco:

• um frasco para a funcionalidade do núcleo
• um frasco para EJBs
• um frasco para os nossos avançados peças de matemática financeira
• um frasco para os nossos pedaços de segurança etc. Tendo vários frascos foi ditada pelo fato de que diferentes pessoas desenvolveram diferentes peças para que eles trabalharam em diferentes projetos Eclipse e combinados-los todos como necessário. Não existem regras rígidas e rápidas, apenas o que funciona para sua equipe e situação.