Suppose you have a Client and a TargetSessionBean, with TargetSessionHome and TargetSession interfaces. You want to place a proxy in front of the session bean, transparantly for the client.
First of all, create the proxy as a session bean – statefull or stateless, depending on the target bean type - with the same interfaces as the TargetSessionBean. This gives you a ProxySessionBean, with TargetSession and TargetSessionHome interfaces.
Now you have to implement the ProxySessionBean. In the ejbCreate() method, create an instance of TargetSessionBean and cache this in the proxy. Forward each business method of the ProxySessionBean to the target:

  public Object executeBusinessMethod(Object input)
  {
//pre-processing here
        Object result = targetSession.execute(input);
        //post-processing here
        return result;
  }

Use local interfaces for the communication between proxy and target to speed up performance. Clean-up the target instance in the ejbRemove() of the proxy and use the same transaction and security settings for both proxy and target. Finally you get a proxy object that is a perfect surrogate for the target.
But what about the client, how does it know that it should call the proxy and not the target anymore? Well, this is the nice part: take as JNDI name for the ProxySessionBean the name from the target, and give this TargetSessionBean another name that the proxy can use. Or, if the client is an ejb, change the ejb-ref entry in the client.

Summarized, you have created a proxy to your target bean without changing the existing application!

Sorry guys, there was a small error in the code example. Obviously the methods in proxy and target should match exactly:

  public Object execute(Object input)
  {
        //pre-processing here
        Object result = targetSession.execute(input);
        //post-processing here
        return result;
  }

No , it 's not necessary the proxy need match the target session , normal the articles metioned is the session Facade pattern ,which publish from sun blueprints ,it 's mainly advantage is reduce more remote call , just operate a proxy sessionbean who wraper some workflow EJBs method ,not only a sessionbean or entityBeans'.

you can read more in

http://java.sun.com/blueprints/patterns/j2ee_patterns/session_facade/index.html

It's not the session facade. Main goal of this pattern is to add an 'invisible' proxy in front of a session bean. It's the J2EE version of the proxy pattern in the GoF book. Or, in some implementations, you probably could consider it as a decorator pattern (also GoF) too. Therefore it is very important that the proxy and the target implement exactly the same interface, otherwise it wouldn't be invisible for the client.

Some while ago I needed this functionality - Here is a very simple example (for WebLogic 6.1) which does it transparently by replacing InitialContext factory.

I would say it is fairly close to the BusinessDelegate pattern of "Sun Core J2EE Patterns". If you use the BusinessDelegate, the implementaion could also serve as implementation for the "Sessionbean Smart Reference" pattern.

Pardon my ignorance, but I fail to see what this pattern
gives you! I see that it adds an extra layer. The client
still needs to do a "lookup" of the session bean. So instead
of directly looking up TargetSessionBean, the client looks
up ProxySessionBean that, in turn, looks up
TargetSessionBean. All right, ProxySessionBean can
communicate with TargetSessionBean via a local interface,
but let's face it, at this point in time, how many app
servers implement local EJB interfaces? (Contrary to popular
belief, WebLogic is _not_ the _only_ EJB container around!)

Please elighten me!

TIA,
Avi.

It gives you the same advantages as the proxy pattern from the GoF. It can act as a smart reference to intercept messages and act upon them. Moreover, you don't need to adapt neither the sending nor the receiving component. You just need to play with the JNDI names. Clearly this is useful when you don't have the source code of sender or receiver.

i have discovered a very interesting thing usefull for decorator: dynamic proxies.
A dynamic proxy is an objects that implements an interface specified at runtime!
Thus in stead of duplicating the bean and calling the one from the other, i have a (java interface) and an (implementation class). The beans remote interface extends the (java interface), the bean implementation is wrapper code : forward methods to the (implementation class).
If i need "generic" pre/post processing (i mean: for each method the same pre/post processing) (like debugging: "this method was called...") i put a dynamic proxy in between the bean and it's implementation. Thus the bean forwards to the dynami proxy, and the proxy to my original implementation.
The interesting thing about dynamic proxy is that you have one method which is called for every method in the interface. You don't have to change it when your interface grows or changes...

i have discovered a very interesting thing usefull for decorator: dynamic proxies.
A dynamic proxy is an objects that implements an interface specified at runtime!
Thus in stead of duplicating the bean and calling the one from the other, i have a (java interface) and an (implementation class). The beans remote interface extends the (java interface), the bean implementation is wrapper code : forward methods to the (implementation class).
If i need "generic" pre/post processing (i mean: for each method the same pre/post processing) (like debugging: "this method was called...") i put a dynamic proxy in between the bean and it's implementation. Thus the bean forwards to the dynami proxy, and the proxy to my original implementation.
The interesting thing about dynamic proxy is that you have one method which is called for every method in the interface. You don't have to change it when your interface grows or changes...

i have discovered a very interesting thing usefull for decorator: dynamic proxies.
A dynamic proxy is an objects that implements an interface specified at runtime!
Thus in stead of duplicating the bean and calling the one from the other, i have a (java interface) and an (implementation class). The beans remote interface extends the (java interface), the bean implementation is wrapper code : forward methods to the (implementation class).
If i need "generic" pre/post processing (i mean: for each method the same pre/post processing) (like debugging: "this method was called...") i put a dynamic proxy in between the bean and it's implementation. Thus the bean forwards to the dynami proxy, and the proxy to my original implementation.
The interesting thing about dynamic proxy is that you have one method which is called for every method in the interface. You don't have to change it when your interface grows or changes...

Pardon my ignorance, but I fail to see what this pattern
gives you! I see that it adds an extra layer. The client
still needs to do a "lookup" of the session bean. So instead
of directly looking up TargetSessionBean, the client looks
up ProxySessionBean that, in turn, looks up
TargetSessionBean. All right, ProxySessionBean can
communicate with TargetSessionBean via a local interface but to what advantage, the client has to make a remote call to the proxy bean..

in case I have wrongly interpretted the pattern kindly let me know..but please elaborate..


Pankaj

email :
[email protected]

First of all: the client doesn't have to make a remote call to the proxy, it can be a local call as well if it is a local client. The main advantage of the pattern is that you can place a proxy in between of a session bean, without rewriting the caller's code. This is particulary usefull in existing applications, where you don't have the source code. In the datamining world for instance, where I work, one often needs to capture the communication between existing components, without changing them. This can be accomplished using this pattern.

It's work....Tim, now try to imagine and help me:
if you pass to the proxy
1- the local JNDI name
2- the method to call
3- a List of the parameters
with a little effort and introspection we can realize an SSLProxyBean object that completely uncouples the client from the interface of every SSL bean other than this ProxyBean.

Right??!!

Could someone please point me to an example of using this pattern (or one similar) for auditing (audit trail creation or simple logging) purposes?

Thanks

- Chris