Galera, tô com uma dúvida aqui em relação ao pattern Façade.
Segundo o livro que estou lendo, EJB em Ação, diz que o façade serve, entre outras coisas, para diminuir o tráfego de chamadas RMI.
Porém não entendi como isto é feito, uma vez que a partir de um façade eu faço chamadas a outros EJB’s, ou seja, mais chamdas RMI da mesma forma.
Tirando o fato do façade agrupar lógicas de negócio, ele realmente diminui o tráfego? Como?
Obrigado.
Ele vai reduzir o tráfico de chamadas RMI porque você vai acessar o Facade como remoto e o Facade vai acessar os outros EJB através de uma interface local se os mesmo estiverem no mesmo ejb-conteiner é claro.
Deixa eu ver se entendi, ao invés de fazer várias chamadas remote, será feita apenas uma, ao facade e a partir dele, as chamadas serão feita local,
é isso ???
Deixa eu ver se entendi, ao invés de fazer várias chamadas remote, será feita apenas uma, ao facade e a partir dele, as chamadas serão feita local,
é isso ???[/quote]
Isso! Ao invés de você ter que fazer varias chamada remotas para varios EJBs, com um Facade você prove um interface simplificada que irá acessar os outros EJBs de forma local. Isso reduz o número de chamadas remotas.
[quote=Foxlol]Porém não entendi como isto é feito, uma vez que a partir de um façade eu faço chamadas a outros EJB’s, ou seja, mais chamdas RMI da mesma forma.
Tirando o fato do façade agrupar lógicas de negócio, ele realmente diminui o tráfego? Como?[/quote]
Pelo que eu entendi, você deve estar tentando usar o pattern bem antigo J2EE chamado Service Facade. Na implementação interna deste, as chamadas aos outros EJBs é feita pela interface “Local”, não necessitando chamadas RMI, o cliente do seu facade sim que fará chamadas RMI. Dessa forma, com 1 chamada, você pode fazer bastante coisa local por trás dos panos e retornar o resultado em seguida.
[]s
Existe alguma solução melhor/nova pra isso?
Galera, obrigado pelas respostas, deu pra entender.
Mas como o psyltrance disse, existe alguma outra forma?
Flw
Existe alguma solução melhor/nova pra isso?[/quote]
Pra esse problema não. Eu disse antigo pois o Pattern é antigo e EJB2x também. Hoje em dia, o Pattern usado pra evitar chamadas remotas em excesso na rede é o Remote Facade, que seria uma evolução desse antigo Pattern Java EE da época. O objetivo é o mesmo, esceto pelo fato que não usa essas tranqueiras de Session Bean.
O custo de uma chamada de rede é enorme num ambiente distribuído. Por isso, usa-se o Session Facade (“Agrupa vários Session-Beans complexos em uma única e simplificada interface”). Para as boas práticas de projeto distribuído, deve-se evitar ao máximo as chamadas de rede. Para complementar esta solução, é necessário a utilização de outro Design Pattern Sun J2EE, o DTO (Data Transfer Object). Deve-se moldar um DTO para compor os dados que seriam devolvidos por todas as requisições na rede… com isto, ao invés de serem feitas 10 chamadas na rede (e serem acessados 10 stubs e 10 skeletons, além do tempo de latência), a chamada é feita num único EJB Stateless Session Bean (que estará no servidor), este, localmente (por que os EJBs devem estar no mesmo servidor dele) fará a chamada no restante dos componentes e construirá o objeto moldado, retornando-o ao aplicativo chamador. Então, reduz-se o tráfego na rede, além de tornar o software mais solto entre as camadas e mais facilmente extensível.
Abraço,
[quote=rodrigo.ferreira]O custo de uma chamada de rede é enorme num ambiente distribuído. Por isso, usa-se o Session Facade (“Agrupa vários Session-Beans complexos em uma única e simplificada interface”). Para as boas práticas de projeto distribuído, deve-se evitar ao máximo as chamadas de rede. Para complementar esta solução, é necessário a utilização de outro Design Pattern Sun J2EE, o DTO (Data Transfer Object). Deve-se moldar um DTO para compor os dados que seriam devolvidos por todas as requisições na rede… com isto, ao invés de serem feitas 10 chamadas na rede (e serem acessados 10 stubs e 10 skeletons, além do tempo de latência), a chamada é feita num único EJB Stateless Session Bean (que estará no servidor), este, localmente (por que os EJBs devem estar no mesmo servidor dele) fará a chamada no restante dos componentes e construirá o objeto moldado, retornando-o ao aplicativo chamador. Então, reduz-se o tráfego na rede, além de tornar o software mais solto entre as camadas e mais facilmente extensível.
Abraço,
[/quote]
Fervasso, esse não é o session e sim o remote façade.
Moldar objetos de grossa granularidade(DTO’s) para de fina granularidade.
Além do que eh a mesma coisa que nosso amigo leonardom disse.
A diferença entre session e remote eh bem singular. Onde o session se aproxima de um Service Layer.
Valeu Emerson, estou lendo os docs do Fowler e as respostas aqui foram de grande auxílio.
Abraço.
Aproveitando o gancho…não haveria o pattern DTO se tornado um anti-pattern no EJB 3?
Uma vez que posso trafegar pojos leves e serializaveis entre as camadas e um dos motivos da criação do DTO ter sido devido aos pesados entity beans das versões anteriores do EJB?
Flw
Bom dia.
Então, neste caso, o termo DTO ou VO (como alguns preferem) seria mais um conceito… o que espera-se de um DTO é um objeto para transferência de dados para redução do tráfego na rede. A diferença entre o EJB 2.1 e o 3 neste sentido seria o fato de não mais necessitar a criação de um outro MODELO IGUAL, apenas para transferência de dados, podendo-se utilizar o mesmo POJO para este fim. Porém, trata-se de um projeto de arquitetura, pois nem sempre é adequado utilizar o mesmo POJO para transferência de dados… cairiamos no mesmo problema anterior (de ter que fazer várias chamadas de dados na rede… e, pelas boas práticas… devemos reduzir ao máximo as idas e vindas pela rede). Com isso, agruparíamos estas chamadas em um único modelo, e este modelo sim, pode ser chamado de DTO.
Aí depende da aplicabilidade… se você não vai fazer chamada em um “serviço” (que utiliza dados de várias solicitações em vários tipos de beans de sessão ou sistemas legados), você deve realmente retornar um único POJO (que neste caso faz a função de um DTO)… mas se a chamada necessitar de processamento e composição de dados… então deve-se modelar um objeto e retorná-lo unicamente, na forma de um DTO ao invés de fazer várias chamadas pela rede e utilizar POJOs em cada uma delas.
Abraço,
[quote=rodrigo.ferreira]Bom dia.
Então, neste caso, o termo DTO ou VO (como alguns preferem) seria mais um conceito… o que espera-se de um DTO é um objeto para transferência de dados para redução do tráfego na rede. A diferença entre o EJB 2.1 e o 3 neste sentido seria o fato de não mais necessitar a criação de um outro MODELO IGUAL, apenas para transferência de dados, podendo-se utilizar o mesmo POJO para este fim. Porém, trata-se de um projeto de arquitetura, pois nem sempre é adequado utilizar o mesmo POJO para transferência de dados… cairiamos no mesmo problema anterior (de ter que fazer várias chamadas de dados na rede… e, pelas boas práticas… devemos reduzir ao máximo as idas e vindas pela rede). Com isso, agruparíamos estas chamadas em um único modelo, e este modelo sim, pode ser chamado de DTO.
Aí depende da aplicabilidade… se você não vai fazer chamada em um “serviço” (que utiliza dados de várias solicitações em vários tipos de beans de sessão ou sistemas legados), você deve realmente retornar um único POJO (que neste caso faz a função de um DTO)… mas se a chamada necessitar de processamento e composição de dados… então deve-se modelar um objeto e retorná-lo unicamente, na forma de um DTO ao invés de fazer várias chamadas pela rede e utilizar POJOs em cada uma delas.
Abraço,[/quote]
Sim, mas aí teríamos um modelo fantoche, burro de carga.
Contando que eu tenha uma arquitetura bem definida para minha persistência de dados, meu entities beans teriam tudo que precisam via relacionamento, anulando a necessidade de criar DTO’s.
Flw
Sim… aí seria uma questão de projeto… Na verdade Design Patterns não são uma ciência exata… são apenas maneiras que outras pessoas encontraram pra resolver problemas semelhantes… e as documentaram… e a gente copia… agora, copiar ou não… é apenas uma questão de escolha.
Mas, os PADRÕES OFICIAIS J2EE da Sun podem ser encontrados aqui: http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html . Estes padrões são os recomendados para utilização em equipe nos projetos J2EE… para que todos falem a mesma lingua e a solução seja realmente comprovada e sua manutenção posterior seja simples.
Se lermos o padrão de Projeto oficial da Sun Session Facade (http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html) veremos que ele é exatamente a solução para a sua dúvida.
Mas novamente, padrões são padrões e cada projeto tem uma solução. Isto não deve ser discutido… Cada projeto se comporta de uma forma e na verdade o que existe mesmo é uma composição muito doida entre vários padrões… Todos são perfeitos… desde que o software faça o que o cliente deseja e que ele seja facilmente mantido e entendido depois pela equipe.
Abraço,
Quem usa DTO com EJB 3?
Só se for uma entidade que tem milhares de relacionamentos e vc precisa de poucos dados.
[quote=Foxlol]Aproveitando o gancho…não haveria o pattern DTO se tornado um anti-pattern no EJB 3?
Uma vez que posso trafegar pojos leves e serializaveis entre as camadas e um dos motivos da criação do DTO ter sido devido aos pesados entity beans das versões anteriores do EJB?
Flw
[/quote]
Depende. Na maioria dos casos sim. Mas se o seu POJO não for suficiente pra trafegar tudo que você precisa e não exista uma agregação dos seus objetos que satisfaça sua consulta o DTO pode ser uma alternativa. Mas nesse caso vai ser mas exeção do que regra.
[quote=rodrigo.ferreira]Sim… aí seria uma questão de projeto… Na verdade Design Patterns não são uma ciência exata… são apenas maneiras que outras pessoas encontraram pra resolver problemas semelhantes… e as documentaram… e a gente copia… agora, copiar ou não… é apenas uma questão de escolha.
Mas, os PADRÕES OFICIAIS J2EE da Sun podem ser encontrados aqui: http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html . Estes padrões são os recomendados para utilização em equipe nos projetos J2EE… para que todos falem a mesma lingua e a solução seja realmente comprovada e sua manutenção posterior seja simples.
Se lermos o padrão de Projeto oficial da Sun Session Facade (http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html) veremos que ele é exatamente a solução para a sua dúvida.
Mas novamente, padrões são padrões e cada projeto tem uma solução. Isto não deve ser discutido… Cada projeto se comporta de uma forma e na verdade o que existe mesmo é uma composição muito doida entre vários padrões… Todos são perfeitos… desde que o software faça o que o cliente deseja e que ele seja facilmente mantido e entendido depois pela equipe.
Abraço,[/quote]
Cara hOUIAEhuioHEAUIOe fervasso minha dúvida não são os padrões de projeto, já vimos que vc conhece os PADRÕES OFICIAS SUN, parabéns.
E exatamente felipeguerra, quem precisa de DTO com EJB3.
Flw.