Introduction to COM and .NET
- The History of COM, MTS/COM+, VB, and SQL Server
- The New World of .NET
- COM+ 1.5 Component Services
- Visual Basic .NET
- C#
- SQL Server 2000
- What's Next
- References
This chapter is from the book
This chapter is from the book
This chapter is from the book
In this chapter, I will briefly discuss the history of COM up to the state of .NET today. In this discussion, I will tell some horror stories from the dark ages of the Component Object Model (COM), Visual Basic 6 (VB6), and COM+, and will look at the advances made in the industry in recent years. I will also touch on key technologies, such as .NET Component Services, Visual Basic .NET, C#, and SQL Server 2000, that I intend to use for my examples and discussions throughout the book. To understand this chapter and the rest of the book, I assume that you are somewhat familiar with Visual Basic .NET, Common Language Runtime (CLR), and so on, and so I won't discuss these topics in detail in this chapter. With that caveat out of the way, let's get started.
The History of COM, MTS/COM+, VB, and SQL Server
Although we all know that programming didn't start with COM, a major shift in the industry occurred when COM became popular in the mid-1990s, so it seems a good place to start our look at the technology's history. From there, we'll move on to MTS/COM+ Component Services, before touching on VB and SQL Server.
COM
Perhaps one of the most important ideas behind COM was to make it a technique for moving away from monolithic applications toward component-based applications. As such, COM is a binary model, not a source-code model. This might make frequent reuse a little easier to accomplish, because you reuse binary components instead of source-code classes with COM. Another important benefit is the user's ability to take advantage of black-box reuse, which means that the reuser only pulls some ropes to make the component behave as wanted without knowing how the code is written for the component. Black-box reuse was not possible to achieve when source code was reused. If you, as a reuser, are able to view the code you are reusing, it might be more acceptable for the vendor to require knowledge of the implementation of the reused code instead of totally hiding all implementation details, which most often makes life easier for the reuser. That means that the reuser must have a firm grasp of the inner workings of the component it wants to reuse before he or she can make it work correctly.
Another idea behind COM was that it needed to be language-independent; in essence, with COM, programmers are able to choose among several different languages. To make this work, certain rules need to be complied with, and the interfaces of the components must be described with Interface Definition Language (IDL), which is then compiled and transformed into type libraries.
The designers of COM were of the opinion that object-orientation was the way to go, and that object-orientation provided a sound base from which to work. One problem COM addressed was versioning, so that a component could be extended while still being compatible with existing consumers. Meanwhile, COM (or rather DCOM for Distributed COM) also focused on creating a method to split applications so that different parts of the workload can be executed on different machines.
MTS/COM+ Component Services
COM was a big leap in the right direction, but Microsoft Transaction Server (MTS) took COM to the next level. MTS added some runtime services for COM components, such as declarative distributed transactions, declarative role-based security, administrative support, and resource pooling, to name a few. In a way, MTS added services to the operating system that developers who wrote distributed applications previously had to build on their own. Soon after MTS was released, pure DCOM applications became a rarity in the industry.
A friend of mine who works as a project manager often asks me how long it will take me to write a certain program. I always tell him that it will take two days. (That is the universal answer, right?) His response is always one of shock: "How can it possibly take two days to check a check box?" he asks. In fact, with MTS's attribute-based programming, my friend's shock is a bit more justified, because more programming can be accomplished through simple declaration or by setting an attribute value. Transactions in COM+ is one example, referential integrity in SQL Server another.
With Windows 2000, MTS was upgraded to COM+. While MTS was actually an add-on to Windows NT, COM+ was natively supported by Windows 2000. This simplified the programming model quite a bit. It was often said that MTS + COM = COM+. In essence, COM+ joined these two previously separated parts. In addition, COM+ added component services, such as Object Pooling (OP), Compensating Resource Manager (CRM), and Queued Components (QC).
VB
I started my adventures in Windows programming with VB1. I still remember my first major mistake in that environment. It's actually rather embarrassing to share, but it makes me sentimental in a nice way. I was supposed to build a menu application from which several other applications should be started. It was an early "portal" of sorts. My boss wanted me to use pictures instead of text on the buttons, so I used picture boxes instead of command buttons. Unfortunately, I managed to insert pictures, each having a size of approximately 200KB, but only 1KB was actually of interest and shown from each of them. The exe was over 2MB large, which made for very slow startup on the hardware at that time, especially in relationship to what a rocket-science application it was.
Several years and many mistakes later, VB4 was released. It was the first really COM-competent version of Visual Basic. Still, it wasn't until VB5 and VB6 that the COM programming in VB became popular. One of the great (but sometimes also negative) aspects of VB is that it hides several details of COM, such as class factories, reference counting, user-defined interfaces (if desired), IDL, and QueryInterface. You can't achieve as good a performance out of VB as you can from C++, but the productivity is very good. Still, in some camps, VB is considered more of a toy than a tool for a professional programmer. In fact, I've been asked more than once if I get paid to program in VB. The good news is that Visual Basic .NET will change the opinions of some of those who see VB as just a toy. So you no longer have to be embarrassed to admit it if it is your favorite programming language.
SQL Server
I learned SQL at the university in the late 1980s, and it is still useful today. Actually, it's more important to master than ever, especially if you find scalability vital for your applications. Since I started working with SQL Server (version 4), its programming model, with its triggers and stored procedures, has remained quite consistent. For example, the shift from version 6.5 to version 7 was a major one at the engine level, but T-SQL didn't change that much at all.
A friend of mine once said, "Database design is important. Databases are used in 102% of all applications today." I think many developers agree that databases are used a lot. I also think that there is a large difference in opinion regarding whether the database tier—such as SQL Server 2000, for example—should be used for data-focused logic.
I fall on the extreme yes side. You will see me present my position throughout the book; stored procedures, for example, will have a central role in several of the proposed solutions. However, even though I am fond of using database capabilities, I definitely want to encapsulate the access calls to them so they are not visible to more layers than necessary.
Now, let's turn our attention to .NET, which can be seen as the fourth version of COM (after pure COM, MTS, and COM+). Saying that, COM is dead, but long live COM (now called .NET)!
A Few Important Definitions
Before we get too far along in the book, I'd like to define a few terms I will be using in these chapters that have many different meanings in the industry:
-
Component—If you agree with Szyperski5, the word "component" refers to a COM server, such as a DLL or a .NET assembly, that is a binary collection of classes. The COM+ definition of the word refers to one single binary class. I prefer this COM+ definition.
Tier and layer—I used to think the terms tier and layer were synonyms. Over the last few years, I have come to understand that layer is logical, while tier is physical. Unfortunately, this explanation isn't very distinct. For example, I like to think of the server-side components as one tier and SQL Server as another, but sometimes they execute physically at the same machine. Therefore, in this book, I will use the word tier to refer to the execution environment and layer to refer to a logical slice of a tier. Typical execution environments include ASP.NET, SQL Server, COM+, Web browser, XML Web Services, and Ordinary Win32 exes.