|
Recently, in the space of four days, I encountered five
different people who had no idea that components could be created in anything other than
some variant of the C programming language, and were also more than a little confused by
the actual purpose of Microsoft Transaction Server (MTS). So I thought I’d have a go
at debunking some of the myths that appear to have grown up surrounding MTS and the
components that it manipulates.
Misconceptions
The misconception comes about because when people think components, they tend to think
high level language, which is fair enough, I suppose, if a little shortsighted. The
confusion is due to the fact that Microsoft chose to call its product a Transaction
Server, and that name is not a fair reflection of just what this rather excellent piece of
software is capable of doing.
I’ll come on to that shortly, but first I’ll delve into the murky world of
components and show you that you don’t need to be a C genius to be able to create
them. In fact, doing them by hand in C++, while no doubt thoroughly laudable, is
absolutely unnecessary. Components are of course, wonderful things. Without them, every
time you created an application, and wanted to use something in it that you had used in a
previous application, you would have to bring all that code in time and time again.
Components
By creating a component, and then calling that component from each application you make
life a hell of a lot easier for yourself. Of course, not so long ago you needed to be a C
star in order to create these components, so most people opted for the ‘bringing code
in’ option.
Components come in all shapes and sizes, and are most commonly supplied in the form of
Dynamic Link libraries (DLL) or ActiveX controls (OCX). The third-party custom control
market is huge, and you can find literally thousands of components out there, all ready to
be bolted onto your program, supplying you the functionality you need without you having
to spend ages learning how to code that functionality yourself. While you should never
pass up the chance to employ a custom control written by someone else if it supplies you
with the functionality you need, sometimes it can be cost-effective to create your own
controls, and other times you really have no choice.
The advantages of components
The big advantage that components offer is that they speed up development time no end.
Given the expected application turnaround times these days, your major concern is
producing on time. If you can do that by using a component written by someone else, do it.
Never think you are a lesser programmer because you use ones written by other people.
There will, however, be plenty of occasions when you will both want and need to create
your own; the creation of business rules, for example. Fortunately, there are now quite a
number of tools around to help you do this, and that’s because all these components
use the same technology through which to talk to Windows – Microsoft’s Component
Object Model (COM). You, with your component developer hat on, create a component that
simply exposes its events, methods, and properties through the standard COM interface.
Then all you the developer, with your application programming hat on, have to do is to
look at those properties and so on, and manipulate them in code.
The best language for practically all component creation is Visual
Basic
I will probably be scorned for saying this but, without doubt, the best language to use
for practically all component creation these days is Microsoft’s Visual Basic. It is
easy to do; the Wizards make component structure creation a walk in the park, and leave
you with the job of writing the code for the events, methods and properties that you
define. One drawback to using Visual Basic is that you have to make sure that the Visual
Basic runtime files, and any other files needed, are present on the system you intend the
component to be used on. This is no problem if you are designing your application in
Visual Basic anyway, but can be a bit of a nuisance if you are using another language for
the application. Having said that, you get a similar problem with C++ so it’s a bit
swings and roundabouts there.
Another drawback is that you probably wouldn’t want to use Visual Basic if the
component you intend to create is going to be a large one. There can be speed problems
with components that execute huge swathes of code, but if that’s the case, you might
be better off seeing if you can’t split the code so that you create more than one
component in the first place. Assuming you can’t, or that you need to write code that
Visual Basic just won’t let you do, the next obvious choice is C++. This is
especially relevant if your component needs to get down and dirty with the system
hardware. I can’t comment for all C++ compilers, but certainly Microsoft’s
Visual C++ provides Wizards to help you along the way, as indeed does Microsoft’s
Visual J++, another compiler that you can use to create components that, in this case, are
called Java Beans.
Other solutions
Of course, you aren’t only restricted to Microsoft. You can use Inprise Delphi,
SmallTalk, PowerBuilder and other languages for your component creation if you wish. You
can even use HTML in conjunction with VBScript or JavaScript to create components. This
technology (known as HTML Scriptlets) is fairly new, so it is worth trawling around the
Web to see what information you can get on it. Once you’ve picked a language, about
the only other thing you need to consider, with regard to components, is to make sure that
they are either multi- or apartment level threaded. Single threaded components are not
going to be much use to you if you intend to use them in a multi-user situation, and they
won’t work with MTS at all.
What is MTS?
So, what exactly is MTS, and where does it fit into the Windows NT arena? Currently, the
only way it fits in is if you install it from the Windows NT 4.0 Option Pack CD. If you
are a Windows 2000 beta tester however, you will know that it is an integral part of the
new OS, and is effectively just another Windows NT Service, but a very important one from
your point of view. This is because of the way that MTS handles components, most
specifically, in the way that letting MTS handle your components can help you save tons of
resources on each system. The reason for this is the way in which it handles them.
One of the biggest problems with components up to now is that they get called by an
application, and generally hang around in memory until they are either killed off by the
application, or the application is closed down. This is not very efficient, and can be a
problem if no code has been written within the application to ensure that it does get
killed off when not needed. That problem gets somewhat exacerbated if other applications
that are running also need access to the same component. You can end up with loads of
instances running, each one unnecessarily hogging precious resources. If you code your
components so that they get handled by MTS, however, this scenario goes away instantly.
MTS is in fact dead sneaky. Let’s say that an application is running that uses a
component, and then another application is invoked that uses the same component. MTS takes
a look at the first program and checks to see if it is doing anything with the component
at that time. If it is, a new instance of the component is created, and all proceeds as
usual. If however, the component is not in use, MTS creates a Context Object for
application one, and hands the component over to the new application to use.
Persistent Context
Application one has no idea what has happened. As far as it is concerned the component is
still there, whereas MTS has, in fact, created a wrapper that fools the application into
thinking that the component is still there. This process is known as Persistent Context.
If the first application should suddenly start using the component again, MTS will check
to see if application two is still using it first. If it is, a new instance will be
created, if not, application two gets a Context Object to stare at, and the Context Object
for application one becomes the full component again.
Of course, MTS doesn’t have a crystal ball to tell it when one application has
finished using a component. It is up to you to make sure that your application tells MTS
when it has finished with the component, but that literally involves a couple of lines of
code. Obviously, there are occasions when you won’t want to do this at all. One that
springs to mind is if the component is stuffed full of data that the application (that
stuffed it) expects to find there when it returns. If that’s the case, telling MTS
the component is free is no use at all because the Context Object that gets created is
empty, and when the application requests use of the component again, it gets a new one
back with the default set of values. If the data needs to be the same when it comes back,
you simply don’t tell MTS that it is available for use, in which case it will create
a new instance of the component when one is called.
That’s all I’ve got room, but I hope I’ve whetted your appetite to find
out more about MTS. My next article will start off
down the road to creating our own component and then using it with MTS.  |
