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.
Se é Java falando com Java, exclua do pensamento qualquer coisa com SOAP/WSDL/WS-*
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.
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.
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.
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.[/quote]
Se pensares em escabilidade, esse pode ser um approach mais agressivo, principalmente pelo fato do provisiona um excelente suporte ao non-blocking NIO .
[quote=nicholas.bittencourt]
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.[/quote]
Com certeza o sistema era mal feito. Repare na minha recomendação (1) da minha mensagem anterior
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.
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.
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.
Servlets possuem limitações ao lidar com NIO - [/quote]
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.
Para fazer só isto existem outras opções como o bom e complexo cocoon por exemplo.
[quote]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.
[/quote]
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.
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?
Dependendo do caso da mais trabalho usar o protocolo do WS do que montar um baseado no HTTP.
E ainda da para usar algumas coisas disponíveis em aplicações web, como HTTPS e autenticação de modo “transparente”.