E esse Jboss Seam? Como arquiteturar uma boa aplicação?

2 respostas
thebluefoot

Saudações!
Estou iniciando no Jboss Seam e gostaria de saber como vocês estruturam suas aplicações no framework.
Minha dúvida deriva em duas vertentes (a) e (b):
a) Os Session Beans que eu crio, anotados com as anotações EJB e Seam, podem ser interagidos através de outras fontes além do JSF, como um Web Service ou até mesmo uma apcalicação standalone via JNDI, correto?
Nesse caso, teríamos uma estrutura inicial com os seguintes pacotes:

app.negocio //(aqui ficariam os Session Beans, responsáveis por toda regra de negocio)
        app.dao //(camada que efetivamente usaria o entityManager para persistir, é usada pela camada de negócio)
        app.modelo //(classes de entidade)

b) Ou acaba-se escrevendo coisas específicas do framework como “redirecione para o JSP X” ou “exiba o widget de mensagem Y”, que um webservice ou uma aplicação standalone não entenderia?
Nesse caso, os senhores concordam que os Session Beans agem como controladores (estranho) específicos do Seam e não devem conter regras de negócio? Ficaria então:

app.seam //(session beans que encapsulam os métodos do negócio, assim um webservice, por exemplo, não precisa conhecer essa camada)
        app.negocio //(classes java (ou sesison beans também?) responsáveis pela regra de negócio)
        app.dao //(camada que efetivamente usaria o entityManager para persistir, é usada pela camada de negócio)
        app.modelo //(classes de entidade)

E então? o que ocorre na realidade?
atenciosamente,
bluefoot

2 Respostas

Alexandre_Saudate

Na realidade, muitas vezes está mais pra segunda opção, mesmo (os EJBs passam a ser controllers). Os EJB´s precisam retornar strings para que o Seam saiba pra onde redirecionar a aplicação. Note que essas Strings, no entanto, não precisam ter o formato “/editSeiLaOque.xhtml”, elas podem ser do tipo “OK”. A chatice é que, no caso de elas serem “OK”, é preciso configurar o JSF para que ele saiba pra onde redirecionar em cada caso.

No geral, o Seam é uma boa pedida. Não tanto por causa da integração com EJB pura e simplesmente, mas por causa das facilidades de gerenciamento dos EJB´s (persistência , transações, integração com jBPM, contexto de conversação, etc.). Sem contar que a implementação padrão já vem com JBoss EL, que é uma mão na roda.

Você perguntou quanto à integração desses EJB´s… todo EJB pode ser um web service, correto? Logo, sim, eles podem ser transformados em EJB facilmente, basta adicionar uma anotação (@WebService) e correr pro abraço.

Quaisquer dúvidas, avise!

[]´s

thebluefoot

asaudate:
Na realidade, muitas vezes está mais pra segunda opção, mesmo (os EJBs passam a ser controllers). Os EJB´s precisam retornar strings para que o Seam saiba pra onde redirecionar a aplicação. Note que essas Strings, no entanto, não precisam ter o formato “/editSeiLaOque.xhtml”, elas podem ser do tipo “OK”. A chatice é que, no caso de elas serem “OK”, é preciso configurar o JSF para que ele saiba pra onde redirecionar em cada caso.

No geral, o Seam é uma boa pedida. Não tanto por causa da integração com EJB pura e simplesmente, mas por causa das facilidades de gerenciamento dos EJB´s (persistência , transações, integração com jBPM, contexto de conversação, etc.). Sem contar que a implementação padrão já vem com JBoss EL, que é uma mão na roda.

Você perguntou quanto à integração desses EJB´s… todo EJB pode ser um web service, correto? Logo, sim, eles podem ser transformados em EJB facilmente, basta adicionar uma anotação (@WebService) e correr pro abraço.

Quaisquer dúvidas, avise!

[]´s

correto. obrigado.
Então acredito que minhas classes de negócio também devem ser EJBs, uma vez que é o negócio quem deve saber quem persiste, operações que merecem ser transacionais, etc.

Alguém mais tem alguma opinião para enriquecer nossa discussão? :smiley:

Criado 25 de agosto de 2010
Ultima resposta 25 de ago. de 2010
Respostas 2
Participantes 2