You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Daniel Krieg <dk...@kc.rr.com> on 2002/10/12 17:52:42 UTC
Inter-SAR communication
I am still new to using Phoenix and am currently working on the Sevak app. What is the standard approach to exposing the services of one SAR to another SAR?
Re: Inter-SAR communication
Posted by Peter Donald <pe...@apache.org>.
On Sun, 13 Oct 2002 23:56, Paul Hammant wrote:
> This Registry thing I have made, will be replaced later with a pure JNDI
> solution (if I can get it working). The point being that no jar will
> need to be mounted at a low point in the tree as the JNDI classes are
> already in J2SE (the primordial classloader). It all depends on whether
> I can place instances perfectly in a VM-wide visible JNDI tree rather
> than serialized refs. Many hint that it is possible...
The issue essentially comes down to where the interfaces for the service are
stored. If the common service interfaces (and all their parameters) are
stored in system/common classloader then the services can be shared directly.
If not then no matter what you do you will need to serialize the calls (even
if it is just local serialization and deserialization in another classloader
context).
So how to do this with JNDI? What I would suggest is that you create a class
with some static Map of services that can be registered or unregistered as
you want. See JBosses NonSerialialzableFactory (or something) for an example
of this.
Then you register a Reference in JNDI and associate it with a ObjectFactory.
The ObjectFactory would then retrieve the object from the
NonSerialialzableFactory and if the classloader different create a
local/pipe/whatever connection.
Hmm thats not exactly clear. Maybe if I put it in point for, :)
* Create an AltrmiObjectFactory that implements JNDIs ObjectFactory. It will
use the local ClassLoader to create a Pipe/local Socket connection to provide
object to "client".
* Create a NonSerializableFactory (NSF) which stores object reference in a
static map.
* When registering an Altrmi object into JNDI instead create a ReferenceObject
(associated with the AltrmiObjectFactory), store the physical object in NSF
and then bind it to JNDI.
* When the client accesses JNDI it will ask for object. The JNDI provider will
find the reference and use the factory to dereference the object (thus
containing the client end of AltRMI object).
Anyways I did this in a previous life and should be able to answer any
questions you have. However I would suggest you look at JBosses NSF (or
whatever it is called) as you seem to prefer code snippets ;) The code is a
bit convoluted but thats just JNDI ;)
--
Cheers,
Peter Donald
------------------------------------
The two secrets to success:
1- Don't tell anyone everything.
------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Inter-SAR communication
Posted by Peter Royal <pr...@apache.org>.
On Sunday, October 13, 2002, at 09:56 AM, Paul Hammant wrote:
> This Registry thing I have made, will be replaced later with a pure
> JNDI solution (if I can get it working). The point being that no jar
> will need to be mounted at a low point in the tree as the JNDI classes
> are already in J2SE (the primordial classloader). It all depends on
> whether I can place instances perfectly in a VM-wide visible JNDI tree
> rather than serialized refs. Many hint that it is possible...
JBoss does this (from looking at the new ECM/Jboss integration code).
It has a NonSerializableFactory that is used to bind ECM to JNDI (since
the ECM isn't serializable).. That may be a place to start looking for
hints...
-pete
--
peter royal -> proyal@apache.org
--
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>.
Daniel,
>>Until some formal structure is written, we are tied to something like
>>AltRMI. It is used bte cornerstone publisher and subscriber blocks as
>>well as the auto publisher. Unfortunately it means an over-sockets
>>mechansim until I can work out how to get and instance registered in
>>JNDI. I'm sure it must be possible, but can'd see how to do it.
>>
>>
>
>Have you considered implementing an Interceptor that first tries to use
>Reflection to call the appropriate method and upon failure use sockets?
>This could be accomplished with Proxies as of J2SDK 1.3.
>
The trouble with a speculative attempt to use something via reflection
is that phoenix will quite neatly hide things ffrom each other. Thus an
AltRMI client that wanted to do (simplified) ...
ThingService ts;
try {
ts = (ThingService) Factory.lookup("ThingService");
} catch (NotFoundException nfe) {
ts = (ThingService) OverSocketsFactory.lookup("ThingService",
"myhost:1900");
}
ts.thing("Hi");
.... it would never work on the local lookup in situations with
classloader trees in that thecontainer hides the Factory class in a
distant classloader to the client such that there are effectively more
than one Factory class in the partiular VM. They are of course
effectively completey different classes.
Using Reflection is the solution I have chosen for the 'Registry'
interim solution booked into CVS for AltRMI.
If that registry is mounted low in a classloader tree, and once only,
then it will be visible to multiple classloaders higher up the tree.
The client side logic uses reflection to narrow to it, but will not
fail if it can't find it at all. In that scenario it will just use the
sockets type to make the same connection albeit slower.
Actually on the issue of speed, it appears that local-loop sockets is
quicker than pipes in JDK 1.4. I'll have to do some debuggung to
determine if that is true. It never used to be in 1.3.
This Registry thing I have made, will be replaced later with a pure JNDI
solution (if I can get it working). The point being that no jar will
need to be mounted at a low point in the tree as the JNDI classes are
already in J2SE (the primordial classloader). It all depends on whether
I can place instances perfectly in a VM-wide visible JNDI tree rather
than serialized refs. Many hint that it is possible...
>Is there currently a JNDI provider that comes with Phoenix?
>
>
Nope.
-ph
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Inter-SAR communication
Posted by Daniel Krieg <dk...@kc.rr.com>.
> Until some formal structure is written, we are tied to something like
> AltRMI. It is used bte cornerstone publisher and subscriber blocks as
> well as the auto publisher. Unfortunately it means an over-sockets
> mechansim until I can work out how to get and instance registered in
> JNDI. I'm sure it must be possible, but can'd see how to do it.
Have you considered implementing an Interceptor that first tries to use
Reflection to call the appropriate method and upon failure use sockets?
This could be accomplished with Proxies as of J2SDK 1.3.
Is there currently a JNDI provider that comes with Phoenix?
--
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>.
Daniel,
>I am still new to using Phoenix and am currently working on the Sevak app. What is the standard approach to exposing the services of one SAR to another SAR?
>
>
Until some formal structure is written, we are tied to something like
AltRMI. It is used bte cornerstone publisher and subscriber blocks as
well as the auto publisher. Unfortunately it means an over-sockets
mechansim until I can work out how to get and instance registered in
JNDI. I'm sure it must be possible, but can'd see how to do it.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>