DCOM, COM+, COM, MTS; what are they?

[Kyle Adams]

I don't know where is the right place to ask this so I will start here.

Can someone explain to me what these represent? I think they all have to do
with the middleware level, but I really don't understand what a DCOM Server
is or a Microsoft Transaction Server, etc. I have no idea....


Kyle

 

[Willy Denoyette [MVP]]

Go to http://www.microsoft.com/ and search for COM, DCOM, MTS ...

Happy reading.
Willy.

 

[Nicholas Paldino [.NET/C# MVP]]

Kyle,

It's a lot of acronyms to get right. Here is a breakdown of what they
are:

COM - Short for Component Object Model. It is an interface-based component
model which allowed different languages to produce code that would be able
to interact easily with other languages. It also was a first attempt at
component-based design (because of the emphasis on interfaces).

MTS - Short for Microsoft Transaction Server. This was introduced in Option
Pack 4 for NT and used the fact that COM is an interface-based model to
provide aspects to code (such as transactioning). MTS was the transaction
coordinator.

DCOM - Short for Distributed COM. It used the fact that everything was
interface based to provide proxies which would allow for communication
between threading apartments.

COM+ - Well, COM+. It took things like DCOM, MTS, and all of the other
aspects provided by the OS to COM components, and wrapped them up into this
package. Things such as queued components, transactions, object pooling,
JITA, etc, etc are all exposed through this. All of these services are
exposed through the ServicedComponent class in .NET

Hope this helps.

 

[One Handed Man \( OHM - Terry Burns \)]

COM
An acronym for Component Object Model, the name of Microsoft's design
strategy to implement OLE 2+ and ActiveX. Distributed COM (DCOM) allows
networked and cross-platform implementation of ActiveX and OLE 2+ operations
and Automation.

DCOM
An acronym for Distributed Common Object Model that allows communication and
manipulation of objects over a network connection. Windows NT 4.0 was the
first Microsoft operating system to support DCOM (formerly called
NetworkOLE).

COM+
COM+ isan extension to Microsoft's Component Object Model (COM). COM+ builds
on COM's integrated services and features, making it easier for developers
to create and use software components in any language, using any tool.
Delivered on the Microsoft Windows platform, COM+ is designed to preserve
and extend current investments in COM. Applications currently using COM
technology will work in the COM+ environment.

MTS
Microsoft Transaction Server. A part of Windows NT server providing
transaction support for COM components over a distributed network.

--



OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

 

[Kyle Adams]

Thanks folks. I should have added MSMQ because I think it is related.

But here's the next question (at least about COM/DCOM/COM+). If I write
objects in the dot net framework language of my choice, what then? Let's
say I make a dll that handles invoicing on our accounting system. The smart
approach in a big environment is to put that in the middle layer, right? So
my backend is SQL S, front end is web or windows forms, and middle layer is
what? What do I choose? Do I use one of these 3?

Is that how you implement (D)COM(+)? Do you make DLLS and put them on a
middle-ware server or am I totally missing it? That is, is the middle layer
COM/DCOM/COM+ just a memory and processing space where compiled dlls live?

And how does web services come into play here? Is web services an attempt
to kill the middle layer or is it the next step in the progression?

thanks for the great responses

 

[Nicholas Paldino [.NET/C# MVP]]

With all due respect, much of this is just plain wrong.

See inline:

2) COM, DCOM, MTS etc... are quite passe {that's a good thing because I
don't care what anybody on the newsgroup says DCOM security was a flippin
nightmare!!!}. Anyway, ".NET Remoting" is the replacement for DCOM and it's
very nice .

.NET remoting is NOT the replacement for COM+ or DCOM. Remoting is
missing authentication, authorization, and all of the other aspects that
COM+ provides. Also, MS has publically stated that remoting is not going to
be improved upon anymore, rather, Indigo will be pushed as the new
communication/aspect providing mechanism.

Furthermore, MS has publically stated that currently, Enterprise
Services (ES, or COM+ in .NET) is the recommended technology of choice today
to provide the easiest migration experience to Indigo.

Also as other posters have pointed out the cool features of
COM+ are mostly built in to classes in the .NET framework so no need to pull
your hair out trying to learn how to build & deploy MTS packages or any of
that older stuff; learn the framework - be the framework...

The idea of COM+ is that you don't have to manage these things
programattically. COM+ allows for easy changes of the aspects it provides
through configuration, not through recompiles of code.

Oh yeah, one other teeny tiny little thing:

3) Depending on how close you live to Redmond WA the incredibly loud noise
you hear is a HUGE train coming down the tracks at you. The train's name is
"SOA": Service Oriented Architecture. XML Web Services and SOA; live them,
learn them, love them...

Remoting provides nothing in terms of migration towards a SOA. Indigo
is meant to be the technology of choice for SOA. As stated before, ES is
the preferred technology of choice when it comes to easy migration to
Indigo.

Don Box even said as much. Check out Tim Sneath's weblog (he works for
MS):

http://blogs.msdn.com/tims/archive/2004/02/24/79054.aspx

In the third paragraph he states:

Don Box even recommended (in his PDC WSV201 talk) combining ASP.NET Web
Services with Enterprise Services today for the easiest migration, which is
interesting.

So basically, use ES, and if you have to expose for SOA, layer your WS
(use WS extensions) on top of ES.

 

[Willy Denoyette [MVP]]

As Nicolas stated in his reply, some of your reflections are plain wrong, I
would add the following:
1. MS never stated that C# is the 'now language'.
2. DCOM and COM aren't quite passé, f.i DCOM will be one of the possible
wire level protocols available with Indigo.
COM (and DCOM) has become part of all currently available Windows OS (and
the upcoming Longhorn), and it's the only viable technology available
for native clients to use .NET components/services. So we can safely say
that COM's (and COM based technologies) life cycle is tied to Windows OS
(or better Win32/Win64) life cycle.
3. DCOM and COM are the base components used by COM+, and COM+ is the
core of .NET's EnterpriseServices
The "cool features are" COM+ features (native code services) the FCL ES
classes are simple wrappers around COM+, using COM and DCOM to cross the
native/managed border.
4. SOA is not a component technology, it's a service technology. The
services offered can use any component technology based on the end-point OS
available platform services (Java, Corba, .NET, COM+ ....).

Willy.

 

[Guest]

Well said.

As Nicolas stated in his reply, some of your reflections are plain wrong, I
would add the following:
1. MS never stated that C# is the 'now language'.
2. DCOM and COM aren't quite passé, f.i DCOM will be one of the possible
wire level protocols available with Indigo.
COM (and DCOM) has become part of all currently available Windows OS (and
the upcoming Longhorn), and it's the only viable technology available
for native clients to use .NET components/services. So we can safely say
that COM's (and COM based technologies) life cycle is tied to Windows OS
(or better Win32/Win64) life cycle.
3. DCOM and COM are the base components used by COM+, and COM+ is the
core of .NET's EnterpriseServices
The "cool features are" COM+ features (native code services) the FCL ES
classes are simple wrappers around COM+, using COM and DCOM to cross the
native/managed border.
4. SOA is not a component technology, it's a service technology. The
services offered can use any component technology based on the end-point OS
available platform services (Java, Corba, .NET, COM+ ....).

Willy.

 

[Guest]

Well Said.

With all due respect, much of this is just plain wrong.

See inline:

2) COM, DCOM, MTS etc... are quite passe {that's a good thing because I
don't care what anybody on the newsgroup says DCOM security was a flippin
nightmare!!!}. Anyway, ".NET Remoting" is the replacement for DCOM and it's
very nice .

.NET remoting is NOT the replacement for COM+ or DCOM. Remoting is
missing authentication, authorization, and all of the other aspects that
COM+ provides. Also, MS has publically stated that remoting is not going to
be improved upon anymore, rather, Indigo will be pushed as the new
communication/aspect providing mechanism.

Furthermore, MS has publically stated that currently, Enterprise
Services (ES, or COM+ in .NET) is the recommended technology of choice today
to provide the easiest migration experience to Indigo.

Also as other posters have pointed out the cool features of
COM+ are mostly built in to classes in the .NET framework so no need to pull
your hair out trying to learn how to build & deploy MTS packages or any of
that older stuff; learn the framework - be the framework...

The idea of COM+ is that you don't have to manage these things
programattically. COM+ allows for easy changes of the aspects it provides
through configuration, not through recompiles of code.

Oh yeah, one other teeny tiny little thing:

3) Depending on how close you live to Redmond WA the incredibly loud noise
you hear is a HUGE train coming down the tracks at you. The train's name is
"SOA": Service Oriented Architecture. XML Web Services and SOA; live them,
learn them, love them...

Remoting provides nothing in terms of migration towards a SOA. Indigo
is meant to be the technology of choice for SOA. As stated before, ES is
the preferred technology of choice when it comes to easy migration to
Indigo.

Don Box even said as much. Check out Tim Sneath's weblog (he works for
MS):

http://blogs.msdn.com/tims/archive/2004/02/24/79054.aspx

In the third paragraph he states:

Don Box even recommended (in his PDC WSV201 talk) combining ASP.NET Web
Services with Enterprise Services today for the easiest migration, which is
interesting.

So basically, use ES, and if you have to expose for SOA, layer your WS
(use WS extensions) on top of ES.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

--Richard

 

[Guest]

.NET remoting is NOT the replacement for COM+ or DCOM. Remoting is
missing authentication, authorization, and all of the other aspects that
COM+ provides.

Remoting also doesn't give you remote activation... On the other hand
Remoting is not RPC based and you don't need IIS running to use it...

But you are very correct on my bad choice of the word "replacement" - I went
back and re-read my post and I even disagree with it the way I wrote it...
COM+ & DCOM aren't going anywhere for very long time but they aren't the
"state of the art" anymore - I think that was more what I was trying to say.

When I read the original poster's question I interpreted it as someone
asking about doing new development today -- and with the new stuff in .NET
why on earth would you bother with something like DCOM?

Where I work now everything is COM+ and it works fine - we're not going to
get rid of it - but all of our new development efforts are moving in the
SOA/ES/Indigo direction; not COM+, MTS, and DCOM...

Also, MS has publically stated that remoting is not going to
be improved upon anymore, rather, Indigo will be pushed as the new
communication/aspect providing mechanism.

You are HUGELY correct that Indigo is going to take over. But as far as not
improving Remoting, let's face it, it's hard to "improve" on a config file
entry and 3 lines of code that gives you distributed objects...

Furthermore, MS has publically stated that currently, Enterprise
Services (ES, or COM+ in .NET) is the recommended technology of choice today
to provide the easiest migration experience to Indigo.

Yes, but the COM+ statements apply more for existing code - yes? You can
still build an MFC application if you want to, would you?

Remoting provides nothing in terms of migration towards a SOA. Indigo
is meant to be the technology of choice for SOA. As stated before, ES is
the preferred technology of choice when it comes to easy migration to
Indigo.

I hope I didn't suggest that Remoting had anything to do with migrating to
SOA. Remoting & SOA solve different problems...

So basically, use ES, and if you have to expose for SOA, layer your WS
(use WS extensions) on top of ES.

EXACTLY --> Use ES & SOA; not MTS and DCOM...

 

[Willy Denoyette [MVP]]

See inline ****

Willy.

Remoting also doesn't give you remote activation... On the other hand
Remoting is not RPC based and you don't need IIS running to use it...

*** DCOM doesn't need IIS too.

But you are very correct on my bad choice of the word "replacement" - I
went
back and re-read my post and I even disagree with it the way I wrote it...
COM+ & DCOM aren't going anywhere for very long time but they aren't the
"state of the art" anymore - I think that was more what I was trying to
say.

*** They are what they are, nothing in .NET has a replacement for them.
Like I said in another reply, .NET ES are simple wrappers around COM+ and
Remoting is not a replacement for DCOM.

When I read the original poster's question I interpreted it as someone
asking about doing new development today -- and with the new stuff in .NET
why on earth would you bother with something like DCOM?

*** Maybe because .NET uses DCOM to interact with a huge number of native
application services based on it? (COM+, AD services, WMI, Office ... to
name a few).
Whenever you need to call into native applications exposing their
functionality through COM interaces from managed code (or the other way
around), you will use DCOM. So you'll have to bother with it.

Where I work now everything is COM+ and it works fine - we're not going to
get rid of it - but all of our new development efforts are moving in the
SOA/ES/Indigo direction; not COM+, MTS, and DCOM...

*** Once again COM+ offers a number of services to managed (using ES) and
unmanaged applications like (Distributed) Transactions, threading, object
pooling, hosting, process recycling... ES is using COM+ under the covers
just like Indigo will use COM+ for some of it's service requirements.
COM+ is the successor of MTS so forget about this one and DCOM is COM's wire
level protocol used by COM+ or any other COM based application that needs
out of proc activation/instantiation and marshaling.
Simply put, remoting can only be used when both parties are .NET
applications and you don't care about security and remote activation, for
all other cases you will have to use DCOM be it directly or indirectly.

You are HUGELY correct that Indigo is going to take over. But as far as
not
improving Remoting, let's face it, it's hard to "improve" on a config file
entry and 3 lines of code that gives you distributed objects...


Yes, but the COM+ statements apply more for existing code - yes? You can
still build an MFC application if you want to, would you?

*** You are confusing API's with service based technologies like COM+.
COM+ exposes it's services through a set op COM interfaces, you can call
into COM+ by using these COM interfaces from native code (VB, C++, Delphi
....) or you can call into COM+ by using the managed interface exposed by the
ES.


Native code Managed code
| |
| |
| .NET ES classes
| |
| ____________________|
|
|
COM/DCOM (SOAP on COM+ 1.5)
|
|
COM+

I hope I didn't suggest that Remoting had anything to do with migrating to
SOA. Remoting & SOA solve different problems...


EXACTLY --> Use ES & SOA; not MTS and DCOM...

*** As I said before
- forget about MTS it is the predecessor of COM+ available on NT4, ES can't
be used on NT4 simply because it needs COM+.
- DCOM is a wire level protocol (automaticaly) used by COM based
applications like COM+, you don't program against DCOM it's not an API.

 

[Guest]

MTS is old-hat technology and is on its way out. Shame, 'cos it was nice.
Learnt about it in my MCSD, it involves creating DLLs with VB6 and then
adding them to 'packages', from where they are run on a server to access
databases.

COM is the standard method of exposing compiled code libraries to other
languages, and is very good, very complex, very popular, and very
essential-to-everyday-life.

COM+ is COM but across machines, and is the replacement for DCOM. Used for
calling code on a different machine. Can't really see much point in it
myself. If you want to run code on a different machine, use either a web
server, a SQL server, or physically go to the other machine and hit the
button.

 

[Willy Denoyette [MVP]]

Please, go and read about these technologies use them and come back when you
have a clear understanding, for the moment I would suggest you to stop
spreading this nonsence. Again, COM+ is NOT a replacement for DCOM, nor is
it "COM accross machines".

Willy.

 

[Robert May]

Ah--the good ole days.

MTS was a windows NT technology. Basically, it allows you to create COM
dlls, put them in packages and then let MTS do all of the thread pooling,
Transaction handling and stuff. MTS used DCOM and COM. DCOM is Distributed
COM--basically, when you exported a package and set it up on a remote
machine, it told the package how to create instances of the COM object on
the server rather than on the local machine.

COM+ is just the newer version of MTS that included MSMQ as part of the
install. Practically, there is very little difference between COM+ and MSMQ
and MTS and MSMQ. Lots of stuff under the sheets, but when using it, they
are very similar.

..NET still uses COM+ through the EnterpriseServices namespace.

It's still good stuff.

Robert