Really Useful Stuff
1/1/2003 1:35:00 AM
You're thinking in terms of single application single server or worse single
application multiple server - not a popular mode of operation given the IT
spending climate. We never run our shared sql boxes at such low levels of
utilization, and we never let projects put application components on the
DBMS machine. If you're app will never see the light of day outside of
your company do what you wish, but no way is mixing workloads in the
distributed world an economy in the large scale. Placing tiers on shared
machines that host only one tier provides the utmost in econmoics,
scaleability and performance - the network penalaty is a legacy conception
from the days of 10/100Mb single duplex networks.
"edward Taaffe" <edward@clickit.co.uk> wrote in message
news:ausgbf$9mc$1@newsg3.svr.pol.co.uk...
> You may well be right on this one, but in this case I am considering it
> because I only intend placing web services there and their only purpose
will
> be to query the database via stored procedures and pass the data to a
> calling business object.
> It is rare that a sql sever uses more than 8 or 10 percent of the machines
> processing capability which should mean ample processing, The memory would
> be beefed up to match the need and there is virtually no storage
> requirement.
> If you take into account the fact that there is no network jump to the
> database, I find it hard to see how this would not perform well.
> In the event that it does not perform the entire assembly can be xcopied
to
> another server and run there with no changes.
>
> All of the above of course is theory in this case and I appreciate any
> arguments you may offer.
>
> --
> Regards
>
> Edward Taaffe
> ______________________________________
> www.clickit.co.uk
>
>
> <news@news.com> wrote in message news:uZp0sENsCHA.1132@TK2MSFTNGP12...
> > Putting application components on the same machine as the DBMS for
> > performance is a layperson's misconception, and in even modest sized
> > implementations, often provides worse performance and certainly always
> worse
> > scalability
> >
> > "edward Taaffe" <edward@clickit.co.uk> wrote in message
> > news:aus5j3$94e$1@news7.svr.pol.co.uk...
> > >
> > > A few other issues which someone may care to comment on:
> > >
> > > How easy is it to create a loosely coupled solution with web
services.?
> > > e.g. if the service can not deliver a reply I need the application to
> > > proceed. Obviously I can deal with this in the calling objects but
will
> > > there be a process hanging on the server where the web service failed?
> > >
> > > Is it feasible at this point to provide fairly sensitive data via web
> > > services beyond the firewall. I.e. homeworkers people on trains with a
> > > laptop etc.?
> > >
> > > Any comments greatly appreciated.
> > >
> > >
> > >
> > >
> > > --
> > > Regards
> > >
> > > Edward Taaffe
> > >
> > >
> > > "edward Taaffe" <edward@clickit.co.uk> wrote in message
> > > news:auq7j3$b16$1@newsg3.svr.pol.co.uk...
> > > > Hi all,
> > > > I have spent the last few days tying to decide on a pattern to use
for
> > > > future enterprise solutions.
> > > > I currently use ntier dna and I am convinced of the benefits here
but
> I
> > am
> > > > always willing to listen.
> > > >
> > > > My basic plan is to create a new data access layer to hide the sql
> > server
> > > > databases , flat files and mailstore.
> > > >
> > > > I won't interfere for now with the com stuff that is running.
> > > > I intend to run the data-access layer on the same server as he main
> sql
> > > > server because it has loads of spare capacity apart from beefing up
> > > memory.
> > > > I am told this gives top performance.
> > > >
> > > > I intend to run all of the business rules classes/components on
middle
> > > tier
> > > > server, this can scale to many if needed.
> > > >
> > > > I intend to run all of the intranet apps and on an existing web
sever
> > with
> > > > the .net framework installed. The web server would also be accessing
> > this
> > > > business rules layer as would some legacy apps. I have discovered
that
> I
> > > can
> > > > easily expose some of the .net classes with com interfaces for
> backward
> > > > compatibility and I can live with a small performance hit.
> > > >
> > > > I don't rate the web farm type of set-up here because one web server
> can
> > > > service a phenomenal amount of requests and it really is the
> > applications
> > > > which need to scale. Also I have a mixture of apps not all web based
> and
> > > > finally the whole web farm thing is in the other direction form .net
> > IMHO
> > > >
> > > > I have experimented with web services and I like them a lot, they
> would
> > > give
> > > > me amazing flexibility to expand the system to share with partners,
> > > service
> > > > users in the field etc. Also I have a requirement to pass data via
> xml
> > in
> > > > all network hops.
> > > > I can not figure out how I might pass this data through layers of
the
> > app
> > > > without jumping the gun e.g updating direct to the database.
> > > >
> > > > If I use a web service can I then read his xml into a dataset ?
> > > > If I do it this way how do I update this back to the database via
the
> > data
> > > > access layer?
> > > > I thought of passing the whole dataset back, but only if I can
> serialise
> > > it
> > > > to xml - can this be done?
> > > >
> > > > Sometimes I will need to build the interfaces via xml and xsl should
I
> > > take
> > > > a different approach in this instance?
> > > >
> > > > I played with the vs.net proxy stubs, they are easy to build but are
> > they
> > > > raise some questions I.e
> > > > is there any point in building new business objects when a dataset
or
> > Dom
> > > is
> > > > itself a business object.
> > > > Could these objects now be used and extended with extra methods in
> .net
> > or
> > > > am I jumping the gun.?
> > > >
> > > >
> > > > Any suggestions or ideas would be welcomed and I will be happy to
> share
> > my
> > > > conclusions and findings with everyone.
> > > >
> > > >
> > > > Edward
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Regards
> > > >
> > > > Edward Taaffe
> > > > ______________________________________
> > > > www.clickit.co.uk
> > > > ___________________________________
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>