|Can you elaborate on the "clustering of invokers"? How will a SOAP client
|allow for fail-over? Does SOAP have something like multiple-profiles like
|IIOP?
|
|Also, can you point me and Sacha to the people that are detyping and
|detaching the invokers? We need to know about this stuff, because our
|clustering implementation will probably be directly affected by this and
|vice versa.
yes, that is scott and me... Sacha saw the presentation in London and I hope
it made sense (it was stuff I was making up as I went :). Seriously now I
gave the presentation with 10 days in CVS behind me but the picture is
getting clearer.
Essentially:
The proxy on the client when we send a java class on it can keep a list of
targets, pretty much like what you are doing with the current design. Of
course the following will apply to clients with Java stuff (smart) for dumb
clients the layer described below will need to live on the server but the
generic 3 layer stuff I am about to describe is solid imho.
I will also stress that it doesn't deeply affect your work (the only thing
is the EJB invoker detachment) so it is just a generalization of your most
excellent work. The other thing that might change is the HAJNDI stuff which
is a "special" case in your design while I suspect it might fall under the
generic clustering case... we will see.
The detyping means that the invokers now is talking to one JMX node at a
time as opposed to a target EJB. The invocation is done through the JMX
dynamic MBean interface (uber fast). Once we have that and we know which
services are clustered (it requires your excellent (and quite generic) state
replicator) the invokers can proxy the invocation to the target nodes, one
by one, in round robin or even with multicast for the simplest state
replication in the world (fail over).
The point I was making is that the infrastructure to cluster these invokers
in a given proxy client is largely independent of the type of service being
clustered. I see three layers but I have to do the code, the first layer is
the generic one with the proxy creation. On top of the proxy we will need
to put some domain specific logic for example it can be a stateless EJB or
an entity EJB or any service that can leverage client local logic on top of
the generic proxy. Then there is the invokers and the JMX bus with creation
of MethodInvocation that I suspect will generalize itself in
"MessageInvocation", the role of this layer is to get the invocation through
any distribution (IIOP/SOAP/RMI/JMS/Socket) and generate a MI. The thrid one
is state replication and that is I think somewhat addressed in your current
design if I understand Sacha's material. It is quite good and my point is
that it is somewhat orthogonal to the other issues.
My guess is that we are really looking at the webOS this time. We got it it
is real.
BTW Microsoft "research" is now writing on the webOS and describing the
features that we are implementing. What a bunch of bozos. Fire them all,
WE already have it, they can only TALK about it. MS-webOS 3.2 (millenium)
will look like JBoss 3.0 and we will be a success.
Here is the link
http://research.microsoft.com/research/sn/Millennium/mgoals.html
Let's lead the way with 3.0, we are way ahead and they will need to copy us
in C$
regards
marcf
|
|Thanks,
|
|Bill
|
|
|
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
