12-24-2004, 10:07 AM
I am currently planning to develop a transaction processing system type of application--accrual based accounting system consisting of inventory management, fixed assets, accounting/finance--for my organization where there are several units in city and remote offices. All units are interconnected over 64Kbps VPN and some over satellite connection with 256/64kbps.
I'm now having trouble of which to choose from among today technologies (Client/Server Application or Web-based, CGI/Perl or ASP.Net or whatever) considering application performance, fast transaction over existing slow WAN speed, reliable, etc of each technology.
Would anyone please kindly advise me or direct me to any useful resources on such implementation. I would prefer to hear your detailed comparison of pros and cons of each technology chosen and your bottom line!
Your contribution would be greatly appreciated.
12-25-2004, 03:54 AM
I'll post a comprehensive opinion sometime soon (next day or 2).
Welcome here David_Lovesit!
it's kind of a broad question, and i fear it wount be easy to answer it. a good consultant would probably be your best bet now.
i have the feeling that you are looking at technology way to fast now. You'll first need to have a detailed funtional analysis and a detailed architectural framework before you can pick the best technology...
also, i think that you are focussing to much on 'The Speed'. This will actually be the part that will be easiest to work on later, and that will probabbly automatically be become irrelevant as technology progresses.
i would focus more on maintainability, expandability, modularisation, interoperatability of your different modules, security etc.
basically (without knowing your exact specifications), i would look into
- setting up 4-tier architectures with an XML middletier --> all modules should output (encoded?) XML and should proces XML-input;
- working with federated servers where you have one central, controling server where you implement a ticketting service (like Kerberos or Bones) that manage all accesrights so that your securitysystem is nicely centralised and easier to manage
12-28-2004, 01:35 AM
Thank you so much for your best advice. It is very helpful indeed.
12-28-2004, 05:49 AM
perhaps this post shall not be as long as I orginially intended.
As raf correctly pointed out, this is quite a broad question. I will, however, attempt to answer the question directly, though keep in mind raf's suggestions when you begin your design.
I would begin by assessing current need and current availability. Overhead will become a factor.
How to determine what technology to use, a thought map... ;)
1. Are developers already familiar with a particular language/technology?
If yes, make a strong consideration for this platform.
If no, proceed to question 2.
2. Will data be stored locally (per site/computer), centrally, or both w/replication ?
If locally/per site, use a client-server technology
If centrally, proceed to question 3.
3. Will the client Operating Systems be fairly Homogenous?
If no, use a web-based solution or consider Java, see Appendix A.
If yes, proceed to question 4.
4. Will you want to integrate this application with existing or future applications?
If yes, consider a client-server technology
If no, proceed to question 5.
5. Do you mind the added challenges of managing/patching a webserver?
If yes, consider using a client-server application
If no, consider building a web-based product
Java - an excellent language, strengths include garbage handling, multi-platform portability, fairly quickly learned. weaknesses include slower applications, harder to build GUIs than say, VisualBasic or MFC.
Just by looking quickly at the application requirements, my instinct is to recommend writing the application in .NET, either VB or c#. Either will be quickly portable to a web-based solution if necessary. Java is a consideration if you really need application portability.
Advantages to a client-server solution include:
Faster application launch time
Push data files in a compressed, encrypted format over network, without worrying about an SSL server
no webserver to maintain
if coded correctly, users already familiar with basic windows forms. Web-apps tend to be less intuitive
Could store data locally on client (temporarily) in a "Work Bin" or something (similar to the email "drafts" folder), and then sync the data at specifed intervals (time delay, application launch/close, clicking a button, etc)
"Generally," more difficult to update than a web app with new features/bug fixes, etc
1 more application on users' desktops
Would (most likely) use a port other than tcp 80. This could be an issue if you want to allow external access.
Application has to be deployed
if using .net, would require the .net framework to be installed on workstations
web-based applications tend to be less OS-dependent.
That's my recommendation: a .NET application. But feel free to decide what works best for you!
12-28-2004, 10:14 AM
That was really an extreme great contribution! THank you very very much! It is very helpful for me.
Frome here I can make decision.
in respect of the client-server versus webapplication (which are also client-server of course), i'd realy recommend using a webapplication.
Go for the thinnest client possible: one that can process (X)HTML.
i would prefer an architecture where all communication goes straight to your central location (possible over a passthrough server on your location), but if bandwith is an issue, i'd consider an architecture where each location has it's server and then have client-server relations for the machines in that location, and a server-to-server communication between that serer and your central location. All data (the 'raw' data in XML form) should go over this server2server link and be stored on and retrieved from your central location.
The local server could then be used to transform your XML into your final output (parsing it, applying applicationspecific formattinglogic, adding links to the stylesheets, making applicationspecific formprocesing and computations etc). It will reduce bandwith consumption between locations and central server, but if at all possible, i'd still try to keep the architecture as straightforward as possible and centralise as much as possible.
it'll be a lott easier and cheaper to maintain and expand + you'll be able reuse your code more if you allways focus on modularisation --> work with independent modules that take XML as input and outputformat (or another dataformat if you wish, but just make sure you use the same dataformat for all your processes companywide, or that you chave a limited set of adapters to transform data from one format to another).
also, don't be tempted to choose 'the best sollution' for every individual problem, or you might end up with lots of differnt technologies and much higher complexity and more maintenance.
set up a general, companywide framework and stick to it (even if some processes will then be a bit less efficient).
the current progrmminglanguages (.NET family, PHP, J2SE etc) aren't as performant as lover-level languages, but the allow much faster development and easier maintenance. The same for OOP versus procedural approaches: OOP will be less performant but for companywide apps, where multiple developpers will work on over time, it surely has advantages. (+ machines realy do get bigger and more powerfull, connections do get faster etc)
so i think these are the sort of changes you'll need to make first: high level architecture, identifying the modules you'll gonna need (starting from your specific business logic) and positioning them. then starting to look into which industrie-wide standards you want to implement (XHTML, CSS, XML, SQL-db's) --> don't choose for products or languages! choose standards and then pick the tools you need to implement these standards as efficient as possible (for instance, it'll be a lott toughter to get an XHTML-strict output with .Net then with PHP). If you choose the industrial standards, then you'll see that everything comes nicely together + that you'll have lots of premade standard-compliant tools (like SOAP for your XML-webservices) and posebilitys...
12-28-2004, 02:41 PM
There are other advantages to using the web architecture. For example, companies who already have http cache servers in place can leverage their existing technology to reduce bandwidth.
I suppose my true affection is with Java, but I have to admit, the tediousness of building a web application usually pays off in the end because of the low network overhead, the simplicity of deploying changes, portability, etc.
12-29-2004, 10:30 AM
Wow wow wow... you all brothers are extremely helpful and kind. Thanks a trillion for your kind contribution. I will take all of your advice into serious consideration and anlaysis.