System Architecture Question

[Chris L]

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

 

[John Saunders [MVP]]

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.

 

[Registered User]

On Fri, 17 Aug 2007 18:10:03 -0700, Chris L <Chris

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.