Thanks Raf for your detailed answers !
For point 4, aren't stubs a scalability problem ? For instance, imagine this situation:
If I:
1- get a stub linked to a stateless bean S in "EJB Server 1"
2- then Server 1 crashes and the balancer knows that,
3 - then I call a method on S.
Will i get an Exception, or can the method transparently be redirected to "EJB Server 2" ? I think it is possible if implementing the "EJB Object" and "Stub class" appropriately (so the vendor should care). But would that be compatible with the
EJB spec ?
On example of what could be a server-vendor implementation that enables this behavior:
Stateless beans: To implement that we need first not to create a specific "EJB Object" for each client (because if we do that each subsequent requests on will have to be redirected to that specific EJBobject that lives on this specific server). So we need that the server creates - at startup time - one big "EJB Object for all stateless beans of type X" on each server. Then the returned stubs will need to have things like a "Client UUID, and the Virtual IP" .
Remote Entity beans: Same could be done as for entity beans. Each server has a big "one EJB Object for all beans of type X" , but the returned stubs have to know the primary key of the entity they are accessing, and the Virtual IP. For instance, if the client calls: entityAccount.setAmount(10); and that entityAccount has the pk #3000, the stub will send something equivalent to "call on VirualIPs EJBObject method entityAccoount.SetAmoun(#3000,10)", and each "big ejb object" on each server will know what to do: "take an entity bean, load it with Account #3000, ejbLoad, and then call method "setAmount(10) on the loaded bean"
Statefull bean: Not possible because the state of the bean lives on server1. So this will require complex "bean state" sync between the servers.
[ January 03, 2009: Message edited by: Jean-Luc Thirion ]
[ January 03, 2009: Message edited by: Jean-Luc Thirion ]
[ January 03, 2009: Message edited by: Jean-Luc Thirion ]
[ January 03, 2009: Message edited by: Jean-Luc Thirion ]