Estou procurando informações sobre arquitetura com plugins, por exemplo, o Eclipse, tem uma arquitetura básica onde recebe plugins para se tornar completo.
O BlueJ também recbebe plugins, só que lendo os jars dentro de um diretório.
Estou querendo fazer algo similar, má só uma arquitetura básica(Carcaça) onde pudesse ser adicionados plugins, isso da uma forma mais independente de plataforma possível.
Alguém ja fez algo assim?
materiais a respeito?
como é chamado este tipo de arquitetura, tem algo algum nome específico?
[quote=LIPE]Você realmente acha que com a frase acima deu pra ter a mínima idéia do que se passa pela sua cabeça? hehe Explica melhor, por favor
Cara, uma coisa muito importante é a interface o programa sob o qual os plugins rodarão irá publicar para os mesmos.[/quote]
Hehe ta certo LIPE, vou explicar melhor.
Quero fazer uma carcaça onde eu possa imbutir módulos nela.
Ex: Carcaça + modulo de calcular normal,
Carcaça + módulo de calcular cientifico,
Carcaça + modulo de calcular normal +módulo de calcular cientifico.
E por ai vai, meu interesse é gerar uma carcaça e a partir dela eu possa desenvolver outros módulos e plugar nela, fazendo algo funcional.
E que estes módulos pudessem se integrar no caso de haver dados em banco.
Neste exemplo seria desktop, mas acho que da para fazer para web também.
Se eu usasse IOC pra deixar cada lógica de negócio no seu devido módulo tendo idependencia acho que daria certo.
Então melhorou a explicação?
Só perguntar que eu explico novamente.
Você pode usar o Eclipse e jogar fora todos os plugins dele, bom se você já tiver alguma experiência de desenvolmento de plugins pra ele.
Você pode usar um outro container OSGi, considere MUITO usar um container OSGi, como Oscar e o knoplerfish. OSGi é um padrão da industria e permite que você utilize plugins dos outros. O Oscar tem uns lances super legais de instegração com o tomcat por exemplo, onde teu plugin pode exportar um servlet expecífico a um contexto.
Além disso, se você quer um contaner de IoC na parada, considere usar o HiveMind, é muito legal nesse sentido, apesar de consumir um bom tempo até você sacar qual é a dele. E tem o container que o maven 2 usa, acho que chama plexus. Esqueça o spring.
Você pode usar um outro container OSGi, considere MUITO usar um container OSGi, como Oscar e o knoplerfish. OSGi é um padrão da industria e permite que você utilize plugins dos outros. O Oscar tem uns lances super legais de instegração com o tomcat por exemplo, onde teu plugin pode exportar um servlet expecífico a um contexto.
[/quote]
Valeu Louds,
O Spring foi só um exemplo não irei usar ele.
IOC eu tava pensando para não haver ligação da lógica do negócio, mas qualquer outra coisa que faça isso serve.
Achei interessante OSGi que você citou, inclusive pelo lance do tomcat, pois pretendo por um modulo que publique informações pelo container
Ahh, nenhum container OSGi tem serviços de IoC que eu saiba. Por que o foco deles são em compor plugins e não objetos.
Mas talves não seja muito dificil colocar a infra do Spring neles
[quote=louds]Ahh, nenhum container OSGi tem serviços de IoC que eu saiba. Por que o foco deles são em compor plugins e não objetos.
Mas talves não seja muito dificil colocar a infra do Spring neles[/quote]
Só preciso que os plugins interajam uns con os outros e com a carcaça.
Além dos containers IoC e OsGI também existem os microkernels baseados em JMX estilo JBoss/Geronimo…
Seria bom que um padrão mais forte surgisse nessa área. Mas a fragmentação tá cada vez maior: JBI e a JSR 277 são specs novas que adicionam mais duas tecnologias à salada atual.
O spring framework faz uma coisa bem diferente que um plugin framework. Ele não é muito mais que uma Factory muito ninja. E não prove nenhum dos recursos que um framework de plugins precisa, como o conceito de módulos, interdependencia, modulos abstratos, eventos… Só olhar o que o OSGi framework faz e o que o spring framework faz, são coisa bem distintas.
Eu acho que os containers do jboss/geronimo são muito pesados para serem usados por uma aplicação, mas pode ser só impressão já que nunca tentei isso ou ví gente tentando.
Quanto a fragmentação, discordo de você. JBI resolve um problema muito diferente disso. E a JSR 277 é apenas o JCP aceitando a existencia do OSGi framework, falasse inclusive que o padrão vai prever interoperabilidade entre os dois. A promessa fica por conta da extinção do jar hell.
Estudei OSGI muito superficialmente, mas já avaliei o Spring para finalidade semelhante e é possível usá-lo como facilitador de uma arquitetura de plugins. A técnica mais trivial é fazer com que cada plugin declare as dependêncais de seus objetos num xml spring padrão; um controle básico de ciclo de vida é feito especificando os métodos init e destroy (são outros nomes na verdade, esqueci agora ).
Para uma aplicação real alguma customização é necessária (talvez com xslt para a configuracao e BeanPostProcessors para outras mágicas).
E quanto à fragmentação, eu creio que seria benéfico uma especificação única para gerênciamento de dependências e controle de ciclo de vida. Outras especificações mais, er, específicas, poderiam ser construídas em cima dessa (EJB, JBI, Servlets, etc…).
O spring não suporta a parte mais interessante do OSGi, que é o isolamento de dependencias e carga/remoção dinâmica de plugins.
Com Spring você não tem como manter 2 plugins que usam versões diferentes do mesmo jar. Tão pouco controlar requisitos de versões e tudo mais. O modelo do BeanFactory é estático, depois de carregado é imutavel. OSGi é feito para plugins entrarem e sairem constantemente.
E introduzir isso no Spring vai ser uma senhora cirurgia, talveZ seja mais facil adaptar ele em cima da infra OSGi. Classloading é a parte mais cabeluda do java.
Primeiro que um plugin não é apenas um mecanismo de publicar eventos.
Um plugin é análogo a um EAR, com a diferença que um plugin é feito pensando em interagir com outros, enquanto um EAR é uma trolha monolítica.
Falando especificamente da stack OSGi. São 3 layers de recursos providos por um container OSGi.
1 - Modulos, define a política de classloading e visibilidade de classes entre plugins. Permite que plugins exportem classes que ficam visiveis aos demais, e que plugins definam qual o exato escopo de plugins visiveis que ele precisa. Isso evita JAR hell de você precisar de versões diferentes dos mesmos jars (já tentou groovy + hibernate) e usar gambiarras como o jarjar. Não tem nada parecido com isso no spring framework.
2 - Ciclo de vida, cada Bundle (termo p/ plugin no OSGi framework) possui um ciclo de vida próprio, ou seja, você pode instalar, remover, parar ou atualizar ele dinâmicamente. O spring framework depende de um modelo estático de classes e configuração.
3 - Registro de serviços, permite cooperação entre bundles levando em conta a dinamicidade do container OSGi. Esse é o aspecto mais próximo entre OSGi e spring. E ainda assim possuem diferenças bem grandes, por que o OSGi é voltado a permitir que bundles se comuniquem, enquando o spring é mais para objetos. O Spring é muito mais interessante neste aspecto.
O porém disso é que se você usar o container do Eclipse ganha de brinde a arquitetura de plugins dele, que é bárbara, que dá muito mais chão para criar aplicações grandes e controláveis.
essa discussão já está parada há um bom tempo mas eu gostaria de reabrí-la!!
No meu trabalho, estamos para iniciar um novo projeto que ainda não tem muita coisa definida. Estamos ainda numa fase de brainstorm informal, onde meu chefe diz o que seria ideal e eu corro atrás de estudar as possibilidades…
A idéia seria ter um software ERP plugin-based funcionando de forma parecida com os gerenciadores de conteúdo (CMS) como o Joomla por exemplo. Assim, eu teria um framework com ganchos para pendurar os plugins (módulos).
Pra deixar claro o que estou chamando de módulo, eu darei um exemplo. O Módulo Financeiro seria um plugin que poderia tanto funcionar sozinho como “conversando” com o Módulo CPR, por exemplo.
Já deu pra ter uma visão geral do projeto? Então aqui vai minhas dúvidas:
1- Seria melhor gastar meu tempo e esforço “estudando” um framework para plugins ou tentar fazer meu próprio framework do zero já que a complexidade do sistema não seria tanta?
2- Pelo que pesquisei, eu prefer o JPF à algum framework OSGi. Eu tenho a impressão que um OSGi seria a velha bazuka pra matar o meu sistema que é uma formiga. O que vocês acham? Surgiu alguma coisa melhor de 2005 pra cá?
3- Recomendam algum material de leitura obrigatória antes de eu decidir me aventurar neste projeto?
4- Recomendam eu abondonar este projeto e fazer o bom e velho software personalizado para cada cliente?
Os motivos para eu querer fazer um sistema plugin-based são:
Agilidade na manutenção. Ao atualizar o sistema, não quero ficar preocupado com as peculiaridades de cada cliente ou ter uma versão diferente para cada um…
Agilidade na entrega. Quando o cliente solicitar um novo módulo, é bem mais rápido desenvolver apenas um plugin e “soltar” no sistema dele.
Mais vendas. Se eu já tive o esforço de desenvolver um Módulo de Folha de Pagamento, basta oferecer aos clientes antigos este plugin.
).