You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/02/01 14:31:24 UTC

Re: Enterprise Object Broker - Advice

On Fri, 1 Feb 2002 02:41, Paul Hammant wrote:
> Reason - p and a could be sourced from facades that are in different
> places.  Person test has done a specific lookup for the two facades, but
> PersonImpl knows nothing of the locaton or existance of a facade for
> Address.  The EOB infrastructure could esablish the link for the class,
> but it is very difficult and will require changes to AltRMI.

It is application-specific and should be "configurable" by the user - much 
the same as in normal RMI. If it is a AltRMI reference then it should be sent 
across as a stub and remotely communicated with. If the implementation of 
Address is a value-object then it should be serialized and sent across. If it 
is neither of the above then an IllegalArgumentException should be thrown ;)

> Given that we design beans systems carefully along the lines of the
> Facade Pattern and use Value-Objects too at certain boundary points,
> should I try to hard to solve this issue.  I.e. by solving it I could be
> encouraging bad model design.  In conventional beans systems, this would
> be analagous to passing and entity bean reference "as is" through a
> session bean to another session bean or a non bean client application...

Bad programming occurs everywhere. Some people will insist on doing bad 
things no matter what. I actually had to deal with a system in last week or 
so that ****remotely**** accessed Entity beans - aaaaaaaaaaaaaaaaaaaargh. 

So maybe dont deal with at ALTRMI level but at EOB level. Make sure your 
persistent objects can not be made into AltRMI-ed objects and you cut down on 
a fairl bit of misuse/abuse. But leave AltRMI just like RMI is.

-- 
Cheers,

Pete

----------------------------------------------------------
Which is worse: Ignorance or Apathy? Who knows? Who cares?
----------------------------------------------------------

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>