13 melhoras ao EJB

:?: :?: :?:

Acho que o Régis se refere a esta notícia.

AAAAAAaaaaahnnnn!

Agora que temos um link, fica tudo mais facil

Bom, vou comentar os pontos, agrupando os mais similares:

Gente, sao nada menos do que 5 itens na mesma lista implorando por um modelo de desenvolvimento melhor para o modelo de entidades*, nao da pra negar isso por mais muito tempo, a menos que o pessoal do expert group queira mesmo assassinar a J2EE.

Eu nao sou nenhum expert no assunto, e com certeza eu tou passando por cima de um daqueles detalhes que emperra toda a coisa, mas pq nao um modelo de desenvolvimento mais parecido com JavaBeans? Getters e setters, serializable, construtor vazio, eventos, e agora que temos JSR 175 (atributos xdoclet-ish), atributos demarcando transacoes, metodos remotos, seguranca e permissoes, etc e tal. O trabalho do application server seria mais o de olhar pra tua classe via reflection pra saber que tipo de proxies (ou aspectos, pra quem ta se aventurando com AOP) ele tem que aplicar.

Falando em AOP… po, se a gente ja tem ServletFilters, pq nao tem SessionBeanFilters ainda? Com certeza seriam muito uteis e, erhm, eu acabei sugerindo essa na thread la da TheServerSide, mas duvido muito que a ideia seja sequer minha, e que ela seja nova…

Acabei falando isso no 1o comentario, mas nao custa frisar: XML nao eh lugar de se colocar informação de deployment do tipo “este EJB depende daquele outro EJB”. Configuracao, ate que tudo bem, fica feio deixar no codigo, mas po, tb nao precisa tirar TUDO do codigo e causar o inferno que eh editar deployment descriptors hoje. Eu diria que o XDoclet quase acertou a mao aqui, mas ainda tem um pouco mais de checagens que poderiam ser feitas em tempo de compilacao, ao inves de esperar a hora de rodar.

Sem comentarios sobre essa. Quem ja precisou sabe do rolo que deu fazer uma gambiarra pra suportar isso

Isso é absolutamente lindo. Se eu puder dizer “olha, appserver, vc tem que me passar uma Connection pra base de dados tal usando o metodo setConnectionParaABaseTal()”, a JNDI vai embora pra sempre, e que nao seja por falta de tchau. E ela pode levar as Factories e ServiceLocators junto tambem. Bleargh. Coisa de programador em C esses patterns.

Quem ja teve que colocar alguma coisa em uma “variavel global” (<- aspas gigaaaaantes aqui) pros EJBs e acabou fazendo um entity bean so pra isso (:shock:) sabe o porre que é…

Putz, merece um tiro quem sugeriu essa. Se o contexto da aplicacao ja for mutavel, e global (ou seja, vale pra todo o cluster), pra que diabos eu vou precisar de um singleton, diacho?!

Quem ai mexe com JBoss e nunca teve que lutar na lama com o UCL (o classloader dele)?

[size=“9”]* qual a melhor traducao de domain model? modelo de dominio soa mto estranho…[/size]

O meu modelo de CMP seria:

// em um Session Bean, por exemplo...
TransactionFactory txf = context.lookup("java:foo/bar/txfactory");// JNDI lookup que poderia sumir do mapa tbm
Pessoa p = new Pessoa();
p.setNome("Daniel");
p.setEmail("[email removido]");
Transaction tx = txf.getTransaction();
try{
tx.save(p);
}catch(TransactionException){
//...
}
tx.close();

Pessoa é um simples JavaBean, com seus getters e setters. Aliás, muito parecido com o que se tem hoje com o Hibernate. Exceto pela ausência daqueles malditos arquivos .hbm.xml, que tornam as coisas muito chatas, e que podem sumir usando a bem lembrada JSR-175 que o Carlos citou .

Vou dar um tapinha no modelo perfeito de CMP do Daniel:

@SessionBean(STATELESS) public class MeuSessionBean {

  @Remote @Transaction(REQUIRED) public void adicionarPessoa(String nome, String email, Transaction t) throws PessoaRuimException {

    t.begin();

    Pessoa p = new Pessoa();
    p.setNome(nome);
    p.setEmail(email);

    try {
      t.save(p);
      t.commit();
    } catch(TransactionException e) {
      t.rollback();
      throw new PessoaRuimException(e);
    }
  }
}

Note que o SessionBean nao implementa nem estende nada, ele eh uma classe Java como qualquer outra, livre de dependencias no container. Um JUnit pra esse cara eh tao idiota que vale ate a pena fazer um:

public void testAdicionarPessoa() {
  MeuSessionBean bean = new MeuSessionBean();
  MockTransaction<Pessoa> tx = new MockTransaction<Pessoa>(); // usamos uma transacao de mentirinha ;)

  bean.adicionarPessoa("Carlos", "[email removido]", tx);

  assertTrue(tx.isCommitted());

  // getSavedObjects eh um metodo que so tem no mock, e da uma 
  // Object[] com os objetos comitados - como eu usei generics, ele 
  // retorna um Pessoa[], só pq eu sou fresco, mesmo. :D

  String nome = tx.getSavedObjects()[0].getName();
  String email = tx.getSavedObjects()[0].getEmail();

  assertEquals("Carlos", nome);
  assertEquals("[email removido]", email);

}

Gostei do lance de usar metadata (especialmente o @SessionBean(STATELESS)).
Alguém poderia dizer de usar alguma coisa ao estilo do Pico ao invés de um new Pessoa(). Fica interessante, mas talvez isso possa ser opcional. Para o caso, em que vai se persistir um simples bean, não vejo a necessidade. Tornaria as coisas mais complexas.

Poder dar um new Pessoa(), sendo que Pessoa eh um EJB CMP ia ser mesmo a 8a maravilha do mundo... o problema aqui eh que, se vc der um simples new no bichinho, vc perde o controle de instancias do application server, e aí a coisa vai morro abaixo.

Uma idéia melhor, talvez, seria usar algum tipo de factory:

Pessoa p = BeanFactory.create(Pessoa.class);
p.setNome(nome);
p.setEmail(email);

...mas aí a injeção de dependências vai pra casa do chapéu. Uma pequena mudancinha já resolve:

@Remote @Transaction(REQUIRED) public void adicionarPessoa(String nome, String email, Transaction t, BeanFactory factory) throws PessoaRuimException {

    // ...

    Pessoa p = factory.create(Pessoa.class);

    // ...
  }
}

Nosso teste, entao, fica com um pouquinho a mais de mock:

public void testAdicionarPessoa() {

  MeuSessionBean bean = new MeuSessionBean();

  MockTransaction<Pessoa> tx = new MockTransaction<Pessoa>();
  MockBeanFactory factory = new MockBeanFactory();

  bean.adicionarPessoa("Carlos", "[email removido]", tx, factory);

  // ...

}

Hmmm touché. Não tinha pensado nisso.
E que tal?

EJBContext ctx = EJBContextFactory.getInstance();// instâncias podem ficar em um pool, afinal ele é um objeto MUITO pesado para ficar dando new
Transaction tx = ctx.getTransaction();
Pessoa p = ctx.getBean(com.acme.Pessoa.class);
//... o resto é aquela lenga-lenga de cima...

Hmm, quase, Daniel… mas getInstance() eh uma rasteira na injeção de dependencias. Logo, mudamos a assinatura do nosso metodo para:

E, dentro do BeanContext, podemos pegar a Transaction e a BeanFactory. Pronto, matou. Usando uma BeanFactory (isso tem cheiro de Spring!), vc ainda ganha de brinde o suporte a AOP e filtros… maneiro!

De quebra, dava pra colocar um getApplicationContext() no dito, e ganhar o item 8 da lista. Entao, vejamos, a gente ja “especificou”* o que a gente quer dizer com os itens 1, 2, 3, 4, 7, 8, 9, 13. Ficou faltando 5 e 12, ja que 10 eh imbecil, e o 11 eh mais especifico da implementacao do container, e nao da pra exemplificar tao facil.

Itens 5 e 12: Make deployment descriptors more like XDoclet, standardize the deployment directory structure for EJBs. Hmmm… alguma ideia legal aqui?

[size=“9”]“especificou” = seria um mundo maravilhoso se fosse assim, mas na pratica a gente ta soh viajando na maionese e achando que o mundo é colorido, sem levar em consideracao coisas como compatibilidade com a especificacao existente nem nada disso. Vamos ficar so com a parte legal da coisa por enquanto ;)[/size]

Olá…

Já que temos uma nova especificação lançada a poucos meses e tão cedo não sai outra, como vocês vêem esta situação de tanto se falar em problemas dos EJB, principalmente dos Entity Beans CMP, e as melhorias virem tão lentamente.

Como estou iniciando em EJB, gostaria de saber se existe alguma alternativa aos EJB na questão enterprise em java, ou como contornar estas questões?

Obrigado desde já!

Bom, alternativas nao faltam, de Hibernate a Prevayler, de JDO a OJB, e ainda tem mais uma porraaaaaada de framework de persistencia bom por ai.

A questao mesmo eh: que diabos vc quer dizer com “enterprise java”? Nao vah me dizer que vc caiu no marketing da Sun

A questão enterprise se encaixa em tecnologias voltadas a desenvolvimento servidor, como componentes por exemplo (EJB). Eu vejo, na realidade uma “burocracia” demasiada pelo JCP, e me parece que estas tecnologias deveriam ter evoluído mais. Vejo muita complexidade, principalmente na quantidade de configurações nos XMLs.

Obrigado.

Jini e JavaSpaces. Mas ninguém ganha dinheiro com isso

Muito bem colocado - ai eh que esta o X da questao.

Marcio Kuchma