Pergunta

Estou planejando uma webapp, onde cada cara usando ele teria uma cliente que iria executar cálculos em seu computador (porque estes cálculos não pode ser feito no servidor, muita carga...) e, em seguida, enviar os resultados para o servidor.

Eu acho que vai haver muita gente interessada na minha aplicação e é por isso que eu sou de saber se a minha arquitetura é bom e se eu vou ser capaz de lidar com milhares de pessoas.

Eu estou planejando para expor remoto EJB através de JNDI com o Glassfish server, para 1000 pessoas, poderia usar esses EJB ao mesmo tempo (eu acho que não poderia ser 5-50 pedidos / segundo) para obter os dados necessários para o local de computação, e, em seguida, enviar os resultados...

É caro para expor EJB para muitos clientes?Seria melhor usar webservices, rmi, outra solução?

Você poderia me recomendar outra arquitetura para o que eu vou fazer?

Foi útil?

Solução

Em primeiro lugar, de um puro ponto de vista arquitetônico, EJBs são utilizados para a construção de aplicações distribuídas, os serviços Web são uma tecnologia de integração, e eles realmente não competir uns com os outros.No seu caso, EJB seria uma escolha natural (estamos a falar de EJB3, certo?) e beans de sessão escala muito bem.

Em segundo lugar, se o código do lado do servidor é usado apenas para recuperar dados de um banco de dados e salvar os resultados depois de lado do cliente de cálculo e, em seguida, o servidor de aplicativo muito provavelmente não ser o gargalo, o banco de dados.Em outras palavras, não há muito com que se preocupar.

Assim, desde que os seus clientes são todos os 100% de clientes de Java, gostaria apenas de expor beans de sessão sem estado1 e evitar a sobrecarga de SOAP/XML empacotamento/unmarshaling e escrita WSDL (se um dia precisar de expor seus serviços como web services, este ainda seria possível, e fácil).

1 Usando JPA ou alguma coisa para o acesso a dados é deixado ao seu critério.

Outras dicas

Meu 2P é que oferecer um cliente WebService ou XML/HTTP é mais fácil e mais padrão do ponto de vista do cliente. Um benefício é que eles não precisam ser clientes Java se for um serviço de sabão.

Eu li em um fórum que poderia ser uma má idéia recuperar entidades no cliente porque o proxy é mantido e gera tráfego

Um cara testado e uma lista serializada de 40ko de 300 objeto gerado por 3,6mo de rede de rede no Wireshark, mas se você usar entityManager.clear () para destacar as entidades ou usar o tipo de retorno POJOS para funções remotas, então está ok :)

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top