Salve GUJ,
Ontem liberei um plugin (bundle) para OSGi de forma a integrar o jBoss RESTEasy dentro de um framework OSGi rodando em um container web. A história completa pode ser encontrada no meu blog http://sarbarian.wordpress.com/2010/03/07/resteasy-and-osgi-perfect-match/
Aqui vou postar um resposta que eu mandei para um grande amigo meu que após ver o announcement no fórum do RESTEasy me mandou um e-mail perguntando quais eram de fatos as vantagens de rodar dentro de um container OSGi:
Po que massa, mais um cara no OSGI.
Então o lance do Spring e OSGi chama spring DM-Server. Li pouco sobre ele, mas ele é um “jBoss application server”, ou seja substitui o application server e passa fazer deploys de tudo como se fosse bundles, ou seja, um EJB é um bundle, um pool é um bundle etc etc e vc vai plugando e desplugando esses bundles on-the-fly.
O que eu estou ganhando com o OSGi é a possibilidade de delegar partes da aplicação para meus implementadores de forma independente e/ou sem que eles passem a alterar concorrentemente a aplicação web(WAR, web.xml). Exemplo: Tenho um sistema de chamados de suporte. Cada projeto da minha empresa precisa implementar peculiariedades, ou seja, um projeto tem uma tela de cadastro de tickets, outro não tem cadastro de tickets e sim uma tela de aceite de tickets. etc etc. Porém todos compartilham a mesma base de dados e a camanda de serviço EJB (addTicket(), addTicketNotes(), etc etc).
Eu tenho duas saídas:
-
Fazer um EJB de serviços e deixar que cada projeto faça o seu WAR da forma que precisa e então cada um tem o seu deploy de war separado, seus problemas e soluções;
-
Fazer um único projeto WAR mas permitir que cada projeto contribua com a interface gráfica implementando suas peculiariedades, ou seja cada um contribui no mesmo sistema de forma isolada. Assim se uma funcionalidade interessante feita por um projeto precisa ser compartilhada com os outros projetos, isso pode ser feito facilmente com plug-in fragments, features e plugins…
Benefícios do OSGi
a) Algumas vezes eu preciso fazer manutenção do código que disponibiliza a url /ticket (um RESTEasy singleton). Hoje eu preciso fazer um redeploy do context web todo, assim todos os usuários do sistema perdem a sessão. Com o OSGi eu posso plugar, desplugar a url /ticket sem fazer um redeploy do contexto web (WAR) e sem derrubar os usuários que não usam a url /ticket.
b) Se eu fizer tudo direitinho, a update dos plugins passam a ser feitos pelo console OSGi, ou seja, para atualizar um plug-in (bundle) basta:
stop com.sarbarian.ticket
update com.sarbarian.ticket (neste momento o container OSGi lê a proprieade update do MANIFEST.MF e faz o download do novo pacote do plugin. Como eu estou usando o Eclipse Equinox, ele faz isso via Eclipse update manager).
start com.sarbarian.ticket
Pronto, minha url /ticket está reimplementada…
c) OSGi enforça modularidade e reuso de código. Posso conseguir apenas com boas práticas e senioridade? - Sem dúvida. Mas o lance de ser “forçado” a implementar módulos evita qualquer futuro problema de acomplamento mal feito…
Sobre o Hibernate
Vi também que estão implementando o Hibernate session/JPA session dentro do OSGi. Minha leitura: Interessante e útil para um sistema J2SE, ou seja, uma application standard rodando a partir de um .exe. Tenho mais confiança em deixar para o application server cuidar da minha sessão JPA pq acredito que ele faz muito bem o controle de transação, poll e cache do JPA. Assim pretendo ter um sistema hibrido JPA/EJB com as regras de negócio e WEB/OSGi para a interface gráfica e serviços (SOAP, REST, etc).
Mas não descarto a possibilidade de também jogar o Hibernate como um bundle dentro do meu OSGi. Apenas acho que vou ter que reimplementar algo que é bem feito por um container, e alias, pretendo rodar minhas aplicações WAR dentro do jBoss…
Vamos discutir!
Abraços,
Davi