• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Validity of Session Facade in JavaEE

 
Ranch Hand
Posts: 413
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

In J2EE, Session Facade pattern was introduced to reduced the network overheads of fine grained methods of Entity Beans. If we assume, EJB 3 Entity represents the Entity Bean's (in EJB 2.x) Role (Both used to represent the persistence data), Is the Session Facade pattern for entities still valid / true?


PS. Note that EJB 3 Entities are just Pojos, available to use in any tier.

Thanks
 
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That is not Facade pattern, It is Transfer Object pattern.
Facade pattern is to reduce the calling of Session bean.
Transfer Object pattern is for Entity bean. When use JPA, it can be given up.
 
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Chaminda Amarasinghe wrote:
In J2EE, Session Facade pattern was introduced to reduced the network overheads of fine grained methods of Entity Beans. If we assume, EJB 3 Entity represents the Entity Bean's (in EJB 2.x) Role (Both used to represent the persistence data), Is the Session Facade pattern for entities still valid / true?


PS. Note that EJB 3 Entities are just Pojos, available to use in any tier.

Thanks



Hi,

I think one thing to note is that one of Session Facade initiatives is to reduce network calls by providing coarse gained functionality and for proper layering and maintainability of codes. Hence, it does not matter much, in my opinion, whether Entities are POJOs (in EJB3) or EJBs ( EJB1.X- EJB2.X). Therefore, I would still think such design pattern is still applicable for JEE5. "EJB3 In Action" will help to provide more advice.

Cheers!!
 
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think you misunderstand. Session Facade is about Session Bean, not Entity Bean.

Main purpose of Session Facade or Service Facade (in case not using Session Bean) is for reduce complexity, not reduce network call.

Facade pattern is about making easier to use.
Session Facade can also reduce network call, but I don't think it's too critical, compare to Entity Bean 2.0.
 
Chaminda Amarasinghe
Ranch Hand
Posts: 413
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kengkaj Sathianpantarit wrote:I think you misunderstand. Session Facade is about Session Bean, not Entity Bean.

Main purpose of Session Facade or Service Facade (in case not using Session Bean) is for reduce complexity, not reduce network call.

Facade pattern is about making easier to use.
Session Facade can also reduce network call, but I don't think it's too critical, compare to Entity Bean 2.0.



Here is a quote of Core J2EE pattern for Session Facade

Core J2EE pattern wrote:Session Façade addresses two issues: controlling client access to business objects, and limiting network traffic between remote clients and fine-grained business components and services.

 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, I know. I said that. But it's not a big problem.

How many fine-grained methods will we call 3 or 4?

Compare to Entity Bean 2.0, if we read 50 Entity Beans, each has 20 attributes, we need to call 1,000 times.
 
Chaminda Amarasinghe
Ranch Hand
Posts: 413
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kengkaj Sathianpantarit wrote:Yes, I know. I said that. But it's not a big problem.

How many fine-grained methods will we call 3 or 4?

Compare to Entity Bean 2.0, if we read 50 Entity Beans, each has 20 attributes, we need to call 1,000 times.



Calling 1000 times over network is not a big problem? :roll:
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is, but we solve by Transfer Object, not Session Facade.

I mean Session Facade might encapsulate about 3-4 methods.

If we read 50 entity beans, each has 20 attributes to display in screen we use Transfer Object pattern.

I hope you understand what I mean. I don't say it does not help, it help but not much.

If a Session Facade call 1,000 methods, I think there is a BIG problem in design.
 
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Session Facade provides a remote view of an application service or services. I'd avoid putting any business logic or use case coordination in it - that's more the role of application services.
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you're asking whether POJO entities replace DTO you might like to have a look at this thread - https://coderanch.com/t/423842/OO-Patterns-UML-Refactoring/Domain-Object-Vs-DTO
 
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here is my opinion..

At a high level DTO are for reducing coupling between systems/tiers and reducing n/w calls, and Session Facades are intended for reducing n/w calls(not just managing EntityBeans in EJB2) and simplifying the interface seen by the clients!!

One way to relate them is - DTOs lead to less remote calls through the Facade pattern. A facade assembles (using TO assembler) a DTO.

DTO is used as an aggregate of fine grained data objects/entities and hence is a more Data Object oriented.

Session Facade on the other hand is more business process oriented.

The differences and similarities become more obvious/magnified in a highly distributed environment involving multiple homogeneous/heterogeneous systems!

If your business entities are scoped within the application then having a DTO for every entity would be over architecting(antipattern). However if you have a business application system(like Master Data Mangement system) that is a source to many other applications having DTOs would make sense as this would reduce the coupling between your system and the MDM.

Having said the above,
Session Facades are still valid in JEE.


HTH
Ashwin

 
Tick check! Okay, I guess that was just an itch. Oh wait! Just a tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic