Olá
Nós dois teríamos gasto menos tempo se você tivesse explicado logo de cara.
Agora entendi. E continuo com a certeza de que o termo EJB não tem nada a ver com nosso papo. Você pode usar ou não mas a decisão não tem nada a ver com esta arquitetura que é bem semelhanto com a que eu já trabalhei.
Se as regras de negócio já existem e estão dentro do servidor que fornece as respostas via sockets, elas podem ser copiadas para uma outra aplicação que responda por web services ou via URA.
Provavelmente a solução adotada no servidor/socket servirá nas outras porém a melhor solução para as outras provavelmente não servirá para o servidor/sockets. Este último precisa responder rapidamente às maquinetas de cartão de crédito e sua principal qualidade é a rapidez na resposta. Usar EJBs aqui seria burrice. E acredite, eu já trabalhei em uma empresa que substituiu um servidor/sockets que respondia 200 tps por um outro que fazia persistência via EJBs 2.x e o throughput caiu para 8 tps. Depois de muitos meses e muita refatoração, conseguiram em casos especiais alcançar 40 tps.
Já para responder web services as exigências de throughput geralmente são mais brandas e para a URA então qualquer tempo de resposta serve (e tome musiquinha…)
Meu conselho é que deixe o servidor de sockets como está e crie as novas aplicações com a arquitetura mais adequada e mais simples possível
E use só o que conhece bem. Se ainda não sabe EJBs, faça persistência com Hibernate ou ActiveObjects.
[]s
Luca