• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Frits Walraven
Bartenders:
  • Carey Brown
  • salvin francis
  • Claude Moore

Session Facade, Business Delegate, Client Stub Proxy or simple services in integration  RSS feed

 
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, ranchers,

I am completing my SCEA5 assignment and the more I polish it the more I have doubts in selecting or not selecting Facade patterns.

I have 2 external systems, one of them is accessed via web services, other is via plain sockets.
I have 2 corresponding stateless EJBs which provide a usable interface and encapsulate connection establishing process to those systems.

The main question is: Are those classes Session Facades or just typical business services?

From the description of the Session Facade pattern I understood that this pattern is used when you have a system and you expose its functionality via session facade to another external system. But in my case I have a client system which uses other systems functionality (via sockets or web services), so this class is consumer, and facade seems to be always a provider.

I even thought that this can be a Business Delegate, the description of this pattern suits well, but I've read that this is more a view-tier pattern, however I invoke it from pure business logic.

Another possibility is that this is a Client Stub Proxy pattern, as described here: http://www.ewebprogrammer.com/ejb-architecture-session-beans/module2/client-stub-proxy-pattern.jsp

I try to put more-and-more patterns in my implementation... perhaps I should stop and just leave those classes as typical business services?

Glad to see your thoughts!
 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Dimitri,

Frankly speaking, I do not understand what are you trying to achieve ?
Trying to use as many patters as possible is not a good idea IMO. Patterns should only be used in case you have a problem that should be solved.
For example if you have many stateless session beans providing lot of services, you can use Session Facade in order to simplify the interface and reduce user calls.
In you project there is probably no need for such additional layer. Additionally your definition of Session Facade is not correct. You can't simply name any EJB a "Session Facade", only because it exposes services of external system.
If you want to find the name of the pattern you use, I think the closest one is "Proxy" (GOF , not Client Stub Proxy).
Each session bean acts as a proxy between clients and external system.

Regards,

Pawel Piwowar
 
Dmitri Ericsson
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
thanks for clarifying this issue
I've just done design as I've done in a real life but I was not sure what pattern describes this solution. Now it's clear
Br,
Dmitri
 
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The URL previsouly mentioned

client-stub-proxy-pattern

has been changed to

Client Stub Proxy Pattern

The following page contains a series of images describing the EJB Proxy pattern.
EJB Proxy Pattern
 
You'll never get away with this you overconfident blob! The most you will ever get is this tiny ad:
Create Edit Print & Convert PDF Using Free API with Java
https://coderanch.com/wiki/703735/Create-Convert-PDF-Free-Spire
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!