Componentização/Modularição de funcionalidade JSF

A utilização de web services para estas funcionalidades não atenderia, tipo, como é feito para pesquisa de CEP.

Acho que não, a não ser que desse imbutir uma tela dentro da minha página, tipo um applet. Porque o problema pra nós é ter que replicar o mesmo fonte em vários lugares. Isso pra um duas coisas é fácil (e dependendo da coisa pode até não ser), o problema é ter que fazer isso pra 10, 20 coisas.

Na especificação JEE o produto para se fazer isso é o EJB! Vc cria o projeto EJB que é justamente “um serviço” rodando dentro de um servidor com toda a regra de negocio sendo acessada por diversas aplicações clientes locais ou remota.
Mas, entretanto, e como a experiencia já nos mostrou nos últimos 10 anos, EJB vem com milhões de complicadores, abrindo algumas outras abordagens viáveis dependendo do cenário. Segue as opções

1. Criar uma projeto (JAR) simples que separe com a regra de negócio usando spring. A assim adicionando esse jar da regra de negocio fisicamente dentro de todos os outros projetos (outros jars ou wars) tb usando spring. Para automatizar esse processo, já vi empresas usando MAVEM com sucesso, ficando 100% transparente, funcional e viável.

2. Atualmente temos a especificação JEE 6 com “Web Profile” contendo recurso EJB locais (sem chamadas remotas). Caso se encaixar no seu cenário das solução que vão consumir essa regra central, vc pode opta por usar EJB Little.

3. Criar as regras de negócio dentro uma aplicação web usando Spring ou EJB Little, habilitando acesso remoto usando REST. Isso habilita as outras soluções/front-end remotos usar as mesmas regras de negocio via REST. O banco do brazil no ano passado migrou todas as chamadas remotas EJB 3.0 por essa abordagem. O pessoal apresentou para nos no JavaOne 2011 em SP.
   Nesse opção 3, o ideal hoje seria usar Web Profile com EJB little que ja vem com a especificação REST padrão do JEE no GlassFish (seria a minha opção escolhida).

Estamos ai para qualquer duvida…

Boa tarde Gerson,
Pode até haver outra solução melhor, mais a saida pra voce pode
ser usar facelets e tag lib.
Se não conheces facelets da uma pesquisada ñ é dificil de usar.
e depois que aprender é muito show para reaproveitar codigos.
e as taglibs tambem são pra reaproveitar codigos, tipos voces
criam as tag lib para reaproveitalas nos codigos evitando repetição de codigo.
da uma estudada nesses dois.
Mais minha dica é só pra camada view mesmo em um unico projeto.
boa sorte!

17/02/2012 15:35:45 Assunto: Re:Componentização/Modularição de funcionalidade JSF
Na especificação JEE o produto para se fazer isso é o EJB! Vc cria o projeto EJB que é justamente “um serviço” rodando dentro de um servidor com toda a regra de negocio sendo acessada por diversas aplicações clientes locais ou remota.

Pelo o que eu entendi do cenário ele não quer deixar somente a camada de negócios disponíveis para todos os módulos, ele quer também deixar a camada de View/Controller com inter-disponibilidade, e nesse caso EJB, Spring, Web Services não tem utilidade…

Eu não sei se entendi muito bem, mas de acordo com o que entendi seria mais menos:
Você tem N módulos, algumas views(Na realidade TODAS as camadas) são compartilhadas entre N desses N módulos e você quer evitar código redundante em qualquer camada, correto?

A dois cenários diferentes nesse caso:
1° - As regras de negocio são imutáveis entre os módulos, ou seja, todas as funcionalidades compartilhadas são exatamente IGUAIS.
Se for isso, uma solução possível seria criar um projeto com essas funcionalidades que serão comuns entre 2 ou mais módulos disponibilizar como uma aplicação implantada no servidor, e caso precise usar, redireciona para a aplicação.

2° As regras de negocio mudam de acordo com o modulo.
Se for isso, disponibilize as regras de negocio em um EJB ou WebService, crie Componentes Compostos que as utilizem e as chame nas views particulares de cada projeto.

não é uma boa pratica usar tais recursos para centralizar regras de negocio…kkkkk

Mas o problema é que ele não quer centralizar SÓ as regras de negócio. Ou pelo menos eu acho que não kkk

diegosammet é exatamente isso que precisamos e a sua 1ª opção funciona sim pro nosso caso. Inclusive algo parecido já foi feito aqui na empresa mas eu não tinha me tocado ainda :). A diferença no caso é que ao invés de ser disponibilizado funcionalidades, são disponibilizados os módulos com um só ponto de login.

Valeu pessoal pela ajuda. Se der tempo (muita correria ultimamente) posto aqui no que deu. Abraços