Arquitetura 2010 

Mar/10
16

Muito do que voc√™ encontra na internet sobre design e arquitetura de aplica√ß√Ķes em java o remete ao JEE e ao famigerado EJB. J√° foi o tempo em que EJB era condi√ß√£o sin qua non para criarmos aplica√ß√Ķes¬†corporativas e especialmente sites.

Hoje com o advento do Seam parece que EJB vai ser novamente necessário para fazer sites. Veja que Seam utiliza os EJB como back-beans do JSF o que significa que não funcionará fora de um Application Server. A maioria dos sites não precisa das capacidades contidas em  um Application Server, bastando um Web Container. A própria especificação JEE 6 vai oficializar este divisão entre o que é web site e o que é realmente uma aplicação corporativa.

Ao falar de aplica√ß√£o corporativa todos imediatamente pensam em bancos de dados, ou melhor, em SGBD (Sistema Gerenciador de Banco de Dados) e imediatamente pensam em DAO e depois em Hibernate e JPA. ¬†O problema aqui √© que DAO √© obsoleto, JPA √© infantil e Hibernate n√£o tem concorr√™ncia. Se voc√™ est√° pensando em criar um software e em usar DAO, esque√ßa. Isso √© coisa do passado. Hibernate e JPA s√£o encarna√ß√Ķes no novo padr√£o que matou ¬†o DAO, o DomainStore. Ent√£o √© neste padr√£o que voc√™ deve se concentrar hoje, e n√£o no DAO.¬†Para web site, voc√™ precisa no m√°ximo de um Hibernate.

Por que não JPA? Porque o JPA tem o mesmo problema do EJB 2.x. A especificação é simplista e falha. Ela viola explicitamente o propósito de mapeamento agnóstico o que significa que usando JPA você não poderá usar qualquer banco de dados. Aliás, se você usa algum tipo de SELECT esqueça JPA.  Não que o hibernate o vai liberar de criar código especial para este ou aquele banco, mas vai minimizar muito essa necessidade e adiá-la o máximo possível.  Mas o grande problema com o JPA é a criação de pesquisas. As pesquisas do JPA não são OO e não são agnósticas. As do Hibernate são OO se usar Criteria e agnósticas, quer usando Criteria ou HQL.

As pesquisas são o elemento esquecido do CRUD. O objetivo de ter um mecanismo de CRUD é poder pesquisar os dados depois. Poderíamos até argumentar que todo o objetivo de ter um banco de dados é permitir as pesquisas. E onde escrevemos estas pesquisas?

Obviamente teremos que as escrever em algum objetos cuja responsabilidade principal seja montar critérios do Hibernate. Estes objetos são os repositórios. Os repositórios concentram todas as responsabilidades CRUDL (CRUD + Listagem) e normalmente precisamos de vários deles.

√Č muito comum a ideia¬†de que ao termos um mecanismo com o ¬†Hibernate¬†poder√≠amos¬†criar um DAO para encapsular as chamadas a ele, mas isso √© um erro t√°tico e¬†t√©cnico¬†muito importante. Primeiro que apenas queremos na realidade facilitar o uso de classes como a Session e talvez adicionar um pouco mais de tipagem forte. Isso n√£o √© um DAO, √© no m√°ximo um Adapter. Nada contra construir um Adapter¬†deste tipo, mas existe um ponto mais importante aqui. Se o¬†reposit√≥rio¬†√© respons√°vel por montar objetos de Criteria, ele j√° est√° acoplado ao Hibernate; logo criar mais um objeto no meio √© f√ļtil. Por outro lado, se quisermos desacoplar ¬†o Hibernate dos reposit√≥rios (veja, o Hibernate √© apenas um, os reposit√≥rios s√£o v√°rios) precisamos, na realidade, de uma estrat√©gia para criar os Criteria sem usar as classes do hibernate e depois delegar a algum outro objeto que as traduza para essa tecnologia. A forma mais realista de fazer isto √© criar um mecanismo agn√≥stico de Query Object e Interpreter. ¬†Funciona assim: o reposit√≥rio √© agn√≥stico (ou seja, n√£o depende da tecnologia de persist√™ncia) e depende de um objeto PersistanceStrategy (o nome pode variar). Este objeto √©, na verdade, uma interface, um servi√ßo, cujo contrato tamb√©m √© agn√≥stico. ¬†PersistanceStrategy aceita entidades para opera√ß√Ķes como save e delete, e aceita objetos Query Object para pesquisas. Objetos Query Object s√£o como os Criteria do hibernate mas sem a depend√™ncia com o Hibernate.

Depois criamos uma implementa√ß√£o HibernatePersistanceStrategy. Este objeto delega as opera√ß√Ķes ao Hibernate e sabe como traduzir Query Object agn√≥stico para Criteria do Hibernate.

Dessa forma, se um dia voc√™ quiser remover o Hibernate, voc√™ pode. E esse dia n√£o √© l√° no futuro n√£o. √Č amanh√£, quando voc√™ come√ßar a escrever os seus testes unit√°rios e de integra√ß√£o.

Recapitulando: Repositório conversa com PersistanceStrategy através de Query Object. Repositório é responsável pelo CRUDL da Entidade.

Do outro lado, queremos manipular as entidades para conseguir criar valor. Controlar uma venda, uma compra,  uma transação de qualquer tipo. Para isso precisamos encapsular as regras para essa transação. Precisamos, principalmente, de objetos capazes de validar os dados de entrada e de objetos capazes de realizar o processo. Os primeiros são validadores e os segundos,  serviços.

Servi√ßos seguem ¬†o padr√£o interface + v√°rias implementa√ß√Ķes e temos dois grandes grupos. Servi√ßos de aplica√ß√£o (como¬†enviador¬†de email) e servi√ßos de¬†dom√≠nio¬†(como o que realiza a transa√ß√£o de compra). O pr√≥prio PersistanceStrategy de antes √© um servi√ßo de aplica√ß√£o.

Validadores s√£o usados dentro dos servi√ßos para validar os dados de entrada. Neles mantemos todas as regras que permitem realizar a opera√ß√£o. Validadores podem ser usado fora dos servi√ßos para acelerar as coisas e nem sequer chamar os servi√ßos caso haja problema, mas devem sempre ser chamados dentro dos servi√ßos¬†independentemente¬†de serem chamados antes. √Č como a valida√ß√£o javascript que n√£o substitui a valida√ß√£o no servidor. Entenda-se: estes validadores n√£o apenas validam os dados de input do usu√°rio, mas aplicam regras de neg√≥cio a esses dados.

Recapitulando:  Serviços de Aplicação e Serviços de Domínio.  Serviços utilizam Validadores para evitar corrupção.

Finalmente, um pouco sobre actions. “Action” √© qualquer classe onde voc√™ controla o fluxo de uma aplica√ß√£o web. O nome ficou famoso devido ao Struts e muita gente ainda chama estas classes de controladores (quando na realidade s√£o apenas Strategy) erradamente. Todos os frameworks web, de uma forma, ou de outra, acabam delegando a uma classe ou conjunto de classes a decis√£o de processamento de um certo request. Essa classe √© a action.

A action só pode conversar com Serviços de Domínio e executar pesquisas em Repositórios. Não podem invocar mecanismos save/delete nos repositórios. Para não cair nesta tentação é mais seguro você criar um serviço de dominio  que medie a comunicação action-repositorio, garantindo que apenas métodos de pesquisa são invocados. A responsabilidade das actions é converter os dados da UI em dados que os serviços entendem. Isso normalmente significa Entidades, mas não apenas. Vários Value Objects como BigDecimal e Date pode necessitar de conversão também. Eventualmente a Action pode invocar validadores antes de invocar os Serviços. Isto especialmente para ser capaz de informar o usuário e proteger o sistema de dados corrompidos ou que não satisfazem as regras de negócio.

Enfim, as requisi√ß√Ķes do usu√°rio s√£o mastigadas nas actions onde se transformam em objetos do que os servi√ßos aceitam. Os servi√ßos s√£o invocados. Os servi√ßos chamam outros servi√ßos e/ou t√™m l√≥gicas internas que produzem altera√ß√Ķes em objetos existentes ou criam novos objetos. Os servi√ßos utilizam os reposit√≥rios para realizarem pesquisas e persistir as altera√ß√Ķes. ¬†Os reposit√≥rios delegam a√ß√Ķes de¬†persist√™ncia¬†e pesquisa a implementa√ß√Ķes de PersistanceStrategy que as traduzem para a√ß√Ķes reais sobre o banco de dados ou sobre um DomainStore como o Hibernate.

N√£o h√° por¬†que¬†complicar a arquitetura e design das sua aplica√ß√Ķes web. Estes poucos elementos s√£o normalmente ¬†suficientes para realizar sistemas em que h√° muito mais leitura do¬† que escrita. ¬†Mas, mesmo que voc√™ esteja desenvolvendo aplica√ß√Ķes web-RIA (ou seja, simulando aplica√ß√Ķes desktop¬†de cadastro em web) esta arquitetura ainda √© suficiente.

N√£o continue se iludindo¬†com o uso de EJB ou desenhando aplica√ß√Ķes como se fazia nos anos 90. J√° se passaram 20 anos.¬†Estamos em 2010.

15 comentários para “Arquitetura 2010”

  1. Cara, na boa, na boa mesmo, revise seu texto. Há uma série de erros e comentários no mínimo duvidosos aqui.Quero deixar claro que não estou aqui para desmerecer seu trabalho, aparecer nem pra te ofender, apenas percebi algumas incoerências que julgo importantes para passarem despercebidas. Não precisa nem publicar esse comentário.
    Vou citar alguns erros, mas espero que você releia e reflita.

    1 – “Hoje com o advento do Seams parece que EJB vai ser novamente necess√°rio para fazer sites.”

    J√° come√ßou errando o nome. √Č Seam, JBoss Seam. E o Seam n√£o te obriga a usar EJB nem JSF. E por falar nisso, a implementa√ß√£o padr√£o do CDI n√£o √© o Seam, mas um framework chamado Weld.

    2 – “Veja que Seams utiliza os EJB como back-beans do JSF o que significa que n√£o funcionar√° fora de um Application Server.”

    Como j√° foi dito antes, o Seam n√£o te obriga a usar EJB. Trabalhei mais de um ano com o JBoss Seam sem escrever um √ļnico EJB. E inclusive voc√™ pode rodar o Seam no Tomcat ou outro web-container, o que refor√ßa essa afirma√ß√£o.

    3 – “A pr√≥pria especifica√ß√£o JEE 6 vai oficializar este divis√£o entre o que √© web site e o que √© realmente uma aplica√ß√£o corporativa.”
    O que a especifica√ß√£o fez foi criar profiles(perfis) de acordo com a frequ√™ncia de uso dos servi√ßos do servidores de aplica√ß√£o. A grande maioria dos desenvolvedores n√£o utiliza Message Driven Beans ou integra√ß√£o com CORBA, o que n√£o significa que a aplica√ß√£o n√£o seja corporativa. Na verdade, at√© mesmo o profile web vai permitir o uso de EJB numa vers√£o light, ent√£o se voc√™ chamou de “aplica√ß√£o corporativa” sistemas que usem EJB pode notar claramente o erro de conceito.

    Perceba que citei alguns erros importantes de apenas um par√°grafo. Vou ficar por aqui, qualquer coisa me manda um e-mail.

  2. Legal o seu artigo Sérgio.
    Você teria um projetinho de exemplo com esta idéia de arquitetura ?

  3. Certo. o nome é Seam. Minhas desculpas.
    quanto ao resto vou citar o próprio site do JBoss Seam
    “Seam integrates technologies such as Asynchronous JavaScript and XML (AJAX), JavaServer Faces (JSF), Java Persistence (JPA), Enterprise Java Beans (EJB 3.0) and Business Process Management (BPM) into a unified full-stack solution, complete with sophisticated tooling.”

    “Seam is based on the Java EE platform. That’s why reinvestment in Java EE standards is crucial to Seam’s future”.

    O ponto n√£o √© que √© poss√≠vel ou n√£o deixar de usar EJB, o ponto √© que existe uma “for√ßa” que pende para ai. Por isso que eu disse ‘parece” e n√£o “√©”. Tudo bem que forcei quando disse que n√£o funciona fora do AS. Faltou explicar o que eu estava realmente pensando. A frase deveria ser “A JBoss n√£o ganha nada se vc rodar o Seam fora do AS”

    No resto concordo. √Č uma quest√£o de como dizer as coisas. Eu n√£o considero sites aplica√ß√Ķes corporativas e o web profile √© exatamente essa separa√ß√£o.

  4. Bom, o http://www.javabuilding.com é escrito nessa arquitetura. Agora, se vc está pedindo por código, o que eu posso dizer é que arquitetura não se entende no código. Se você entendeu os componentes e o que cada um deve fazer, vc cria seu próprio código.

  5. Pelos vistos v√°rias pessoas querem ver um exemplo pr√°tico. Ent√£o, gente, mandem sugest√Ķes de programas simples onde demonstrar isso e posso fazer uma segunda parte do artigo. O problema √© que √© muito c√≥digo para escrever num blog….

  6. Sergio,

    Excelente texto e brilhante colocação, aos comentários leigos não percebi sequer algo que me convencesse.

    Um grande abraço !!!

  7. Ol√° Sergio,
    Como ja comentaram aqui, o Seam roda em simples servlets containers e totalmente independente de EJBs. E n√£o √© que a utiliza√ß√£o do Seam em projetos “pede” ou “tende” a usar EJBs como vc comentou e sim o contr√°rio, se vc pretende usar EJB 3.0, √© bastante recomend√°vel usar o Seam – existe uma larga diferen√ßa aqui. Inclusive no JavaEE 6, o CDI (engine do Seam 3, implementado com Weld), tbm roda em ambiente Desktop JavaSE, conforme demonstrei ao vivo no TDC-2009. Tenho v√°rios projetos Seam sem o uso de EJB, e se voc√™ ler o livro Seam In Action ver√° que Dan Allen tbm n√£o gosta muito do uso de EJB em seus projetos.

    Outro ponto √© que existe um grande equ√≠voco na afirma√ß√£o: “Ela (JPA) viola explicitamente o prop√≥sito de mapeamento agn√≥stico o que significa que usando JPA voc√™ n√£o poder√° usar qualquer banco de dados. (..) As pesquisas do JPA n√£o s√£o OO e n√£o s√£o agn√≥sticas. As do Hibernate s√£o OO se usar Criteria e agn√≥sticas quer usando Criteria ou HQL.”

    O JPA e sua JPQL oferece a mesma abstração e agnoticismo que o HQL, na verdade as diferenças são mínimas. Inclusive a versão 2 do JPA tbm suporta Criteria.

    No mais parabéns pelo novo site, tenho certeza que fara sucesso.

    []s
    A. Lazarotti

  8. O fato do JPA só suportar criteria na versão 2 suporta exatamente o que eu quero dizer. JPA não é completo o suficiente e não é OO o suficiente. Ficar remendando uma má idéia não a torna uma boa idéia.
    Eu acho, sempre achei, um absurdo que o JPA tenha sido lan√ßado sem criteria. O JPA sobre do mesmo problema que o EJB sofre. √Č inst√°vel por design.

    Mas vejam, não sei porque essa defesa tão ferrenha do JPA. Se querem usar JPA , façam-no. Na realidade é irrelevante qual mecanismo de persistência usam desde que não usem DAO.
    Na realidade eu n√£o uso nenhum dos dois, JPA ou Hibernate, se puder escolher.

    O ponto é que para usar persistencia, o uso do DAO é obsoleto e um uso de Repositorios e estratégias de persistência mediados pelo uso de Query Object agnóstico.

  9. Sergio, note que não foi uma defesa, mas apenas uma correção. A maioria dos meus projeto utilizam hibernate e apenas bootstraps do JPA e DI de EntityManager.

    E ainda bem que existem estes remendos, o mundo seria pior apenas com softwares 1.0.

    De qualquer forma, o design do JPA é igual o design da maioria dos ORMs, principalmente em sua nova versão. Com a diferença da propagação e integração dos seus serviços a todos os demais container JEE.

    Abraços

  10. Da pra ver que √© uma boa arquitetura mesmo: a home page esta exibindo zilhares de ??messages:architecture?? no chrome. Bom fazer antes de falar…

    E esses erros sobre o Seam, falando que ele precisa de EJB, e que a JPA n√£o tem Criteria… pesquise um pouco antes. N√£o era preciso ler muito para descobrir esses graves erros.

  11. Caro robson,

    Primeiro, obrigado por ter referido o problema das mensagens eu não está consciente desse problema. Vou corrigir assim que possível.

    Segundo. Julgar a arquitetura pela apresentação é simplesmente um fraco argumento. Aliás nem sequer é argumento, é uma piada de mau gosto. Você sabe quanto demorei para colocar a feature de search no site ? 3 horas. E isso porque tive que aprender a usar o Compass nesse tempo. Vc sabe que esse site não usa banco de dados ? Vc sabe que quando usar, não preciso mexer em nada do mecanismo de pesquisa ? Para mim isto que é arquitetura.

    Terceiro, JPA atualmente ainda n√£o est√° na vers√£o 2.0. Apenas a vers√£o 2.0 ter√°, quando sair, no futuro, uma Criteria API. O JPA hoje, agora, n√£o tem api de criteria. Dizer que o JPA tem criteria √© simplesmente anacr√īnico.

    Sim, o design do JPA √© igual aos dos ORM, por isso mesmo ele deveria ser o JORM n√£o o JPA. Eu n√£o disse que o design dele √© ruim, eu disse que ele n√£o serve um prop√≥sito maior e por isso ele √© inutil face √†s alternativas. A unica coisa que ele tem a oferecer √© neutralidade mas todo o mundo que mexeu com JPA j√° teve que fazer alguma coisa “por fora” , portanto, essa neutralidade tem um pre√ßo e n√£o √© possivel criar sistemas reais apenas com JPA. Da mesma forma que n√£o era possivel apenas com EJB 2.x. Quem passou por esse tempo sabe muito bem que CPM era uma porcaria e BPM dava tanto trabalho que t√≠nhamos que usar DAO. Hoje DAO n√£o √© mais necess√°rio, mas o trabalho de isolar a aplica√ß√£o do banco de dados ainda n√£o terminou.

    Persist√™ncia √© mais lato que apenas banco de dados. S√≥ posso supor que vc n√£o tem problema algum em simular um banco de dados em memoria quando usa JPA e que todos os seus testes executam rapidinho… Gostaria de ser no seu blog como vc consegue isso.
    O JPA funciona fora do aplication server, portanto é bom não confundir os recursos do AS com os do JPA. Por exemplo, injetar o Entity Manager não é uma feature do JPA.

  12. Parece que as pessoas n√£o entendem o que “parece” significa. eu disse :

    Hoje com o advento do Seam parece que EJB vai ser novamente necess√°rio para fazer sites.

    E todo o mundo leu “O Seam precisa de EJB”. N√£o entendo essas conclus√Ķes. A l√≥gica √© simples. Se vc usa Seam com EJB vc precisa de um EJB container, e isso significa que precisa de um AS. Ainda n√£o estamos usando embeded EJB porque isso ainda n√£o saiu. Se vc n√£o usa EJB com Seam, porque usaria EJB ? qual vantagem EJB tem que n√£o pode ser alcan√ßada de outra forma ? Ou seja, hoje em dia EJB serve para qu√™ ?

    A √ļnica vantagem nestas condi√ß√Ķes √© neutralidade. Session e Message beans sempre foram neutros, mas esses vc simula muito facilmente. A real neutralidade est√° nos entity beans que agora n√£o existem mais. Ent√£o o EJB 3 √© apenas Session e Message beans, ou seja , a parte facilmente replic√°vel de outras formas. E o problema real ficou na m√£o do JPA que continua sendo “neutral demais”.

    O Seam √© um exemplo de algo que revive o EJB e isso √© necess√°rio para reviver o uso do JBoss como um todo e n√£o apenas o Tomcat. Mas para fazer sites, n√£o precisamos do JBoss…

  13. “Terceiro, JPA atualmente ainda n√£o est√° na vers√£o 2.0. ”

    http://www.jcp.org/en/jsr/detail?id=317
    “Final Release 10 Dec, 2009”

    Por favor, um minimo de pesquisa… J√° tem mais de 4 meses. Um cara escreve um jornal de arquitetura e n√£o sabe nem sobre o release da JPA2? EclipseLink e Hibernate (3.5cr1) j√° s√£o compat√≠veis.

    E sobre sua frase do Seam, na primeira frase voce diz “parece”, na segunda voc√™ √© bem claro, e afirma categoricamente: ” Veja que Seam utiliza os EJB”. N√£o, n√£o utiliza.

  14. Primeiro, alguma confus√£o ai, eu n√£o escrevo um jornal, muito menos de arquitetura. √Č apenas um blog. Um blog sobre desenvolvimento. Arquitetura √© um dos itens.
    Sim, embora soubesse que o hibernate e o eclipse estavam se mantendo compativeis e o eclipse link fosse a RI n√£o sabia que j√° tinha saido. Obrigado por me esclarecer.
    Como j√° disse antes, se dependesse de mim JPA n√£o seria usado nunca.

    Mas nada disso muda o argumento do post. O ponto √© que o JPA n√£o pode ser “mokado” para testes ou usado para persistir em outra “media” que n√£o SGBD
    e que o EJB atual é dispensável para web. Esse é a questão. Se vc vai fazer um site, EJB é totalmente dispensável. A referencia ao Seam era apenas para mostar que para o olhar mais superficial
    pode parecer que o EJB ainda tem algum papel no jogo. N√£o tem.

    Quando a Seam usar EJB, n√£o vamos ficar aqui brincando com as palavras :

    ‚ÄúSeam integrates technologies such as Asynchronous JavaScript and XML (AJAX), JavaServer Faces (JSF), Java Persistence (JPA), Enterprise Java Beans (EJB 3.0) (…)”

    O EJB 3 vai rodar do mesmo jeito que o 2.x. O problema ainda se mantém só mudou de nome. Entity Beans agora são JPA.
    O modelo de persistencia do java vai mudar numa versão 4 da vida. Mas no mundo real JPA não é e nunca foi um beneficio. E com o movimento NoSQL e os bancos não-relacionais no virar da esquina ele está cada vez mais inutil. Algo que nos pode valer são coisas como o Projeto Siena ou o MiddleHeaven que ainda são projetos em gestação.

    Sem uma API à altura de resolver o problema da persistencia ( e não apenas do mapeamento objeto-relacional ) JEE com EJB e JPA continua obsoleto.
    N√£o tou proibindo ninguem de usar ( nem poderia), estou apenas mostrando uma alternativa. Usa quem quiser.

  15. […] Em 2010 insisti no conceito do Reposit√≥rio como pe√ßa fundamental do andar de dom√≠nio.Era a mudan√ßa de paradigma mais relevante na √©poca. Este tempo todo depois e parece n√£o ter vingado. As pessoas ainda pensam em termos de DAO. Mas isto me p√īs a pensar o que mais falta nos designs de hoje em dia. Al√©m do isolamento da UI que falei outro dia, que √© um assunto mais complexo, um ponto importante √© a prote√ß√£o do dom√≠nio. […]

Comente

Enquete

Sobre quais assuntos gosta de ler neste blog ?

View Results

Loading ... Loading ...

Artigos