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>