Mais lenha na fogueira dos entity beans

Programação Arquitetura
#1

http://www.manageability.org/blog/stuff/scalable_ejb_idiom

Novidade pra muitos aqui, acredito… :o

#2

Ae cv blz?
Bom nao basta criticar neh… Fala ae quais são suas alternativas para persistencia de dados fora Entity Beans…
Ae a galera pode ter uma base mais legal pra escolher se usa ou nao entity beans.

PS: fiz um build.xml e um xdoclet q ficou bem legal depois postarei e gostaria de criticas suas e do ozie, q parecem ser as pessoas q mais conhecem a tecnologia aki…
Qualquer outra pessoa q conheca bem tb , gostaria de ouvi-lo …

Abraços a todos

#3

Opções para persistência não faltam. E o melhor, estas opções não precisam de um trambolho como um servidor J2EE acoplado para funcionarem. As opções vão desde o bom e velho JDBC, passando por frameworks de persistência como o Hibernate (meu favorito!), JDO, OJB, Torque, Prevayler (este sem usar banco de dados), chegando até o pouco conhecido JavaSpaces, que faz parte da tecnologia Jini. Esta última opção pode ser muito útil caso você precise de espaços persistentes distruídos E transacionais.
E, como disse antes, você pode usar todas as alternativas onde você quiser: em uma aplicação Swing de duas camadas, em uma aplicação de WEB que não precisa de muita frescuras ou em uma aplicação J2EE completa, substituindo aquele lixo dos entities.

#4

por falar em JavaSpaces,
alguem ja utilizou isto?? tem algum parecer??
existe alguma implementação free? (só ouvi falar de duas implementações comerciais :slight_smile: )

#5

[quote=“urubatan”]
existe alguma implementação free? (só ouvi falar de duas implementações comerciais :slight_smile: )[/quote]

RI da sun, nao?

#6

Eu já usei. É uma visão diferente de persistência, na minha opinião. Mas não deixa de ser interessante. A idéia é que seja lá o que for colocado dentro de um Space não é nada mais do que mero dado, ou seja, se você enfiar um objeto em um destes espaços, você não vai poder invocar nenhum método dele. Para tanto, é preciso travá-lo (ou seja, ninguém acessa aquele objeto até você destravá-lo), obter uma cópia, invocar o método e depois recolocar a sua cópia de volta no espaço. Mas há uns problemas que poderiam ter sido resolvidos, mas não foram. O principal se refere a uma coisa muito feia: todas as propriedades de um objeto que vai ser inserido no espaço devem ser declarados como PÚBLICOS!!! :roll: Mais ou menos assim:

[code]
public class MeuObjeto{

public Integer prop1;
public String prop2;
// and so on...

}[/code]
Feio, né? Espero que eles tenha resolvido isso na versão 2.0 do Jini.
Ahhh outra coisa interessante de se lembrar: caso você queira, por exemplo, persistir uma lista de objetos, JAMAIS use arrays ou quaisquer collections. Lembre-se que, fazendo isso, ao travar o objeto para atualizar uma posição do seu (por exemplo) array, você vai travar o acesso ao objeto, o que não é muito interessante. Para isso, você tem que implementar uma “lista” no JavaSpace. Mais ou menos assim:

[code]
public class JavaSpaceList{

 public Integer index;
 public String dado;

}[/code]

Desta forma, quando você precisar atualizar alguma posição da sua lista, você o faz procurando por um objeto no espaço cuja propriedade index seja igual àquela que você queira atualizar.

Bom, sobre implementações abertas e gratuitas, a próprioa implementaçào que vem junto com o Jini Starter Kit é gratuita. A IBM, se não me engano, também tem sua implementaçào de JavaSpaces, que se chama TSpaces (ou TupleSpaces, não lembro).

Maiores informações, no GOOGLE ou no JINI.ORG. :smiley:

Até,

#7