Qual Framework mais indicado nesse caso?

Bom nesse caso o que você pode fazer é usar o EJB 3.0 .

Eu já cheguei a fazer isso. O EJB tem suporte à web service. Então ao mesmo tempo que você vai ter um jndi name para ser acessado no container (acessando ele pelo container, vc terá o resultado do objeto) você também poderá disponibilizar o endereço para acessar essa classe, devolvendo o xml para o projeto remoto.

oi ralphsilver,

Eu cogitei sim a possibilidade de usar EJB 3, porém me parece um tiro de canhão para matar uma formiga :shock:

Das N características do EJB, acredito que só usaria essa, então me parece algo exagerado para um ‘pequeno’ problema.

Tendo isso em mente voce ainda recomenda o EJB mesmo ? É algo simples de implementar ao ponto de valer a pena para tirar proveito apenas dessa característica dele?

Nunca usei EJB e estou com um pouco de receio devido a experiencias já relatadas, inclusive aqui, com o seu uso.

Obrigado por sua resposta

GraveDigger:

oi ralphsilver,

Eu cogitei sim a possibilidade de usar EJB 3, porém me parece um tiro de canhão para matar uma formiga :shock:

Das N características do EJB, acredito que só usaria essa, então me parece algo exagerado para um ‘pequeno’ problema.

Tendo isso em mente voce ainda recomenda o EJB mesmo ? É algo simples de implementar ao ponto de valer a pena para tirar proveito apenas dessa característica dele?

Nunca usei EJB e estou com um pouco de receio devido a experiencias já relatadas, inclusive aqui, com o seu uso.

Obrigado por sua resposta

Se seu problema é pequeno deixou de ser ao considerar usar SOAP e toda sua complexidade. O suporte a webservices nos EJBs podem ajudar mas ainda assim WS-* estao longe de ser uma solucao facil pra interoperabilidade (alem de introduzir forte acoplamento entre os sistemas).

Nesse caso, qual seria sua sugestão para esse cenário?

Grato

Minha indicação é o Jersey.

Com ele é possível usar serviços REST usando classes POJO. Por default ele devolve documentos no formato XML, ou no formato JSON. Mas você pode acrescentar outros formatos (não lembro como, mas a documentação explica, não é nada além de uma classe), por exemplo: voltar uma representação serializada do objeto Java se o mime-type enviado for “application/x-java-serialized-object”. Tem a vantagem que você pode usar um objeto serializado, mesmo se for uma aplicação externa.

Leonardo3001:

Minha indicação é o Jersey.

Com ele é possível usar serviços REST usando classes POJO. Por default ele devolve documentos no formato XML, ou no formato JSON. Mas você pode acrescentar outros formatos (não lembro como, mas a documentação explica, não é nada além de uma classe), por exemplo: voltar uma representação serializada do objeto Java se o mime-type enviado for “application/x-java-serialized-object”. Tem a vantagem que você pode usar um objeto serializado, mesmo se for uma aplicação externa.

Oi Leonardo, dei uma lida sobre o Jersey e realmente achei bem interessante.

Porém, não sei se seria o caso de aplicá-lo aqui, minha idéia é evitar o overhead gerado pelo marshalling/unmarshalling de meu(s) objeto(s).

Os objetos que serão providos pela aplicação que possui os serviços, serão objetos complexos e esse processo de transformar meus objetos em alguma outra coisa para a transmissão depois remontar o objeto pode gerar um overhead que eu gostaria de evitar, ao menos entre minhas APPs java.

REST está intimamente ligado a MIME types, e o mais próximo que o MIME chega do java é um objeto serializado,o que implicaria no marshalling/unmarshalling.

Se meus objetos estivesse em servidores diferentes(ou ao menos Virtual Machines diferentes) eu aceitaria esse overhead, porém, estando tudo na mesma VM, não vejo essa necessidade.

Estou me convencendo de que EJB é uma boa alternativa nesse caso.

Porém ainda gostaria de mais algumas opiniões antes de trilhar esse caminho.

Grato,

PS

oi ralphsilver,

Eu cogitei sim a possibilidade de usar EJB 3, porém me parece um tiro de canhão para matar uma formiga

Das N características do EJB, acredito que só usaria essa, então me parece algo exagerado para um ‘pequeno’ problema.

Tendo isso em mente voce ainda recomenda o EJB mesmo ? É algo simples de implementar ao ponto de valer a pena para tirar proveito apenas dessa característica dele?

Nunca usei EJB e estou com um pouco de receio devido a experiencias já relatadas, inclusive aqui, com o seu uso.

Obrigado por sua resposta

Bom, o ejb realmente é um conjundo de recursos muito grandes.
Eu optaria por esse recurso pois, com ejb, haveria um fraco acoplamento de código, possibilitando manutenção sem precisar alterar muita estrutura.

outra coisa também é que nada impede de você aproveitar ele para outros fins como oferecer suporte ao JPA, pelo menos eu gosto do suporte que ele oferece.

Enfim, é um recurso simples de implementar, já que as ides hj em dia dão bom suporte para ele e fácil de acesso a web service pois basta apenas usar anotações para preenchê-lo.

O único problema é se voce usa um servidor sem container ejb.

Qualquer coisa se precisar de ajuda com implementação de webservice em um ejb. Me dá um toque

[]'s