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

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

Happy reading.
Willy.


"Kyle Adams" <kyle.adams@bointonyel_spammersbeware_.info> wrote in message
news:4118ffb1$0$74186$(E-Mail Removed)...
>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
>
>

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.


--
- Nicholas Paldino [.NET/C# MVP]
- (E-Mail Removed)



"Kyle Adams" <kyle.adams@bointonyel_spammersbeware_.info> wrote in message
news:4118ffb1$0$74186$(E-Mail Removed)...
> 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
>
>

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" <kyle.adams@bointonyel_spammersbeware_.info> wrote in message
news:4118ffb1$0$74186$(E-Mail Removed)...
> 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
>
>

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




One Handed Man ( OHM - Terry Burns ) wrote:
> 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.
>
>
> "Kyle Adams" <kyle.adams@bointonyel_spammersbeware_.info> wrote in
> message news:4118ffb1$0$74186$(E-Mail Removed)...
>> 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

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/2.../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 Removed)

>
> --Richard
>
>
> "Kyle Adams" wrote:
>
> > 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
> >
> >
> >
> >
> > One Handed Man ( OHM - Terry Burns ) wrote:
> > > 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.
> > >
> > >
> > > "Kyle Adams" <kyle.adams@bointonyel_spammersbeware_.info> wrote in
> > > message news:4118ffb1$0$74186$(E-Mail Removed)...
> > >> 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
> >
> >
> >

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.


"Richard" <(E-Mail Removed)> wrote in message
news:B32D5BEF-4837-4A4E-AE6A-(E-Mail Removed)...
>
> 1) Microsoft has clearly stated that C# is the 'now language'. I'd
> recommend learning C# if that's what you're asking in your "language of my
> choice - what then" question...
>
> 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 . 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...
>
> 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...
>
> --Richard
>
>
> "Kyle Adams" wrote:
>
>> 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
>>
>>
>>
>>
>> One Handed Man ( OHM - Terry Burns ) wrote:
>> > 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.
>> >
>> >
>> > "Kyle Adams" <kyle.adams@bointonyel_spammersbeware_.info> wrote in
>> > message news:4118ffb1$0$74186$(E-Mail Removed)...
>> >> 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
>>
>>
>>

Well said.

"Willy Denoyette [MVP]" wrote:

> 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.
>
>
> "Richard" <(E-Mail Removed)> wrote in message
> news:B32D5BEF-4837-4A4E-AE6A-(E-Mail Removed)...
> >
> > 1) Microsoft has clearly stated that C# is the 'now language'. I'd
> > recommend learning C# if that's what you're asking in your "language of my
> > choice - what then" question...
> >
> > 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 . 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...
> >
> > 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...
> >
> > --Richard
> >
> >
> > "Kyle Adams" wrote:
> >
> >> 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
> >>
> >>
> >>
> >>
> >> One Handed Man ( OHM - Terry Burns ) wrote:
> >> > 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.
> >> >
> >> >
> >> > "Kyle Adams" <kyle.adams@bointonyel_spammersbeware_.info> wrote in
> >> > message news:4118ffb1$0$74186$(E-Mail Removed)...
> >> >> 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
> >>
> >>
> >>
>
>
>

Well Said.

"Nicholas Paldino [.NET/C# MVP]" wrote:

> 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/2.../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 Removed)
>
> >
> > --Richard
> >
> >
> > "Kyle Adams" wrote:
> >
> > > 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
> > >
> > >
> > >
> > >
> > > One Handed Man ( OHM - Terry Burns ) wrote:
> > > > 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.
> > > >
> > > >
> > > > "Kyle Adams" <kyle.adams@bointonyel_spammersbeware_.info> wrote in
> > > > message news:4118ffb1$0$74186$(E-Mail Removed)...
> > > >> 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
> > >
> > >
> > >
>
>
>

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