You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/01/14 10:01:04 UTC
Inter-sar communication.
Folks,
I've been playing with Jo! the webserver and it is very stable under
Phoenix configuration. To remind everyone Jo has a service of :-
public void deployWAR(String hostName, String name, String ctxPath,
String warUrl) throws Exception;
public void undeployWAR(String hostName,String name) throws Exception;
I don't think it is perfect that each throws Exception. Perhaps
JoException might be more usable. I think what we need is an
interface/impl separation of the current block We'd end up with two
blocks one for the service that depending applications would compile
against and include in their SAR. The other would contain the hidden
impl. and only be in Hendrik's avalon-jo.sar. I've emailed Hendrik to
ask for these...
What is the feeling about the inter-sar communication. Clearly we need
a lookup stage before the service can be used just like normal.
Question is should it be part of the existing API :-
public void compose( final ComponentManager componentManager ) throws
ComponentException {
mMyService = (MyService) componentManager.lookup( MyService.ROLE );
mJoService = (Jo) coponentManager.lookup( Jo.ROLE );
}
Or a separate API? :-
public void compose( final ComponentManager componentManager ) throws
ComponentException {
mMyService = (MyService) componentManager.lookup( MyService.ROLE );
}
public void compose( final CrossApplicationComponentManager
componentManager ) throws ComponentException {
mMyService = (MyService) componentManager.lookup( MyService.ROLE );
}
It is important because we might need to juggle the needs of Phoenix
which might like to do all lifecycles methods against each sar in turn
and the assembler who might like to choose whether a particular
application depends on a block that the sar contains or another in an
alternate sar that is also deployed.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Inter-sar communication.
Posted by Peter Donald <pe...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Inter-sar communication.
Posted by Paul Hammant <Pa...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Inter-sar communication.
Posted by Peter Donald <pe...@apache.org>.
On Mon, 14 Jan 2002 20:01, Paul Hammant wrote:
> What is the feeling about the inter-sar communication. Clearly we need
> a lookup stage before the service can be used just like normal.
> Question is should it be part of the existing API :-
>
> public void compose( final ComponentManager componentManager ) throws
> ComponentException {
> mMyService = (MyService) componentManager.lookup( MyService.ROLE );
> mJoService = (Jo) coponentManager.lookup( Jo.ROLE );
> }
>
> Or a separate API? :-
>
> public void compose( final ComponentManager componentManager ) throws
> ComponentException {
> mMyService = (MyService) componentManager.lookup( MyService.ROLE );
> }
> public void compose( final CrossApplicationComponentManager
> componentManager ) throws ComponentException {
> mMyService = (MyService) componentManager.lookup( MyService.ROLE );
> }
>
> It is important because we might need to juggle the needs of Phoenix
> which might like to do all lifecycles methods against each sar in turn
> and the assembler who might like to choose whether a particular
> application depends on a block that the sar contains or another in an
> alternate sar that is also deployed.
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?
Q2. If Application A depends on Application B then does shutdding down B
require the shutting down of A?
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?
Q4. Should it matter if applications are on different JVMs or not?
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 );
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.
--
Cheers,
Pete
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>