As I mentioned, Spring is a network operating system.
So, what I described to you just now, is how
object invocation works within a single node. But these doors
are confined to the nucleus on a single node. And
we need to be able to do object invocation
across the network. The client domain may be over here
and the server domain may be on a different node
on the local area network. Object invocation between client and
server across the network is extended using network
proxies. For example, on the client box there
is this Proxy B and on the server box, there is the Proxy A and proxies
can be potentially different for connecting to different
servers. So, this client may talk to this
server using this proxy. And may talk to
a different server, which I'm not showing here using
a completely different proxy. In other words, the
proxies can potentially employ different protocols. That's where you
have the opportunity to specialize. Whether the communication
that's happening between the client and server is on
the local area network or on a wide
area network, and so on. Depending on that, you
can employ the protocol that is appropriate for
use in the proxy. So, this is a key
property of building a network operating system in Sun
where they wanted to make sure that decisions are not
being ingrained in the operating system of a single
node, in terms of the connectivity of that node to
other nodes on the network. Depending on where the
servers for a particular client is going to be maintained,
that is where the location of the server is.
You can employ different protocols to talk between the proxies
that are on the client machine and the
server machine. And also the proxies are invisible
to the client and the server. In other
words, the client and the servers are unaware whether
they are both on the same machine or
on a different machine, and they don't care.
Let's see how this client-server relationship is established
using these proxies. So when a client-server connection has
to be made across the network. The first
thing that happens is, you instantiate a proxy
on the server node and establish a door
for communication between the Proxy A and the
server domain through the nucleus on the server
machine. And now what does Proxy A is
going to do, is to export a network handle
embedding this Door X to its peer proxy,
B that is on the client domain. And
see that this interaction that's going on between Proxy
A and Proxy B is outside of anything that is in the preview of the nucleus. So
the network handle that is being established has
nothing to do with the primitives or the mechanism
that are available in the nucleus of the Spring
system. So what proxy is doing, is to create
a network handle embedding this Door X. And
it is going to export that to this Proxy B
and Proxy B has a door that it has
established locally on Nucleus B so that the client
domain can communicate with it. And now what Proxy
B will do, is it will use the network
handle that has been exported by Proxy A to
establish a connection between the two nuclei. So this
network handle and the communication that goes on between
these two guys is not through the nucleus. That's
important for you to understand. So now, how does
the client make an invocation on the server domain?
Well, when the client wants to make an invocation,
it thinks that when it is accessing Door Y,
it is accessing the server's domain. But it isn't.
What it is. What it is accessing, is this
Proxy B and of course access to this Door Y, which is in Proxy B, is blessed by
Nucleus B, and when this invocation happens, Proxy B then is going to
communicate through this network handle that it
has with its peer Proxy A. And the
peer Proxy A, when it gets this
client invocation proxied through this Proxy B and
arriving at Proxy A, will know that oh, this
is really intended for the server domain. And I know
how to access that through the door that I
have in the server domain, and it uses the door
it has in the server domain in order to
make the actual invocation. So to recap, what is really
going on, the client wants to open this Door X.
It doesn't have a direct handle on Door X because
server domain is in a different node
of the network. And therefore, the way remote
invocation is accomplished, is by the server
domain's door which is the entry point into
the server domain, is passed on by this proxy via a network handle to its
peer proxy on a different node, in this case the client node. And once this
network handle is available to Proxy B, it
can establish the connection between these nuclei, and
once this connection is established. Then the client
domain, it thinks it is making an invocation
call for Door X, but in fact it is being passed through Door Y to this
proxy. And the Proxy uses a network handle
to communicate that invocation over to Proxy A
which then uses the actual door that will open the
invocation call under server domain and execute the client domain's call.