Eu estou com a seguinte dúvida: Tenho um aplicativo Socket que faz uso de algumas regras de negocios. Preciso desenvolver agora um Web Service e um site quer irão utilizar tambem das mesmas regras. Visando o reaproveitamento de codigo, gostaria de saber a opinião de vocês se o EJB3 seria a melhor solução? Se não, o que eu deveria utilizar?
Lembrando somente que existe um grande trafego de informações no aplicativo socket.
O meu medo é de gerar uma alta taxa de dados na rede, e ela na aguentar, pois o aplicativo socket está em uma máquina e o EJB ficaria em outra.
O uso ou não de EJBs não deve ter nada a ver com o ser servidor que usa sockets e que já está em funcionamento. E não adote nenhuma medida em termos de arquitetura só com intuito de aproveitar código pois a vitima será você. Escolha a arquitetura mais adequada considerando o que já tem funcionando.
Pois intão.
O servidor socket já esta em funcionamento, perfeito. Agora preciso disponibilizar outras interfaces de acesso a essas regras de negocios, que seriam o Web Service e o site.
Então eu estava pensando em disponibilizar as regras de negocios utilizadas pelo aplicativo socket em um EJB, para que tanto o site, quanto o WS possam utiliza-las.
Eu só não sei se o EJB seria a melhor solução para isso. Alias, ainda não consegui achar outra solução, pois o meu conhecimento na area de JEE ainda é pequeno, estou meio inrolado no monte de siglas e soluções.
Existiria outra solução para esse problema? Pois se eu for pela cabeça dos programadores existentes aqui na empresa, eles iriam fazer eu copiar e colar as classes do projeto original(socket) e colar nos projetos ws e site. Isso funcionaria, mas qualquer mudança nas regras de negócio(coisa comum aqui na empresa) desencadearia serie de alterações em projetos diferentes. Ou seja, dor de cabeça!
O que vocês me sujerem? EJB mesmo, ou outra solução?
Nem consigo imaginar o que tem a ver EJBs com um servidor que trabalha por sockets. Acho que alguns conceitos estão misturados aí ou aqui.
Motivo forte para você nem passar perto de EJBs. Mesmo web services não parecem a solução ideal para trabalhar com um servidor que troca informações por socket.
Passe e receba as mensagens por socket e fim de papo. Só encontre um protocolo e um formato adequado para as mensagens. Em prol da sua felicidade futura, não faça RPC, isto é, não engrunvinhe seu sistema acoplando chamadas de métodos em outras aplicações. Apenas troque mensagens.
O aplicativo socket é utilizado por alguns clientes nosso. Mas esta entrando um novo cliente que solicitou a disponibilização de nossos serviços em Web Service. Eu já desenvolvi alguns Web Services, e já até fiz alguns EJBs! Estou estudando sobre, lendo artigos e foruns. Ai me pintou essa dúvida, se ele séria o ideal para o meu problema.
O servidor que trabalha por sockets, recebe os parametros, processa e retorna a string de retorno! Simples! Agora eu preciso fazer com que esse mesmo retorno vá via Web Service, utilizando as suas vantagens.
Com isso, eu gostaria de compartilhar a mesma regra de negocio nos 2 projetos. O meu problema é esse. Ai eu gostaria de saber se a minha solução seria EJB ou outra coisa que ainda desconheço.
Lembrando que o Web Service vai rodar em cima do JBOSS 4.2.2 em uma maquina, ja o aplicativo socket esta rodando em uma outra maquina diferente.
O que estou tentando dizer sobre EJBs é: não misture as coisas. Você pode usar EJBs e disponibilizar serviços através de web services. Mas não pode e nem deve disponibilizar serviços através de EJBs.
É por isto que eu digo que a decisão de usar ou não JBs não tem nada a ver com sockets e com web services. A motivação deve ser outra e nunca, mas nunca mesmo, usar EJBs só para aprender.
O ideal é que adote as soluções mais simples possíveis. Se eu estivesse no seu lugar talvez nem fizesse em Java e disponibilizaria os serviços de maneira mais simples possível. Só lembre-se que depois de disponibilizar um serviço para um cliente, sua empresa ficará escrava deste serviço. Portanto analise bem antes de mostrar o serviço ao mundo exterior.
Um, acho que a palavra serviço não fico bem pronunciada então.
A empresa que eu trabalho vende Consultas de Creditos SPC/SERASA.
Existe hoje um aplicativo JAVA socket que recebe conexões dessas maquininhas de cartão de credito para fazer esse tipo de consulta. Surgiu a necessidade agora de se fazer essas consultas via Web Service, e futuramente via URA.
Ou seja, serão 3 aplicativos utilizando a mesma regra de negocio. Correto?
Eu gostaria de saber qual é a melhor forma de disponibilizar essas regras para os 3 aplicativos?
Pensei em fazer isso em EJB, mas ai surgiu a duvida se essa seria a melhor solução. Pelo visto não né? Mas o que seria legal eu fazer então?
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.
Ahhh… acho que agora consegui fazer você intender o problema!!
Antes de qualquer coisa, obrigado pela paciência.
Bom, realmente o pensado foi de dar um ctrl+c nas regras de negocio do servidor/socket e um ctrl+v no projeto do Web Service. Mas o meu medo é que se daqui alguns meses sair alguma modificação nessas regras. Ai la vai eu tendo que alterar 2 aplicativos diferentes. =(
Mas no caso de utilizar a mesma regra pra Web Service e URA a melhor solução seria o EJB mesmo, pois o Web Service iria ficar em uma maquina e a URA vai para outra máquina.
Repare que não recomendei o Ctrl C + Ctrl V. Você pode colocar as regras em um jar e reutilizar o jar na outras aplicações. Mas pode também reescrever as regras de forma mais adequada às aplicações que não tem tanta necessidade de respostas rápidas.
Não concordo que este seja um motivo razoável para adotar EJBs em uma equipe que não domina esta tecnologia. Não excluo o uso deles mas não usaria para só fazer isto no seu caso. Se for só para reaproveitar as regras de negócio eu preferiria apenas instalar o mesmo jar em cada máquina.
Caso a equipe já dominasse bem os EJBs, aí sim seria plausível considerar a hipótese das aplicações trocarem mensagens assíncronas com auxílio do JBoss e das message driven beans .