Segundo a querida Wikipedia, “Cache é uma coleção de dados duplicando valores existentes em algum lugar ou previamente calculados, …” [Tradução minha]. Aplicações frequentemente utilizam cache para poupar recursos com custo alto de acesso tais como Bases de Dados Relacionais, arquivos, comunicações remotas. A intenção é manter o mais próximo da aplicação, de maneira rápida e barata o acesso a dados necessários para alguma computação, ou seja: Caches são em sua maioria um conjunto de dados em memória.

Alguma vez na vida já utilizamos Cache no desenvolvimento de uma aplicação. E muito frequentemente este Cache está fortemente integrado a um framework ORM como Hibernate ou TopLink. O lado bom é que abstrai-se para o desenvolvedor os meios necessários para obtenção de dados a partir do cache, ou a partir da fonte de dados real (Banco de Dados nesse caso).  Mas essa é de longe a estratégia mais simples e, de fato, mais pobre quando se trata de tirar o máximo da sua ferramenta de Caching ou data grid.

Outro uso comum de Cache são os Caches locais, os que residem na memória da aplicação. É aí que o uso dos cache.get(key) e cache.put(key, value) aparecem, mas o simples uso destes dois métodos traz uma série de questões:

• Toda vez que uma entrada no cache é atualizada, como e quando devo aplicar tais mudanças para a fonte de dados original (ex.:  Base de Dados)?
• E se eu obtiver uma entrada no cache, iniciar um processamento e, antes de concluir este processamento a entrada for alterada?
• Eu tenho servidores geograficamente distribuídos, como compartilhar um mesmo cache para um recurso extremamente custoso entre estes servidores?
• Utilizo Cache para evitar acesso constante à Base Relacional, mas minha aplicação é “Clusterizada” e uma próxima requisição frequentemente é destinada a um servidor cuja entrada ainda não foi inserida no Cache. Como evitar acessos repetidos para os mesmos dados processados em servidores diferentes?
• Acessar uma entrada pela chave não é suficiente, isso me força a criar chaves modificadas – como “SP-Republica”, uma junção entre dados de dois campos distintos de uma mesma entidade (supondo Endereco(UF, Bairro)) – ou mesmo ignorar o cache e efetuar consultas constantemente na Base de Dados.
• Preciso realizar uma operação em milhares de entradas no cache, mas cada get() executado traz os dados para a memória local o que pode causar OutOfMemory, como contornar isso?

Poderíamos ter um Post inteiro só com questionamentos do gênero. Pelo menos um destas dúvidas você já teve, certo? Resolvi apresentar o Oracle Coherence desta maneira, respondendo estas. O Coherence é uma suite poderosa para Data Grid e Cache provida pela Oracle e permite a replicação (particionada) de dados em cluster.

Não é minha intenção (nem seria possível) cobrir todos os aspectos da ferramenta, mas sim de oferecer um Overview, um ponto de vista e até mesmo dicas para o uso da ferramenta baseado na minha experiência.

Neste Post trago uma resposta ao menos à primeira pergunta:

Toda vez que uma entrada no cache é atualizada, como e quando devo aplicar tais mudanças para a fonte de dados original (ex.:  Base de Dados)?

A técnica comumente utilizada para escrita simultânea no cache e na fonte de dados é conhecida por Write-Through (veja artigo na Wikipedia). É possível utilizar um DAO conhecedor do Cache que faz um put e um insert em uma tabela, por exemplo. Dessa maneira o Write-Through é feito com o Cache-aside, ou seja o cache participa passivamente neste processo.

O Oracle Coherence utiliza o conceito de CacheStore e oferece a interface com.tangosol.net.cache.CacheStore para onde a operação de persistência é delegada:

public class YourCacheStore implements com.tangosol.net.cache.CacheStore {
   ...
   @Override
   public void store(Object key, Object value) {
   ... // code to actually persist the value.
   }

   @Override
   public void storeAll(Map cached) {
      for (Object key : cached.keySet()) {
        ... //persist it!
      }
   }
}

O CacheStore é uma classe qualquer que conhece como obter e salvar definitivamente as informações para uma entrada no Cache. Logo, não é relevante para o Coherence como o dado é acessado, seja via JDBC, JPA, WebService, RMI, etc. O Coherece delagará a execução para a classe configurada em um cache do tipo read-write-backing-map-scheme:

	<read-write-backing-map-scheme>
		<scheme-name>DB</scheme-name>
		<internal-cache-scheme>
			<local-scheme/>
		</internal-cache-scheme>
		<cachestore-scheme>
			<class-scheme>
				<class-name>com.codemountain.grid.store.YourCacheStore</class-name>
			</class-scheme>
		</cachestore-scheme>
		<write-delay>5s</write-delay>
                <write-batch-factor>0.3</write-batch-factor>
	</read-write-backing-map-scheme>

Note o parâmetro write-delay:5s, isso significa que o Coherence vai iniciar a escrita após o tempo especificado de 5 segundos. Assim passamos a fazer o uso da técnica de Write-Behind, ou seja os dados se mantém consistentes e disponíveis para a aplicação, enquanto num momento futuro o Coherence iniciará uma escrita Assíncrona para o repositório de dados.

Até aqui temos um mecanismo integrado à ferramenta de Cache, garantindo consistência dos dados em cache e em Base de Dados. O Coherence executa o que ele chama de coalescing , ou seja, sucessivas escritas a uma mesma entrada não gerarão diversos updates/inserts para a entrada.

Write-Behind é uma técnica particularmente interessante e pode reduzir drasticamente o acesso a uma base de dados enviando em lote uma quantidade maior de registros alterados ou inseridos. É possível configurar um fator (write-bacth-factor:0.3), tal que, toda entrada cujo tempo de espera para persistência tenha atingido uma percentagem do  tempo total de delay, será enviada em lote para escrita. A formula para o wirte-batch-factor é : (1 – 0.3) * 5 = 3.5s.

Sem esta possibilidade de definir uma janela de tempo, as escritas só aconteceriam num momento diferente do insert da entrada no cache, mantendo a alta carga carga no banco de dados.  Um CacheStore implementado corretamente deve tirar proveito disso e utilizar apenas uma conexão/transação para a escrita do lote através do método storeAll(). Ah! Fique atento as necessidades de negócio e até mesmo acesso de outras aplicações a esta base dedados, estes são pontos determinantes para a adoção desta técnica.

Com o Write-Behind você pode cortar pela metade a quantidade de acesso à base de dados. Numa aplicação onde eu e minha equipe aplicamos o Oracle Coherence, eliminamos um INSERT + SELECT + UPDATE por apenas um INSERT. Ou seja, o dado era criado em memória no cluster, obtido em um momento posterior e então atualizado. Com o Coherence, e as operações ocorrendo em memória, todas as manipulações se traduzem para um único INSERT no final do procedimento. Multiplique 3 acesso à base de dados por 2 milhoes de transações e note que uma operação é muito menos custosa para todo o seu ambiente.

A geração de IDs para registros na base de dados pode ser feita em cluster de forma segura (leia-se consistente) evitando até mesmo um MY_SEQUENCE.nextval.

É importante saber que há também aqueles que não acreditam em Caches como a melhor solução. Como disse Greg Linden: “Camadas de Cache adicionam complexidade ao design, latência para entradas não encontradas no cache, e uso infeficiente de recursos ‘clusterizados’” (Tradução livre minha). Greg ainda advoga a favor da remoção das camadas de cache e transferência de tais máquinas para a camada de banco de dados, que por sua vez deve apostar alto no particionamento e em seus próprios mecanismos de cache.

Ao tomar decisões de design para aplicações que demandam alta disponibilidade, baixar latência e alta performance, esteja ciente das vantagens e desvantagens das diversas topologias e abordagens disponíveis, inclusive o caching.

Todas as informações sobre o produto podem ser encontradas na documentação do próprio produto Oracle Coherence de propriedade da Oracle. Este blog não expressa direta ou indiretamente quaisquer opinião da Oracle.

Meu querido amigo @lucastex Postou sobre Elvis operator em Groovy. Ele também me perguntou se Scala tinha este operador. E eu disse: Não, mas eu posso criar agora. E assim fiz:

implicit def toRockStar[B](v : B) = new { def ?: (opt: => B) : B =
                                           if (opt == null) v else opt}

Se voce observar bem neste Post, eu criei o operador % aplicável a Strings para facilitar a configuração de alguns parâmetros em uma conexão com o RabbitMQ.

Então, para usarmos nosso Rock Start Elvis operator fazemos assim:

scala> val name : String = null
name: String = null

scala> val l = name ?: "Lucas"
l: java.lang.String = Lucas // resultado deve ser Lucas

scala> val p = l ?: "Paulo" // Resultado Deve ser Lucas
p: java.lang.String = Lucas

A variável imutável p só deve receber o valor Paulo se a variável l não tiver sido atribuído a uma String. O Elvis aqui serve para qualquer tipo, pois foi construído de forma genérica com tipos parametrizados (ver o [B]).

Em Scala os operadors aritiméticos também são funções e não operadores da linguagem. Logo, existe a possibilidade de criação de qualquer operador com o nível de complexidade necessário para resolver o seu problema.

Foi um post curto, e um bate bola com o Lucas. Tento usar o público dele e de outras linguagens para atrair a atenção para Scala, uma linguagem sem dúvida promissora.

Com Scala é assim, não espere a linguagem criar um operador interessante como esse, simplesmente o faça.

No último Post tivemos uma visão inicial do uso de Specs, BDD e um exemplo de utilização do framework. Mas como você deve ter percebido, as especificações eram blocos de códigos ainda soltos no Post. Specifications são objects ou classes Scala, vejamos como declarar a especificação do post anterior, configurar uma sessão Lift, criar um contexto de execução das especificações, e por fim estender o framework Specs com Matchers personalizados.

object TodoSpec extends Specification with Contexts {

    "Create/Update a ToDo item" should {
       //... spec from last post.
    }

   //Inicia um sessão Lift
    val session = new LiftSession("", StringHelpers.randomString(20),
                                                new MockHttpSession, null)
   //Executa a dentro da sessão Lift
   def inSession(a: => Any) = {
        S.initIfUninitted(session) { a }
    }

   //Novo usuário para execução da especificação
    def loginUser = inSession {
        val user = User.create
        user.email("tester@gmail.com").password("xxxxxx")
        user.save
        User.logUserIn(user)
    }

    //Contexto de execuão da Especificação
    new SpecContext {
        //Estabelece Conexão com o banco antes da execução.
        beforeSpec {
            if (!DB.jndiJdbcConnAvailable_?)
            DB.defineConnectionManager(DefaultConnectionIdentifier,
                                                     DBVendor)
            loginUser //Acontece o login do usuário
        }
        aroundExpectations(inSession(_))

        //Remove o usuário de teste
        afterSpec {
            val user = User.find(By(User.email, "tester@gmail.com"))
            User.delete_!(user.open_!)
        }
    }
}
class TodoSpecTest extends JUnit4(TodoSpec)

Uma especificação é um objeto que extends a classe org.specs.Specification. Specification oferece um conjunto de conversores implícitos para Strings, por isso os métodos should, in e >> aparentam serem invocados a partir das strings que descrevem a especificação.

Como todo teste que deve acontecer dentro de um contexto (jndi, spring, hibernate, ejb3, etc), precisamos de um código extra para usarmos recursos do Lift e definir um contexto para a execução da especificação. Por isso, aqui usamos a trait Contexts e criamos uma nova instância de SpecContext com os métodos beforeSpec fazendo a conexão com a base de dados e aroundExpectations garantindo que a especificação ocorra dentro da sessão Lift criada.

Com Specs, você pode visulizar o resultado das execuções na sua IDE como se fossem testes JUnit. Por isso a TodoSpec é um objecto e há uma classe TodoSpecTest que extends org.specs.runner.JUnit4. O objeto da especificação é passado como construtor do runner de JUnit4. Assim temos a execução da especificação integrada com a IDE. Veja outras formas executá-las aqui.

Usamos o próprio Lift Test Kit  uma instância de HttpSession (new MockHttpSession), assim podemos instanciar corretamente uma sessão Lift.

Para a execução dos testes vamos precisar das dependências abaixo. Lembre-se de instalar no seu repositório local Maven a versão SNAPSHOT do Specs 1.6.1 encontrado aqui.

        <dependency>
            <groupId>org.scala-tools.testing</groupId>
            <artifactId>specs</artifactId>
            <version>1.6.1</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>net.liftweb</groupId>
            <artifactId>lift-testkit</artifactId>
            <version>1.0</version>
            <scope>test</scope>
        </dependency>

Outro ponto importante do framework Specs, é a sua extensibilidade. Podemos criar Matchers tão poderosos quanto queiramos para oferecer um melhor suporte à linguagem única utilizada no negócio do sistema. Supondo que a especificação descreva que um usuário logado no sistema deve ser um usuário Gmail, podemos criar nosso próprio matcher para tornar nossa especificação mais natural. Vamos adicionar o seguinte sistema para especificar o comportamento do nosso matcher, facilitando o entendimento:

    "A logged user" should {
        "be a Gmail user" in {
            val user = User.currentUser.open_!
            user.email.asString must beAtGmail
        }
    }

beAtGamil é um matcher definido em um object que pode conter diversos matchers customizados. Até aqui temos apenas um matcher:

object CustomMatcherSpec extends Specification {
    "beAtGmail" can {
        "assert users at Gmail" in {
            "paulosuzart@gmail.com" must beAtGmail
        }
    }
}

object CustomMatcher {
    import java.util.regex.Pattern
    val beAtGmail = new Matcher[String]{
        def apply(m : => String) = {
            val pattern = Pattern.compile(".+\\@gmail.com")
                                      (pattern.matcher(m).matches,
                        m + " is at Gmail",  m + " is not at Gmail")
        }
    }
}
class CustomSpecTest extends JUnit4(CustomMatcherSpec)

Não podemos esquecer de um executor JUnit4 para a integração com a IDE. Seguindo os passos do post passado, você pode ver o resultado das especificações do sistema ToDo e a especificação do Matcher customizado.

BDD é sem dúvida uma metodologia com grande potencial de expansão no mercado e torço pra que muito em breve apareçam oportunidades com tecnologias e metodologias como essas.

Ainda não sei dizer em qual a dimensão de projeto o BDD é mais apropriado, talvez as mesmas dimensões onde TDD e DDD são aplicáveis.

Detalhes como as classes DB, S e todos os fontes do Post, você vai encontrar na aplicação disponibilizada no meu repositório github. Reforço que o projeto froi criado seguindo o tutorial de Getting Started do Lift e modificado para a construção do Post. E não se esqueça de me seguir no Twitter.

Pra variar um post sem ligação alguma com o anterior. Mas vamos lá.

Há pouco mais de um ano que comecei a estudar Scala, e durante este tempo me dediquei quase que puramente à linguagem. O máximo que brinquei foi com Scala SBT, o Dispatch do n8han e outras coisinhas. Acredito que até mesmo por não ser meu foco profissional (por hora) demorei pra estudar o Lift, o framework MVC para Scala.

Completei o getting started do framework e comecei a fazer uma segunda aplicação de estudo com @lucastex e @r4f4e1. Mas o motivo desse post é um processo de desenvolvimento que me chamou a atenção depois que vi o Cucumber. BDD, ou BehaviourDrivenDevelopment é uma metodologia ágil que vem como um complemento – ou mesmo evolução – ao TDD (Test Driven Development) e se transformando em uma ferramenta primordial para o DDD (DomainDrivenDesign).

Existem muitos frameworks BDD como RSpec, Specs, Scala Test, Cucumber, JBehave, jsspec, e escolhi o Specs por algum motivo obscuro.

Sendo bem objetivo e tentando reduzir a quantidade de palavras no post (deixando o máximo de código possível), o foco do BDD é a construção de comportamentos esperados para o sistema ao invés de testes. A construção de testes, em última instância, tem interesse em verificar o comportamento que o sistema deve (should) ter em diversos cenários (examples), por isso BDD.

Outro ponto importante é a tão falada linguagem ubíqua, ou seja, uma linguagem que todos os envolvidos na construção do software consigam entender. Frameworks BDD permitem que esta linguagem seja executável e escrita na propria linguagem de construção do sistema. Scala é muito poderosa na construção de DSLs (Domain Specific Languages), chegando ao ponto do código se parecer com uma escrita em ingles, não em uma linguagem de programação. Neste post, o comportamento que escolhi especificar foi de validação de dados de domínio:

"Create/Update a ToDo item" should {
   "show the following error messages:" >> {
     "Description must be 3 characters" >> {
       "if description field length is less than 3" in {
         val todo = ToDo.create.owner(User.currentUser)
         todo.desc("").validate must
         contain(FieldError(todo.desc, Text("Description must be 3 characters")))
       }
     }
     "Priority must be 1-10" >> {
       "if priority field is not between, including, 1 and 10" in {
         val todo = ToDo.create.owner(User.currentUser)
         todo.priority(-1).validate must
         contain(FieldError(todo.priority, <b>Priority must be 1-10</b>))
        }
     }
   }
 }

Nos parágrafos acima note em negrito as palavras should e example. Indicamos com should o que o sistema (ToDo app) deve fazer nos (in) exemplos, ou cenários, que seguem.

Dada cada uma das mensagens esperadas, o trecho de código delimitado por in {…} é implementado com um ou mais matchers.  o matcher must contain é usado aqui por que o método de Validação de uma classe mapper no lift retorna um List[FieldError]. FieldError é uma case class de construção FieldError[Identifier, NodeSeq]. Logo, o matcher must contain verifica a existência de um objeto com o formato especificado na lista de erros retornados na validação.

Logo, os matcher são os responsáveis por assegurar que a especificação descrita no texto será atendida pelo resultado do código nos exemplos.

O guia de matchers apresenta uma listagem completa desta DSL que pode ser aplicada em Iterables, String, Objects, Maps, Numer, Options, ScalaChecks, XML, Arquivos e grafos de objetos. E para ilustrar o uso de matchers para string.

Ao executar a especificação acima, temos o resultado:

-------------------------------------------------------
Running com.liftworkshop.todo.TodoSpecTest
Tests run: 3, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 2.694 sec <<< FAILURE!
Running com.liftworkshop.todo.AppTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.042 sec
Results :
Failed tests:
  Create/Update a ToDo item should show the following error messages: Description must be 3 characters if description field length is less than 3
  Create/Update a ToDo item should show the following error messages: Priority must be 1-10 if priority field is not between, including, 1 and 10
  Create/Update a ToDo item should show the following error messages: Priority must be 1-10 if priority field is not between, including, 1 and 10
Tests run: 5, Failures: 3, Errors: 0, Skipped: 0

Isto por que os campos desc e priority (mostrados abaixo) não implementam nenhuma validação:

class ToDo extends LongKeyedMapper[ToDo] with IdPK {
    lazy val priorityList = (1 to 10).map(v =>; (v.toString, v.toString))
    def getSingleton = ToDo
    object done extends MappedBoolean(this)
    object owner extends MappedLongForeignKey(this, User)
    object priority extends MappedInt(this) {
        override def defaultValue = 5
        override def _toForm = Full(select(ToDo.priorityList,
                                           Full(is.toString),
                                           f => set(f.toInt)))
    }
    object desc extends MappedPoliteString(this, 128)
}
object ToDo extends ToDo with LongKeyedMetaMapper[ToDo]

E aqui chegamos a um ponto interessante do BDD, certamente herdado do TDD: vamos escrever o código estritamente necessário para atender a nossa especificação. Supondo que você tenha o mínimo de conhecimento com Lift e quem sabe tenha feito o getting started, adicionemos as validações assim:

    object desc extends MappedPoliteString(this, 128) {
        override def validations = valMinLen(3, "Description must be 3 characters") _ :: super.validations
    } // para o mapeamento da descrição e ...
    object priority extends MappedInt(this) {
    ...
        override def validations = validPriority _ :: super.validations
        def validPriority(in : Int) : List[FieldError] =
        if (in > 0 && in >= 10) Nil
        else List(FieldError(this, <b>Priority must be 1-10</b>))
    ...
    }
<p>

O método validations é redefinido em cada propriedade mepada que necessida validação. O campo desc apenas obriga o tamanho mínimo para 3 com a mensagem especificada definido pela função utilitária valMinLen. Já o campo priority instancia diretamente um FieldError passando o campo contendo o erro junto com a mensagem em negrito.

Este projeto foi montado usando o NetBeans junto com o Maven conforme descrito no getting started do Lift. Fazendo um pequeno ajuste (descrito no próximo post), temos a execução da especificação integrada ao JUnit na IDE NetBeans.

Executando outra vez a especificação, teremos todos os testes ok como na figura a seguir. Um print do Netbeans.

Especificação atendida!

Esta foi talvez a parte mágica da coisa. Onde tudo já está funcionando e precisamos só curtir o BDD num exemplo sofrível com intuito de ilustrar esta metodologia, o framework Specs, o framework Lift e a linguagem Scala.

O código completo do projeto estará disponível no próximo Post desta série. As versões utilizadas no projeto são: Lift 1.0, Scala Specs 1.6.1, EasyMock 2.5.2 (instalada no repositório maven local). E no próximo Post teremos: Configurando seu projeto Maven para o uso de Scala Specs; Explorando mais matchers; Configurando Contexto Specs para execução da especificação em uma LiftSession acessando a base de dados; Especificando Snippets Lift, e mais. Será que cabe tudo em mais um Post? Vai ter que caber.

Se puder visite o site do BDD e conheça mais sobre esta metodologia no mínimo interessante. Dado que não sou especialista em nenhum metodologia ágil, se você tem ou teve alguma experiência prática com BDD, TDD ou DDD deixe seu comentário ou sua sugestão sobre como abordar o tema de maneira mais prática.

Veja a Parte II deste post.

Update (09/10/09): Conversando com Daniel Guggi (Desenvolvedor Grepo), ele me alertou sobre a possibilidade de uma configuração mais enxuta no applicationContext.xml do Spring. Eu mantive essa configuração no post por ser a utilizada no projeto em questão. Daniel também falou sobre a versão estável do framework que será lançada até o final da semana que segue.

Outra vez longe do blog! Passei o último mês até o pescoço em um projeto um pouco apertado. Algo que acontece só as vezes não é mesmo?

Despois de quase um ano focado apenas em SOA e todo seu “pequeno” universo, precisei fazer o setup e os primeiros códigos/camadas deste projeto. Logo, juntando o pouco tempo para entrega com minha ausência na construção de aplicações standalone no último ano, temos como resultado: Desespero! Mas um desespero divertido. ;p

A aplicação possui bastante CRUD, e na equipe começaram os rumores dos famosos AbstractDAO. Wow! Realmente não dá pra fazer o mesmo código sempre pra operações básicas. Mas construir seu próprio AbstractDAO tem lá seus riscos e desvantagens, a saber: não atingir um nível de abstração satisfatório que permita a construção realmente rápida de telas básicas, perda de tempo fazendo a abstração se não existir uma, discussões sobre quem não obedeceu a abstração corretamente, e coisas do gênero.

E é aí que entra o GREPO, um framework da Codehaus que se entitula como simples, flexível e consistênte. E é verdade. A simplicidade pode ser atribuída ao fato de nenhum implementação ser necessária para o seus DAOs. Isso sim é ganhar tempo!

O Grepo, ou Generic Repository permite iterações via JPA, Hibernate e ainda execução de procedures. Meu foco aqui é JPA. O Grepo trabalha em conjunto com o spring, então os exemplos aqui foram construídos numa aplicação com Spring. Chega de conversa e vamos ao primeiro DAO:

//Entidade
@Entity
public class Administrador {
  @Id
  @GeneratedValue(strategy = GenerationType.AUTO)
  private Integer id;

  @Basic
  private String email;

  @Temporal(TemporalType.TIMESTAMP)
  private Date cadastro;
  //get/set etc ...
}

//Código do DAO
public interface AdministradorDAO extends ReadWriteJpaRepository<Administrador, Integer> {}

Supondo uma entidade Administrador de Primary Key do tipo Integer, criamos a nossa interface AdministradorDAO que extende ReadWriteJpaRepository passando a entidade e o tipo da sua chave como parâmetro de tipos (generics).

ReadWriteJpaRepository, como o nome já diz, fornece operações de leitura e escrita em uma entidade, ao contrário de ReadOnlyJpaRepository. E é só! Imagine agora o código de uma classe Service:

@Autowired
private AdministradorDAO dao;

public Administrador findById(Integer id) {
  return dao.find(id);
}

public void removeAdministrador(Administrador admin) {
  dao.remove(dao.merge(admin));
}

Na verdade, a interface herdada fornece todos os métodos do EntityManager JPA: find, remove, refresh, merge, lock e persist. E isso sem sem escrever código algum para o DAO. Mas sim, há necessidade de escrevermos consultas que permitam retornar entidades que não seja pelo seu id.

Mantendo a abordagem de código zero, definimos um método na interface do dao assim:

public interface AdministradorDAO extends ReadWriteJpaRepository<Administrador, Integer> {
   @GenericQuery(query = "from Administrador where email = :email")
   public Administrador getByEmail(@Param("email") String email);
}

Quase dispensa explicações! adicionando este método, definimos via anotação a query que deve ser executada. O parâmetro nomeado JPA é mapeada para o argumento email passado ao método via anotação @Param(“email”). É possível usar named queries, passando em @GenericQuery o valor de queryName. O Grepo fornece algumas possibilidades para um bind de um método na interface para uma named query definida, por exemplo, na entidade.

Todo tipo de query jpa, incluindo o uso de QueryHints é possível. Operações de deleção, update, etc, tudo pode ser usado normalmente sem limitações.

Outra sitaução comum é a filtragem de entidades a partir de parâmetros preenchidos em um formulário de filtro html, o que exige uma query gerada dinamicamente a partir dos dados pesquisados. Numa tela de filtro de administradores onde a busca por e-mail e/ou data de cadastro usamos o AbstractJpaQueryGenerator para gerar a consulta:

public interface AdministradorDAO extends ReadWriteJpaRepository<Administrador, Integer> {
  @GenericQuery(query = "from Administrador where email = :email")
  public Administrador getByEmail(@Param("email") String email);

  @GenericQuery(queryGenerator=AdministradorFiltro.class)
  public List<Administrador> findByFilter(AdministradorFiltroBean filtro)

  public static class AdministradorFiltro extends  AbstractJpaQueryGenerator {
    @Override
    public String generate(QueryMethodParameterInfo info) {
      AdministradorFiltroBean bean = info.getParameter(0, AdministradorFiltroBean.class);
      StringBuilder query = new StringBuilder();
      query.append(" from Administrador where 1=1 ");
      if (bean.getEmail() != null){
        query.append(" and email = :email ");
        this.addDynamicNamedParam(new DynamicNamedJpaParam("email", bean.getEmail()));
      }

      if (filtro.getDe() != null) {
       query.append(" and cadastro >= :de");
       this.addDynamicNamedParam(new DynamicNamedJpaParam("de", bean.getDe()));
      }

      if (filtro.getAte() != null) {
       query.append(" and cadastro <= :ate");
       this.addDynamicNamedParam(new DynamicNamedJpaParam("ate", bean.getAte()));
      }

      return query.toString();
    }
  }
}

Preenchendo o Bean de pesquisa que guarda o e-mail e data de início e fim de cadastro a pesquisar, passamos como argumento para o método findByFilter de AdministradorDAO e automagicamente o Grepo invoca o AdministradorFiltro, que por sua vez implementa o método generate.

QueryMethodParameterInfo armazena os parâmetros passados para a inferface de pesquisa, no nosso caso o único parâmetro passado é o Bean de Filtro. Note tambémm as classes DybamicNamedJpaParam, que é responsável por fazer o mapeamento do valor do Bean e um parâmetro nomeado.

Pronto, temos um filtro conciso!

Outro ponto que vale a pena observar é que os nomes de métodos no DAO estão todos em inglês. Isto por que o Grepo usa convention over configuration para decidir pela invocação de getSingleResult() ou getResultList() por exemplo. As convenções seguidas são a partir do prefixo dos métodos e podem ser: is|has|find|get|load|delete|updat.

Mas o Grepo não força o uso destes prefixos, voce pode escolher um nome qualquer e construir seu próprio QueryExecutor, ganhando flexibilidade como prometido. Confesso que foi ótimo usar estas convenções e a equie absorveu muito rápido o uso delas.

Você deve estar se perguntando onde configurar isso, ta tudo muito bonito e muito simples até agora. E continuará simples. Mas afinal de onde vem o código para a interface do DAO? Qual a instância injetada classe service acima via @Autowired?

Com pequenas configurações no seu Spring applicationContext.xml, você define seu repositório abstrato de onde todos os seus repositórios (leia-se DAO) irão herdar, passando pra ele o EntityManagerFactory, configurações de transação (opcional) e outras configurações do Grepo:

<!-- Configuracao repositorios -->
<import resource="classpath:META-INF/spring/grepo-query-jpa-default.cfg.xml" />
<bean id="abstractRepositoryTarget" abstract="true">
  <property name="entityManagerFactory" ref="entityManagerFactory" />
  <property name="executorFindingStrategy" ref="grepo.queryExecutorFindingStrategy" />
  <property name="resultConversionService" ref="grepo.resultConversionService" />
  <property name="executorFactory" ref="grepo.defaultQueryExecutorFactory" />
</bean>

<!-- Todo repositorio sera um filho do repositorio abstrato -->
<bean id="abstractRepository" abstract="true">
  <property name="interceptorNames" value="grepo.genericQueryIntroductionInterceptor" />
</bean>

<!-- nossa interface -->
<bean id="administradorDAO" parent="abstractRepository">
  <property name="proxyInterfaces">
    <value>com.codemountain.dao.AdministradorDAO</value>
  </property>
  <property name="target">
    <bean parent="abstractRepositoryTarget">
      <constructor-arg value="com.codemountain.Administrador" />
    </bean>
  </property>
</bean>

A interface é registrada no Spring, e o Grepo fornece a implementação que por traz utiliza Spring JPA Template através de um proxy dessa interface. A EntityManager Factory utilizada foi previamente configurada.

Um DAO Grepo pode ser transacional se a propriedade transactionTemplate for configurada com um transactionManager para o  bean abstractRepositoryTarget.

A intenção do post é apresentar o básico deste framework que realmente conseguiu me chamar atenção. O projeto que citei no início do post está entrando em produção e os desenvolvedores envolvidos ficarm muito satisfeitos com o uso desta ferramenta.

De fato um DAO capaz de fornecer operações básicas é frequentemente necessário, o que não precisamos é gastar tempo construindo ou utilizando implementações não capazes de satisfazer as necessidades do projeto. Experimente, vale a pena. Até a próxima.

Olá a todos. Desde que fiz a primeira fase da Certificação SOA Architect da BEA em 2008, não escrevi nada sobre SOA aqui no blog.
Infelizmente não vou começar falando do Paradigma de design Service-Orientation [01], tão pouco como ela se Encaixa em Service-Oriented Computing [01] até chegar em SOA de fato. Dois termos, alias, completamente desconhecidos por quem imagina que trabalha com SOA.

Não vai dar pra postar nada introdutório neste artigo, tão pouco tratar SOA por completo. Mas vou falar de um dos enganos mais comuns quando se trata de SOA dentre  muitos  que já presenciei, a saber:

“Um Webservice é um seviço”, “Ter um ESB é ter SOA”, “Ter Webservices é fazer SOA”, “ESB deve ser o responsável por fazer Service Orchestration“, “Meu sistema X ‘chama’ o BUS que ‘chama’ o sistema Y”. Bom, dá pra fazer uma lista vasta aqui, mas paremos por aqui.

E o engano que trato neste post é: “Todo e qualquer serviço deve ser exposto no barramento de serviço ESB”. Mas por quê? Existem alguns outros blogs que já falaram sobre quando usar ou não um ESB adotando uma abordagem diferente desta aqui.

Primeiro vamos ao Papa Thomas Erl [01] para a definição de ESB:

“An enterprise service bus represents an environment designed to foster sophisticated interconectivity between services. It estabilishes an intermediate layer of processing that can help overcome problems associated with reliability, scalability, and communications disparity“.

É um bonto de partida. Podemos agregar outras e outras definições e ter uma definição mais completa ou à contento.

Um pouco da minha humilde vivência em SOA concorda com isso e diz que o ESB é puramente um mediador e deve ser visto como um componente da infra estrutura de serviços de uma corporação, não como o “ambiente soa” (outro engano).  Um Service BUS deve prover algumas características como capacidade de roteamento de mensagem, transformação de mensagem, tradução de protocolos, virtualizaçao de serviço, balanceamento de carga, message throttling, dentre outros.

Mas aí o engano que diz que um webservice é um serviço aparece por aqui. E essa é uma das maiores falácias que a humanidade já conheceu, tal como 2+2 = 5.

Um serviço dentro do contexto SOA, segundo a Wikipedia é: “… the term service refers to a set of related software functionality, together with the policies that should control their usage.” [02]

Logo, um serviço é acessível por sua interface [03] que expõe sua implementação*, que por sua vez obedece a um contrato bem definido para o serviço (funcionalidade). O contrato é o descritor, comumente não técnico, das capabilidades [01]  de um serviço. Estas capacidades por sua vez foram derivadas de alguma necessidade do negócio, ou seja, um Serviço existe pois uma necessidade (requerimento funcional) corporativa existe. Vamos parar por aqui, não vamos chegar ao ponto de onde uma necessidade corporativa (Business Requirement) é derivada. Por tanto temos (de forma resumida, e me perdõem meus amigos conhecedores da ESEF pela simplicidade aqui) os seguintes elementos que compõe um serviço:

Agora que chegamos a um ponto onde sabemos o que é um serviço e (mais ou menos) de onde ele brotou, voltemos aos Requisitos Funcionais Corporativos, ou seja, funções desenpenhadas pela corporação.

Uma funcionalidade corporativa pode não ser justificável como um Serviço compartilhado, que embora obedeça a definição de um serviço (Acima), o seu uso deve ocorrer apenas no escopo de uma aplicação. Quando isso acontece, diz-se que um serviço X é pertencente ao escopo de Aplicação pois é acessível somente por esta. Frequentemente os demais escopos são: Aplicação, Inter-departamental, Empresarial e público. Escopo está diretamente ligado a que tipo de consumidor o serviço atende.

STOP! Aqui temos uma boa razão  para não expor um serviço na infraestrutura SOA corporativa da empresa: O serviço tem um escopo tão reduzido (De aplicação) que se restringe a atender uma única aplicação. (escrevi o post basicamente pra mostrar isso, outras razões para não expor um serviço em um ESB vem de bom senso e prática, além de depender do cenário em questão).

Seguindo a idéia de classificar um serviço quanto ao seu uso, temos uma segunda forma de classificação, comumente chamada de categorização, onde um serviço pertence a uma categoria, ou camada, dada sua capabilidade. Ou seja, serviços capazes de acessar uma função de um sistema legado e expor tal para o ambiente SOA (dentro de algum escopo acima) como ela é, é comumenta categorizado (ou reside na camada de) serviço de conectividade.

Tal categoria pertence a um conjunto mairo de categorias, ou camadas, que facilitam a abstração e auxiliam nas decisões de design. Outra camadas, não menos importante são:

• Serviços de Dados – Requisitos Corporativos frequentemente tratam de entidades corporativas a exemplo de Cliente, Contrato, Endereço, etc. Serviços que provêem acesso unificado, bem como uma visão única entre os diversos formatos de diversas fontes em uma corporação, residem nesta camada.
• Serviços de Negócio – São comumente subdivididos em serviços que executam atividades corporativas atômicas (ex: validar cartão de crédito) e serviços de granularidade mais espessa, também chamados de processos de negócio (ex: Processar pedido em e-commerces)
• Serviços de Apresentação – São serviços que permitem a reutilização de uma interface com o usuário (ex: portlets e mash-ups.
• Serviços utilitários – São serviços que não estão associados a um contexto específico dentro do negócio (ex: Serviços de Notificação).

De fato, dada uma combinação Categoria x Escopo, tem-se uma série de boas práticas aplicáveis aqui. E considerando um serviço de acesso a dados que atende exclusivamente a uma aplicação, não há a necessidade de mediação pelo ESB, ou ainda, não há necessidade de que este serviço resida na infraestrutura da companhia.

Numa abordagem simplista, temos a distribuição de camadas/categorias de serviços como exemplifiquei ano passado aqui [04]. Pra ficar mais coerente com este post e a minha modesta evolução em SOA no último ano, considere a camada vertical vermelha como a camada de serviços utilitários. Ah! Vamos imaginar uma última camada abaixo da camada de serviços de dados, de acesso ou conectividade.

O bom senso ajuda muito, mas ter noção de onde um serviço nasce, é tão importante quanto isso. Decidir cegamente se um serviço, e sua interface física (WSDL em caso de uso de webservices) deve residir no barramento de serviços é um equívoco. Definir nomes, tipos, escopos, quantidade e relacionamento entre serviços sem uma justificativa é algo que leva ao erro e uma frustração no programa SOA do cliente. E quando isso acontece, todos nós que acreditamos em SOA, pagamos por isso. Agindo assim, fazemos SOA perder credibilidade e estar fadado ao fracasso.

Toda essa história de Requisito Funcional, Serviços e seu componentes, Escopo, Camada de serviços vêm de uma metodologia, de uma engenharia de serviço. SOA também precisa de uma metodologia, e governança. Por favor, nada de empirismo

ESB faz parte da infraestrutura SOA e deve ser tratado como tal. E considerando as novas tendências e o uso de Composite Applications baseadas em SCA, teremos uma ajuda para colocarmos o ESB em seu devido lugar. Ou então SCA vai terminar de confundir mais algumas pessoas que imaginam fazer SOA.

*existem outras definições para os componentes de um serviço e como eles se relacionam.

Referências:

[01] SOA Design Patterns by Thomas Erl

[02] SOA in Practice: The Art of Distributed System Design (Theory in Practice) by Nicolai M. Josuttis

[03] Service (systems architecture) from Wikipedia

[04] Rasea e SOA – Parte I by Paulo Suzart

update: link to code, now using sxr 0.2.1

Hi folks. Long time away! Confess I hadn’t had nice ideas to work on, but now I have a lot.

While implementing one of them (sort of Scala lib to use Actors as RabbitMQ Queue consumers over the Java API), I figured that my lib user shouldn’t explicitly instantiate or even interact with some original RabbitMQ Java API classes. This small piece of my construct is sufficient to show nice Scala features and functional programming style (the following is not the unique solution or the best way to do that, but funny and teaching).

To consume a Queue, we  first connect to the broker and get a Connection and a Channel. Using this ConnectionFactory constructor is useful to get a Connection. However, it takes a set of parameters wrapped in ConnectionParameters class.

So I decided follow these rules:

1. lib users must not instantiate ConnectionParameters directly

2. configuration must appear in the order: user, password, virtual host

3. configuration must take one line and be transparent to lib client

4. Ah! Users shouldn’t use common Scala Lists

How to make it happens in Scala? My answer was put some interesting features together such as Pattern Match, Options, Case Classes and Implicit Conversions.

Using a SBT aproach to declare project dependencies, We have the format:

val connParams = "guest" % "guest" % "/" //say a abstract val named connParams

An implicit function will help to convert a String to an object that takes a String value and the previous declared parameter as arguments. So we get  Param(“/, Param(“guest”, Param(“guest”, None))). Every time the user call the function % on a String, this implicit converter will instantiate a new Param.

The convertion function can be done as:

 implicit def s2Param(s : String) = Param(s, None)

Here a new element takes place, the Param class hasn’t a new keyword. That is a Case Class, a especial Class that help us with PatternMatch and  doesn’t need such a keyword.  And more, the parameters of a case class are “mapped to” attributes accessible by its own names:

case class Param(value : String, precending : Option[Param])

So, say a variable named x referencing Param, x allows x.value and x.precending without any extra declarations.

s2Param implicitly converts a String to a Param Instance to bring the function %. Let see the function %:

case class Param(value : String, preceding : Option[Param]) {

def % (value : String) = Param(value, Some(this))

}

For our surprise, we have one more element here, the Some -  in conjunction with None (see s2Param) – extends Option[+A]. Option is used to represent optional values, and here is a nice place to apply it. For example, the preceding Param of a Param is not required for the first in the chain.

None means no value, and Some means some value of the type of +A. Option has many other features not covered here.

Now, with the class designed, we can add another function (used strictly by the lib) to transform the parameter chain into the Rabbit ConnectionParameters:

def asConnectionParams = { 

 val (user, pass, vHost)  = this match {
   case Param(user, None) =>  (user, ConnectionParameters.DEFAULT_PASS, ConnectionParameters.DEFAULT_VHOST)
   case Param(pass, Some(Param(user, None))) => (user, pass, ConnectionParameters.DEFAULT_VHOST)
   case Param(vHost, Some(Param(pass, Some(Param(user, None))))) => (user, pass, vHost)
   case _=> error("ConnectionParameters configuration Failed")
 }

 //Returning ConnectionParametters
 new ConnectionParameters {
   setUsername(user)
   setPassword(pass)
   setVirtualHost(vHost)
 }

 }

asConnectionParams uses Pattern Match to declare the val user, pass and vHost matching the current instance of Param (supposed to be the las declared by the user) against some expected patterns. This Pattern Match carres about the default values to configure the ConnectionParametters instance returned. Any other Param combination not allowed will fall into case _, and a error is raised.

Now the Param class complete:

   case class Param(value : String, preceding : Option[Param]) {

      require(value != null)  

      def % (value : String) = Param(value, Some(this))

      def asConnectionParams = { 

        val (user, pass, vHost)  = this match {
           case Param(user, None) =>  (user, ConnectionParameters.DEFAULT_PASS, ConnectionParameters.DEFAULT_VHOST)
           case Param(pass, Some(Param(user, None))) => (user, pass, ConnectionParameters.DEFAULT_VHOST)
           case Param(vHost, Some(Param(pass, Some(Param(user, None))))) => (user, pass, vHost)
           case _=> error("ConnectionParameters configuration Failed")
          }

        //Returnin ConnectionParametters
        new ConnectionParameters {
        	setUsername(user)
        	setPassword(pass)
        	setVirtualHost(vHost)
        }

      }
    }

Usage:

val params = "guest" % "guest" % "/"

Thus, the super class can execute params asConnectionParams to grab the params required to get a Connection and a RabbitMQ channel.

To make things simple to test by yourself, you can find the code that runs stand alone here (with Scala X-Ray). Next time I promess a Scalatest or something like.

Thats it! Impressive? No! Useful? Maybe. Funny? For sure!!!

Stay up and see more POSTs about real RabbitMQ and Scala soon. It was an appetizer to play around with Scala.

Thanks for coming!

Depois do talk não acontecer (veja posts anteriores), resolvi disponibilizar no Slideshare toda a apresentação que seria utilizada no evento, e que provavelmente usarei numa próxima oportunidade:

Por enquanto é isso. Ainda devo continuar em estudos profundo so bre SOA Security por mais tempo, uma demanda do trabalho. Mas falou em estudar, é comigo mesmo!!!

Espero voltar em breve falando de Scala já na versão 2.8, agora com Continuations e Named Arguments, o que vai deixar essa linguagem simplesmente imbatível de uma vez por todas. Até a próxima!

Update: Se você não consegue ver os slides no seu leitor de feeds, clique aqui.

É pessoal, o talk não aconteceu por alguns motivos particulares na empresa. Mas ainda temos a esperança de conseguir agendar uma data para o evento.

No final, a possibilidade do talk me rendeu material para apresentação sobre a linguagem (Scala) numa próxima oportunidade

Tenho estado sumido ultimamente pois algumas atividades no trabalho exigiram um estudo mais focado sobre o tema (SSO, SAML, WSS). Por isso pisei um pouco no freio na minha vertente de estudo de novas tendências. 

Ainda assim consegui ler bastante sobre RabbitMQ (implementação do Advanced Message Queue Protocol – AMQP), e fiquei realmente interessado.  A propósito o RabbitMQ foi o broker utilizado no Twitter por um tempo, e por conta de uma necessidade particuliar, eles acabaram desistindo do uso. Mas o RabbitMQ não vai ficar atrás, e nas próximas versões disponibilizará a feature. Veja a discussão entre Alex Payne (Twitter) e Alexis (RabbitMQ) aqui, e veja aqui o que o Robey (Twitter) fez pra atender as necessidades deles.

Detalhe: o Lift sempre deu suporte ao Rabbit e eu não sabia o.O!

Dediquei um pouco (pouco mesmo) de tempo a uma outra linguagem funcional chamada Clojure. A brincadeira começou justamente enquanto preparava os slides para o talk (#fail) e tive que ler bastante sobre Lambda Calculus (de onde vem a FP). O gostoso do Clojure é a encarnação do Lambda Calculus como ele é, numa syntax Lisp. Aqui você pode brincar um pouco com a linguagem; um “console” on line. Ah! E dá pra brincar com outras linguagens também como Scala e até OCaml  

Bom, no final vi um pouco sobre Compojure, um framework web pra Clojure muito irado.

Por enquanto é só. Estou pensando em abordar mais tópicos sobre Scala, pois ainda há muito o que falar sobre os recursos e características da linguagem com Actors, Extractors, Pattern Matching, Lists e mais. Aguardem!

Em breve, eu e alguns colegas de trabalho faremos um talk na empresa.
O objetivo é apresentar ao restante da companhia, as algumas inovações tecnológicas que cada um vem estudando nos últimos meses.
Dentre elas, Groovy/Grails, CEP, SOA, Terracotta e um talk sobre Scala apresentado por mim.
Para o exemplo usado, Scala X-Ray vai ajudar a ilustrar o uso da linguagem: http://is.gd/tmFg

Acompanhe!

obs: logo não oficial.