The Proxy class would most commonly be used in one of two
ways: to interpose functionality between an interface and its
implementation class, or to provide a generic implementation of
interfaces that follow a design pattern. Here's an example that
might apply to your situation. I haven't tried this, so take it with a
grain of salt.
Say you want to give your client programmer a business interface
without all those annoying RemoteExceptions in the throws
clause. Instead, you want a common error handling routine to be
called whenever there is a RemoteException, and then you want an
unchecked exception to be thrown instead. Also, assume that the
functions in the business interface map one-to-one with functions in
the bean's interface.
You could use the Proxy class to "implement" your business
interface. In your InvocationHandler, you could use introspection to
find the equivalent method of the bean's stub. You could then call
this equivalent method, catching RemoteException and calling your
error routine, etc.
I haven't thought much about the wisdom of doing any of these
things. I'm just trying to give an example of the kind of thing Proxy
is good for. Hope it helps.
-Dan
On 14 Apr 00, at 14:19, Ed Lorenz wrote:
> Thanks Dan.
> The idea would be to present one interface to the application programmer,
> EJB user,
> and yes, using a facade, hide the EJB stuff. I'm trying to figure out how
> or if I
> would want to use the DynamicProxy object to facilitate the facade.
>
> -----Original Message-----
> From: Dan OConnor [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 14, 2000 1:37 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Dynamic Proxies
>
>
> On 14 Apr 00, at 12:25, Ed Lorenz wrote:
>
> > A while back there was mention of using the DynamicProxy object included
> in
> > 1.3 ( I checked the archives )
> > Was the idea to allow the client application to use ONE, simple,
> > object/interface from which they would be able to
> > manipulate state as well as invoke behavior.
>
> I don't remember the specific thread you are referring to, but in the
> contexts I have seen it discussed, Proxy is an implementation
> detail hidden from the client programmer.
>
> > Then through the use of the DynamicProxy the method would be delegated to
> > the appropriate Entity or Session bean.
> > This sounds like a good idea. It would appear to be a more true OO
> design,
> > at least from the application
> > programmers point of view.(Data and behavior together)
> > It would certainly reduce the amount of objects / interface's / EJB
> concepts
> > for
> > which the application programmer would have to understand and keep track
> of.
>
> When you say application programmer, are you talking about
> someone who writes enterprise beans or someone who writes
> clients that use enterprise beans?
>
> It seems as though you are talking about the latter, but the client
> programmer's burden doesn't seem that great to me. You have an
> interface that implements the factory pattern and another that
> provides the business logic, and that's pretty much it. (You may
> want to hide some details of these in case your client were to use
> a different technology.)
>
> Do you have an idea how you would like your client code to look?
> It may be possible to present a facade to the EJB stuff to get the
> effect you are looking for.
>
> -Dan
>
> >
> > Is this what you guys where talking about ???
> >
> > Ed Lorenz
> > [EMAIL PROTECTED]
> > With no fences, who needs Gates ?
> >
> >
> ===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
