Pessoal, temos aqui uma aplicação voltada para um dado segmento do mercado, é uma aplicação de gerenciamento que envolve vários módulos (Administrativo, RH, Financeiro, Relatórios especializados, Comunicação e por ai vai), a questão é que estamos planejando a evolução deste software, ou seja, agregar novos módulos a ele, e minha duvida é como arquitetar um software web em java que facilite a inclusão de novos módulos, eu vejo que em php quando baixamos por exemplo um CMS qualquer ai e eu desejo adicionar a ele novos módulos, eu copio para uma pasta determinada os arquivos php e depois só peço para a aplicação instalar aquele módulo, pois um arquivo de configuração já é reconhecido pela aplicação.
Enfim, é possivel fazer algo similar em java? Vejo que em java a necessidade de configuração de um web.xml e outros (arquivos de configuração das frameworks e por ai vai) complicam muito essa questão de junção de módulos em uma aplicação, estou errado?
Cheguei a pensar em criar cada módulo como uma aplicação diferente, disponibilizada em contextos diferentes, e trocando informações via web-services quando necessário uma buscar informações de outra, estaria este pensamento correto?
Pensando aqui, enquanto escrevo este texto, estou supondo que implementação de cada módulo como um portlet seria a solução, seria isto o mais correto? Mas mesmo que seja (caso me confirmem), existe outra solução recomendada? Pois acho que para uso de portlet eu teria que ter como base uma espécie de sistema de gestão de conteudo que implementasse tal especificação né.
É isso ai pessoal, conto com a ajuda e experiência de vocês em mais essa dúvida.
Todos os seus módulos são em Java? Se sim, que tal usar EJB?
Cada módulo seria uma aplicação distribuída. Se quiser que um módulo use outro, basta que este tenha um client daquele outro para fazer o lookup.
Sim, todos os meus módulos são em java, mas o problema principal não é implementar o modulo de forma bem coesa para que eu possa se quiser utilizar até objetos distribuidos, minha duvida principal é elaborar uma arquitetura para que criando novos módulos eu integre estes novos módulos à minha aplicação de um jeito prático e fácil. Imagine que eu queira disponibilizar meu software para download, dai o cliente baixou e instalou no tomcat dele na maquina dele, e amanha eu fiz um novo modulo e vendi pra ele, dai que eu quero disponibilizar para download somente um zip, contendo meus jsp, imagens, e jar’s correspondentes, para que quando descompactado sejam colocados na aplicação que ele já instalou lá e então a partir dai o novo modulo já passa a poder ser utilizado. Esse seria o cenario ideal ao meu ver, portanto não sei é como arquitetar uma solução java web que me auxilie neste sentido. O que tenho mais proximo até agora seria realmente criar cada novo modulo como um sistema diferente e faze-los conversar via web-service, seria uma especie de SOA né, mas já vi o povo falando que não faz sentido utilizar este tipo de solução quando se tem a mesma tecnologia aplicada em todos os módulos, porque não faria sentido? qual a melhor solução entao?
Continuo achando que EJB é a melhor solução para o seu caso.
Pense em cada módulo como uma aplicação diferente. Suponha que, inicialmente, você tenha 2 módulos e uma aplicação WEB utilizando as funcionalidades deles. Seu cliente terá então 2 EARs (módulos) e um WAR (app web) com seus JSPs, os clients dos módulos (JARs) e etc dentro dele, rodando num servidor de aplicação. Beleza.
Então você cria mais um módulo e precisa que a sua aplicação web passe a utilizá-lo. Seu cliente precisará então fazer o seguinte: 1) deploy de mais um EAR no servidor de aplicação (EAR do módulo novo). 2) redeploy da sua Web App (WAR) agora com o client (JAR) do seu novo módulo.
Isso funciona. Só não sei se é a melhor forma pra seu caso específico.
Uma solução simples:
1 - Crie o menu principal de seu sistema, onde são listado os módulos em um arquivo separado.
2 - Quando o usuário comprar um módulo novo, crie um instalador que substitui este arquivo em disco.
3 - Instrua o usuário a reiniciar a aplicação, assim irá aparecer a opção nova no menu para o usuário.
Claro que esta é uma solução que exige que seus módulos sejam desenvolvidos de uma maneira a compartilhar as informações necessária.
Uma opção seria enviar o sistema completo, então o usuário compra o novo módulo e vc libera a funcionalidade com o arquivo externo proposto acima.
Se você optar por projetos separados precisará de um deploy de cada módulo, e creio que isto não seja uma opção no seu caso, porém a mesma idéia acima pode ser utilizada, mapeie seus módulos no sistema de maneira que quando vc descompactar o módulo novo ele apenas contenha as classes prontas para uso.
De qualquer forma, vamos ver as opiniões, é um assunto interessante.
[]'s
Você está trabalhando com lagum framework web? A maioria deles permitem que você tenha vários arquivos de configuração que funcionam da maneira como você quer.
Quanto ao EJB, ainda tenho um certo receio, seria esta mesma a solução mais aconselhada? Em um EAR eu consiguo embutir jsp’s e outros resources como imagens a serem utilizados na minha camada de visualização?
Quanto a ideia do Aleck achei bem simplória mas interessante, acredito que esta seja a alternativa mais simples e fácil de ser implementada. No entanto, vejo que ela não exige muita separação entre os módulos, ou seja, ela permitiria ao sistema que cada um de seus módulos fossem altamente acoplados, o que não é bom, além do que, tenho minhas dúvidas principalmente quanto a segurança de acesso a tais módulos, já que isto estaria muito ligado ao menu e se o usuario souber a url de acesso eu teria que barrá-lo então via um filtro de autorização por exemplo.
Phillip quanto ao framework web, este sistema foi desenvolvido tendo como base o STRUTS. Mas mesmo que ele não dê o suporte citado por você, agradeceria muito se me indicasse outros que ajudam em tal situação. Seria possível eu ter um struts-config.xml para cada módulo, e todos os módulos em uma só aplicação?
Quanto a segurança do arquivo, seria necessário implementar algum tipo de criptografia neste arquivo e aplicar o filtro no Struts.
Quanto a ter multiplos arquivos de configuração do struts, retirei da própria página do struts:
http://struts.apache.org/1.x/userGuide/configuration.html
5.3.1 Module Configuration Files
Back in version 1.0, a few "boot-strap" options were placed in the web.xml file, and the bulk of the configuration was done in a single struts-config.xml file. Obviously, this wasn't ideal for a team environment, since multiple users had to share the same configuration file.
Since version 1.1, you have two options: you can list multiple struts-config files as a comma-delimited list, or you can subdivide a larger application into modules.
With the advent of modules, a given module has its own configuration file. This means each team (each module would presumably be developed by a single team) has their own configuration file, and there should be a lot less contention when trying to modify it.
Agora quanto ao uso de EJB:
Creio que você não entendeu o contexto que o Adolfo quis explicar sobre o uso de EJB, vou tentar exemplificar, inclusive para ver se eu entendi a idéia dele.
Temos 2 Aplicações utilizando EJB, cada uma provê um arquivo jar client:
MODULO 1 - EAR 1 - jarClient1
MODULO 2 - EAR 2 - jarClient2
Temos uma aplicação WEB, esta aplicação utiliza os jars client:
APP WEB 1
jarClient1
jarClient2
Cliente compra novo módulo:
Ações
DEPLOY MODULO 3 - EAR 3 - jarClient3
Inclusão do jarClient 3 na APP WEB 1
REDEPLOY da APP WEB 1
Questiono a utilidade dos EJB neste caso, pois seria mais fácil você entregar um novo “pacote” para o cliente fazer Deploy, este incluiria o novo módulo do sistema, com pouco trabalho para seu time.
Quando digo pacote, estou me referindo a sua aplicação mãe já acoplada ao seu módulo novo.
[]'s
É exatamente isso que você entendeu, aleck.
EJB me veio à cabeça justamente por ele precisar ter módulos que “conversem” entre si. Acho que com EJB essa integração entre os módulos seria bem fácil.
E essa abordagem que eu sugeri tem o inconveniente de, no caso de qualquer alteração de alguma interface de um módulo, obrigar a atualização do client nas Web Apps que utilizam aquele módulo.
Realmente não sei se dei a melhor idéia, porém vale para a discussão.