Use of Application Server

[Varkey]

Dear friends,

I am new to .NET based app development and have a pretty elementary
query, I suppose... I have caught up with the basics of .NET pretty
well, thanks to some Microsoft VB/ASP background and helpful
colleagues...
The query goes...

In a DOTNET based desktop application environment, does it make sense
to have each copy of the installed application from the different
machines talk directly to the SQL Server Database. Or do you suggest
the use of an Application Server??? Logically, there has to be some
threshold after which SQL Server cannot takeup the load and the
multiple number of connections.. So connection pooling and etc etc...
features of App Server got to be useful, I suppose..

Now coming to the most baffling part of the question. Extending the
logic that an App Server might be needed( I had read somewhere that
COM+ Services can act as App Server.. That is great!!!), where is this
to be hosted?? If this is going to be a seperate server, then how are
the different client machines to talk to the database? They will have
to create objects of the classes and invoke methods in the App
Server!!!! Now how is this to be done, as we are talking about
different machines..... Is it what they use Remoting for??? If yes,
how performance efficient is it for a realtime application with say
100-200 users? If no, then what is the ALTERNATIVE????

Hoping to get a convincing response fro . IT would be fine if you can
guide me to some good material to quench my curiosity..
Thanks and regards,

:)

[Nick Malik]

Boy, you must have one heck of an application to be worried about this level
of scaling...

So, if you want to scale a desktop client environment...

First off, why a desktop client environment? That's the first point in
scaling and security... in a web environment, you can hide that db server
behind a secondary firewall. With a client/server environment, you have a
db server out in the open, ready to be attacked... Web servers tend to have
more efficient interfaces... not always, but usually.

Now, assuming a desktop environment...
Sure, you can use remoting to access the application server, but you won't
see an improvement in *performance* until you scale quite a bit. A single
managed code component can not handle more concurrent connections than the
finely tuned communication layer that SQL Server uses. To see a performance
increase on an app server, you have to have three or four of them (my
guess), and you'd have to be using them in some way where they can minimize
the hits on SQL (like with caching, or async updates). No, App servers are
not normally something you do for performance. At least, not one at a time.

So, what if you do want to improve performance? For queries, you still have
to use synchronous messages, but for updates and inserts, I'd suggest async
messages, sent over HTTP, to a load-balanced array of machines using SOAP
web services. As connectionless and as stateless as you can possibly get
away with.

Does that help?
--- Nick

"Varkey" <va**********@y ahoo.com> wrote in message
news:ea******** *************** ***@posting.goo gle.com...

Dear friends,

I am new to .NET based app development and have a pretty elementary
query, I suppose... I have caught up with the basics of .NET pretty
well, thanks to some Microsoft VB/ASP background and helpful
colleagues...
The query goes...

In a DOTNET based desktop application environment, does it make sense
to have each copy of the installed application from the different
machines talk directly to the SQL Server Database. Or do you suggest
the use of an Application Server??? Logically, there has to be some
threshold after which SQL Server cannot takeup the load and the
multiple number of connections.. So connection pooling and etc etc...
features of App Server got to be useful, I suppose..

Now coming to the most baffling part of the question. Extending the
logic that an App Server might be needed( I had read somewhere that
COM+ Services can act as App Server.. That is great!!!), where is this
to be hosted?? If this is going to be a seperate server, then how are
the different client machines to talk to the database? They will have
to create objects of the classes and invoke methods in the App
Server!!!! Now how is this to be done, as we are talking about
different machines..... Is it what they use Remoting for??? If yes,
how performance efficient is it for a realtime application with say
100-200 users? If no, then what is the ALTERNATIVE????

Hoping to get a convincing response fro . IT would be fine if you can
guide me to some good material to quench my curiosity..
Thanks and regards,

:)

[Varkey]

Dear Nick,

Thanks a lot for your response... It certainly has helped with a lot
of my queries.. If I read you right, you are suggesting that in such a
scenario, an APP Server need not be used and if at all scalability is
a concern, there should be multiple App Servers to cater to the
requirement.... Correct me if I am wrong...

Also can I take the liberty of going one step further and ask, "What
do you think is the scenario where an App Server is needed??"

To answer the query you had put up... Well, a desktop application is
preferred as the targetted users are more comfortable using a desktop
based application(got to do a lot with the predecessor of the
application) with a rich GUI...

The application will only be run in a LAN environment with AD based
security, and so I reckon the Security bit should not be a major
concern... Ofcourse, feel free to correct me if you feel so...

Thanks once again for the response.

Regards,

:)

"Nick Malik" <ni*******@hotm ail.nospam.com> wrote in message news:<2R4Mc.148 488$IQ4.38512@a ttbi_s02>...

Boy, you must have one heck of an application to be worried about this level
of scaling...

So, if you want to scale a desktop client environment...

First off, why a desktop client environment? That's the first point in
scaling and security... in a web environment, you can hide that db server
behind a secondary firewall. With a client/server environment, you have a
db server out in the open, ready to be attacked... Web servers tend to have
more efficient interfaces... not always, but usually.

Now, assuming a desktop environment...
Sure, you can use remoting to access the application server, but you won't
see an improvement in *performance* until you scale quite a bit. A single
managed code component can not handle more concurrent connections than the
finely tuned communication layer that SQL Server uses. To see a performance
increase on an app server, you have to have three or four of them (my
guess), and you'd have to be using them in some way where they can minimize
the hits on SQL (like with caching, or async updates). No, App servers are
not normally something you do for performance. At least, not one at a time.

So, what if you do want to improve performance? For queries, you still have
to use synchronous messages, but for updates and inserts, I'd suggest async
messages, sent over HTTP, to a load-balanced array of machines using SOAP
web services. As connectionless and as stateless as you can possibly get
away with.

Does that help?
--- Nick

"Varkey" <va**********@y ahoo.com> wrote in message
news:ea******** *************** ***@posting.goo gle.com...

Dear friends,

I am new to .NET based app development and have a pretty elementary
query, I suppose... I have caught up with the basics of .NET pretty
well, thanks to some Microsoft VB/ASP background and helpful
colleagues...
The query goes...

In a DOTNET based desktop application environment, does it make sense
to have each copy of the installed application from the different
machines talk directly to the SQL Server Database. Or do you suggest
the use of an Application Server??? Logically, there has to be some
threshold after which SQL Server cannot takeup the load and the
multiple number of connections.. So connection pooling and etc etc...
features of App Server got to be useful, I suppose..

Now coming to the most baffling part of the question. Extending the
logic that an App Server might be needed( I had read somewhere that
COM+ Services can act as App Server.. That is great!!!), where is this
to be hosted?? If this is going to be a seperate server, then how are
the different client machines to talk to the database? They will have
to create objects of the classes and invoke methods in the App
Server!!!! Now how is this to be done, as we are talking about
different machines..... Is it what they use Remoting for??? If yes,
how performance efficient is it for a realtime application with say
100-200 users? If no, then what is the ALTERNATIVE????

Hoping to get a convincing response fro . IT would be fine if you can
guide me to some good material to quench my curiosity..
Thanks and regards,

:)

[Varkey]

An additional Query on this topic

I had been going through a few websites.... and came across this
one...

http://www.eggheadcafe.com/articles/20021025.asp
Does this also state that it is not worthwhile to have an App Server
for an application like the one I have discussed below, but let the
office clients talk directly to the database....

Thanks and regards,

Varkey



"Nick Malik" <ni*******@hotm ail.nospam.com> wrote in message news:<2R4Mc.148 488$IQ4.38512@a ttbi_s02>...

Boy, you must have one heck of an application to be worried about this level
of scaling...

So, if you want to scale a desktop client environment...

First off, why a desktop client environment? That's the first point in
scaling and security... in a web environment, you can hide that db server
behind a secondary firewall. With a client/server environment, you have a
db server out in the open, ready to be attacked... Web servers tend to have
more efficient interfaces... not always, but usually.

Now, assuming a desktop environment...
Sure, you can use remoting to access the application server, but you won't
see an improvement in *performance* until you scale quite a bit. A single
managed code component can not handle more concurrent connections than the
finely tuned communication layer that SQL Server uses. To see a performance
increase on an app server, you have to have three or four of them (my
guess), and you'd have to be using them in some way where they can minimize
the hits on SQL (like with caching, or async updates). No, App servers are
not normally something you do for performance. At least, not one at a time.

So, what if you do want to improve performance? For queries, you still have
to use synchronous messages, but for updates and inserts, I'd suggest async
messages, sent over HTTP, to a load-balanced array of machines using SOAP
web services. As connectionless and as stateless as you can possibly get
away with.

Does that help?
--- Nick

"Varkey" <va**********@y ahoo.com> wrote in message
news:ea******** *************** ***@posting.goo gle.com...

Dear friends,

I am new to .NET based app development and have a pretty elementary
query, I suppose... I have caught up with the basics of .NET pretty
well, thanks to some Microsoft VB/ASP background and helpful
colleagues...
The query goes...

In a DOTNET based desktop application environment, does it make sense
to have each copy of the installed application from the different
machines talk directly to the SQL Server Database. Or do you suggest
the use of an Application Server??? Logically, there has to be some
threshold after which SQL Server cannot takeup the load and the
multiple number of connections.. So connection pooling and etc etc...
features of App Server got to be useful, I suppose..

Now coming to the most baffling part of the question. Extending the
logic that an App Server might be needed( I had read somewhere that
COM+ Services can act as App Server.. That is great!!!), where is this
to be hosted?? If this is going to be a seperate server, then how are
the different client machines to talk to the database? They will have
to create objects of the classes and invoke methods in the App
Server!!!! Now how is this to be done, as we are talking about
different machines..... Is it what they use Remoting for??? If yes,
how performance efficient is it for a realtime application with say
100-200 users? If no, then what is the ALTERNATIVE????

Hoping to get a convincing response fro . IT would be fine if you can
guide me to some good material to quench my curiosity..
Thanks and regards,

:)