Newby High Level Design/Architecture Question

[Tobes \(Breath\)]

Hi there,

Firstly, sorry for the cross post. I didn't get a reply on the
dotnet.framework.webservices group so I though this group may be able to
help!? Or, perhaps my question doesn't make sense!?...

We want to rebuild a business application, and are considering using Web
Services in .NET. Our application will have between 50 and 100 users. There
is much data stored by the business, and various applications that access
that data. This business solution is distributed, with users accessing data
from all over the country/world! We are considering the following
architecture:

- Relational Database (MSSql or Postgres) at core
- A web services layer to encapsulate access to the database
- Clients (Win32 and Web) use services to fetch/modify data and carry our
operations

We hope it will bring the following advantages:

- Allow more business logic to exist in the services layer, or data layer,
without clients caring
- Allow for one-point of access to data
- Allow for alterations to be made to business logic without having to roll
out new Win32 clients

We're worried about the following:

- Webservices might bring a whole new set of problems to the table
(performance overheads, especially when being used to encapsulate data
access)
- It may cause problems mixing OO techniques, and Web services, and
relational database techniques in one project
- Additional development expense of extra layer, compared to the current set
up (VB6 apps talking directly to Sql Server 7 database)

Is this a generally accepted approach? Is there any MS documentation on
architecting small-medium bussiness applications? Also, I have found plenty
of docs describing how to create web services (it's made fairly easy in
..NET!), but haven't found many on structuring /partitioning services, or
naming them, or any general do's and don'ts!? Can anyone point me in the
right direction. Is there an underlying set of theory behind web services
that will help us in successfully applying them? (similar to how learning
relational theory can help you work with databases!)

I appreciate these are very general questions! Of course, we could quite
happily just dig in and start building our app, and perhaps that would be
the way to go, but it would be nice to get an overview. I've started reading
the W3C specifications for web services. I like these specs, but they ain't
exactly a "fun" read ;-)

Thanks in advance,

Tobin

 

[Pooran Prasad]

Hi Tobin,
As this is going to be a small application and assuming
that the application will be used within an Organization,
You have 2 options; .Net remoting and webservices. Decide
on this first.

Check these articles
http://www.developer.com/net/net/article.php/2201701
http://www.fawcette.com/vsm/2002_09_14th/online/holloway/
https://doc.telin.nl/dscgi/ds.py/Get/File-
26565/Brussel_web_services.ppt
http://www.dotnetjohn.com/articles.aspx?articleid=84

I personally find webservices good and quite easy to
implement than remoting After reading these you should
be able to decide which one to go for.

If you decide on implementing Remoting.. this is my
favorite link
http://www.ftponline.com/wss/2002_11/magazine/features/dbro
wning/

R. Pooran Prasad
Itreya Technologies Pvt Ltd.,
Mail: (e-mail address removed)
Phone (Off) : 5200179/80/81/82/83 Extn: 42
Mobile: +91 98860 29578

 

[Sami Vaaraniemi]

Hi Tobes,

Web Services are very convenient to get started with - even deceptively so.
The post by Pooran already lists some good links that get you started on
choosing the right technology. I'd like to add to the list Ingo Rammer's
Remoting FAQ and related pages that are a must read:
http://www.ingorammer.com/RemotingFAQ/RemotingUseCases.html .

Having built a business application recently similar to yours I can list
some practical issues you may run into when using Web Services as a remoting
solution (I won't list pros because the articles do pretty good job at it).
I'll address your worries first:

- Webservices might bring a whole new set of problems to the table

(performance overheads, especially when being used to encapsulate data
access)

This is true. If you plan on returning large result sets, SOAP
serialization/deserialization with Web Services will be many times slower
than what you will get with Remoting and a binary formatter. There are ways
to work around this, see below.

- It may cause problems mixing OO techniques, and Web services, and

relational database techniques in one project

True. Then again, if your client mostly just displays the data and does not
need to interpret it, you can simply return a DataSet bypassing the
relational-to-object mapping completely. If you need to work with the data
in the client, as opposed to just displaying it, then you may want to use
typed DataSets. Typed DataSets are sort of in between full fledged objects
and the relational model - they provide type safe access to your data while
also allowing convenient binding to e.g., a DataGrid for display purposes.

- Additional development expense of extra layer, compared to the current

set up (VB6 apps talking directly to Sql Server 7 database)

I believe that the benefits of separating business logic into its own layer
will outweigh the cost of developing an extra layer. The major benefits (in
addition to the ones you listed) are improved scalability and reusability.
Now your VB6 client has a connection to the database. This limits the number
of clients you can have running at any given time. With a separate business
layer on the server, your scalability improves because you can serve many
clients with just a few physical database connections (ADO.NET connection
pooling will do most of the legwork for you). Also, currently your business
logic is embedded in the VB6 client, and therefore there is no way to call
it from other applications. Separating the business logic on its own layer
improves reusability because it allows you to call the functions from e.g.,
a console or a web application.

Here's a list of issues I've found to be a bit of a hassle when using Web
Services as a remoting solution:

- Long running requests. You will need to manage timeouts both on the client
and on server side.
- Large result sets. Serialization/deserialization to/from text will add
overhead, and this will become very noticeable with large result sets. One
way to address this is to return data one small 'page' at a time. Another
way could be to send large result sets as Dime attachments.
- Multiple concurrent requests from one client. HTTP 1.1 protocol limits the
number of concurrent requests from one client to two. You can work around
this, though.
- Callbacks from the server back to the client. This is pretty much
impossible to do with Web Services.
- Exceptions. Web Services map exceptions to SOAP faults which show up as
SoapExceptions on the client side. If you want smart handling of server-side
exceptions in the client, you will need to serialize/deserialize the
exceptions yourself. This is a fair amount of work but not undoable.
- The .NET Web Services infrastructure "flattens" types. This means that if
your Web Service returns an object of type Employee, then in the client
you'll have a flattened copy of that class which has only public fields but
no methods.
- Aborting long running queries from within the client will be not very easy
to implement. Then again, this is a general issue with n-tier systems since
the query is performed by the business logic layer which is decoupled from
the client.

Things listed above should not be seen as limitations of .NET Web Services
technology per se, but rather they are a consequence of using Web Services
as a remote method invocation solution. Web Services are at their best when
used as a platform independent message passing technology rather than as a
way of making remote method calls.

Regards,
Sami