The comparison between an assembly line and a department store is good in another way too. An assembly line is usually the heart of a huge factory of some sort. The factory might only have one assembly line. That's like computers used to be when huge mainframes had only one processor. Back when there was only one processor, and every program had to use the same one, sequential batch processing made a lot of sense because it kept that one processor busy all the time.
Today, however, a large data center at Amazon.com or Google uses a server farm where literally thousands of individual computers will process the data. Now that PC's have dual and quad core chips in them, even your laptop often has more than one processor. There are processors everywhere - lots of them. It's OK if they just wait around for something to happen.
A multiprocessing system is one that runs on computer systems that contain more than one processor. Although it's an advanced topic, you can write multiprocessing systems in VB.NET. One way is to use the Open Specifications for Multiprocessing (OpenMP) API available from Microsoft. The .NET libraries necessary to write multiprocessing programs are fully available to VB.NET Express just like the rest of the .NET Framework, but the debugging features necessary to develop programs efficiently are only in the Visual Studio products from Microsoft.
There has been another development that has made things different too. The processor is much faster than just about anything else in the system. For example, it's almost infinitely faster than you type. It's waaaay faster than your Internet connection can deliver data. It's much faster than your hard drive or your monitor. So, no matter what you do - except for certain error conditions like an infinite loop - the processor in your computer is just going to be waiting for something to happen anyway. (You can check this out yourself by watching the CPU Usage chart or the "System Idle Process" in Windows Task Manager. Press Ctrl-Alt-Del and select the "Processes" or "Performance" tab.)
To use more of your processor, and make your computer more productive, Windows and .NET also support multitasking. In multiprocessing, one program is distributed to multiple CPU's. But with multitasking, one CPU is distributed to multiple programs. The way this works is that Windows parcels out CPU time slices to each program. In this way, the computer appears to be doing a lot of things at the same time. In fact, it's still only doing one thing at a time, but it switches from one to the next so fast that you can't tell that it's happening.
Multitasking support is one of the key differences between .NET and VB 6. For example, if a VB 6 program starts processing a large data file, everything else stops. (The VB 6 DoEvents function lets Windows check to see if other programs need some CPU time, but that's not multitasking.) When you write code in VB for multitasking, it's actually called multithreading because your program code will actually start and stop something called a program thread. Several threads running at the same time are said to be running in parallel. Again, writing the actual code to do this is an advanced topic that we won't code here.
Client-Server and Multi-tier Architectures
We've talked about one system running on multiple computers and one computer running multiple programs. The next step is multiple computers cooperating to do a job together: Client-Server and Multi-tier Architectures.
An example of this that is familiar to everyone today is the web. Your computer runs a program called a web browser - IE, Firefox, Opera, Netscape or something else - but most of the data comes from another program called a web server. Some popular server systems include Microsoft Internet Information Server (IIS), Apache and Sun ONE.
Getting all these different computers and programs to work together (mostly) flawlessly is truely one of the major information technology wonders of our time. It works because a standard exists for passing data back and forth called HTTP - Hypertext Transfer Protocol. For years, getting computers to exchange information was a technical trick that was difficult under any circumstances. Now, we all do it every day. In my view, this is one of the best demonstrations of the power of the simple idea of having good rules and also requiring everyone to follow them. (This is like that rule in management: You can have the most powerful people on your team, but if they're pulling in different directions, you still don't go anywhere.)
But the web isn't the only example. An example that is almost as widespread, but not as well known, is when one computer is a database server. In this client-server relationship, the rule book that is usually followed is called SQL (Structured Query Language). Although SQL rules are reasonably consistent, there are minor differences in the way different companies implement it. But even minor differences are enough to make the success of SQL only a shadow of the phenominal achievement that we've seen in the web. (For example, the SQL programming to retrieve data from an Oracle database won't run without some tweaking on a Microsoft SQL Server database.)
The "client" and "server" in this architecture are called "tiers" - as in "tiers" on a wedding cake for example. It's common today to have many tiers, all passing data back and forth. An example of a "middle" tier that is often used is called the "business logic" tier. This tier integrates different data sources (for example, multiple ATM machines for a banking application), ensures that data is consistent and doesn't violate any company policies (An example of a company policy is a special bank rule that must be used for high value transactions.)
When the program that actually processes the data can assume that it's all good data, computers submitting data for processing also get a faster response when something is wrong.
We've come a long way from the old days when you didn't discover errors until the next month's processing!
