To use Webservices or not to use Webservices?

[00Kevin]

Hi Everyone,

I have an architecture design decision to make and I was wondering if there is anyone here that could help out. The one thing I have learned is that it isn't always a good idea to go with what is published in a magazine or to do it the way Microsoft says to.

My team is currently working on a large financial system that will be the core for a medium sized financial company. It will involve the development of just about every aspect of the business: AR, GL, Customers, Contracts, Leasing, Invoicing, Credit, Sales, etc…

Before I came on board the previous developers made the choice to use VB.NET and SQL Server for the systems main technologies. I'm more in favor of developing an ASP.NET application, but at this stage it is too late for that.

Anyway, my team is currently reviewing the various pros and cons of our multi-tier architecture. As it stands right now we have organized the system in the following way.

Solution A

1. Presentation Layer (VB.NET Windows Forms) (on client machine)
2. Web Services Layer (IIS server)
3. BAL (contains business objects) (on IIS Server)
4. DAL (contains sql helper functions) (on IIS Server)
5. DB (includes save sp's for every table etc) (on DB Server)

Under this architecture, our client application would be responsible to interact with the Web Services layer for every thing it does (saving data, retrieving data, etc.)

The problem we are all arguing about it weather or not we need to use Web services. Some people on our team are dead set against it and others like the idea as it keeps the system open to other applications. There are people on my team suggesting that we remove the Web Services layer and place the BAL and the DAL on the client machine. They are suggesting that it will increase the speed of the application. They have also stated that Web services should only be used if it is absolutely necessary. Their approach would look like the following

Solution B

1. Presentation Layer (VB.NET Windows Forms) (on client machine)
2. BAL (contains business objects) (on client machine)
3. DAL (contains sql helper functions) (on client machine)
4. DB (includes save sp's for every table etc) (on DB Server)

From what I can tell there are pros and cons to both. Some of the ones that stand out to me are:

Development Time: Is greater for Solution A. There are more layers to code and debug. Errors will be harder to trap with Web services.

Conceptualization: The code for Solution A will most likely end up being simple and easy to understand and functions in each layer will be smaller. There will also not be a lot of code in the client application. The level of abstraction from the db will increase as it approaches the presentation layer.

Maintenance/ Modifications: For solution B, every client machine will have to be updated every time a bug is fixed or a mod is created. This will be a pain unless we use an auto update tool. For solution A, there is one more layer to change for each mod.

Performance: I would suspect that Solution A would be a bit slower for the client.

Security: (my team is still talking about this)

If there are any experts on here that can offer some advice please do so. I don’t want this project to go down the wrong path.

I would really like to hear the arguments in favor of using web services. Nobody on my team has offered any good reason to use it or not to use it.

[Edneeis]

Why would you use it to communicate between layers? Or maybe this is just a symantic difference, but wouldn't the web service BE a layer? For instance the DAL would be a web service. Unless you have some specific plans to open up your web service then I'd pass on using it. It will degrade performance and may open up new security concerns. It might be easier to make standard components and wait for 'Indigo' to switch to web services.

[nswan]

If the application is going to remain internal then why not use remoting instead of webservices.

This is a great book on this kind of stuff:
http://www.lhotka.net/Articles.aspx?...2-b383f4b3474b

[00Kevin]

Originally posted by Edneeis
Why would you use it to communicate between layers? Or maybe this is just a symantic difference, but wouldn't the web service BE a layer? For instance the DAL would be a web service. Unless you have some specific plans to open up your web service then I'd pass on using it. It will degrade performance and may open up new security concerns. It might be easier to make standard components and wait for 'Indigo' to switch to web services.

Using web services to communicate between layers would alow us to develop a web client and a windows forms client. In addition, another platform with can interface with the web services layer via xml.

[nswan]

When you say web client do you mean something developed in asp.net?

[00Kevin]

Originally posted by nswan
When you say web client do you mean something developed in asp.net?

when I say web client I mean ASP, ASP.NET, or a even a non-microsoft technology that interfaces with the web services layer (intranet)

There are parts of the application that will be web based, but most will be windows forms based. For example there is a module for sales people. They need to access it remotely from their laptops. Connection speeds may not be all that great for those people.

I think that if we use web services we gain the advantage of creating any sort of client(s) we want.

[nswan]

well if they are remote clients and they don't have a VPN connection then it is probably a good idea to use webservices.

I would consider creating webservices for the remote windows applications but for everything else use remoting, as from what i've done webservices seem quiet slow. I know it's more development though.