How many people really use COM+/.NET EnterpriseServices?

tags:

com+

views:

answers:

+2 Q:

How many people really use COM+/.NET EnterpriseServices?

I am learning about COM+ and EnterpriseServices. I came across the complete list of COM+ services on MSDN and read every one of them.

The sheer volume of this awed me. On the surface, it seems to be a really advanced system unmatched by other development platforms. Concepts like pooling, synchronization and remoting seem really useful and they've standardized a way to do it.

On the other hand, mentions of COM+/EnterpriseServices on the net is surprisingly scarce. When I typed the title here in SO, almost all the related questions have 0 answers (hopefully this won't become one of them). I have a feeling that all these facilities are in fact mainly used by MS to implement IIS. But they published it for some marketing buzz.

Do you have any real experience using these services? Are they just some over-architectured nuisance or did you have experience where they turned to be real time savers?

COM+ services are somewhat dated, in the sense that there are more modern ways to do most of what COM+ does.

On the other hand, one can use .NET to create COM+ services, so it's not dead yet.

BTW, why are you learning about COM+?

John Saunders 2010-07-07 02:15:39

All of the pages in the OP's link say "Build Date 5/20/2010".

Robert Harvey 2010-07-07 02:17:11

Sorry, missed that he found that on MSDN, which is actually worse. The fact that MSDN documents something has little bearing on whether anyone is using it.

John Saunders 2010-07-07 02:23:47

Well, I joined an MS shop and apparently many clients use COM+ so one of our products (we create libraries) support being created as a COM+ service. What would be the "more modern ways" for example?

kizzx2 2010-07-07 03:08:49

@kizzx2: Using .NET instead of C++, using WCF, using the `TransactionScope` class, etc. COM+ is from the days when the features in your list were _only_ implemented by COM+. That was about a decade ago...

John Saunders 2010-07-07 05:51:28

COM services don't work through firewalls (except for the SOAP services).
COM+ is designed primarily for Microsoft Visual C++ and Microsoft Visual Basic developers
COM+ is an older technology (i.e. it is not the flavor of the week).

The link at the bottom of this page (linking to a video explaining the new features in COM+ 1.5) no longer works.

Dig into COM long enough, and you will stumble into the reasons .NET took over the COM world.

Robert Harvey 2010-07-07 02:19:13

Dig into COM+ enough and you will find that COM+ was originally intended to be far more than it was and when it actually arrived contained a lot less than what was originally promised. Some years later, a lot of that promise was finally delivered.... in .NET. Some parts of the .NET runtime still reveal their COM+ heritage.

Deltics 2010-07-07 02:35:37

Well, how about the EnterpriseServices part? Is that part where COM+ "lived on"? If so, are people actually, pragmatically using those complicated Enterprise Services?

kizzx2 2010-07-07 03:09:46

I think it would be fair to say that most, if not all of the useful COM+ services have been absorbed into the .NET framework, either having .NET wrappers, or being rewritten in .NET.

Robert Harvey 2010-07-07 05:34:36

@Deltics: did you read that list of COM+ services? What was promised beyond what was in that list?

John Saunders 2010-07-07 05:57:34

@John: There was a white paper before COM+ arrived describing what COM+ was going to deliver. What ended up missing was a lot of the core underlying technology/platform features, and COM+ became merely a suite of services. Common language runtime and cross-language implementation inheritance and debugging support etc etc. Essentially the CTS and CLR is what ended up missing. That white paper itself has disappeared however, but the .NET runtime still contains COM+ "archeology" in that area, (e.g iirc the GC has/or had PerfMon counters with names that still refer to themselves as COM+).

Deltics 2010-07-07 21:03:52

@Deltics: parts of COM+ started development as an enhancement to COM+. I am surprised that I don't recall such a white paper, as I was working for a Microsoft Partner at that time, working specifically in the COM/COM+ area. I also don't recall anything about the development of managed languages before .NET, so I can't think where CTS and CLR would have come in. If you can find that white paper, or a reference to it, that would be useful.

John Saunders 2010-07-07 21:13:37

@John: The white paper didn't mention managed languages - it posited a technology that would allow a COM+ object to be extended in a language independent fashion (e.g. C++ could be used to extend a VB object) and a debugging framework that would allow you to transition from one language to the other. It didn't specify how this would be achieved. It was some time ago that I saw the paper, but I never kept a copy and it has proven impossible to find since, but I definitely saw it, and it was definitely before COM+ was "delivered" ... (cont)

Deltics 2010-07-07 22:21:35

...(cont) MTS was still relatively new at the time that I saw the paper and MS were still trying to beat Java with itself (via their J++ "trojan"). When COM+ eventually arrived it was clearly just MTS 2.0 renamed, then when .NET arrived I recognised it as largely what COM+ was originally intended to be, combined with the dead/dying J++ (managed execution environment), thinly masked by the "all new" languages for the new platform (C# etc).

Deltics 2010-07-07 22:24:38

ansaurus

tags:

views:

answers:

How many people really use COM+/.NET EnterpriseServices?

related questions