Hi!
Rhett Guthrie wrote:
> > 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.
Note the parenthesis quote. The difference is just that instead of
having dynamic JNDI lookup ("Gimme cluster FOO!") you'll have to say
"Gimme cluster Foo at somehost.com". That's all. Less dynamic, but still
working.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
