an excellent email from Sacha, back to the list (hope you don't mind sacha)
point below
|Hello Bill,
|
|I just take this off the ML... We will do exactly the same as now. The
|difference is that instead of keeping container RMI remote
|references in our
|smart proxies, we will keep RMI remote reference of the generic
|RMI MBEAN of
|our node/Jboss instance + the name of our container. Thus, all invocations
correct
|will go through this RMI invoker and, thanks to the additional container
|name (i.e. it is a routing information for a JMX node), the invoker will
|transmit this to the JMX bus.
correct
|As you already told me, you think we will have performance problems with
|this scheme: you had this problem with Orbix 2000, when a single server
|socket was overused, it didn't scaled. So we may need to create additinals
|RMI invokers MBEAN "on-the-fly" for some of our containers but the scheme
|will stay the same.
If we *really* need more sockets then we can open ports on the RMI front and
have new clients talk to these. Say that we limit the number of clients on
a port we can always open new ports. The point is that the client will
still see the same invoker even though behind the scenes it is a round robin
on independent JMX nodes.
|For SOAP and other dummy protocols, as you said, we won't be able to have
|this smart client code. Consequently, we will most probably need to have a
|set of front-end JAVA dispatchers that will have the RMI smart proxies +
|some hard/soft load balancers in front of this (for IIOP, we do
|not need the
|hard/soft load balancers thanks to the multi-profiles IOR).
Yes, that is a good point, if there is no-one on the client, the load
balancer will be important. How we keep track of sessions there will also
be important, is there a notion of sessions (as Servlet HTTPSession) in web
services? this is down the road though, we will worry about it when we get
there.
|Are we all in-sync?
I am, you are quite right to stress that it is not a real departure from
your current design just an abstraction of it. In fact we are talking about
something I understood during your presentation Sacha... I am really looking
forward to Bill's presentation in Las Vegas as it will be even more precise
and maybe even some code by then (if I get down to it).
marcf
|
|Cheers,
|
|
|
| Sacha
|
|
|
|
|> -----Message d'origine-----
|> De : [EMAIL PROTECTED]
|> [mailto:[EMAIL PROTECTED]]De la part de Bill
|> Burke
|> Envoy� : lundi, 24 septembre 2001 16:38
|> � : [EMAIL PROTECTED]
|> Objet : RE: [JBoss-dev] RE: [JBoss-user] Open letter: ZOAP is dead, long
|> live JBossSOAP!
|>
|>
|>
|>
|> > -----Original Message-----
|> > From: [EMAIL PROTECTED]
|> > [mailto:[EMAIL PROTECTED]]On Behalf Of marc
|> > fleury
|> > Sent: Monday, September 24, 2001 10:06 AM
|> > To: Jboss-Development@Lists. Sourceforge. Net
|> > Subject: [JBoss-dev] RE: [JBoss-user] Open letter: ZOAP is dead, long
|> > live JBossSOAP!
|> >
|> >
|> > Cleaning up my mail box...
|> >
|> > I believe this is a clear match for RH.
|> >
|> > Jung, the microkernel arch with JMX bus plugs nicely with the detyped
|> > invokers and adding an XML invoker is still a bit priority. In
|> > fact I don't
|> > see a reason why any service in JBoss wouldn't be invocable
|through SOAP
|> > that is the power of the detaching going on in RH.
|> >
|> > BTW the same logic applies to the clustering of the invokers...
|> I will try
|> > to show that in the coming days,
|> >
|>
|> 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.
|>
|> 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
