Discussions

EJB design: Help on Business delegate and Session facade

  1. Help on Business delegate and Session facade (7 messages)

    Hi, I have read the core j2ee pattern book and have a little bit confuse about these 2 patterns.
    the book said :

    BD should has a one to one mapping to SF,
    where BD delegate the request to SF to execute the business object.

    So if BD JUST delegate request and has one to one mapping to SF, what point for us to have both BD and SF at the same time? We could just use BD to access business object, maybe via a Service locator to preform JNDI lookup. I am not sure about the function and value of SF.

    any help??

    Regards
  2. These patterns are easier to understand if you imagine that the BD is on the client side (servlet/swing) and the SF is on the server side. SF do all the work (deal with other sessions, use entity beans, send JMS messages... and so on) and BD just do a lookup on the SF and delegates the call. You don't want a client that does all the business work, that's why you create a SF, and you don't want a client to have JNDI lookup code, that's why you use a BD.

    DB can also be used to catch SF exception and transform them into other exceptions.

    Hope this helps.
  3. Business Delegate is to reduce coupling between client and business objects. One of the basic example is, if you use a method from business object in your clients, let say in 10 servlets, if the method signature changes on the business object, you have to change in all(10) your client places(ofcourse, IDE can easily refactor it, but it will be complicated if the project is very big). To avoid this, have a layer of classes/interfaces which have the methods corresponding to each business object.

    Session Facade is to reduce the number of network calls made from client to business objects. As you said, if you implement the business logic in your Business Delegate layer, you will be making multiple fine grained calls to your business objects to complete a Use Case. Network calls are expensive and must be reduced. So instead of implementing the business logic in clients, implement it in business object layer and send required data as a bundle(coarse grained).

    Hope this helps,
    Senthil.
  4. I can't thank u two more, it definitely made me cyrstal clear on these patterns !!!

    and can I ask for more help? ^^

    I use Tomcat as webcontainer and Struts as MVC framework, I know Struts has Action Servlet act as front controller, so the system would be:

    Action Servlet <--> Action(s) <--> BD <--> SF

    so my action should only keep only ONE instance of BD, as the BD should also keep only ONE instance of SF

    I would like to implement both BD and SF as Singleton, so they are all stateless. Then where and how to keep my session data??

    Also I know Stucts implement Action as Singleton and multi-thread /cache it. If my action keep a single instance of BD, which keep a single instance of SF, will all my Action, BD and SF be benifited in terms of multi-thread and caching by Tomcat??
    (I don't want my actions retrieve the instance of BD everytime they get a request from Action Servlet)

    I don't want to use stateless session bean now, but I want to leave my system capable to scale up to use session bean / ejb, would the above architecture suitable to scale up to Enterprise level??

    a little help would be appreciated

    Regards
  5. and Senthil, you said:
    "if the method signature changes on the business object, you have to change in all(10) your client places"

    I can't understand fully, in technical terms. My Action retrieve an instance of BD which retrieve an instance of SF. Then the BD should return an interface corresponding to a business object back to Action.
    Finally it is the Action to preform business call to the interface.
    So if the method sign. change, the interface will be change, the method call will also be changed, how can my Action don't need to modify ??

    Regards
  6. Loose coupling...[ Go to top ]

    To really abstract away dependencies between Action classes and SF Apis would be to provide setters for each parameter on BD. So if signature changes, probably you can handle them internally in the setters of BD - that is if the front end is not concerned about the signature change. Let's say the suignature change is to handle some other consumer's requirements not the current Action class. Or you can use soft interfaces to BD by taking in a HasMap or XML.
  7. It was my mistake, sorry. I meant to say, if you move methods across beans. One of the common ways of implementing BD is to combine both BD and Business Interface pattern. You can use the Business interface as your BD. They way we implemented is, create a XML file which contains Business interface name, JNDI name and Home class...etc And then create a delegate factory class, which reads the XML and lookup beans based on request and return business interface(Remote Object), which contains all the business methods.

    Thanks,
    Senthil.
  8. This is exacly what I plan to implement !
    However I am not using session bean right now, a XML file seems to complex

    So I will create a singleton final object which contains all business interface and string pair, Action just pick a business service from this object and send the String name to BD to create the remote interface, finally the interface is send back to action and execute against it

    If somedays later my application is scale up to Enterprise, using XML is the right choice then, ^^

    thank for help

    Regards