Tecnologia para desenvolver em componentes (Portlets, etc...)

Front-end
#1

Pessoal, acho que o título do tópico não ficou bom, mas não consegui pensar em um melhor.

É o seguinte, aqui onde eu trabalho desenvolvemos aplicações corporativas pra web. E estamos pesquisando se tem jeito de desenvolver componentes separados, como se fossem plugins mesmo. Queria saber se existe algo que permita que eu desenvolva um componente (um jar por exemplo) e apenas “encaixe” esse jar na aplicação e a funcionalidade já é adicionada (telas, etc…).
Andei dando uma pesquisada em portlets, mas pelo que eu vi, eles são mais voltados para o front end (me corrijam se eu estiver errado) e não sei bem se é isso que eu quero.

Sei que existem tecnologias e padrões onde você pode empacotar ou separar componentes de negócio e adicionar na aplicação, mas, isso não bastaria pois, de qualquer forma eu tenho que fazer implementações na camada de apresentação para invocar esses componentes de negócio por exemplo.

Não sei se fui claro no que eu estou querendo.

Conto com a ajuda de vocês!

#2

Deixa eu ver se entendi:
Você pensa em encapsular um componente “full”(apresentação+negócio)?

#3

Isso aí.

Se é que tem jeito né.

#4

Com Portlet isso é possível caso você não use/precise de EJB em um módulo separado. Assim, você teria um portlet (dentro de um projeto war e esse portlet pode fazer a camada de apresentação e a camada de negócio (dentro do WAR e sem EJB). Para usá-lo, instalada o Portlet (precisa de um Portal Server) e consegue configurá-lo para aparecer na página. Na teoria é lindo, mas na prática o processo é um pouco custoso (experiência própria)

Agora na minha opinião, você poderia se preocupar mais com “componentes” web (JSF, JQuery, etc) e a camada de negócio seria algo mais específico para cada requisito.

#5

E pq não usar um RichFaces/PrimeFaces da vida?

#6

Jair Rillo Junior

A idéia é desenvolver componentes à parte e quando precisar desse componente na aplicação, bastaria “instala-lo”.

Eu não sei se entendi direito esse conselho. Nós aqui, já utilizamos esses componentes web (JSF, JQuery, etc…) Mas a intenção é desenvolver novos módulos sem ter que tocar na aplicação entendeu?

#7

Joomla!

#8

Como eu disse, o Portlet você não faz simplesmente “componentes”, pode fazer um módulo completo (sem o EJB). Inclusive um projeto Portlet na verdade é um projeto WAR com um arquivo portlet.xml.

Para o que você quer, o que eu acho mais aconselhavel é Portlet mesmo, porém eu particularmente eu não gosto de Portal

#9

Entendi, você poderia me dizer o motivo?

Me deixou com pé atrás hehehehe

#10

[quote=foxpv]Jair Rillo Junior

A idéia é desenvolver componentes à parte e quando precisar desse componente na aplicação, bastaria “instala-lo”.

Eu não sei se entendi direito esse conselho. Nós aqui, já utilizamos esses componentes web (JSF, JQuery, etc…) Mas a intenção é desenvolver novos módulos sem ter que tocar na aplicação entendeu?[/quote]
Não :smiley:
Exemplifica pra gente.

#11

Alguns dos motivos que eu não gosto de Portlet:

  • Precisa rodar sobre um Portal, que na minha opinião é bastante pesado
  • Você tem que trabalhar em cima da especificação dele, se você quer fazer algo diferente (como um simples href) você tem que usar as taglibs prontas dele
  • Eu não gosto do comportamento padrão dele de manter estado (embora isso seja possível alterar)
  • Nas versões que eu utilizei, ele era compativel apenas com Struts 1.1 (velho pacas), me parece que já tem versão compativel com JSF, mas não testei ainda.

Enfim, isso que eu lembro de cabeça.
Quero deixar anotado aqui que a idéia de Portlet é MUITO LEGAL, porém na prática eu não gostei muito não. Caso você queira aprender a respeito, não custa nada dar uma estudada (a nível de implementação é bem parecido com servlet).

#12

Por exemplo, você vai desenvolver uma aplicação que tem duas telas, cadastro de clientes e cadastro de funcionários.

Primeiramente criaríamos o esqueleto da aplicação onde, esse esqueleto aceitaria módulos.

À PARTE desenvolveríamos o módulo de cadastro de cliente e quando estivesse pronto, “instalaríamos” esse módulo no esqueleto da aplicação.

Posteriormente e também à parte, desenvolveríamos o módulo de cadastro de funcionários e instalaríamos no esqueleto (que já contém o módulo de clientes).

Entendeu? Repare que pra desenvolver o módulo de cliente e o de funcionários, em nenhum momento eu tive que tocar no esqueleto.

#13

Obrigado pelo esclarecimento Jair Rillo Junior!

#14

Muito interessante a discussão e também é de meu interesse. Só acho estranho que a única opção seja a arquitetura de Portlets.
Ninguém nunca precisou desenvolver uma aplicação web que ao ser iniciada verifica se algum jar novo foi incluido na aplicação e a partir dai considerar que naquele novo jar possa estar um novo módulo da aplicação?
Mesmo frameworks que possam realizar esta tarefa, alguém conhece? Ou até mesmo padrões voltados para isso.
Por exemplo no Eclipse, mesmo não sendo web, resumidamente alguém saberia dizer como funciona lá esta arquitetura de plugins que você baixa e a partir daí basta reiniciar a IDE para que ela já reconheça o novo módulo?

#15

Portal e Portlet é uma especificação.

Talvez exista algum framework em Java igual o Joomla para PHP. Se alguém conhecer, por favor nos avise :lol: . Na verdade uma simples pesquisa sobre CMS JAVA retorna alguns resultados, entre eles o seguinte: http://java-source.net/open-source/content-managment-systems. Não estou com tempo para ver, mas acho que é interessante fazer alguns teste

#16

Mas acho que não seja a melhor opção utilizar um CMS que já seja um Portlet Container só para ter uma arquitetura de plugins.
O foco da discussão é justamente ter uma aplicação com arquitetura de plugins que não seja um Portal, utilizar um CMS para buscar este objetivo implicaria em um peso muito grande sobre a aplicação, pois importaria para ela toda a estrutura de um portal.

#17

Pensei exatamente a mesma coisa que o spranta disse.

Estou precisando de uma forma de desenvolver aplicações corporativas em formato de plugins. Que seja uma arquitetura, padrão, framework já pronto…

#18

OPA!

Já desenvolvi módulos da forma como está sendo especificado aqui para aplicação web. Tratava-se de módulos de gestão de RH onde o cliente poderia (e pode até hoje) adquirir apenas um ou alguns módulos e com isso, era disponibilizado para ele apenas os módulos licenciados - com setup e tudo mais.

Entretanto, não tive dificuldades nenhuma para fazer essa suite de produtos só que a tecnologia que utilizava era MICROSOFT .NET.

Agora estou trabalhando com JAVA e tenho dificuldades para conseguir o mesmo resultado devido à arquitetura web dessa plataforma.

Já verifiquei tecnologias mencionadas mas está difícil chegar perto do que eu tinha…

Realmente não temos muita liberdade para trabalhar e aí fica difícil.

Basicamente a solução criada foi:
1 - Criação do Portal + sistema de autorização compatível com a Lei Sarbanes Oxley (SOX). Esse aplicativo possibilitava a publicação de novos módulos como plugins e o sistema de autorização já reconhecia os módulos instalados para que fossem concedidas as devidas permissões de acesso e de visibilidade de domínio bem como de auditoria;

2 - Criação de um framework para possibilitar a distribuição dos módulos em servidores diferentes de forma transparente para o portal, possibilitando o load balance e tudo mais;

3 - Criação dos módulos, começamos pelos módulos de auto-atendimento onde disponibilizavam serviços como emissão de contra-cheque, declarações, solicitações de férias, etc…

4 - Criação do serviço BPMN que possibilitou a publicação dos fluxos de processos - workflow - como se fossem serviços comuns no portal (muito bacana essa parte já que o cliente podia criar seus fluxos de processos na ferramenta de desenho de processos e publicar os processos como se estivessem instalando um novo plugin no portal);

5 - Criação do módulo de configuração que permitia ao cliente determinar o layout das páginas que ele desejava que sua empresa visse. O bacana disso tudo era que ele poderia criar vários layouts e definir para qual grupo de usuários aquele layout deveria aparecer, se o usuário teria liberdade para editar o layout, se poderia mudar a posição dos objetos (pagelets)…

Enfim, antes de mais nada foi preciso definir uma arquitetura que possibilitasse tudo isso. Essa arquitetura foi até homologada pela Microsoft mas hoje, na empresa que trabalho atualmente adotamos java e até agora estou tendo dificuldades de viabilizar algo dessa grandeza já que tudo é baseado em ferramentas já prontas que fazem muita coisa por um lado e deixam a desejar por outro.

Além disso, existem inúmeras possibilidades, o que nos leva a dedicar um tempo grande para pesquisar, encontrar, aprender e avaliar cada opção para ver qual é a mais indicada, porém, a empresa não quer gastar muito tempo com pesquisa, ela quer “resultados” rápidos porque afinal, a cultura dela é que as coisas já estão prontas e basta pegar e agregar para utilizar…só que não é bem isso né?!

Enfim, também estou nessa mano e se eu souber de algo mais concreto eu te falo.

Estou para decidir fazer o básico utilizando GWT porque tudo será feito apenas em JAVA, sem a necessidade de ferramentas adicionais. Isso tornará o processo de gestão mais fácil já que teremos diversas equipes por módulos e elas poderão trabalhar com uma única tecnologia, um único padrão e uma única arquitetura de referência, sem precisar estudar complementos.

#19