All,
Wouldn't this solution be slow? Not intimate with
SOAP but would the addition of tags bloat the volume
of data shared between servers..
JINI seems like a pretty cool idea...
peter
--- YM_M4I5S3S_1 Lev <[EMAIL PROTECTED]>
wrote:
> 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 YM_M4I5S3S_4
servers. This
> however require a
> YM_M4I5S3S_5 in case the central serval fail as well
as
> backup server, working
> like YM_M4I5S3S_6 domain server, backup domain
server and
> cached users for
> YM_M4I5S3S_7.
>
> YM_M4I5S3S_8 Lev
> YM_M4I5S3S_9 - the YM_M4I5S3S_10 Catalog Company
> WWW.YM_M4I5S3S_11.COM Phone:972-9-7447201 ext 209
> Fax:7447202
> email: [EMAIL PROTECTED]
>
> > -----Original Message-----
> > From: YM_M4I5S3S_14 YM_M4I5S3S_15
[SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, December 20, 2000 9:19 PM
> > To: YM_M4I5S3S_18 Developer
> > Subject: Re: [YM_M4I5S3S_19-YM_M4I5S3S_20] using
YM_M4I5S3S_21 for clustering
> >
> > sorry for the intrusion. I believe YM_M4I5S3S_22
can
> still be used.
> > the YM_M4I5S3S_23 however will be used between the
> YM_M4I5S3S_24, to broadcast
> > changes in one cluster instance.
> > so even if your YM_M4I5S3S_25 are outside the
> firewall, they should not use
> > the
> > YM_M4I5S3S_26 messages.
> >
> > so YM_M4I5S3S_27 will work here, however, using
YM_M4I5S3S_28
> will limit your clusters
> > to
> > one subnet, due to a restriction with multi cast.
> > the YM_M4I5S3S_29, will have to be "cluster-aware"
> through a plug in, that
> > points them to the cluster.
> >
> > please comment, I'd like to learn more
> > YM_M4I5S3S_30
> >
> > ----- Original Message -----
> > From: "YM_M4I5S3S_31 Guthrie"
<[EMAIL PROTECTED]>
> > To:
<[EMAIL PROTECTED]>
> > Sent: Wednesday, December 20, 2000 11:03 AM
> > Subject: [YM_M4I5S3S_36-YM_M4I5S3S_37] using
YM_M4I5S3S_38 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 YM_M4I5S3S_39 uses
YM_M4I5S3S_40 for
> lookup). This will
> > not
> > > be a big problem in most cases since the most
> common case is to use a
> > > YM_M4I5S3S_41 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
(YM_M4I5S3S_42
> 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 "YM_M4I5S3S_43" subnet, and
YM_M4I5S3S_44 servers
> and database in a
> > protected net:
> >
> > firewall ---> (YM_M4I5S3S_45) web servers --->
firewall --->
> YM_M4I5S3S_46 server -->
> > databases
> >
> > Sometimes the second firewall (between web and
> YM_M4I5S3S_47) is eliminated and
> > basic YM_M4I5S3S_48 is all that is used. In either
> case, YM_M4I5S3S_49 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"
> >
> > -YM_M4I5S3S_50
> >
> >
> >
>
__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
