A client application with all logic accessed via web services?

  • Thread starter Thread starter Simon Harvey
  • Start date Start date
S

Simon Harvey

Hi everyone,

We have a need to make a Windows Forms (2.0) client application that
will be installed on our clients site.

The data that the application uses needs to be centrally available to a
potentially large number of other sites, which would seem to leave us
with our traditional approach, or having a central database server on a
dedicated server someplace.

My question is, is it a good idea to design the client to perform all
operations on the database via web service calls. The client is going to
be relatively complex. I know how to use threads, paging and so on to
keep performance as good as possible, but is designing all business
logic into a web service API, called remotely, a bad idea? Or is this
what SOA is all about?

Any advice would be very helpful!

Kindest Regards

Simon
 
Simon Harvey said:
Hi everyone,

We have a need to make a Windows Forms (2.0) client application that will
be installed on our clients site.

The data that the application uses needs to be centrally available to a
potentially large number of other sites, which would seem to leave us with
our traditional approach, or having a central database server on a
dedicated server someplace.

My question is, is it a good idea to design the client to perform all
operations on the database via web service calls. The client is going to
be relatively complex. I know how to use threads, paging and so on to keep
performance as good as possible, but is designing all business logic into
a web service API, called remotely, a bad idea? Or is this what SOA is all
about?

Any advice would be very helpful!
Click to expand...

If you're still at the design stage, why not design an abstract data layer
for your client to access. Design it using either abstract classes, or
interfaces. This way, it won't matter to the client which implementation you
choose, and you will be able to change implementations based on performance
or other considerations.

Besides, why use web services if there is only one kind of client? You're
using a least-common-denominator approach when there's only a single
denominator.

John
 
Simon Harvey said:
Hi John,

Thanks for your reply.

The web service thing is basically because the database server is going to
be deployed somewhere over the internet. I wasn't sure about calling
SProcs directly accross the internet. I'm pretty sure that that's
possible, but web services seemed to be the more "abstract" option. I
don't want all the SPRocs to be available over the web, and with a web
service I can make the data access API more coarse grained.

Having said all this, this isnt to say that I've decided one way or the
other. I just needed some general advice one whether having a whole
business layer and DAL implemented in web services is a smart idea.

I like the abstract class/interfaces layer thing you suggested. Seems like
a good idea to me.

The other thing to note though is that the windows forms client wont be
the only client - there will actually be web based clients that will need
to access at least a subset of the business logic/data access logic.

Just generally speaking, do you think that exposing so much business logic
in web services and having so much done over remote calls is a bad idea?
Or is this sort of thing done all the time?
Click to expand...

In general, this isn't a bad idea. Specific implementations may or may not
be a bad idea.

The overriding principals should be separation of responsibility and
abstraction. You should never expose stored procedures because you should
never expose the fact that your data is stored in a relational database.
Instead, expose Create Update, and Delete operations - which may happen to
be implemented in terms of stored procedures.

Also, though you've said that you'll have a web-based client, you haven't
said what platform that will be implemented on. I just want to point out
that Web Services may not be necessary to communicate between two layers
which are both implemented using .NET. .NET Remoting can be used. Contrary
to popular belief, this is NOT about to disappear with the introduction of
WCF in Windows Vista.

And keep in mind that if you're keeping your layers isolated, it won't
matter very much if you later need to transition from .NET Remoting to Web
Services - perhaps because you find that you later need to implement a Java
client. If you've kept things isolated, then the rest of the code won't
care.

John
 
Simon Harvey said:
Hi John,

The main thing I'm concerned about is the potential performance of an
application that basically requires a web service call for any databound
operation.

Do you know if the application will feel sluggish, or if done well, is it
possible that it could be just as responsive as say an ASP.net
application?
Click to expand...

Simon,

You really need to take a big step back and look at what you're doing.

If you are designing an application where each small user interface
interaction requires an exchange with your data store, then you should not
be looking at SOA. You should be looking at designing your user interface,
then perhaps pushing some parts of it onto your server. This is the sort of
thing that AJAX and ATLAS do, where, for instance, there is a piece of code
running on the server, which can respond to the user clicking the down-arrow
of a dropdown box by returning some XML or some HTML markup.

The same sort of code, less the HTML, could be useful for a Windows Forms UI
where, similarly, some minor user interaction should go get some data.

Said data may or may not come directly out of a database. In fact, you
should access that data through an abstract data layer, which can be
implemented however you like (or however you need to), without requiring
changes to the part that returns XML to the client. That data layer might,
for instance, want to cache subsets of that data, for faster access (how
often do you need to go to the database for a list of US states, for
instance?) Such caching should be hidden from most of the rest of your code.

OTOH, if your client application is smart enough, it could keep much of the
data manipulation on the client, only communicating to the server for
something "large". For instance, it could allow the user to enter all of the
data necessary for a transaction before submitting the entire transaction to
the server, in a single, SOA-style request.

There's no single blueprint for what's appropriate. Just architect your
application with the layers separate and independant. Then, a change to one
may not require youto change the others. You can then concentrate on getting
the individual layers correct (preferably with automated unit tests) and
then later worry more about implementation details.

John
 
Hi,

I would add the following

Simon said :
" I just needed some general advice one whether having a whole
business layer and DAL implemented in web services is a smart idea. "

I think it is impossible to organize DAL in web-services. If we're
considering SOA itself, it has nothing to do with the way your
organize your data.
The service is a set of business operations you want to expose to the
world and say : "Hey, guys! I can do this, that, and that.".
From my perspective, web-service method should be like a business
Click to expand...
transaction, not just the simple class method, which implements a
simple operation.
It's a good way to think about web-service like a business transaction.
So is this case you can avoid overhead which reduces the performance.

Thank you,
Andrei
 
Simon,

you are spot-on 100%.

We have a development approach and supporting framework that allows rapid
development of complex business systems, that deploy purely as Web Services.
This allows for rich [but thin] client access (Windows Forms 2), AJAX, PDA's
via .NET CF, etc, and inherent B2B.

I must ask why you are using Windows Forms? The reason we do is because the
majority of our users are effectively back-office people - they use our
system from the time they get in to when they leave, and their productivity
would drop greatly if they were forced to sit in front of a browser, even it
was pure AJAX.

There are many years of development in our system, but it has been worth it.

If you are willing to invest some effort, you are on the right track; the
clients must be "thin", and preferably rich. So all business rules,
persistence etc must be server side. And now that internet and WebServices
are ubiquitous, you have your deployment mechanism.

Good luck.
 
Simon,

I can address a few concerns from first hand experience:

1) performance - latency hurts, but overall bandwidth requirements are
minimal; we use stateful server sessions, so no cookies ir state farms
required

2) Windows vs HTML - with AJAX and a robust server architecture, the
browser/html user experience can be very good, up to a point, where user
demands require a rich windows client. Dont under-estimate your [teams]
html capabilities (not ASP.NET - more html/javascript) - maybe look at Atlas

3) disconnected / offline capability - this is the bane of our existence; we
have several models to remedy this
a) backup (wireless/dialup) ISP
b) for larger sites, we have a backup application server and SqlServer
replication on their LAN (replicating the hosted database)
c) true offline capability [very very limited] and merge/sync logic - so far
only used on PDA's

For a greenfields development like yours, a hosted Web Service deployed
architecture will pay off big time.

Cheers,

Radek
 
Back
Top