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.
>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,
>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?
>Q4. Should it matter if applications are on different JVMs or not?
>
No it should not. Perhaps Phase 3.
>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 :-)
>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.
It is the duty of the assembler to honour the declarations made by the
block developer as to which params and return vals to a service are
other facades (ie. which mix of pass by value and pass by reference).
Whether the service is remote or not clearly has a bearing on the
managability from a pheonix point of weiw (unless Phoenix's management
could be federated too "Can you shut down XYZ please, no? thats OK then,
thanks for telling me".
Whether the service is remote or not does have a bearing on the tool
used to achiece inter-sar communication. Last year we pondered the
classloader issue. You were confident there was a solution to multiple
K/HC, I was doubtful. This year because of AltRMI, I am quite confident
that we can support a number of possibilities. Consider Jo! having
service API 1.0 and 1.1 in 'current use' and other applications that are
hard coded against each of those APIs. With blocks being in SARs at the
moment and each in a diff classloader there is no problem. However, to
share Jo! outside the SAR presents problems if the service classes are
visible to many sars. With AltRMI we can lash together SARs and support
multiple versons of the same tool in the same VM. Clearly with this
example we still have a problem in that two instaces of a webserver
can't serve the same socket. Bad example perhaps. In short I am
confident tha the Piped-ObjectStream impl of AltRMI can solve the
inter-sar issues, and the Socket-ObjectStream version can solve the
federated pheonix dependancys. The current limitation of AltRMI is that
it likes things to be both pass by value and pass by reference. The
former must be serializable and there are many noteworth example of
broken serialzed impls in the JDK. There are also many things that ae
not serializable becase they themselves are not so much objects as streams.
We should begin to recommend separation of Jars for interface and impl.
Sam, you listening? As a head honcho figure, could you carry that into
other projects (particularly those that I have overstayed my welcome in ;-)
Phew!
- Paul
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
