commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <>
Subject Re: FW: [Ann] AltRMI work in Avalon Demos & Jesktop
Date Sat, 19 Jan 2002 17:41:29 GMT

> I don't want to have this discussion AspectJ list.
> Lets talk here. 

We were not on the AspectJ list dude.  One of use had hit reply and it 
went to sender not list :-)

> > AltRMI publishes plain interfaces.
> >
> >Put it another way, think of the SimpleStore you are working on with
> >Gerhard and others.  Imagine that there could be a 'Remote Store'
> >(SimpleStore does separate interface/impl yes?).  If Remote Simple store
> >were one implementation then the team has to make a choice.  That choice
> >is whther to have RemoteException on all methods in the interface. Or to
> >not do, and have an 'adapters' to re-represent all the methods as
>  Yes I prefer 'adapters' I dont know how to hanle "By Value" and
>  by reference stuff if I have no tag.
>  You told, transparency is the advantage of .NET . All of transparent 
> objects in .NET are COM objects, and all of them implenet IUnknown
>  interface, COM does not have "By Value" or you must use "Custom  
> Mashaling" it is not trivial for trivial objects, yes it copies BSTR,
> safe arrays and predefined primityve types "OLE Automation", thre are
> no "By Value" for COM object, you can implement it youself, but it 
> does not like "Serelizable" it is "IPersistSream". It is binary 
> standard and it language neutral, I don't say .NET,COM or DCOM is bad,
> but it is no very transparent as you thing, 

Perhaps I'e misunderstood the simplicity of the .Net method invocation 
transports then.  I'll check my facts.

> I agree C# is good and transparent, but not all this .NET framework.
> I dont say "bad" or "good" for Microsoft, I like it, nothing personal.
> Please tell me if it possible to handle all this "By Value" stuff 
> transparently in ARMI, it very hard to understand for me.
> remote 

When you publish an object via one or mor interfaces it implements, you 
also tell AltRMI which additional interfaces to facade-ify.

Consider :-

interface PeopleManager {
  Person getPerson(String name)
  Person makePerson(String name);
interface Person {
  String getName();
  Person getSpouse();
  Address getAddress();
  // more methods
interface Address {
  // methods.

With AltRMI you could decide whether you want Person and Address to be 
serialized and sent (well the class that implements it anyway) in a 
pass-by-value concept, or whether each invocation of the remote 
getAddress() should instatiate another facade.  Clearly with 
PeopleManager it would defiantely be a facade.  The choice is at time of 
publication (well it will be when I can dynamically write bytecode).


Interestingly I went out a bought some fresher books today ( I have 
loads of Java book but mostly from the last millennia).  Whist I was 
there a C# book launched itself if its high shelf and hit this fellow on 
his shoulder.  He he, I hope it was not that sharp.

I now have the 2002 edition of  Ed Roman's "Mastering EJB II".  Page 49, 
Footnote : "For a while, the primary author of this book (Ed Roman) has 
been pushing Sun to adopt some kind of flag that enables you to switch 
between local and remote access to beans without changing code.  The 
idea is that the flag would determine whether the container-generated 
interceptor object would behave as a locally object or remote object. 
 We think this is the best  approach because (in reality) many 
developers will misjudge whether to use remote or local interfaces when 
designing their object models, and will have to rewrite parts of their 
code later in their projects. <para> The response from Sun so far is 
that this approach would not work because the semantics of the 
application change when switching between local and remote interfaces, 
due to the differences in pass-by-value versus pass-by-reference. It 
would be error prone to allow developers to 'flip a switch' in this 
respect.  <para> Personally, we don't agree with Sun.  We think the 
developer is smart enough to avoid these mistakes, and the potential 
benefits outweigh the drawbacks.  Many EJB server vendors disagree as 
well.  They actually support this local/remote flag idea through 
proprietary container tools or vendor specific files that are separate 
from your bean.  Thus if you want to, you may be able to still take 
advantage of these flags without sacrificing portability"

There is also a big "opinion" style note on Exception handling on page 
60.  It is too big to type!  Excellent stuff.

I'm not the first to think that RemoteException (and it's implications 
for a local service that wants remote capability) smells.

AltRMI blurs the distinction between local and remote.  It it /nearly/ 
invisible in use.  Of course the developer should be aware of the 
application of the facade pattern for those interfaces they choose to 


- Paul H

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message