Thanks for the reply, my further comments, clarifications and questions
are added throughout.
----- Original Message -----
From: "Cedric Beust" <[EMAIL PROTECTED]>
To: "Joel Riedesel" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, July 13, 2001 11:41 AM
Subject: RE: Design for both Remote/Local, is it possible?
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Joel Riedesel
>
> > So can what I am trying to do here be done or am I being abusive of EJB?
>
> I think you're being abusive of the Java type system :-)
>
> For example:
>
> > public interface Foo {
> > public String getName() throws java.rmi.RemoteException;
> > public Long getID() throws java.rmi.RemoteException;
> > }
> > import org.foo.Foo;
> > public interface FooLocal extends EJBLocalObject, Foo {}
>
> is probably not going to work as Foo only contains methods that throw
> RemoteExceptions.
Ahhh, but I'm not hearing that it shouldn't work or can't work. Only
a "probably not going to work". I would much prefer a reason that
it will or won't work according to the EJB specification. I'll admit
that I'm not even close to being an expert on it, but I have done a bit
with RMI over the last four years now.
>
> I understand that it's tempting to try to reuse as much as possible when
you
> have methods that you want to be both local and remote, but this is not
the
> right way to do it (see http://beust.com/cedric/smli_tr-94-29.pdf for more
> details). You *want* these methods to be different, trust me.
I know the arguments about RPC.
Our current rmi-based application has two interfaces, one remote and one
local.
Basically every API is duplicated among them. Fun.
I want to write code elegantly (reuse in many cases) and also do the
right thing when it comes to whether I want to use the remote or the
local object I am trying to access. If I were not going to an EJB world,
I'd be spending my energy working on the whole dynamic-proxy thing to
clean this up.
>
> The solution would be more along tools, such as EJBGen, which lets you
> specify:
>
> /**
> * @remote-method
> * @local-method
> */
> public void doSomething() {
> }
>
> and will generate the interfaces with the right signatures.
Sounds interesting. Where does EJBGen come from?
>
> The Java type system is here to help you both on a syntactic standpoint
and
> also on a semantic one, so you can clearly see what methods are remote
when
> you read your code. Squelching exceptions in the local case will only
bring
> you trouble in the long run.
That's not waht I'm talking about. No one's squelching exceptions here.
And in fact, in my example, I'm possibly raising remote exceptions even
in the local case.
>
> > One of my questions is whether I can deploy this bean as both a local
and
> > remote bean.
>
> Yes, no problem with that, but you need to expose two distinct interfaces:
> one local and one remote.
Which I have in my example.
>
> As a sidenote, I believe that having a bean exposing both interfaces is a
> rare case, and even more rare would be exposing the *same* method locally
> and remotely. I would be definitely interested in hearing why you think
you
> need that.
I don't buy it.
We have many objects in our application that may be used both locally
and remotely. We allow the application to be built in a distributed fashion
with parts of it being run on different machines. At the same time we try
to use local interfaces when the objects are talking to objects in the
same VM. Obviously. The cost of marshalling is way too high to ignore
and I do everything I can about avoiding it if at all possible.
If I didn't have to worry about scalability, everything would simply use
the remote interfaces. Period. But my boss would probably fire me
then when our product didn't scale. Thus the need to also have local
interfaces.
>
> > And then, once that's done, how do I access it locally vs.
> > remotely from client code (hmmm, seems to be a sticky point)?
>
> Remote client invokes stateless session bean (remotely) which in turn
looks
> up the local home of an Entity bean and passes value objects around.
So, how would an entity bean in one VM/AS directly talk to another entity
bean in another VM/AS?
>
> > I hesitate to ask this question: Any recommendations of an AppServer
that
> > can at least get me close to the kinds of things I'm trying to
> > do;
>
> I would suggest you download the Weblogic 6.1 beta version from our Web
> site. After that, you are very welcome to come and bug us on our
newsgroups
> :-)
Does this support local entity beans now as well as CMP 2.x?
Last time I looked at WebLogic it at least didn't have the local entity bean
support.
Joel
===========================================================================
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".
