Hello,
> I read your proposition. And I like it, but for us to make the first
> implementation simple and elegant, I feel it would be better to focus only
> on Java-RMI clients. This way we can implement logic in the stub
> so that we
> don't have to "pin" objects once they are created by the home interface.
I agree that the stub mechanism can provide much more sophisticated
client-side behaviour. Nevertheless, using CORBA does not mean our objects
are "pinned" to a particular destination. The CORBA IOR mechanism allows
what is called a multi-profiles IOR (IOR = object reference) i.e. you add
many target object references to a single IOR you give back to the client.
Then, on the client side, if an invocation fails with the first profile
(i.e. the first target object), it is up to the CORBA subsystem to
automagically try to reconnect to the next available profile (and so on) =>
there is already some failover mechanism ready in CORBA and implemented
since spec > 2.2 I think
For the RMI vs CORBA issue, I think that J2EE moves quite strongly in the
CORBA direction (confirmation?) Consequently, it is most probably preferable
to directly have a CORBA compatible JNDI space (i.e corba interoperable
naming service)
> The notion of "only one" JNDI space, could you elaborate more?
> Meaning that
> each deployment on each server would be identical?
No. Exactly the same JNDI space would be replicated on each server but it
does not mean that each node need to deploy every application. You need to
split the JNDI replication from the bean deployement =>
- The JNDI space is completely replicated on (possibly) all server
- Our JNDI implementation would be extended to allow more than one binding
for the same name i.e. key => (vector of (IOR + node info)[] + pluggable
load balancing algorithm)
- when we deploy a bean, we tell how it should be deployed. E.g. : "our
application must run on at least two nodes, starting with A and B, and, in
case of problem, can also use nodes C, D and E (but not F and G) and node C
should already be prepared in stand-by (application already waiting).
Whatever node this application run on, it should be in its own JVM." not
mandatory to implement everything from the start ;) just some ideas...
- During the deployement, each node repeatedly tells the JNDI space that it
wants to bind reference R1 to name N1 (for each binding to be done). The
node sees the JNDI space as a single entity: it is the responsability of the
JNDI space to replicate its content to all other JNDI replicat.
- As the node knows how to use this extended version of the JNDI space
(i.e. that allows multiple references per name), the binding is not a
problem.
- As the client does not know how to use this extended version of the JNDI
space, it simply lookups a name and receives a reference
- when a JNDI replicat receive a lookup query, it decides, thanks to some
algorithm, which reference to build and how
Consequently, node C may not have application A1 deployed on it but the JNDI
replicat on this same node C, as every other replicat, knows everything
about the bindings, event the bindings originating from application A1
deployement.
=======================================================================
| NODE 1 | NODE 2 | NODE3 |
=======================================================================
JNDI |App1/BeanAHome |App1/BeanAHome |App1/BeanAHome |
SPACE |App1/BeanA |App1/BeanA |App1/BeanA |
|App2/BeanBHome |App2/BeanBHome |App2/BeanBHome |
|App2/BeanB |App2/BeanB |App2/BeanB |
=======================================================================
EJB | | | |
SERVER | App1 running | App1 running | App1 running |
| App2 deployed but | App2 running | |
| in standby backup | | |
=======================================================================
If I find time, I would like to elaborate these ideas in some sort of RTF
document or whatever else.
Nevertheless, I a sure that one of the most challenging part is the
administrative part. It will make the difference between an easy to use
clustering solution and a nightmare.
Cheers,
Sacha
