----- Original Message -----
Sent: Thursday, October 03, 2002 12:17
PM
Subject: Re: [enterprise-list] Business
Delegator
Eu discordo.
Cliente ------>WebserviceClient
Impl------->SOAP----> JAX-RPC webservice endpoint ----->
BusinessDelegate1 ------> SessionBean ------> EntityBean
Exemplificar com esse n�vel de detalhe n�o iria
acrescentar nada aos objetivos do exemplo. Al�m do mais, fazendo como vc fez o
cliente t� todo amarrado no WebserviceClient Impl. E se por acaso ele quisesse
retirar essa casca WebService e voltar a utilizar EJB diretamente ? Teria que
alterar TODOS os clientes, que � justamente o que n�o se deseja
fazer.
Por mim, para atingir os objetivos do Business
Delegate, deveria ser:
Cliente ------> BusinessDelegate1
------> WebserviceClient Impl------->SOAP----> JAX-RPC webservice
endpoint -----> SessionBean ------> EntityBean
Quanto a outra parte, pres'ten��o na preocupa��o
de quem fez a pergunta
"A ideia � utiliza-lo
para mais tarde migrar a aplica��o para a plataforma J2EE com EJB e assim
evitando mudan�as na parte do cliente"
Ele n�o quer utilizar o BD para evitar altera��es
na camada neg�cio quando a camada cliente muda, como vc fez. Ele quer
evitar alterar o cliente quando a camada de neg�cios sofrer
altera��es.
A abordagem que vc fez � a de que o BD seja um
simples proxy do Session, quando eu acho que ele deveria ser algo mais. Ser
apenas um proxy � papel de um Client Facade. IHMO, Business Delegate = Client
Facade + Service Locator
[]s
By Ale!
----- Original Message -----
Sent: Thursday, October 03, 2002 7:26
AM
Subject: Re: [enterprise-list] Business
Delegator
> Cliente ------>
BusinessDelegate1 ------> SessionBean ------> EntityBean
>
> Toda a complexidade envolvida na manipula��o de EJBs fica
concentrada no BD.
> Se por acaso, a tecnologia mudar para
WebServices, teremos que fazer as
> mudan�as apenas no BD, mantendo
sua interface de servi�os e, por
> consequ�ncia, mantendo a
implementa��o do cliente intacta.
>
> Cliente ------>
BusinessDelegate2 ------> WebServices -->
> SessionBean
------> EntityBean
At� ae tudo bem,
mas aqui est� enganado. Seria:
Cliente
------>WebserviceClient Impl------->SOAP----> JAX-RPC webservice
endpoint -----> BusinessDelegate1 ------> SessionBean ------>
EntityBean
O objetivo � esconder a
complexidade de EJB para o cliente e separa��o de camada de apresenta��o da
camada de negocios (loosely coupled). O Business delegate neste sentido � um
proxy. Do seu jeito n�o faz sentido nenhum pois em qq tipo cliente deveria
ser implementada um outro Business Delegate. A proposta do business delegate
�:
WebCliente ------> BusinessDelegate1
------> SessionBean ------> EntityBean
PDACliente ------> BusinessDelegate1 ------> SessionBean
------> EntityBean
WebServiceCliente
------> BusinessDelegate1 ------> SessionBean ------>
EntityBean
SWINGCliente ------>
BusinessDelegate1 ------> SessionBean ------> EntityBean
VBJCommCliente ------> BusinessDelegate1 ------>
SessionBean ------> EntityBean
DelphiJCommCliente ------> BusinessDelegate1 ------>
SessionBean ------> EntityBean
WAPCliente ------> BusinessDelegate1 ------> SessionBean
------> EntityBean
> Uma
estrat�gia que eu acho legal � agrupar casos de uso semanticamente
>
relacionados em Session Facades que disponibilizam servi�os de alto n�vel
de
> abstra��o e utilizar o Business Delegate como Client Fa�ade para
funcionar
> como um proxy do Session Fa�ade no lado
cliente.
Quase. O Business Delagate � o
ponto de entrada (proxy) de componentes.
>
> []s
> By Ale!
>
> -----
Original Message -----
> From: "F�bio Barboza de Oliveira"
<[EMAIL PROTECTED]>
> To:
<[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
> Sent: Wednesday, October 02, 2002
10:32 AM
> Subject: Re: [enterprise-list] Business Delegator
>
>
> Mas acho improv�vel que n�o seja necess�rio reescrever os
clientes, pois a
> maneira com se faz acesso aos EJBs (Entity,
session) � algo mais complexo.
> Acredito que se as classes fossem
modelas de forma bem semelhante ao modelo
> do EJBs, ai sim as
altera��es para os clientes seriam pequenas.
> No EJB, voc� tem o
metodos Home, para criar (ejbCreate) no caso de um Entity
> Beans ele
ser� respos�vel pela cria��o de um novo registro na base, etc...
>
E
> tem os m�todos de negocio que ficam na interface.
> Se voc�
modelar as classes de maneira diferente, tipo criar uma classe que
>
tenha um m�todo "inserirUsuario" ou "consultarUsuario", essa classe
estar�
> longe de parecer com um EJB, sendo assim seu cliente ter� que
ser reescrito
> tambem. Pode-se at� criar um Bean dessa maneira, mas
voc� estar� fugindo do
> padr�o EJB e podendo comprometer a
performance do Aplication Server.
> N�o concorda?
>
>
> Em Qua 02 Out 2002 09:58, Bruno Copelli escreveu:
> > Bom
dia Fabio.
> >
> > Utilizando os Business Delegates vc
pelo menos nao vai precisar reescrever
> > a parte cliente qndo
fizer a migracao. So vai precisar reescrever o
> > conteudo dos
delegates. Eu pelo menos apostei nessa estrategia.
> >
> >
Abracos,
> >
> > Bruno
> >
> > -----
Original Message -----
> > From: "F�bio Barboza de Oliveira"
<[EMAIL PROTECTED]>
> > To:
<[EMAIL PROTECTED]>
> > Sent: Wednesday, October
02, 2002 9:51 AM
> > Subject: [enterprise-list] Business
Delegator
> >
> >
> > Caros colegas,
>
>
> > Gostaria da opni�o de voc�s sobre a utiliza��o de um
Business Delegator
> > para o desenvolvimento de um sistema
java.
> > A ideia � utiliza-lo para mais tarde migrar a aplica��o
para a plataforma
> > J2EE com EJB e assim evitando mudan�as na
parte do cliente Swing.
> > Eu queria saber se vale a pena utilizar
um Business Delegator ou ele ser�
> > uma
> > perda de
tempo pois a aplica��o ter� que ser reescrita para a plataforma
> >
J2EE
> > mais tarde tando na parte de clientes quanto na parte do
servidor, pois a
> > modelagem n�o est� seguindo a metodologia
EJB.
> >
> > Atenciosamente
> >
> >
F�bio Barboza de Oliveira
> >
> >
---------------------------------------------------------------------
>
> Para cancelar a subscri��o, envie mensagem para:
> >
[EMAIL PROTECTED]
> > Para comandos
adicionais, envie mensagem para:
> >
[EMAIL PROTECTED]
> >
> >
> >
---
> > Outgoing mail is certified Virus Free.
> > Checked
by AVG anti-virus system (http://www.grisoft.com).
> > Version:
6.0.393 / Virus Database: 223 - Release Date: 30/9/2002
> >
>
>
_______________________________________________________________________
>
> Yahoo! Encontros
> > O lugar certo para encontrar a sua alma
g�mea.
> > http://br.encontros.yahoo.com/
> >
> >
---------------------------------------------------------------------
>
> Para cancelar a subscri��o, envie mensagem para:
> >
[EMAIL PROTECTED] Para comandos adicionais,
envie
> > mensagem para:
[EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
>
Para cancelar a subscri��o, envie mensagem para:
>
[EMAIL PROTECTED]
> Para comandos adicionais,
envie mensagem para:
> [EMAIL PROTECTED]
>
>
>
>
>
---------------------------------------------------------------------
>
Para cancelar a subscri��o, envie mensagem para: enterprise-list-
>
[EMAIL PROTECTED]
> Para comandos adicionais, envie mensagem
para: enterprise-list-
>
[EMAIL PROTECTED]
