Question regarding software architecture

Question

Hello.

Currently, I am working on a Loans application for one of our clients. The details of our project is specified below:

-It is based heavily on a former Oracle Forms(front-end)/Oracle 10g system(back-end)
-It is basically a migration from Oracle forms to .Net, because I think, the management prefers the new look that ASP.Net pages give to the users and they'd like to improve the layout of the screens. The back-end will still be Oracle 10g
-For some reason, there is also a management directive that was given out that we will be creating Web Services to make the former stored procedures of the Oracle applications "modular" (ie: split them to atomic pieces of procedures so that it is possible to call the procedures through the web services if there are other applications that need to use it)

From my understanding, much of the business processes involved with the project we are doing are basic create/read/update/delete operations. With this in mind, I thought, "If I were to design the system, I'd use the n-tier approach...and just have the data access layer do all the basic CRUD operations, then encapsulate ALL the business rules in a business layer in .Net"

For some reason, management did not like that approach again. They said that majority of the business rules (Yes, even validations for null fields, or complex/simple computations) should be in stored procedures and should only be available through web services that we will write. I am not sure whether this is a good idea or not. In some online articles I have read, it said that we should always question the use of web services when all it does is to do CRUD operations and do some very basic validations like checking for null values or checking if a value selected from a drop-down list exists in your table (Which, by the way, I think is retarded, since we are also going to provide a web service to populate the said drop-down list in the first place with data coming from our DB. I cannot understand why we still need to check for the validity of the selected value if all possible values in the drop-down list will be coming from the back-end in the first place).

My main question here would be, for CRUD operations, is a Service-Oriented-Architecture a good fit or will we be better off using an n-Tier architecture instead?

Another thing that I was concerned with was that most of the web services we will be creating will be returning datasets for a list of values derived from a query to the tables and that the parameters we are going to pass are also datasets. From my understanding, our technical architect's solution for a n"add" operation would be something like:

1. Front-end guys will put the data they got from the users into a dataset
2. Front-end guys will call our web service and pass the dataset
3. Back-end guys (that's us) will receive the dataset and pick out data row 0 (since we're only usually inserting one row at a time) then pass it to our data access layer, construct the parameters needed for the command, then execute the command.

I asked the architect why we can't just come up with an architecture of business objects/classes that we can use instead of datasets as, I have read that classes are better "performance-wise" since they are a lightweight holder of data and you can probably do a better job of manipulating them with regard to the business process that the application will do, but here are his rebuttals:

1. When the db/table schema changes, you'd need to change your object/classes architecture as well, thus, it's added maintenance. With datasets, you can just get the db/table schema, put it in an xml file or use xml readers/writers and then pass it to the front-end guys and it's much easier to do than using classes.

2. Classes/objects are a pain to pass through web services as parameters/return types.

I have not come up with a response to this yet as I am weighing the pros and cons of using classes vs. using datasets that is why I am asking for your opinions. He had a valid point regarding manually-coding the classes again in case the db/table schema changes, but I don't know if there are tools or methods out there that are already existing that can be used to work around this limitation.

As far as passing classes/objects through web services as parameters/return types, I am still researching on this one and it would be great if someone could shed light on this issue. I do agree that in terms of serializing data to/from the front-end guys, datasets are a much easier option, but I don't know if this is the best way to do it in the long run or we will be having some problems in the future because of some limitation that comes with it.

Sorry for the long post. Thank you.