You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Scott Sanders <ss...@nextance.com> on 2002/01/14 20:04:13 UTC
FW: [Ann] AltRMI work in Avalon Demos & Jesktop
Thought this would be interesting to commons-dev, to show how AltRMI is
transparent :)
-----Original Message-----
From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
Sent: Sunday, January 13, 2002 3:07 AM
To: Avalon Development
Subject: [Ann] AltRMI work in Avalon Demos & Jesktop
Folks,
To complete a flurry of 'remote management' activity this week by many
of us, I'd like to announce that :
1) The 'HelloWorld' demo has been upgraded to have an AltRMI interface.
To recap, the demo as is allows you to point a web browser to a port and
see the following in the browser's window:
HelloWorld!
Requests so far = 1
By invoking 'build cornerstone check-altrmi' you'll launch the tester
that, via AltRMI, changes the message in the block to:
Howdie Partner!
Requests so far = 2
2) I've done some more work with Jesktop. Actually the apps (that are
not Apache license) have moved from Perforce hosting to SourceForge.
One of those is Beanshell. I've added the client side AltRMI jars to
that app and also added a new command arLookup.bsh (attached). In the
Shell you can now do the folllowing ('bsh %' is beanshells prompt)
before using the browser to see the results:
bsh % fred = arLookup("127.0.0.1",8666,"helloworld");
bsh % fred.setGreeting("How do you do");
The interesting point about this is that Beanshell contains no classes
from Cornerstone-demos. It has no knowledge of it and is merely
actioning methods calls agains a bean. It could to a similar lookup on
any service anywhere. setGreeting() is just an example of a method that
can be exposed.
---
Granted we see Eung-Ju working on RMI and Peter delivering JMX. AltRMI
is for those people that want to deal with legacy interfaces. For
example the Servlet API. It is not MBean, nor is it RMI. Ganted also it
may be a bit hard and pointless to publish via AltRMI.
---
For those that want to repeat the tests.............
1) 'build jesktop install' (in cornerstone)
2) 'build demo install' (in cornerstone)
3) delete all bar jesktop.sar and avalon-altrmidemo.sar from
<phoenix>/dist/apps/
4) run phoenix as usual.
5) point browser to http://localhost:7666/
6) 'build demo check-altrmi' (in cornerstone)
7) refresh browser
8) In Jesktop go to SimpleInstaller and install Beanshell from
http://jesktopapps.sourceforge.net/apps/ (though give me an hour to
upload a new version).
9) launch beanshell and do the bsh% bits above.
---
For those that are interested in possibilities. We could have many
beanshell 'bsh' scripts :
startService(..)
listServices()
stopService(..)
shutdown(..)
.. all these commands could use management facades.
Regards,
- Paul H
Re: FW: [Ann] AltRMI work in Avalon Demos & Jesktop
Posted by Paul Hammant <Pa...@yahoo.com>.
Juozas,
> 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
publish.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: FW: [Ann] AltRMI work in Avalon Demos & Jesktop
Posted by Juozas Baliuka <ba...@mwm.lt>.
Hi,
I don't want to have this discussion AspectJ list.
Lets talk here.
> 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,
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
>methods for remote use. The choice of being remote compatible or not is
>a choice that affects basic design. AltRMI allows your team to think &
>code local-only and still remote publish the store. It is much easier
>for its users.
>
>Phew, I hope I have explained it well.
>
>Regards,
>
>- Paul H
>
>
At 11:04 AM 1/14/2002 -0800, you wrote:
>Thought this would be interesting to commons-dev, to show how AltRMI is
>transparent :)
>
>-----Original Message-----
>From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>Sent: Sunday, January 13, 2002 3:07 AM
>To: Avalon Development
>Subject: [Ann] AltRMI work in Avalon Demos & Jesktop
>
>
>Folks,
>
>To complete a flurry of 'remote management' activity this week by many
>of us, I'd like to announce that :
>
>1) The 'HelloWorld' demo has been upgraded to have an AltRMI interface.
>
>
>To recap, the demo as is allows you to point a web browser to a port and
>
>see the following in the browser's window:
>
> HelloWorld!
> Requests so far = 1
>
>By invoking 'build cornerstone check-altrmi' you'll launch the tester
>that, via AltRMI, changes the message in the block to:
>
> Howdie Partner!
> Requests so far = 2
>
>2) I've done some more work with Jesktop. Actually the apps (that are
>not Apache license) have moved from Perforce hosting to SourceForge.
> One of those is Beanshell. I've added the client side AltRMI jars to
>that app and also added a new command arLookup.bsh (attached). In the
>Shell you can now do the folllowing ('bsh %' is beanshells prompt)
>before using the browser to see the results:
>
> bsh % fred = arLookup("127.0.0.1",8666,"helloworld");
> bsh % fred.setGreeting("How do you do");
>
>The interesting point about this is that Beanshell contains no classes
>from Cornerstone-demos. It has no knowledge of it and is merely
>actioning methods calls agains a bean. It could to a similar lookup on
>any service anywhere. setGreeting() is just an example of a method that
>
>can be exposed.
>
>---
>
>Granted we see Eung-Ju working on RMI and Peter delivering JMX. AltRMI
>is for those people that want to deal with legacy interfaces. For
>example the Servlet API. It is not MBean, nor is it RMI. Ganted also it
>
>may be a bit hard and pointless to publish via AltRMI.
>
>---
>
>For those that want to repeat the tests.............
>
> 1) 'build jesktop install' (in cornerstone)
> 2) 'build demo install' (in cornerstone)
> 3) delete all bar jesktop.sar and avalon-altrmidemo.sar from
><phoenix>/dist/apps/
> 4) run phoenix as usual.
> 5) point browser to http://localhost:7666/
> 6) 'build demo check-altrmi' (in cornerstone)
> 7) refresh browser
> 8) In Jesktop go to SimpleInstaller and install Beanshell from
>http://jesktopapps.sourceforge.net/apps/ (though give me an hour to
>upload a new version).
> 9) launch beanshell and do the bsh% bits above.
>
>---
>
>For those that are interested in possibilities. We could have many
>beanshell 'bsh' scripts :
>
> startService(..)
> listServices()
> stopService(..)
> shutdown(..)
>
>.. all these commands could use management facades.
>
>Regards,
>
>- Paul H
>
>bsh.help.arLookup = "usage: arLookup(host, port, name), returns object";
>
>/*
> By Paul Hammant : Specifically for Jesktop
>*/
>Object arLookup(String host, int port, String name) {
>
> org.apache.commons.altrmi.client.AltrmiFactory af = new
> org.apache.commons.altrmi.client.impl.ServerClassAltrmiFactory();
> af.setHostContext(new
> org.apache.commons.altrmi.client.impl.socket.SocketObjectStreamHostContext(host,
> port));
> return af.lookup(name, true);
>
>}
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>