This discussion is archived
6 Replies Latest reply: Mar 7, 2013 1:42 AM by r035198x RSS

Business Delegate and Session Facade usage.

995008 Newbie
Currently Being Moderated
Hi guys.

I am new to JavaEE and I recently learnt the Business Delegate and Session Facade design patterns. The tutorials from Oracle did gave me a basic idea of what they are and why they are used, but the example didn't really answer all my questions. So I decided to use a real life scenario here and put my question in to it. Any help is appreciated.

Assume I want to create a search employee page for my company, the employees are categorized by his or her department and the province he or she is in. I have in the database a look up table for department and province. (as shown in the image below)

http://oi46.tinypic.com/idvpsl.jpg


So I create three JPA entities, one for each table. Now I am stuck with what is the proper way to design the session facade design pattern. I know that I will need the to access all three entities in my page. (to get the drop down list for Provinces and Departments, and to retrieve list of Employees based on the selection) So should I create a Stateless Session Bean as session facade to access all three JPA Entities or should I create three separate Stateless Session Bean to manage one Entity each?

I came up three component diagram in the below picture.
The first one has one Stateless Session Bean as session facade and manages all three Entities.
The second one has a session facade to manage the relationship between business objects such as ProvinceManagerEJB and DepartmentManagerEJB which will manage the corresponding Entities.
The last one has three Stateless Session Beans that will manage one Entity each, all three Stateless Session Beans can be looked up via the Business Delegate pattern.

http://oi46.tinypic.com/10pqets.jpg

Please let me know if any one of them is the proper way to use business delegate and session facade. or none of them is correct. (which I assume might happen)

Again, thank you so much for your help.

Cheers

Edited by: 992005 on 05-Mar-2013 18:15

Edited by: 992005 on 05-Mar-2013 18:17
  • 1. Re: Business Delegate and Session Facade usage.
    r035198x Pro
    Currently Being Moderated
    Well I can't access any of your diagrams from here so can't comment on them. For dividing the functionality into separate classes, think about

    1.) Quantity - Are there many enough service calls to require splitting up or will one application service class be enough? The size of the system is important here.
    2.) Are you duplicating logic in the services? e.g save person, delete person in one service and save department, delete department in another e.t.c is better factored into one service with save entity, delete entity calls because the JPA entity manager doesn't know about the type anyway and it's easier to apply common logic (e.g logging auditing) around the calls.
    3.) Will each service makes sense on it's own or do you always need the other functionality to completely describe the service? Here it is important not think about entities but about the business use cases. Process1Service is better than Entity1Service, Entity2Service ... EntitynService.Think granule of reuse = granule of release. Only split out individually reusable services. A good way to understand granules of reuse in your system is to think about (or start by writing) test cases for the functionality. Testable code is reusable code.
    4.) Will the services change together? At class level you would look at common closure principle (classes that change together should be packaged together). You can apply the closure to the methods as well. Make it easy for future developers to recognize dependent functionality by packaging it together.

    These are just general because in enterprise development requirements are king. You can chose to follow or discard any of these rules depending on your requirements as long you understand the impact of each decision.
  • 2. Re: Business Delegate and Session Facade usage.
    995008 Newbie
    Currently Being Moderated
    Thank you, I guess in this case, assuming there is no other process required in this project, a Session Bean that represent the search process will be the pick. It will access all three Entity Beans and manage the relationship between them.

    I have another question though, when using the Business Delegate pattern, is it common practice that a Business Delegate will only look up one EJB? It is not stated clearly in the tutorial and from all the example I've seen, only one EJB is looked up in all them.
  • 3. Re: Business Delegate and Session Facade usage.
    DarrylBurke Guru Moderator
    Currently Being Moderated
    Cross posted
    http://www.java-forums.org/enterprise-javabeans-ejb/69830-business-delegate-session-facade-usage.html

    db
  • 4. Re: Business Delegate and Session Facade usage.
    r035198x Pro
    Currently Being Moderated
    992005 wrote:
    I have another question though, when using the Business Delegate pattern, is it common practice that a Business Delegate will only look up one EJB? It is not stated clearly in the tutorial and from all the example I've seen, only one EJB is looked up in all them.
    Yes, typically a delegate will be for one service, hiding how the service is found and called and it is common that one service is implemented as one EJB. That doesn't mean you should do that for your project of course, as I said above, requirements are king. Remember also that not all business services are EJBs.
  • 5. Re: Business Delegate and Session Facade usage.
    gimbal2 Guru
    Currently Being Moderated
    r035198x wrote:
    Yes, typically a delegate will be for one service, hiding how the service is found and called and it is common that one service is implemented as one EJB. That doesn't mean you should do that for your project of course, as I said above, requirements are king. Remember also that not all business services are EJBs.
    Exception to that I employed myself: when you need to do nested transactions it works nicely to have a second "support" service in which you can stick methods that create their own private transactions, to do for example batching jobs. Bean Managed Transactions would make that easier to do within the same EJB, but I like to stick to container managed ones at all times and in my opinion it adheres to separation of concerns.
  • 6. Re: Business Delegate and Session Facade usage.
    r035198x Pro
    Currently Being Moderated
    Ya I have an EJB called OwnTransactionTaskProcessor with one execute method marked as REQUIRES_NEW and execute the tasks through command pattern.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points