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

Similar Messages

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, 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.

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

=== SESSION FACADE v/s BUSINESS DELEGATE ===

Hi
Can anyone help me with my design here - I am not sure whether to use a Session Facade or a Business Delegate in the following scenario:
[Our application is pure J2EE and does not use EJBs]
PRESENTATION-TIER
I have a Command and Control strategy employed in my presentation tier where requests are intercepted by a controller and processed by helpers delegating to appropriate commands and dispatch appropriate responses.
PRESENTATION-TIER - COMMANDS
The Commands will invoke appropriate Business Methods in the business tier to retrieve data (mostly).
BUSINESS-TIER
Now - most of my business methods use the DAO pattern to retrieve data and are effectively dealing with Data Beans (Value Object beans) - passing them back to commands.
I can clearly see the use of a generic Interface at the Business tier - i.e., rather than expose the Buiness Methods direcly leading to increased coupling between presentation and business tiers.
BUT THE CONFUSING PART IS - DO I USE A SESSION FACADE OR A BUSINESS DELEGATE TO INTERFACE WITH MY COMMANDS??? What is the difference? I have looked at Sun's J2EE blueprint and cant make out the clear cut difference between the two.
Can anyone help?
thanks
Aswin

I agree with you, Business delegate and Session facade are quite alike.
I believe that you could use the Business delegate pattern as a facade. Possibly, you could argue that the Business delegate is an extension of the Session facade pattern. However, I think that SUN thinks that a Business delegate should be a singleton while a Session facade is a session EJB. My firm belief is that you could create a business delegate that is a session EJB instead.
But, you could also use both pattern as some one else suggested.
In your case when you do not use EJBs, I would suggest that you use a facade which could be design like a business delegate. However, as there aren't any EJBs, you will not need a service locator. In this way, you will have a design that can be extended (without any impact on the the presentation tier) to use EJBs in the future.
Remember, SUN's core J2EE patterns assume that you use EJBs. If you don't, they have to be adapter a little bit.

Is the Business Delegate a Singleton?

I use the Business Delegate to hide the implementation details (lookup, EJB, etc.) of the Business Service from the client. The same Business Delegate is used in many different places in the client. Now I would like to avoid to pass around the object reference of the Business Delegate in the client.
I wonder if the Business Delegate should be a Singleton. Is this reasonable?
Thank you.

excellent, thanks for your comments.
so to the orginal question, would you agree with the comments below?
The pattern catalog describes the business delegate as containing an instance of an EJBObject where as the service locator can optionally cache an EJBHome object. The former avoids repeated JNDI lookups and creating an EJB whilst the later just avoids repeated JNDI lookups.
Using this strategy, the delegate looks up the home interface and creates an instance of an EJB on creation; it has a one-to-one relationship with it. You don�t really want the delegate to have to create an EJB from the home interface in every method so it should therefore contain an instance member.
This all means the delegate can�t be a singleton, it can't share that EJBObject with multiple clients.

Must not use Java 1.7 when using E-Business Suite

This notification is being posted at the request of Oracle Corporation
All E-Business Suite desktop administrators must disable the JRE Auto-Update for their end users immediately to stop it updating to Java 1.7.
URGENT BULLETIN: Disable JRE Auto-Update for All E-Business Suite End-Users.
The following link from my fellow blogger Steve Chan explains more: https://blogs.oracle.com/stevenChan/entry/bulletin_disable_jre_auto_update
To disable automatic updates, you do this in the Java Control Panel using this workflow:
1. From the Windows Start button launch Control Panel
2. Double-click on the Java icon
3. On the Update tab, uncheck the box that says Check for updates automatically.
4. Click the OK button to complete
So why is this required?If you have Auto-Update enabled, your JRE 1.6 version will be updated to JRE 7. This may happen as early as July 3, 2012. This will definitely happen after Sept. 7, 2012, after the release of 1.6.0_35 (6u35).
Oracle Forms is not compatible with JRE 7 yet. JRE 7 has not been certified with Oracle E-Business Suite yet. Oracle E-Business Suite functionality based on Forms -- e.g. Financials -- will stop working if you upgrade to JRE 7.
If you have already upgraded to 1.7 but already have 1.6 you do not need to uninstall 1.7. You can just tell the system which one to use. You do this using this workflow:
1. From the Windows Start button launch Control Panel
2. Double-click on the Java icon
3. On ths Java tab, click the View button
4. Uncheck the Enabled box against 1.7 and check the box against 1.6
5. Click the OK button to complete
There is also a known issue with WebLogic 10.3.6 and JDK 1.7 and you must use JDK 1.6 for that. I will be posting on my blog shortly about this issue.
Seems to me therefore that until further notice, even for Discoverer, but definitely for E-Business Suite that you must stay on Java 1.6.

Hi Jerre
I hear your concern and when I heard about the issues with E-Business Suite and Java 7 I was horrified. After all, we kind of got used to this when Sun and Oracle were separate but now that Oracle own both you would think these problems would have gone away.
I'm not an insider to the problems with E-Business Suite and I urge anyone that is using it to wait for Oracle's solution and /or follow the great blog owned by Steven Chan which is dedicated to EBS. I took another look a few minutes ago and the advice is still the same - to NOT upgrade to Java 7 if you have E-Business Suite you need to roll back to Java 6 and turn off the automatic updates.
As for Discoverer, I have 10g clients whose workstations were automatically upgraded to Java 7 and had their applications fail. I have always advised my clients to turn off automatic updating of Java and keep their client Java at the same level as the server. There were serious issues here in the past but those were when Sun and Oracle were separate. We had compatibility issues when servers were on Java 5 and workstations upgraded to Java 6 and it looks like we may be having the same problems between Java 6 and Java 7.
I tend to notice far fewer problems in corporate environments when IT departments manage the versions of Java on their servers and workstations rather than let it auto upgrade.
It was me who uncovered a bug in 11.1.1.6 where the Java 7 JDK was not working. Since then Oracle issued a Discoverer patch to allow it to work with Java 7 so for users of 11.1.1.6 you should be OK now to go ahead and allow Java to upgrade. Mind you, if the same workstations need to connect to Forms or E-Business Suite the advice given earlier to not upgrade stilll applies - that is unless someone knows otherwise.
Best wishes
Michael

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

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

Business Delegate & Session Facade

1 What is the need of Business delegate? For controlling the interactions between the presentation tier and business tier, session facade pattern can be used.
2 Can a session facade have all the facade related methods. (i.e. entire application has only one session facade). In the pattern documentation, it is stated as this stratergy inefficient. Why is so?

1 What is the need of Business delegate? The delegate provides a client-side business abstraction and acts as a proxy for the business service. Note that it is a proxy, not a facade. In other words, it is a "stand-in" for the biz service, but it is not aggregating several method invocations into one and controlling the processing flow. So, the delegate is not providing a higher-level interface to some underlying system, as would a facade.
So what's the need, if it's just a proxy? Obviously, it adds a layer, so one must consider its benefits versus the drawback of writing, maintaining, and interacting with this extra layer. In a sophisticated system, the benefits are many and will usually outweigh the drawbacks. Following are some of the benefits of using a delegate in the web container as an access point for invocations to the business tier:
- It hides the underlying implementation details of the business service (ie: lookup, creation, access details of EJB...The delegate may use the Service Locator pattern to achieve this goal).
- The delegate translates exceptions as necessary. Service-level exceptions, such as java.rmi.Remote can be intercepted by the delegate and translated into application exceptions. This also helps shield web container clients, for example, from EJB and network-related implementation details, which they should not need to worry about.
- The delegate can attempt retries/recovery efforts transparent to its clients, such that this code can be localized and reused, instead of being duplicated in numerous clients.
- The delegate can also manage a cache of resources/results, limiting unecessary remote roundtrips
- The delegate can be used as a control point for multi-threaded access into the business tier. For example, stateful beans are not to be invoked by multiple client threads simultaneously. The delegate can serialize access, or, as mentioned above, handle exceptions/retries, as necessary.
For
controlling the interactions between the presentation
tier and business tier, session facade pattern can be
used.If you decide to use a delegate in your system, based on considering its benefits, as described above, then you'll typically create a one-to-one mapping between a delegate and a session facade. The delegate is not controlling the processing flow per se, but rather serving as a single access point and proxy as described above. The facade acts as a controller, though, aggregating the interfaces of underlying components and subsystems into a higher-level interface. If you find that your using the delegate more as a facade, we recommend pushing this control code from the web container (where the delegate lives) back to the session bean in the ejb container, so that the logic can be reused across clients.
>
2 Can a session facade have all the facade related
methods. (i.e. entire application has only one session
facade). In the pattern documentation, it is stated
as this stratergy inefficient. Why is so?Having a single facade for the entire system would prove to be quite a maintenance and manageability headache for a non-trivial application. Imagine that every time something changes in any subsystem of the service layer, developers are all making changes to the same file and the same class...Not desirable and not very elegant. At the same time, one does not want to go the other way and create too many facades by having a one-to-one mapping of session facades to use cases, for example. We recommend aggregating a group of related interactions into a session facade, so that it provides highly course-grained access and control to underlying components.
Thanks,
Dan

Business Delegate (remove session bean)

HI all,
I followed the code example of Business Delegate pattern
as described in java.sun.com site.
Everything is well, but I have only a doubt:
in Business Delegate's constructor the Business Delegate object
create the session bean reference that it will use.
I don't see any call to session.remove() method.
Is it a forgetfulness or there is no real need to call the remove method ?
May developers rely on the Application Server for bean's removal ?
(removal for Statfeul or pooling for Stateless)
Many thanks in advance
Moreno

Yes, it's fine to rely on the ejb container to remove both stateful session bean and stateless session bean resources. Most ejb containers define a timeout period after which stateful session beans that have not been accessed will be removed. Similar settings typically control the amount of time a stateless session bean instance will be pooled within the container.
If you'd like more predictable, programmatic control for stateful session bean removal, you can explicitly call EJBObject.remove(). In that case, the ejb container is required to call ejbRemove on the corresponding stateful session bean, assuming it hasn't already been removed. For stateless session beans, EJBObject.remove() is merely a hint to the container, and might not result in any specific action on the pooled instances. Hope this helps.
--ken

Calling business delegate object from client

Hi guys,
I want to know how can I use Business Delegate Pattern in my client program(e.g JSP for that matter). I would really be thankful if u plz illustrate ur point thru code.
One more doubt....
Can a Normal Java Bean be a Business Delegate Object??
What I am trying to say is,
In a typical J2EE application architecture which uses MVC design pattern as follows:
(JSP--->Java Bean--->Session Bean--->Entity Bean-->DB)
Can I say the java bean used above is acting as a "Business Delegate Object", coz business delegate object lets u to decouple the presentation and business tier, which is what the above java bean is also doing??? Any comments on this????
Thanx in Advance
Jam

Hi buddy,
Tx for ur response.So as per to the architecture as i have mentioned in my first query(i.e JSP-->Java Bean--->Session Bean--->>Entity Bean-->DB)
Sould i introduce a Business Delegate Object somewhere in between JavaBean and Session Bean. This business delegate object will be looking for the seesion facade used above, and java bean will be acting as a client for Business Delegate Object. Am i correct here???? Plz clarify.
Thanx n Regards
Jam

EJB 3.x business delegate & service locater

Hi all
are business delegate & service locater patterns still relevant when considering EJB 3.x? Why or why not?
Does dependency inversion replaces service locater? was there dependency inversion in EJB 2.x??
Thx a lot

Hello,
Business Delegate is still relevant while using EJB 3.0
Business Delegate reduces coupling between presentation-tier clients and business services, that does not change with EJB 3.0.
However, Service Locator can be avoided by the Dependency injection provided by java EE5.
But, remember, Dependency injection works only for object managed by the container, so, Service locator can yet be useful in ejb 3.0.
Regards,
Sebastien Degardin

Configure CRS2008 to using AD and Kerberos with Java application servers.

Hi All,
I have configure CRS2008 to using AD and Kerberos with Java application servers. Domain Controller is installed on W2K3 Server. In addition, CRS2008 is installed on another W2k3 Server.
I have create service account in domain controller: CMSACC
I have create two user account: CRuser1 and CRuser2
I have create domain group: CRSGroup
After I had run the setspn in domain controller,I got the message at below:
Registered ServicePrincipalNames for CN=CMSACC, OU=TEST, DC=BD, DC=com:
    BOBJCentralMS/BDMGTSRV.BD.com
CMC Setting:
AD Administration Name: BD\administrator
Default AD Domain: BD.com
Add AD Group(Domain\Group): secWinAD:CN=CRSGroup,OU=TEST,D=BD,DC=com
Service principal name:BOBJCentralMS/CMSACCatBD.com
I have create a WINNT folder in root directory.Moreover and save bcsLognin.conf and Krb5.ini at here.
bscLogin.conf:
com.businessobjects.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required;
krb5.ini:
[libdefaults]
default_realm = BD.com
dns_lookup_kdc = true
dns_lookup_realm = true
[realms]
forwardable = true
BD.com = {
default_domain = BD.com
kdc = BDMGTSRV.BD.com
I have tested the Kerberos,using kinit CMSACCatBD.com password, and got error message at below:
Exception: krb_error 41 Message stream modified (41) Message stream modified
KrbException: Message stream modified (41)
        at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:53)
        at sun.security.krb5.KrbAsRep.<init>(KrbAsRep.java:96)
        at sun.security.krb5.KrbAsRep.getReply(KrbAsRep.java:486)
     at sun.security.krb5.KrbAsRep.getReply(KrbAsRep.java:444)
     at sun.security.krb5.internal.tools.Kinit.sendASRequest(Kinit.java:310)
     at sun.security.krb5.internal.tools.Kinit.<init>(Kinit.java:259)
     at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:106)
My problem is failed to logon CMC and infoview and got error message at below:
Account Information Not Recognized: Active Directory Authentication failed to log you on. Please contact your system administrator to make sure you are a member of a valid mapped group and try again. If you are not a member of the default domain, enter your user name as UserNameatDNS_DomainName, and then try again.
Actually, I am sucessful to logon Business View manager with CRuser1. However, I fail to logon CMC and infoview and got the above error. Have you any suggestion to solve this problem?
Ken.

if you can logon with client tools then that should be an indication that the service account running the CMS IS working! Good news.
So the problem is likely with the java portion (krb5/bsclogin or java options)
If the files are in c:\winnt\ (if not copy them there) and perform c:\program files\business objects\javasdk\bin\kinit username
then enter and password/enter again
Probably get the same message. To note in your krb5.ini all domain info must be in CAPS (the .com appears to be in lower case)
kinit works with just the krb5.ini, java SDK and AD (removing BO config and the service account from the picture). Once that works if your java options are specified properly you should be able to login to CMC/infoview.
also 1 last point. Add udp_preference_limit = 1 to the krb5 lib defaults section
libdefaults
default_realm = BD.com
dns_lookup_kdc = true
dns_lookup_realm = true
udp_preference_limit = 1
Regards,
Tim

Use of Business delegates in Java?

Similar Messages

Maybe you are looking for