468,785 Members | 1,649 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,785 developers. It's quick & easy.

Using a Web Service for Business Logic BackEnd / Data Layer

Hi all,

I'm building a multi-tier web application that is primarily driven by a web
service back end.

Are there any configuration settings I should know about to increase the
performance of the site?

For example, if the site is going to service 100+ users, do I need to do
anything special to ensure IIS can contact my back-end webservice at the
highest possible throughput?

The webservice will be hosted on the same machine as the website.

The webserivce primarily interacts with a SQL Server database. DTOs are
passed back and forth between the web service and the web front-end
(ASP.NET web application).

Any hints, tips, etc. would be greatly appreciated.

Thanks!
Oct 18 '07 #1
4 1780
Not really, but if the webservice and the website are both hosted on the same
box, why do you need a webservice? Why not just have your Data layer talk
directly to the database - that would certainly be the fastest.
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

"Spam Catcher" wrote:
Hi all,

I'm building a multi-tier web application that is primarily driven by a web
service back end.

Are there any configuration settings I should know about to increase the
performance of the site?

For example, if the site is going to service 100+ users, do I need to do
anything special to ensure IIS can contact my back-end webservice at the
highest possible throughput?

The webservice will be hosted on the same machine as the website.

The webserivce primarily interacts with a SQL Server database. DTOs are
passed back and forth between the web service and the web front-end
(ASP.NET web application).

Any hints, tips, etc. would be greatly appreciated.

Thanks!
Oct 18 '07 #2
=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=
<pb*******@yahoo.yohohhoandabottleofrum.comwrote in
news:51**********************************@microsof t.com:
Not really, but if the webservice and the website are both hosted on
the same box, why do you need a webservice? Why not just have your
Data layer talk directly to the database - that would certainly be the
fastest.
Couple reasons:

1. I can move the front end to another server in the future for scalability

2. The backend web service can be used by other tools in the future :-)

In fact, we have a desktop administration tool which does site maintainance
through these the web service.

Oct 20 '07 #3
Peter Bromberg [C# MVP] wrote:
Not really, but if the webservice and the website are both hosted on the same
box, why do you need a webservice? Why not just have your Data layer talk
directly to the database - that would certainly be the fastest.
You'd think so but I've been thinking about this a bit myself recently.
If you're talking to your databases via something like nNibernate,
there's an initialization phase when setting up nHibernate where it
builds an map telling it how objects relate to database objects. This is
kind of a time consuming process and in a Windows Forms app you'd
usually only do this once, when the app was launching. In a Web app, as
with a windows app, you're going to have to do this, at the very least,
once each time the application domain gets loaded - however the app
domain can potentially get loaded a lot more often in Web Apps (and it's
not under your direct control when this happens)... and to achieve that
"just once" scenario in a web app you need to override the
Application_Start() event of the global.asax file and make sure you
store a thread safe reference to the object map in a static member that
is accessible to all the other threads in your web app (which doesn't
sound like it would be too hard).

Alternatively, you can have an NT Service application running a WCF
service or something, which takes care of all the DB work and
initializes that object map once and only once - when the operating
system boots and the service gets loaded. That WCF service is then
available to any threads in your web app (maybe via Named Pipes if it's
running on the same box, which has fairly minimal overhead aside from
the obvious serialization/deserialization) and which, as an added bonus,
can also be made available to other processes (potentially on remote
clients).

I'm not sure what kind of performance each of the above two
architectures would yield comparatively as I haven't tried them both yet
with the back end DB code and run any empirical analysis. However I'm
currently in the process of building a web app that needs to do a bunch
of stuff with databases which I've encapsulated in a MyAppService:
IMyAppService class (in a separate assembly). Initially I figured I'd
try the path of least resistance and simply add a direct reference to
that separate assembly to the web application project and instantiate
MyAppService directly in the code for the web app... if that's too slow
(which I suspect it will be) I figured I'd go the extra mile and yank
out all the stuff that initializes the object map for nHibernate and
make sure it gets called in the Application_Start() event of the
Global.asax file. If that still doesn't give the desired performance
then I'll try the second architecture - add some DataContract and
DataMember attributes to the IMyAppService interface and add some WCF
configuration sections into the config files of a separate NT Service
app (to host the MyAppService service) and the web application which
needs to consume this "service".

You can get better performance again with WCF services by using custom
binary serializers and the like, so if performance is really key and
you're using architecture number 2 then that's always on the cards as
well... although it involves writing more code and even though I'm a
programmer I'm always a bit loath to actually write code if I can avoid
it ;-)

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net
Oct 21 '07 #4
James Crosswell <ja***@microforge.netwrote in news:OmJm5sDFIHA.4400
@TK2MSFTNGP04.phx.gbl:
If you're talking to your databases via something like nNibernate,
there's an initialization phase when setting up nHibernate where it
builds an map telling it how objects relate to database objects.
I use LLBLGen Pro ... It has no caching, so there is no object
initialization delay (besides the standard instantation delays).

If you get a chance, give LLBLGen Pro a try. It can run in 2 modes, self-
servicing and adapter.

Adapter is akin to Datasets (disconnected).

Self-Servicing can fetch data dynamically... perfect for easy access to
data as you need it (hence no map building).

Performance with the web service layer is definately slower than direct DB
calls ... but the flexability it provides I think is worth it (it basically
makes all code reusable and more importantly distributable for redundancy).
Oct 23 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Ray5531 | last post: by
25 posts views Thread by Stuart Hilditch | last post: by
2 posts views Thread by Marin | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.