EJB ou Webservices?

Aqui na empresa onde trabalho estamos desenvolvendo uma aplicação para gerenciar conteudo do portal corporativo de um cliente. Além dos requisitos básicos do publicador, teriamos ainda que disponibilizar serviços que permitam que outras aplicações do cliente publiquem informações no site e criem seu próprio conteudo.

Qual a melhor abordagem pra isso? Estou na dúvida entre disponibilizar EJBs para que as aplicações do cliente possam instanciar os caras e elas mesmas executarem os codigos ou um conjunto de webservices para esse fim. A premissa é que as aplicações do cliente também seriam todas em java.

Agradeceria se me dissessem o motivo da escolha por uma ou outra tecnologia.

Valeu!

Olha cara.
Sinceramente eu escolheria WebServices.

Hoje são todas em java, mas tem que analisar se serão sempre assim.
Pois trabalhar com corba para integração é pra matar.

Mas por outro lado nunca tive experiências de disponibilidade de EJBs para clientes.

nicholas,

De uma olhada neste tópico, acredito que te ajude.

http://www.guj.com.br/posts/list/62614.java

Olá

1) Se é Java falando com Java, exclua do pensamento qualquer coisa com SOAP/WSDL/WS-*

2) Para disponibilizar os serviços de publicação eu usaria um servlet. As aplicações do cliente enviariam as solicitações via POST ou mesmo GET. Razões da escolha: simplicidade, rapidez no desenvolvimento e nenhuma necessidade de expor as entranhas.

[]s
Luca

fsquadro wrote:nicholas,

De uma olhada neste tópico, acredito que te ajude.

http://www.guj.com.br/posts/list/62614.java

Como os serviços só estariam disponíveis em uma aplicação, acho que a adoção do OSGi seria matar uma formiga usando um canhão. Eu pensei em algo mais simples mesmo mas de forma que os clientes pudessem acessar os serviços e um novo deployment da aplicação não interfica no funcionamento deles.

Outra coisa é que existem sistemas desses que já estão implementados, então eu tenho que ter o cuidado de os serviços serem os mais flexiveis possiveis de forma que o cliente não precise ser reimplementado.

Luca wrote:2) Para disponibilizar os serviços de publicação eu usaria um servlet. As aplicações do cliente enviariam as solicitações via POST ou mesmo GET. Razões da escolha: simplicidade, rapidez no desenvolvimento e nenhuma necessidade de expor as entranhas.

Um trauma que o cliente tem é na performance do sistema. Um portal anterior que ele usava, fazia todas as requisições ao banco de dados por webservices e com isso uma tela simples demorava 10 segundo pra ser renderizada.

Minha preocupação em usar o Servlet, ou mesmo um Webservice, é a codificação e decodificação das informações enviadas pro serviço. Essas operações são custosas e iriam impactar muito no resultado final.

nicholas.bittencourt wrote:

fsquadro wrote:nicholas,

De uma olhada neste tópico, acredito que te ajude.

http://www.guj.com.br/posts/list/62614.java

Como os serviços só estariam disponíveis em uma aplicação, acho que a adoção do OSGi seria matar uma formiga usando um canhão. Eu pensei em algo mais simples mesmo mas de forma que os clientes pudessem acessar os serviços e um novo deployment da aplicação não interfica no funcionamento deles.

Outra coisa é que existem sistemas desses que já estão implementados, então eu tenho que ter o cuidado de os serviços serem os mais flexiveis possiveis de forma que o cliente não precise ser reimplementado.

Já olhou a abordagem Rest ?

Dê uma olhada nesse carinha - http://www.restlet.org/

Se pensares em escabilidade, esse pode ser um approach mais agressivo, principalmente pelo fato do provisiona um excelente suporte ao non-blocking NIO .

Servlets possuem limitações ao lidar com NIO - http://blogs.webtide.com/gregw/2004/02/09/1076359560000.html

Agora a discussão sobre Servlets 3.0 do JavaOne, pretende resolver uma série de questões como essa -

http://blogs.webtide.com:80/gregw/2007/05/09/1178670900000.html , mas ainda sim ainda há restrições por parte do NIO.

HelloWorld Membro desde: 04/01/2007 22:12:40 Mensagens: 14 Offline

pensando em flexibilidade futura (caso o cliente resolva desenvolver modulos em outra plataforma) não seria melhor usar webservices?

Olá

nicholas.bittencourt wrote:
Um trauma que o cliente tem é na performance do sistema. Um portal anterior que ele usava, fazia todas as requisições ao banco de dados por webservices e com isso uma tela simples demorava 10 segundo pra ser renderizada.

Com certeza o sistema era mal feito. Repare na minha recomendação (1) da minha mensagem anterior

nicholas.bittencourt wrote:Minha preocupação em usar o Servlet, ou mesmo um Webservice, é a codificação e decodificação das informações enviadas pro serviço. Essas operações são custosas e iriam impactar muito no resultado final.

1) Nunca vi integração entre sistemas em que não existisse a etapa de codificação e decodificação das informações. Fazer isto de forma complexa usando SOAP/WSDL/WS-* ou de forma simples via um servlet é opção do programador.

2) Repare que ao sugerir o uso de servlet estou dizendo logo de cara como fazer REST. É super fácil e rápido. Mas se você preferir EJBs, abrir portas RMI ou outras portas exóticas na rede, fique a vontade.

[]s
Luca

Olá

teatroDaDor wrote:pensando em flexibilidade futura (caso o cliente resolva desenvolver modulos em outra plataforma) não seria melhor usar webservices?

Já pensou o quanto isto seria ruim e overkill?

[]s
Luca

teatroDaDor wrote:pensando em flexibilidade futura (caso o cliente resolva desenvolver modulos em outra plataforma) não seria melhor usar webservices?

O cliente já possui diversos outros sistemas em ASP. Inclusive onde eu trabalho desenvolve sistemas em ASP pra ele tambem... Mas como eles querem integrar os sistemas Java primeiro, prefiro não questionar.

Olá

Kenobi wrote:
Dê uma olhada nesse carinha - http://www.restlet.org/

...

Servlets possuem limitações ao lidar com NIO -

O Restlet foi uma boa sugestão. Mas significa incluir mais um elemento ao sistema que provavelmente já usa um servidor de aplicação.

Só lembrando: servlets = web com Java. O uso ou não de NIO depende do servidor de aplicação. O Restlet é um servidor para servlet. Mesmo com os que não usam NIO, se pode obter um excelente throughput. Para um tomcat, jetty ou glassfish abrir o bico, é preciso mandar muita coisa ao mesmo tempo. Eu duvido que isto vá acontecer no caso descrito neste tópico, a menos que seja para uma Reuters ou similar.

[]s
Luca

Olá

nicholas.bittencourt wrote: disponibilizar serviços que permitam que outras aplicações do cliente publiquem informações no site e criem seu próprio conteudo.

Para fazer só isto existem outras opções como o bom e complexo cocoon por exemplo.

Cocoon]
What is Cocoon?

Apache Cocoon is a web development framework built around the concepts of separation of concerns (making sure people can interact and collaborate on a project, without stepping on each other toes) and component-based web development.

Cocoon implements these concepts around the notion of "component pipelines", each component on the pipeline specializing on a particular operation. This makes it possible to use a "building block" approach for web solutions, hooking together components into pipelines without any required programming.

Cocoon is "web glue for your web application development needs". It is a glue that keeps concerns separate and allows parallel evolution of the two sides, improving development pace and reducing the chance of conflicts.

Cocoon has been designed to coexist and interoperate side-by-side with your existing J2EE solutions or to give them new functionality without requiring any change in the existing infrastructure.

Cocoon interacts with many data sources, including filesystems, RDBMS, LDAP, native XML databases, SAP® systems and network-based data sources. It adapts content delivery to the capabilities of different devices like HTML, WML, PDF, SVG, and RTF, to name just a few. You can run Cocoon as a Servlet as well as through a powerful, commandline interface. The deliberate design of its abstract environment gives you the freedom to extend its functionality to meet your special needs in a highly modular fashion.

[]s
Luca

Pessoal,

Valeu pelas dicas. Vou estudar as partes que não conheço mais a fundo antes de tomar uma decisão aqui.

JavaEvangelist Membro desde: 07/04/2005 11:37:42 Mensagens: 328 Offline

Luca,

Porque uma abordagem com webservices exporia as entranhas? E será que vale mesmo a pena fazer um servlet, haja vista que seria necessário criar outro "protocolo" de comunicação, ou seja, definir um formato não-padronizado para os serviços retornarem informações?

Valeu!

Notícias, artigos e o maior fórum brasileiro sobre Java