Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Microsoft The Internet Book Reviews IT Technology

Programming .NET Components 327

Posted by timothy from the strings-and-knots dept.
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.
This discussion has been archived. No new comments can be posted.

Programming .NET Components More

Programming .NET Components

Comments Filter:

  • This is what this article is about. (Score:5, Insightful)

    by Anonymous Coward on Thursday August 28, 2003 @12:46PM (#6816003)
    This article from earlier today explained it all [slashdot.org]
    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 [freedesktop.org] standard gets implemented soon, or Linux will be screwed on the desktop for a while
    • 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.

      And you never will be able to. And that's a good thing. To many people, it's questionable whether component models are ever a good thing, and there are big differences in how to implement them. By creating many different desktops and having them compete, good co
    • XUL is not a component framework, it's a javascript/xml based interface language that just happens to use XPCOM, which IS a component framework. XPCOM is very similar to COM+, with some of the more obscure cruft taken out and some things missing (like a global standard transaction manager and remoting support).

      You make a good point, however, I just wanted to clarify what exactly XUL is, becuase it is definitely NOT a component framework.

      Bryan

  • What? (Score:5, Funny)

    by JohnwheeleR ( 662355 ) on Thursday August 28, 2003 @12:46PM (#6816004)
    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


    Why anyone would say DCOM is more graspable than J2EE is IUnknown

    • Comment removed based on user account deletion

    • Re:What? (Score:3, Funny)

      by dnoyeb ( 547705 )
      Of course DCOM is simpler than CORBA or J2EE.

      CORBA is cross-language.

      J2EE is cross-platform.

      DCOM is cross-yourfingers.

      (j/k, I actually like DCOM, but it has a much simpler task)

  • Microsoft (Score:4, Insightful)

    by Nuttles ( 625038 ) on Thursday August 28, 2003 @12:49PM (#6816039)
    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

    • Re:Microsoft (Score:5, Insightful)

      by Winterblink ( 575267 ) on Thursday August 28, 2003 @12:56PM (#6816118) Homepage
      Well, whether the greater /. crowd realizes it or not, there's a lot of us who regularly contribute around here that develop on the Microsoft platform and do so willingly. Lets face it, there's lots of work out there for this stuff, and if I can make money doing it then great. While at times Slashdot can be rather hostile towards Microsoft anything, it's still a pretty good resource for interesting IT information and wacky links.

    • Standard for what? (Score:5, Interesting)

      by Dr. Bent ( 533421 ) <ben.int@com> on Thursday August 28, 2003 @01:06PM (#6816227) Homepage
      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.
    • "Microsoft... the de facto standard out there"

      That's because, if they weren't the de facto standard, they'd simply integrate it into their product line and force everyone to use it. Can you say Monopoly?

    • Re:Microsoft (Score:4, Insightful)

      by rutledjw ( 447990 ) on Thursday August 28, 2003 @01:26PM (#6816450) Homepage
      "de facto standard" how? On server-side stuff? They are not. On Web Servers? Nope. App Servers? No. DB? Programming Language(s)?

      They control the desktop and have a majority of the browser market. How that makes them a "de facto standard" for server-side and/or OO programming languages I'm not certian.

      Especially considering that .NET is an attempt to implement Java / JVM concepts within an MS-only environment

    • 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.

    • Re:Microsoft (Score:4, Insightful)

      by twocents ( 310492 ) on Thursday August 28, 2003 @01:54PM (#6816784)
      but they are, like it or not, the de facto standard out there.

      Unless you count databases, web, mail, and print servers.

      Sorry if I missed some.

  • Simplicity??? (Score:5, Interesting)

    by Stiletto ( 12066 ) on Thursday August 28, 2003 @12:49PM (#6816047)
    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??? (Score:3, Insightful)

      by AKAImBatman ( 238306 )
      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!!!

      • Re:Simplicity??? (Score:2, Insightful)

        by nixer ( 692046 )
        Actually you can put two copies of the same COM component on the same system - it's called side-by-side running. It aint pretty, but it works.

        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

      • Re:Simplicity??? (Score:3, Interesting)

        by ncc74656 ( 45571 )
        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:Simplicity??? (Score:5, Interesting)

      by msheppard ( 150231 ) on Thursday August 28, 2003 @01:09PM (#6816256) Homepage Journal
      COM was a pain in C++. COM was easy as pie in VB. .NET components work equally easy in C# or VB.NET

      M@
      • VB - Large Project? You gotta be kiddin.

        • Re:Simplicity??? (Score:4, Informative)

          by Gaijin42 ( 317411 ) on Thursday August 28, 2003 @02:19PM (#6817019)
          for VB = 6 I agree 100%

          For vb.net, it is fully featured, and just as powerfull as c#

          I personally prefer c# syntax, because it is more terse, and more strict. Its also closer to Java and C (obviously) so I dont have to do as much mind shifting about case sensitivity, semicolons, etc.

      • Re:Simplicity??? (Score:3, Insightful)

        by Jugalator ( 259273 )
        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.

    • Re:Simplicity??? (Score:5, Interesting)

      by anonymous loser ( 58627 ) on Thursday August 28, 2003 @01:22PM (#6816416)
      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??? (Score:5, Interesting)

        by RelliK ( 4466 ) on Thursday August 28, 2003 @01:41PM (#6816618)
        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...

        • ... because COM has alot of technical advantages over static linking. Like not needing to worry about binary compatability, for example, just interface compatability. Thats a massive gain for anyone who cares about backwards compatability, which is a big deal to Microsoft.

        • 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 scri

    • Re:Simplicity??? (Score:2, Interesting)

      by mattgreen ( 701203 )
      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, a
    • I was wondering if somebody was gonna say that. I was beginning to doubt my gut-reaction. (ie: COM sucks donkey nads, especially when you wind up bailing out collegues who try to use it)

      Who ever thought exporting Microsoft's C++ vtable and calling it a "standard" was a good idea should have at least 2 fingers removed for the pain and suffering they've caused. Binary artifacts like that belong *below* the abstraction level!!

  • April Fools? (Score:2, Insightful)

    by Glock27 ( 446276 )
    Upon finding the following statement, I realized I was either the victim of a hoax, or reading a review by a fairly unqualified reviewer. ;-)

    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 l

    • In fact, .Net is largely the latest kludge slapped on top of COM/DCOM to try and hide it's hideous complexity.

      You have to be kidding me-- .net has nothing to do with dcom/com, other than provide a wrapper that can be used with old components.

      • Re:April Fools? (Score:2, Insightful)

        by Glock27 ( 446276 )
        You have to be kidding me-- .net has nothing to do with dcom/com, other than provide a wrapper that can be used with old components.

        Are you claiming that every .Net component isn't a COM component?

        Further, the "wrappers" you mentioned are exactly the kludge I was referring to. ;-)

        • I'll claim it. a .NET assembly is NOT a COM component. They have similarities in design, because they address much of the same problem space, but thats as far as it goes. .NET provides wrappers for COM interop. These wrappers are needed because (suprise) .NET isn't COM and can't interact with it directly.

    • Re:April Fools? (Score:5, Insightful)

      by leerpm ( 570963 ) on Thursday August 28, 2003 @01:13PM (#6816315)
      And upon reading your comment, I realized I was reading a statement by an unqualified critic.

      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.)

      No, .Net is not a kludge slapped on top of of COM. It is a platform created from the ground up to replace COM, among many other things. Many of the .Net APIs do call upon various services implemented in COM. But that is only because Micrsoft has not had the time to port that code to managed .Net code. I will agree that Java and .Net provide many similar services, they have more things in common than differences. However there are some things Java does better, and there are some things that .Net does better.

      And your statement about Mono? How on earth does the DMCA relate to patent law? It is called the Digital Millenium Copyright Act.
      • And upon reading your comment, I realized I was reading a statement by an unqualified critic.

        Well, I'm certainly qualified in one sense of the word. I've developed COM components in C++(ATL). Have you? It was not a fun experience. Do you know the difference between a BSTR, and a WSTR? What a mess.

        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 tha

        • I'm pretty sure that my worst programming experience thus far was trying to write multi-threaded COM object in ATL that talk to hardware via parallel and serial ports. All the worst parts of each one of those technologies rolled into one horrible experience.

          I did, however, get it to work.

          ATL... ack... better than MFC, but not by much.

        • You don't know what the fuck you're talking about. I've written COM components in C++ too, it's a pain in the ass. It's easier in VB, which is why there's a ton of VB ActiveX controls out there.

          .NET doesn't have anything to do with COM, and is certainly not a wrapper on top of it. Your initial post claiming this is bullshit and trying to redirect the argument to whether or not .NET is a good idea is irrelevent.

          The DMCA was used against DeCSS by claiming it was a copyright infringment tool, which is one of

    • .NET is many things, but kludge slapped on top of COM it most certainly is not. Yes, DCOM is a bit of a mess, but much of .NET is a "new" take on OO and remoting. Well, yes, it owes a lot to Java and related technologies (only a fool would claim otherwise). But much is a clean code base and pretty good. There is COM interop for compatibility, and the EnterpriseServices namespace *Is* still dependendent on the COM+/MTS code base, but that will probably change anyway over time. Most of .NET is COM independent
    • Java provides everything that .Net provides, but in a platform neutral and sane manner

      Java is not platform neutral. Java, the language, only *officially* runs on the JVM, the Java platform. This platform has been ported to a number of different hardware and operating system combinations, but it most certainly is not platform independent.

      Note that I'm not bashing Java in anyway - it's been my primary programming language for about three years now.

  • Pearls of Wisdom from Morpheus (Score:5, Funny)

    by GillBates0 ( 664202 ) on Thursday August 28, 2003 @01:02PM (#6816182) Homepage Journal
    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.

    Before making any knee-jerk comments regarding the post, take a moment to ponder over these pearls of wisdom from none other than the great Morpheus, which are very relevant in this context. Take heed and realize that the poster is but part of the system. Forgive him.

    "Microsoft Windows is a system, Neo. That system is our enemy. But when you're inside, you look around and what do you see? Businessmen, Teachers, Lawyers, Carpenters...the very minds of the people we're trying to save. But until we do, these people are still a part of that system, and that makes them our enemy. You have to understand, most of these people are not ready to be unplugged from Windows. And many of them are so innerred, so hopelessly dependent on the system that they will that they will fight to protect it. Are you listening to me, Neo? Or were you laughing at the stupid MSN fairy again?"

  • portability (Score:3, Interesting)

    by u19925 ( 613350 ) on Thursday August 28, 2003 @01:07PM (#6816240)
    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.

  • CORBA vs .NET (Score:2, Informative)

    by Anonymous Coward
    Ok lets see we can choose something which works, is industry proven, IS a real standard set forth by a commitee (OMG) or we can have .NET a fake standard certified by ECMA (who got lots of $$$ for calling .NET a standard). .NET lacks a lot of cross platform availablity that CORBA has. Just about anything can use CORBA: C, PHP, PERL, C++, OBJC, JAVA, SMALLTALK, PASCAL, DELPHI, the list goes on. .NET has yet to prove itself, as well most java/.net interaction is done through CORBA.
    • Erm, you are aware that ECMA actually is a standards body, while the OMG is basically a private club of software vendors? And that few standards bodys do work just for fun?

      Not that I'm all that fond of .NET, but that argument is pretty weak.

    • Re:CORBA vs .NET (Score:2, Informative)

      by mrlpz ( 605212 )
      Both of the previous replies respond to your point as well. But I don't see any language you've got listed up there who doesn't have some adapability to being able to utilize COM objects in one form or another ( When implemented on Windows, of course. ).

      I remember when CORBA was really "gathering steam" ( at least from the number of contracting projects out there calling for it ), and remember seeing some of my OOD/OOP bretheren head off to Corba-based projects. I can think of only two of them who ever sai

  • Troll Alert (Score:2, Redundant)

    by donutello ( 88309 )
    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.

    Ha! Be prepared to be modded down like the astroturfing troll you are! Ooops.. too late for that I guess.

  • COM and CORBA (Score:3, Interesting)

    by u19925 ( 613350 ) on Thursday August 28, 2003 @01:13PM (#6816308)
    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.

  • Technology is not the hard part (Score:4, Insightful)

    by Dr. Bent ( 533421 ) <ben.int@com> on Thursday August 28, 2003 @01:19PM (#6816372) Homepage
    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.

    If this book does a better job of explaining those concepts using .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.
  • I appreciate that the metadata is the managed code and the Language neutrality of the project, but I still think questions need to answered about if this is really just a new way to try to kill Java, and how nice it'll play with projects like Mono after it takes off.

    CB

  • Highly recommended (Score:2, Informative)

    by garoush ( 111257 )
    This is one of the best books I read in a while about .Net To give you some insight download and read C# Coding Standard [idesign.net] by Juval Lowy
  • 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 th
  • COM/DCOM are a messy hack on top of C++ virtual tables. They are not a good thing, nor is there anything new in COM/DCOM relative to earlier OO component architectures. They are, in fact, so much not a good thing that Microsoft cloned Java in order to replace COM/DCOM with the C# object model.

    J2EE is a mess, but you can't fault the underlying object and component model for that.

  • /.s been hacked. (Score:3, Funny)

    by 514x0r ( 691137 ) on Thursday August 28, 2003 @01:52PM (#6816760)
    first there's an article touting the benefits of COM+--i disagree, but it's your opinion--then, when i go to read it, there's a windows server 2003 ad at the top of the screen

  • The open source world is behind here (Score:3, Insightful)

    by Animats ( 122034 ) on Thursday August 28, 2003 @02:24PM (#6817066) Homepage
    One of the big problems in the Open Source world is that methods for program to program communication haven't really kept up.

    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 [openoffice.org], 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.

  • Microsoft IP? (Score:3, Insightful)

    by Max Threshold ( 540114 ) on Thursday August 28, 2003 @03:16PM (#6817633)
    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.

  • Back in the day. . . (Score:3, Insightful)

    by kfg ( 145172 ) on Thursday August 28, 2003 @03:21PM (#6817725)
    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
    • Ah bugger. I didn't preview and missed closing a tag properly. Why doesn't someone invent an idiot proof markup language. There isn't any reason in this day and age we should have to deal with this low level shit.

      I didn't buy a computer so I'd have to think.

      KFG

  • DCOM easy? (Score:2, Insightful)

    by iPaul ( 559200 )
    After doing a sizeable amount of CORBA work (including writing a trader service) in graduate school I did about a year and a half of COM/DCOM programming in VC++ (5.0 and 6.0). I also did an amount of Java RMI and Java CORBA programming after the Microsoft stuff. In no sense of the word "easy" was DCOM easier than even C++ CORBA. And in no way was it easier than Java RMI or Java CORBA!

    In fact COM/DCOM always seemed to be the poor man's version of CORBA (COM can be seen as equivalent to in-process activ

Slashdot Top Deals

"I'm a mean green mother from outer space" -- Audrey II, The Little Shop of Horrors

Close