florisb
asked on
thin versus fat clients
Hi experts,
I'm asking a question here that could be answered with the contents of various books. I know some of those books; I ask this question here for an up-to-date answer that's Delphi related.
Consider an application that works with one central database (100MB) and 100+ users. What would be 'good'; a very thin client / application on the server (application server), or better fat applications on all clients and only database-layer on server / (business rules / stored procedures?) Is DCOM the most advisable technic for this?
Okee... ...I'll check my books, but I would like some expert advise! Points will be doubled for very complete info.
Thanks,
Floris.
I'm asking a question here that could be answered with the contents of various books. I know some of those books; I ask this question here for an up-to-date answer that's Delphi related.
Consider an application that works with one central database (100MB) and 100+ users. What would be 'good'; a very thin client / application on the server (application server), or better fat applications on all clients and only database-layer on server / (business rules / stored procedures?) Is DCOM the most advisable technic for this?
Okee... ...I'll check my books, but I would like some expert advise! Points will be doubled for very complete info.
Thanks,
Floris.
Hi florisb.
It strongly depends on that you want high efficiency and speed or to save money. Usually it has direct dependence.
Igor.
It strongly depends on that you want high efficiency and speed or to save money. Usually it has direct dependence.
Igor.
Hello,
I would suggest the following reading :
http://community.borland.com/delphi/distcomp/0,1418,10003,00.html
Regards...
I would suggest the following reading :
http://community.borland.com/delphi/distcomp/0,1418,10003,00.html
Regards...
The most thin client in my opinion is to use Internet Browser, in this case you do not need to distribute any thing to the clients. The most important and heavy thing will be the server side programming such as CGI, ISAPI, but I'm not sure that will be suffiecent for you project or not.
Motaz
Motaz
As of whether DCOM is appropriate or not, here's my tip: I am forgetting about CORBA, and all distributed stuff I am starting to develop will be for MTS (thus DCOM). This gives me the ability to deploy my app over the internet easily not restricting it to our intranet.
As Motaz stated, the thinest client is a simple web browser, and that's what I like too.
Alex
As Motaz stated, the thinest client is a simple web browser, and that's what I like too.
Alex
If you want to create thin clients, check www.astatech.com, they have a great framework for that (and even a wizard to convert your old app)
ASKER
oops, it's about a local network... ...no internet.
thanks so far! I'll be back.
Floris,
thanks so far! I'll be back.
Floris,
ASTA works great for a local network too! We're using it for our in-house application.
ASKER
Where is my comment! Hmmmm... ...will write a new one then... ...shorter...;-(
Personally I'm compelled to choose for COM, perhaps working with MTS / SQL Server (I'm reading about MSMQ). I have some (D)COM experience. When internet-access is not required for application, I wonderded whether COM versus DCOM makes difference in database-access speed. With DCOM thinner clients; but COM is so much easier to develop.
Developing for LAN-only I suppose MIDAS-alike (that's ASTA too) solutions, will not give the best speed. Making the thinnest possible client is not my main goal, so using an internet browser is perhaps an answer to 'thinnest client' (how thin is I.E. anyway?), but not an option for me.
Rbetora; I checked Terminal Server; for both projects I'll work on in the near future, it's licensing makes it a less preferable choice.
Blackman: is it a database application with, f.e. 100 users and 20 database transactions per user per day?
Floris
Personally I'm compelled to choose for COM, perhaps working with MTS / SQL Server (I'm reading about MSMQ). I have some (D)COM experience. When internet-access is not required for application, I wonderded whether COM versus DCOM makes difference in database-access speed. With DCOM thinner clients; but COM is so much easier to develop.
Developing for LAN-only I suppose MIDAS-alike (that's ASTA too) solutions, will not give the best speed. Making the thinnest possible client is not my main goal, so using an internet browser is perhaps an answer to 'thinnest client' (how thin is I.E. anyway?), but not an option for me.
Rbetora; I checked Terminal Server; for both projects I'll work on in the near future, it's licensing makes it a less preferable choice.
Blackman: is it a database application with, f.e. 100 users and 20 database transactions per user per day?
Floris
ASKER
The thin client solution;
"Citrix's Independent Computing Architecture (ICA).The foundation for turning any client device-thin or fat-into the ultimate thin client.":
http://www.computersamerica.com/events/presentation/citrix/sld001.htm
also funny: "Micosoft licenses MultiWin frop Citrix to produce Terminal Server. Citrix introduces the MetaFrame product as an extension to TSE".
happily I'll only have to develop for the MS platform in the near future...
"Citrix's Independent Computing Architecture (ICA).The foundation for turning any client device-thin or fat-into the ultimate thin client.":
http://www.computersamerica.com/events/presentation/citrix/sld001.htm
also funny: "Micosoft licenses MultiWin frop Citrix to produce Terminal Server. Citrix introduces the MetaFrame product as an extension to TSE".
happily I'll only have to develop for the MS platform in the near future...
Floris, as usual to drive the convertable you need the money :-)
Still for 100 users 20 transactions each a day, why not just use good old client server or has that been banned the way the GOTO statement was banned?
notice delphi still supports goto statement, a good thing :-)))
Keep your client app on the server, add desktop links to it on all clients. The app is run in clients memory (there for fat client), you can install immediate upgrades by renaming the exe to
oldexe and copying the new exe to the dir. next time the user runs the program he will be using you latest version (and you can rename a file while it is in use)
why worry about 3 tier when 2 tier works well at those numbers?
Rob;-)
Still for 100 users 20 transactions each a day, why not just use good old client server or has that been banned the way the GOTO statement was banned?
notice delphi still supports goto statement, a good thing :-)))
Keep your client app on the server, add desktop links to it on all clients. The app is run in clients memory (there for fat client), you can install immediate upgrades by renaming the exe to
oldexe and copying the new exe to the dir. next time the user runs the program he will be using you latest version (and you can rename a file while it is in use)
why worry about 3 tier when 2 tier works well at those numbers?
Rob;-)
>why worry about 3 tier when 2 tier
>works well at those numbers?
By the whay, what exactly the meaning of Multi-tier? what is the 2 tier module and what is the 3'd?
Motaz
>works well at those numbers?
By the whay, what exactly the meaning of Multi-tier? what is the 2 tier module and what is the 3'd?
Motaz
ASKER
TBertora, have to refresh some things: if app. is started by client with a link and there's only one .exe (on the server); what about network traffic when an app. of say 2Mb is started?
And what if say 500+ users start that app on the server; I only have experience with 100- people starting the same app. Can I expect problems?
COM and everything is nice, but I agree... ...simple solution are often great, simple and the best. If all database communication is allready seperated in a layer, is does make sence to me, to place that on the server (f.e. in shared COM instance, or distributed by DCOM) and let client allready have GUI and other layers.
Are there standards like:
if number users > x and databaseaccess > y then use this?
Greetings,
Floris.
And what if say 500+ users start that app on the server; I only have experience with 100- people starting the same app. Can I expect problems?
COM and everything is nice, but I agree... ...simple solution are often great, simple and the best. If all database communication is allready seperated in a layer, is does make sence to me, to place that on the server (f.e. in shared COM instance, or distributed by DCOM) and let client allready have GUI and other layers.
Are there standards like:
if number users > x and databaseaccess > y then use this?
Greetings,
Floris.
Floris:
have to refresh some things: if app. is started by client with a link and there's only one .exe (on the server); what about network traffic when an app. of say 2Mb is started?
That in my oppinion will not be a problem especially if your network is 100megabits , even a 10megabit network is still fine for 100users. Because you will always find that users only run the app once in the morning, and they don't all launch the app at exactly teh same time any way.
500 people , I don't know if one server is enough.. I have never worked with so many clients. sorry perhaps someone else can give you insight.
Motaz :
2 tier, clients and server(DB)
3 tier, clients Appserver, DB Sever
App server process messages, translates them and then verifies the messages and talks to DB server, verifies and translates the results and then passes to client,
More work involved here but because you have a appserver if your db changes, then you don't need to rewrite the clients, just rewrite the part of the appswerver that talks to the DB server.
Aslo you can put a second DB server in teh 3 tier model, if first DB goes down your app server can continue to talk with the other DB server.
n tier, just add more appservers.
That's my simple explanation, I have never really programmed for that model, but does that mean I cant?? According to the employment agencies thats it I can't- what a bunch of idiots.
Hope that helps, sorry about my attack on the employment agencies but I needed to vent somewhere..
Rob;-)
have to refresh some things: if app. is started by client with a link and there's only one .exe (on the server); what about network traffic when an app. of say 2Mb is started?
That in my oppinion will not be a problem especially if your network is 100megabits , even a 10megabit network is still fine for 100users. Because you will always find that users only run the app once in the morning, and they don't all launch the app at exactly teh same time any way.
500 people , I don't know if one server is enough.. I have never worked with so many clients. sorry perhaps someone else can give you insight.
Motaz :
2 tier, clients and server(DB)
3 tier, clients Appserver, DB Sever
App server process messages, translates them and then verifies the messages and talks to DB server, verifies and translates the results and then passes to client,
More work involved here but because you have a appserver if your db changes, then you don't need to rewrite the clients, just rewrite the part of the appswerver that talks to the DB server.
Aslo you can put a second DB server in teh 3 tier model, if first DB goes down your app server can continue to talk with the other DB server.
n tier, just add more appservers.
That's my simple explanation, I have never really programmed for that model, but does that mean I cant?? According to the employment agencies thats it I can't- what a bunch of idiots.
Hope that helps, sorry about my attack on the employment agencies but I needed to vent somewhere..
Rob;-)
The main problem with 2-tier applications is that a large number of users has connection to the database. With more than 10-30 users, this creates overhead on the server. And if you are talking a Non-C/S DB like Paradox or dBase, it's even worse because all the clients are accessing the same database file.
A 3-tier solution like MIDAS or ASTA is much more scalable and you get the opportunity to pool the database connections on the AppServer so it only has like 10 DB connections which it then shares between the 100 clients.
Also, you can do DB processing (like generating reports) on the AppServer and thus preventing a lot of data from being sent to your client.
My current ASTA appl. will not reach more than 20-30 simultanious users, but check this link for a users expirence with 400 users.. http://www.astatech.com/support/contrib/exp1.html
A 3-tier solution like MIDAS or ASTA is much more scalable and you get the opportunity to pool the database connections on the AppServer so it only has like 10 DB connections which it then shares between the 100 clients.
Also, you can do DB processing (like generating reports) on the AppServer and thus preventing a lot of data from being sent to your client.
My current ASTA appl. will not reach more than 20-30 simultanious users, but check this link for a users expirence with 400 users.. http://www.astatech.com/support/contrib/exp1.html
BlackMan, what is the meaning of tier 2 and tier 3?
Motaz
Motaz
Basically, 3-tier allows you to implement business logic on the server and just code the presentation part in the client. This is especially handy if you want to have both a Win32 frontend and a web based frontend.
Additionally, you get much less load on your database.
Additionally, you get much less load on your database.
ASKER
Add:
Motaz: A sstem we develop here now has three tiers, basically it's more component-based, but:
client layer is GUI.
server layer is database communications.
Not all user can access all data, so we made a business layer that talks to the database layer. All rights / permissions are retrieved in this layer; we call this the business-rules. A client app makes calls to the business-layer and just rows that this user may see are retrieved. So client app's don't contain this functionality.
Motaz: A sstem we develop here now has three tiers, basically it's more component-based, but:
client layer is GUI.
server layer is database communications.
Not all user can access all data, so we made a business layer that talks to the database layer. All rights / permissions are retrieved in this layer; we call this the business-rules. A client app makes calls to the business-layer and just rows that this user may see are retrieved. So client app's don't contain this functionality.
ASKER
who should get the points?
Not me.. :-)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Rob.