• 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

Business Delegate, Session Facade and Application Service

 
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Folks,
Read the Core J2EE Patterns, specificallly Business Delegate, Session Facade and Application Service. The books says, "Business Delegate is the client-side abstraction for a Session Facade". So it merely prevents the clients being directly exposed to the Session Facade. The real work is done by the Session Facade. So I believe, the Business Delegate should have just the busines methods that client can call. The methods are implemented (ie the codes to do the actual work - the business logic) in the Session Facade. But Application Service can be used to encapsulate the business logic. So the business logic in Session Facade is moved to Applicatoin Service leaving only the methods in the Session Facade. Now the Application Service is doing the work. Now the Business Delegate and Session Facade are there just for the layers providing abastraction. Why do we need the both? can we not just use the Session Facade like this:

Client --> Session Facade --> Application Service

I chose the Session Facade so that we can use it as a Stateful in case we want to maintain the conversational state. Also, it provides insulation for Application Service preventing the client directly accessing the Applciation Service where business logic is implemented.

Or we do need to have the Business Delegate even if it means just a layer containing the methods which calls the Session Facade to call the same methods?

Am I missing something here? Please educate me.
Thanks.
BR
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Brian,

As far as I concern, the business delegate also hides the underlying implementation of the business service (look up stuff, getting the home/remote interfaces, catching handles, handling non business exceptions...)

Or we do need to have the Business Delegate even if it means just a layer containing the methods which calls the Session Facade to call the same methods?


I guess so. You will have practically the same methods.

Client --> Session Facade --> Application Service



I am thinking too using a SFSB to keep the conversational state of the client. I am also decided to use a BusinessDelegate to let the Presentation tier interact with the Business tier

Client --> BusinessDelegate --> Service Locator --> Session Facade (SFSB) --> Application Service (SLSB)

There is something I really dont really like about my proposal: I dont like having all business methods on the Session Facade. I guess it could grow and grow and grow... On the other hand, I need it to force all method call pass throw it in order to manage the client session.
 
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Holden Caulfield:

There is something I really dont really like about my proposal: I dont like having all business methods on the Session Facade. I guess it could grow and grow and grow... On the other hand, I need it to force all method call pass throw it in order to manage the client session.



Holden,

I am in the same situation. However, I designed a couple of independent business subsystems that do the actual work in the manner of BusinessDelegate->SessionFacade->ApplicationService->Persistence(CMP, DAO).
Those subsystems then implement the use cases where as the SFSB does the stateful stuff. You are right, that SFSB will have a good bunch of business methods since it is the single point of entry into the bunsiness-tier. However, think of the FrontController, that is also the single point of access to a web-client. So I think it shouldn't be that bad. What do you think?

D.
[ November 05, 2006: Message edited by: David Follow ]
 
Holden Caulfield
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Amazing, I have decided to implement the same "architecure" as you have described in you last post. It makes me feel better

.. think of the FrontController, that is also the single point of access to a web-client. So I think it shouldn't be that bad. What do you think?



Well, dont know. In my opinion the frontController is quite different. It is true that it is the single point of access, but on the other hand it has not as many methods as my BusinessDelegate. I was thinking about a FrontController who resolves dynamically to which RequestProccesor/ActionProcessor/ActionCommand deliver the processing staff (like the mainServlet of the PetStore) What do you think?

There is something for sure: The more I read, more doubts comes into my mind.

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

Originally posted by Holden Caulfield:
Hi Brian,

Client --> BusinessDelegate --> Service Locator --> Session Facade (SFSB) --> Application Service (SLSB)



Any reason to make Application Service as a SLSB?Why not just a POJO so that the business logic itself is not EJB dependent, more portable?

Thanks,
BR
[ November 06, 2006: Message edited by: Brian Smith ]
 
David Follow
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Brian Smith:

Any reason to make Application Service as a SLSB?Why not just a POJO so that the business logic itself is not EJB dependent, more portable?



Hi,

if you make them SLSB you can take advantage of bean pooling and other appserver features. Basically you are right, they could be simple POJOs. However, I decided to make them SLSB as well. You still can put your logic in POJOs after all.

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

Originally posted by Holden Caulfield:
[

Well, dont know. In my opinion the frontController is quite different. It is true that it is the single point of access, but on the other hand it has not as many methods as my BusinessDelegate. I was thinking about a FrontController who resolves dynamically to which RequestProccesor/ActionProcessor/ActionCommand deliver the processing staff (like the mainServlet of the PetStore) What do you think?



You are right. I think you have only thwo choices
a) live with a good bunch of BD methods for your controller
b) come up with something like a generic Event object that you pass into the controller that then knows what to do.

So far, I prefer a) since the amount of methods will be still acceptable. However, if more use cases come up the more methods you will have.

D.
 
Can't .... do .... plaid .... So I did this tiny ad instead:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic