Hi all,

While developing one of our modules I found that Proxy pattern applied to Entity beans would be very helpful for me. For example, if there is Something Entity Bean, I'd like to have

public class SomethingProxy implements Something, Remote {
    private Something delegate;

    public SomethingProxy (Something s) {delegate=s;}

    //all other Something methods, calling delegate if needed
}

and then somewhere in the code:

Something s = somethingHome.findByPrimaryKey(pk);
return new SomethingProxy(s);

This is just an example, in practice I'm planning to use different proxies and a factory for their creation.
The question is: does it violate EJB spec.? Will it work for all app. servers?

Thanks
Konstantin

This does not violate the EJB spec, and is in fact codified in a popular design pattern: Business Delegate.

http://java.sun.com/blueprints/patterns/BusinessDelegate.html

Thanks Paul, but Business Delegate looks much like a Facade pattern. The key point of my Proxy is to implement original Entity Bean's remote interface and be possibly passed instead of this bean instances.

If that is all you want to do, there is not a lot of point to your proxy.

The interface is already implemented by a remote proxy, generated by the server. To make your proxy work on a remote client, you would have pass both your proxy and the server's proxy, and you end up with a proxy-calling-a-proxy.

Technically this is all OK by the specs, but unless I am missing something, I don't see much of a point to it.

The only reason I can think of that you might want to do this is to replace the remote-access or security model of your EJB server with something custom of your own, but that would be a lot of work.

This is OK if server doesn't expect to see exactly it's server proxy class which may be generated with some additional service methods. My proxy will not implement them of course.

Why do I need it, in brief: we have lots of different entity beans and IM (integrity manager) to support data integrity across them. If one of this beans is removed some other dependant beans should be updated/removed as well. All such beans extend IntegrityAwareEntity/IntegrityAwareEntityHome interfaces and there is Session Facade to build dependency graphs and handle complex removes.
Everything works fine until two additional requirements appear:
1. Some beans require using special facades for their removal, so remove() can't be called.
2. Some beans can have TONS of instances. For example, if there are Table and Record entities, and we want to remove a Table with 1M records, IM will build reference graph and then remove records one by one forever. In fact transaction will be rolled back after timeout. So we need mass operations support, which is implemented using Commit Option B and a number of home methods in the IntegrityAwareEntityHome like massRemove(..).

To make all this stuff more or less transparent to the IM and GUI I decided to make IntegrityAwareEntityProxy that will
- replace remove() calls with facades calls in case of (1)
- replace IM calls with massXXX home methods calls in case of (2) [tricky, but possible]
- delegate the rest to server proxy.

Ah! I understand now. In that case:

Yes, what you are doing is legal and yes, there is a point to doing it. Using a combination of the Facade/Proxy patterns seems to be the best way to do this.

I assume you are using direct JDBC calls or stored procedures for the direct remove operations? This would be the best to remove 1M records.

Yes, we use JDBC covered by our own thin layer to be DB-independent. So mass remove will be a single SQL command.
Thanks for your replies, now I feel safe to spare my time for implementation.