|
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]
|
