>Ol� Pessoal
Ol� Aguinaldo
> - Quando voc� desenvolve uma aplica��o distribuida utilizando CORBA,
>normalmente voc� tem um objeto que se encarrega de ser a porta de entrada
para o
>processo que est� rodando (ou seja, ele � um obj. fabrica, ou o pai natural
da
>aplica��o(processo)) , sendo que este objeto � registrado em algum servi�o
de
>nomes, ou no gerenciador de referencias do ORB, permitindo que atrav�s dele
voc�
>tenha acesso aos outros objetos ou servi�os disponiveis .
Em EJB voc� pode ter os 2. Toda interface Home de um EJB ser� instalada no
servi�o de nomes que � acessado via JNDI. Se voc� quiser, poder centralizar
as chamadas em um �nico objeto, e disponibiliz�-lo na servi�o de nomes.
> - 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.
> - 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.
> - 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!
>Tenho alguns outros pontos .... mas ficam para depois ...
No problem, � s� mandar que a medida do poss�vel, estamos a�!
Ricardo Munhoz Santiago (CPM Sistemas)
Sun Certified Programmer for the JAVA 2 Platform
Come and get some !!!
--------------------------- 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]
---------------------------------------------------------------------
