.Net versus COM+ components

[Guest]

What is the general difference between .Net and COM+ components? When is one
better than the other? Where can I find information about the similarities
and differences? I have browsed msdn but so far I have not found much useful
information.

 

[Angelos Karantzalis]

..NET classes are regular objects. They live in the same process with their
caller, and that's that.

COM+ Components offer some more advanced functionality, for instance:

1) Transactions. Imagine a process that needs to get some data through say 5
objects for processing. If one of them fails, you don't want to "save" the
changes the ones before it have made, and you don't want to process the data
any further. COM+ will allow you to do that ( in simple terms )

2) Clustering/Load Balancing: In cases of high loads, the container can pool
instances of your object, even in different machines, and re-use them. That
saves you a lot of instantiation overhead.

3) Synchronization: You can define how your object is accessed from
different caller threads.

COM+ will give you all that, with an added overhead in coding & complexity.
It takes a while to get acquainted with all it's little idiosyncracies &
tricks. In addition, you can create COM+ components using .NET relatively
easily.

In any case that you absolutely need all the above, COM+ will do the trick
for you. If you want to develop something simple that will not have to
process thousands of requests in 3 milliseconds ( I wish !), go for
plain-old-.NET-objects.

Angel
O:]

 

[Sujith S. Varier]

Hi Angelos,

I read your reply on COM+ .NET comparison. One of the points actually
conflicts with my idea on this..
like..
- you ahve written that .net classes are instantiated in the same
process as that of the caller.
But actually we can have both in process and out of process componets as
we have in COM (some keywords client activated, singleton,singlecall etc),
but here the things are lil bit differnet becasue there is some thing like
application domain ...which is not actually equivalent to a process. ANyway
the objects need not always be in the same process as that of the
caller.(Details i think we can get from MSDN)

Angelos, if i am wrong, correct me.

regards
Sujith S.Varier

.NET classes are regular objects. They live in the same process with their
caller, and that's that.

COM+ Components offer some more advanced functionality, for instance:

1) Transactions. Imagine a process that needs to get some data through say 5
objects for processing. If one of them fails, you don't want to "save" the
changes the ones before it have made, and you don't want to process the data
any further. COM+ will allow you to do that ( in simple terms )

2) Clustering/Load Balancing: In cases of high loads, the container can pool
instances of your object, even in different machines, and re-use them. That
saves you a lot of instantiation overhead.

3) Synchronization: You can define how your object is accessed from
different caller threads.

COM+ will give you all that, with an added overhead in coding & complexity.
It takes a while to get acquainted with all it's little idiosyncracies &
tricks. In addition, you can create COM+ components using .NET relatively
easily.

In any case that you absolutely need all the above, COM+ will do the trick
for you. If you want to develop something simple that will not have to
process thousands of requests in 3 milliseconds ( I wish !), go for
plain-old-.NET-objects.

Angel
O:]

What is the general difference between .Net and COM+ components? When is one
better than the other? Where can I find information about the similarities
and differences? I have browsed msdn but so far I have not found much useful
information.

 

[Angelos Karantzalis]

You mean that if i create a class MyClass, put it in a class library
(assembly DLL) and have the assembly referenced from another project, where
the code is like:

MyClass obj = new MyClass();

... I can specify in advance what process this class instance will run in ?

That sounds a bit weird to me. This is functionality provided by COM & COM+,
no ? Perhaps you mean .NET COM+ components ? Your suggestion is something
new to me :?

Angel
O:]

Hi Angelos,

I read your reply on COM+ .NET comparison. One of the points actually
conflicts with my idea on this..
like..
- you ahve written that .net classes are instantiated in the same
process as that of the caller.
But actually we can have both in process and out of process componets as
we have in COM (some keywords client activated, singleton,singlecall etc),
but here the things are lil bit differnet becasue there is some thing like
application domain ...which is not actually equivalent to a process. ANyway
the objects need not always be in the same process as that of the
caller.(Details i think we can get from MSDN)

Angelos, if i am wrong, correct me.

regards
Sujith S.Varier

.NET classes are regular objects. They live in the same process with their
caller, and that's that.

COM+ Components offer some more advanced functionality, for instance:

1) Transactions. Imagine a process that needs to get some data through

say

5
objects for processing. If one of them fails, you don't want to "save" the
changes the ones before it have made, and you don't want to process the data
any further. COM+ will allow you to do that ( in simple terms )

2) Clustering/Load Balancing: In cases of high loads, the container can pool
instances of your object, even in different machines, and re-use them. That
saves you a lot of instantiation overhead.

3) Synchronization: You can define how your object is accessed from
different caller threads.

COM+ will give you all that, with an added overhead in coding & complexity.
It takes a while to get acquainted with all it's little idiosyncracies &
tricks. In addition, you can create COM+ components using .NET relatively
easily.

In any case that you absolutely need all the above, COM+ will do the trick
for you. If you want to develop something simple that will not have to
process thousands of requests in 3 milliseconds ( I wish !), go for
plain-old-.NET-objects.

Angel
O:]

What is the general difference between .Net and COM+ components? When

is
one

better than the other? Where can I find information about the similarities
and differences? I have browsed msdn but so far I have not found much useful
information.

 

[Sujith S. Varier]

I mean we have the provision to get a reference to an instance of a class
which is being instantiated in another process.
i ahve a class, I want to invoke a method in a class in another assembly,
let it be in a diffeerent machine, i want to get it executed there and only
the return value is of my interest, then, the only way here would be to
instantiate the class in a process running there. We should get a reference
to the instance, actually a proxy would be present at the client..I think u
got the point, i am talking abt Remoting. Exaclty the way DCOM was being
used.

regards
Sujith S. Varier

You mean that if i create a class MyClass, put it in a class library
(assembly DLL) and have the assembly referenced from another project, where
the code is like:

MyClass obj = new MyClass();

.. I can specify in advance what process this class instance will run in ?

That sounds a bit weird to me. This is functionality provided by COM & COM+,
no ? Perhaps you mean .NET COM+ components ? Your suggestion is something
new to me :?

Angel
O:]

Hi Angelos,

I read your reply on COM+ .NET comparison. One of the points actually
conflicts with my idea on this..
like..
- you ahve written that .net classes are instantiated in the same
process as that of the caller.
But actually we can have both in process and out of process

componets

as
we have in COM (some keywords client activated, singleton,singlecall etc),
but here the things are lil bit differnet becasue there is some thing like
application domain ...which is not actually equivalent to a process. ANyway
the objects need not always be in the same process as that of the
caller.(Details i think we can get from MSDN)

Angelos, if i am wrong, correct me.

regards
Sujith S.Varier

.NET classes are regular objects. They live in the same process with their
caller, and that's that.

COM+ Components offer some more advanced functionality, for instance:

1) Transactions. Imagine a process that needs to get some data through

say

5
objects for processing. If one of them fails, you don't want to "save" the
changes the ones before it have made, and you don't want to process

the
data

any further. COM+ will allow you to do that ( in simple terms )

2) Clustering/Load Balancing: In cases of high loads, the container

can
pool

instances of your object, even in different machines, and re-use them. That
saves you a lot of instantiation overhead.

3) Synchronization: You can define how your object is accessed from
different caller threads.

COM+ will give you all that, with an added overhead in coding & complexity.
It takes a while to get acquainted with all it's little idiosyncracies &
tricks. In addition, you can create COM+ components using .NET relatively
easily.

In any case that you absolutely need all the above, COM+ will do the trick
for you. If you want to develop something simple that will not have to
process thousands of requests in 3 milliseconds ( I wish !), go for
plain-old-.NET-objects.

Angel
O:]

What is the general difference between .Net and COM+ components?

When

is

 

[Guest]

It is common misconception that .NET and COM+ are contrary to each other
infact .NET and COM+ are two different things. As .NET components runs on CLR
and gets thr runtime featurs of CLR but COM+ is just an enhancement of
MTS,DCOM and MSMQ with some new feature. Just it gives you neccessary
infrastructure to the component so the developer can concentrate on the
application logic rather than infrastructure.This infrastructure including
automatic transaction, object pooling, Just-in-time activation etc This
infrastructure can be used by COM or .NET dlls. In .NET , if you want to use
it , you have to inherit your class from
System.EnterpriseService.ServicedComponent class and register your assembly
through Regasm tool.

 

[Angelos Karantzalis]

ooohhhh .. I see. Well, Remoting is another ballgame altogether ( I kinda
like it though, since I started out as a Java/CORBA & Java/RMI boy in my
Distributed computing adventures, but I certainly wouldn't use it unless I
definitely had to ... )

Angel
O:]

I mean we have the provision to get a reference to an instance of a class
which is being instantiated in another process.
i ahve a class, I want to invoke a method in a class in another assembly,
let it be in a diffeerent machine, i want to get it executed there and only
the return value is of my interest, then, the only way here would be to
instantiate the class in a process running there. We should get a reference
to the instance, actually a proxy would be present at the client..I think u
got the point, i am talking abt Remoting. Exaclty the way DCOM was being
used.

regards
Sujith S. Varier

You mean that if i create a class MyClass, put it in a class library
(assembly DLL) and have the assembly referenced from another project, where
the code is like:

MyClass obj = new MyClass();

.. I can specify in advance what process this class instance will run in ?

That sounds a bit weird to me. This is functionality provided by COM & COM+,
no ? Perhaps you mean .NET COM+ components ? Your suggestion is something
new to me :?

Angel
O:]

Hi Angelos,

I read your reply on COM+ .NET comparison. One of the points actually
conflicts with my idea on this..
like..
- you ahve written that .net classes are instantiated in the same
process as that of the caller.
But actually we can have both in process and out of process

componets

as
we have in COM (some keywords client activated, singleton,singlecall etc),
but here the things are lil bit differnet becasue there is some thing like
application domain ...which is not actually equivalent to a process. ANyway
the objects need not always be in the same process as that of the
caller.(Details i think we can get from MSDN)

Angelos, if i am wrong, correct me.

regards
Sujith S.Varier

.NET classes are regular objects. They live in the same process with their
caller, and that's that.

COM+ Components offer some more advanced functionality, for instance:

1) Transactions. Imagine a process that needs to get some data

through
say

5
objects for processing. If one of them fails, you don't want to

"save"
the

changes the ones before it have made, and you don't want to process the
data
any further. COM+ will allow you to do that ( in simple terms )

2) Clustering/Load Balancing: In cases of high loads, the container can
pool
instances of your object, even in different machines, and re-use them.
That
saves you a lot of instantiation overhead.

3) Synchronization: You can define how your object is accessed from
different caller threads.

COM+ will give you all that, with an added overhead in coding &
complexity.
It takes a while to get acquainted with all it's little

idiosyncracies

&

tricks. In addition, you can create COM+ components using .NET relatively
easily.

In any case that you absolutely need all the above, COM+ will do the trick
for you. If you want to develop something simple that will not have to
process thousands of requests in 3 milliseconds ( I wish !), go for
plain-old-.NET-objects.

Angel
O:]

What is the general difference between .Net and COM+ components?

When

is
one
better than the other? Where can I find information about the
similarities
and differences? I have browsed msdn but so far I have not found much
useful
information.