wood burning stoves 2.0*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Business Delegate, Session Facade and Application Service Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Business Delegate, Session Facade and Application Service" Watch "Business Delegate, Session Facade and Application Service" New topic
Author

Business Delegate, Session Facade and Application Service

Brian Smith
Ranch Hand

Joined: Oct 26, 2002
Posts: 232
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
Holden Caulfield
Greenhorn

Joined: Nov 04, 2006
Posts: 4
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.
David Follow
Ranch Hand

Joined: Oct 16, 2001
Posts: 223
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 ]

SCJP, SCEA
Holden Caulfield
Greenhorn

Joined: Nov 04, 2006
Posts: 4
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

Joined: Oct 26, 2002
Posts: 232
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

Joined: Oct 16, 2001
Posts: 223
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

Joined: Oct 16, 2001
Posts: 223
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Business Delegate, Session Facade and Application Service