EJB x WebService: Mais rápido?

Programação Java
#1

Bom dia pessoal!

Estou precisando que duas aplicações (ambas Java) se comuniquem, e não sei se devo usar EJB ou WebService (ou alguma outra sugestão).

A minha questão não é referente a tempo de desenvolvimento, custo, nem nada, o foco é: Qual é mais rápido na hora de se comunicar?

Aqui no GUJ já temos um tópico bem parecido com isso, onde foi questionado qual seria melhor de um modo geral, mas meu foco é somente no tempo da comunicação, uma vez que tenho um SLA muito curto para fazer várias consultas.

Poderiam me ajudar, por favor?

Servidor JBoss 5.1.

Muito obrigado,

Rodrigo

#2

EJB é mais rápido, sem dúvida nenhuma. Por usar RMI por baixo dos panos, os dados trafegados já estão em um formato que é interpretado mais rapidamente pelo Java, ao contrário de XML / JSON e afins.

[]'s

#3

É inválida a comparação uma vez que as tecnologias citadas possuem propósitos distintos.

#4

não sei dizer qual é mais rápido, embora o Alexandre tenha esclarecido bem essa questão.
mas acredito ser mais viável a implementação via EJB do que com WebService.
abs!

#5

[quote=asaudate]EJB é mais rápido, sem dúvida nenhuma. Por usar RMI por baixo dos panos, os dados trafegados já estão em um formato que é interpretado mais rapidamente pelo Java, ao contrário de XML / JSON e afins.

[]'s[/quote]

Primeiramente muito obrigado pela ajuda asaudate!

Olhando por esse lado que você mencionou, não seria ainda mais rápido usar RMI?

Aqui mesmo no GUJ achei um tutorial interessante: http://www.guj.com.br/articles/37

Depois vou ler com calma, mas seria mais rápido que EJB? Vê algum contra nisso?

Muito obrigado!

#6

[quote=gambazinho]não sei dizer qual é mais rápido, embora o Alexandre tenha esclarecido bem essa questão.
mas acredito ser mais viável a implementação via EJB do que com WebService.
abs![/quote]

Pensei nisso também, por causa da interpretação do XML do WebService que é um pouco “demorado”. Embora sinceramente não sei bem como funciona o EJB a fundo.

Muito obrigado!

#7

[quote=rodrigoalegre][quote=asaudate]EJB é mais rápido, sem dúvida nenhuma. Por usar RMI por baixo dos panos, os dados trafegados já estão em um formato que é interpretado mais rapidamente pelo Java, ao contrário de XML / JSON e afins.

[]'s[/quote]
Olhando por esse lado que você mencionou, não seria ainda mais rápido usar RMI?
[/quote]
Não seria ainda mais rápidos usar sockets?

Mas não é assim que a banda toca.

#8

[quote=rodrigoalegre][quote=asaudate]EJB é mais rápido, sem dúvida nenhuma. Por usar RMI por baixo dos panos, os dados trafegados já estão em um formato que é interpretado mais rapidamente pelo Java, ao contrário de XML / JSON e afins.

[]'s[/quote]

Primeiramente muito obrigado pela ajuda asaudate!

Olhando por esse lado que você mencionou, não seria ainda mais rápido usar RMI?

Aqui mesmo no GUJ achei um tutorial interessante: http://www.guj.com.br/articles/37

Depois vou ler com calma, mas seria mais rápido que EJB? Vê algum contra nisso?

Muito obrigado![/quote]

Não, teria uma performance muito próxima sem muitos ganhos. Lembrando que EJB utiliza o protocolo RMI/IIOP (RMI sobre IIOP), que é o RMI nosso de cada dia em cima do IIOP, que é basicamente um protocolo criado para prover mais interoperabilidade (que de interoperável não tem nada, mas isso a gente releva :wink: ). O fato é que usar RMI em várias máquinas pode ser incrivelmente mais chato do que usar EJB, já que EJB’s pelo menos têm a facilidade de serem registrados via JNDI, ao contrário do RMI puro. Além disso, o próprio desenvolvimento usando RMI é um pouco mais complexo do que usar EJB, pois é necessário compilar stubs/skeletons, processo que é transparente para quem usa EJB. Além disso, alguns Application Servers detectam quando o EJB está sendo executado localmente ou remotamente (para alguns, isso é independente do tipo de interface utilizado) e aí, otimiza o acesso, deixando de fazer acesso a várias camadas de rede, etc.

Ou seja, resumindo… acredito que o ganho de performance que você teria usando RMI puro seria muito pequeno em relação ao trabalho adicional .

[]'s

EDIT: Ah, além disso, notei que a necessidade é em relação a SLA. Talvez seja mais interessante checar gargalos maiores de memória, como tuning de banco de dados ou mesmo usar NoSQL, do que considerar coisas que vão além de EJB - incluindo RMI e Sockets.

#9

Concordo. EJB’s não são desenvolvidos para serem interoperáveis, então, tudo depende da necessidade arquitetural.

[]'s

#10

Pow perfeito asaudate, muito obrigado pela aula!

Vou com base na sua opinião então, valeu mesmo!

#11