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?[/quote]
Não não cara,com JAX-RS é bem mais simples,olha um exemplo:
Serviço:
@Path("/venda")
public class BuscadorVenda {
@GET
@Path("{id}")
@Produces( { MediaType.APPLICATION_XML })
public Venda buscarVenda(@PathParam("id") Integer id
){
try {
Venda venda = new Conexao().findById(id);
return venda;
}catch(Exception e){
e.printStackTrace();
}
return null;
}
}
Para consumir um xml a partir desse serviço,basta invocar uma url host://aplicacao/consulta/venda/${id}.
[quote=raf4ever]Não não cara,com JAX-RS é bem mais simples,olha um exemplo:
Serviço:
@Path("/venda")
public class BuscadorVenda {
@GET
@Path("{id}")
@Produces( { MediaType.APPLICATION_XML })
public Venda buscarVenda(@PathParam("id") Integer id
){
try {
Venda venda = new Conexao().findById(id);
return venda;
}catch(Exception e){
e.printStackTrace();
}
return null;
}
}
Para consumir um xml a partir desse serviço,basta invocar uma url host://aplicacao/consulta/venda/${id}.
[/quote]Legal, mas desse modo aí, o nome do método deve ser o nomdo encontrado no WSDL? Isso se aplica a SOAP ou REST ou os dois? Desculpe as perguntas, quero ficar bom um dia nisso. [=
[quote=felipe_gdr]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?[/quote]Isso, RMI. Pouca coisa. Isso varia de acordo com o servidor. [=
[quote=Hebert Coelho][quote=raf4ever]Não não cara,com JAX-RS é bem mais simples,olha um exemplo:
Serviço:
@Path("/venda")
public class BuscadorVenda {
@GET
@Path("{id}")
@Produces( { MediaType.APPLICATION_XML })
public Venda buscarVenda(@PathParam("id") Integer id
){
try {
Venda venda = new Conexao().findById(id);
return venda;
}catch(Exception e){
e.printStackTrace();
}
return null;
}
}
Para consumir um xml a partir desse serviço,basta invocar uma url host://aplicacao/consulta/venda/${id}.
[/quote]Legal, mas desse modo aí, o nome do método deve ser o nomdo encontrado no WSDL? Isso se aplica a SOAP ou REST ou os dois? Desculpe as perguntas, quero ficar bom um dia nisso. [=[/quote]
Ao meu ver não. Para alcançar performance no caso de grandes clientes, imagino que clusterizar seja a prática mais reconhecida e comprovada. Mas tá difícil convencer os “chefões”, rs.
Vou preparar uma apresentação detalhada, levando-se em conta as informações valiosas que adquiri nessa discussão, e mostrar para a equipe.
[quote=raf4ever][quote=Hebert Coelho][quote=raf4ever]Não não cara,com JAX-RS é bem mais simples,olha um exemplo:
Serviço:
@Path("/venda")
public class BuscadorVenda {
@GET
@Path("{id}")
@Produces( { MediaType.APPLICATION_XML })
public Venda buscarVenda(@PathParam("id") Integer id
){
try {
Venda venda = new Conexao().findById(id);
return venda;
}catch(Exception e){
e.printStackTrace();
}
return null;
}
}
Para consumir um xml a partir desse serviço,basta invocar uma url host://aplicacao/consulta/venda/${id}.
[/quote]Legal, mas desse modo aí, o nome do método deve ser o nomdo encontrado no WSDL? Isso se aplica a SOAP ou REST ou os dois? Desculpe as perguntas, quero ficar bom um dia nisso. [=[/quote]
Esqueça o WSDL nesse caso. [/quote]Então você está falando de REST?
[quote=Hebert Coelho][quote=raf4ever][quote=Hebert Coelho][quote=raf4ever]Não não cara,com JAX-RS é bem mais simples,olha um exemplo:
Serviço:
@Path("/venda")
public class BuscadorVenda {
@GET
@Path("{id}")
@Produces( { MediaType.APPLICATION_XML })
public Venda buscarVenda(@PathParam("id") Integer id
){
try {
Venda venda = new Conexao().findById(id);
return venda;
}catch(Exception e){
e.printStackTrace();
}
return null;
}
}
Para consumir um xml a partir desse serviço,basta invocar uma url host://aplicacao/consulta/venda/${id}.
[/quote]Legal, mas desse modo aí, o nome do método deve ser o nomdo encontrado no WSDL? Isso se aplica a SOAP ou REST ou os dois? Desculpe as perguntas, quero ficar bom um dia nisso. [=[/quote]
Esqueça o WSDL nesse caso. [/quote]Então você está falando de REST?[/quote]
Exatamente.
de inicio está me parecendo errado o que eles estão propondo. Talvez por causa do rumo da discussão.
Se eu entendi certo, eles querem fazer com que os Managed Beans se comuniquem com a camada de negócio utilizando REST. (Parece ruim, comparando com injetar EJB)
Assim, toda a regra de negócio estaria exposta como um serviço. (Parece bom)
Dúvidas: Somente sua camada de negócio se comunica com a de persistência? então cadastros simples também necessitarão que o MB faça chamada REST?
Como quase tudo vira serviço, tem que cuidar para não cometer este erro: http://blog.xebia.com/2008/05/12/top-10-soa-pitfalls-7-incorrect-granularity-of-services/
De acordo com o artigo, os serviços devem ser divididos até a menor parte possível em que ainda faça sentido para a área de negócio.
Acho que dependendo de como for quebrada as regras de negócio nos EJBs, muitas regras não deveriam ser expostas.
Estou em dúvida neste ponto, talvez a proposta deles crie uma ótima API RESTful. :?
Mas ainda tenho a impressão que está sendo criada uma camada extra desnecessária, talvez duas, pois precisarão de algum esquema para que os serviços não sejam acessíveis por qualquer um.
Comece simples e adicione complexidade a medida que for necessário.
Outra coisa, imagina uma requisição em que o managedbean precisa executar 3, 5 ou 10 regras de negócio para dar uma resposta.
Se essas regras forem dependentes, o custo da camada REST que foi adicionada pode ser alto.
Acredito que o desempenho destas chamadas REST deve ser bem inferior ao desempenho de chamadas com injeção dos EJBs, ou seja, pode ser muito lento com REST.
Poderiam fazer uma POC sobre isto para comparar o desempenho ou talvez pesquisar mais.
Se eles não querem investir neste estudo para ter certeza que a arquitetura está ‘correta’, poderão pagar muito mais no futuro.
[quote=lsjunior] …
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.
…
[/quote]
utilizando da forma com REST eles precisarão ter uma URI que faça toda a transação necessária, correto?
