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!
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.
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.
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
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.
