Boas práticas / performace
26/01/2013 18:22
9
Boa tarde a todos,
Procurei um tópico parecido, mas não encontrei nada que abordasse diretamente
Quais boas práticas são boas em Groovy / Grails?
Coisas como por exemplo:
-dicas para perforamce
-como evitar estourar o permgen
-versão do JDK usar
-parametros da máquina virtual
-qual servidor web / de aplicação utilizar em prod
-como organizar o projeto (plugins, estrutura)
-como fazer leverage do spring
-cache
-design patterns
-testes
Valeu!
Procurei um tópico parecido, mas não encontrei nada que abordasse diretamente
Quais boas práticas são boas em Groovy / Grails?
Coisas como por exemplo:
-dicas para perforamce
-como evitar estourar o permgen
-versão do JDK usar
-parametros da máquina virtual
-qual servidor web / de aplicação utilizar em prod
-como organizar o projeto (plugins, estrutura)
-como fazer leverage do spring
-cache
-design patterns
-testes
Valeu!
5
Oi Mussatto,
sobre performance, a melhor dica que tenho é... ciência da computação.
Sério mesmo: sempre se lembrar das aulas de algoritmos e estruturas de dados que vimos na faculdade. Isto ajuda muito na hora de pensar como executar o processamento, etc.
Uma dica interessante que dou é a seguinte: se você está trabalhando com processamento em lote de registros no banco de dados relacional, use JDBC nativo ao invés do GORM: sua performance sempre vai ser ordens de magnitude superior. Porém, não do modo como os caras dizem pra usar, mas de uma maneira alternativa, tal como no código abaixo:
No modo como obtive a conexão, eu ainda estou dentro do contexto transacional do service, a diferença é que estou bypassando o GORM e o Hibernate completamente. Com isto eu evito problemas decorrentes de preenchimento de sesssão para atualizar estados dos objetos (muita atenção com este ponto) e consigo executar o processamento ordens de magnitude mais rápido.
Sobre os problemas de permgen, eu tenho uma solução que ajuda a economizar boa parte da sua memória. O que rola: toda closure que você implementa no seu código groovy no final das contas vai virar um .class. Então, o ideal é que você minimize isto ao máximo, porém sem perder a grande vantagem da linguagem que é justamente este construtor.
Então, como eu resolvo o problema? Simples: eu reaproveito a closure! Hà diversas closures que são exatamente iguais, como no exemplo abaixo em que eu ordeno três listas de pessoas, observe:
Uma solução é ter estas closures por exemplo todas agrupadas em uma única classe que você reaproveita pelo seu código fonte inteiro. Isto costuma gerar uma economia monstruosa de memória e ainda modulariza melhor o seu código.
sobre performance, a melhor dica que tenho é... ciência da computação.
Sério mesmo: sempre se lembrar das aulas de algoritmos e estruturas de dados que vimos na faculdade. Isto ajuda muito na hora de pensar como executar o processamento, etc.
Uma dica interessante que dou é a seguinte: se você está trabalhando com processamento em lote de registros no banco de dados relacional, use JDBC nativo ao invés do GORM: sua performance sempre vai ser ordens de magnitude superior. Porém, não do modo como os caras dizem pra usar, mas de uma maneira alternativa, tal como no código abaixo:
class ServicoBrutoService {
// injete o sessionFactory diretamente no seu serviço
def sessionFactory
// trabalhando com JDBC direto
def processamentoBruto() {
// Repare como obtive a conexão
def conexao = sessionFactory.currentSession.connection()
}
}
No modo como obtive a conexão, eu ainda estou dentro do contexto transacional do service, a diferença é que estou bypassando o GORM e o Hibernate completamente. Com isto eu evito problemas decorrentes de preenchimento de sesssão para atualizar estados dos objetos (muita atenção com este ponto) e consigo executar o processamento ordens de magnitude mais rápido.
Sobre os problemas de permgen, eu tenho uma solução que ajuda a economizar boa parte da sua memória. O que rola: toda closure que você implementa no seu código groovy no final das contas vai virar um .class. Então, o ideal é que você minimize isto ao máximo, porém sem perder a grande vantagem da linguagem que é justamente este construtor.
Então, como eu resolvo o problema? Simples: eu reaproveito a closure! Hà diversas closures que são exatamente iguais, como no exemplo abaixo em que eu ordeno três listas de pessoas, observe:
def pessoasFisicas = obterPessoasFisicas() // obtenho a lista de pessoas fisicas
def pessoasJuridicas = obterPessoasJuridicas()
def pessoasEsquisitas = obterPessoasEsquisitas()
// em seguida, eu as ordeno
pessoasFisicas.sort {it.nome}
pessoasJuridicas.sort {it.nome}
pessoasEsquisitas.sort {it.nome}
// repare que é a mesma closure implementada três vezes acima. Como resolvo? assim:
def closureOrdenacao = {it.nome}
// eu a reaproveito
pessoasFisicas.sort closureOrdenacao
pessoasJuridicas.sort closureOrdenacao
pessoasEsquisitas.sort closureOrdenacao
Uma solução é ter estas closures por exemplo todas agrupadas em uma única classe que você reaproveita pelo seu código fonte inteiro. Isto costuma gerar uma economia monstruosa de memória e ainda modulariza melhor o seu código.
27/01/2013 10:55
0
É muito assunto pra um post só! rs
Vou fazer separar em várias respostas, mas com ajuda de vocês seria interessante colocar estes assuntos como posts separados.
Vamos lá...
Vou fazer separar em várias respostas, mas com ajuda de vocês seria interessante colocar estes assuntos como posts separados.
Vamos lá...
27/01/2013 14:18
5
*** DICAS DE PERFORMANCE ***
PREMISSA: "A otimização prematura é a raiz de todo o mal" (Donald Knuth) - ou seja, quem otimiza antes da hora, atrasa as entregas e pode estar otimizando algo que não faz a menor diferença pro usuário final (ex. chamada única de 0,0001seg para 0,001seg) e o pior, deixando o código menos legível. O ideal são otimizações que não alteram o código
1) Utilizar a JRockit JVM.
O desempenho que se consegue em alguns casos é de até 20% automaticamente. Contudo, o Grails utiliza algumas libs proprietárias da Sun HotSpot JVM que causam problemas, sendo necessário pequenos ajustes. Mas como a comunidade Grails tá muito fera, basta seguir este post: http://blog.terrencemiao.com/pt/archives/keep-walking-around-weblogic-server-and-jrockit-traps
Preciso alterar código? Não :-D
2) Atualizar para o Grails 2.2.
O Grails 2.2 usa o Groovy 2.0 que mesmo sendo uma linguagem dinâmica tem performance equivalente à linguagem estática como Java ou Scala. Vários que já usaram sabem que o desempenho do Groovy e do Grails já é muito satisfatório por toda produtividade que oferece, mas agora você pode usar o Groovy em *todos* os cenários. "Aquele abraço" pra linguagem Java e viva a plataforma Java! :-)
Preciso alterar código? Poucas ou nenhuma nas versões 2.0. Nas versões 1.x só atualize se a necessidade de desempenho é crítica (algo muito raro), pois necessita de muitas alterações pontuais.
3) Utilizar funcionalidades static do Groovy 2.0
Nas versões do Grails que utilizam Groovy 2.0. As anotações para Static Checking e Static Compiling trazem bons ganhos de desempenho. Mas use SOMENTE quando necessitar de mais desempenho. Desempenho *nunca* deve ser a prioridade, do contrário estaríamos programando em Assembly até hoje.
What's new in Groovy 2.0?
http://www.infoq.com/articles/new-groovy-20
Preciso alterar código? Somente adicionar anotações, sem alteração de código.
3) Sempre ler a seção What's New do Grails que você utiliza e as Release Notes do Groovy que o acompanha. Atualizar sempre que possível pra ultima versão para ter os benefícios de desempenho das novas versões do Groovy.
Grails User Guide - What's New in Grails 2.2?
http://grails.org/doc/2.2.x/guide/introduction.html#whatsNew22
Preciso alterar código? Utilize nas próximas entregas. Somente atualize o código corrente se desempenho for necessário.
PREMISSA: "A otimização prematura é a raiz de todo o mal" (Donald Knuth) - ou seja, quem otimiza antes da hora, atrasa as entregas e pode estar otimizando algo que não faz a menor diferença pro usuário final (ex. chamada única de 0,0001seg para 0,001seg) e o pior, deixando o código menos legível. O ideal são otimizações que não alteram o código
1) Utilizar a JRockit JVM.
O desempenho que se consegue em alguns casos é de até 20% automaticamente. Contudo, o Grails utiliza algumas libs proprietárias da Sun HotSpot JVM que causam problemas, sendo necessário pequenos ajustes. Mas como a comunidade Grails tá muito fera, basta seguir este post: http://blog.terrencemiao.com/pt/archives/keep-walking-around-weblogic-server-and-jrockit-traps
Preciso alterar código? Não :-D
2) Atualizar para o Grails 2.2.
O Grails 2.2 usa o Groovy 2.0 que mesmo sendo uma linguagem dinâmica tem performance equivalente à linguagem estática como Java ou Scala. Vários que já usaram sabem que o desempenho do Groovy e do Grails já é muito satisfatório por toda produtividade que oferece, mas agora você pode usar o Groovy em *todos* os cenários. "Aquele abraço" pra linguagem Java e viva a plataforma Java! :-)
Preciso alterar código? Poucas ou nenhuma nas versões 2.0. Nas versões 1.x só atualize se a necessidade de desempenho é crítica (algo muito raro), pois necessita de muitas alterações pontuais.
3) Utilizar funcionalidades static do Groovy 2.0
Nas versões do Grails que utilizam Groovy 2.0. As anotações para Static Checking e Static Compiling trazem bons ganhos de desempenho. Mas use SOMENTE quando necessitar de mais desempenho. Desempenho *nunca* deve ser a prioridade, do contrário estaríamos programando em Assembly até hoje.
What's new in Groovy 2.0?
http://www.infoq.com/articles/new-groovy-20
Preciso alterar código? Somente adicionar anotações, sem alteração de código.
3) Sempre ler a seção What's New do Grails que você utiliza e as Release Notes do Groovy que o acompanha. Atualizar sempre que possível pra ultima versão para ter os benefícios de desempenho das novas versões do Groovy.
Grails User Guide - What's New in Grails 2.2?
http://grails.org/doc/2.2.x/guide/introduction.html#whatsNew22
Preciso alterar código? Utilize nas próximas entregas. Somente atualize o código corrente se desempenho for necessário.
27/01/2013 14:18
4
** MÁQUINA VIRTUAL **
Todas as dicas valem para qualquer aplicação Java, mas o Grails por usar o Groovy que é uma linguagem dinâmica, agradece mais que a maioria!
1) Qual versão utilizar?
Sempre a ultima versão suportada.
Pra Grails 2.2 utilize a JDK 7 (invokedynamic) para ter o Groovy 2.0 com desempenho equivalente a linguagens estáticas como Java e Scala. Caso contrário ele não vai se adaptar a JDK 6 ou menores, ou seja, não vai utilizar o invokedynamic que é específico da JDK 7.
2) Parametros da Máquina Virtual
- JRockit JVM: Os parâmetros padrões costumam atender. Mas estude os parâmetros específicos dela se necessário.
- HotSpot JVM: Vai depender muito pelo tamanho da aplicação. O ideal é fazer sob demanda, como aumentar o PermGen e o HeapSize quando há PermGen e Out of Memory Exceptions respectivamente. Com novas versões do Grails, o GSP não utiliza closures para action o que reduz esta necessidade, ou seja, nestas versões considere reduzir se você precisa de memória.
Se o problema é memória, considere que um pente de memória é muito mais barato do que horas de otimização (sem garantia de sucesso) - e você ainda chega cedo em casa pra curtir seu filho ou jogar videogame! Quando precisar convencer a gerência, sempre utilize o argumento financeiro.
3) Como evitar PermGen Exceptions?
- Utilize a JRockit JVM e dê um *adeus* pra este problema. :-)
- A excelente dica do Kico para reuso de closures é uma boa prática em qualquer caso. Mas se precisar usar a Hotspot JVM, siga esta boa prática com afinco. O líder de desenvolvimento deve revisar o código do time a cada commit.
4) Como evitar OutOfMemory Exceptions?
Caso você não faça um loop infinito que consuma muita memória e estoure a capacidade (memory leak), a JRockit JVM também resolve este problema! Parece milagre, mas é verdade.
5) Como resolver problemas de estouro de memória?
HotSpot JVM
- Utiliza a ferramenta Visual VM. É a melhor ferramenta free para análise de memória (profiling). Para simular cenários de alta carga, automatize com Greb (recomendado) ou JMeter.
JRockit JVM
- Adquira uma licença do Mission Control. É de longe a melhor ferramenta para análise de memória. Em um dos clientes que atendi, o Visual VM não encontrou o leak. Já o Mission Control apontou o trecho exato do código que estava gerando o estouro de memória.
6) Como resolver problemas de GC pause (muito tempo de CPU fazendo garbage collector)?
A JRockit JVM mata o problema na hora. :-)
AVISO FINAL: A Oracle vai unificar a HotSpot e a JRockit a longo prazo. Este não é um trabalho simples pois é necessário se preocupar com todo um legado Java rodando muito bem no mercado, além da HotSpot ter muito pacote "com.sun" que gera dependência direta e dificulta o processo. Mas em breve teremos uma JVM unificada para a plataforma de desenvolvimento mais utilizada do mundo.
Todas as dicas valem para qualquer aplicação Java, mas o Grails por usar o Groovy que é uma linguagem dinâmica, agradece mais que a maioria!
1) Qual versão utilizar?
Sempre a ultima versão suportada.
Pra Grails 2.2 utilize a JDK 7 (invokedynamic) para ter o Groovy 2.0 com desempenho equivalente a linguagens estáticas como Java e Scala. Caso contrário ele não vai se adaptar a JDK 6 ou menores, ou seja, não vai utilizar o invokedynamic que é específico da JDK 7.
2) Parametros da Máquina Virtual
- JRockit JVM: Os parâmetros padrões costumam atender. Mas estude os parâmetros específicos dela se necessário.
- HotSpot JVM: Vai depender muito pelo tamanho da aplicação. O ideal é fazer sob demanda, como aumentar o PermGen e o HeapSize quando há PermGen e Out of Memory Exceptions respectivamente. Com novas versões do Grails, o GSP não utiliza closures para action o que reduz esta necessidade, ou seja, nestas versões considere reduzir se você precisa de memória.
Se o problema é memória, considere que um pente de memória é muito mais barato do que horas de otimização (sem garantia de sucesso) - e você ainda chega cedo em casa pra curtir seu filho ou jogar videogame! Quando precisar convencer a gerência, sempre utilize o argumento financeiro.
3) Como evitar PermGen Exceptions?
- Utilize a JRockit JVM e dê um *adeus* pra este problema. :-)
- A excelente dica do Kico para reuso de closures é uma boa prática em qualquer caso. Mas se precisar usar a Hotspot JVM, siga esta boa prática com afinco. O líder de desenvolvimento deve revisar o código do time a cada commit.
4) Como evitar OutOfMemory Exceptions?
Caso você não faça um loop infinito que consuma muita memória e estoure a capacidade (memory leak), a JRockit JVM também resolve este problema! Parece milagre, mas é verdade.
5) Como resolver problemas de estouro de memória?
HotSpot JVM
- Utiliza a ferramenta Visual VM. É a melhor ferramenta free para análise de memória (profiling). Para simular cenários de alta carga, automatize com Greb (recomendado) ou JMeter.
JRockit JVM
- Adquira uma licença do Mission Control. É de longe a melhor ferramenta para análise de memória. Em um dos clientes que atendi, o Visual VM não encontrou o leak. Já o Mission Control apontou o trecho exato do código que estava gerando o estouro de memória.
6) Como resolver problemas de GC pause (muito tempo de CPU fazendo garbage collector)?
A JRockit JVM mata o problema na hora. :-)
AVISO FINAL: A Oracle vai unificar a HotSpot e a JRockit a longo prazo. Este não é um trabalho simples pois é necessário se preocupar com todo um legado Java rodando muito bem no mercado, além da HotSpot ter muito pacote "com.sun" que gera dependência direta e dificulta o processo. Mas em breve teremos uma JVM unificada para a plataforma de desenvolvimento mais utilizada do mundo.
27/01/2013 14:51
2
Oi Wanderson, então tenho uma experiência bacana pra compartilhar aqui.
Recentemente atuei em um projeto com Grails 1.3.3 legado que migramos a JVM para o JRockit. Foi a melhor coisa que poderíamos ter feito!
* Nossa performance aumentou bem mais de 20%. Não cheguei a medir, mas em determinados pontos do sistema eu diria que talvez tenha sido mais. Algo em torno de 100, 200%. Num ponto, seguramente te digo que ficou 10 vezes mais rápido.
* Estabilidade melhorou MUITO. Nossa instância do Tomcat não raro ficava fora do ar. Após a migração, *nunca mais* houve queda. Está em execução há meses sem qualquer tipo de interrupção.
* E tem também o Mission Control: trabalho com ele na Squadra e é a melhor ferramenta de monitoramento que conheço. Fantástico.
* E quando dá errado? Temos um dump legível! A única vez que tivemos algum problema com este servidor pudemos ver que a causa era fora da JVM. Coisa do Linux. Sério: só o dump já seria razão pra adotar o JRockit.
Porém, nem tudo são flores: o consumo de memória inicial no JRockit é maior, então não sei se ele funcionaria bem em micro instâncias, por exemplo. Mas acredito que seja algo no qual com um pouco de análise eu não resolva.
Recentemente o Grails Brasil foi migrado do JDK6 para o Java 7. De novo, já percebo algum ganho de performance. Eu achava que nossa performance *era* ótima. Não, não era: consegui melhorar mais alguma coisa com o Java 7, que já tem aspectos do JRockit embutidos.
Quanto ao uso de bibliotecas específicas do HotSpot Sun Wanderson, no projeto que citei acima não tivemos problema algum. Você sabe quais são estas bibliotecas? No código fonte do próprio Grails nunca encontrei qualquer menção.
Recentemente atuei em um projeto com Grails 1.3.3 legado que migramos a JVM para o JRockit. Foi a melhor coisa que poderíamos ter feito!
* Nossa performance aumentou bem mais de 20%. Não cheguei a medir, mas em determinados pontos do sistema eu diria que talvez tenha sido mais. Algo em torno de 100, 200%. Num ponto, seguramente te digo que ficou 10 vezes mais rápido.
* Estabilidade melhorou MUITO. Nossa instância do Tomcat não raro ficava fora do ar. Após a migração, *nunca mais* houve queda. Está em execução há meses sem qualquer tipo de interrupção.
* E tem também o Mission Control: trabalho com ele na Squadra e é a melhor ferramenta de monitoramento que conheço. Fantástico.
* E quando dá errado? Temos um dump legível! A única vez que tivemos algum problema com este servidor pudemos ver que a causa era fora da JVM. Coisa do Linux. Sério: só o dump já seria razão pra adotar o JRockit.
Porém, nem tudo são flores: o consumo de memória inicial no JRockit é maior, então não sei se ele funcionaria bem em micro instâncias, por exemplo. Mas acredito que seja algo no qual com um pouco de análise eu não resolva.
Recentemente o Grails Brasil foi migrado do JDK6 para o Java 7. De novo, já percebo algum ganho de performance. Eu achava que nossa performance *era* ótima. Não, não era: consegui melhorar mais alguma coisa com o Java 7, que já tem aspectos do JRockit embutidos.
Quanto ao uso de bibliotecas específicas do HotSpot Sun Wanderson, no projeto que citei acima não tivemos problema algum. Você sabe quais são estas bibliotecas? No código fonte do próprio Grails nunca encontrei qualquer menção.
27/01/2013 15:18
1
** SERVIDOR JAVA (CONTAINER WEB) **
- Qual servidor Java utilizar?
Vai depender do cenário...
* Apache Tomcat ou Jetty
Para ambientes com poucas aplicações (~5 aplicações) e não relacionadas à processos de negócio, como sites institucionais e aplicativos.
Atende perfeitamente e é suportado oficialmente pelo Grails. Eu prefiro o Jetty, mais leve e fácil de gerenciar e era o servidor padrão do Grails. Mas depois que a SpringSource comprou o Grails, eles tiveram que suportar o Tomcat por causa do produto deles, o tcServer. E pra evitar trabalho extra e bugs, tenho ficado com Tomcat.
* Oracle Glashfish ou JBoss Community
Para ambientes com mais de 5 aplicações pra gerenciar, você precisa de melhor capacidade de gerenciamento e monitoramento.
JBoss foi minha escolha durante anos para servidor Java free, mas a ultima versão realmente boa que eu trabalhei foi o 4.2, exatamente a que foi responsável pela sua boa fama. A versão 5 além de demorar a sair era muito lenta e bugada, o que queimou esta versão no mercado. Tanto que a RedHat lançou o 5.x como Jboss 6, mas não resolveu o problema. Então neste período o Glassfish 3 se tornou o servidor Java EE free mais escolhido para novas implantações. A JBoss ainda tem uma marca forte, muitos servidores rodando no mercado. A versão 7 está tentando recuperar o prestígio perdido.
* Oracle WebLogic ou JBoss Enterprise
Para ambientes que rodam aplicações de missão crítica, como por exemplo sistemas que suportam todo um processo ou toda uma cadeia de negócio, onde um bug ou uma parada no ambiente gera um prejuízo incalculável como funcionários parados, vendas perdidas, marca do cliente afetada, dentre outros.
Neste cenário você precisa de um servidor que te auxilia muito no trabalho de gerenciamento e monitoramento. Também é importante o suporte do fornecedor para resolver problemas rapidamente (o ambiente não pode parar), então recomendo os servidores Java EE licenciados acima.
- Qual servidor Java utilizar?
Vai depender do cenário...
* Apache Tomcat ou Jetty
Para ambientes com poucas aplicações (~5 aplicações) e não relacionadas à processos de negócio, como sites institucionais e aplicativos.
Atende perfeitamente e é suportado oficialmente pelo Grails. Eu prefiro o Jetty, mais leve e fácil de gerenciar e era o servidor padrão do Grails. Mas depois que a SpringSource comprou o Grails, eles tiveram que suportar o Tomcat por causa do produto deles, o tcServer. E pra evitar trabalho extra e bugs, tenho ficado com Tomcat.
* Oracle Glashfish ou JBoss Community
Para ambientes com mais de 5 aplicações pra gerenciar, você precisa de melhor capacidade de gerenciamento e monitoramento.
JBoss foi minha escolha durante anos para servidor Java free, mas a ultima versão realmente boa que eu trabalhei foi o 4.2, exatamente a que foi responsável pela sua boa fama. A versão 5 além de demorar a sair era muito lenta e bugada, o que queimou esta versão no mercado. Tanto que a RedHat lançou o 5.x como Jboss 6, mas não resolveu o problema. Então neste período o Glassfish 3 se tornou o servidor Java EE free mais escolhido para novas implantações. A JBoss ainda tem uma marca forte, muitos servidores rodando no mercado. A versão 7 está tentando recuperar o prestígio perdido.
* Oracle WebLogic ou JBoss Enterprise
Para ambientes que rodam aplicações de missão crítica, como por exemplo sistemas que suportam todo um processo ou toda uma cadeia de negócio, onde um bug ou uma parada no ambiente gera um prejuízo incalculável como funcionários parados, vendas perdidas, marca do cliente afetada, dentre outros.
Neste cenário você precisa de um servidor que te auxilia muito no trabalho de gerenciamento e monitoramento. Também é importante o suporte do fornecedor para resolver problemas rapidamente (o ambiente não pode parar), então recomendo os servidores Java EE licenciados acima.
27/01/2013 17:08
0
Kico, fico muito feliz com sua experiência com JRockit. Os números são matadores!
Há 2 anos atrás na Eteg, tinhamos planos para migrar pra JRockit exatamente devido a instabilidade do Tomcat/Hotspot com alta carga de usuários. Porém havia um bug aberto no JIRA do Grails pra o JRockit 1.6 que impedia: http://jira.grails.org/browse/GRAILS-5636
Felizmente hoje é compatível. E que ótimo que vocês conseguiram migrar!
Para o alto e avante!
Há 2 anos atrás na Eteg, tinhamos planos para migrar pra JRockit exatamente devido a instabilidade do Tomcat/Hotspot com alta carga de usuários. Porém havia um bug aberto no JIRA do Grails pra o JRockit 1.6 que impedia: http://jira.grails.org/browse/GRAILS-5636
Felizmente hoje é compatível. E que ótimo que vocês conseguiram migrar!
Para o alto e avante!
27/01/2013 17:16
0
Kico, o seu ganho de desempenho pela migração pro JDK 7 foi devido ao Groovy 2 utilizar o invokedynamic. E o salto é considerável. Quando puder faça um teste de Fibonacci simples rodando no JDK 6 e no JDK7. É impresssionante.
E pessoal, a partir do Groovy 2.1 já tem suporte a JDK 7. Então se não puder migrar o Grails e ele utiliza o Groovy 2.1, basta migrar pra JDK 7 (de preferência a JRockit) e obter ganhos de desempenho.
E pessoal, a partir do Groovy 2.1 já tem suporte a JDK 7. Então se não puder migrar o Grails e ele utiliza o Groovy 2.1, basta migrar pra JDK 7 (de preferência a JRockit) e obter ganhos de desempenho.
27/01/2013 17:32
0
** BOAS PRÁTICAS PARA GRAILS VERSÃO <= 2.1 **
Pessoal, tem uma boa prática que traz um ganho considerável de desempenho pra quem pra versões anteriores à Grails 2.2 (Groovy 2.0). A boa prática para evitar código na camada de visão (GSPs).
- Utilizar Freemarker ao invés de GSP com o Freemarker Plugin
Você continua tendo todas as vantagens do GSP como TagLibs facilitadas, mas a linguagem utilizada é de marcação, ao invés de ser a linguagem Groovy. O ganho de desempenho é absurdo para cenários do mundo real.
Considerações: se for utilizar somente por questões de desempenho, nas novas versões do Grails (> 2.2) não é necessário, pois a JDK 7 faz o Groovy 2.1 ou maior ter desempenho de linguagem estática, equiparável a linguagem Java.
Fora isso, só é interessante utilizar caso a equipe não tenha práticas de revisão em pares (peer review) ou revisão pós-commit para evitar regras de negócio na camada de visão. Vale a pena lembrar: códigos para lidar com disposição de interface (uso de if por exemplo) não necessáriamente são regras de negócio.
Pessoal, tem uma boa prática que traz um ganho considerável de desempenho pra quem pra versões anteriores à Grails 2.2 (Groovy 2.0). A boa prática para evitar código na camada de visão (GSPs).
- Utilizar Freemarker ao invés de GSP com o Freemarker Plugin
Você continua tendo todas as vantagens do GSP como TagLibs facilitadas, mas a linguagem utilizada é de marcação, ao invés de ser a linguagem Groovy. O ganho de desempenho é absurdo para cenários do mundo real.
Considerações: se for utilizar somente por questões de desempenho, nas novas versões do Grails (> 2.2) não é necessário, pois a JDK 7 faz o Groovy 2.1 ou maior ter desempenho de linguagem estática, equiparável a linguagem Java.
Fora isso, só é interessante utilizar caso a equipe não tenha práticas de revisão em pares (peer review) ou revisão pós-commit para evitar regras de negócio na camada de visão. Vale a pena lembrar: códigos para lidar com disposição de interface (uso de if por exemplo) não necessáriamente são regras de negócio.
27/01/2013 17:56
0
Oi Wanderson, neste caso acho que não.
O Grails Brasil usa o Grails 1.3.9.
Mas com relação ao tráfego, é interessante: Grails Brasil nunca caiu e temos algo em torno de no mínimo umas 200 conexões simultâneas. E isto por anos usando a jvm da Sun tradicional com Java 6. Passei oro Java 7 semana passada apenas.
Mas é o tal negócio: JVM ajuda bastante, mas no final das contas, minha arma secreta sempre foi ciência da computação na veia! :)
Conceitual bem aplicado é a melhor plataforma. Sempre.
O Grails Brasil usa o Grails 1.3.9.
Mas com relação ao tráfego, é interessante: Grails Brasil nunca caiu e temos algo em torno de no mínimo umas 200 conexões simultâneas. E isto por anos usando a jvm da Sun tradicional com Java 6. Passei oro Java 7 semana passada apenas.
Mas é o tal negócio: JVM ajuda bastante, mas no final das contas, minha arma secreta sempre foi ciência da computação na veia! :)
Conceitual bem aplicado é a melhor plataforma. Sempre.
27/01/2013 17:57
2
Sensacional as postagens =)
A maior parte dos gargalos que eu vejo hoje em dia são de códigos mal escritos, problemas com modelagem e arquitetura...
Eu li a um bom tempo atras o Clean Code e o Pragmatic Programmer que me ajudaram a escrever menos código mal feito.
Uma coisa que digo para projetos em Grails: faça testes de integração, e se não for documentar escreva direito o código (funcoes com nomes condizentes, objetos)
Se possível desenvolva em TDD, o framework tem muita funcionalidade pronta e boa pra isso mas ainda é ignorado
A maior parte dos gargalos que eu vejo hoje em dia são de códigos mal escritos, problemas com modelagem e arquitetura...
Eu li a um bom tempo atras o Clean Code e o Pragmatic Programmer que me ajudaram a escrever menos código mal feito.
Uma coisa que digo para projetos em Grails: faça testes de integração, e se não for documentar escreva direito o código (funcoes com nomes condizentes, objetos)
Se possível desenvolva em TDD, o framework tem muita funcionalidade pronta e boa pra isso mas ainda é ignorado
27/01/2013 19:31
1
Para projetos grandes, testes é fundamental.... pq senão vc vai criar 10 bugs pra resolver 1
pq senao vai contratar 10 testers e estourar o budget =P
Jenkins / Hudson e Grails é uma combinação que te deixa muito mais calmo quando pra realizar uma virada em produção =)
pq senao vai contratar 10 testers e estourar o budget =P
Jenkins / Hudson e Grails é uma combinação que te deixa muito mais calmo quando pra realizar uma virada em produção =)
27/01/2013 19:33
2
** DICAS DE PERFORMANCE PARA PROCESSADORES MULTI-CORE **
- Utilizar o GPars, principalmente para lidar com coleções
O GPars é uma bilbioteca feita pra escrever código paralelizado em Groovy, aproveitando os vários cores de um processador. O GPars ficou tão bom que foi agregado ao Groovy como um módulo a partir da versão 2.0.
Utilizando o Groovy 2.0 vc já tem extensões prontas pra uso em Collection e Lists:
> list.eachParallel()
> list.findAllParallel()
.. e várias outras!
Elas já fazem uso automático de paralelismo que o GPars proporciona. É só usar!
Para entender os conceitos: GPars Concept Explained
http://www.infoq.com/presentations/Grails-2
Para entender profundamente paralelismo na plataforma Java, Groovy e GPars
http://www.slideshare.net/paulk_asert/concurrency-with-gpars
Já utilizei várias abordagens para paralelizar código, como Actor no Scala e algumas com a lib Akka com Java. O Groovy 2.0 com o GPars integrado suporta muito mais abordagens e também tem o código mais legível.
* Concurrent collection processing
* Composable asynchronous functions
* Fork/Join abstraction
* Actor programming model
* Dataflow concurrency constructs
* CSP
* Agent - a thread-safe reference to mutable state
* STM (Software Transactional Memory)
Pra entender melhor qual utilizar: http://gpars.codehaus.org/Concepts+compared
Vejam alguns exemplos na prática de várias técnicas: http://www.ibm.com/developerworks/java/library/j-gpars/
- Utilizar o GPars, principalmente para lidar com coleções
O GPars é uma bilbioteca feita pra escrever código paralelizado em Groovy, aproveitando os vários cores de um processador. O GPars ficou tão bom que foi agregado ao Groovy como um módulo a partir da versão 2.0.
Utilizando o Groovy 2.0 vc já tem extensões prontas pra uso em Collection e Lists:
> list.eachParallel()
> list.findAllParallel()
.. e várias outras!
Elas já fazem uso automático de paralelismo que o GPars proporciona. É só usar!
Para entender os conceitos: GPars Concept Explained
http://www.infoq.com/presentations/Grails-2
Para entender profundamente paralelismo na plataforma Java, Groovy e GPars
http://www.slideshare.net/paulk_asert/concurrency-with-gpars
Já utilizei várias abordagens para paralelizar código, como Actor no Scala e algumas com a lib Akka com Java. O Groovy 2.0 com o GPars integrado suporta muito mais abordagens e também tem o código mais legível.
* Concurrent collection processing
* Composable asynchronous functions
* Fork/Join abstraction
* Actor programming model
* Dataflow concurrency constructs
* CSP
* Agent - a thread-safe reference to mutable state
* STM (Software Transactional Memory)
Pra entender melhor qual utilizar: http://gpars.codehaus.org/Concepts+compared
Vejam alguns exemplos na prática de várias técnicas: http://www.ibm.com/developerworks/java/library/j-gpars/
27/01/2013 21:24
1
Wanderson,
vi que vc falou muito bem do JRockit JVM. Se eu quiser utilizá-lo hoje em meu projeto Grails o que tenho que fazer? Por onde começar? Me ajuda ai....
Abraço
vi que vc falou muito bem do JRockit JVM. Se eu quiser utilizá-lo hoje em meu projeto Grails o que tenho que fazer? Por onde começar? Me ajuda ai....
Abraço
28/01/2013 12:04
0
@Rodrigo: Teoricamente só desinstalar o JDK antigo e instalar o JRockit (tirar bibliotecas antigas, trocar o JAVA_HOME, colocar $JAVA_HOME/bin no PATH, etc)
Alguém sabe qual tomcat (6 ou 7) é o certo de utilizar?
Já vi umas coisas dizendo sobre a versão do servlet que o Grails usa (2.5 ou 3) e o tomcat, mas não sei se dá problema
Alguém sabe qual tomcat (6 ou 7) é o certo de utilizar?
Já vi umas coisas dizendo sobre a versão do servlet que o Grails usa (2.5 ou 3) e o tomcat, mas não sei se dá problema
28/01/2013 14:02
0
Mussatto,
fazendo isso é possível programar normalmente minha aplicação ou tenho que adaptar a nível de implementação?
Porque o JRockit é considerado melhor que o JDK 7? Pelo que vi, sua última versão, só funciona na JVM 6 né?
fazendo isso é possível programar normalmente minha aplicação ou tenho que adaptar a nível de implementação?
Porque o JRockit é considerado melhor que o JDK 7? Pelo que vi, sua última versão, só funciona na JVM 6 né?
28/01/2013 14:14
0
Não precisa mudar nada de código não (pelo menos não imagino um caso em que precisaria)
Então, o Jrockit foi comprado pela oracle e tão unindo as features dele ao Hotspot (JVM da oracle)
Ele implementa as especificações do Java6 sim.
Agora comparar ele com o Hotspot java7 não sei dizer =/
Então, o Jrockit foi comprado pela oracle e tão unindo as features dele ao Hotspot (JVM da oracle)
Ele implementa as especificações do Java6 sim.
Agora comparar ele com o Hotspot java7 não sei dizer =/
28/01/2013 15:01
0
@Rodrigo
Como o Mussatto disse é só apontar para a JRockit VM. Recomendamos desinstalar a HotSpot VM para garantir que ele utilizará a JRockit.
Como disse no post sobre máquina virtual, você não vai precisar de nenhuma alteração de código. Eu utilizei no tempo em que era necessário ajustar as configurações. Hoje nem isso precisa, é só apontar e pronto.
Assim como o Kico, poste aqui os seus resultados mensurados. Sempre há ganhos, 20% em média além de eliminar problemas de estouro de memória, mas os ganhos variam de aplicacao pra aplicacao e de rotina pra rotina. O Kico em uma rotina teve ganho de até 10x de ganho ou seja 500%. Sem ajuste de código ou parametros.
Boa sorte!
Como o Mussatto disse é só apontar para a JRockit VM. Recomendamos desinstalar a HotSpot VM para garantir que ele utilizará a JRockit.
Como disse no post sobre máquina virtual, você não vai precisar de nenhuma alteração de código. Eu utilizei no tempo em que era necessário ajustar as configurações. Hoje nem isso precisa, é só apontar e pronto.
Assim como o Kico, poste aqui os seus resultados mensurados. Sempre há ganhos, 20% em média além de eliminar problemas de estouro de memória, mas os ganhos variam de aplicacao pra aplicacao e de rotina pra rotina. O Kico em uma rotina teve ganho de até 10x de ganho ou seja 500%. Sem ajuste de código ou parametros.
Boa sorte!
28/01/2013 22:15
0
Obrigado por me ajudar com estas dúvidas Wanderson!
Confesso que ne não fosse por este post nunca saberia disso. Sinceramente pensei que para o projeto Grails apenas a JDK do Java fosse possível. O estranho é que com tamanho ganho, não existe nenhuma recomendação do Grails para uso do JRockit. Poderia ter né? Facilitaria para os iniciantes.
Apenas fico na dúvida do porque que o rockit utiliza a JDK 6 e não o 7. Em meu servidor de produção esta o Java 7, será que pode dar algum problema???
Confesso que ne não fosse por este post nunca saberia disso. Sinceramente pensei que para o projeto Grails apenas a JDK do Java fosse possível. O estranho é que com tamanho ganho, não existe nenhuma recomendação do Grails para uso do JRockit. Poderia ter né? Facilitaria para os iniciantes.
Apenas fico na dúvida do porque que o rockit utiliza a JDK 6 e não o 7. Em meu servidor de produção esta o Java 7, será que pode dar algum problema???
28/01/2013 23:49
1
Aproveitando o calor da discussão @Wanderson.santos você havia feito um paralelo entre o Glassfish e o Jboss... em sua opinião pessoal, qual dos 2 prefere o GlassFish 3.1 ou o Jboss 7 ?
29/01/2013 13:03
0
Oi ivgsilva,
na minha vivência, JBoss 7. É mais rápido, leve e fácil de trabalhar que o Glassfish.
na minha vivência, JBoss 7. É mais rápido, leve e fácil de trabalhar que o Glassfish.
29/01/2013 13:30
1
@ivgsilva
O JBoss 7 Community teve um salto muito grande e se tornou um concorrente do Glassfish hoje em dia. O JBoss 5 e 6 foram uma decepção.
O artigo abaixo é excelente. Mostra como o Glassfish por vários anos foi muito mais rápido que o JBoss AS. E somente com o JBoss 7 eles conseguiram alcançar o Glassfish. Vejam a tabela.
JBoss AS 7: Catching up with Java EE 6
http://hwellmann.blogspot.com.br/2011/10/jboss-as-7-catching-up-with-java-ee-6.html
Contudo, como diz o artigo, somente o tempo de subida da aplicação não é o único ponto a ser considerado. Existem vários fatores como a velocidade da aplicação em execução (tempo de resposta), suporte a alta carga de usuários (escalabilidade), clusterização e documentação.
Minha preferência é o Glassfish e cito os motivos abaixo:
- O Glassfish 3 (lançado em 2009) tem um código mais estável que o JBoss 7 (lançada em 2011) ainda assim com os specs incompletos, que só vieram na versão 7.1, lançada a menos de 1 ano.
- O Glassfish suporta mais usuários simultâneos que o JBoss pois utiliza o Grizzly que é NIO (não bloqueia acesso a arquivos) por default, enquanto o JBoss ainda usa o bom mas defasado Tomcat que não usa NIO por default.
- O Glassfish implementa os novos specs Java antes de outros servidores. Ou seja, o Java EE 7 vai sair no Glassfish e pelo histórico da JBoss, demorar a ser suportado. E não tem jeito de fazer o JBoss funcionar com uma spec que não suporta.
- A JBoss tem um histórico de soltar releases *sem implementar* o spec inteiro como a 5.0 (JavaEE 5 parcial) e a 7.0 (Java EE 6 parcial). Isso é muito ruim pq você usa alguma coisa do spec e depois de gastar muito tempo com erro vc descobre que ele não suporta.
- Se precisar de um container mais robusto para gerenciar um parque de aplicações ou aplicações de missão crítica com um bom suporte, eu escolheria o WebLogic. Sendo assim a migração seria muito fácil usando Glassfish.
----------------------------------------------
Apêndice: Minha experiência com JBoss
- Conheço profundamente o JBoss 4.2 e ministrei vários cursos desta excelente versão.
- Quando a RedHat soltou o JBoss 5 com 3 anos de desenvolvimento (estigma de ser o ultimo container a suportar Java EE 5 no mercado), eles reescreveram completamente o núcleo do servidor. O resultado foi uma lista infindável de bugs de regressão, o que demonstrou a falta de cuidado com testes pela RedHat. Vários códigos simplesmente não funcionavam sem reescrita. Só deu pra utilizar na versão 5.1 que saiu 6 meses depois. Mas o maior problema foi a lentidão: ele era de 3-5x mais lento pra subir que o 4.2.
- A versão 6.0 foi uma versão "nas coxas" para implementar o Java EE 6, simplesmente pra JBoss não ficar pra trás no mercado (de novo) em implementar o spec. Mas não tinha certificação Java EE 6 nem mesmo era oficialmente suportada pela RedHat! Ou seja, se precisasse de suporte, nada feito. Isto foi como uma bomba para várias empresas que confiavam no JBoss para rodar um parque de aplicações corporativas.
- O JBoss 7 foi (novamente) uma reescrita completa do servidor, com o objetivo de eliminar a má fama de 'pesado' que o 5 e 6 carregaram. Foi a segunda reescrita completa do container em menos de 3 anos, o que claramente não é um bom sinal. De fato o JBoss 7 ficou muito mais rápido (muito mesmo!), mas novamente veio recheado de bugs que só foram ajustados na versão 7.1 que saiu ano passado.
Enfim, ainda tem muito chão pela frente para a JBoss recuperar o prestígio com vários desenvolvedores, decepcionados como eu. :-(
O JBoss 7 Community teve um salto muito grande e se tornou um concorrente do Glassfish hoje em dia. O JBoss 5 e 6 foram uma decepção.
O artigo abaixo é excelente. Mostra como o Glassfish por vários anos foi muito mais rápido que o JBoss AS. E somente com o JBoss 7 eles conseguiram alcançar o Glassfish. Vejam a tabela.
JBoss AS 7: Catching up with Java EE 6
http://hwellmann.blogspot.com.br/2011/10/jboss-as-7-catching-up-with-java-ee-6.html
Contudo, como diz o artigo, somente o tempo de subida da aplicação não é o único ponto a ser considerado. Existem vários fatores como a velocidade da aplicação em execução (tempo de resposta), suporte a alta carga de usuários (escalabilidade), clusterização e documentação.
Minha preferência é o Glassfish e cito os motivos abaixo:
- O Glassfish 3 (lançado em 2009) tem um código mais estável que o JBoss 7 (lançada em 2011) ainda assim com os specs incompletos, que só vieram na versão 7.1, lançada a menos de 1 ano.
- O Glassfish suporta mais usuários simultâneos que o JBoss pois utiliza o Grizzly que é NIO (não bloqueia acesso a arquivos) por default, enquanto o JBoss ainda usa o bom mas defasado Tomcat que não usa NIO por default.
- O Glassfish implementa os novos specs Java antes de outros servidores. Ou seja, o Java EE 7 vai sair no Glassfish e pelo histórico da JBoss, demorar a ser suportado. E não tem jeito de fazer o JBoss funcionar com uma spec que não suporta.
- A JBoss tem um histórico de soltar releases *sem implementar* o spec inteiro como a 5.0 (JavaEE 5 parcial) e a 7.0 (Java EE 6 parcial). Isso é muito ruim pq você usa alguma coisa do spec e depois de gastar muito tempo com erro vc descobre que ele não suporta.
- Se precisar de um container mais robusto para gerenciar um parque de aplicações ou aplicações de missão crítica com um bom suporte, eu escolheria o WebLogic. Sendo assim a migração seria muito fácil usando Glassfish.
----------------------------------------------
Apêndice: Minha experiência com JBoss
- Conheço profundamente o JBoss 4.2 e ministrei vários cursos desta excelente versão.
- Quando a RedHat soltou o JBoss 5 com 3 anos de desenvolvimento (estigma de ser o ultimo container a suportar Java EE 5 no mercado), eles reescreveram completamente o núcleo do servidor. O resultado foi uma lista infindável de bugs de regressão, o que demonstrou a falta de cuidado com testes pela RedHat. Vários códigos simplesmente não funcionavam sem reescrita. Só deu pra utilizar na versão 5.1 que saiu 6 meses depois. Mas o maior problema foi a lentidão: ele era de 3-5x mais lento pra subir que o 4.2.
- A versão 6.0 foi uma versão "nas coxas" para implementar o Java EE 6, simplesmente pra JBoss não ficar pra trás no mercado (de novo) em implementar o spec. Mas não tinha certificação Java EE 6 nem mesmo era oficialmente suportada pela RedHat! Ou seja, se precisasse de suporte, nada feito. Isto foi como uma bomba para várias empresas que confiavam no JBoss para rodar um parque de aplicações corporativas.
- O JBoss 7 foi (novamente) uma reescrita completa do servidor, com o objetivo de eliminar a má fama de 'pesado' que o 5 e 6 carregaram. Foi a segunda reescrita completa do container em menos de 3 anos, o que claramente não é um bom sinal. De fato o JBoss 7 ficou muito mais rápido (muito mesmo!), mas novamente veio recheado de bugs que só foram ajustados na versão 7.1 que saiu ano passado.
Enfim, ainda tem muito chão pela frente para a JBoss recuperar o prestígio com vários desenvolvedores, decepcionados como eu. :-(
29/01/2013 15:42
0
Pessoal,
Tenho receio de usar plugins pq temo pesar minha aplicação. O proprio henrique (kiko) quase não usou plugins para o GrailsBrasil por questão de performance. O que vcs acham ?
Achei muito interessante o tópico. Queria saber de vocês 2 assuntos que estão descritos no tópico: 1. como organizar o projeto (plugins, estrutura) e 2. Testes como vocês tratam a questão da implementação de testes, usam algum plugin para isso?
Tenho receio de usar plugins pq temo pesar minha aplicação. O proprio henrique (kiko) quase não usou plugins para o GrailsBrasil por questão de performance. O que vcs acham ?
Achei muito interessante o tópico. Queria saber de vocês 2 assuntos que estão descritos no tópico: 1. como organizar o projeto (plugins, estrutura) e 2. Testes como vocês tratam a questão da implementação de testes, usam algum plugin para isso?
29/01/2013 15:59
1
Sobre os plugins: a maior parte dos plugins vem com muita coisa desnecessária (e dependência), ou com muita coisa a mais. Sempre que vou utilizar, acabo reescrevendo um monte de coisas ou fazendo do 0. Recomendo utilizar somente os que são mantidos oficialmente
Sobre como organizar o projeto, depende muito da sua aplicação. Me acostumei com SOA por causa de padrões de projeto utilizados na empresa. (dá lhe xml pra todo lado)
Num projeto pessoal, fui organizar as coisas em plugin e fiz coisas muito parecidas com um projeto EAR / EJB3 hehehehe
Um projeto .war que une tudo, e varios pequenos que resolviam problemas especificos (e maven 2 pra unir tudo)
Sobre TDD, eu perguntei a mesma coisa um tempo atrás =)
Topico
Sobre como organizar o projeto, depende muito da sua aplicação. Me acostumei com SOA por causa de padrões de projeto utilizados na empresa. (dá lhe xml pra todo lado)
Num projeto pessoal, fui organizar as coisas em plugin e fiz coisas muito parecidas com um projeto EAR / EJB3 hehehehe
Um projeto .war que une tudo, e varios pequenos que resolviam problemas especificos (e maven 2 pra unir tudo)
Sobre TDD, eu perguntei a mesma coisa um tempo atrás =)
Topico
29/01/2013 16:52
0
Lembrando que organizei o projeto assim por causa de costume, me fez sentido na hora =)
Mas é uma coisa que gostaria de saber fazer melhor também
Mas é uma coisa que gostaria de saber fazer melhor também
29/01/2013 16:55
0
@Mussatto,
poderia descrever melhor como vc faz para organizar um projeto Grails em SOA? Qual conceito considerar, o que fazer?
Sei que é uma arquitetura orientada a serviços porém o que vc faz, na implementação, para incorporar os conceitos do SOA dentro do projeto Grails?
poderia descrever melhor como vc faz para organizar um projeto Grails em SOA? Qual conceito considerar, o que fazer?
Sei que é uma arquitetura orientada a serviços porém o que vc faz, na implementação, para incorporar os conceitos do SOA dentro do projeto Grails?
29/01/2013 18:18
1
@Ovidio
Pra falar a verdade um SOA "by the book" eu nunca vi =/
To devendo estudos da area, caí nessa arquitetura meio q de para-quedas
Mas os services (ou os que sao condizentes pelo menos) são expostos como webservices em rest ou SOAP.
Dae tem uma classe de parser (normalmente usando o JsonSlurper ou XmlSlurper) que traduz os objetos pra objetos de dominios daquele projeto.
Exemplo basicão:
Um forum e um servidor de login.
o Forum tem uma tabela de usuários (com atributos somente que fazem sentido pra essa aplicacao), e quando o cara vai fazer login, consome o webservice lá do servidor de login, passando o password e o usuario
dae pra sair os dados tem o model -> parser -> xml -> servico -> xml -> parser -> model
Pra falar a verdade um SOA "by the book" eu nunca vi =/
To devendo estudos da area, caí nessa arquitetura meio q de para-quedas
Mas os services (ou os que sao condizentes pelo menos) são expostos como webservices em rest ou SOAP.
Dae tem uma classe de parser (normalmente usando o JsonSlurper ou XmlSlurper) que traduz os objetos pra objetos de dominios daquele projeto.
Exemplo basicão:
Um forum e um servidor de login.
o Forum tem uma tabela de usuários (com atributos somente que fazem sentido pra essa aplicacao), e quando o cara vai fazer login, consome o webservice lá do servidor de login, passando o password e o usuario
dae pra sair os dados tem o model -> parser -> xml -> servico -> xml -> parser -> model
29/01/2013 19:01
0
Mussatto,
interessante sua explicação. Você efetua uma arquitetura de webservices com services do Grails fazendo com que serviços executem toda os procedimentos né?
Só fiquei numa dúvida, porque vc faz a comunicação com model da GSP através de um XML e não através dos objetos diretamente? Porque vc não repassa os objetos diretamente ao model?
interessante sua explicação. Você efetua uma arquitetura de webservices com services do Grails fazendo com que serviços executem toda os procedimentos né?
Só fiquei numa dúvida, porque vc faz a comunicação com model da GSP através de um XML e não através dos objetos diretamente? Porque vc não repassa os objetos diretamente ao model?
29/01/2013 23:07
1
calma lá,
só pra ver se a gente ta na mesma página
o xml é só na transmissão dos dados, quando chega na aplicacao, parseia o xml e monta os models daquele projeto
a idéia disso é pra desacoplar o projeto e ajudar na escalabilidade
imagine q vc tem um .jar com suas entidades, e vc tem 10 projetos
se precisasse trocar em 1 projeto a modelagem, vc precisa trocar em todos os projetos (dado que todos tem o mesmo banco e tal)
o xml é mais uma convenção pra poder conversar com linguagens diferentes...
vc pode ter um front escrito em .net, um backend escrito em php, um servidor de imagens em ruby, etc
só pra ver se a gente ta na mesma página
o xml é só na transmissão dos dados, quando chega na aplicacao, parseia o xml e monta os models daquele projeto
a idéia disso é pra desacoplar o projeto e ajudar na escalabilidade
imagine q vc tem um .jar com suas entidades, e vc tem 10 projetos
se precisasse trocar em 1 projeto a modelagem, vc precisa trocar em todos os projetos (dado que todos tem o mesmo banco e tal)
o xml é mais uma convenção pra poder conversar com linguagens diferentes...
vc pode ter um front escrito em .net, um backend escrito em php, um servidor de imagens em ruby, etc
30/01/2013 00:35
0
Estou entendendo (eu acho hehehe)....
Então cada um dos seus serviços comunica com outros serviços e com os models da GSP através de XMLs?
Mas daí mesmo que vc altere a modelagem de 1 projeto quando houver uma requisição, o service se encarregará de fornecer as mesmas informações para haver a integração com outras classes né?
Então seus serviços trabalham basicamente com o recebimento de uma XML e com a Remessa de outro XML processado né?
30/01/2013 00:50
1
models da gsp?
mas é essa a idéia sim, vc deixa uma interface a disposição e as requisicoes são feitas em http + json / xml
tem o layer de serviços de barramento (webservice) e os serviços da aplicação normal, não são necessáriamente TODOS os services do grails como webservice
mas é essa a idéia sim, vc deixa uma interface a disposição e as requisicoes são feitas em http + json / xml
tem o layer de serviços de barramento (webservice) e os serviços da aplicação normal, não são necessáriamente TODOS os services do grails como webservice
30/01/2013 00:54
1
Pessoal, o tema SOA está fora do tópico do post.
Estou abrindo um novo post 'Arquitetura SOA em Grails' pra gente tratar este assunto lá, ok?
Estou abrindo um novo post 'Arquitetura SOA em Grails' pra gente tratar este assunto lá, ok?
31/01/2013 00:47
0
ótima idéia, pode deixar que eu crio Wanderson!
Acho que será melhor para segmentar o assunto...
Estou muito interessado nesse assunto.
Acho que será melhor para segmentar o assunto...
Estou muito interessado nesse assunto.
31/01/2013 01:31
0
Discordo que o tópico SOA esteja fora do escopo, porque o fato de você expor serviços externamente entra como uma excelente prática de reaproveitamento de código.
É interessante discutir SOA em outro tópico, no entanto, esta entra como boa prática por uma razão muito simples: a maior dificuldade que eu vejo na hora de implementar uma solução Grails em uma empresa diz respeito ao reaproveitamento.
Então, no momento em que você chega para o gerente de TI do cliente e mostra como é fácil criar um webservice com apenas uma linha em um serviço, man.... os mano pira. Além disto, é o santo graal da computação corporativa né? Reaproveitamento.
Fica como excelente prática na minha opinião, desde que seja usada com sabedoria e, principalmente, atenção aos aspectos de segurança.
É interessante discutir SOA em outro tópico, no entanto, esta entra como boa prática por uma razão muito simples: a maior dificuldade que eu vejo na hora de implementar uma solução Grails em uma empresa diz respeito ao reaproveitamento.
Então, no momento em que você chega para o gerente de TI do cliente e mostra como é fácil criar um webservice com apenas uma linha em um serviço, man.... os mano pira. Além disto, é o santo graal da computação corporativa né? Reaproveitamento.
Fica como excelente prática na minha opinião, desde que seja usada com sabedoria e, principalmente, atenção aos aspectos de segurança.
31/01/2013 10:44
0
@Kico
Acredito que seria mais interessante tratar cada assunto em separado por um motivo: quando alguém faz uma busca sobre algum assunto como SOA ou JDK e cai aqui, terá que ler todas as respostas para filtrar exatamente aquilo se é interessante pra ele ou não - o que não ocorre num novo tópico com um título mais direcionado como o que foi criado pelo Ovídio.
Aproveitando o assunto, SOA é uma arquitetura e não necessariamente uma boa prática. Anos atrás vi sistemas .NET feito todo com WebService SOAP com desempenho sofrível. Outro dia vi um cara reclamando que REST é lento num fórum e quando perguntaram o que ele fez, ele simplesmente transformou todas as chamadas de métodos em recursos REST desempenho. O objetivo dele era reutilizar tudo mas ele nem avaliou se ia precisar utilizar e simplesmente esqueceu de bibliotecas e repositórios. Eu discorro sobre isso no outro post.
Sendo assim existem cenários onde SOA é recomendado e se utilizado existem boas práticas de Arquitetura Orientada a Serviço, o que me parece ultrapassar a questão "boas práticas em Grails" e entrar na seara de Arquitetura de Sistemas de um modo geral, o que exige um texto mais detalhado, assim como respostas que postei aqui sobre JVM, Servidor de Aplicação, etc. que gostaria de ter aberto outro tópico para cada uma delas.
Acredito que seria mais interessante tratar cada assunto em separado por um motivo: quando alguém faz uma busca sobre algum assunto como SOA ou JDK e cai aqui, terá que ler todas as respostas para filtrar exatamente aquilo se é interessante pra ele ou não - o que não ocorre num novo tópico com um título mais direcionado como o que foi criado pelo Ovídio.
Aproveitando o assunto, SOA é uma arquitetura e não necessariamente uma boa prática. Anos atrás vi sistemas .NET feito todo com WebService SOAP com desempenho sofrível. Outro dia vi um cara reclamando que REST é lento num fórum e quando perguntaram o que ele fez, ele simplesmente transformou todas as chamadas de métodos em recursos REST desempenho. O objetivo dele era reutilizar tudo mas ele nem avaliou se ia precisar utilizar e simplesmente esqueceu de bibliotecas e repositórios. Eu discorro sobre isso no outro post.
Sendo assim existem cenários onde SOA é recomendado e se utilizado existem boas práticas de Arquitetura Orientada a Serviço, o que me parece ultrapassar a questão "boas práticas em Grails" e entrar na seara de Arquitetura de Sistemas de um modo geral, o que exige um texto mais detalhado, assim como respostas que postei aqui sobre JVM, Servidor de Aplicação, etc. que gostaria de ter aberto outro tópico para cada uma delas.
31/01/2013 19:10
0
O Ovídio levantou a questão de usar ou não plugins, que é muito recorrente!
Abri um tópico para tratar do assunto: http://www.grailsbrasil.com.br/post/show/2234
Abri um tópico para tratar do assunto: http://www.grailsbrasil.com.br/post/show/2234
31/01/2013 19:44
0
*** BOAS PRÁTICAS: COMO ORGANIZAR PROJETOS (PLUGINS, ESTRUTURAS) ***
O Grails já possui uma ótima estrutura baseada nos padrões da Spring. Contudo por muitas vezes queremos criar vários módulos para uma aplicação. Para isso existe um padrão chamado "Plugin-Oriented Architecture" que a Spring publicou em seu blog em 2010:
What's Plugin-Oriented Architecture
http://blog.springsource.com/2010/06/01/whats-a-plugin-oriented-architecture/
Recentemente o Ken Liu da IEEE.org (sim, eles usam Grails desde 2009!) fez uma excelente apresentação sobre o assunto na 2GX:
Modularizing your Grails Application with Private Plugins - SpringOne 2GX 2012
No mais seguem outras dicas...
- Estudar e fazer uso do Sitemesh. Dá pra fazer herança de templates (layouts no Grails) utilizando o <g:applyLayout> para aplicar os templates pais nos filhos.
- Evitar criar uma classe única de TagLib. O Grails aceita várias classes de taglib pra um sufixo. Por exemplo, se você criar TFormsTagLib e TTableTagLib, ambas com o mesmo sufixo 't', você pode utilizar ambas taglibs como <t:form> <t:input> e <t:table> por exemplo.
A medida que for lembrando de outras eu posto mais... e em breve falo sobre testes.
Abraço!
O Grails já possui uma ótima estrutura baseada nos padrões da Spring. Contudo por muitas vezes queremos criar vários módulos para uma aplicação. Para isso existe um padrão chamado "Plugin-Oriented Architecture" que a Spring publicou em seu blog em 2010:
What's Plugin-Oriented Architecture
http://blog.springsource.com/2010/06/01/whats-a-plugin-oriented-architecture/
Recentemente o Ken Liu da IEEE.org (sim, eles usam Grails desde 2009!) fez uma excelente apresentação sobre o assunto na 2GX:
Modularizing your Grails Application with Private Plugins - SpringOne 2GX 2012
No mais seguem outras dicas...
- Estudar e fazer uso do Sitemesh. Dá pra fazer herança de templates (layouts no Grails) utilizando o <g:applyLayout> para aplicar os templates pais nos filhos.
- Evitar criar uma classe única de TagLib. O Grails aceita várias classes de taglib pra um sufixo. Por exemplo, se você criar TFormsTagLib e TTableTagLib, ambas com o mesmo sufixo 't', você pode utilizar ambas taglibs como <t:form> <t:input> e <t:table> por exemplo.
A medida que for lembrando de outras eu posto mais... e em breve falo sobre testes.
Abraço!
31/01/2013 19:54
0
Infelizmente coloquei um link acima como imagem. Segue o link correto!
Modularizing your Grails Application with Private Plugins - SpringOne 2GX 2012
http://www.slideshare.net/kennethaliu/modularizing-your-grails-application-with-private-plugins-springone-2gx-2012
Modularizing your Grails Application with Private Plugins - SpringOne 2GX 2012
http://www.slideshare.net/kennethaliu/modularizing-your-grails-application-with-private-plugins-springone-2gx-2012
31/01/2013 19:55
0
*** BOAS PRÁTICAS - MODULARIZAR GRAILS COM ARQUITETURA ORIENTADA A PLUGINS ***
Segue este excelente documento para ajudá-los a criar plugins para modularizar sua aplicação seguindo melhores práticas:
Grails Plugin Development Best Practices
Segue este excelente documento para ajudá-los a criar plugins para modularizar sua aplicação seguindo melhores práticas:
Grails Plugin Development Best Practices
31/01/2013 19:57
0
Olá Kiko.
Não conegui implementar a ideia dos closures genéricos nos sorts.
Tem ideia se mudou alguma coisa?
Não conegui implementar a ideia dos closures genéricos nos sorts.
Tem ideia se mudou alguma coisa?
29/05/2017 18:11
Ainda não faz parte da comunidade???
Para se registrar, clique aqui.
Aprenda Groovy e Grails com a Formação itexto!
Newsletter Semana Groovy
Os melhores blogs de TI (e em português) em um único lugar!
