estou no meio de uma discussão acirrada com minha equipe de desenvolvimento em relação ao uso de Web Services em nossa nova versão do aplicativo web.
Nosso aplicativo irá usar EJB 3 e JSF, logo teremos um EAR e um WAR, a princípio rodando dentro do mesmo JBOSS (ou Websphere).
Os defensores do Web Service são a favor de que a comunicação entre EJB e Web seja inteiramente feita através de Web Services. Eu faço parte do outro lado da discussão, e sou a favor de expormos via Web Services só os métodos que deverão ser chamados por aplicativos terceiros (mobile, por exemplo).
Na minha opinião, a utilização indiscriminada de Web Services iria adicionar mais uma camada de complexidade, sem contar o tráfego de arquivos XML, ou JSON. Principalmente porque nosso aplicativo usa MUITO ajax, partial form submission, autocomplete. Meus argumentos, no entanto, não foram fortes suficientes.
Gostaria de mostrar alguma prova concreta, artigo ou argumento irrefutável de que a decisão deles está totalmente equivocada.
Não tem o menor sentido usar Web Services para a comunicação interna das camadas de sua aplicação. Apesar da inteface e o uso ser semelhante com EJB/Web Services, o custo para transformar as entidades em XML/JSON será considerável.
Além do mais que não são todos os métodos necessários para o JSF que poderão ser disponibilizados via serviço. Métodos de autenticação, por exemplo, a meu ver não podem ser expostos como serviço, visto que qualquer desenvolvedor pode fazer um robo para forçar a autenticação apenas com o WSDL e o endereço do serviço. Falando nisso vc teria que adicionar uma camada de segurança para restringir o acesso aos serviços, seja por autenticação(usuário/senha, certificado, etc), restrição de endereço IP, etc, isso também adiciona mais custo para aplicação.
Normalmente crio uma camada de Web Service acima da camada EJB apenas com os métodos e entidades que serão expostas, isso facilita tratar relacionamentos ciclícos, campos lazy, etc.
Tem muitos pontos negativos em fazer o sistema todo usando serviço, ainda mais quando não é um sistema distribuído.
Quando você diz Web Services, significa usar o protocolo SOAP? Se sim, realmente a complexidade é um pouco maior. No caso de trabalhar diretamente com REST, a específicação e os frameworks estão bem legais e ajuda bastante na conversão dos dados de xml/json para java e etc.
Porém eu também sou a favor de expor apenas o que é necessário para o mundo “externo”. Eu mesmo trabalho em uma aplicação assim.
Um pouco que talvez você possa argumentar é em relação a performance. A comunicação local, através de RMI será muito melhor que a comunicação através de HTTP (Web Services).
Ainda não está decidido se usaríamos SOAP ou REST, provavelmente REST…
No nosso caso, não precisaríamos nem usar o RMI para a comunicação entre EJB e camada Web, pois os dois projetos estariam no mesmo JBOSS.
Dentro do Managed Bean quando coloco a anotação @EJB o bean já é injetado e invoco os métodos de maneira transparente. É realmente muito fácil e rápido de programar, e é essa facilidade que eu não queria comprometer, usando Web Service.
Quando uma entidade E1 é relacionada com a E2, a E2 com a E3 e a E3 volta para a E1. Então tem um relacionamento circular que nunca acaba, que pode acarretar em StackOverFlow. Então vc tento as entidades gerenciadas pelo JPA que pode ter esse tipo de relacionamento e os objetos que serão usados pelos Web Services separados facilita muito, vc pode otimizar algumas coisas, esconder outras, etc.
Os defensores do Web Service são a favor de que a comunicação entre EJB e Web seja inteiramente feita através de Web Services. Eu faço parte do outro lado da discussão, e sou a favor de expormos via Web Services só os métodos que deverão ser chamados por aplicativos terceiros (mobile, por exemplo).
Abraços!!![/quote]
De acordo.
Aliás,pros backing beans reconhecerem um EJB é só anotar com @EJB,não?
caso seja necessário rodar a camada web em um servidor diferente da camada de negócio/EJB, já estaria toda a arquitetura pronta (a meu ver, isso é bem improvável, é mais lógico manter as camadas “locais” e clusterizar vários servidores do que separá-las. Aliás já temos esse cenário do aplicativo rodar em cluster em alguns clientes)
caso um dia seja preciso disponibilizar todas as funções to aplicativo para mobile, já estaria tudo pronto também (muito, mas MUITO, improvável. O sistema é super complexo, mais de 3000 tabelas, milhares de funções. Via celular só consigo imaginar funções de consulta ou ações bem pontuais.)
deixar a aplicação mais moderna (ao meu ver, uma aplicação moderna é aquela que utiliza as tecnologias com sensatez e análise aprofundada, escolhendo a melhor solução para cada caso específico. Simplesmente usar WS não significa que a aplicação é moderna).
Enfim, o outro lado da discussão quer se preparar para cenários que são, no mínimo, improváveis, mas são os desenvolvedores mais experientes da equipe. Eu cheguei há pouco tempo, então tenho que provar por A mais B que o melhor caminho é usarmos WS sim, porém com moderação.
Exatamente Rafael. É realmente simples e rápido de desenvolver usando essa anotação. [/quote]
Então nesse caso,é indiferente pra aplicação JSF se o método está ou não exposto como webservice.
O problema são as implicações de segurança em expor um método que não necessariamente precisa ser exposto,como já foi comentado aqui.
O que eu quis dizer é o seguinte:
public class BackingBean(){
@EJB
ClasseEJB ejb;
public void consultar(){
ejb.consultar();
}
}
public class EJB(){
@GET
@Path("{consultar}")
@Produces( { MediaType.APPLICATION_XML })
public void consultar(){
}
}
Pra aplicação JSF,que diferença faz se o método está exposto ou não?
O tempo gasto em desenvolvimento vai ser maior com webservices. Você terá que criar o método no server, o consumidor no cliente. O consumidor pode ser por wsimport ou na unha ( oq precisa ser feito por alguém experiente em wsdl )
Pode haver perda de performance. Uma lista de pessoas onde cada pessoa tem sublistas. No webservice tudo terá virar xml e depois virar objeto na view. A cada processo/consulta isso será feito.
Pode expor métodos que não devam ser expostos. Se programado erroneamente você pode abrir métodos da API que não deveriam ser, risco que não se correria utilizando EJB.
Tratamento de erro é mais fácil com EJB do que com Fault do Webservices (esse eu imagino que seja baseado no que eu tenho estudado)
Se for para deixar o WSDL mais legível, vai rolar aí um trabalho maior para tratar o xml gerado
Ao criar um método novo, é mais fácil entender uma classe java do EJB do que um método assinado no wsdl.
Tratar usuário valido ou não vai ser mais complicado com webservices,
Acho que tá bom. ^^
Na boa… acho que sua empresa vai perder dinheiro ao aplicar webservice como back end para o que você nos descreveu como sendo a aplicação.
@Named("meuMB")
@ConversationScoped
class MeuMB {
@EJB
private MeuEJB meuEJB;
}
EJB locais vc terá um controle mais fino em transações, podendo colocar a transação em método do MB, por exemplo, podendo chamar vários EJB e fazer o commit junto.
Com WebServices também tem a anotação @WebServiceRef, mas não tem controle o transação que pode ter em EJBs(a chamada é atómica).
Uma coisa interessante que faço com EJBs também é o controle de acesso, quando usado com JAAS ou até mesmo criando uns interceptadores customizados.
Fiz esses customzados para evitar que um usuário chame um método caso não esteja logado ou não seja membro de uma role.
caso seja necessário rodar a camada web em um servidor diferente da camada de negócio/EJB, já estaria toda a arquitetura pronta (a meu ver, isso é bem improvável, é mais lógico manter as camadas “locais” e clusterizar vários servidores do que separá-las. Aliás já temos esse cenário do aplicativo rodar em cluster em alguns clientes)
caso um dia seja preciso disponibilizar todas as funções to aplicativo para mobile, já estaria tudo pronto também (muito, mas MUITO, improvável. O sistema é super complexo, mais de 3000 tabelas, milhares de funções. Via celular só consigo imaginar funções de consulta ou ações bem pontuais.)
deixar a aplicação mais moderna (ao meu ver, uma aplicação moderna é aquela que utiliza as tecnologias com sensatez e análise aprofundada, escolhendo a melhor solução para cada caso específico. Simplesmente usar WS não significa que a aplicação é moderna).
Enfim, o outro lado da discussão quer se preparar para cenários que são, no mínimo, improváveis, mas são os desenvolvedores mais experientes da equipe. Eu cheguei há pouco tempo, então tenho que provar por A mais B que o melhor caminho é usarmos WS sim, porém com moderação.[/quote]
Basta já projetar a aplicação para ter deploy de artefatos diferentes. Realize o deploy do JSF em um war e do EJB em um EJB. Caso fosse necessário separar os sevidores, os artefatos já estariam em módulos separados. Basta apenas configurar apenas a localização de cada um.
O acesso mobile em geral tem menos funcionalidades do que um acesso web. Mas com EJB é possível expor um método como webservice. Bastaria anotar o EJB e o método desejável que esse um webservice já estaria pronto.
webservice não é modernidade, na verdade, é velho pra “chuchu”.
Herbert, concordo com você. Inclusive a aplicação já está separada entre EAR (com os EJBs) e WAR (ManagedBeans e JSF).
Caso eu venha a colocar o EAR no servidor X e o WAR no servidor Y, como será feita a comunicação? Via RMI? Existe muita configuração a ser feita, nesse caso?
Não necessariamente,com JAX-RS dá pra dispensar toda a parafernália de WSDL,Stub etc,dá uma olhada no meu post acima.[/quote]O JAX-RS não é acionado quando chamamos o wsimport para gerar tudo automático?
Pelo que eu tenho lido (não tenho experiência com webservices ainda) para cada novo método que é exposto como webservices é necessário executar o wsimport novamente. Não é isso?