Business delegate

I hope this topic isn't completely worn out ... I tried looking a bit for
relevant info here.
I'm looking at mixing and matching an EJB deployment with local and remote
interfaces. The Business Delegate pattern seems the way to go. Here, we can
encapsulate and logic around the selection of a remote or local
implementation for example (and among other things).
The rub seems that we would like to define an interface that mostly
defines our basic business contract. Of course (or maybe not - I know I will
get some dissention here), this interface should not throw RemoteException.
We can have our remote interface extend this interface and define the
methods WITH a throws RemoteException clause. Our local interface may just
extend this one. But, the container won't let us do this. It wants our
interface to throw Remote.
I tried defining a new EJB, as opposed to the one EJB deployed with both
interfaces - that didn't work. I've headr it suggested that the uber
interface be defined with a throws Exception clause, but this really breaks
the contract.
I think you get the picture. I'm sure that by now there are some good
solutions to this. I am interested to hear them.
Thanks for your input.

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.

Similar Messages

  • Business Delegate and Session Facade

    Business Delegate as well as Session Facade are used to reduce coupling between presentation-tier clients and business services.
    Could someone provide the key differences between these two patterns.
    And one more, is Session Facade applicable(can be implemented) only to Enterprise Java Beans? Or even a POJO can be a Session Facade
    Thanks in Advance

    Business Delegate as well as Session Facade are used
    to reduce coupling between presentation-tier clients
    and business services.
    Yes. And also in EJB to overcome some of the deficiencies in distributed architectures.
    Could someone provide the key differences between
    these two patterns.
    Business Delegate is used by a client whereas the Session Facade is used to abstract a business service.
    And one more, is Session Facade applicable(can be
    implemented) only to Enterprise Java Beans? Or even a
    POJO can be a Session Facade
    Yes. Think of a session facade as your 'easy' or 'high-level' API. Your actual business tier may have its own 'low-level' API that callers should not have to interact with or understand.
    Thanks in AdvanceYou're welcome.
    - Saish

  • Business delegate and Session facade design patterns

    Does any one tell me, what is the difference between business delegate and session facade design patterns.

    1. Session Facade decouples client code from Entity beans introducing session bean as a middle layer while Business Delegate decouples client code from EJB layer ( Session beans).
    2. SF reduces network overhead while BD reduces maintenance overhead.
    3. In SF any change in Session bean would make client code change.
    While in DB client is totally separate from Session bean because BD layer insulate client from Session beans(EJB layer).
    3. In only SF scenario, Client coder has to know about EJB programming but BD pattern no EJB specialization needed.
    4.SF emphasizes on separation of Verb, Noun scenario while BD emphasizes on separation of client(presentable) and EJB layer.
    Anybody pls suggest more differences ?

  • Use of Business delegates in Java?

    Hi,
    Could anyone please tell me the advantages/uses of using Business Delegates in Java?
    Regards
    Ram

    Could anyone please tell me the advantages/uses of
    using Business Delegates in Java?Where's the emphasis? On "Java" or on "Business Delegates"?
    http://java.sun.com/blueprints/patterns/BusinessDelegate.html

  • Business Delegate Pattern?

    What is the real use of Business Delegate pattern in a J2EE architecture design?
    I know it is to decouple the Presentation and Business Logic tiers. But all I can see is it just contains one method which basically accepts data (say Value Object) from Presentation tier (in an example I am looking, it is a Command class) in a method and the method in turn just calls a Session Facade Bean from the Model tier. So, why do we need a Business Delegate class in this scenario? And what are the drawbacks of calling the Session Facade Bean directly from the Command class?
    Thanks for helping me understand it better.
    Rgds,
    Tappori

    Business delegate typically is a presentation-tier object. It serves to shield the presentation-tier from business-tier implementation details. A Business Delegate can encapsulate business services from one or many Session Facade and could also delegate processing to web services as well.
    Here are some fancy links that talk about the Business Delegate guy-
    http://forum.java.sun.com/thread.jsp?forum=425&thread=535855
    http://forum.java.sun.com/thread.jsp?forum=425&thread=548634
    http://forum.java.sun.com/thread.jsp?forum=425&thread=523520
    http://forum.java.sun.com/thread.jsp?forum=425&thread=495578
    And what are the drawbacks of calling the Session Facade Bean directly from the Command class?You tie the presenation-tier object (Command) to business-tier implementation. The Command class should not have lookup code in it and it should not know that it is calling a remote object. Say you want to replace the EJB implementation with the XYZ implementation. Would you then have to recompile all of the Command classes and/or subclasses?

  • Business Delegate and Session Facade Pattern

    Hi!
    The only way to use the Session Facade Pattern, is if I use EJB for Persistence.
    Is valid to do this?:
    I use Ejb for simple update, insert querys. From my business delegate I call the Session Facade Layer, and from this I invoque Entyties for persistence.
    But if I have complex querys, is correct to make PL SQL Procedures and do the following:
    From my business delegate I call to the Dao layer, and from this via JDBC I call the Procedure.
    Please explain me the best form to do this, having complex querys for reporting and simple querys for inserts/update.
    Is valid to combine the use of CMP (for simple persistence cases), BMP (for complex persistence cases), and JDBC for complex select querys with multiple result rows.
    Thanks!!

    It depends on your design goals. One of the forces driving the use of patterns is the desire to tier an application and abstract the internals of each tier away from the other tiers. One (normal) benefit of this methodology is that the application should become more portable. Now, if you are using PL/SQL, BMP and CMP, you are mixing and matching portable versus proprietary. This is okay. But you should abstract away whether you are using PL/SQL, BMP or CMP from the business layer (or domain model). Ideally, you could completely swap database technologies (say from relational to object) and only have to re-write your integration tier (your DAO's).
    Session facade is simply a glorified Facade pattern. It abstracts the lower-level details of what you are persisting and instead forces you to think in terms of objects. You can use a facade without even remotely touching EJB's. It just so happens that, historically, EJB containers made a mess out of scalability when it came to entity beans. The "session" facade refers to a facade pattern implemented in session beans (that have fewer scalability problems) communicating with the entity beans which do have scalability problems.
    So... to make a long story short, use whatever persistence mechanism you desire. Remember that you should be able to completely switch your persistent store from one type or another and simply re-write your DAO's (or CMP deployment descriptors). Using a facade pattern can help towards this end, but don't make it a straightjacket.
    - Saish
    "My karma ran over your dogma." - Anon

  • Business Delegate and Session Facade usage.

    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

    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.

  • Business Delegate / Session Facade interaction questions

    I understand the concept and the benefits of a business delegate "front-ending" a session facade. I am hoping that someone can answer the following questions:
    Is it acceptable if a business delegate were to front-end more than one session facade in order to create a more unified service. For example is it ok to create one business delegate that provides Account Inquiry and Maintenance functionality and behind the scenes it talks to an AccounInquiry Session Facade and AccountMaintenance Session Facade?
    We are looking at a designing a Account Inquiry business delegate. It will return an AccountProfile business object. A behaviour of the AccountProfile object will be update capability (i.e. update account status, modify balance, etc.). Considering that the business object is a "business tier" component, is it ok fif it were to talk directly to an Account Update Session Facade or instead should it use a business delegate which in turn will call the session facade?

    I understand the concept and the benefits of a
    business delegate "front-ending" a session facade. I
    am hoping that someone can answer the following
    questions:
    Is it acceptable if a business delegate were to
    front-end more than one session facade in order to
    create a more unified service. For example is it ok to
    create one business delegate that provides Account
    Inquiry and Maintenance functionality and behind the
    scenes it talks to an AccounInquiry Session Facade and
    AccountMaintenance Session Facade? This is a feasible solution. As long as you have 1:2 ratio or a ratio which is very less, it is fine. But one of the intents for having this pattern is also to make the client's life easier. If the client who's using your delegate is someone else, sitting else where, he/she would be wondering about the reason for a single class like AccountInquiryMaintenanceDelegate providing two different functionalities. So, this has to be kept in mind before coming up with a single class.
    We are looking at a designing a Account Inquiry
    business delegate. It will return an AccountProfile
    business object. A behaviour of the AccountProfile
    object will be update capability (i.e. update account
    status, modify balance, etc.). Considering that the
    business object is a "business tier" component, is it
    ok fif "it"what does "it" mean here?? Did you mean the 'AccountProfile' bussiness object?? or the AccountInquiry business delegate??
    were to talk directly to an Account Update
    Session Facade or instead should it use a business
    delegate which in turn will call the session facade?
    HTH,
    Kalyan

  • Business Delegate, Session Facade or both?

    Hi,
    I'm having some problems with figuring out the point of using both Business Delegate (BD) and Session Facade (SF). As far as I can see, you often have a 1-1 mapping between the BD and SF, so why not use the SF directly?
    Here's my scenario. I have a web application that uses WebWork for presentation and pageflow, a session facade implemented using an ejb, which aggregates calls to the businness objects into "business rule"-methods and business objects implemented using plain java objects. Is there really any need to have a business delegate here? I might as well use the session facade directly from the webwork actions? Or..?
    Any suggestions? Am I far off? ;-)

    As far as I can see, you often have a 1-1 mapping between the BD and SF, so why not use the SFYou can have one Business Delegate encapsulate all of the business methods that are exposed by one or more Session Facades. The benefit here is that you protect the web component from any details of the business tier. e.g. your business tier has five session facades and the web tier has a single Business Delegate. The BD can be extended to call web services as well.
    Here's my scenario. I have a web application that uses
    WebWork for presentation and pageflow, a session
    facade implemented using an ejb, which aggregates
    calls to the businness objects into "business
    rule"-methods and business objects implemented using
    plain java objects. Say you eliminate the EJB implementation. What effect will this have on the web tier objects? The Business Delegate will enable you to easily replace the business implementation with little impact on the web components.

  • Difference between session facade and business delegate patterns

    Hi,
    How the session facade and business delegate patterns differ from each other, as both of them have similar and almost same forces to be addressed.
    Please address.
    Satya.

    BTW, in J2EE Core patterns :
    When the Business Delegate is udes with a Session Facade, typically there is a one-to-one relationship between the two. This one-to-one relationship exists because logic that might have been encapsulated in a Business Delegate relating to its interaction with multiple business services (creating a one-to-many relationship) will often be factored back into a Session Facade.[I/]

  • Difference between Session Facade and Business Delegate??

    Hello,
    I am currently working on design patterns and I am confused what the difference is between the Session Facade and Business Delegate pattern. They look identical.
    What's the difference?
    Balteo.

    We implement Business Delegators (BD) as follows:
    1. The client always talks to the BD.
    2. The BD then talks to either our Session Facade, Session EJB, or Java Class, etc, etc directly.
    This allows the client end code to never change whilst allowing our BD to swap between different providers of the service we require.
    It's the good 'ole "layer of indirection" thingy.

  • Difference between Session Facade and Business Delegate design patterns

    Can someone tell me the differences between Session Facade and Business Delegate design patterns

    1. Session Facade decouples client code from Entity beans introducing session bean as a middle layer while Business Delegate decouples client code from EJB layer ( Session beans).
    2. SF reduces network overhead while BD reduces maintenance overhead.
    3. In SF any change in Session bean would make client code change.
    While in DB client is totally separate from Session bean because BD layer insulate client from Session beans(EJB layer).
    3. In only SF scenario, Client coder has to know about EJB programming but BD pattern no EJB specialization needed.
    4.SF emphasizes on separation of Verb, Noun scenario while BD emphasizes on separation of client(presentable) and EJB layer.
    Anybody pls suggest more differences ?

  • Session Facade and Business Delegate Pattern

    Hi!
    The only way to use the Session Facade Pattern, is if I use EJB for Persistence.
    Is valid to do this?:
    I use Ejb for simple update, insert querys. From my business delegate I call the Session Facade Layer, and from this I invoque Entyties for persistence.
    But if I have complex querys, is correct to make PL SQL Procedures and do the following:
    From my business delegate I call to the Dao layer, and from this via JDBC I call the Procedure.
    Please explain me the best form to do this, having complex querys for reporting and simple querys for inserts/update.
    Is valid to combine the use of CMP (for simple persistence cases), BMP (for complex persistence cases), and JDBC for complex select querys with multiple result rows.
    Thanks!!

    The session facade is borrowed from the facade pattern, so you could have a facade to almost anything.
    A session facade is usually against other beans...for example if you
    (Not deployed as CMR)
    1. Address bean
    2. Phone Bean
    3. Customer bean
    as entity beans then you can build a session facade such as
    CustomerFacadeBean which will CreateReadUpdateDelete(CRUD) address and phone as well when a customer is CRUD ed.
    In your case you said you have very complex sql's so one way would be
    Business Delegate -> Session Facade -> (Bean Managed) Entity Bean -> DataAccessObject.
    If you think this is a overkill then, write a custom pattern such as DataDelegate
    DataDelegate -> (Bean Managed) Entity Bean -> DataAccessObject.
    In the above scenario you should be quite sure that the system will not evolve into a case mentioned above such as when customer is deleted a phone and address object are also thrown away.
    You said this scenario
    Business Delegate -> DAO..
    I don't think this is a good idea because, a business delegate is a proxy against business objects....and usualy in J2EE business objects are session beans. Entity and DAO objects are data objects not business ones.
    Besides if you do the above scenario you will end up wiring all the transactions, etc etc in your DAO which is not a good idea.
    Although you could use BusinesDelegates against entity beans it will lead to a misnomer.

  • Diferences between Business Delegate and Session Facade

    Hi, I've been programming with java for a long time now, but recently decided to formally studing the J2EE patterns. By now I have the intuition of many of them but in paper looks a little confusing. Let me ask you what is a clear diference between Business Delegate and Session Facade.
    For me, exposing interfaces, hiding implementations and masking the complex interactions in the back are common factors in these patterns, could you please help me to identify diferences?

    There are more subtle differences, but the basic gyst is that the Business Delegate is used on the client/presentation tier. The Session Facade is used on the server/service tier. The Business Delegate typically performs a lookup of the SessionFacade which in turn fronts a service method (EJB or otherwise). The Business Delegate pattern is typically associated with J2EE remoting and its shortcomings.
    - Saish

  • Business delegate to servlet

    I have a business delegate that delegates to a servlet from outside the
              servlet container. For the actual servlet interaction, I'm using basically
              URLConnection connection = ,,,
              connection.openConnection()
              readResponse
              and then appropriate connection closing facilities.
              This seems to work fine on some version of the Sun JVM (e.g. 1.3.1), but not
              on others (e.g. 1.3.1x and 1.4).
              This question is more about a specific pattern implementation (involving
              servlets) than the pattern itself.
              Thanks in advance.
              -- Jay
              

    "Jay" == Jay Baker <[email protected]> writes:
                        Jay> I have a business delegate that delegates to a servlet from outside the
              Jay> servlet container. For the actual servlet interaction, I'm using basically
              Jay> ...
              Jay> URLConnection connection = ,,,
              Jay> connection.openConnection()
              Jay> readResponse
              Jay> and then appropriate connection closing facilities.
              Jay> This seems to work fine on some version of the Sun JVM (e.g. 1.3.1), but not
              Jay> on others (e.g. 1.3.1x and 1.4).
              Jay> This question is more about a specific pattern implementation (involving
              Jay> servlets) than the pattern itself.
              How can anyone help you if you don't give any indication of what the symptom
              is?
              ===================================================================
              David M. Karr ; Java/J2EE/XML/Unix/C++
              [email protected] ; SCJP; SCWCD
              

Maybe you are looking for