Hi,
Migrating this thread to the avalon-phoenix-dev list. Will post replys over
there from now on. For those who are interested you should subscribe over
there ;)
On Wed, 16 Jan 2002 02:09, Paul Hammant wrote:
> Peter,
>
> >I guess there are are a few real questions that need to be answered before
> > we can get clean inter-application communication. It really depends upon
> > the answers to these questions, how inter-sar communication can be
> > enabled.
> >
> >Q1. Do we need "pass by reference" or can we live with "pass by value"
> >semantics for inter app communication?
>
> We need both.
ok - so it is not a management interface then - more a service interface? ie
you expect the interfaces exported to be providing you with a service rather
than just a passive management API?
> >Q2. If Application A depends on Application B then does shutdding down B
> >require the shutting down of A?
>
> Yup dependancies should be honoured in the same way that they are for
> normal blocks. Phoenix could handle the correct order of stopping apps
> perhaps,
now this is the hard bit ;)
> >Q3. Should you be able to "browse" the services offered by another
> >application or should you only access services that you declare
> > dependencies on and are wired together via an assembly mechanism?
>
> Phase 2?
Actually this is the easiest bit about ;)
> >Q4. Should it matter if applications are on different JVMs or not?
>
> No it should not. Perhaps Phase 3.
I have actually thought about this and it could work. The problem is that we
would have to declare some services as "call-by-value" (CBV) and some as not.
There is no way to transparently do inter-JVM stuff except with an explicit
RPC interface (ie RMI or presumably AltRMI) and even then they are mainly
call by value semantics.
ie there is no way that a SocketManager could be in a different JVM. However
other services (like the one you describe for Jo) would fit in perfectly
regardless whether it is same JVM or not.
So there is 3 cases I can think of.
* Pure CBV - doesn't matter which JVM you are in
* exchanging of non-portable resources (ie FileDescriptors, Sockets, nio
buffers etc)
* CBV with possible "reference semantics". However this requires very careful
programming acknowledging you are distributed - ie RMI rules (or AltRMI).
However this must be explicitly defined by the block developer.
> >Q5. Do services offered by other applications need to be accessed via
> >standard mechanisms or can they be accessed from the somewhat round-about
> >dynamic dispatching APIs ? ie is something like
> >
> >final Object[] args = new Object[] { param1, param2 };
> >Object result = myObject.invoke( "myMethodSignature", args );
>
> You know I'll vote against the above :-)
Then I guess JMX is out ;)
> >So I guess the question comes down to which types of services can and
> > should be exported between applications. I have a few ideas that I
> > sketched out in november but I would like to hear your ideas first.
>
> <plug>
>
> AltRMI could merge straight in to the ComponentManager framework.
...
I would suggest you may start by implementing a AltRMI SystemManager for
phoenix. You could also implement a JNDI directory to store the services for
the time being (you can use naming in excalibur and I will help you with that
if you like). After it is implemented and we can try it out then it may be a
good idea to see where it goes and stuff. Thoughts?
--
Cheers,
Pete
---------------------------------------------
We shall not cease from exploration, and the
end of all our exploring will be to arrive
where we started and know the place for the
first time -- T.S. Eliot
---------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
