Enterprise Object Broker - Advice

[Paul Hammant <Pa...@yahoo.com>]

Folks,

Advice/Opinion needed....

*Context*

I have it working now.  Beans in separate jars and classloaders are 
interoperating as if they were normal Java classes.  Each bean jar 
contains an XML manifest that states its interfaces with the outside 
world.  Whether the bean is local or remote is irrelvant (well in the 
design it is, but I've not implemented the remote bit).

Working, that is, bar a feature that I wanted, but am having trouble 
implementing.  Consider......

interface Person {
  void setName(String s) ;
  String getName();
  void setAddress(Address s);
}
interface PersonFactory {
  Person makePerson();
}
interface Address { 
  void setZipCode(String s) ;
  String getZipCode();
}
interface AddressFactory {
  Address makeAddress();
}

class PersonTest {
  PersonFactory mPersonFactory; // via lookup
  AddressFactory mAddressFactory; // via lookup
  void test() {
    Person p = mPersonFactory.makePerson();
    p.setName("Fred");
    Address a = mAddressFactory.makeAddress();
    a.setZipCode("ABC123");
    p.setAddress(a);
  }
}


The bit I am having trouble with is :
    p.setAddress(a);

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.

*Question*

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...

I'd be pleased to hear people's opinion, and invite people that are 
*really* intersted to join up eob-developer@lists.sourceforge.net via 
https://sourceforge.net/mail/?group_id=44888

Regards,

- Paul H


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

Re: Enterprise Object Broker - Advice

[Peter Donald <pe...@apache.org>]

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>