Pergunta

Eu estive olhando para OSGi recentemente e acho que ele se parece com uma idéia realmente boa para modular aplicativos Java.

No entanto, eu queria saber como OSGi iria trabalhar em uma aplicação web, onde você não só tem código que se preocupar -. Também HTML, imagens, CSS, esse tipo de coisa

No trabalho que estamos construindo uma aplicação que tem vários 'guias', cada guia sendo uma parte do aplicativo. Eu acho que isso poderia realmente beneficiar de tomar uma abordagem OSGi - no entanto eu não sou realmente certo o que seria a melhor maneira de lidar com todos os recursos habituais de aplicativos web

.

Eu não tenho certeza se ele faz alguma diferença, mas estamos usando JSF e IceFaces (que adiciona outra camada de problemas, porque você tem regras de navegação e você tem que especificar todos os rostos arquivos de Configuração em seu web.xml ... doh!)

Editar: de acordo com este arquivos fio , faces-config.xml lata ser carregado a partir de arquivos JAR -. por isso é realmente possível ter vários arquivos faces-config.xml incluídos sem modificar web.xml, desde que se separaram em arquivos JAR

Todas as sugestões seria muito apreciada: -)

Foi útil?

Solução

Você está muito certo em pensar existem sinergias aqui, temos uma aplicação web modular, onde o aplicativo em si é montado automaticamente a partir de componentes independentes (OSGi pacotes), onde cada pacote contribui com sua próprias páginas, recursos, css e, opcionalmente, javascript.

Nós não usar JSF (Spring MVC aqui), então eu não posso comentar sobre a complexidade adicional de que o quadro em um contexto OSGi.

A maioria dos quadros ou abordagens lá fora ainda aderem à "velha" maneira de pensar: Um. arquivo WAR representando a sua webapp e, em seguida, muitos pacotes OSGi e serviços, mas quase nenhum se preocupam com a modularização do próprio GUI

Pré-requisitos para um projeto

Com OSGi a primeira questão a resolver é: qual é o seu cenário de implantação e quem é o recipiente primário? O que quero dizer é que você pode implantar seu aplicativo em um tempo de execução OSGi e usar sua infra-estrutura para tudo. Alternativamente, você pode incorporar um runtime OSGi em um servidor de aplicativo tradicional e, em seguida, você terá que re-utilizar algumas infra-estruturas, especificamente você quer usar mecanismo de servlet do AppServer.

Nosso projeto está atualmente baseado em OSGi como o recipiente e usamos o HTTPService oferecido pelo OSGi como nosso servlet container. Nós estamos olhando para fornecer algum tipo de ponte transparente entre um servlet container externo eo OSGi HTTPService mas que o trabalho está em curso.

Esboço arquitectónico de um webapp modular Spring MVC + OSGi

Assim, o objetivo não é apenas servir uma aplicação web sobre OSGi, mas também para aplicar modelo de componente do OSGi para o próprio UI web, para torná-lo combináveis, re-utilizáveis, dinâmico.

Estes são os componentes do sistema:

  • 1 pacote central que cuida da ponte Spring MVC com OSGi, especificamente ele usa href="http://thegoodthebadtheugly.wordpress.com/2007/05/20/springosgi/" por Bernd Kolb para permitir que você registrar o DispatcherServlet Primavera com OSGi como um servlet.
  • 1 costume URL Mapper que é injetado no DispatcherServlet e que fornece o mapeamento de pedidos HTTP de entrada para o controlador correto.
  • 1 Sitemesh central sediado decorador JSP que define o layout global do site, bem como o CSS central e bibliotecas JavaScript que queremos oferecer como padrão.

  • Cada pacote que quer contribuir páginas ao nosso UI web tem de publicar 1 ou mais controladores como OSGi Serviços e certifique-se de registrar seu próprio servlet e seus recursos próprios (CSS, JSP, imagens, etc ) com o OSGi HTTPService. O registro é feito com o HTTPService e os métodos principais são:

    httpService.registerResources () e httpService.registerServlet ()

Quando um ui web contribuindo ativa pacote e publica seus controladores, eles são automaticamente detectados pelo nosso pacote ui web central e o costume referido URL Mapper reúne estes serviços controlador e mantém um mapa atualizado de URLs a instâncias do controlador.

Então, quando uma solicitação HTTP chega para uma determinada URL, ele encontra o controlador associado e despacha o pedido lá.

O controlador faz o seu negócio e, em seguida, retorna todos os dados que devem ser prestados e o nome da visão (a JSP no nosso caso). Esta JSP está localizado no pacote do controlador e pode ser acessado e transmitido pelo web centro de ui agrupar exatamente porque nós fomos e registrou a localização de recursos com o HTTPService. Nossa resolver visão central em seguida, mescla essa JSP com nosso decorador e espetos centro Sitemesh o HTML resultante para o cliente.

No sabe que isso é bastante alto nível, mas sem fornecer a implementação completa é difícil explicar completamente.

O nosso ponto de aprendizado chave para isso foi a olhar para que Bernd Kolb fez com o seuconversão exemplo JPetstore para OSGi e usar essa informação para projetar nossa própria arquitetura.

IMHO não há atualmente maneira muito hype e se concentrar em obter OSGi de alguma forma incorporado em aplicativos tradicionais baseados em Java EE e muito pouca atenção a ser posta em realmente fazer uso de expressões idiomáticas OSGi e sua excelente modelo de componente para realmente permitir que o projeto de web componentizado aplicações.

Outras dicas

Confira SpringSource dm Servidor - um servidor de aplicação construída inteiramente em termos de OSGi e apoiar web modular formulários. Ele está disponível em livre, open source e versões comerciais.

Você pode começar com a implantação de um arquivo WAR padrão e, em seguida, gradualmente quebrar a sua aplicação em módulos OSGi, ou 'pacotes' em OSGi falar. Como você poderia esperar de SpringSource, o servidor tem um excelente suporte para o framework Spring e produtos do portfólio da Primavera relacionados.

Disclaimer:. Eu trabalho sobre este produto

Esteja ciente do servidor Primavera DM licenciamento .

Estamos usando Restlet com OSGi para um bom efeito com um serviço incorporado Http (sob as cobertas é realmente Jetty, mas tomcat está disponível também).

Restlet tem zero a necessidades de configuração XML mínimos, e qualquer configuração que fazemos é nos (novos serviços registrando) BundleActivator.

Ao construir-se a página, nós apenas processar as implementações de serviços relevantes para gerar a saída, estilo decorador. Novos pacotes de ficar conectado irá adicionar novas decorações página / widgets na próxima vez que o seu prestados.

RESTO nos dá limpas e significativas URLs agradáveis, múltiplas representações dos mesmos dados, e parece uma metáfora extensível (alguns verbos, muitos substantivos).

A característica do bônus para nós foi o amplo suporte para armazenamento em cache, especificamente o ETag.

SpringSource parece estar trabalhando em um framework web modular interessante construído em cima do OSGi chamado SpringSource Slices . Mais informações podem ser encontradas nos postos seguintes no blog:

Tenha um olhar em RAP! http://www.eclipse.org/rap/

Dê uma olhada http://www.ztemplates.org que é simples e fácil de aprender. Este permite que você coloque todos os modelos relacionados, JavaScript e CSS em um frasco e usá-lo de forma transparente. Significa que você ainda não têm de se preocupar declarando o JavaScript necessário na sua página ao usar um componente fornecido, como o quadro faz isso por você.

interessante conjunto de mensagens. Tenho uma aplicação web que é personalizado em uma base por cliente. Cada cliente recebe um conjunto de componentes e componentes adicionais, dependendo do que eles se inscreveu para. Para cada lançamento, temos de 'montar' o conjunto correto de serviços e aplicar a configuração de menu correto (usamos menu de suportes) com base no cliente, que é entediante para dizer o mínimo. Basicamente é a mesma base de código, mas nós simplesmente personalizar a navegação para expor ou ocultar certas páginas. Isso obviamente não é ideal e gostaríamos de OSGi alavanca para serviços inserir componentes. Enquanto eu posso ver como isso é feito para APIs de serviço e tipo de entender como recursos como CSS e java script e controladores (usamos Spring MVC) também poderia ser incluído, como você iria sobre como lidar com as preocupações transversais ", como navegação de página e trabalho em geral fluir especialmente no cenário onde você deseja implantar dinamicamente um novo serviço e necessidade de adicionar a navegação para esse serviço. Também pode haver outras preocupações dos transversais ", como serviços que abrangem outras de outros serviços. Obrigado, Declan.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top