Another solution is to use HTTP soap to talk between the servers over the
firewall. There here a need to all server to know of central server and
register
and request the register list of app servers. This however require a
cach in case the central serval fail as well as backup server, working
like NT domain server, backup domain server and cached users for
autohentication.
Adi Lev
Cardonet - the Transactive Catalog Company
WWW.CARDONET.COM Phone:972-9-7447201 ext 209 Fax:7447202
email: [EMAIL PROTECTED]
> -----Original Message-----
> From: Filip Hanik [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, December 20, 2000 9:19 PM
> To: jBoss Developer
> Subject: Re: [jBoss-Dev] using Jini for clustering
>
> sorry for the intrusion. I believe multicast can still be used.
> the multicast however will be used between the appservers, to broadcast
> changes in one cluster instance.
> so even if your webserver are outside the firewall, they should not use
> the
> multicast messages.
>
> so JINI will work here, however, using multicast will limit your clusters
> to
> one subnet, due to a restriction with multi cast.
> the webserver, will have to be "cluster-aware" through a plug in, that
> points them to the cluster.
>
> please comment, I'd like to learn more
> Filip
>
> ----- Original Message -----
> From: "Rhett Guthrie" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, December 20, 2000 11:03 AM
> Subject: [jBoss-Dev] using Jini for clustering
>
>
> Just browsing the archives for info on the clustering strategy. At one
> point I read the following:
>
> > The drawback of this solution is that the client and server has to be
> on
> > the same subnet (because Jini uses multicast for lookup). This will
> not
> > be a big problem in most cases since the most common case is to use a
> > webserver as client, which almost always is on the same subnet. If
> > anyone objects to this assessment, please let me know and I will take
> > into account clients on different subnets (Jini can work in this case
> > too, but not as dynamic).
>
> I would definitely take it into account. I even question the claim "the
> most common case...". A very common deployment for security is to have
> the web servers in a "DMZ" subnet, and app servers and database in a
> protected net:
>
> firewall ---> (DMZ) web servers ---> firewall ---> app server -->
> databases
>
> Sometimes the second firewall (between web and app) is eliminated and
> basic subnetting is all that is used. In either case, multicast may not
> be the way to go.
>
> These deployments are usually used when security is a large concern. As
> architects, we have to balance competing forces like flexibility,
> manageability, security, availability, scalability, etc. As platform
> "vendors", you have to decide what kind of deployments you want to
> support. The kind I described here (which is common based on my
> experience) may or may not matter to you.
>
> As a friend of mine is fond of saying, "food for thought, eat what you
> like"
>
> -rg
>
>
>
