Options/Opinions Please.... 1

skeamy · May 2, 2000

Im now getting a bit more familiar with this whole n-tier setup but I'd like to hear opinions on what must be a common situation/problem in converserion from a client/server setup to n-tier. The application I am converting does Debit Card processing. At the moment when the Client application starts up it queries the database and stores in memory all the validation for the card numbers such as length of card number, whether it needs an issue number etc..(about 300 records) When a User enters the Card Number it immediatly tells them what is required for input for that card. Do I forget about holding any data in memory in the new set-up and always go all the way to the database to validate all the card details or is there some alternate method of persisting this data without compromising the n-tier approach? Not sure if Ive explained that well but hopefully you get the jist. Thanks

juliaroberts · May 2, 2000

hi ! An n tier architecture gives you a nunber of benefits over your client server architecture. 1. In a client server model your business logics are on the client system . The server just holds your data in some form or the other (RDBMS,ERP,XML and other legacy systems). What happens in this system is that there is a lot of network traffic involved between client and server because large amount of data has to be transferred from the server to the client to be processed on the client side. This leads to network congestion when large number of users are accessing the server. In the n tier model we shift the business logic to components running on the server. This results in a thin client. In this case the client deals only with presentation issues and some minor client side validations using some client side scripts. The bulk of the processing is done on the server in what is called the middle tier or the business layer. MTS can be installed on the server and your components can run under MTS. The advantage you get is that details like component lifetime, transactions, database connectivity are all taken care of by MTS. You as a developer need to focus only on the business logics. MTS takes care of the generic functions while you deal with just the specifics. 2. By shifting to a n tier model deployment of software is no longer a problem. In a client server model when new releases of a software are released, some clients may upgrade while others may not. So what is happening is that many versions may exist and the server app has to support all these versions. This problem doesn't occur in an ntier system. As long as the interface remains the same the code can be changed and the client gets better service. Versioning problems are thus taken care of. 3. the third advantage is flexibility. If you want to shift from an ASP/ HTML based front end to a VB/DCOM client then all you have to do is change the front end. The business logics in the middle layer need not change. On the other hand you can change your business rules by removing a component from the middle tier and replacing with another . the front end remains the same. Now coming to your problem....... What I would recommend is to have a component called validate_creditcard in yur middle tier. This component basically should do your validation. You should submit the credit card details to a function in this component which will then either return true or false depending on your rules for validation. In this case if your rules change then all you have to do is change the code in this component. Since you are providing the smame interface for your component the client app need not change. ex:- class valid_credit function validcredit(arsg) as boolean ---------' business rules are checked here. the rule parameters can be hard coded here or retrived from the database. if it is hardcoded then a trip to the database is saved and changes to the rules require a change to this code. if it is in the database then code remains the same while changes have to be made in the database for any changes in business rules -------- validcredit=true/false end function    note:-  small details like length of credit card numebr can be verified on the client side using some slient side script also.

skeamy · May 3, 2000

Thanks for replying. I take on board all that you have said about the n-tier approach and agree but the whole approach seems to be baised towards the internet and seems to consider Win32 apps as an afterthought. What have the Users currently got.. They have field level validation which is resident in the memory of the client and therefore prompts them immediatly any card details they enter are incorrect. Therefore when they press the 'OK' button they can be happy they have entered the card details correctly. What will the Users get.. They will get batch validation which will go to an application server to do simple validation and when it has passed, will travel all the way to the database just to tell them they have entered 19 digits instead of 18 for that particular card. (There are at least 300 different cards - you weren't suggesting I hard code 300 sets of params instead of using a DB?) How can that be a step forward? I know that Internet uses accept some lag but our local users don't. Ok we get the benefits of re-use and OO but its no good if the application runs like a dog. I would like to hear your views on this.

juliaroberts · May 3, 2000

hi! "They will get batch validation which will go to an application server to do simple validation and when it has passed, will travel all the way to the database just to tell them they have entered 19 digits instead of 18 for that particular card" In a client server model all processing is done on the client. The server is just a warehouse for data. For your case when the user fills in the details of the credit card , the details are checked with data on the client. You'll have to get the data from the server and keep it on the client earliar before this checking is done or at the time of checking. Just imagine the network traffic involved!!!! On the other hand if you can have a middle tier on the server doing this checking network traffic reduces as all 300 records need not be send across to the client. All that needs to be send across is the credit card details and you will get a response if everything is valid..... hardly any network traffic when compared to the earlier model. Your client server model will result in a big big lag not the n tier model! pronto

skeamy · May 3, 2000

The client server model only gets the data once - at the start of day - and then holds it in memory. Most users expect that an application takes a little while to start up so they are none the wiser. During the day there is no traffic to do validation because its all in memory. In the new set-up, even if the business tier holds the validation data I still have to take a trip there every time I want to validate. Am I missing something?

juliaroberts · May 3, 2000

hi! "The client server model only gets the data once - at the start of day - and then holds it in memory" So your system is a client server model only for a few minutes in the morning after which you might as well disconnect from the server. hahaahaha! what fun!

juliaroberts · May 3, 2000

hi again! I am afraid we may be getting into a needless banter. Can I ask you a few question:- 1. How many clients do you have? 2. What other details are stored in the database?

juliaroberts · May 3, 2000

hi skeamy! How do you propose to keep 300 records in memory? You said that you will fetch the records once in the morning and keep them in memory. How do you keep them in memory? I am afraid that is not a good design. A better design would be to query the database based on the card type and return just one record pertaining to that card type to the client. Afterall how many different cards are going to appear .. say in an hour. Needless records stored in the memory of the client. You might as well have a database on the client storing all these details. Why connect to the server. You might argue that the card details may change! But your model will not be aware of any card changes because as you say you get evrything in the morning and then that's it ... your relation with the server is over!

skeamy · May 4, 2000

The system we are using currently has 300 users doing 5000+ transactions a day - this could increase 5 fold (both in transactions and users) in the future. The validation records are held in a collection on the VB client. All I am trying to contrast is the speed of holding something in memory on the client against having to go to the database every time. The philosophy of never keeping business rules on the client is sound from the point of view of programming but the performance may suffer as a result. I don't know how else to get this point across -- sorry. We must have all worked on systems that cache up as much static data as is possible when an application starts to improve the performance of the application, right?

juliaroberts · May 4, 2000

hi! From what I understand you do not want to run to the database everytime. Do this then.. Have your collection on the server.Have a business component on the server which uses this collection for validation. On server startup or on the first request you can populate the collection on the server. From then on all client requests can be made to that business coponent on the server. Imagine 300 users starting up their apps in the morning presumably at the same time. 300 * 300 =90000 records have to be fetched from the database at that time. As you said the users may increase 5 times. Then the figure goes upto 1500*300=450,000 records requested. In our new strategy only 300 records are fetched at one time into a collection which exists in the same server. No question of network traffic here!!! As the number of users increase in your client server model you will have to take care of transactions. In the n tier model you put that component under MTS and MTS takes care of it. Performance increases in this model. Every client need not have 300 records in his memory. At your present figures.... 5000 transactions by 300 users is equivalent to about 17 transactions per day from a user. Hardly more than 1 transaction an hour!

juliaroberts · May 4, 2000

hi skeamy! There are one or two things that Julia left out that I should add... What happens if you suddenly decide to shift to the internet. Why shifting... you may decide to have a web based client as well in addition to your existing system. If you shift to the n tier model all you have to do is design your web pages and bingo your ASP pages can make use of existing business components . No major recoding has to be done.

skeamy · May 4, 2000

Thanks for your help I think I'll mull it over for now. I think the problem is that I have got used to never taking a trip across the network unless I have to and this is probably in direct conflict with n-tier architecture. In the bad old days networks were slow and this could have a detrimental effect on the application but it appears from what has been written that this is no longer a serious consideration. Maybe Im just a dinosaur...

VB400 · May 8, 2000

Skeamy, Don't give up!  Here's what we've done in a similar situation and it has helped a great deal. On the client machines we have not two but three tiers: UI.exe - The user interface (no business rules here) UI-Centric Business Objects.DLL - all the business rules Proxy.DLL - think of it as a traffic controller for the data On the server machine, we have: Data-Centric Business Objects.DLL - running under MTS (not an issue for this discussion).  This dll just takes care of retrieving and updating the database. Here's how it works: When a user starts the application, we retrieve data from the server that we have decided to be "static" data.  Say, department master file, warehouse master file , etc.  (in your case, this would possibly be validation rules for the different card types).  The Proxy component that got the data from the server saves this data in a local database or even a simple text file. Later, when the user needs this data, the Proxy DLL simply gets the data from the local files and sends it to the UI-Centric DLL.  No more trips across the network. We could have eliminated the Proxy tier and did this in the UI-Centric Business Object tier; however, this would break a major rule of n-tier methodolgy that which is the UI-Centric Business Objects should be independent of the data.  i.e. the UI-Centric B.O. should not know anything about where the data is coming from or even how it is stored.  The Proxy dll (which is very simple to implement) solves that problem. The only "real" decisions that you need to make is which data do you consider to be "static enough" to download only once a day and how do you store it locally (Access .MDB, .txt, etc.). If this is any help to you and you need more info, please post more questions and I'll do my best to answer. Good Luck!

juliaroberts · May 8, 2000

Hi, If all your data is going to be stored on the client side what is the advantage you get in going for 3 tiers on the client machine? You might as well provide data access logic directly in the UI component itself... Why does the UI component have to ask the proxy dll to ask the local database for data when it can do it by itself?

VB400 · May 10, 2000

Notice I did not say "all" the data, just the data that is fairly static.  Certainly a decision has to be made on what data is considered "fairly static". The idea behind the Proxy component is that all other components can remain intact -- it merely intercepts static data and stores it locally for faster secondary retrieval.  Neither the UI-Centric Business Object nor the UI component need to concern itself with how or where the data is coming from. In many environments the UI developers are not the Business Objects developers.  We want to provide our UI developers with Business Objects and not concern them with data retrieval issues. Moreover, the Proxy component easily provides the ability to work with distributed data.  For example, some data may be stored on a central server (say corp headquarters) while other data may be stored in a local branch's server.  The Proxy tier is a great place to put the logic for controlling which data to get from which server. Having a Proxy tier opens the door to using MSMQ in a more complex envirnoment (if needed). There are a few good books that cover this topic in greater detail -- far more than I can write.

Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Options/Opinions Please.... 1

skeamy

Programmer

juliaroberts

Programmer

skeamy

Programmer

juliaroberts

Programmer

skeamy

Programmer

juliaroberts

Programmer

juliaroberts

Programmer

juliaroberts

Programmer

skeamy

Programmer

juliaroberts

Programmer

juliaroberts

Programmer

skeamy

Programmer

VB400

Programmer

juliaroberts

Programmer

VB400

Programmer

Similar threads

Part and Inventory Search

Sponsor