|
This month we will be continuing on from last month’s
initial coverage of Microsoft Transaction Server and COM components. Before I move on
though, I’d like to answer some questions posed to me about last month’s column,
and hopefully make it clear why I believe this to be so important, not just for the
present, but also for the future.
COM
When I started writing the first part of this article, it was before I went to
Microsoft’s European Visual C++ Developer’s conference, but I have to say I only
came away from there even more convinced of just how important it is to understand just
what COM, and Microsoft’s suite of largely unsung products (MTS, MSMQ, and WSH)
actually do when all these elements are brought together to become part of COM+, which is
a lot more than the sum of its parts. I’m not going to launch into a hugely lengthy
explanation of COM+ yet, but I do want to try and get across just how important it is to
start learning about these technologies now. Oh, and do not fear that this will be wasted
time. In Microsoft’s labs where testing never stops, so far all of the Transaction
Server-based applications that have been brought in for testing against the versions due
to ship with the ‘2000’ series software have worked without a hitch. Part of the
problem with Transaction Server has of course been its naming which seems to imply that it
is designed to handle database work and nothing else need apply. Even if you had never
come across it before, hopefully last month’s column would have helped to dispel
thoughts of that kind.
Client/server
The simple fact of the matter is that as computers and software have evolved, so have the
demands we place upon them. This means we both want and need more. To place that in the
context of this column, consider say the old corporate solution to data handling problems.
You either had some hulking great mainframe with thousands of dumb terminals, and thus had
the pleasures of screen scraping, a total lack of interoperability and a somewhat tedious
environment to look forward to. If you were very lucky you might have been able to play
with your data locally, although that meant that multi-user went out the window for the
most part, data exchange was not as easy as it might have been, and it was extremely
unsuited to large amounts of data.
The solution of course was the introduction of client/server, a methodology that is still
working just fine for huge numbers of people. The advantage of client/server of course was
that you had a rich front-end for the client, and that meant that the user, if nothing
else, had a more pleasant working experience. The disadvantages became more apparent as
time went by however. Let’s take the evolution of a typical solution developed using
Visual Basic for the interface, with Access for example as the back end. You started off
with a pretty front-end, with perhaps a dash of business logic, talking directly to the
core of the application which was of course loads of VB code, and that talked to the data
in Access. As things progressed and some of its size limitations became apparent, Access
was replaced by a SQL back end, but that was all that was really needed, until it was
decided that it would probably be a neat idea if the SQL back-end could handle some of the
business logic, so the app grew a bit more.
That was fine for a while, but the desire for more and more business logic grew, and the
question soon arose as to just where was all this logic supposed to be kept. In the
front-end user interface? In the back-end database? Where? A solution was sought, and
3-tier became the buzzword of the day. Now, while you almost certainly had business logic
in the front-end application, and there was still some in the back-end database, the
remainder could be shoved into the middle tier and everyone was happy. Or where they? Well
not exactly, because it was quickly realised that without some form of control having all
these business logic components floating around all over the place was just about as
inefficient as it could possibly get.There were scalability problems, reliability
problems, a complete lack of connection pooling, about as much opacity as a block of
granite, a distinct problem with the reliability of DCOM, and the burning question of how
the hell were you to create a transaction that could span multiple components?
Microsoft Message Queue
Enter, stage left, Microsoft Transaction Server. Here was an application that was going to
do the rather decent job it does of handling those middle-tier components for you. This
was great news because it meant that you could write COM components that could be used by
any number of front and back-end solutions, and not be locked away in a single
application. You might have shuddered as you thought of all that C code you would need to
write, but as you no doubt recall from last month, language restrictions no longer apply
to any great extent. Hell, you can even use COBOL or FORTRAN if you want, so let’s
hear no excuses out there. Although Transaction Server is good, it is of course only one
cog in a giant machine. One thing that tends to happen with applications that make calls
upon components is that sometimes, the answers aren’t immediately to hand. When that
is the case, you’d better have something around to handle that, or your system is
going to be about as much use as a chocolate fireguard. Enter stage left, Microsoft
Message Queue, a solution that has nothing to do with email, although email is its closest
comparison point, and also doesn’t have a whole lot to do with messages, but
we’ll let that one slide, because the message metaphor is again a good one to use in
explanation.
Put simply, MSMQ will handle all these problems for you. It works in the same way your
Windows NT back-ends work at the moment, with a big Primary Enterprise Controller acting
as boss, and then a number of other Windows NT Servers with MSMQ sites on them. Each site
can have a Primary or Backup Controller, or be a Routing Server. There are two client
types, dependent and independent. One needs the site controller server to always be there,
and is synchronous. The other is asynchronous, and doesn’t need the controller to be
there all the time. You just pick the one that suits you best.
When running, MSMQ allows you to have multiple queues, and all you have to do is open one,
dump some data in, and close it again. That’s it. The data gets to its destination
after that, and you don’t have to worry about it any more. Link MSMQ with Transaction
Server and you’ve just solved your problem of what to do if a server is not up at
some point. MSMQ will even handle the "Set Complete" part of a transaction, and
it supports 2-phase commit among other things. Currently the only problem with MSMQ is
that you have to write some code in order to use it. It’s not just a
"snap-in", unless you’re talking about its MMC control interface.
COM+
Come COM+ however, it will be a part of a giant whole that will include Transaction Server
that will have a new name… maybe something along the lines of Component Service
Manager? Who knows? Who cares, even? I don’t care what it’s called, all I need
to know is that it is there, and that it does its work in as transparent a manner as
possible.Don’t be alarmed by COM+. It might be Windows-only for the foreseeable
future, but if that’s your environment, you really aren’t going to care about
that at all. Straight old COM isn’t going anywhere in a hurry, and that is what
concerns us at the moment. I hope that those who asked the questions are now clearer as to
the importance of COM and COM+ to the Microsoft way of doing things. In fact, if COM+
doesn’t work, Windows 2000 isn’t going to work, and there’s no danger of
that happening, so getting a head start by first looking into COM and then COM+ right now
will be no bad thing at all.
COM and COM+ are integral parts of Microsoft’s DNA architecture, and they have bet
the farm as the saying goes on that little lot working. I never met a group of people who
were less into gambling with their livelihoods, so I think it safe to say that this
architecture and its components is going to do the business at the right time.
See you next month, where we take our first tentative steps towards the creation of a
working COM component. Don’t be too stressed by that thought though. I created a
wrapper for one as part of a live demo the other day, and that took an entire four lines
of code. |
