Paul:
I'm not a candidate in terms of being able to help on on this (question
of time available) - but you should know I am doing some some work
related to a CORBA container using Merlin 2. The objective is to
provide a container that incorporates the CORBA POA architecture
(Portable Object Adapter) as the containment implementation. A POA
Activator will receive corbaloc URL based requests for service
activation and return CORBA object references to the client (reference
and valutype). Inside the container I'm using the Merlin ability to
dynamically mount and demount components that will be used to actually
handle the the requests from client object references established by the
manager. Merlin's lazy activation ensures that the container based
component does not get instantiated until required to service a client
request, and the POA management architecture will be used to demount
components that are not in active use.
This allows me to very easily provide complete remote and scalable
activatation of services in any of the following types of scanarios:
component to remote container
container to container
web-application to container
etc., etc.
Cheers, Steve.
Paul Hammant wrote:
> Folks,
>
> Firstly ->
>
>http://cvs.apache.org/viewcvs/jakarta-avalon-excalibur/altrmi/src/xdocs/altrmi_logo.gif
>
> -> Way cool!! I missed it happening, but it looks good.
>
> I'd like to start a dialogue with persons intersted in pushing AltRMI
> forward. Namely those are Leif, Peter Royal, Vinay and Jeff looking
> at the CVS logs. Stephen too is interested given some previous
> Merlin work. There are also some users of AltRMI in companies for
> bespoke solutions.
>
> *Async behaviour*
>
> Joe Walnes (Mr Sitemesh - blog : http://radio.weblogs.com/0108103/),
> Charles Lowell (Thoughtworks) and myself are slowing pushing towards
> an Asynchronous aspect to AltRMI. Basically if a methods returns void
> and throws no exceptions, it could be executed asynchonously. This is
> a publication choice of course. Joe talks of a default implementation
> of 'over AltRMI' but envisages ones over JMS and other specialised
> messaging transports, possibly including the way-cool JavaGroups.
> With a JMS tyle solution hierarchies of messaging factories could be
> laced together to releive the burdon on the server and guaranteed
> deliver could be a value added possibility.
>
> *Unit Tests*
>
> I've added some more, based on an orginal one from Charles and Joe.
> We can now unit test, well integration test, all of the transports
> that AltRMI offers. There are more to add to specifically test the
> various tylpes of class loader and authentication, but they will be
> added later. There is work needed to make the Piped tests perform
> better - there must be some thrashing due to lack of threads in the
> test cases presently. I say that because the piped speeds suck, which
> is not my actual experience. It would also be nice to extract the
> testSpeed() elapsed time from the Jinit XML and make a page for use on
> the website with actual relative speeds. Has anyone got Zen level XSL
> and can take on the task?
>
> *Jar Files*
>
> Currently there are five jars files for AltRMI. Given that there are
> multiple transport implementations, it is likely that users will use
> jar files that contain transports that are just not needed. Should we
> push towards more jars files? There is also a case that we should
> push towards less jar files bu combining the server and client
> interfaces ones into the common. Thoughts?
>
> *Dual level client side proxies*
>
> Consider an interface 'HowdieInterface' that has a single method 'void
> howdie()'. AltRMI generates the equiv of:
>
> public class AltrmiGeneratedHowdie_Main implements
> org.apache.excalibur.altrmi.client.AltrmiProxy{
> private transient org.apache.excalibur.altrmi.client.ProxyHelper
> mProxyHelper;
> public AltrmiGeneratedHowdie_Main
> (org.apache.excalibur.altrmi.client.ProxyHelper proxyHelper) {
> mProxyHelper = proxyHelper;
> }
> public void howdie () {
> // method body
> }
> }
> public final class AltrmiGenerated2Howdie_Main extends
> AltrmiGeneratedHowdie_Main implements HowdieInterface {
> public AltrmiGenerated2Howdie_Main
> (org.apache.excalibur.altrmi.client.ProxyHelper proxyHelper) {
> super(proxyHelper);
> }
> }
>
> This is done so that in theory a remote client like BeanShell (I love
> it), can use the service and do preper reflection over the methods
> without dealing with an java.reflect.Proxy style invocation handler
> which is a bit of a black-box to reflection tools. Anyway a couple of
> people have requested that the classloader should get dependencies
> over AltRMI like RMI does. Specifically that would mean
> HowdieInterface in the above example. At the same time we could
> combine the two above classes into a single class. This would be
> quite easy for the Javac using proxy generator. For the BCEL one ot
> would be harder for me cos I have trouble understanding it to the
> level Vinay does. Thoughts?
>
> *SOAP*
>
> Anyone want to take this on? Reusing Apache-Axis or James Strachan's
> Jelly (jakarta-commons-sandbox/jelly) or something else?
>
> *Custom XML transport*
>
> I'd though for a while that something that leverages
> http://www.csse.monash.edu.au/~bren/JSX/tech.html would be really
> cool. Unfortunately it is dual GPL/Commercial license which completely
> precludes any effort on our part to ship anything that includes it.
> We could. I'm sure do some work that codes against it using some
> Class.forName(..) way of circumventing the licnse issue, but
> previously it was incompatible with JDK 1.4. It would be interesting
> to see the speed of a JSX using transport over one that utilises the
> JDK serialzed objects (all other AltRMI transports). It would also be
> interesting to see how version tolerant this would be (XMLs promise).
>
> I'm beginning to think that James Strachan's Jelly is the way forward
> though. Talking to James there is some realy interesting work going on
> there. It is ahead of a curve presently and bit of a tool looking for
> its killer app. (Blog of James http://radio.weblogs.com/0112098/
> change the skin dude!).
>
> *More transportable pass-by-value types*
>
> Currently the primatives and basic dervarions of plain Object are
> supported provided they are transportable. We can also do derivations
> of Object[] but I think more complex things require more work. Is
> Object[][] ever going to need to be supported? Also I feel that some
> special work needs to be done for Collection and Iterator etc. Thoughts?
>
> *Distributed Garbage Collection*
>
> We have implemented this so far using WeakReferences on both the
> client and server side. .Net uses leasing. The weak references is a
> perfect world scenario, but if a client dies without tidying up, then
> the server will be prevented from garbage collecting an item on teh
> server side. It also relies on the fact that Java does actuall GC
> objects when they are inaccessible, and not when there are tight
> memory situations. Should we also implement a leasing scheme? My view
> is that it would supplement the weak reference impl addressing the
> client-death scenario. Thoughts?
>
> *AltRMI tunnelling*
>
> Just an idea. Is there a concept of a firewall or proxy server for
> AltRMI? I.e. a way of tunnelling an AltRMI connection through a
> server. Some listener that does nothing other than forward calls to
> some other thing. Thoughts?
>
> *AltRMI redirection*
>
> Another on the original todo list. Client esablished a dialog with a
> server but is redicrected to another server which unknown to the user
> of lookup(..). A poor man's load balancing. Thoughts?
>
> *Seperation of Content and Addressing*
>
> Currently some bastardized command pattern is uses as the messaging
> protocol (over the transport) for method invocations. The whole thing
> has to be deserialzed to show what type of command it is. If this
> were split into basic info and a methods args components, then
> tunnelling might be easier. Deterministic routing might be easier
> too. Having said that basic client to server connections would be
> slower.
>
> *Any Other Business*
>
> Anything else to discuss?
>
> Regards,
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
