Cara, arquiteturas engessadas são um grande problema, mas já que o seu problema é entender uma já definida, normalmente usam essa arquitetura da seguinte forma:
1 - Solicitação HTTP recebida pelo ActionServlet do struts e delegada ao seu Action.
2 - No action você vai chamar o Business Delegate, opcionalmente passando um Value Object com os dados
3 - O Business Delegate vai chamar o Service Locator para obter a referência do EJB, opcionalmente o service locator pode fazer cache dela.
4 - Uma vez com a referência do EJB, você invoca o método desejado, opcionalmente passando o VO como parâmetro.
5 - No seu EJB, que provavelmente é um Stateless Session Bean (ou uma session façade, pra sair bem na foto) você vai pegar a referência do DAO e invoca-lo.
6 - Agora é só retornar tudo até la em cima.
Só lembrando:
-
No action: Só logica de receber dados do usuário e exibir uma resposta, nada de passar o form pras camadas de baixo, crie um VO e repasse (o Dozer ajuda bastante com VO´s e forms parecidos). Sem nenhuma regra de negócio aqui.
-
No Business delegate: Essa camada só server para você localizaro responsável pelo processo de negócio (EJB) invocar o processo. Tem business no nome mas nada de negócio aqui.
-
No service locator: Aqui você só pega a referência do EJB via JNDI… JNDI só aqui, nada de fazer lookups em outros lugares… aqui você pode fazer cache das referências (pra stateless).
-
No EJB : Aqui é que você orquestra a transação. Aqui fica centralizada a regra de negócio.
-
No DAO, só acesso a banco, nada de um if “rs.getInt(1) == 0” pra verificar regras, isso tem que estar no EJB.
Bom, acho que no mais é isso aí cara… essa arquitetura é bem ultrapassada mas ainda tem muita gente socando isso em tudo quanto é sistema…
Espero que tenha tirado suas dúvidas,
[]´s
