'
Ol� Aguinaldo.
Pelo visto eu cheguei tarde demais e o Ricardo Santiago j� respondeu
todas as suas d�vidas, mas talvez eu possa acrescentar alguns detalhes �s
respostas dele:
> > - Com rela��o aos EntityBeans, todos os objetos que necessitem de
> >persistencia devem ser mapeados como EntityBeans, n�o estou falando dos
> objetos
> >SessionBean que quando possuam estado que necessite de persist�ncia podem
> ser
> >serializados e armazenados pois s�o objetos para uma sess�o especifica,
> estou
> >falando de objetos de neg�cio, so que MENOS relevantes, mas que tem
> contexto
> >corporativo, ex.; tenho algo parecido com aquelas classes que s�o tipo
> >"tabelas", ex.: Estados, Paises, Escrit�rios, Moeda. Estas Classes tem
> mais
> >atributos alem da descri��o, n�o poderiam ser simplesmente resolvidas por
> um
> >enum (por ex.). O gerenciamento EJB n�o seria muito pesado para estes
> casos????
> >Como se tratam este objetos, tamb�m como EntityBeans ???
>
> Voc� pode trat�-los normalmente como EntityBeans. A performance n�o ser�
> pior do que se voc� implementasse isso da maneira tradicional. Al�m do mais,
> o container pode fazer um momente de melhorias na performance atrav�s de
> cache de objetos muito usados.
Devido �s otimiza��es da persist�ncia autom�tica (como cache e
a capacidade de combinar diversas opera��es em um �nico acesso ao BD),
� muito mais prov�vel que a performance fique melhor do que se isso
fosse implementado manualmente.
Em alguns casos especiais mais espec�ficos, pode ser que uma
implementa��o manual possa ficar mais eficiente aproveitando alguma
caracter�stica particular daquele objeto. Mas mesmo nestes casos,
vale mais a pena primeiro fazer a implementa��o de todo o sistema
usando a implementa��o autom�tica, a� depois que estiver tudo
funcionando basta mudar esses poucos objetos espec�ficos para
persist�ncia "Bean Managed" e a� sim colocar o seu pr�prio c�digo.
Isso vai inclusive permitir que voc� possa facilmente comparar com
a performance obtida no modo autom�tico e verificar se sua
otimiza��o realmente vale a pena.
Mas � claro que desenvolvimento de software n�o � apenas
uma receita de bolo, tudo isso tem que ser feito com crit�rio. Se
houver alguma parte do sistema em que n�o � poss�vel um mapeamento
mais direto entre objetos e bancos de dados, provavelmente vai ser
necess�rio implement�-los usando persist�ncia Beam-Managed desde
o princ�pio, embora mesmo assim esses objetos devam ser definidos
como Entity Beans.
> > - Em uma aplica��o normal CORBA, o crit�rio de registro ou n�o de um
> obj.
> >no ORB mesmo sendo de neg�cio fica a crit�rio do desenvolvedor, pois � um
> >procedimento pesado. Assim sendo em alguns casos voc� somente trabalha como
> o
> >objeto IMPL, ou seja, voc� s� trabalha com o obj, no contexto do servidor
> sem
> >registra-lo no CORBA, o que � muito mais leve, o que � uma alternativa
> >interessante caso voc� n�o necessite passar a referencia para o CLIENTE.
> Em EJB
> >para um obj. EJB isso n�o � poss�vel (aparentemente) , pois eu somente
> consigo
> >acessar o obj atraves da sua interface, assim sendo eu teria sempre que
> >solicitar ao CONTAINER do Aplication Server o Objeto ??? Isso n�o � muito
> pesado
> >??? Como eu faria para contornar esse problema ???
>
> Quando voc� escreve um bean que tem refer�ncias para outros beans, voc� pode
> descrever isso no deployment descriptor. Ent�o, o container poder� optimizar
> este acesso, tornando as chamadas locais, ou de alguma outra forma que eu
> n�o sei qual � (isso � da conta do container).
> S�o exatamente nestes pontos que os produtos (Application Server J2EE
> compliants) do mercado ter�o de mostrar vantagens adicionais uns sobre os
> outros.
Se do ponto de vista l�gico os dois objetos comp�em um �nico
servi�o, ent�o voc� pode combin�-los dentro de um �nico Entity Bean.
A melhor analogia � imaginar a interface exportada pelo EJBean como o
equivalente ao IDL do CORBA: da mesma forma como a implementa��o do
IDL skeleton pode ser implementada por v�rios outros objetos para
os quais ser�o repassados os acessos, tamb�m a implementa��o de um
Entity Bean pode conter v�rios outros objetos. Da mesma forma que
voc� pode acessar classes da biblioteca padr�o para implementar
o seu EJBean, voc� tamb�m pode acessar outras classes externas
criadas por voc� mesmo.
Por outro lado, se do ponto de vista l�gico seus objetos
corresponderem a servi�os diferentes, melhor coloc�-los em
Entity Beans diferentes mesmo. A performance n�o vai ser um
grande problema, porque voc� deve poder configurar o seu
Application Server para rodar estes Entity Beans dentro de
um mesmo processo (em threads diferentes � claro) e neste caso
as chamadas entre eles n�o vai ser muito mais pesada do que uma
simples invoca��o de m�todos entre threads. A grande vantagem �
que nesse caso o seu sistema n�o fica monol�tico, mais tarde
voc� vai poder facilmente reutilizar esse servi�o em outro
contexto sem que ele esteja amarrado aos demais.
> > - Com rela��o ao mapeamento de persist�ncia autom�tico do J2EE, para que
> eu
> >possa utilizar o servi�o de persistencia do Application Server, �
> necess�rio que
> >se deixe os atributos que ser�o persistidos como PUBLIC, como fica a parte
> de
> >seguran�a neste sentido, digamos que algum outro programador mal
> intencionado(ou
> >n�o), resolva acessar diretamente os atributos da CLASSE, como eu poderia
> me
> >garantir que ele n�o faria isso ??? Isso dentro do contexto do pr�prio
> Servidor.
>
> Aqui n�o tem problema, visto que voc� NUNCA acessa o seu EJB diretamente. O
> que o seu programador vai ver � uma Remote interface, que n�o tem atributos
> nem nada. Entenda bem o seguinte ponto, quando voc� escreve um EJB, voc�
> escreve 2 interfaces e uma classe. As interfaces s�o de interesse dos
> clientes, e ser�o vis�veis. A classe � de interesse apenas do container.
> Ningu�m mais neste mundo pode colocar sua m�o nela.
> Eu tamb�m fiquei encucado com isso no come�o, pois sou FAN�TICO por
> encapsulamento, mas, depois que entendi direito a arquitetura, vi que n�o
> tem erro.
>
> Encarre a classe que implementa a interface EntityBean ou SessionBean, como
> uma helper. O que interessa mesmo no seu design OO s�o as Remote e Home
> interface!
As regras de acesso do Java como "public" s� valem para chamada
direta de m�todos dentro de um mesmo programa ou dentro de um mesmo
EJBean. Mas isso n�o se aplica no caso de acessos externos ao EJBean,
porque quem valida o acesso � o Container e n�o apenas as regras de
programa��o do Java.
No caso, o Container nem sequer permite acesso direto aos
atributos do EJBean, apenas aos seus m�todos (mesmo assim o acesso
est� sujeito �s regras de seguran�a), por isso n�o tem como um
programador fazer besteira neste caso, mesmo que esteja no mesmo
servidor.
Um abra�o,
Einar Saukas
Technical Consultant
Summa Technologies, Inc.
http://www.summa-tech.com
--------------------------- LISTA SOUJAVA ---------------------------
http://www.soujava.org.br - Sociedade de Usu�rios Java da Sucesu-SP
[para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
---------------------------------------------------------------------
