Implement business delegate as a singleton.

Anyone have any comments regarding implementing the bussiness delegate
as a singleton? I currently have something like this.
public class ClientUserManager {
public ClientUserManager() {
public void deleteUser(Long userid) throws RemoteException,
CreateException {
UserManagerHome umh =
(UserManagerHome)EJBHomeFactory.getInstance().getBeanHome(Constants.USERMANAGER_CLASS,
Constants.USERMANAGER_JNDI);
UserManager um = umh.create();
um.deleteUser(userid);
If I change this to a singleton I could peform the Homelookup and
create in the constructor? Any problems with concurrency?

Ophir,
I ran into this while testing, are you sure your started the oc4j and it is still running .. I remember some persistence issue, with the IP addr, hostname .. so I needed to clear the persistence directory in j2ee/home to have the container starting up.
thx clemens

Similar Messages

Business Delegate - best way to do it?

First of all I have to say that I'm using local interfaces so client and SLSB EJB are in the same JVM.
I would like to implement business delegate to make abstraction in case something changes later.
1. Does BD contains local interface to EJB as instance variable or something else?
2. My client is web based so should I keep BD in HttpSession to prevent creating BD for each method call or implement some other pattern? If so, which one do you recommend?
I would just like to hear from you guys how to implement so I wouldn't speend to much time on creating BD or EJB.

This is the normal procedure:
When you use the LiveUpdate DOS option a Windows Format Disk dialog pops up. Don't check any options (especially the system disk one). When the format is complete exit the dialog. LiveUpdate will copy files to the floppy.
To flash, put the floppy in the drive and reboot the computer. A freeware version of DOS will boot, create a ram drive, copy the flash file and bios image to the ram drive, and then execute the flash file.
You will be prompted to OK proceeding. If you do, the bios is erased, the new image is copied and then checked. A message will then be displayed that you can reboot the computer. Pop the disk out and press Ctrl Alt Delete.
When the computer reboots, press the Delete key, go into the bios and check/reset all settings.

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.

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

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.

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

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.

Business Delegate pattern - need some advice

Hi. First let me apologize for the long post. I could see no other way. I�m building a system that quite large and I need some advice. The system is a type of transaction system, let�s suppose a shopping cart. I�m using struts taglibs and tiles for presentation, struts proper for controller, and POJOs for business logic. Also I�m using OJB for my data tier.
Now I�ve been reading Pro Jakarta Struts (Apress), which BTW is a recommended read to anyone with novice experience in struts and related technologies. I�ve assimilated most of the techniques and patterns described in the book, and most of them make sense to me. However, I�ve hit a snag while reading the Business Delegate and Service Locator patterns.
The way I had though of building my application before reading the book, was to have a wrapper class, such as the following:
public class ShoppingCart {
private IAuthenticationService authenticationService;
private ITransactionService transactionService;
public ShoppingCart() {
     authenticationService = new DBAuthenticationService();
     authenticationService = new DBTransactionService();
public login(String username, String password) {
     String sessionToken = authenticationService.logon(username, password);
     return sessionToken;
private boolean isValidUser(sessionToken) {
     bolean validUser = authenticationService.isValidUser(sessionToken);
     return validUser;
public performTransaction(sessionToken, TransactionVO) {
     if (!isValidUser(sessionToken) {
          throw new AuthenticationException();
     transcationService.performTransaction(TransactionVO);
public editPreferences(sessionToken, PreferencesVO) {
     if (!isValidUser(sessionToken) {
          throw new AuthenticationException();
     authenticationService.performTransaction(PreferencesVO);
}My idea was that my wrapper class would isolate all the business logic and could perform login service in case my application was ever to be used with other presentation layer than struts (standalone client, web services). However I believe that this overlaps the Business Delegate pattern and maybe even totally implements it. The way I understand the code I�m reading in the book, they suggest having a BD for each major service such as AuthenticationServiceBD, TransactionServiceBD, etc� However this would break my single point of entry for authenticating users. I really need some advice on my design and how it fits with the BD and SL patterns (or others). I would also like to know what you think/recommend of my authentication strategy.
thanks in advance
Raphael

Thanks for your reply. This however, I understood. My concern is regarding my application in regards to business delegate pattern. You see I have this class (simplified for clarity):
public class ShoppingCart {
   private ILoginService ls = new DBLoginService();
   private ITransactionService ts = new DBTransService();
   // and so on for all services I offer.
   // then I mirror all the calls of my private interfaces
   // and pass them through internally
   public String sessionToken login(String username, String password) {
        ls.login(username, password);
   public boolean addToCart(sessionToken, itemNo) {
        // check session
        ts.addToCart(sessionToken, itemNo);
   // and so on
}Multiple questions for this one:
1) Am I not already implementing the Business Delegate pattern with my ShoppingCart class since all interfaces are private and all calls are mirrored from the wrapper class (ShoppingCart) to the private interfaces? All services are implemented as POJOs and I am not using JNDI at the present so I don't use the ServiceLocator pattern.
2) I store a reference to the wrapper class (ShoppingCart) in the ServletContext so I can grab it from my Action classes. What do you think of this approach?
3) How many BDs should an application contain. In my case I use just one. What is the advantage of using more?
4) I create my own session tokens in case I ever want to use to business code in a non-web applications where sessions are not available readily. This brings about the problem that I can't pass the interfaces directly to the Action classes because the login session needs to be checked before any calls to services. So all methods include a sessionToken parameter which I use to check the session. This way, if I want to expose some of the services through web services, I can still use a login. What do you think of this approach.
5) Any other remarks are very welcome...
I really need help with this from an experienced programmer. Most things I can handle on my own but with this type of design issue, books just don't cut it. I need experience. I would really apreciate some feedback.
Raphael
ps: I would give all my Duke dollars for this (I only have 30), but I'm not sure how. If you want them I can create a dummy question and give them to you.

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

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

Populate business delegate

Hi i studied a bit jsf
reason is we need to convert an application. however, i have a question.
in struts you have forms and actions. that actionClass populates a business-delegate
with formbean data.
i don't like this approach. (not that businessDelegate... i mean formBean -> action)
in jsf, my backingbeans hold the form-data and i implement
a method, that i refer
from action-attribute on commandButton that method
populates my businessDelegate.
what do you think on it?
i belive webwork2 (or was it tapestry) will deal similar, isn't it?
and if you think, well it is okay,
please tell me, for what i need a actionListener?
not valueChangeListener. i use this guys for notice
changes on a formfield.
Jay

hi roger,
thanks. but i more want to know, how can i use my valueObjects and my delegates
with JSF.
i have javaObjects, that represents my data like user (name,password)
so i can "enlarge" my valueObjects with a method performLogin()
that can i refer with action-attribute an method binding.
inside of performLogin(), i call
my delegate.logon()
but is it a good idea to deal so?
or is it better to write a wrapper ? (call it backingbean, or else)
with holds form-data, creates the valueObject and bypasses it to delegate?
like:
public class UserBackBean{
private UserVo u;
getU();...
setU(UserVo u) ...
public String performLogon(){
mydelegate.logon(this.u);
}and in webpage:
<h:inputSecret value="${UserBackBean.u.password}"/>
<h:commandButton value="logon" action="#{UserBackBean.performLogon}"/>good idea?
i just searched the corej2ee-pattern_book. the second edition
covers j2ee1.4, but not jsf-"patterns" :-)
i read on my search a thread, where craig told, he meet the blue-prints-folks
so i guess, perhaps some code will be published?
jay

Implement business delegate as a singleton.

Similar Messages

Maybe you are looking for