A client application with all logic accessed via web services?

[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

[John Saunders]

"Simon Harvey" <us**@example.netwrote in message
news:11**************@sp6iad.superfeed.net...

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!

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

[John Saunders]

"Simon Harvey" <us**@example.netwrote in message
news:11**************@sp6iad.superfeed.net...

Saunders wrote:

>"Simon Harvey" <us**@example.netwrote in message
news:11**************@sp6iad.superfeed.net...

>>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!

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

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?

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

[John Saunders]

"Simon Harvey" <us**@example.netwrote in message
news:11**************@sp6iad.superfeed.net...

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?

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

[Andrei Varanovich]

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

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

John Saunders wrote:

"Simon Harvey" <us**@example.netwrote in message
news:11**************@sp6iad.superfeed.net...

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?

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

[Radek Cerny]

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 Harvey" <us**@example.netwrote in message
news:11**************@sp6iad.superfeed.net...

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

[Radek Cerny]

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

"Simon Harvey" <no******@hotmail.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

Hi Guys,

Thank you all for your suggestions and advice - it's all very much
appreciated.

I understand that I don't want to create a whole load of web services that
basically mimic the sort of class methods a typical business object might
possess. I understand tat I want the client to "aggregate" transaction
data in order to submit it in a single go, as opposed to lots of chatty
method calls. Thats all fine. I just wanted to make sure that using a thin
client/webservice combination for a relatively complex line of business
application wasn't totally absurd.

A couple of people have asked why I'm considering a windows forms
application...

- The principal reason is that I'm not confident enough in my own html
based abilities to create the level of UI that is going to be required.
It's going to need all manner of complex grids and gubbins that, although
ASP.net can do, it isn't as easy. At least if you want to make it look
cool and responsive.

- The other reason is that the application needs to be robust to a loss of
connectivity at the client premises. The users need to be at least able to
read their data if they can't connect to the web service layer/database.
To this end I've been looking into smart clients and SQL Server
replication to create a read only cache of data at the client premises.

- The other main reason is, ironically, performance. Which is why I'm so
keen to find out if the winform/web service combination can offer a nice
and responsive solution. If done well that is.

These factors have led me down the Forms route.

Many thanks

Simon