Thin client vs smart client
We are moving from a VB6 to a .net world. We are about to finish our business components and now its time to start thinking about the UI. Well, there it comes the doubt: should we choose a smart client path or a thin client one? We develop backoffice financial apps; they are used in several ways (users that operate it to process information, board of directors that access it just to analyse information, end customers that access it to get information on balance account etc). The chance to have someone using a non windows OS (accessing the system as client) is remote, but exists. If we choose a webbrowser client, then we would have to buy some good components (specially grid component and menus) that could "replicate" desktop experience. Maybe adopting a framework like Laszlo might help. Having a thin client might be good at:
- deploying the app, since no plugin is involved, just the browser is needed.
- be cross-OS compatible (only the client)
- centralize all dlls in the webserver (actually probably in the GAC)
but might be bad at:
- difficult to write client code for all browsers (IE6, IE7, Firefox at least). Some good components might encapsulate this and treat these differences for me.
- some rich features we have in win world are impossible to be reproduced, even with Laszlo, XAML or whatever.
So, here is the BIG dilemna, someone could share experiences with me, exposing the opinions and critics on each model?
Thanks a lot
Raul.
Pros and Cons of Smart Client
Having a thin client might be good at:
- deploying the app, since no plugin is involved, just the browser is needed.
Shahid > You can use ClickOnce to install smart client.
- be cross-OS compatible (only the client)
Shahid > If its is a browser based application then you dont need to worry about OS compatibility issue.Smart Client is some time buggy in this area.
- centralize all dlls in the webserver (actually probably in the GAC)
Shahid > Smart Client is one step ahead on this point.
but might be bad at:
- difficult to write client code for all browsers (IE6, IE7, Firefox at least). Some good components might encapsulate this and treat these differences for me.
Shahid > I think this is currently the Thin client greats cons and if you have more than 1/3 of your full project coding to do in web browser based environment then i would have personally preferred smart client.
Shahid > Smart clients are less cross-platform/browser dependent because of their reliance on web services
- some rich features we have in win world are impossible to be reproduced, even with Laszlo, XAML or whatever.
Shahid > For this point Smart client really scores well and it have lot of advantage on this point plus you can later on push your new updated control and enhancment to the smart client thus updating it to a much richer and feature based platform.
Smart client is available offline also so some amount of caching also is possible
Smart client have threading advantage also.
Smart client applications have the capability to be deployed and updated in real time over the network from a centralized server, they support multiple platforms and languages because they are built on Web services, and can run on almost any device that has Internet connectivity, including desktops, workstations, notebooks, tablet PCs, PDAs, and mobile phones
The Cons of Smart Client as i see are
A "smart" client can vary in it's "thickness" relative to the browser. Thus, there are still some deployment and platform-dependent issues to consider. On the flip side, a smart client allows for a richer user interface, such as drag-and-drop, undo/redo, etc. Many of these features are becoming more easily accessible to developers using Web 2.0 technologies ( Gmail , Some CRM applicaiton and now many banking institution are moving toward web 2.0) ; however, the fact remains that to most business users, browsers are slow, cumbersome to navigate, toggling between screens is painful, and a litany of similar complaints.
Check this image http://msdn.microsoft.com/smartclient/art/smartClientDef.JPG to get to know what is possible.
| Feature | Thin client | Smart client |
|---|
| Provides a rich user interface | Yes, but difficult to develop, test, and debug. Generally ties the application to a single browser. | Yes. Easier to develop, test, and debug. |
| Can take advantage of hardware resources on local computer | Yes, but only through COM components. | Yes |
| Can interact with other local applications | No | Yes |
| Can be multithreaded | No | Yes |
| Can function offline | No | Yes |
| Can perform well in low bandwidth and high latency environments | No | Yes |
| Easy to deploy | Yes | Varies. Difficulty depends on application requirements. |
| Low maintenance and change management costs | Yes | Varies. Costs depend on application requirements. |
| Can be deployed to a wide variety of clients with varying capabilities | Yes, although more complex thin clients may require a single browser. | Yes. Can be deployed on any platform that supports the .NET Framework (including the .NET Compact Framework). |
Check this.
Hope this gives you a better perspective on this issue
Adhering to Shahid and adding:
- One of the advantages of the 3-Tier Deployment Architecture is the fact that allows you to reuse, concentrate and scale logic in those tiers
- They are: the Client or Front-end (which you are not sure what technology apply), the Middleware (where the most of your transactional logic will lay), and the back-end (possibly just your data, perhaps also some legacy logic or even a robust mainframe handling business logic)
- So the question is, web client or smart one? My answer, due to my experience working for the biggest Spanish bank in Latin America, is "both"
- Let's see: you don't need to implement the front-end for every use case twice. Select which case studies you need to run indoors (headquarters, branches), probably the 100% percent, and implement for them a Smart Client approach. Why?
- Because, surelly you have more control over the indoor infrastructure: the OS, and desktop base specifications (RAM, disk capacity, CPU, etc) is something that you can know in advance
- Offline handling: try to explain a customer who's paying a service the due date (one date later he would be in default) that you can't receive the money because there's no web access. The smart client approach at least will permit you enter the transaction, store it locally and forward it once the link is restablished
- Responsiveness. It's not such a sin replicating certain, controlled, validation business logic in the front-end if that will permit you avoid some round-trips to the middleware (most of all in those branches with slower connection). Of course, we are talking of little validating business logic like "People younger than 18 can't apply for a credit card". Even putting such business logic in the front-end, you still has to put it in the middleware or back-end (depending on which of them handles the business logic). Of course, this point still generates bitter debates and discussions
- For those customer (not inner users) whom you want to allow, let's say, home banking or so, surely a web client will be more adequate (since you surelly want to cover the most of them, despite their infrastructure -Mac? Linux? Mozilla? MS family?-). Probably you couldn't repeat the same user experience than the smart client (althought web techs state of the art have evolved a lot: have you seen ASP.NET AJAX?). Forget at least for a while anything related with offline handling here. You also don't need to replicate all use cases here. Just those you want to enable in the home banking channel, in this example
- There are some special considerations when you have several branches with lots of desktops there, because if your indoor, smart-client versions is very big, possibly that will require an importan infrastructure (RAM, CPU, etc) the bank could not be willing to invest for. Be prepared, for those cases, to architect your application dynamically modular. I mean, don't deploy the whole client-side (use cases, forms, reports, etc) if user profiles for that desktop won't use all of them
Finally, for further info, the MSDN Architecture center is hosting a subsite just for Banking
Good luck, Raul. You have a great challenge ahead
2 things to consider:
1) If the app has to access DB (in most cases it does), you would not be able to work with the app offline, unless u copied the whole GB Database to the laptop...
2) It does not make any difference if its plugged to Internet or not, if your app is to be run in an Intranet...
Does that make any sense?
Hi Raul
about offline capabilities? No, actually when disconnected is not a matter of how to continue business as if nothing happens, but some minimal level of continuity
Let me offer an example not related with your problem domain first: your email client application. What happens when you aren't plugged-in? You can't receive new mails but you still can continue reading those mails you downloaded while you were connected. Furthermore: you can at least write replies or new mails, which will remain in your outbox folder until the connection is restablished. And when that happens, you don't need to push that backlog. That simply happens
So comming back to your app, isn't a fact of a 100% of availability but a minimum level of guaranteed services. That minimum level will be defined by business analyst and checked out by the IT department. At the bank I used to work, for instance, the policy was something like "receiving money (payments, deposits) in the form of cash and checks, anytime; withdrawals up to certain amount (i.e. $100) admited even at a risk of loss (that is, giving $100 to a customer with a lower balance)". In some of the contries where the bank was present, the policy was "withdrawals with no restrictions if the customer is at his branch", because every branch had a subset of the database with the information of its customers and their balances (with less than 24 hours of antiquity
Of course, those policies are driven by business needs. For instance, a policy of "no net, no business" is pretty much easier and convenient from our IT point of view, but in terms of customer experience and relationship... 
A complete offline module provides, technically speaking "store for forwarding" capabilities. That is, it holds all movements done during offline (enabled by policies) and when the link with the backends is restablished, takes those movements from the storage and forwards them to the central servers, without disturbing user activities
Hope it helps
Hi Diego,
What you mentioned does make sense, the point is that our app would not work at all without DB connection. Its all based on information that comes from the database. In the example you mentioned (Outlook), offline information are stored locally in some kind of file (pst). In our situation, to make the same thing locally, that would demand to have a local DB, right? Besides it would certainly demand to have a complex sincronizing routine to bundle all information in the same database, after Internet connection comes back...
As for the problem of not working offline (thin client), that applies only to Internet connection, supposing the DB is hosted outside the company, right? If its in an Intranet, Internet connection would not hinder the thin client to work...right?
Hi Raul
Think of what Diego described as a Queue rather than a database.
Items of work are queued until the connection is available.
This is only possible if your application will work in an asyncronous manner.
Syncronising local databases is usually only used in apps where a sensible slice
of information can be identified. For example a sales exec goes to a customer site
where they may not be suitable internet connectivity, so all the information
for that company/region is loaded into a local DB on the laptop so the sales
person can run a demo / show figures etc for that client/area.
Regards
Ed
