Estou desenvolvendo um sistema onde o usuário deve possuir permissoes para executar qualquer funcionalidade.
Quando eu fui passar isso para meu mundo OO ai que bicho pegou!
A quetão é quem deve controlar as permissões?
Ex.:
Usuário deve possuir permissão para exibir uma imagem.
Vendo através de responsabilidade:
Usuario possui permissão para exibir imagem;(Usuário que sabe as permissões que ele tem)
Imagem requere permissão para se exibir;(Imagem que sabe as permissoes que ele requere para se exibir)
Partindo do principio acima todo os meu objetos de negocio vao fazer verificações de permissão. (Eu particulamente acho isso tosco)
Estava pensando em colocar uma camada acima da de negocio para verificar permissões e gerar Logs!
Não vejo qual porque faria diferença, já que geralmente os conteiners web utilizam um pool de objetos criados e não ficam instanciando objetos a cada nova requisição.
[quote=jmizutani]Ok, para finalizar a questao nao é instancias…e sim as threads, stacks…performance…
De uma olhada aprofundada em threads, stack e faca simulacoes que vc verá a diferenca. É pequena mas para uma aplicacao de mais de 100 mil conexoes, vc vai ver o servidor fazendo diferenca[/quote]
Conheco alguma coisa de threads e mesmo assim nao entendi isso que voce ta falando (stacks?). Basicamente, entre o que voce comentou e o que o Daniel comentou a diferenca eh simplesmente: um acha melhor fazer isso com um filtro de Servlet e o outro acha mais interessante fazer numa classe abstrata da qual decendem todas as Actions.
Tudo bem, dependendo do cenario pode-se preferir uma ou outra, mas… performance? No que usar a Action sera mais performatico do que usar o filtro?
Se voce puder elaborar um pouco essa ideia, seria interessante. Talvez eu nao tenha captado algo que voce quis transmitir. Obrigado.
Servidores Web e Servidores de Aplicação já possuem recursos de autenticação e autorização. Vc atribui papéis (roles) para o contexto de cada requisição que é realizada e o container valida se o requisitante pode ter acesso ao recurso solicitado (autorização).
Dê uma estudada na documentação de sua ferramenta e vc certamente encontratrá informação.
[quote=Taz]
Servidores Web e Servidores de Aplicação já possuem recursos de autenticação e autorização. Vc atribui papéis (roles) para o contexto de cada requisição que é realizada e o container valida se o requisitante pode ter acesso ao recurso solicitado (autorização).
Dê uma estudada na documentação de sua ferramenta e vc certamente encontratrá informação.[/quote]
Servidores de Aplicação tb podem ser usados com clientes desktop.
Uma opção seria colocar um servidor de aplicação “escondendo” seus serviços em Session Beans Stateless. Isso pode facilitar muito sua vida não só com serviços de autenticação e autorização, mas também com controle de transações e integração com legado.
[quote=jmizutani]Ok, para finalizar a questao nao é instancias…e sim as threads, stacks…performance…
De uma olhada aprofundada em threads, stack e faca simulacoes que vc verá a diferenca. É pequena mas para uma aplicacao de mais de 100 mil conexoes, vc vai ver o servidor fazendo diferenca[/quote]
Este assunto me deixou curioso.
É claro a gente imagina que a criação de threads e pilhas pode impactar o desempenho. Mas ainda não parei para examinar a diferença entre os 2 diferentes procedimentos. Como desconfio que o Struts faz algumas coisas desnecessariamente pesadas demais passando objetos pesados para lá e para cá, eu preferiria usar filtros que são fáceis de fazer e dependem só do servidor de aplicação ao invés de me meter na herança do Struts.
Como você fez para descobrir esta diferença?
Sem usar filtros são criados menos objetos, são chamados menos métodos, são executados menos passos de programa ou é alocada menos memória?
3.a Como fez profiling do servidor de aplicação?
3.b Ou foi fazendo debug que descobriu isto?
Amigo, para as aplicacoes que desenvolvo para uma instituicao financeira é feita o seguinte:
a) cria-se um classe UsuarioBen onde lá esta todos os dados do usuario, bem como o tipo. (No nosso caso, ele vai buscar os dados no LDAP, logico q isso acontece quando ja foi feita a autenticacao que vc define nos seus xml o grupo do usuario)
b) se estiver usando Struts, criou-se uma classe abstrata(AbstractAction) onde tem o metodo principal das Action (execute) que verifica se o usuario esta null e se tiver, vai buscar no LDAP. Tambem verifica se a sessa expirou, ai mostra a pagina dizendo q Sessao Expirada. Logar Novamente. Faz o log tambem. E por ultimo (se tiver tudo ok, usuario, sessao e etc), nesse metodo chama-se o metodo executeFunc, onde esse metodo nessa classe é abstrata. Todas as actions das funcionalidades herdam a classe AbstractAction e herdando dessa classe, tem que criar o executeFunc para cada action. Portanto, toda vez que chama alguma funcionalidade, ele verifica o usuario, faz o log, verifica se a sessa expirou e etc.
4) Nas paginas jsp, utliza-se o html:logic no UsuarioBean e dependendo do tipo do Usuario mostra ou nao um link ou uma imagem.
Concordo contigo Daniel. Porem isso para aplicacoes que nao são muito dependentes de performance, principalmente para uma aplicacao que é acessada em todo Brasil
O filtro executa em ordenados stacks ou seja, vai executando e repassando para outros filtros (caso tiver mais de um). Isso pode ser besteira, mas numa aplicacao de grande porte, faz diferenca.
Sim…concordo que somente existe uma instancia para cada uma. O problema nao é as instancias, mas a criacao de stacks. Mas se vc imprimir o tempo com relacao as stacks (1 stack e 20 por exemplo) vc vai ver que dá diferenca
