I have a client who is building a Human Resources web application on SQL 
Server 2000, C#, and .Net 1.1. It is a single system for internal company use 
only and does not actively interoperate with any other systems. There are 
hundreds of users with an average of approx. 50 concurrent. The app is 
accessed through a single web server which retrieves data from a SQL cluster. 
The architecture they have set up is as follows:

1) The presentation layer handles all business logic and data access.

2) No stored procedures are used. There is only inline SQL.

3) Data access is entirely through XML Web Services. The web server uses Web 
Services to talk to itself (and only itself). The resulting XML stream then 
has to be parsed in the presentation layer so that the individual data 
elements can be inserted into the correct controls

4) I'm a little fuzzy on the "save" process because I don't have access to 
the code, but I believe that it involves physically writing an XML file to 
the web server which is then somehow picked up and processed by web services. 
In beta testing, I have been repeatedly able to crash the application with an 
unhandled exception by putting an XML tag in one of the fields. BTW, their 
proposed solution to this is to put client-side JavaScript validation on 
every field to check for XML-related special characters.

5) The database is highly normalized. Ex: A simple phone/address report with 
16 fields requires 13 joins.

I would like to receive some feedback on what anyone thinks of this 
architecture, if anyone has seen a similar implementation (in regards to the 
use of web services) and if so what the results were.

Thank you,

-Chris

"Chris L" <Chris L@discussions.microsoft.com> wrote in message 
news:3DBA7473-78DD-4C91-9F03-D3AD0458B129@microsoft.com...

>
> I have a client who is building a Human Resources web application on SQL
> Server 2000, C#, and .Net 1.1. It is a single system for internal company 
> use
> only and does not actively interoperate with any other systems. There are
> hundreds of users with an average of approx. 50 concurrent. The app is
> accessed through a single web server which retrieves data from a SQL 
> cluster.
> The architecture they have set up is as follows:
>
> 1) The presentation layer handles all business logic and data access.
>
> 2) No stored procedures are used. There is only inline SQL.
>
> 3) Data access is entirely through XML Web Services. The web server uses 
> Web
> Services to talk to itself (and only itself). The resulting XML stream 
> then
> has to be parsed in the presentation layer so that the individual data
> elements can be inserted into the correct controls
>
> 4) I'm a little fuzzy on the "save" process because I don't have access to
> the code, but I believe that it involves physically writing an XML file to
> the web server which is then somehow picked up and processed by web 
> services.
> In beta testing, I have been repeatedly able to crash the application with 
> an
> unhandled exception by putting an XML tag in one of the fields. BTW, their
> proposed solution to this is to put client-side JavaScript validation on
> every field to check for XML-related special characters.
>
> 5) The database is highly normalized. Ex: A simple phone/address report 
> with
> 16 fields requires 13 joins.
>
> I would like to receive some feedback on what anyone thinks of this
> architecture, if anyone has seen a similar implementation (in regards to 
> the
> use of web services) and if so what the results were.


I dislike everything you mentioned. I see nothing good about this 
architecture.
-- 
John Saunders [MVP]

On Fri, 17 Aug 2007 18:10:03 -0700, Chris L <Chris
L@discussions.microsoft.com> wrote:


>
>I have a client who is building a Human Resources web application on SQL 
>Server 2000, C#, and .Net 1.1. It is a single system for internal company use 
>only and does not actively interoperate with any other systems. There are 
>hundreds of users with an average of approx. 50 concurrent. The app is 
>accessed through a single web server which retrieves data from a SQL cluster. 
>The architecture they have set up is as follows:
>
>1) The presentation layer handles all business logic and data access.
>
>2) No stored procedures are used. There is only inline SQL.
>
>3) Data access is entirely through XML Web Services. The web server uses Web 
>Services to talk to itself (and only itself). The resulting XML stream then 
>has to be parsed in the presentation layer so that the individual data 
>elements can be inserted into the correct controls
>
>4) I'm a little fuzzy on the "save" process because I don't have access to 
>the code, but I believe that it involves physically writing an XML file to 
>the web server which is then somehow picked up and processed by web services. 
>In beta testing, I have been repeatedly able to crash the application with an 
>unhandled exception by putting an XML tag in one of the fields. BTW, their 
>proposed solution to this is to put client-side JavaScript validation on 
>every field to check for XML-related special characters.
>
>5) The database is highly normalized. Ex: A simple phone/address report with 
>16 fields requires 13 joins.
>
>I would like to receive some feedback on what anyone thinks of this 
>architecture, if anyone has seen a similar implementation (in regards to the 
>use of web services) and if so what the results were.
>


A web service is simply a wrapper for some sort of remote
functionality. If that functionality is available locally, a web
service adds no value but provides unnecessary complexity. A server's
resources shouldn't be wasted by having the server serve itself.  A
more suitable wrapper should be used. 

From top to bottom this is an extremely poor design. 

regards
A.G.