Imaginethat your application has a small plastic block for every step of code. These blocks are made to snap together. When the blocks are snapped together, they must go in a particular order as specified by the code you write. Each block has only two connectors, which means that as the blocks are snapped together they form a single strand, i.e. a thread. You cannot form a branch in the chain: one block must follow another. These threads made up of programming blocks are used to run your code. One step must always follow another: you cannot place two blocks next to each other on the same thread.
Prior to Windows 95 and Windows NT 3.51, everything in the Windows world ran on a single thread. When a program runs on a single thread, you can only place one block on at a time (run one code step at a time). Since it would be useful to do more than one thing at a time, and a thread is only capable of doing one sequence of steps at one time, later Versions of Windows allowed applications to create more than one thread. Each thread can only do one sequence of events, but you can have many sequences of events running at the same time using more than one thread. This is called multi-threading or free-threading. Unfortunately, Visual Basic is not one of the programming languages that can create multiple threads (Visual C++ is).
Now, threads do not just float around inside your computer's processor. They need to be put somewhere, ideally isolated from other threads. It could be a serious problem if the sequence of steps of one thread was suddenly replaced by a sequence of steps from another thread. To prevent this, threads are placed in apartments. To keep one apartment separated from another apartment, apartments are placed inside a process. This looks as follows:
When a client makes a call to a component, COM will create the component in an apartment in a process, and run the code steps on a thread. If we have two clients, Client1 and Client2 and one component called Object1, what happens when Client1 calls Object1 and then Client2 also calls Object1? If Client2 makes a call to Object1 on the same machine as Client1, and Client1 is still using Obj ect1, the second client must wait. Client2 cannot get access into the apartment until Client1 is done:
Prior to the current releases of Windows, this is how everything worked. As you can imagine, this does not scale very well. As more and more clients make requests for the component, the queue gets longer and longer. Eventually the computer runs out of memory. In Visual Basic, this is called single-threaded, which is a very poor choice for a name, as all Visual Basic components are single-threaded in the sense that there is only one thread in an apartment. Single-threaded really means that there is a single apartment.
The only other option available to Visual Basic programmers is to have COM create multiple apartments within one process, each with a thread in it for each call to a component. Each apartment still has one thread, so this is not multi-threading. This would look as follows:
This solution became available in the recent versions of Windows. As you can see, each instance of Object1 is still not multi-threaded, but now there can be multiple instances of Object1. Since there is no waiting for Object1 to finish servicing Client1, all three clients can be serviced at the same time. In Visual Basic and COM, this is called apartment threading. If you look at the Properties dialog of a Visual Basic ActiveX DLL, you will see the following options:
MTS will manage our Visual Basic apartment-threaded components: it will have an apartment waiting for our component when a client is called and will handle the management of creating multiple instances of our Visual Basic apartment-threaded components. This allows our component to be scalable and to be used by multiple clients. If we code our components correctly, we can use this to make our components run faster and scale better. MTS will also create multiple instances of our Visual Basic apartment-threaded components so multiple clients can use the component.
Now that we understand MTS and Visual Basic, let us turn our attention to the 3-tier solution. Perhaps one of the most confusing aspects of the three-tier solution is DNA. Microsoft replaced the term three-tier with n-tier, and now n-tier has now been replaced by DNA. It is important to understand what DNA is if we are going to develop a three-tier application.
Just What is DNA?
In the beginning, DNA was an abbreviation for Distributed interNet Applications, although some documents referred to it as Distributed interNet Architecture. Eventually it mutated to Distributed interNet Application Architecture. Today it stands for Windows Distributed interNet Application Architecture. The name is appropriate, even if the abbreviation is not. DNA is an architecture on which we can build Windows applications.
People are often confused because of the word Internet; in fact, DNA does not necessarily involve building internet applications. Actually, it is about building applications using internet programming techniques.
Internet applications can have thousands of users and require components to handle hundreds of simultaneous requests. This means that internet programming techniques must include some methods to make components on the server scalable. One such technique centers around the idea that only the client maintains state between calls to the server, i.e. the client has a memory of what is happening between calls and the server does not. If we maintain state on the server, our server component will need to persist variables for every client currently connected; this could clearly become very costly in terms of resources if we have thousands of users. Performance considerations therefore force us to make our server components stateless. For scalable web applications, information is therefore usually stored on the client in cookies which can be read by the server. Of course, if we are moving information around in cookies, this information should be limited to the smallest size to prevent delays.
From our discussion of MTS, we know that we can build stateless Visual Basic components that run on a server. If we build the components correctly, they will be scalable. Thus, including MTS server components in our application can fulfill the basic requirements of creating an Internet type of application. The best way to use a Visual Basic middle-tier component is to build a three-tier solution.
Another way to make an application scalable is to build the component out of smaller components. We can scale the application by redistributing the components across different servers. Internet-style applications also need the ability to evolve as business requirements and technology change. By building our application with components, we will be able to update or replace individual components over time, without having to rebuild the entire application.
Thus, DNA is about building internet-like applications - applications that can evolve and that have a scalable server component that does not maintain state and a client that does maintain state. DNA could include building an Internet application, an intranet application, or a three-tier solution with a Visual Basic executable on the client.
Was this article helpful?