Programming .NET Components

Gianluca Insolvibile writes "I plead guilty: I have always admired Microsoft's COM architecture and the relative simplicity that allows you to reuse already installed components to create even complex programs. And I have always been fascinated by the distributed nature of DCOM, which seemed to me much more graspable than complex monsters like CORBA and J2EE. While looking for equally expressive Open Source component technologies among GNOME and KDE, I was never able to find something fitting my needs (I never got into Bonobo deeply enough, though)." Read on to see how this led Gianluca to Juval Loewy's O'Reilly-published Programming .NET Components, and what he thinks of the book. Programming .NET Components author Juval Loewy pages 460 publisher O'Reilly rating 7.5 reviewer Gianluca Insolvibile ISBN 0596003471 summary An introduction to components-oriented development with the tools and services provided by the .NET framework

One day, I stumbled upon the mono and Portable.NET projects, which are trying to bring all the .NET stuff to the penguin platform. This was the main reason that convinced me to learn more on .NET: open specs, a component-enabling technology, the cross-platform mirage, a completely new (well, sort of) set of concepts to be grasped, and something which I could use both on Linux and on Windows.

Armed with these expectations, I decided to look for a good introductory text on the .NET framework focused on components development. Among the plethora of publications on the subject, I decided to stick with a publisher having a long and respectable tradition in Open Source related books. Among the herd of funny beasts that populate O'Reilly's catalog, I picked out a "land hermit crab," aka Programming .NET Components, by Juval Loewy.

Overview The book begins with a chapter giving a rationale behind component-oriented programming versus object-oriented programming, that is, interfaces versus inheritance. The second chapter shows how those concepts are reflected in the .NET Framework, briefly introducing the Common Language Runtime (CLR), the Intermediate Language (IL) and .NET Assemblies. The following three chapters deal with interface-based programming, objects lifecycle management and versioning, gradually introducing the underlying concepts and showing how they become concrete in the .NET framework (more specifically, by using the C# language). No formal introduction to C# language constructs is given, but if you are familiar with C++ or Java you will be able to follow the code snippets fairly easily.

Events and asynchronous code execution are the subjects of Chapters 6 and 7, respectively. While the former is just a quick introduction to the C# approach to delegates and events (yet useful if you are new to the matter), the chapter on asynchronous calls is much more substantial. The mechanics behind async calls are explained, together with pros and cons of using callbacks, BeginInvoke() and EndInvoke() calls, one-way methods, and so on.

Chapter 8 is devoted to Multithreading and Concurrency. Commonplace concepts like threads application and usage are explained, as always dressed with a bit of C# syntax. While such concepts are easily found in any multithreaded programming tutorial on the Internet, explaining them from the basics never hurts -- and prepares the reader to the most insidious traps of multithreaded programming. Synchronization appropriately takes a fair part of Chapter 8: automatic and manual synchronization provided by the .NET runtime environment are explained, together with the concepts of contexts and synchronization domains. This part is quite interesting, since it delves into .NET specific concepts which are quite new to programmers who had a happy Microsoft-less childhood (though they might not be so new to people who speak COM fluently). Other .NET threading related services (such as timers) are presented at the end of the chapter.

Chapter 9, devoted to object serialization and persistence, describes how live objects can be transformed (formatted) into a stream of bytes to be sent over a network channel, or stored on a persistent storage medium. This chapter lays the grounds for the exacting chapter on remoting, which follows immediately. Chapter 10 is the longest and most content-rich chapter of the book: first, the entire story of native processes, .NET app domains and assemblies is told. After reading it here, it won't look so confusing as before. Then, objects marshaling, remote callbacks, synchronization and activation modes are described, including client and server activated, single-call and singleton modes. Afterwards, the author gets to a global overview of the .NET remoting architecture, its basic building blocks (like proxies, transport channels and call dispatchers) and working mechanisms (like type registration and environment configuration). A reprise on objects sponsorship and leasing closes the chapter and completes the discussion on objects' lifecycle left pending in Chapter 4. Chapter 10 offers a lot of interesting cues, but unfortunately cannot dig deeply enough in the subject (after all, this is not a book on remoting). Many people (including Juval himself) recommend Ingo Rammer's Advanced .NET Remoting (APress) to learn more on the topic, but I have yet to get my hands on it.

Chapter 11 reprises the description of contexts in .NET, this time focusing on calls interception. The whole interception architecture is described with a fair level of detail and, as always, in a clear and understandable way. Context-agile and context-bound objects are described, as well as .NET and custom component services. While reading this chapter, you start understanding that contexts, app domains, call interception and remoting are tightly interwoven and that their full understanding is the real key to the exploitation of the .NET platform potential. Unfortunately, this is where the book leaves you alone -- but I strongly suspect that a full coverage of these topics would have required an entire book on its own.

The last chapter of the book deals with the .NET Security architecture, introducing the concepts of permissions, code groups and policies. Security administration is explained, both from a system configuration and a programmatic point of view.

What's to like What I liked most is the straightforward approach of the author in introducing the rationale behind components, components-based programming and their support in the .NET Framework: each concept is walked through step-by-step, instead of being presented in a complete working example with little or no explanation. Hence, you won't get working code on page 3 of the book -- instead, you will gradually learn how to write some.

Indeed, I found the description of awkward concepts like asynchronous calls, multithreading and remoting very clear, even for someone with no previous experience with .NET and C#.

I also consider a plus the broad experience the author has in the field, which shines through the many programming hints given, and in lots of references to concepts in COM which have an homologous in .NET.

I finally found the book to have the right balance between printed code and text (that is: do not fill hundreds of pages with code, I'll look at it online).

What's to consider Programming .NET Components is just an introductory book: it points you in the right direction toward components programming with .NET, but does not bring you very far. If you are really serious about learning .NET advanced topics, you will need a more specific tome to complement (or substitute for) this one.

More specifically, the 70 pages which cover remoting are just an introduction to the matter. The same applies to some of the most important concepts revolving around .NET (app domains, contexts, and the like).

Finally, despite the subtitle ("Design and Build Maintainable Systems using Components-Oriented Programming"), be warned that this is not at all a book on software design (components oriented programming is covered in just 15 pages).

The summary Reading the book goes without a glitch, thanks to a smooth writing style and a very structured approach to explaining concepts. Still, when I turned the last page of the book I felt that my understanding of components within the .NET platform was far from complete.

.NET Components Programming is quite fair to its title: it will teach you how to program components by using .NET constructs, but (apart from some quick notes here and there) it will not provide extensive coverage of components oriented design and development. If you are already familiar with .NET concepts and are looking for something shedding light on components programming, this book will not help you significantly. On the contrary, if you know something about components and want to start developing them into the .NET Framework, this will surely be an interesting read.

Table of Contents
Preface
Chapter 1. Introducing Component-oriented programming
Chapter 2. .NET Component-oriented Programming Essentials
Chapter 3. Interface-based Programming
Chapter 4. Lifecycle Management
Chapter 5. Version Control
Chapter 6. Events
Chapter 7. Asynchronous Calls
Chapter 8. Multithreading and Concurrency Management
Chapter 9. Serialization and Persistence
Chapter 10. Remoting
Chapter 11. Context and Interception
Chapter 12. Security
Appendix A. Interface-based Web-services
Appendix B. Custom Security Principal
Appendix C. Reflection and Attributes

You can purchase Programming .NET Components from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Simplicity???

[Stiletto]

I have always admired Microsoft's COM architecture and the relative simplicity that allows you to reuse already installed components

"Simplicity" is probably the one word you can't use to describe that nightmare called COM. COM makes programmers jump through hoops to achieve what plain vanilla C++ (mostly) already provides. Anyone who has ever tried to do a large project using COM (no, that little DirectX Tetris game doesn't count) can attest to the pain and suffering the architecture inflicts on those unlucky enough to have to use it.

Re:Simplicity???

[msheppard]

COM was a pain in C++. COM was easy as pie in VB. .NET components work equally easy in C# or VB.NET

M@

Re:Simplicity???

[anonymous loser]

COM makes programmers jump through hoops to achieve what plain vanilla C++ (mostly) already provides. Anyone who has ever tried to do a large project using COM (no, that little DirectX Tetris game doesn't count) can attest to the pain and suffering the architecture inflicts on those unlucky enough to have to use it.

COM can definitely be challenging sometimes when things don't work properly, but in my experience it makes my life easier much more often than it makes my life more difficult.

For example, I'd say it's MUCH easier to use the COM-reliant WSH (Windows Scripting Host) to add scripting capabilities to my application than it is to write my own interpreters for all those languages, or make my own scripting language. I've done both, and using WSH takes almost no time or effort, whereas writing my own backend and/or language compiler/interpreter can take days.

If I want to integrate my application with other windows apps, COM is pretty much the only way to go. Some programs MIGHT offer a native C++ or Java API, but 99% of the time the applications I have to integrate with expose a COM API exclusively. So, writing my app using vanilla C++ doesn't do much since I have to do all that COM programming anyway.

Similarly, if I want other programs to be able to talk to mine, exposing a COM API is usually my best bet, since it allows people to choose from a variety of languages, perform rapid prototyping quickly and easily, and be able to quickly integrate my application into other applications I hadn't even considered. Anyone can pick up a bit of VBScript or VBA and figure out how to use my application through its COM API. I've had managers muddle through simple excel macros to control my software and do some great customization that way, but a C/C++/Java API means only other programmers will be able to take advantage of that feature. IMHO There's no point in developing features only a select few users will be able to take advantage of.

And getting back to WSH, this also means that users don't have to be programmers to use other windows programs from my application, either. Want to make my app export data directly to Excel and plot it? No problem! Record a macro in Excel and you're halfway there!

When all bets are in, I'd much rather have COM than not have it. All of the hoops you refer to are what make COM so easy to use from a higher level of abstraction, which was the goal in the first place. The places where it runs into problems are generally where the spec (IMHO) is ill-defined (or undefined) such as how to effectively handle multi-threaded apps talking to single-threaded apps and vice-versa, determining how and when to display a user interface for a program that is being controlled via COM, determining how and when a program should clean-up and exit that is being controlled by its API (e.g. some programs require you explicitly to call a "quit" function, even though releasing the object should be sufficient), and the semantics for getting/using/releasing COM objects for programs that users are already running. Despite those flaws, I still get a lot of mileage out of COM, and I spend a lot more time making useful things happen than being mired in the tedious bits.

Re:Simplicity???

[RelliK]

For example, I'd say it's MUCH easier to use the COM-reliant WSH (Windows Scripting Host) to add scripting capabilities to my application than it is to write my own interpreters for all those languages, or make my own scripting language. I've done both, and using WSH takes almost no time or effort, whereas writing my own backend and/or language compiler/interpreter can take days.

This example is stupid. You are saying that it is much easier to use a third-party library than to write your own implementation. Well, duh! And it makes no difference whether you access the library via COM or plain C++ / Java / whatever interface.

If I want to integrate my application with other windows apps, COM is pretty much the only way to go. Some programs MIGHT offer a native C++ or Java API, but 99% of the time the applications I have to integrate with expose a COM API exclusively. So, writing my app using vanilla C++ doesn't do much since I have to do all that COM programming anyway.

There! Now we get to the real reason windows programmers use COM: they are forced to!

I've had managers muddle through simple excel macros to control my software and do some great customization that way, but a C/C++/Java API means only other programmers will be able to take advantage of that feature.

There are other ways to do it. There is no reason why excel couldn't have a scripting library to link with your application. It's no different from linking with WSH. But Microsoft chose COM...

Re:Simplicity???

[mattgreen]

COM was designed to erode the differences between programming languages on the Win32 platform. Obviously this isn't easy or elegant. Most painful is probably querying for interfaces using the awful ID strings, and marshaling all your parameters. In addition, I don't see how equalizing the languages is a good thing. If I develop an extensible application, I would *not* want users writing plugins using VB. With that in mind .NET can be seen as COM 2.0, because all the languages compile to a common format, and are really just a choice of your favorite grammar.

Re:Simplicity???

[anonymous loser]

This example is stupid. You are saying that it is much easier to use a third-party library than to write your own implementation. Well, duh! And it makes no difference whether you access the library via COM or plain C++ / Java / whatever interface.

No, you are both oversimplifying what I said, and putting words in my mouth. What I'm saying is that thanks to the COM interface architecture, there are ubiquitous components that can all talk to each other with relative ease, making stuff like adding a scripting language relatively painless. Conversely, I have used C and C++ libraries for doing that stuff as well, and it is anything but painless. It's better than coding everything by hand, but not as easy as COM and WSH make it.

There! Now we get to the real reason windows programmers use COM: they are forced to!

Huh? Most programs expose a COM API exclusively because it gives you the most functionality for the effort required. It isn't costly to implement, you can access it from any language with relative ease, and it's strongly supported by the OS. Nobody is forced to use COM, and frankly I would love it if I could use COM on UNIX, too. It would make UNIX component programming much easier than it is. CORBA is a clusterfuck that really takes a lot of work to implement even if you are using the latest whiz-bang commercial libraries. I spent a lot of time doing CORBA and other component integration before I finally learned COM. COM is downright simple by comparison.

There are other ways to do it. There is no reason why excel couldn't have a scripting library to link with your application. It's no different from linking with WSH. But Microsoft chose COM...

And there's no reason UNIX apps couldn't support COM, either. It's an open standard, and IMHO it's better than what you suggest since it allows my to dynamically declare and use interfaces. Meaning, I don't have to link to the programs I wish to integrate with. Instead I can just say "create an instance of this object" when I want to use it, and the OS takes care of the rest-it figures out if it needs to link to a library, start an executable, or whatever.

Re:Simplicity???

[ncc74656]

And please, while you're at it, remind the Slashdot crowd of the stupid "one install per system" idiocy that M$ forces on you.

MSDN includes access to all of the desktop and server versions of Windows, and you can have up to 10 machines running desktop Windows. They figured that a coder would have multiple machines and accomodated that.

Nice attempt at a troll, though. Not.

Re:DCOM vs .NET?

[Pfhreakaz0id]

umm, his comment was And I have always been fascinated by the distributed nature of DCOM, which seemed to me much more graspable than complex monsters like CORBA and J2EE.

DCOM, can, indeed be a mess when things go wrong. Show me a dcom programmer who doesn't know how to use dcomcnfg fluently and you're probably looking at someone padding their resume. But so can EJB's (want to see our organizations Oracle TAR's on EJB context lookups? There are many... and you have no clear idea to track down the problems).

I think .NET remoting is an attempt at a compromise between those two (caveat: I haven't done a lot with it), we'll see how it works out.

Re:.NET is crap

[the_rev_matt]

No technology is trying to become Cold Fusion. .Net is trying to become Java, and so is Java, but no one in their right mind wants to aspire to be an evolutionary dead end like CF. Macromedia (who now one CF) are slowly migrating all CF to J2EE and will kill of CF.

Standard for what?

[Dr. Bent]

Microsoft doesn't play nice in the industry, but they are, like it or not, the de facto standard out there.

Microsoft may be the defacto standard for client side apps. But on the server side it holds no such title, and enterprise development is supposed to be what DCOM is all about. Things like J2EE and CORBA have way more of a hold on enterprise development than anything that Microsoft has ever put out. There's a big difference between a single-user desktop operating system and a multi-user scalable enterprise platform. From what I've seen, Microsoft has only been sucessful with the former.

portability

[u19925]

it was more than 5 years ago, microsoft mentioned that they will port DCOM to unix. This killed of many CORBA projects on windows at many organizations. COM specs are binary specs. I am not sure about DCOM and ActiveX. But microsoft hasn't been able to port to unix even after 5 years. Either they lied or it is extremely difficult. CORBA is the only architecture which is alternative to DCOM. Not sure, how much of its complexity is due to portability.

Re:.NET is crap

[orionware]

Obviously you don't use them both.

Macromedia is not going to kill off Coldfusion and replace it with j2EE. CF is built on top of Java and co-exists very well with Java and can even be extended with Java. Other than that they are two completely different types of technology and have two different uses.

Java is for those who still think that Java is the only serious development tool for the net regardless of the long dev cycle and CF is for those who understand that rapid development and ease of maintenance is often key in sucessfull projects.

We were a huge JSP/J2EE/EJB shop and now rarely use it. It's just not necessary... CF is more than capable and just as fast for anything that is not massivly back end heavy.

COM and CORBA

[u19925]

If you were to program in C using COM and CORBA based purely on their specification, which one would be easy to program? COM spec is from MS and using their tools in C# and C++, you can simplify things, but that doesn't make COM or DCOM simpler.

Re:April Fools?

[Glock27]

[uninformed attack snipped]

Read some of my other responses, I think I covered almost everything there. The one bit I need to respond to is your comment regarding Java:

Almost as great as everything else that happens to be an afterthought port of some wacky technology from another OS.

First off, .Net is clearly the sincerest form of flattery: a blatant ripoff of Java in almost every respect.

Secondly, the Windows port of Java is arguably the most robust port of any, so calling it an "afterthought" simply labels you as ignorant.

Finally, comparable Java code often outperforms C# on Windows...so any imaginary advantage you think .Net might have on it's "native platform" is exactly that. Imaginary.

Very courageous posting as an AC, BTW. ;-)

Have a nice day.

Re:Sigh. Do we really need this?

[plierhead]

In 1996 we built a portable transaction monitor that is used today in several very large web applications that run on Linux. The entire TP monitor is only several thousand lines of C, the applications are extremely simple, and it all works beautifully.

In 1998 we were asked to make something very similar, but using MTS and COM+. The animal works, but it is incredibly complex, slow, unstable, and frankly impossible to control totally. When we approach the limits of the system in any sense, it collapses, and we cannot do anything to discover why.

I know jack shit about .NET and would never consider using it, but I have seen exactly the same experience with J2EE. Relatively simple applications, which solely produce web pages from the data in a single underlying RDBMS, and could be easily (and appropriately) built just using servlets, are turned into stinking, creaking and groaning and sluggish monsters by introducing EJB servers in the middle.

Anything that introduces more threads and more machines is going to have a wicked effect on your performance and productivity. Its not unique to .NET.

That said, if there has to be a big crusty layer in the middle, I'd rather it was built by someone else than the Borg - in the scale of their commercial interests, your application's scalability and reliability come very low indeed.