Starting Out With Components
As our customers, our managers and the sales team ask for
increasingly complex applications, the demands made of software developers are
growing at an ever-increasing rate. Lately, the vogue for companies, quite
rightly, has been to automate their business processes. Now the drive is to
integrate all of these disparate systems together, often with the addition of a
web interface so that access to these products and services is more widely
The continual growth in the adoption and expansion of
computer-based systems leads to more sophisticated (or complicated)
applications�some of which take years to develop, or evolve without direction
into unmanageable systems that no single developer fully understands. When the
system requires maintenance or an upgrade, where's the developer who built the
thing in the first place? They're either 'too busy', or they've moved on to
richer pastures (not uncommon in today's market). That means that some other
poor developer has to bear the pain and hardship of working out where changes
need to be made�and the ramifications that these changes will have on other
parts of the system.
Concerns over scalability, structure and maintenance of
these increasingly complex systems, coupled with the demands that are the very
nature of software development, mean that something is needed to ease the
burden. Components have got a lot
to offer us. If you think of a component as a small, self-contained nugget of
code that we write to sit at a well-defined point in a system's architecture
and perform certain (related) tasks, we can begin a list of the benefits of
components right here:
Because by itself it is a lot simpler than the entire
application, we can maintain it easily.
Because it's self-contained, we can upgrade simply by
taking out the old component and putting the new one in its place. The same
applies to components that we discover to contain bugs.
If it's useful elsewhere, we can reuse it�we may borrow
it for our own purposes, or put it on the market.
We could go on, but we'll save that for later. The point is
this: everything we've said so far is just as applicable to ASP and web
development as it is to any other kind of development. Web sites are becoming
more complicated: our ASP applications are being asked to incorporate the
functionality of traditional applications; to centralize the point of access
for end users who need to get at different applications; to handle increasing
numbers of users. The fact is, we need to give components some serious
Components are already an important part of programming and
software development, and the ability to build and use components is a valuable
tool in any programmer's arsenal. In fact, these days, component building is
arguably an essential skill.
In this chapter, we're going to convince you that you
already know quite a bit about programming with components; we'll look at some
typical scenarios in which components are used; and we'll begin to investigate
the impact that component programming has on application design. By the end of
the chapter, you should understand that componentization isn't just about code reuse�it implies a new
way of creating applications, opening the door to techniques and technologies
that aren't available in 'traditional' programming. Specifically we will see:
The advantages of using components
The basics of COM�Microsoft's Component Object Model
An introduction to 3-tier and n-tier application development
Examples of situations where you're probably using components
How to build and use our first component
The Advantages of Componentization
Consider the question, "What's the best approach to the
solution of a complex problem?" Perhaps the most obvious answer is this:
Break it up into a number of smaller parts, each of
which is self-contained and can be easily understood
Solve each of the smaller parts (or use a ready-written
solution�you might have a solution lying round from a previous project, or you
might buy in a third-party solution)
Bring each of the smaller parts together to create the
This approach generally works very well�and programming is
no exception. The reason is probably its simplicity�but this simplicity is the
key to good software engineering and development.
COM�the Component Object Model
The good news is that there is an established technology
available to us today that allows us to build our applications this way. It is
called COM�the Component Object Model. COM is the
software industry's favored solution for solving the complex problems relating to
large applications and code reuse on the Windows platform. Using componentization, large
applications can be assembled from smaller, self-contained packages of software,
each of which performs a particular task.
By using components, we only need to write a small amount of
application code to act as 'glue', sticking the pieces together. The 'glue'
then simply calls the components into being, provides them with the information
they need to do their work, and then either lets them get on with it or waits
for them to produce a result. In this sense, they can be like little
"black boxes" of functionality: you don't need to know how each
component achieves its task; you just need to know what it's capable of doing
and what values you can provide it so that it will accomplish the task it is
A Couple of Analogies
If that sounds a bit esoteric, consider what happens when
you need to ask the operator for your uncle's telephone number. You call the
operator, and you give the name and address of your uncle. Then, they go away
and do their thing... and eventually they come back with a number (or not, if
your uncle has no telephone). In this sense, the operator is acting like a
component�maybe the request would be programmed like this:
�� Dim objOperator
�� Set objOperator =
�� Response.Write "The phone number you
require is " & _
objOperator.GetNumberFor("Uncle Brian", "Chicago")
The point here is that we're not particularly worried about
how the operator finds the number�we just give them the information and expect
them to do the job.
As another example, think about hi-fi 'separates'. You buy
an amplifier, a pair of speakers, a CD player, and you wire them all together
with some leads. Then, a month later, you decide that you wanted a turntable so
that you can play all your old vinyl. But you don't go out and buy a whole new
system�after all, you already have an amplifier and speakers. You just expand
the existing system by purchasing the turntable and plugging it into your
In your average software house, this is how customers and
the sales/marketing department think that application development works.
Wouldn't it be nice if it really did?
Well, there can be a strong similarity. You may not have
realized it, but you're already using COM components. For example, in your
software development, you've probably already come across ActiveX Data Objects
(ADO)�a set of components for data access. Or perhaps you've used the Ad
Rotator component, the Content Rotator component, or some of the other
components that are provided as standard with ASP?
Better still, look at the software you use every day�things
like Microsoft Word and Internet Explorer. Many of these kinds of application
are written using components. The Internet Explorer executable (Iexplore.exe) is only 77Kb in
size; all of its sophisticated functionality is handled by numerous other
components, which the executable only calls into action when necessary.
What Do Components Do for Us?
Hopefully, we've given you an incentive for wanting to learn
about components. The advantages of packaging up our code into
components rather than using script are numerous, and we'll outline the main ones here.
Code Reuse and Distribution
Possibly the two most common reasons for using components
Breaking up a complex application into manageable
chunks, as we've already discussed
Packaging up code that you are likely to need more than
once so that it can be re-used
Having written a piece of code that performs a specific function, cutting and
pasting the appropriate pieces into another program can often be
difficult. If you've ever done this with your own code,
you'll know how tricky it is to remember how you originally
intended the code to work�you may have to work out what each line is doing in
order to select precisely the correct lines. And if you've ever done it with
someone else's code, you'll know that it's even harder!
When you package code into a COM component, you are
automatically providing a clear definition of precisely how to use the
functionality of that component. You'll still need to document it, but you
won't need to do any cutting and pasting of code.
Of course, this also makes for a convenient code
distribution technique. When passing your neatly packaged component to your
colleagues and customers, they don't need to
understand the code behind it to get it to work�you just tell them what tasks it can achieve and
what information they'll need to pass to it.
For example, we don't need to know how the ADO components
work in order to use them. We can just retrieve them from the Microsoft web
site, install them, and let Microsoft's documentation tell us the rest.
Binary Distribution and Reuse
As we'll discuss in more detail later on, COM components are
language neutral�they can
be written in one language and used in another. If you ask a
Visual Basic compiler to compile some C++ code, you'll see some interesting
errors and it won't work. Ask a Visual Basic application to use a COM component that was
written in C++, and it will work fine.
Maintenance and Replacability
Here's a case in point: if you have to do a lot of form
field validation, you can write a component that performs the task for you�that
way, you centralize the code in a
component, and you can simply reuse it time and time again.
If you ever find a problem with your validation code, you
can just correct the component and reinstall it in place of the faulty one.
Drawing an analogy with our telephone operator example, this is comparable to
the operator being off work. The telephone company just
installs another operator as a stand-in.
We, as clients, don't care which
operator is on the other end of the 'phone�so long as they can do the job.
Commercially Available Components
There are an ever-growing number of components that are
available commercially. If you have a programming task to achieve, it's quite
possible that there's already a component out there in the marketplace that
will help you to achieve you goal, or even provide a complete solution. Buying
a suitable third-party component means that we don't need to research,
write and test the component ourselves�this brings three immediate advantages:
We can acquire the component immediately, and therefore
we should be able to deliver our final solution faster
We've effectively replaced the cost of development and
testing (for that part of the project) with the cost of a fixed-price lump of
pre-written code�which is usually cheaper
Highly specialized components are usually written in
consultation with specialists in the field. In that case, we also avoid the
cost of employing a specialist
In addition, commercial components should be tried and
tested in their market situations, so you can be fairly confident that it will
perform well at the task it is intended to achieve (although it's worth
restricting yourself to buying components only from trusted suppliers, as you
generally don't get to see the source code). One very popular example of such a
component would be a credit card verification component for use in e-commerce
To get an idea of the
number of components on the market, check out some sites that specialize in
selling components over the Web. For starters, try http://www.componentsource.com, http://www.greymatter.co.uk, and http://www.serverobjects.com.
When you're executing complicated code, you're always
looking to reduce the time it takes to process. However, if your code is in the
form of ASP or some other script, you can reasonably expect it to take a while.
That's because scripting languages are interpreted.
That is to say, each line of code needs to be converted into more elementary instructions (binary code)
that the processor can understand, before that line can be executed. That happens every time a
script is run.
By contrast, components are usually already compiled, which means that they
have already been converted into the binary format. This means that the
component's methods�the functions that
it makes available�can be executed straight away. The result is that components
often execute much more quickly than plain scripts do.
Hiding Sensitive Code
If you're distributing code, then you need to think about
whether you want other people to see it. If they can see it, they can figure
out how it works, and they can probably also tamper with it. If you're
distributing script files, your code is open to these kinds of threat.
Writing components in languages such as Visual Basic and C++
requires you to compile them. By compiling the component, you produce the
that we mentioned in the previous section�not only does this execute
efficiently, but also it protects your code from snoopers and code-changers.
Your component's business logic is safe from anyone who may wish
to meddle with it.
Splitting Tasks Into Distinct Areas
If you have several developers or teams working on an
application that is split up into discrete chunks, componentization makes it
possible for each of the different groups to work on a different part of the
application. Each task can be clearly defined, and you can specify the values that
the different parts of the application need to share in order for the
application to come together as a whole afterwards.
Ease of Debugging
While the Script Debugger is a very useful tool, it isn't
nearly as sophisticated as the debuggers in Visual Basic and (in particular)
Visual C++ . The debugging tool in the Visual C++
for example, allows you to look right down into the computer's
memory to see what is being stored where.
This kind of capability means that, if you're using Visual
C++ or Visual Basic to write components that are intended to perform complex tasks,
you gain the edge in terms of finding out exactly why your code isn't working
That covers some of the major advantages of
componentization, although we will see others as we go through the book�in
fact, we'll see some more in this very chapter. If you take all of these
advantages into account as you write your ASP applications, you may soon find
yourself writing less of your programming logic in script, and placing more of
it into components. The ASP script becomes the 'glue' that binds the component
pieces of your application together.
How It All Comes Together
So, to recap: COM
stands for the Component Object Model, which is a framework
for creating and using components.
Microsoft introduced the COM framework back in 1993, as a
model for describing and implementing components in such a way that they could
interact with each other and with all COM-enabled platforms and applications.
COM is the specification to which
components are written and used on the Windows platform�and there are now
implementations of COM on many non-Microsoft platforms. Every component that we
develop in this book will be a COM component, and will therefore conform to
Let's backtrack a little. We've just made a rather lofty
claim. All COM components will be able to interact with all other COM-enabled
platforms and components? How do they do that?
The foundation of COM is a binary
specification that defines how the code using a component�usually
called a client�can use the functionality
that a component makes available. On the flip side, it also defines how a component exposes that functionality to
Because COM is a binary specification, it allows language neutrality. As long as a
given language can produce compiled code that complies with the binary
specification, it can be used to write COM components�and it can also interact with COM components written in
any other COM-enabled programming language.
There are a number of languages in which you can write COM
components. In this book, we will mainly see how to write COM components in
Visual Basic and C++, although there are many more languages you could use,
including Visual J++, SmallTalk and Delphi.
So, while this book is about components for ASP, the
components that we'll develop are all COM components�and that means that (with
some exceptions) they can be used in other COM-aware programs, such as
standalone applications written in Visual Basic or Visual C++. As we will see
in Chapter 3, the ability to do this is dependent upon whether our components
are designed to interact with the environment that calls them. If we develop a
component that relies on some functionality of the ASP object model, for
example, we will only be able to use it within with ASP applications. There
are, however, very many occasions when our components will be reusable in
COM is not the only
specification for components�CORBA and JavaBeans are two others.
However, as this book is about components for ASP, we will be focusing on COM
ActiveX and COM
A term that you may have come across in the context of
component-based development is ActiveX,
and we should make clear that in most situations, ActiveX means pretty much the
same thing as COM. An ActiveX component is the same as a COM component. In
addition, an ActiveX control is the same as a COM control, and an ActiveX
server is the same as a COM server. But don't let all that confuse you�we'll
come back to these terms shortly.
Today, ActiveX is little more than an outdated brand name
that was introduced by Microsoft a few years ago when they redirected folks
towards the Internet and revamped and optimized some of their technologies to
meet the low-bandwidth requirements of the Net. There was ActiveX Scripting,
ActiveX Components, ActiveX Data Objects, ActiveX Controls, and ActiveX
ActiveX achieved its original goals and got lots of media
attention, but since then people have been confused about the differences
between COM and ActiveX. Essentially, however, in modern-day parlance and as
far as ASP component development is concerned, ActiveX implies COM.
Components and Objects
We've established that a COM component describes a set of
related functionality and the code required to achieve that functionality. When
we want to use a component's functionality, however, we don't make constant
references to the component itself. Rather, we use the component as a
blueprint, and we use it to create an entity that we refer to as an object.
The process of creating an object from a component is called instantiation. An object is a
single instance of a component. The object is created in the image of the
component, and is the vehicle by which we make use of the component's
In code, we use objects. An object
represents a single entity within our code; we use a component as the blueprint
for creating an object.
We may want to use several instances of a single component
at any one time, within different applications. Or we may have a single
application that uses several instances of the same component�just like having
many variables (or 'instances of variables') to hold different strings.
You should be aware
that the term 'component' is often used to refer both to the COM component and
to the instance�relying on the context to imply the exact meaning.