On Oct 21, 2005, at 10:03 AM, Jules Gosnell wrote:
I've been thinking about what we can get done for Geronimo-1.0. We
hope to get WADI into it. and I have come up with a few questions.
I hope you don't mind if I throw them at the list :-)
EJB stubs can be converted to handles, which are serialisable and
my be migrated in a web-session from node to node.
Cool, that's how we serialize stubs right now.
My question is, if we do this, and then rehydrate an OpenEJB stub
on another node, will it find the correct EJB container OK when we
come to use it?
It should.
What is encoded in the handle ? EJB class, PK for Entities, JNDI
name, server address:port etc - or is it just an opaque int that
only makes sense to the server from whence it came, except, having
only got the handle, you don't know where it is :-(
We do the first one plus home and remote interfaces. In addition,
there is primary-key-like thing for stateful session bean identity.
Second question - If we stick to SLSB and Entity, could we send the
handle to a different OpenEJB container and still receive service ?
Since the container should be able to run a SLSB or entity
invocation with just the context known to the stub - class [and PK].
The answer is yes if you talking about a scenario where a proxy
(handle) which points to Server A is sent directly or indirectly from
Server A (or a client of Server A) to Server B. When code on Server
B attempts to use the proxy, it should successfully contact Server A
so Server A can execute the call.
or am I off in la-la land :-) - it's been a while since I used EJB,
especially clustered ones...
No, you've pretty much described exactly how our protocol works.
It's stateless for the most part which makes each individual proxy
very durable. We do have some shared aliasing that can take place
between a client proxy and a server, but it's easy for the server to
say "what?" and reset that state.
La-la land is the next step where you can replicate instance state
from one server to the next then give clients a 302-like redirect to
the server holding the new state. I've been kicking that one around
in my head for a while and would be really easy to add in the
protocol if we actually had some way to replicate instance state from
one server to the next.
If all of this works, then we could go live with "clustered" (but
not HA - yet - might not be too much work to put this into client
side interceptor...) SLSB and Entity in G1.0. Later we need some
cluster aware stubs, clustered jndi and SFSBs etc...
Yea, there are a lot of cool things we can do. I can crank out
protocol improvements pretty quickly, so if you have a specific
feature you need, just let me know.
hope that is not too confusing,
Nope. I'm pretty impressed you managed to nail the system down so
well without looking at any code.
-David
