Different Kinds of Components
Components come in all manner of different types. To try to get an idea of the range of tasks that could be performed using custom-designed components, it can be useful to categorize components according to their nature. In this section we'll describe a few of the commonly used categories.

Note that we've only categorized in this way for guidance. We've intended this as a useful way of understanding what can be done with components, but nothing more—there are no hard and fast rules about categories, and they are not mutually exclusive. A given component may fit into more than one of the categories we describe. If you've used many components in your ASP development, you'll probably recognize some of these varieties, and may even be able to name some examples of each. If not, don't worry—you'll have seen plenty before long!

Generalized or Universal Components
Some components are of a generalized nature, and designed to be used in many different environments. Typical examples that display this behavior are the members of another group that you may well have met before: the set of ActiveX Data Objects (ADO) components that provide programmatic access to data stores.

The ADO components ship with all current Microsoft operating systems and data-aware applications, and they can be used from programming languages such as Visual Basic, Visual C++ and Visual InterDev. However, they are equally at home within applications that contain programming or scripting features, such as Microsoft Office, Windows Script Host (WSH), Internet Information Server (IIS), and so on. And, of course, we can use them from ASP—we'll be focusing more closely on ADO and ASP in Chapter 4.

The Brick Calculator component we just saw (and which we'll be building later in the chapter) is an example of a generalized or universal component.

Environment-Specific Components
Other components are designed specifically for use in a particular environment, and rely on some of the facilities of that environment in order to operate. The standard Browser Capabilities component that ships with ASP, for example, is designed specifically for use within IIS and ASP, and useless in any other environment. On the other hand, the Progress Bar component (which is supplied with Windows programming languages like Visual Basic and Visual C++) is totally unsuitable for use in IIS, as it provides a visual interface that is designed to provide feedback on a standalone workstation, as opposed to a web page served across a network or the Internet to a client.

We will come back to a discussion of client–server and n-tier architecture when we've completed our 'categorization'. But for the moment, if you think about the client as being the machine that makes a request for the pages, and the server as a different machine where your ASP pages reside and get processed, with some kind of network in between, you will be able to follow the descriptions of components.

Visual Interface Components
The Progress Bar component we mentioned above also hints at a second way of classifying component types: by their support for a visual interface. Some components are more often described as controls, and the term is generally used to indicate that a component has some sort of visible representation that forms a significant part of its operation. The ActiveX Calendar control that ships with MS Office, the Structured Graphics control that ships with Internet Explorer 4+, and the FlexGrid control (shown here) that ships with Visual Basic 6.0 are also examples of components with visual interfaces.

Because controls are usually implemented on client machines, as opposed to being run on the server as part of an ASP script, we will not be covering them in this book.

Business Rules Components
Business rules are the rules to which the operation of your component, application or system (or even your business) must adhere. These rules might involve checking that customers remain within agreed credit limits, that discounts are applied in a uniform manner, or that a manufacturing cycle is correctly scheduled. Business rules components are components that implement this kind of programming logic.

Because business rules components are chiefly concerned with the internal logic of the application, they often have no visual interface. However, there are many exceptions to this very general rule.

Transactional Components
Some applications require multiple, separate actions to take place in order to achieve the desired result. For example, if we're updating a local database and then sending an order to a remote server, we want both actions to succeed: if the order request succeeds but the data update fails, our database won't contain an accurate reflection of our orders. It is usual to implement a system that guarantees either that all of the required actions are successfully completed, or that none of them takes place. This is called a transaction, and we can create components that work with a transaction monitor to ensure the completion or complete undoing of each transaction. We'll cover transactional components in Chapters 6 and 7.

Active Server Components
This is the category of components that this book is really about! If you're reading this now then you probably don't need to be told about the increasing popularity of Active Server Pages as a server-side programming language. This has produced an explosion in Active Server (sometimes called ActiveX Server) component usage. These components are specifically designed to run on the server under IIS, and to interface with ASP directly. They can provide better performance than pure script code, and encapsulate complex tasks. We'll be looking at what programming features characterize Active Server components and how to write them in Chapter 3. Active Server components can be considered to form a sub-category of environment-specific components.

Utility/Commercial Components
This is the catchall that covers all the 'leftovers' from the other categories—for example, components designed to perform specific tasks within other components, and highly generic components that can be used in a variety of ways. You can make almost any block of code into a component, and so there is really no limit to the components you might create. Common examples are the commercial components that you can purchase off-the-shelf, such as registry access components, HTTP transfer components, and XML data parsing components.

How Components Are Made Available
OK, we've had an example of using a component from ASP, and we've talked about some of the ways we can think about categorizing the components we're going to build. Despite that, what we've yet to do is establish exactly how components are made available to our client code. You know that components are stored in DLL and EXE files, but there have been no references to those in the code you've seen so far. There must be another mechanism in operation.

The first questions to ask are: How do we know how to reference the component that we want? Where do applications get the information about components? The answer to both these questions lies in the system registry (often known simply as "the registry"). The registry currently plays a lead role in the world of COM. It's a hierarchical data store that's used to hold COM-related information and lots more.

The role of the registry with COM+ in Windows 2000 has changed slightly; the general concept of having a 'central repository' for component information is the same, but the registry is no longer that repository, except for legacy components.

Generally, applications don't access the registry directly for the COM information they need. Instead, they use some Application Programming Interface (API) functions provided by COM that encapsulate its usage. To take a closer look at the registry, run the registry editor program Regedit.exe (just choose Run... from the Start menu and type Regedit). When it starts, you'll see a number of keys:

COM information is stored under the HKEY_CLASSES_ROOT key. We won't discuss the registry editor or the various keys in detail here, but feel free to have a look around it when you have a spare moment.

Looking around is fine, but never change anything in the registry unless you know exactly what you're doing. The registry holds a lot of information that's used by the Windows operating system. If you accidentally change something important, it's possible to render your computer unusable.

If you expand the HKEY_CLASSES_ROOT key, you'll find a number of interesting sub-keys. Those of interest are shown here:

Most of the COM components installed on your machine will be listed under the key HKEY_CLASSES_ROOT\CLSID, where you'll find a large number of sub-keys whose names are all CLSIDs of the form you saw earlier. There will a sub-key for every component registered on your machine. As we've explained, these identifiers are the actual names of your components, and each sub-key stores information about the component whose name it bears. One of these pieces of information is the location of the server that contains the component, and it's by this means that components are found and subsequently instantiated on request.

When your client is compiled (if, for example, it's a Visual Basic or a Visual C++ application), the CLSIDs of the components it uses are generally "hard-wired" into the code. This means that if the CLSID of the component it uses should change, the client will no longer work.

However, in our Brick Calculator example, when we created the component instance within the ASP page, we did not use the CLSID to reference the component. Instead, we used the programmatic identifier, or ProgID.

Programmatic Identifiers
In our first example of using a component in an ASP page, we created an instance of the component like this:

Dim objBrickCalc

Set objBrickCalc = Server.CreateObject("BrickCalc.wsc")

When you create a class module in Visual Basic, it generates a ProgID for you, in the form:

[ProjectName].[ClassModuleName]

At the end of this chapter, we'll build the Windows Script Component using the Wizard provided by Microsoft. There, you'll see that WSCs store the ProgID in the same file as the rest of the component's implementation:

<registration

description="BrickCalc"

progid="BrickCalc.WSC"

version="1.00"

classid="{f954a720-67c1-11d3-99b1-00104b4c84a4}"

>

</registration>

As the next screenshot shows, ProgIDs are also sub-keys under HKEY_CLASSES_ROOT. They provide a way of looking up a CLSID at runtime from a "friendly" string identifier. Using the Brick Calculator component as an example, we can see that the ProgID key has a sub-key called CLSID. This has a Default string value that contains the GUID in string format:

Whether you use ProgIDs or CLSIDs to call your component from ASP is up to you. While CLSIDs are less easy to write and less logical to read than ProgIDs, they do ensure that (in the unlikely event that there is a component with the same name and method as the one you are calling) you get the correct method of the correct component.

The COM Runtime
An important part of the COM is the COM runtime, which provides the API functions that enable applications use to create and manipulate COM objects. As ASP programmers, we don't really see the COM runtime, but functions like the Server object's CreateObject() method are layers upon it. If you asked ten C++ programmers to name a COM runtime API, you'd probably find 99% of them would say CoCreateInstance() or CoCreateInstanceEx(). These APIs are responsible for the creation of COM objects—they are the equivalent of CreateObject() in ASP. The COM runtime is a large topic, and we will not be covering it in depth here.

There is a lot more to learn about COM in general, but both ASP and Visual Basic make COM very easy to work with. While we could introduce all manner of topics to help you understand what is going on under the hood, the ASP and Visual Basic environments are designed to hide much of the complexity from you until you're at a stage when you really need to dig into the inner workings. We will be looking into COM more deeply in the section on C++, starting in Chapter 10, but what you have seen so far is enough to get you used to building components and using them in your ASP pages.

Will Microsoft Replace COM?
Unlike a lot of Microsoft technologies, COM has a fairly stable history that can be tracked back long before the official release in 1993. Since its release, COM has slowly evolved, but this has largely involved additional features such as security and the ability to call up components on different computers. There have been no major architecture changes.

COM has a solid future. These days, almost every new technology that Microsoft introduces is based to some extent—and in some cases entirely—on COM. This is true for all the technologies we will be examining in this book—ADO, MTS, MSMQ ADSI, and OLE DB. All the Microsoft Office components expose COM interfaces, as does Internet Explorer. The next version of COM, known as COM+, already has a pivotal role in Windows 2000, so you can rest assured it is here to stay. There are some big changes between COM and COM+, but nothing that invalidates or outdates the code that we will be writing in this book.