EJB e Design Patterns - Estou fazendo correto?

Estou com uma dúvida conceitual sobre EJB e Design Pattern, gostaria de saber se estou estruturando certo meu software.
Meu objetivo é o usuário fazer uma requisição através de uma pagina JSP, essa página chamar um modelo no banco de dados e me retornar todos os usuários cadastrados no sistema, estou estuturando mais ou menos assim.

JSP -> Apenas Visão
|
Action -> Recebe a requisição do usuário e chama um Business Delegate
|
BD -> Faz as operações de lookup para encontrar os objetos EJB
|
Session Bean -> Possui um objeto para capturar todos os clientes cadastrados e jogá-los em uma Collection. Nesse caso não se se devo chamar um DAO para fazer isso ou crio as regras de negócio dentro do método no SessionBean
|
BD -> Recebe a Collection e repassa para a Action do Struts
|
Action -> Recebe a collection, joga no request e da um forward para o JSP.

A primeira dúvida é relacionada ao SessionBean, se as regras de negócio devem ficar nele ou em um DAO?
A segunda é se a minha estrutura está ok? ou talves ela fique confusa…

Obrigado

A estrutura no meu ponto de vista está legal a única coisa que vou resaltar é que o seu SessionBean deve chamar o DAO invés de implementar a regra de negócio dentro dele, pois nesse caso, como é algo simples, pode ser feito no SessionBean, mas imagine um caso maior, onde deve-se acessar vários DAOs, outros SessionBeans, classes java e por ae vai, nesse outro caso o seu SessionBean se transforma no Pattern Session Facade.
Eu particularmente gosto de separar tudo, cada coisa com sua devida responsabilidade, então se vc vai fazer uma operação de banco de dados, faça dentro do DAO e no seu SessionBean chame essa operação :wink:

[quote=alex.lopes]
A primeira dúvida é relacionada ao SessionBean, se as regras de negócio devem ficar nele ou em um DAO?[/quote]

Nenhum dos dois.

Sua regra de negócio deve ficar em objetos de domínio, objetos que tenham significado dentro do sistema. Colocá-la em DAOs é o mesmo problema de colocá-los em StoredProcedures, colocá-la no EJB geralmente resulta num sistema não OO.

[]s

Fazer um projeto assim eh uma receita pro desastre. Voce esta desenhando o sistema com base em definicoes tecnicas, e nao em definicoes de negocio. Ao inves de pensar “eu preciso de um EJB assim e outro assado”, pq nao pensar em “eu preciso de um cara no meu sistema responsavel por Notas Fiscais”?

Eh uma mudanca sutil, mas que faz toda a diferenca, e vai te levar bem longe desse modelo. Voce vai acabar vendo que nao precisa de EJB pra muita coisa, e DTO/VO, menos ainda (preferencialmente, nenhum, ou apenas quando extremamente necessario devido ao trafego de rede excessivo).