Slashdot Mirror
Programming .NET Components
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.
This article from earlier today explained it all
The lack of starndardized libraries. KParts, Bonbobo, XParts, DCOP, XUL, OpenOffice are all competing technologies. No one component model for linux. Wan't the KHTML part to display a webpage in your gnumeric spreadshit? No, you can't do it yet.
I just hope the proposed Xembed standard gets implemented soon, or Linux will be screwed on the desktop for a while
Finally, someone that at least indirectly acknowledges that Microsoft oriented programming is at least worth reading about. I am like many people who read slashdot in that I think Microsoft doesn't play nice in the industry, but they are, like it or not, the de facto standard out there.
Nuttles
Christian and proud of it
Heheheh As a computer programmer myself, I tend to like to see everything that exist in the world. I don't care if it's made by the evil monopolistic giant or not.
.NET goes (while we're on the subject), I think it's ... mmm ... nice ... Too big, too bulky, I prefer J2EE to .NET 10 folds. I choke and puke every time I see some small nibblets of C#, that aberration of a language. But it's intersting to know how it works and how to code anyways.
Like the reviews author says, I find COM concepts very easy to grasp and quite interesting. Compared to CORBA, it is indeed very easy to use.
As a hacker (someone who likes to know how it works), I find that very interesting. As someone who code for Mac and Palm, I find I can apply many concepts of COM to my code and make it object-portable.
As far as
By the way, LMAO yes hell is all frozen I think. What the heck, M$ coding book ? EEEK!
Mike
Thank you! And please, while you're at it, remind the Slashdot crowd of the stupid "one install per system" idiocy that M$ forces on you. Want to test multiple versions of something some COM component? Buy more windows boxes!!!
Javascript + Nintendo DSi = DSiCade
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.
First of all, J2EE is not the relevant technology. Java RMI is. RMI is massively simpler than DCOM, which, contrary to this author's take, is a nasty mess of C-inspired foolishness. ;-)
In fact, .Net is largely the latest kludge slapped on top of COM/DCOM to try and hide it's hideous complexity. The programming community should wake up and see the obvious fact that Java provides everything that .Net provides, but in a platform neutral and sane manner. It even works great on Windows. (And for those of you that would bring up Mono - we'll discuss that again the day that Microsoft sues for patent infringement under the DMCA.)
Microsoft - Just Say No.
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
Understanding the ins and outs of J2EE is not the hard part of enterprise development. Understanding things like async messaging, transactions, and multithreaded logic are what makes enterprise development difficult. Switching to .NET because you don't 'get' J2EE will not magically make you understand these complex ideas.
.NET examples, then fine. But it's not learning the particular technology that's the hard part...it's learning the theory that drives it.
If this book does a better job of explaining those concepts using
An irrelevant review about an irrelevant book about an irrelevant technology.
Just how is this long informercial supposed to interest us? Go ahead, mod me down, flame me for my lack of understanding, but I have worked extensively with COM+ over the last years and I regret ever starting with the stuff.
Am I the only one detecting a current of counter-revolution in Slashdot? Negative moderations of eminently reasonable comments by pro-MS and pro-RIAA voices we can't identify?
A small voice says: stick to the point, people, or the point will stick it to you.
Ceci n'est pas une signature
Maybe thats why corporate application I've worked on the last 4 years has deployed on Solaris or Linux using Java or C++ and Corba....
It maybe the defacto standard for mail servers (exchange) but thats all I've seen it used for.
It's defacto if you want to write video games.
So Long and Thanks for all the Fish.
I don't really understand your comment.
Look: my company designs transactional web processing applications.
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.
It's not about Windows vs. Linux, this is a stupid misdirection on your part. COM is not simple, it is a mass of layers which can be simplified with the appropriate packaging (as can any technology), but which remains complex, slow, and unreliable at the core.
Now explain once again why I personally am part of the reason for what exactly? Or HIBT?
Ceci n'est pas une signature
COM was a pain in C++.
COM is pretty easy in C++ with the #import key word. Actually, it's very easy with that one as VC++ will generate wrapper classes for you to communicate with the component. The only difference from VB should be the syntax; you wouldn't write much more code to accomplish the same thing. Sure, #import is probably a VC++ specific key word, but as COM is an MS-specific technology and VC++ is the dominating IDE on Windows, I don't really see a problem with that.
Beware: In C++, your friends can see your privates!
In the beginning, UNIX was ahead. It had multiple processes, pipes, and signals. This looked like reasonable interprogram communication back in the late 1970s, but it's too low-level; trying to do anything that way is painful.
The problem is that what you want is a subroutine call, but what the OS usually gives you is an I/O operation. Some OSs do have good interprocess message passing as standard - QNX, Mach, L4/Hurd, and AmigaOS have it. The others need some kind of middleware to build message passing on top of I/O operations.
In the Microsoft world, that middleware is always there, and you can assume its presence. In the Unix/Linux world, you can't. That's why few open source programs are built that way.
Worse, the message-passing middleware for Unix and Linux carries excess baggage. CORBA for Linux is big, heavy, and available from at least five different sources in incompatible forms. The GNOME people finally had to implement their own CORBA, but it's still at the beta level. GNOME wants it mostly as an internal interface for GNOME components, so they're not too concerned with external compatibility.
OpenOffice uses an incompatible system called UNO. There's an effort to build a CORBA-UNO translating gateway, but the systems have conceptual differences and don't play well together. And, of course, all this translation drives overhead up.
Related to this problem is inadequate language support for inter-object communication. Newer languages like Java and C# have some built-in support for serialization, marshalling, and introspection, but C and C++ do not. So the operation that really has to be efficient - turning a local object into a string of bytes - tends to be slow.
Because this is more of a standards problem than a technology problem, it's tough to fix in the open source environment.
I'm going to guess you were being sarcastic. For your information, .NET is not "simply one more layer" around the old COM code. It is internally, completely and totally different and unrelated to COM. It is a complete departure from it. Period. If you don't understand that, you don't know enough about COM or .NET to be speaking on the subject.
Forget the whales - save the babies.
Eeek! Maybe actually trying to understand Wines implementation of DCOM has fried my mind, but COM/DCOM cannot possibly ever be called conceptually easy. Oh sure, the IUnknown/ClassFactory stuff, while a pain in the ass, is easy enough to understand.
Now start trying to implement late binding on your object so it's usable from JavaScript. You do that by implementing IDispatch right? Wrong. IDispatch is such a horribly complex interface that MSDN recommends you don't try and implement it, because you'll get it wrong - and they're right, you will. Instead, you should use the provided typelib invokers. Now you have to describe your object using a typelib. There are two different typelib file formats, and they can be standalone or embedded in DLLs.
Of course, IDispatch binds on an interface, but you have to be careful - due to obscure implementation details, you can't have more than one of them. Therefore, you have to choose a primary interface to be your dispinterface.
Careful! You initialized OLE Automation (a part of DCOM) but forgot to process the message loop, didn't you? Now everything is locking up, right? You just have to know that inter-thread RPC in DCOM takes place via window messages, so bash that loop boy. Just be aware that the DCOM runtime runs its own message loop for re-entrancy reasons, so you could find your WndProc running while another part of the code is supposedly blocking on a remote interface call.
Confused yet?
If you're an Open Source developer who's the least bit suspicious that Microsoft has anything to do with the latest IP attacks against Linux, I can't imagine why you would touch .NET with a ten foot pole. You're just begging to have all your hard work stolen in court.
I came to computers as a physicist. They filled rooms and were tended to by swarms of real scientists and engineers, not "technicians".
They were built by scientists and engineers for scientists and engineers.
The languages developed to program them, and the logical grammer developed within these languages, were those in common use by scientists and engineers, which is to say mathmatical syntax, grammer and logic. That's why they're called computers and not emailers or blogers.
This lead to the rise of "functional" programing through the natural course of things as computers became advanced enough to ignore the physical architecture when programing them. The Function is the natural "object" of the mathmatical language. You can do anything on a computer with the purely functional approach and, what may be hard for the modern trained mind to grasp, the mathmatically trained mind can often do so faster and easier this way than with any of the more recent "developments" in programing.
This is not to say that other ways of looking at things doesn't have its, ummm, functionality. The Object Oriented approach was developed by engineers ( who didn't have very mathmatical minds and didn't particularly understand computers or programing) to conceptualize and solve certain engineering problems dealing with real objects. Beams, pistons and the like. It made a lot of sense to model these objects as objects. What may not be obvious the Object Oriented programer is that these objects are still mathmatical models, in fact just a class (sorry) of function whose variables are handled in a predefined sort of way making the function into a kind of virtual Mechano set.
The way these varibles are handled from and programer point of view ( once the object itself is written) constitutes a user interface to the object.
What Microsoft is doing at the logical and matmatical scale isn't really any different, they're just using a slightly different terminolgy and logic to accomplish largely the same end, but one they are able to "brand" and control, not to mention leverage for their own dominence.
The main difference is that their interface is more ridigly controled by them, being sold by an "ease of use" argument of many small componants which are really just objects with a restricted interface, replacing understanding of what you are doing mathmatically and logically with a kind of tinkertoy set of objects. Just plug 'em together and watch 'em work.
I don't wish to ruffle any feathers, but I'm not particularly afraid of doing so.
This is an approach that may be valid for the modern crop of "programer", but if you wish to honestly be considered a computer engineer, let alone a computer "scientist", it is a largely unworkable solution, just as a person adept at using tinkertoys and mechano sets isn't qualfied to be called an engineer.
This isn't to belittle tinkertoys and mechano sets either. They have their valid place and uses.
Personally I've been "Object Oriented" programing since before there was any such thing. It's an obvious format for modeling real objects in a compact, understandable, easily modified and reusable way, although I didn't call my "beam object" a beam object. I called it my beam function, because that's what it is, even though it may well contain subfuntions while at the same time being a subfunction of the "building function."
I've always tended to think of my programing models in terms of ICs. Note that there are two basic kinds of ICs. Those that are hard wired to perform a single task, such as the venerable 555 chip, and those that are designed with a changable internal logic (you're using at least one of these right now to read this post) such as the Z80.
Both of these kinds of ICs have their valid uses. The programable chip hasn't replaced the hard wired chip, it has augmented the toolset available. Both kinds of mathmatical logic these chips represent are valuable to the programer in t
Thats the first time I saw those two words connected together, com is a lousy hack on the C++ VTABLEs for plugging an interface mechanism into C++ to the worse they than did the hard work to bend this full thing over into C and you have a real mess on your hands.
Com is by far the worst component model out there, compared to the simplicity of java beans (which avoids interfaces for reflection) the usage of interfaces in the language level and the simplicity of pure OO component models like KParts (you mentioned you haven't found anything on KDE)
you basically can say Com is the worst of it all.
DCom basically was a technology to take over Corba after Microsoft was sitting for years in the Corba consortium to get a grasp on the technology, it failed because as usual Microsoft tied DCOM to windows and therefore was no real competition to a cross platform solution.
There is...in this months ( Sept 2003 ) .Net magazine, there's an article about what they call "Rich Clients" ( though they throw in Macromedia Flash ). Which essentially are ASP.NET driven pages which can be manipulated by back-end assemblies. The example shown at:
http://www-106.ibm.com/developerworks/java/library /j-struts/
( almost half-way down the page ) is a model which can be implemented by server-side ASP and C#/VB components. You'd be using the MTS/MSMQ "parts" of .NET.
You know, every once in a while someone makes a really stupid comparison between the people who were responsible for the murder of millions of human beings, and something incredibly trivial like using the "wrong" type of software. And it really pisses me off.
Yes, I have a sense of humor. No, this isn't funny.
Struts is a framework for development in the model-view-controller paradigm.
.net that closely resembles struts. But asp.net itself solves (or rather, makes it easier for the developer to solve) many of the same problems that struts solves, just in a different way.
Then again, ASP.NET is supposed to be more MVC-centric as well.
From a high-level perspective, struts by itself focuses primarily on the "controller" part. I believe jakarta-tiles is now integrated with the latest version, and tiles focuses on the view part.
You could actually build a framework in
-CausticPuppy "Of all the people I know, you're certainly one of them." -Somebody I don't know
There was nothing particularly wrong with the approach M$ took with only allowing one instance of a single version of a component to be installed. The problem was all the hackers out there who didn't understand the versioning schema - and hence failed to provide backwards compatibility for their components under the same GUID.
COM is complicated - but then again so is J2EE (which is what I'm now developing with).
Under .NET everything gets much nicer with the fine grained versioning and scoping on assemblies. Oh yes, and let's see how Java approaches the issue - ah yes - we ignore it entirely. OK we don't have system wide issues, but if you've ever played the game called "which version of Xerces works with all my third party utilities" you'll know what I mean.
Microsoft has its problems - but they think through their stuff well.
In fact COM/DCOM always seemed to be the poor man's version of CORBA (COM can be seen as equivalent to in-process activations of CORBA servers). Writing CORBA services using emacs on an out-dated Sun box in the graduate computer lab seemed a great deal easier than the gymnastics we had to go through with DCOM. (Including setting up our own development PDC, much to the chagrin of the network admins).
Leave the gun, take the cannoli -- Clemenza, The Godfather